JASON Report Part II was released at the end of November, titled Data for Individual Health
. The report aims to examine how to create a health information system that focuses on the health of individuals. The report focuses heavily on the critical need for the adoption of open APIs to foster interoperability. Claims are made in the report that the health data infrastructure does not have the capability to make the data accessible in a usable form or to represent it in an atomic format.
The ONC has spent considerable time and money trying to foster interoperability through Meaningful Use the past several years. Putting the infrastructure in place to support CCD and CCR was the main focus of interoperability for Stage 1. Then Stage 2 introduced Consolidated CDA along with the Direct Project, which was touted to be a secure and simple protocol that would be easy to implement. So what does the JASON Report have to say about CDA and the efforts made towards interoperability so far?
The report indicated that as a document standard that CDA did possess some “desirable characteristics.” There are three areas of the CDA approach that received positive comments in the report:
This is where the compliments end, which is not exactly a glowing endorsement of CDA.
- The CDA Header, one of the six key characteristics of a CDA document as defined by HL7, sets context for the entire document.
- The human readability component of CDA was viewed as a positive feature. Human readability is also one of the six key characteristics of a CDA document.
- Level 3 Semantic Interoperability. CDA documents which apply Level 3 Semantic Interoperability with full coding of the entries were seen as “a good example of an open standard that can be further evolved.”
The chief complaint with CDA is that it is “really only a container for the information.” The report focuses in the importance of having open standards which embrace the concept of atomic data. While the report concedes that XML will allow for the parsing of the data to be used in an atomic way, they comment that disaggregating the data in this way “is made quite difficult.”
The report does not go into details as to why the parsing of the data has been so difficult, but there have been obvious difficulties for each stage of Meaningful Use:
Meaningful Use Stage 1. The requirements for Meaningful Use Stage 1 called for the infrastructure to be in place to send a CCD or CCR document. In a previous blog, I discussed how vendors would chose to test with CCR instead of CCD because it was simpler. The CCD of Meaningful Use Stage 1, the C32 version, had multiple sources of truth requiring anyone who wanted to understand the standard to go to multiple implementation guides. This did not make it easy to embrace the standard.
Meaningful Use Stage 2. The requirements for Meaningful Use Stage 2 called for the use of C-CDA. The C-CDA standard aimed to solve the multiple sources of truth by combining the standards of nine different common document types into one C-CDA implementation guide. One of those nine document types was CCD. But, curiously, the ONC chose to utilize none of those nine document types, but rather four additional document types. These document types are structured using the C-CDA standard, but are not one of the included nine defined types. Needless to say, this adds to the difficulty of disaggregating the data as pointed out in the JASON report.
If CDA is not an adequate standard for leading the industry to utilize atomic data, then what would be better? The report spends many more pages talking about the possibilities than they do rehashing what went wrong in the past. After the discussion of CDA the report analyzes the emerging HL7 FHIR standard, and details how REST and FHIR could become the foundation for the future of the health IT system. Look for future blogs that focus on FHIR. I look forward to your comments below [ click here to view / comment ]
By Rob Brull | Retrieved from hl7standards.com
January 8, 2015