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.

5 thoughts on “Untangling the Electronic Health Data Exchange

  1. Although I am in the same camp as Dr. Kibbe and Vince, I believe both are ignoring the fact that in almost all business endeavors the eventual winners are not the ones with the best product; it is usually those with the best marketing, distribution, and power relationships to make implementation work.

    It took me 20 years as a clinician, and 15 years as a physician executive to learn this lesson. For example: It is the hospital administration and/or the managed care industry (who can devote 40 hours a week, $$$$, people and time to their efforts) pushing their agendas that will win over an unorganized provider community (that meets only before or after office hours). For any significant project, these are the “industry experts” and this is their business and they will devote the planning and resources to get their way. Normally, end users don’t have this level of committment. It is how the world works. Welcome to business.

    Dr. Rearick

  2. Dear Dave: Thanks for your comments. Yes, I agree that many times the best product doesn’t win the race. The best standard doesn’t get implemented.
    But I don’t think that’s happening here, in part because both the CCR standard and the CCD use the content and tagging of the CCR standard. Perhaps HL7 will eventually control the standard, because they have the money and the power. But I still think that market forces will dominate the technical issues, particularly now that Google, Microsoft, and other consumer brands are in play. DCK

  3. David:

    I like your analysis of current standard. Nevertheless, USC’s MMM program taught us the same theory “the best marketing, distribution, and power relationships to make implementation work.” I believe Healthvault is showing this through their recent conference in Washington.

    I may be wrong, but I thought HL7 v2.4 has been used by 94% US IT. V3.0 is more popular now in Europe and gaining popularity in US. HealthVault adopts all standards (XML, HL7, CCR, CCD, etc).

    If Google Health mainly adopts CCR, are they behind? Next, does Google Heatlh allow bilateral interface (I believe they do with Medem)? Some said not.

    Afterall, I believe the trust is leaning toward Microsoft at this time, supporting by their privacy policy when compared to Google Health’s privacy policy.

    Best Regards,

  4. David, thanks for your thoughtful analysis of this issue.

    This is a great example of the issues that we face with healthcare data transmission and storage standards.

    I heartily agree that I couldn’t care less which standard is adopted as long as one is adopted for each use case.

    Until we work together to bridge the gap between these standards and many other standards, the benefits of electronic medical records and other software systems will be handicapped.

    Even the “worst” standard for each use case winning would benefit the greater good, as it would save a tremendous amount of money and effort. This money and effort could be used to create software and services to help people live longer and healthier lives.

  5. This is likely not THAT important, and basically supports the good works of the author.
    1) if you really don’t want top down and want PERSONAL health records, make it able to be made by the patient and privately held.
    2) make it in HTML. If it is in HTML, then the different sections can be demarcated with and written by anyone and read by anyone. If it is held by the patient confidentiality is moot. If it is from the patient it is a primary source.
    3) Neither 1 NOR 2 are incompatible with the author’s views.

Comments are closed.