Response to Keith's ask on my theory of Interoperability

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 communication flow (Privacy Consent). See In Wisconsin we have Interoperability

While I am really not a fan of mechanisms that put the Patient as the means of communications. I understand that this could be the least common denominator, but why try to improve in such a undesireable way. This said, we do have the Meaningful Use feature of "Download". In fact my healthcare provider has provided this for a very long time, and I have downloaded my data. I have a copy of my data, in XDM.zip form of both PDF and CDA. So I have in my hands what, as healthcare standards geek, understand as the most highly interoperable form possible. YET, I have no clue what to do with this data. Why do I have it? Why do I need it? See I feel BlueButton advancement

yes, I know that I am lucky to be in good enough health that I 'don't need it'... and I feel for anyone that really does need it and can't get it....  This is why I continue to work on solutions that don't make practical sense to me personally.

Interoperability delivers a desired outcome that has a known value.

IHE FormatCodes are mandatory

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 the people using that specific Document Source to come to the Affinity Domain organizers and follow their Process to get their format approved. In this way the Affinity Domain starts with nothing approved. Even the IHE defined Document Content profiles are not pre-approved. Just because a formatCode exists does not mean that it is understood by Document Consumers, or that it is considered useful within that Affinity Domain.

Formats not defined by IHE are thus registered as Affinity Domain specific codes. Cases where a JPEG or PNG mime-type is needing to be registered could be discussed within that Affinity Domain to understand the details on what kind of a document is actually being recorded. The Affinity Domain could decide that the JPEG or PNG file is appropriate to register as it has a specific value, and it would assign an Affinity Domain specific code to be used. It is likely that the Affinity Domain would assign a more specific code than the Mime-Type, as they would recognize the medical significance of the JPEG. Thus the Affinity Domain could recognize multiple JPEG files for various purposes (One could point out that this variance is better managed with typeCode and classCode).   This does not diminish the usefulness of mime-type, as often that is all the Document Consumer cares about.

I am not sure IHE ever said that the Registry couldn't have been told that it's validation requirement for formatCode was to accept all codes (.*). We simply put in that it was required that validation rules would exist…

The question that triggered this post is one that asks for a general mechanism where the document is really not more distinguishable at the FormatCode level than is already defined by the mime-type. One alternative suggested is a blanket FormatCode (undifferentiated), a set of blanket FormatCodes (image, text, etc), or allowance to use mime-type as the FormatCode (which would need some codesystem). For example where the file is simply a picture from a phone-camera, a JPEG. Note that all the other metadata is useful and not in question, just not clear what to do with FormatCode.

I would push back on requests to just accept all JPEG; as I am sure there is more detail. I am guessing that we would understand that although the file format is JPEG, that the use-case is specific to something. (Note I am not picking on JPEG specifically, but using it as a representation of any class of mime-type identified document)

So this is why we defined formatCode as mandatory, and why we didn't define a type for 'any'… We wanted the Affinity Domain to be in control.

More blog articles on Document Sharing Management (Health Information Exchange - HIE)

FHIR Security initiatives

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 using UMA to authorize others to gain access to their PHR. The drawback at this point is that this seems to be rather USA centric and FHIR centric, although I don't think that is the goal of the community.

IHE – Internet User Assertion (IUA) -  This is a simple profile of OAuth2/OpenID-Connect.  There is some work underway to improve on this initial specification. Taking on some of the lessons learned from SMART, and regional deployments. This is focused tightly on just the interaction necessary to enable protected API use.  This includes DICOM and FHIR. So it is not specific to FHIR, but can be used with FHIR.  This specifies three levels: Bearer token, JWT token, and SAML encapsulated.

IHE also has a Basic Patient Privacy Consent (BPPC) profile, and there is a proposal for developing an advancement that can carry coded exceptions or additions.



SMART, -- This group has developed, among other things, a specification for OAuth based solution for authorized applications and the users using the applications. I understand that this is further being developed now under Argonaut Project. It is very FHIR  centric.

HL7 Security WG -- I am co-chair of this workgroup. This workgroup maintains the FHIR AuditEvent and FHIR Provenance resources; as well as the security guidance pages. This workgroup maintains security-tagging within the FHIR Resource header. So that each resource can be tagged with security (privacy) relevant tags that can be used in the Access Control decision, and can carry Obligations to a recipient. This workgroup cooperates with the CBCC workgroup on Privacy matters

HL7 CBCC WG -- This is the workgroup that is working on Patient Privacy Consent.  They have a CDA implementation. They are now working on a FHIR specification. The FHIR specification is currently a Profile upon Contract.

see also my blog topic on mobile security and FHIR Security: Do (Not) Worry (start worrying now).
 

Guest Post: Use-Case - Security Audit Prompts Investigation

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.