HIT Standards - PCAST analysis against Standards

I missed the HIT Standards committee meeting last week, but when I looked at the presentations and the minutes I was EXCITED. They took my advice, well they have done what I really wanted them to do. They extracted the PCAST principles and evaluated the current standards against them. Well, they contracted out to Mitre, who did a really good job.

However I do have some corrections or additional insight that I would like to provide the committee members, Mitre, and my blog readers.

Page 4: I really hope that when they say "Bias towards false negatives", they really mean "Bias AWAY FROM false negatives". A false negative will result in an inappropriate disclosure. It is true that the user should notice when they are working with the wrong patient, but not all use-cases have a user interact with whole documents. I would hope that the Doctor never needs to 'browse', but rather has the data gathered, collated and analyzed for her.

I know that we have an aversion to creating federal patient identities. I think this is misguided. I want to see real discussion on the reasons for and against. One thing that we MUST do is make sure that what ever identity that is given is simply an identity. These identities should be PUBLIC. If they are designed to be public, then we will not improperly use them as a secret. If we had this, we would NOT NEED to have all that other demographics such as Address, Phone Numbers, Zip Code...

Page 5: And I would suggest that although the IHE XDS Metadata contains the values that Mitre considered critical Patient Matching; that the more important thing is that IHE has the service interfaces for Lookup (PDQ), Cross-Reference (PIX), Updating (PAM), and Community Discovery (XCPD). The other alternatives don't have these service interfaces.

Page 6 & 7: Provenance is nicely introduced although the conclusion "Start with shallow provenance, increase over time" is a great conclusion, there is so much that is not said by this statement. Provenance is a very tough topic especially when there are so many different documents to cover, this is why IHE duplicates some of the provenance aspects found in CDA and puts them into the XDS metadata (including XDM, XDR, and XCA). What this does is allow for some level of provenance to be maintained in the XDS Metadata even when the document is a simple text document, PDF, or other.

So I would say that the assessment for both XDS as well as CDA on Chain-Of-Custody are wrong. For XDS it is simplistic, but CDA includes the recording of the custodian of the original electronic document (the originator of the information), as well as the source of it (through the informant participation), and if you wanted to go further, you could.  The exact way to do it simply isn’t specified, mostly because nobody have ever had a convincing use case for it.

Each CDA document is documentation of a specific encounter, by including both author and informant, it allows the chain of custody of information to be discovered.  Information going into the record does so only after a healthcare provider makes a clinical judgment that the information is both accurate and relevant (needs to be recorded).  It actually becomes a new piece of information:  Provider X (the author) thinks that this Act should be documented as part of the encounter.  The information may have been in fact received from multiple sources (other providers, the patient, a family member, a lab result, et cetera).  What is the chain of custody for a diagnosis and how is it intended to be used?  Is it to discover the source of errors in transmission of information?  Is it to deal with redisclosures?  These are interesting issues to discuss.  I don’t necessarily accept it as a requirement in the communication, but I can accept a requirement that it be discoverable.

In CDA, if you want to record credentials associated with an Information Recipient in CDA, you can certainly do so.  The element contains which allows any number of license identifiers to be recorded, including NPI, state license identifier, DEA number, et cetera.

And to add cryptographic assurances one simply Digitally Signs each document using the IHE DSG profile. 

Slide 8: We then get to Consent, I like their diagram  where we see that there is "Data Elements with Content Metadata". What is not shown and gets confused is that this Metadata in this case includes a set of metadata that would enable the "Policy: Assembled from Modular Components" to act upon. That is that it is the Metadata tags on the Clinical data that is used by the Policy. There is also conflating of the security/privacy context of a request to access the clinical data, which is the domain of the security context. Thus there are three concepts that need to be analyzed against existing standards.  

Slide 9: They do actually show the three concepts, they just lump them against one standard. The items they have identified as "Request Metadata" are the characteristics of the User Context that are provided by system requesting access to some clinical information. This information is is NOT included in BPPC, but is FULLY included in XUA. 

Then then include the "Content Metadata", which I will agree is NOT covered by BPPC, because this is metadata on all the OTHER documents, so it belongs to those documents. The Content:Datatype, and Content:Sensitivity are fully supported by the XDS metadata; thus are fully available regardless of the document type or transport type (XDS, XCA, XDM, XDR). Further these two metadata values are common in DICOM transports and available for HL7 transports; ALL with common vocabulary. The third value "Content:Coverage" is something that is very much not the domain of clinical documents, although I do agree that CDA covers it. 

The last value is the domain of Consent (and authorization), actually there is far more that should be listed here including Duration of the Consent (needed by many states), Organizations that are a party to the consent (needed for authorizations too), Digital Signature of the Consent, ability to capture the signing ceremony. These are covered by BPPC, even if complex consent rules are not covered.

Conclusion:

I am very excited that this work was done, and I applaud the great work of the Mitre team. I challenge them to take this information and enhance the work. Especially on the Consent portion. I realize that higher-executives want you to speak of these as one thing, but they need to understand the separation of these will create a more powerful solution, and does not diminish the analysis. The last observation it seems while looking across all the solutions analyzed that there is a tendency to say "N" when the standard does not mandate the capability. It is unusual for a standard to mandate something, what should be assessed is if the standard supports through specifying the mechanism. Mandates are the domain of Policy, not Technology.

So, Please look at:

• PUSH HIE: XDM, XDR, ATNA
• Regional HIE: XDS, PDQ, PIX, PAM, XUA, ATNA, BPPC
• Nationwide Federation of HIN: XCA, XCPD, XUA, ATNA, BPPC.

There are others that can be used including DSG, XDS-SD, SVS, etc...