HL7 Data Segmentation for Privacy

That which the S&I Framework - Data Segmentation for Privacy (DS4P) created, now is being balloted in HL7. This is a win for those that have seen previous HHS/ONC projects create something only to see it die due to lack of funding, interest, or new administration (e.g. HITSP). This is an example of a project that S&I Framework took too the limit of what it could do. It wrote the Implementation Guide, and ran multiple pilot projects. So, now the work is brought to HL7. Where, in the words of Wes Rishel, "Change the consensus group, change the consensus.". This new consensus has not changed much, but it has changed somethings I think are critical. I also will be looking closely at the ballot for more things that could be changed.

Much of the new consensus is to harmonize with other works in progress. Such as the efforts I am driving to define a RESTful equivalent to XDR and XDS with Mobile access to Health Documents (MHD), and updates to the definition of IHE ITI Technical Framework Metadata.

In the ballot are three things. First, a CDA specification that shows how to identify different segmentation within a CDA document, Second, a specification for XDM metadata for use with Direct, Third, a specification for XDR. Yes, this third part is XDR, but it is called XDS-Metadata-Content-Profile because the current IHE Technical Framework Volume 3 section 4.0 is called "XDS Metadata". This is about to change, as IHE is publishing new Technical Framework and Volume 3 section 4.0 is now written more broadly to include XDS, XDR, XDM, XCA, and be ready to for others like MHD.

HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1
Chapter 1: CDA R2 and Privacy Metadata Content Profile

• HL7_IG_DS4P_R1_CH1_CONTENT_N1_2013SEP.pdf

Chapter 2: NwHIN Direct XDM Metadata Content Profile

• HL7_IG_DS4P_R1_CH2_DIRECT_N1_2013SEP.pdf

Chapter 3: NwHIN SOAP/Exchange XDS Metadata Content Profile

• HL7_IG_DS4P_R1_CH3_EXCHANGE_N1_2013SEP.pdf

Sample Files
CDA R2 and Privacy Metadata Content Profile

• SegmentedDocumentContentProfileSample.xml

Chapter 2: NwHIN Direct XDM Metadata Content Profile

• SampleXDMetadata.xml

Digital Signature standards use and evolution

I am excited about a S&I Framework project. Excited at the prospect that finally Digital Signatures will see the light of day. Yet, I am also troubled by the overly technical focus of the maximal solution.

The Electronic Submission of Medical Documents (esMD) project is a very good case for the use of Digital Signatures. There is a high-value asset, and high-value to false submissions. Meaning having a mechanism that can prove non-repudiation would have a big benefit. Unfortunately, there is a downside on the workflow by the Provider. This downside is that even the GOOD Providers (which we must presume is a much larger number than the bad ones) will need to carry out extra steps when documenting. 

Their First Level of solution is not so onerous It recognizes that the act of submitting the document could be enhanced to include a Digital Signature on that bundle of Medical Documents. This use-case is well handled by the IHE- Digital Signature Profile (DSG). You can see the S&I Framework reportout slide that was used when presenting this to the HIT Standards Privacy and Security workgroup and Exchange Power Team.

The signature would still need to be by the Authoring Doctor and Legal Authenticator. The technology and workflow are just different. The IHE-DSG profile also can be used to sign any format of document, so if the Doctor has documents in PDF, DICOM, or any other format; these can be signed by IHE-DSG. The IHE-DSG profile creates a NEW document that is the signature itself. This document lists each of the documents it is signing with the cryptographic hash of that document. Thus the original document is totally unaffected.

The drawback, as described by esMD leadership, is that the signature can become lost. That is that as the document is moved around, someone might carelessly not continue to carry around the Digital Signature.

This is why they have also prototype d a Digital Signature that is carried within the CDA document that it is signing. This is done through the magic of XML, and is supported by CDA and XML-Signature. There is just some important syntactic sugar that is needed to make sure everyone does it the same way. This is now being written into a standard by the Structured Documents workgroup. This CDA Digital Signature standard will be coming out for Ballot soon.

There are well known issues with the use of Partial Signatures, even when using XML-Signature. These issues need careful attention. Further, I am unconvinced that that same careless individual that in Level 1 failed to carry along the digital signature, might not also carelessly not carry along this digital signature. Being XML, it is easy to extract and re-create. This should not be done with CDA anyway, as it does break the theory of wholeness. But we are talking about careless people.

Signature: Digital-Signature, Electronic-Signature

• IHE - Privacy and Security Profiles - Document Digital Signature
• Signing CDA Documents
• Using both Document Encryption and Document Signature
• Non-Repudiation is a very old art

Time to kindle the FHIR - It needs ballot comments to grow

HL7 has released FHIR to ballot. This is the very first DSTU ballot, with the expectation that there will surely need to be at least one more DSTU ballot followed by many cycles of maturity before going Normative in 2016.  It is thus time for everyone that likes RESTful to speak up. Now is the time for those that insist that all others are not as good as RESTful to prove it through providing constructive input. It is also time for those that are not RESTful advocates to also provide constructive input. Constructive comments that are persuasive are what is important.

UPDATED 8/14/2013 8:00pm: I got a comment from Lloyd McKenzie, (Chairman of the FHIR Management Group) on the dates. "The DSTU will be published in early 2014.  I wouldn't expect a normative version of FHIR until at least 2016.  We need significant depth and breadth of implementation before we start locking things down."

The first HL7 FHIR DSTU ballot opened on Aug 12, 2013. The ballot signup close date is Sep 09, 2013 and the ballot close on Sep 16, 2013. The list of resources that are contained in the ballot is found at http://www.hl7.org/implement/standards/fhir/resourcelist.htm

This ballot contains some resources that come from IHE. I worked hard over the past year to get these into the FHIR specification. I brought MHD to the attention of the FHIR developers as an example of where the industry needed simple access to healthcare documents. I give Grahame all the credit for getting it done.

• DocumentResource -- the document sharing model from XDS, XDR, XCA, XDM, MHD 
• SecurityEvent -- the Audit Logging component of IHE-ATNA

There is also recognition in FHIR of the use of IHE profiles.

• Security layer -- use of the IUA profile

Mobile access to Health Documents (MHD)

The DocumentResource will be brought back to IHE once it becomes a stable DSTU. I and IHE hope that we can use the FHIR standard in the next revision of MHD, because it really hits the mark. This is likely to be this winter or coming spring. At that time the Volume 2 part of Mobile Health Documents (MHD) will be replaced with the appropriate content describing  a profile of DocumentResource to meet the needs of MHD and the family of Document Sharing in XDS, XDR, and XCA.

Security/Privacy Audit Trail (ATNA)

The SecurityEvent is a RESTful implementation of the audit logging schema that IHE-ATNA uses. This schema has been slightly changed to meet the goals of FHIR, but is intended to be fully compatible. The future is not as clear with this resource, but I know there is interest in the community. First there is interest in having an HTTP mechanism to submit a new audit log event, rather than using SYSLOG which is required in IHE-ATNA. Second there is interest in having a standardized interface to support Audit Log Reporting and Alerting use-cases. Thus there might be an IHE  profile proposal in the future that uses the SecurityEvent resource.

Please Review and Comment on the HL7 FHIR Ballot

It is very important that everyone take a look at the FHIR Ballot. Those that want this to succeed as well as those that don't think it will work. It is only with everyone participating that we get a good solid specification. I think that there is certainly a place for RESTful to be used. I can see potential for IHE to utilize FHIR quite a bit in the coming years. I however don't think that RESTful is the solution to all needs (Web-Services RESTful vs SOAP).

mHealth

• getting to mHealth solutions - real People
• getting to mHealth solutions - Users
• Security Considerations: Healthcare RESTful Resource specifications
• Privacy and Security in Designing an mHealth Application
• mHealth Solution
• Security Considerations: Healthcare RESTful Resource specifications
• IHE efforts in RESTful security
• IHE mHealth Hackathon
• The Magic of FHIR – The HL7 movement toward REST resources, away from v3 and v2 
• IHE Mobile access to Health Documents - Trial Implementation