Friday, September 21, 2012

Advanced Access Controls to support sensitive health topics

I hope everyone who works on Privacy and Security in Health Information Exchanges felt the advance in the potential. What the VA and SAMHSA showed at the HL7 meeting was big. Not only was it big, but it was well done. Please review the News on this demonstration, the presentation given by Mike Davis, the Pilot specification, and the S&I Framework Data Segmentation for Privacy work. Pretty impressive stuff, right? YES it is. I am proud to be a part of  the S&I Framework overall Data Segmentation for Privacy workgroup.

This demonstration really showed the potential. However I think it highlights the potential without exposing the realities of demonstration. This is a demonstration that has not been evaluated from a Clinical Practice perspective. This demonstration modifies CDA documents without the Author knowing. This demonstration abuses some functionality of CDA. This demonstration abuses XDM metadata. This demonstration uses complex technology, leveraging highly advanced subject-matter-experts. This demonstration uses all greenfields technology. This demonstration is simply a demonstration, and when viewed in this light; this demonstration was fantastic.

I will describe the above concerns that  I have in a section below, but first I must describe my proposal. I have a proposal that does not need changes to standards, works with any document type including CDA, works with current technology, does not require high-technology on the receiver side, and gets the same job done.

Easier Way: 
There is an easier way. One that does not require any changes to standards, although I will admit that it is less elegant and more blunt. The use-case space we are trying to solve is that many HIE simply recommend against sharing sensitive topics. Thus for a population with sensitive health topics their data is excluded from HIE, and possibly the normal information that is tightly coupled with the sensitive information. I have proposed a more blunt solution, one that IHE built into the XDS metadata, yet one that has been rejected by some in the S&I Framework and ONC leadership. My proposal is somewhat represented by section 3.5 in the S&I Framework specification (4 pages of text).

My solution is to have the original CDA document in full form, mark this as “Restricted”. Then create a Transform of the CDA document that has the sensitive data removed, mark this as “Normal”; and use the Metadata ‘association’ relationship to indicate that this is a “Transform”. In the case where the documents are managed in something like XDS, this is all registered this way. Being registered does not mean it is accessible, Retrieval utilizes the metadata to control access. In the case of a PUSH using XDR or XDM (Direct); one would choose to put in both forms if the recipient has the authority for both, or just put in the normal if the recipient has only the authority for normal data (clearly don’t send it if the recipient has no authority). In both the PUSH and PULL case this is a simple Access Control rule applied to well established Metadata.

I would encourage the use of Clinical Decision Support (CDS) that the demonstration used to detect sensitive topics. This detection of sensitive topics is NOT something that security experts are good at. So I would still suggest that a tool like this can be used to flag the Author with the need to create a transform only when it is needed with suggested transform. The method of using CDS to detect the presence and XSLT to transform the CDA is a fantastic idea. I just want the Author of the document to agree that it still is a worthwhile document that they want their name on. The main difference is that I just want the sensitive data removed, whereas the VA Demo used an extension to apply tags at the element level removing some sensitive data and leaving other sensitive data in the document.

In my solution using the CDA document requires no new technology, it is just a CDA document. It doesn't have extended metadata or element tagging that would not be understood by current technology. A system that is allowed to get both Restricted and Normal data; should be careful to import the data marked Normal first as it doesn’t come with Restrictions. Then inspect the Restricted document and if necessary import anything new found AND track the restrictions.

This solution works with ANY document. Including a document that uses FHIR encoding, or Green-CDA encoding, or CCR, or PDF, or DICOM-SR, or anything else. I like CDA, but if the only solution we have forces CDA, then we are cutting off documents from the past and cutting off new document types in the future.

None of this requires new standards or abuse of standards. YET it results in the same functionality on the use-case need. This solution put up against the one demonstrated by the VA/SAMSHA makes their demo look like a Rube Goldberg machine.

Yes, the solution requires that within the USA there needs to be a definition of 'why would you mark a document Restricted', and 'who has legitimate access to documents marked Restricted', and 'what are the receiver behaviors required when using Restricted documents'. All things that must be done no matter what technology we use.

Demonstration Dirty Details: 
I don’t want to sound like the demonstration was a complete farce. IT WAS GREAT. I only want to point out that there are some details that are important to recognize and that the solution is not close at hand and easy to implement.

I already pointed out above the CDA entry level tagging, which would not be understood by current systems. It would also not be possible to get some systems to understand it. Further the topic was brought up with HL7 Structured Documents Workgroup (owners of CDA), and they indicated that there might be a better way to do it. They needed more time to think it through. Yes, making a mistake on a technology like CDA can mean long-term problems. CDA are documents, intended to be used over the life of the patient; They are not messages that are transitory.

I also addressed the need to present the transform to the Author. It is very possible that the transform is of no clinical value. More important is that a CDA document is ‘Authored’. It is a legal representation by the Author. This is not true if the Author never sees the content with their name on it. Keith has covered this far better than I have in Data Classification, Redaction and Clinical Documentation

My biggest concern is the abuse of XDM metadata. These additions are allowed by the specification, but they are expected to be processed without fail by the recipient. This is not acceptable to extend a specification and expect compliance. Extensions are allowed by many standards, but extensions behavior are not forced upon the recipient. I don’t disagree with the need to convey the Obligations; I just want a reasoned and standards based solution. This is an important advancement, we need to do it the right way. Not force a hack upon the world.

Lastly they did magic using very talented subject-matter-experts using greenfields technology. It is important to recognize the non-trivial work necessary to build this functionality into a real-workflow with real-users and sensitive to patient safety.

Conclusion:
I have been involved in standards development for a very long time, I know that it takes many years for a reasoned solution to be fully ‘standardized’. This period does not mean no-one is using that method, indeed pilots and implementations are important to proving viability. Then there is the typical 5 years it takes the market to pick up and use the standard. Thus 7+ years is not unusual. I would rather see my Easier Way used today, than continue to simply forbid sensitive topics from entering a Health Information Exchange.

So, why was my solution not part of a Pilot? Because it is already available, and thus doesn't need to be tested. I have been involved in the development and deployment of HIE technology. I know of multiple exchanges that were working on Policy solutions that would have enabled sensitive topics. For example Connecticut. These HIE solutions were put on mothballs as ONC has forced everyone to implement Direct first. I know of multiple states where progress was put on hold. I like Direct for what it was intended to solve, but I hate what the ONC mandates on Direct have done for HIE progress. It has not been a net positive.

The Easier Way can be used with Direct TODAY, and XDS, and NwHIN-Exchange. My solution does not require any changes to Standards. My solution works with any document type, not just CDA (e.g. Green-CDA, FHIR, DICOM). I ask that the Future-Nirvana not get in the way of the Good.

UPDATE:

I just remembered that the Easier Way has been demonstrated multiple years at HIMSS. The scenario is fully explained in this article on the HIMSS 2008 Privacy and Security Use-case. This is what inspired the HIE like Connecticut to put this into their infrastructure.

See also:

1 comment:

  1. John your blog begs a response, and since I was the individual who personally provided you with a walk-thru of the demonstration, and a core member of the development team, I think the burden is on me.

    Before I get started let me just say that my response in no way reflects the opinion public or otherwise of any other organization or individuals who participated in the ONC Data Segmentation for Privacy Pilot demonstration.

    --“Rube Goldberg” and “GreenField Technology”--
    I completely disagree here. For your readers the demonstration including a mix of robust, mature, standards based, and broadly implemented systems. These systems and/or services are commercially available, federally developed, or freely available open source components.

    The following systems were part of the demonstration;

    Open Source Behavioral Health Information Technology Architecture (OBHITA) REM system a Meaningful Use 1 Certified Electronic Health Record (Federally Developed)

    National Library of Medicines (NLM)/National Institutes of Health (NIH) Unified Medical Language System (UMLS) – Terminology Services (Federally Developed Web Services)

    Jericho Systems Enterspace Decisioning Service (Commercially Available)

    HIPAAT Patient Consent Management (Commercially Available)

    Mitre Kairon Consents (Open Source Project)
    JBoss Drools 5.x Rules Engine (Community Edition)

    --“Abuse of XDM”--
    Extending the XDM metadata is not abusive, allowed in the specification, and frankly intuitively obvious. Including document handling instructions (obligations), refrain policies, and other information necessary to ensure that patients authorization restrictions are met will REQUIRE that the receiving organization understands how to consume and process these instructions. However, this requirement is mitigated, by 1) layering these capabilities on top of existing implementations as we have demonstrated, and 2) providing implementers with a reference implementation for further development, and inclusion into their core systems. Our team is currently working to release the artifacts of the demonstration by early October. This way the American public benefits from the work done by, as you put it, a group of “very talented subject-matter-experts using greenfields technology”.


    Additionally, our approach, adding additional slots to ExtrinsicObject is no different than what was implemented for DoD in their NwHIN/VLER 1a production release when MHS wished to capture data provenance, and track whether or not the retrieved document was viewed by the requestor prior to assimilating it into their authoritative XDS.b repository. Interestingly, isn’t data provenance a concern of DS4P?

    --Demonstration Dirty Secrets—
    “Complete Farce”, this is an offensive statement John, and serves no one but you. Granted, tagging of the clinical observation via an external reference is less than optimal, and frankly the CDA standard needs much work in this area, our hopes are that the proposed Healthcare Classification System (HCS) addresses our concerns, by providing security labels that define Confidentiality, Sensitivity, data Intregrity, etc, as described in ISO 10183-3, and NIST FIPS PUB 188. The graphic you have included on this blog is outdated. The actual reference is a uuid that relates back to the originating authorization event.

    --“Conclusion”—
    It’s not as hard as John says it is! As the co-author of 3 ratified Oasis standards on Privacy and Security for Healthcare, and directly or indirectly(reference implementation) having my hands on production NwHIN Connect Policy Engine deployments supporting organizations nearing 20 million members this year alone, including integration with GE Epic system. Maybe there is an “Easier Way”.

    The reality is that there is still much work to be done in this area, and many battles still need to be fought for the patient. I would invite John to bring what he has so we can collaboratively compare and contrast what has been accomplished thus far.

    Duane DeCouteau

    ReplyDelete