Subscribe if you want to be notified of new blog posts. You will receive an email confirming your subscription.

Please enter your name.
Please enter a valid email address.

Please check the captcha to verify you are not a robot.

Something went wrong. Please check your entries and try again.

CCHIT Should Support BOTH the HL7 CCD and the ASTM CCR for PHRs.

The federal government sponsored Certification Commission for Healthcare Information Technology (CCHIT ) is undertaking a certification process for personal health records (PHRs) . The CCHIT PHR Work Group has invited public comment on the First Draft of the PHR Certification Criteria .

The current draft of the PHR Certification Criteria specifies use of the HL7 Continuity of Care Document (CCD) as the only endorsed standard for interoperable exchange of information to and from PHRs.  This is extremely short-sighted.

I wrote a comment to the PHR Work Group explaining why it’s important to adopt BOTH the HL7 CCD and the ASTM Continuity of Care Record (CCR) .  I suspect most professionals commenting on these criteria will be looking through the lenses of health information technology, so I thought it would be important to share a different view — one through the lenses of business strategy and public policy.  Here’s my commentary:


Dear Members of the CCHIT Personal Health Record Work Group:

CCHIT should recognize both the HL7 CCD and the ASTM CCR as interoperability standards for PHRs.  Some perceive the CCR and CCD as competitive; in application, they are turning out to be highly complementary.

Both CCD and CCR Are Gaining Traction in the PHR Marketplace

Chilmark Research reports equal use of the CCD and CCR standards in PHRs, with both having about 60% adoption (some PHRs use both standards).

CCRCCD

Microsoft HealthVault is supporting both the CCD and CCR standards.  Sean Nolan , Chief Architect and General Manager, Health Solutions Group at Microsoft informs me that they are seeing about 50/50 adoption of the CCD and CCR standards.

Google Health has voiced support for both standards, but currently only accepts a subset of the CCR.

CCD and CCR are Complementary Standards

Both the CCD and CCR are recognized formal standards; the CCD is recognized by Health Level 7 (HL7) and the CCR is recognized by ASTM International .

However, the CCD and CCR are suited to become de facto standards in different environments — implemented by different types of organizations and used in different applications.

The CCD standard is more likely to be used:

  • By organizations that have already adopted HL7 (e.g., large delivery systems)
  • To support existing business models
  • In non-disruptive applications that achieve costs savings and/or quality improvements by automating EXISTING processes that are INTERNAL TO THE ORGANIZATION (or with existing trading partners), e.g., hospitals sending test result information to doctors.
  • Where implementers have already incurred significant fixed costs to adopt HL7 as a broader enterprise standard

The CCR standard is more likely to be used:

  • By organizations that have not yet adopted any standard (e.g., early stage companies)
  • To support new business models
  • In disruptive applications that achieve costs savings and/or quality improvements by creating NEW PROCESSES, often involving parties that are not currently exchanging information, e.g., improving patient chronic care management with the goal of avoiding ER visits and hospitalizations.
  • Where the implementers are highly sensitive to incremental costs of IT resources and view the CCR as a “better, faster, cheaper” alternative.

Public Policy Implications

What are public policy implications?

  • To the extent that CCHIT wants to encourage innovation and to facilitate maximum data interoperability and liquidity, it should support BOTH the CCD and CCR.
  • To the extent that CCHIT wants to protect interests of incumbent health care organizations, it should support only the CCD.

The market is speaking…please listen.


Vince Kuraitis
Principal, Better Health Technologies, LLC
Member, ASTM CCR Steering Committee


This work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License. Feel free to republish this post with attribution.

17 Comments

  1. Ted Eytan, MD on October 27, 2008 at 9:52 am

    …and the CCHIT PHR Workgroup is listening. Thank you for the comment and I encourage as many people with expertise in this area to comment publicly. Thank you for your interest, Vince!



  2. Vince Kuraitis on October 27, 2008 at 6:06 pm

    Ted,

    I really appreciate your taking time to read my commentary and to respond. THANK YOU!

    Vince



  3. Nathan Low on October 30, 2008 at 4:56 am

    Great post! It’s certainly true that most healthcare companies that don’t have a PHR for their patients are more likely to use CCR. The company I work for in Boston is using it, mostly because the PCP offices we and SNFs we are partnered with use CCRs, so it’ll be a great idea to support both.



  4. Jonathan C. Puskas on October 30, 2008 at 6:08 pm

    Vince,
    In a perfect World, both would be an acceptable (and recommended) path.

    However, we often need to prioritize. How would you prioritize between these two standards if you had to choose? Who do you fancy will be the driver (incumbents with internal process improvements or new players driving innovative new solutions)?

    Best regards,
    Puskas



  5. Vince Kuraitis on October 31, 2008 at 11:32 am

    Jonathan,

    I’m not aware of many incumbents yet using the CCD standard since the state of evolution and readiness is very early. For an example, see John Halamka’s writings about the CCD at http://geekdoctor.blogspot.com/search?q=ccd — this is one of the nation’s most advanced delivery systems in IT and they’re still feeling their way along.

    I’d welcome anyone providing better and real data about CCD/CCR adoption and use, but I haven’t seen much written.

    I believe the incentives are very strong to build innovative and disruptive business models using the CCR.

    Choosing between the CCD and CCR is a false dichotomy. The CCD and CCR each support different markets and different applications; long-term the standards should be harmonized.

    MS HealthVault is building capabilities to translate between the two standards, i.e., a user will be able to add to the data repository via CCR and someone else can extract via CCD — and vice versa. This reduces risk of lock-in or high switching costs to users who are afraid of picking the “wrong” standard, and thus are sitting on the sidelines. Again, the idea of CCHIT needing to make “one” choice is a false dichotomy.



  6. DR R on November 3, 2008 at 8:07 am

    Well first lets clearify a couple of things. CCHIT is proposing the use of the HITSP C32 document which is a further constraint on the CCD. This is an important distinction for interoperability as the CCD does not mandate the use of the structured content sections and only requires the free text narrative section.

    Next MS Health Vault is not a PHR or EHR its a storage mechanism so saying that it supports both is like saying that I can put a pdf and a gif in the same folder on my hard drive.

    Ok now that thats out of the way I think I’ll rant a bit.

    The CDA itself is a joke as far as interoperability goes. It is an unwieldy overly architecture and complicated specification that I think was developed more to keep the contractors that developed in a job then to actually promote interoperability between HIT systems. For one it’s contradicts itself by saying inorder to be a valid CDA document it must validate against the CDA xml schema, but then goes on to describe a means of adding extention content in a different namespace which would then cause the document to not validate agaisnt the schema. Oh, and the fact that it states it’s primary purpose as being human readable via the narrative text sections with a single simple stylesheet is very telling as to its ability to be a machine to machine interoperability spec.

    I’ve been in the xml game for over a decade and dealing with interoperability issues across disparate systems for just as long and have never seen anything that resembles the mess that the CDA is. One thing we have learned a long time ago is that to promote interoperability you must start with a normalized for of data to pass between systems. This way each system has to worry about only transforming between their system’s data structures and that of the interoperability spec. The CDA DOES NOT do this. One example of this is the fact that you can represent dates in multiple ways in the CDA spec, one is all you need. This has the effect of causing each vendor to check for each different way that a date/time could be entered effectively quadrupling the amount of effort required to support a CDA system. And there are multiple eamples of this sort of thing throughout the CDA.

    Next, any real semantic meaning behind a document is described in word and PDF documents, calling them specification constraints. So now it’s up to each individual user of that particular spec to interpret the constraints and attempt to implement it without the convenience of something to validate them against. Validation is kind of critical when dealing with interoperability and again the CDA does nothing to promote this and everything to get in the way. With the CDA you have this ridiculous 3 tired validation system, with most systems dealing with making a document structurally correct and ignoring all of the R2 fields, with good reason. Take a CDA based document spec like the HITPS C32 and attempt to create a validation routine for it that validates everything to level 3, good luck, thats an app unto itself.

    Like I said before I’ve been in this xml interop game for a long time and dealing with the CDA for a few years now and it is one of the most mind numbingly horrific standards that cliams to support,really only a claim, interoperability I have ever seen. when dealing with interoperability issues simplicity almost always wins and the CDA is anything but. The CCR is terse and to the point of what it is attempting to do, that is what makes it a much better spec and is the ONLY spec that CCHIT should be looking at. But hey what do you expect when thos that are on the interoperability working group for CCHIT are the same folks that are on working groups outside of CCHIT deailing with things like createing the CCD spec. Alan Zuckerman is the head of the CCHIT WG and is one of the authors of the CCD. There are various other members of the CCHIT WG that are on HL7 WG crafting things like the CDA, and they tend to work for the larger vendors which have the deep pockets to implements an overly complicated spec, where the smaller vendors who can barely scrap the $$$ needed for certification together cannot.

    And one last side not to those who think that the CCD and CCR need to be hamonized, well the CCD is the harmonization of the CCR based on the CCD. So it’s already been done, and again the main goal of creating something that is human readable via a stylesheet and a web browser. Chist if that all you looking for create an HTML document



  7. Lory Wood on November 14, 2008 at 11:59 am

    Just to clarify….everyone on the CCHIT PHR committee is not involved with the CCD movement. I am a member of the ASTM E31 Committee and work on the CCR committee. I have been the demonstrator of the CCR with the ASTM and PDF-Healthcare committees at TEPR for the past 3 years. Dr. Alan Zuckerman and I demonstrated a digitally signed CCR at TEPR 2007. I am also one of the co-chairs of the CCHIT PHR Workgroup. We have had very healthy discussions and disagreements within our workgroup and the other CCHIT workgroups. The biggest obstacle that we have is the fact that HITSP/Dr. Halamka made a recommendation to HHS and the Secretary approved it. That was to use the CCD for interoperability for the NHIN. The EHR/EMR market now for the most part has gone with the flow and is now developing the CCD for the import and export of data. Just a few of the EHR/EMR market, (i.e., NextGen) are still using the CCR to exchange data with the PHR. I agree that the CCR has been tried and proven and demonstrated for 3 years. The CCD still is not proven and readily used. I have been told that the CCDs that are being claimed to be exchanged are actually modified CCRs. That being said, it does no one any good to have PHRs that import and export a CCR if there are not any EHR/EMRs that can receive it. It is also a significant problem for all of the EHR/EMRs to export a CCD that cannot be used by consumers through their PHR. Unless HITSP and HHS change the approval and recommendation of the CCD to include the CCR, the CCHIT PHR Workgroup has no other option but to recommend that PHRs use CCDs for interoperability. That doesn’t prevent systems and partners from also using the CCR, it just makes interoperability between doctor’s offices and patient’s PHRs virtually impossible without PHRs importing and exporting a CCD. Interoperability is imperative for the NHIN to be realistic and implementable. The truth tables with the current HHS criteria are only allowing the CCD as the only results……unfortunately in my humble opinion.



  8. Vince Kuraitis on November 17, 2008 at 6:25 pm

    Lory,

    It would certainly be ideal if EHRs and PHRs had direct (point-to-point) interoperability using the CCR.

    But its not a deal killer if this doesn’t happen.

    It today’s world, connections can be made through hub and spoke networks, and having the CCR as a standard for even one spoke (e.g., PHRs) creates tremendous value.

    Sean Nolan of Microsoft has written that HealthVault will have capabilities to “translate” between the CCR and CCD standards:
    “…it is absolutely our goal to be able to transform between types used in the marketplace — and CCR and CCD are two great examples of this. For example, we have partners that are constructing CCR documents out of the items in a HealthVault record, many of which may have originated from CCDs sourced from Kaiser or other providers. (comment #3 at http://blogs.msdn.com/familyhealthguy/archive/2008/10/23/awkward-turtle.aspx )

    I’ve hear anecdotally that Google Health is developing similar capabilities.

    Vince



  9. Lenel James on November 24, 2008 at 12:25 pm

    Interesting conversation on CCR merits versus CCD merits. I am both a member of the CCHIT PHR WG, a team leader of the HL7 PHR Functional Model Standard, and active on the BCBSA/AHIP team to support the X12/HL7 standards for PHR portability. Given the importance of HITSP, IHE and HL7 standards in the NHIN process and Federal contracting. I took the time to reach out to HL7 experts for their view. Below is feedback from the HL7 Chair elect, Bob Dolin.

    “I’d love to chime in.

    First, my biases: I’m the chair-elect of HL7, and am the primary editor of CDA and CCD.

    I’ve studied CCR in considerable detail and have tremendous respect for the work and the individuals behind it. But let me try to explain why I would consider CCD.

    It’s often the case that when you have one use case, you will find a specification built just for it – this is a CCR strength when we talk about exchanging summary data. However, when your use cases broaden, and when you have a need to send coded H&Ps, operative reports, consultations, radiology reports, lab reports, etc, you may find that you need to then implement additional standards. I worked at Kaiser for 18 years as the physician lead of the terminology team, and what I’ve found is that mapping between standards is the biggest cost, and is always somewhat ambiguous.

    CCD is based on the HL7 Clinical Document Architecture standard.
    Learning CCD means you’ll learn CDA. When and if you then choose to implement CDA-based operative reports, H&Ps, consults, radiology reports, etc, it’ll be pretty easy for your developers to make the leap. CCD is based on the HL7 Reference Information Model, which means your ability to share and reuse data between CCD and other HL7 specifications such as lab reports, pharmacy messages, immunization messages is greatly facilitated.

    So overall, what I’ve found is that if your only use case is the exchange of summary data, CCR may be easier, but if you anticipate broader use cases, it’s worth making the CCD investment up front.

    I did the bulk of mapping between CCR and CDA when we wrote CCD, and would suspect that it’ll be hard to find a vendor that produces a complete bi-directional translation between CCR and CCD.

    Take care,
    Bob”

    Bob Dolin, MD
    HL7 chair-elect
    Principal, Semantically Yours, LLC
    BobDolin@gmail.com



  10. Vince Kuraitis on November 25, 2008 at 2:12 pm

    Bob,

    Thanks for your thoughtful post. No disagreement.

    Your conclusion sums it up well:

    “So overall, what I’ve found is that if your only use case is the exchange of summary data, CCR may be easier, but if you anticipate broader use cases, it’s worth making the CCD investment up front.”



  11. Charlotte on January 21, 2009 at 3:07 pm

    This seems like a long debate, and an even longer pro con pro discussion on the standards that are used(HL7 ). What I want to know is what is the popular way that the industry has taken, and if this is a fight for rights on the right way of doing things. Who really wins?



  12. Didier Thizy on August 12, 2009 at 6:49 am

    The article mentions that Healthvault supports CCD and CCR, but this isn’t quite accurate. There is a very basic level of support, but many would argue too basic to say Healthvault supports either standard. See http://softwarepmp.blogspot.com/2009/07/does-microsoft-support-ccd.html



  13. Vince Kuraitis on February 18, 2010 at 2:15 pm

    .@john_chilmark We agree 90% of time, but NFW is CCD easier/more flex than CCR. Read comments http://bit.ly/9fDzOY#hchit #hit #hitpol



  14. Vince Kuraitis on February 18, 2010 at 2:23 pm

    .@john_chilmark We agree 90% of time, but NFW is CCD easier/more flex than CCR. Read comments http://bit.ly/9fDzOY #hchit #hit #hitpol



  15. John Moore on February 24, 2010 at 8:29 am

    @WorldsCutestDog My pleasure to clarify, adding some points to Vince's post on CCR vs CCD http://bit.ly/9fDzOY #hchit #hit #hitpol



  16. Steven Waldren on February 24, 2010 at 8:39 am

    Bob’s quote: “I did the bulk of mapping between CCR and CDA when we wrote CCD, and would suspect that it’ll be hard to find a vendor that produces a complete bi-directional translation between CCR and CCD.”

    I think this demonstrates HL7’s intent to never have the CCR and CCD interoperable with each other.

    Best,
    Steven



  17. Vince Kuraitis on February 25, 2010 at 8:04 pm

    Steven,

    Maybe. Maybe not.

    As one member of the ASTM CCR Steering Committee, I’m for exending an olive branch. Further harmonization of CCR and CCD would be in patients’ and providers’ best interests.

    V