Healthcare Software
A Standard within a Standard: The Continuity of Care Record
Looking at the different implementations of the Continuity of Care Record (CCR) by Google Health and Microsoft HealthVault, I noticed something interesting. I found that despite conforming to a standard, they are both creating dependencies on their particular implementation of it. I think the best way to explain this is with an example. Consider the special rules for each governing the Medications section:
Google Health - Medications Mapping:
- Medications/Medication/DateTime/Type/Text should be set to Start date
- Medications/Medication/DateTime/Type/Text should be set to Stop date
- Medications/Medication/DateTime/Type/Text should be set to Prescription date
- Medications/Medication/Source/Actor/ActorRole/Text should be set to Prescribing clinician
- Medications/Medication/FulfillmentHistory/Fulfillment/DateTime/Type/Text should be set to Dispense date
- Medications/Medication/FulfillmentHistory/Fulfillment/IDs/ID/Type/Text should be set to Prescription ID
Microsoft HealthVault - CCR Mapping (scroll down for Medications section):
- Medications/Medication/Directions/Direction/Indication/InternalCCRLink/LinkID (Must link to Problem)
- Medications/Medication/DateTime (Must be "Administration Date")
- Medications/Medication/DateTime (Must be "Prescription Date")
I think if there is to be real interoperability in healthcare, these issues need to be resolved with consistency. For example, if a CCR record from Google Health is to be loadable into Microsoft HealthVault then the text associated with the Medications/Medication/DateTime/Type/Text element needs to be consistent. It should either be “Administration Date” or “Start date” as having both out there does not allow a CCR to be exported from one solution and imported into the other without requiring some kind of conversion.
About the Author
Quintin has an extensive software development background in clinical applications and business intelligence.
Feb 18, 2010
09:53
Whenever people discuss interoperability and standards, this argument always comes up
I agree with your article in theory, but in practice I’m skeptical we could ever move forward with not only a common standard but also a completely uniform interpretation of that standard (see http://softwarepmp.blogspot.com/2008/03/be-proud-of-your-sip-dialect.html)
To make a comparison to the world of VoIP, different platforms take different liberties with the now-standard SIP protocol. Avaya SES might use a particular SIP header differently than Microsoft OCS, and this does cause some interop headaches. But the fact that they could agree at all on the SIP protocol and not another alternative such as H323 was a huge leap forward.
The VoIP industry however had a big advantage - there are arguably only a few big players in that space. A unilateral move on their part to adopt a particular protocol (even if they speak different “dialects”) was enough to move that standard forward. On the other hand, there is no small group of big players in Healthcare. Even Microsoft and Google, normally considered big players in any field, are quite small in healthcare.
Another concern is one that a lot of people have mentioned on the web - why CCR, why not support CCD or at least provide a mapping to CCD instead? This would make for more straightforward interoperability with CCHIT-certified and Continua-certified products, for starters.
To your point though, you can always map CCD to a CCR document, or even map GoogleCCR to HealthVaultCCR - but keeping track of all these little dialects is a pain