clair054

Keith asks A theory of interoperability Definitions of interoperability surround us, but all the attention in the world to definitions make very little difference in the end. ... What is your theory of interoperability?  How would you test it? My theory of Interoperabilty: Starts with a desired outcome that has a known value. Without this use-case driving interoperability you are just talking technical capabilities. Meaning, the reason why one can get PDF out of WORD, but not PDF into WORD, is because the desired outcome with a known value is to produce a report that can be rendered easily but not modified easily. Hence this is a delivered Interoperability. In healthcare, I fully understand why a Patient would want to enable a specialist to gain full access to their medical history. A understood outcome with a known value. This is why I very much support and work hard to enable providers to communicate in as full fidelity as possible, while also enabling Patients to control that ...

The expectation that the IHE ITI Technical Committee had on formatCodes was that the Affinity Domain would not want random and unspecified documents registered. As documents that can't be understood by Document Consumers are not helpful to the Affinity Domain. The Affinity Domain, which is some kind of an organization, would have some Process where those that had a new format would argue the usefulness of their document format. This Affinity Domain process would, if approved, add that formatCode to the acceptable formats in that Affinity Domain, thus triggering the Registry requirement to validate formatCodes. These codes would be either pre-coordinated, such as with IHE Document Content profiles; or would be assigned by the Affinity Domain. In this way the Affinity Domain would be able to make sure that only document types that they agreed with would be registered, and those that were not approved would be rejected. The rejection of a document type in this case could trigger th...

I am asked how someone can get engaged with developments in Privacy/Security around FHIR. I am very happy that people want to help. I am especially encouraging to anyone that has either coding experience, or deployment experience; as I find that too many people engaged in Privacy/Security around FHIR are coming from the theoretical perspective. This is a good perspective, but not sufficient to give us practical solutions. What we need today is practical solutions, that are on the trajectory of a theoretical horizon. HEART – where I think bleeding edge work is being done. This group is initiated by the OAuth / OpenID Connect / UMA communities. There are some key people involved from healthcare, more people are always welcome. There are participation from Patient advocates as well. It has taken input from various Healthcare initiatives including SMART, and Argonaut. They will be starting with simple things, but eventually want to show how a patient can interact us...

Glen Marshall is well known in Healthcare Security circles, and he continues to contribute in Retirement. He produced this use-case and I found it so well written, and it explains Security Audit Logging (FHIR AuditEvent ) as distinct from Provenance (FHIR Provenance ) so well, that I asked him if I could publish it as a guest post. I got his approval almost a month ago, so here it is. Read more »