By David Kibbe
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.
Editor’s note: When republishing Kibbe’s post today, we accidentally deleted the great conversation going on in the comments section. If your comment was deleted, we encourage you to submit again.
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.
Categories: Uncategorized
A frequently visited museum of the city, Chandigarh was built by the Chandigarh administration in December 1997. The museum displays the beautiful interiors and lets the visitors explore the contemporary architectural designs. Featuring an array of sketches, models, plans, photos and documents, City Museum mirrors the evolution of the Chandigarh city and offers a live picture of the past world. The exhibits projected on the lower basement narrate stories about the partition of India and the journey of building a new world. The first floor exhibits offer a striking theme of “Chandigarh today and tomorrow” which has become a popular attraction among local and travelers alike. Government Museum & Art Gallery
Hi there, after reading this remarkable paragraph i am too glad to share my familiarity here with colleagues.
นี่คือของฉันบล็อก;รถแบคโฮ
Hello to all, the contents present at this web page are genuinely
amazing for people experience, well, keep up the
nice work fellows.
บล็อก::ราคามือถือ
I simply desired to say thanks all over again. I am not sure the things that I might have made to happen in the absence of these ways revealed by you on that problem. It was before a troublesome setting for me personally, nevertheless finding out this professional style you resolved the issue made me to leap over delight. I am just happy for this help and as well , have high hopes you are aware of a powerful job you have been accomplishing teaching the mediocre ones through your web blog. More than likely you havent come across any of us.
But the pact remained hung up on one key point: Karzai’s insistence that American servicemen accused of a crime be tried in Afghan courts. during services at a mosque 40 miles southeast of Kabul. The V8 models however have a different attitude, suspension,In either case albeit snugly. offering an impressive 53/46 mpg return in a super mini package. such as advanced multi-stage airbags, a Bang & Olufsen premium stereo system and a special lighting package. adaptive cruise control and Audi drive select.
Kevin,
I’m new to data exchange standards and am hitting the learning curve to get caught up, so I have absolutely no invested interest in either standard. The good thing about this blog is that:
1. It is very informative for a newcomer; and
2. Even without your comments, Kevin, it is quite obvious that Dr. Kibbe is writing from an extremely biased position. In fact, its this type of blind bias that inhibits collaboration that leads to movement forward.
In any case, thanks for your clarification.
Dr. Coonan,
Thanks for your well thought and comprehensive response to Dr. Kibbe’s diatribe. You certainly have more patience than I when dealing with this type of misleading hyperbole.
Tim
Member, openEHR Architecture Review Board
DK: Can you provide any comment regarding Kevin’s specific points, particularly regarding CDA/CCD? In looking over the JAMIA paper it seems he is accurate as far as CDA. There isn’t anything about the CCD in the paper.
Is CCR publicly available for review?
David, your comments concern me. I’m in agreement with Kevin in finding your motives and facts suspect. Without a standards development process in the United States we’ll have, well, lots and lots of standards. We need to agree to all get behind and support and improve the current ONC/HITSP process.
Dr. Kibbe,
I don’t quite understand how you think that your patronizing “rebuttal” could be taken seriously without any sort of meaningful comments. If I am in error, please point this out, rather than arrogantly dismissing them with some hand waving.
If you wish to be taken seriously and treated with some degree of professional respect, I would request you show some yourself.
My facts are drawn from the HL7 specifications, the SNOMED-CT documentation as well as from both IHE and HL7 implementation guides. I have provided ample PUBLICLY AVAILABLE links for yourself, and others, to review.
If you wish to provide any sort of useful comments, I would invite you to do so after review.
Kevin
Wow. Don’t know what to say. Your “facts” aren’t even close, but you do have a lot of emotion and religious fervor there, Kevin. DCK
War, what is it good for?
Dr. Kibbe has made a long history of bashing HL7 and anyone else he perceives as a detractor from what he sees as his CCR. Dr. Kibbe has again taken upon himself to employ the standard techniques of fear, uncertainty and doubt to engage in his ongoing and pointless character attack on HL7.
Few, if any, of the above statements are true and/or without hyperbole. I also think that Dr. Kibbe’s statement that he doesn’t “..give one hoot..” is far from genuine (esp. given his work w/ Adobe and others on a PDF ‘alternative’ to CDA). I also can’t take him at face value about his concern that he is primarily concerned that “…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..”
A lesson from the “Deciderer” play book
He clearly is advocating for something he created and damn’d be the facts; his mind is made up!
In hope of providing something of value to people who may read this: HL7 is not part of the “Axis of Evil” and is not spying on you
HL7 is an international non-profit volunteer organization comprised of “..people, institutions, and companies who use the standards..” The bulk of the work is done by a relatively small group of technical and clinical experts who have some sort of day job that lets them devote considerable effort to this endless task. People routinely are up before the crack of dawn or long after the kids are in bed on conference calls, editing implementation guides or working on the technical details. Most HL7 work is done by people who often have to beg their employer to let them have time to work on the standards, and often have to not only cover their own travel and phone costs, but also pay a hefty ($1K) registration fee so they can participate in the in-person workgroup meetings.
If anything, there is a notable lack of dominant vendors (although some do shoulder an unfair amount of the burden) involved, and a wider and more diverse group of vendors, institutions, patient representatives, or other volunteers is always welcome. If a particular group, agency or company is “cozy” with HL7 it is probably because they have been working their ass off as part of the HL7 process and just got to know each other after spending 12 hours in the same poorly vented conference room over the course of a week long work group meeting.
HL7 volunteers often work double extra overtime for HL7 to work with other groups like ASTM, ISO/CEN (including on the OpenEHR spec), IHE, the CDC/FDA/NIH, LOINC, SNOMED to try and harmonize. I hardly think any of us think of this as a battle–this apparently is not how Dr. Kibbe perceives things.
Lets be clear on this: There is no competition, conflict, war, battle, campaign between CCR and the HL7 CDA implementation of the CCR (the CCD) any more than there is between the forks and chop sticks in my silverware drawer. (Well, maybe late a night, when the dog is sleeping, and the moonlight is just right, they meet down at the school yard to fight over a dish named “Maria”.)
Of course HITSP has been “player controlled”. This is the case with any volunteer effort. One questions how many of the ONC/HITSP use cases Dr. Kibbe has contributed to, commented on, or participated in the follow up activities surrounding these? It is pretty easy to make vague and unsubstantiated derogatory remarks when you are not the one having to endure week after week of conference call, long lines at TSA, and soggy hotel room service French fries for supper.
Sure, it is a flawed process, but at least it is making progress where the lack of anything remotely resembling a healthcare SYSTEM in the US has left the US healthcare industry lagging behind the global power curve. Free and open market forces, which are not exactly evident in the US economy (at least not in the last 7 years), got the US healthcare sector INTO the mess and are not a solution. Anticompetitive government activity is the norm of the current reigning power in US executive branch, and is hardly within scope of any SDO’s sphere of influence. Nor does it matter.
Dr. Kibbe’s actual descriptions of the CDA (and CCD) are completely inaccurate. I would encourage interested parties to read one of the implementation guides or the review published by the lead authors of the CDA if they are interested in further details (or actual facts) about the CCD or CDA.
The purpose of the CDA is to provide a HUMAN READABLE electronic document which can be signed, transmitted, maintained, etc. This is a crucial notion, as the sad reality of most of electronic health information about a person is stored as narrative text (e.g. a physician’s dictated encounter). The CDA also provides for two additional levels (not “several”) of structure beyond just a block of narrative (i.e. not very computable) text for those implementations/uses where this is important. Level one is just human readable text, level two has some non-standard XML tags (and may contain variable levels of structured data), and level three (the level used in the CCD) is based upon a normative (balloted standard) information model, following very specific rules about XML tags, data types and controlled terminology use (i.e. it is not only structured but also encoded using a standard clinical vocabulary such as SNOMED-CT). This is not to prevent the use of structured data, but rather to also accommodate those cases where structured data isn’t available or needed.
The CCD uses these levels of structured data extensively and does so in a manner which is not only computable, but is also computable to a degree that it is useful.
There is a tremendous amount of organization and structure in the CCD that is not representable in the CCR. The CCR has made changed a good deal regarding the specification since the joint effort of ASTM/HL7 to create the CCD, and one can only hope it is due to the combined efforts and contributions of both organizations which has resulted in progress with both specifications.
Dr. Kibbe does not state the facts: The CCD is nearly all structured AND CODED data and is not a free text document. HL7 does have a set of emerging specifications for documents which traditionally have been paper bound (or at least in unstructured narrative formatted like it was only to be printed and read) which do allow all of the content to be in unstructured text. This is an urgent need of industry. It would be foolish, however, to come to any sort of conclusion about the CCD based upon completely different implementation guides.
OK, so lets look at a single example posted to the web and draw broad conclusions
As far as John Halamka’s CCD, you need to go to the right URL to find it (not to the URL that Dr. Kibbe provided). If you actually look at the content you can see it is not even remotely as Dr. Kibbe describes. It does have XHTML tables in it (it does make the data more easy to read on screen), but also has the data in a coded form. So while there is infact a table that says:
Weight (lb)172.4174.8169173
There is also a corresponding entry, which has a vital signs organizer with a component of an observation which says:
Now, I can find some fault with this specific non-normative example in that there is a good deal of information which should someday be coded to make this a better example . . .but it is pretty clear that this is structured data. When I have some time I will dig out my SNOMED-CT magic decoder ring and look up the codes for John.
I was not able to find a freely available description of the CCR which would allow me to post an example of how the CCR represents a weight. Sorry, I didn't feel like forking out the money to buy it from ASTM. The link that Dr. Kibbe provided was to a Wikipedia stub and wasn't of any help. If you want to review the standard, you can purchase it from ASTM's web site for $100. You do want to read the license agreement before purchase, however. The best I could come away with was from browsing Google's API The example showed:
Weight
363808001
SNOMED
150
lbs
As for the differences in SNOMED codes, that isn't too hard to explain why Google has a poor choice of code. The one used by HL7 is a more specific code for the actual weight, and Google is using a generic code for any sort of body weight measure (which also could mean a percentile, weight velocity, weight change from baseline, percentage of reference weight, your birth weight and a few other things) and NOT one specific to the actual value you expect. Hopefully, this is a simple error of ignorance on Google's API developers and doesn't represent a more profound lack of understanding of controlled clinical terminologies. It does appear that you do also have the option of including the date/time the value was recorded as well.
Obviosly, if you take a general purpose document structure and add this level of semantics to it, the resulting specification will be more complex than a simple set of XML tags. This is quite true and is of no practical consequence except that you can take away that the HL7 CCD is more highly structured than the ASTM CCR. This is important since any sort of computation done on the data within the document requires this degree of specificity to acomplish anything of interest. While Google may be using the CCR specification, it isn't actually doing much with the resultant data set besides storage/retrieval. If you want to do fun and exciting things like map data from multiple providers into an existing EHR application with accuracy, perform analysis of the data (including QA and billing) or use it for decision support the CCD goes a lot further to acomplishing this goal.
I have here in my hand a list of 205...:
Dr. Kibbe quotes a 2006 HIMSS Analytics Report, which doesn't even mention CCD, CDA or CCR, as evidence that nobody uses it. Phoey.
I hope that anyone reading Dr. Kibbe's "comparison" will come away, not as he states "..thinking that they are really very different tools, and address the needs of quite different constituencies.", but rather quite clear regarding Dr. Kibbe's total lack of understanding regarding the HL7/ASTM Continuity of Care Document (CCD) and his bizarre vendetta against HL7.