Early this week ONC released an Advanced Notice of Proposed Rulemaking on Metadata Standards to support Nationwide Health Information Exchange. ONC is seeking comments on metadata standards for patient identity, provenance and privacy.
My first question is (as it almost always is in these cases), “What are you trying to do?” Are we seeking standards for how the messages should look when exchanging information on the NwHIN? Are we seeking standards for what information should be exchanged? Are we looking to express functional requirements or technical requirements? Or, are we simply trying to say that “we addressed the recommendations” of the flawed PCAST report?
As written, the ANPRM appears to be trying to answer the last of these questions with a set of technical requirements on expression of data in XML, and it does so without considering any of the ramifications a selection would have on existing implementations.
In “The ABC’s of Standards-Related Activities in the US” (1987!), NIST classifies standards into 8 different types.
· Data Requirements
They also distinguish between standards for “design” (how it is implemented), vs. performance (what it much be capable of). We speak of the latter set of standards as functional today (such as the HL7 EHR Functional Model).
In this ANPRM, ONC has identified the need for a standard for metadata (because metadata is a good thing according to the PCAST report), without determining the type of standard to choose. What they’ve recommended is an interface design standard (HL7 CDA Release 2.0), instead of a functional data requirement standard. Because standards are good, and metadata is good, apparently we must have a standard for metadata. So, the ONC way seems to be to pick a likely standard, without first even answering the question of what it will be used for. I suppose I should be used to this by now.
Functionally, the choice proposed is very similar to the choice that IHE looked at more than five years ago for Cross Enterprise Document Exchange (IHE also looked at several others). What is different is that IHE looked at CDA as a source of functional requirements for Cross Enterprise Document exchange, where the current ANPRM looks at this as a representation specification for how information should be exchanged.
What are the ramifications for this choice?
If ONC truly wants to require the use of CDA Release 2.0 for information exchange (a move that I would support), it is quite possible to use it to exchange immunizations, laboratory reports, patient summaries, claims documentation, operative notes, patient instructions, et cetera. Doing so would be a challenge for many existing Health Information Exchanges, who are already using OTHER ONC selected standards for interoperable EHRs.
The existing standards support the same functional requirements on identity and provenance as CDA Release 2.0, but do not have the same XML structure. What are you going to say to all those HIEs with respect to implementation of the metadata standard? Will they need to change what they are doing today? What about all the systems using NwHIN Connect or Direct to talk to other systems? Why they support CDA Release 2.0, they can also exchange other content that doesn’t have the same XML format. Functionally those two systems do include the same metadata found in CDA (by virtue of the fact that they support the XDS metadata, which used CDA as its source of functional requirements).
I won’t even bother answering the questions right now that ONC asks about how easy it would be to do something with the CDA standard. Why? Because they cannot even be bothered to work with any of the at least 4 contractors who know CDA to generate technically accurate XML in Section II.B. Metadata Example. If you’re just going to make stuff up, why bother using standards to begin with?
After my vacation, I’ll take the time to correct the metadata example.
In summary, the current thinking is misguided and over-prescriptive. It needs to take into account what is already being done, and identify the appropriate kind of standards to select for Health Information Exchange. We don’t need an over-prescriptive standard to be selected to accomplish something in a way that is different from what more than two hundred organizations are already doing.
Back to my regularly scheduled vacation.