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.

Don't disassemble ATNA, what you are looking for is there.

I have been pulled into many discussions that are not taking 'all' of ATNA. They are either just taking the audit logging, or just taking the Secure Communications. Then there are the discussions that are taking the Secure Communications but don't want to take the Client authentication. All of these discussions are missing the point of ATNA, and/or are missing the configurability that is built into ATNA.

Let me explain:

1. ATNA is a grouping of three functions: Security Audit, Secure Communications, and local Access Controls. It is only when you are assured that ALL of these functions exist that you should administratively accept the node/application, and provision a certificate. When I see groups picking and choosing parts, I worry that they might not be understanding the overall. I don’t mind treating them independent as long as this overall design is understood.

2. ATNA Secure Communications (actually Authenticate Node). is not just mutual-authenticated-TLS, although this is the predominant form (The only form for point-to-point protocols like HL7 v2, and DICOM). It also includes SMTP end-to-end security used by Direct. It includes end-to-end security for SOAP using XML-Signature and XML-Encryption….

3. ATNA Secure Communications expects that you will do certificate management (PKI) properly, that is that authenticating a node is more than just proving that the claimed identity is the one authenticated. If you don’t manage your truststore, then you are just authenticating that the identity is the one claimed in the certificate. This is the kind of https used on the internet, one that only looks to prove that the server you connected to is 'most likely' the one you intended. When you don't manage your trust-store, all you can know is that the identity seems 'most likely' to be the one you intended to connect to. This is indeed not very helpful. This is why ATNA has a long discussion around certificate management. Managing the trust-store, usually through removing the hundreds of internet Certificate Authorities (CA), and leaving only CAs that you really trust.

4. Further there is an expectation that you don’t stop at authentication, but also check that the remote node is authorized. The ATNA Secure Communications is just the “Interoperability” way to get authentication done, you still must use that authenticated identity in an authorization decision. If you fail to do this then you will certainly fail to be secure. This fact is true about ALL authentication mechanisms.

5. ATNA Secure Communications can be grouped with a user authentication profile like EUA, XUA, or IUA. This is less clear in the ATNA profile and transaction, as the transaction doesn’t mention these (beyond EUA). So you can authenticate the user at the client, in addition to authenticating the client they are on.

6. ATNA Secure Communications does specify TLS 1.0 or better, and the use of TLS_RSA_WITH_AES_128_CBC_SHA; this is an “Interoperability” statement, not a security statement. Meaning it is there to set a low bar that assures interoperability can happen. Policy is expected to take over from there, where policy can push the security criteria up as high as the actors can handle. If you are in the space of Policy, you can certainly set the Policy higher. I emphasize that IHE is focused on assuring that products come with capability that will interoperate, it is NOT constraining on the top-end and can’t constrain on the top-end; that is policy space. The profile does recommend that all crypto algorithms, and key sizes be configurable. It only specifies one set, so that interoperabililty will work, as without this it is likely two systems choose non-overlapping crypto algorithms and key sizes.

7. IHE has further explained that for HTTP traffic, it is likely that policy will allow HTTPS with no client-authentication, where the client is authenticated using IUA (OAuth). This is the same recommendation you will find in FHIR, and SMART. OAuth is an acceptable standard, it “can” represent the application as being authorized by the User. In this way it meets the expectation of ATNA Secure Communications. So if you are focused on HTTP like things, FHIR, then stop worrying about the client certificate in ATNA Secure Communications, and start demanding OAuth for client; as this does meet the ATNA requirement and is far more easy to manage in HTTP like architectures (Mutual-Auth-TLS is very hard to deal with in web centric architectures).

8. That said, although OAuth can be used to authorize background tasks for authorized applications (e.g. Facebook app does this); OAuth doesn’t work as well for cases where the identity that needs to be claimed is NOT HUMAN. Meaning it works fine for Facebook, but doesn’t work all that well for “The XCA Gateway of Kaiser”. In these cases certificates work better as they are inherently more manageable as automaton identity, vs human identity.

 

Conclusion

So, keep ATNA together, it is an important set of capabilities that if not used together don't provide security. Recognize that ATNA is just one security profile, user authentication is done with IUA, XUA, and EUA. Lastly recognize that IHE is enabling default interoperability, it is not restricting the security to that level. 

Other articles

• User Identity and Authentication
• Access Control (including Consent Enforcement)
• Audit Control
• Secure Communications
• mHealth
• The Direct Project

Where do I record the Reason that an auditable event happened?

I received a question about where to put the 'reason' that an ATNA auditable event has happened. The short answer is that Security is not interested in the reason; but Provenance is.

Hello John,

I have a question around ATNA logging. We are currently implementing the Metadata Update profile; ITI-57 "Update Document Set". [Specifically for deprecating a document without replacement.]

However, we cannot find a place to store a reason (free text), which the user can enter when deprecating the document. It does not really make sense to allow the user to enter a reason, but not log it as part of the audit trail.

The ATNA log is for Security purposes. It therefore is not interested in why. it is just interested in the fact that it happened. Security is interested in making sure that those that are not authorized to do things, are prevented from doing them. So the Security audit log is there to prove that only authorized acts are happening. If non-authorized acts are happening, then security is broken somewhere. If acts are happening that shouldn't be authorized, then the access control rules need to be changed.

This is not to say that it is not important to Medical-Records that there is a reason why the act happened. As with most information in medical records, they don’t really get removed but rather deprecated. In these transitions it is important to note why this happened. This kind of a record-keeping is Provenance, and is parallel to security/privacy audit.

The most important distinction between Audit and Provenance is the target audience (Security/Privacy vs Medical-Records); this is also recognized in the fact that the Audit is often only kept around for a few years. The Audit is only kept long enough to prove that the whole system is operating properly, that only authorized acts are happening.

There is some support for recording the reason the event happened. But they are both coded values to limit the potential unintended spilling of PII into the Audit log.

1. ParticipantObject.ParticipantObjectDataLifeCycle -- indicates the lifecycle that the object is now in.
2. Event.PurposeOfUse, (also being added through DICOM) -- indicate the purpose of use when the event happened.

Note that this use-case, deprecate without replacement, is explicitly troubling. The original design for XDS allowed only Replacement. In a Replacement transaction one can record in the new XDS entry why this entry is better than the old one. This transaction was intentionally  the only method, so that we always had a permanent  record of the deprecation. We even explained how to do a Replace with an empty document. The Metadata-Update supplement breaks this nice model, and thus leaves us with no way to record why the deprecation is happening. The XDS registry is the place where Provenance is recorded, the ATNA log is not permanent.

So it is important with ATNA to keep the log entry to as minimal information as possible, using coded values and identifiers (pointers) rather than textual descriptions. This keeps the risk that the audit log itself presents as minimal as possible, while still making the content useful for the Security and Privacy use-cases. As in those use-cases the codes and identifiers can be dereferenced, with authority and audit log entries.


Blog articles on Audit Control

How to set the ConfidentialityCode

I have been discussing the confidentialityCode, especially within the context of IHE-XD* (Document Sharing).  I was asked, by Keith, to give guidance on how the confidentialityCode should be set as without guidance he just tells everyone to use "N" (Normal confidentiality).

Some background articles:

• Healthcare Privacy and Security Classification System (HCS)
• Data Classification - a key vector enabling rich Security and Privacy controls
• and other articles on my topics page

Recommendation for setting confidentiatlityCode

So. I would continue to recommend that anyone or any-system publishing a CDA document should use "N", unless they have evidence to say that is the wrong value. Meaning it should be a specific effort to choose the other values:

• "R", because there is specifically sensitive content – HIV, alcohol/drug abuse, etc.
• "V", because the content should be seen only when reader is individually authorized -- psychology-notes, usually also used on all VIP patients (Not a best practice, but reality).
• "M", because the content is less sensitive than normal, but still medical. authorized for wide distribution – like an emergency-data-set, or for dietary use-cases
• "L", because the content is not medical, or has been de-identified
• "U", because the content is not specific to an individual and is public

This is right out of the definition of the vocabulary values 2.16.840.1.113883.5.25 for "_confidentiality". Available from the FHIR specification for easy reading. https://www.hl7.org/fhir/v3/Confidentiality/index.html

How to determine what the value should be?

I don't disagree that this is a hard thing to determine.

• It might be determined by workflow, psychology notes clearly are coming from a psychology workflow. 
• Clearly de-identification is a specific workflow. 
• It might be an explicit act, where the user is specifically trying to make a less-sensitive document for broad use such as a emergency-dataset, or 
• for export to the dietician. 
•  It might be a specific request, where the clinician decides that the data is very sensitive, or 
• where the patient decides that the data is very sensitive. 

This is different than a patient choice in consent regarding rules applied to these different codes, meaning where a patient chooses a restrictive consent for their data accessibility. See http://healthcaresecprivacy.blogspot.com/p/topics.html#Privacy

The VHA has shown some success in demonstration projects with passing the data through a CDS (Clinical Decision Support) to tag sensitive clinical concepts. See FHIR Demonstration of DS4P. If none are found then the data is "N", if some are found then the data is "R", if specific types are found the data is "V"… This automated method has me somewhat worried as the social norms of what is sensitive, change often. So using this automated form on publication time might produce wrong evaluation overtime. In the case of the VHA demonstration, they applied it upon 'use' of the data, so it was using the social norms rules at the time of reading. Likely better social norm rules, but not sure this is better behavior. Note that the intermediate step is tagged sensitivity category, which might be given to the access control system as information to be used in the access control decision or enforcement

Is there more?

All the other security-tags are not likely to be set upon publication. IHE has brought in the whole of  the "Healthcare Privacy/Security Classification System"

• IHE specifically recommends against using the sensitivity category, as the value itself is sensitive. They are useful for internal use, like the VHA demonstration.
• Compartment is mostly undefined, but would likely be a local value-set. Unlikely to be understood at publication time. Interesting place to play, as it might be used to define compartments like Radiology, Cardiology, Psychology, etc... but it is untested grounds.
• Integrity could be equally set by the publisher, although it is not well enough defined. But this would be a way to tag data that was generated by the patient, vs data generated by a licensed clinician.
• Handling caveats might be set on publication. The only cases I can think of are similar to the "V" cases, in that the author explicitly knows something about the data and thus needs to add a caveat.
• One specific example is 42CFR Part 2 – SAMSA covered treatment- that must be explicitly marked with a 'do not disclose without explicit authorization by the patient'. NOAUTH
• Second specific example is an obligation to delete after use, which specifically forbids persistence (including printing) DELAU

Conclusion

So, simple guidance. You need all of the _confidentiality vocabulary, and two more from the handling caveats. -- [U, L, M, N, V, R] + NOAUTH + DELAU  

Blog articles by Topic

• Patient Privacy Controls
• Access Control (including Consent Enforcement)
• Document Sharing Management (Health Information Exchange - HIE)