Untangling the Electronic Health Data Exchange

by David C. Kibbe MD, MBA

The purpose of this post is to help a non-technical audience untangle some of the confusion regarding health data exchange standards, and particularly come to a better understanding of the similarities and  differences between the Continuity of Care Record (CCR) standard and the CDA Continuity of Care Document (CCD). But what I’m most interested in is getting beyond the technical, political, or economic positions and interests of the proponents of any particular standard to arrive at some principles that demonstrate in plain language what we are trying to achieve by using such standards in the first place.

Frankly, I don’t give a hoot about what standardized XML format for capturing clinical data and information about a person becomes the norm in the health care industry over the next several years. I do care that the decision is made by the people, institutions, and companies who use the standards, and not made by a quasi-governmental panel or a group of “industry experts” whose economic or political interests are served by the outcome, and dominated by a particular standards development organization with whom they are very cozy. 

In other words, I do want free and open market forces to be able to operate freely and openly as health information exchange evolves, in part because I believe market forces will work in the direction of continuously improving health IT, whereas in my experience top-down efforts are often protective of established interests and discouraging to innovation.

Herein lies the problem, in my opinion, with the standards adoption process that the Office of the National Coordinator of HIT (ONC) and HITSP have overseen during the past four years.

It is the epitome of a top-down, large established player-controlled, and anti-competitive juggernaut in which a “one size fits all” paradigm has been promoted and lobbied for. In this case, HITSP has “selected” the CCD and not the CCR standard, despite the market forces that seem to be continuing the use of the CCR standard. This is simply stupid and likely will turn out to be futile.

I am one of the many volunteer co-developers of the Continuity of Care Record standard, which has been developed under the auspices of ASTM International, a not-for-profit organization that develops standards for many industries, including avionics, petroleum, and air and water quality. The CCR is sponsored by the American Academy of Family Physicians and numerous other physician groups.  I am also the 2008-2010 chair of the E31 Technical Committee on Healthcare Informatics, the leadership group within ASTM that is working with Google Health and many other individuals and organizations on the implementation and use of the CCR standard in this country and abroad. 

There are people who will claim that I am a partisan in a battle with a competing standards development organization, known as HL7, which has indeed developed a completely separate standard known as the Continuity of Care Document that utilizes the CCR standard. These folks will tell you that this is a classic competition between standards, a Sony versus Betamax situation, and that only one of these standards can survive in the current environment. Some would even like to use the giants Google and Microsoft to set the stage for such a competition.   

Honestly, I think that’s all baloney. It makes for good drama, but it doesn’t get close to the truth. I’m a family physician who was inadvertently and almost completely by chance drawn into the technical standards world over the past 5 years, and as a result of caring deeply about the value of software applications that physicians and their patients use to help manage clinical processes and make decisions about health and the treatment of disease.

The idea behind the CCR standard is very simple: if certain relevant health information — such as one’s diagnoses and conditions, medications, allergies, and past procedures — can be reliably and unambiguously tagged using XML (extensible markup language) within a single file, then this information can then be passed across communications networks where it can be read and understood by servers and software applications in a vendor-neutral manner. Software vendors who agree to share this set of computable health data about a person gain value in the same way that any network effective product or service gains value, e.g. telephone and faxes.

Users of these products then leverage that value to become better at communicating and sharing, which over time may lead to better clinical decisions, fewer and less costly medical errors, and greater efficiency as hands-off between providers involves less rework and duplication of effort.

The differences between the CCR standard and the CCD are quite easy to articulate and explain. The CCR standard is the simpler of the two, came first, and is in widening use. It consists of a header, a footer, and a body of health data organized into as many as 17 sections, e.g. problems and conditions, medications list, allergies list, family history, procedures, encounters, and so on. It uses a bit of XML technology, called a schema, to direct how the data are to be tagged using XML, and to enforce certain conventions such as time and date and the identification of coding systems used.

The CCR’s sections are optional, that is, a CCR xml file can be valid even if it includes just a header, a footer, and one section, say the medications list or lab results of a patient. Of course, the CCR standard can also allow for other sections to be added on as needed. Google’s CCR profile, for example, includes 8 sections,  which reflects an industry trend to be economical with the CCR xml file’s contents and keep things as simple as possible while momentum builds and experience of exchange is gained.

It is very important to understand that the CCR standard is intended to structure the data as much as possible. Short textual elements are allowed, but the purpose of structuring the data using XML tags and coding systems is to maximize the possibility that the CCR’s data elements can be both machine readable as well as human expressible. If there is a bias within the CCR standard community, it is for what Adam Bosworth calls “computability,” that is to say that the CCR standard is a way of structuring data, and not a way of moving documents that were previously paper. The CCR standard is not a discharge summary or an encounter/visit note. It is intended to be a “snap shot” of a person’s summary health information.

The CCD, or Continuity of Care Document, is more complex, is based upon the CCR standard schema in part, and has not yet been tested in the market. It is derived from and must be integrated with other HL7 standards; it is in fact a particular instance of a class of HL7 standards known as the Common Document Architecture or CDA. The formal designation for the CCD is the CDA CCD, and is described by HL7 officials as having several “levels” which refer to the extent to which the information in the CCD xml file is  merely textual, as in most health care documents, or structured, as in the CCR standard. A CDA CCD level two is a text document with no structured XML, and therefore no computability. A good example of this type of CDA CCD document can be seen at John Halamka’s web site entry of March 6, 2008, examination of the source code for which shows no structure more complex than an HTML table. 

A “level three” CDA CCD file will have structured XML included in it, in which case it could be used to exchange computable data machine-to-machine. The CDA CCD’s structured data component is supposed to be harmonized with the CCR’s xml, (see HITSP slide), but it’s not clear that full harmonization will ever materialize. At the time of this writing, the level three CDA CCD is not used by a single institution on a production basis according to a HIMSS Analytics Report called “EMR Adoption Model.” 

One of the nice things about the CDA CCD is that it can accommodate large blocks of text from provider institutions that want an XML package for portability of documents, but don’t have the capability of structuring data from their EMRs to create a CCR. Many large health care provider institutions are “document rich,” but “data poor,” and may want to approach computability in stages using the CDA CCD.

Anyone who managed to read my descriptions of the two standards above will likely come away thinking that they are really very different tools, and address the needs of quite different constituencies. And that would be correct. Both the CCR standard and the CDA CCD deserve to be tested in the market place of ideas and products, and both have their uses, advantages, and disadvantages. The CCR standard is proving very useful and agile for health data exchange where small amounts of data can be computed upon using web services, which Google Health beta is showing to be possible. The CDA CCD is proving useful as a means to gain portability of formerly paper documents and creates a glide path for increasing level of computability as the data become increasingly structured.

Which brings me to the finale of this post, namely, to state in plain language that interoperability can only be approached in incremental stages when so much health data and information exists in non-structured formats. The principle to uphold is the encouragement of any and all efforts to innovate in the direction of computability and interoperability, even if some of these appear less than perfect or even piece-meal. One size will not fit all uses or use-cases, and what is good for consumers’ PHRs may not be the same thing that works in a very large medical enterprises. Control over standards by large enterprises and/or their vendors is spurious, anti-competitive, and probably won’t be effective. The standards are supposed to make our lives simpler, not more complicated.