Feeds:
Posts
Comments

Posts Tagged ‘CCD’

In a number of interviews with leading HIE vendors, it is becoming clear that the clinical standard, Continuity of Care Document (CCD) will be the dominant standard in the future.  The leading competing standard, Continuity of Care Record (CCR) appears to be fading with one vendor stating that virtually no client is asking for CCR today.  This HIE vendor did state that one client did ask for CCR, but only to enable data transfer to Google Health.

CCR was created by ASTM with major involvement by AAFP wih the objective to create a standard that would be far easier to deploy and use by smaller physician practices.  At the time of CCR formation, the dominant standard was HL7’s CDA, a beast of a standard that was structured to serve large hospitals and based on some fairly old technology and architectural constructs.  With competing CDA and CCR standards in the market, there was a need for some rationalization which led to the development of CCD, a standard that combined some of the best features of CCR and CDA.

Today, CCD is seen as a more flexible standard that is not nearly as prescriptive as CCR. This allows IT staff to structure and customize their internal HIT architecture and features therein for their users and not be confind to a strict architectural definition such as that found in CCR.  (Note: such strict definitions are not always a bad thing as they can greatly simplify deployment and use, but such simplicity comes at a price, flexibility.)

Unfortunately for Google Health, who has built its system on top of a modified version of CCR, this trend   likely lead to increasingly difficulty in convincing healthcare providers to provide patient health records in a CCR format.  Google would be wise to immediately begin the work necessary to bring CCD documents into their system as the writing on the wall is getting clearer by the day.  CCR is a standard that will fade away.

Read Full Post »

Received a note from a Microsoft representative today with some pretty big news regarding HealthVault.  The news centers around efforts that the HealthVault team are taking to simplify the development, by partners, of solutions that will leverage the HealthVault platform.  These efforts can be broken down into three distinct steps:

  1. Creating a number of “open-wrapper” libraries to facilitate development across a variety of environments.  These libraries will be stored in a new Codeplex project that has been established for HealthVault.
  2. By late Spring of this year the HealthVault group will release the complete .Net software development kit (SDK) on Codeplex.
  3. They will release the complete HealthVault platform XML interface protocols including making all specifications public.  Wow!

With these three steps Microsoft is signaling its intent to provide its partners (Personal Health Application (PHA) vendors) the flexibility and tools they need to not only create applications that will run in the HealthVault environment, (though I’m sure apps will be optimized for such) but will also run in other envirornments, for example Dossia.

Analysis

Three key points:

  1. Microsoft really has no choice as HealthVault is really nothing more than a data repository without these partners.  With Dossia driving a similar model and Google in the wings, well…
  2. Microsoft has to move fast to gain a critical mass of partners to make the whole HealthVault model work as HealthVault will fail if all they can do is bring a few small players into the fold.  By demonstrating “openness” and “flexibility”, Microsoft is allowing PHA vendors to leverage existing development resources to create solutions that will operate in the HealthVault environment while concurrently allowing these partners to create solutions that will operate elsewhere, as well.  This will instill a lot of goodwill among its present and future partners.
  3. Microsoft will monetize this openness long-term by keeping developers in the .Net camp.

Looking Ahead 

What I’d like to see from Microsoft is their embracement of PDF-Healthcare.  They are almost there as Microsoft has  committed to adopting CCR and CCD standards.  Taking the next step and adopting PDF-Healthcare will signal to me that they truly are serious regarding openness.

If you want to delve far deeper into the subject, encourage you to visit the new site of HealthVault’s Lead Architect, Sean Nolan.  He has a great post on this announcement that was the basis for this post.

Read Full Post »

John Halamka, the CIO of Boston based Beth Israel Deaconess Hospital and Chairperson of standards organization HITSP is a daring soul, having had an RFID implanted into his upper arm to validate the technology and most recently provides an interesting example of two formats for displaying his medical records.

Why is he doing this?

As a healthcare CIO, Halamka is intimately familiar with the challenges of data exchange, primarily within the confines of a hospital or IDN.  But Halamka also foresees a future where the patient will become the custodian of their health records.  In this future, patient-controlled health record paradigm data exchange will be infinitely more challenging.  In providing these two examples, Halamka attempts to show a future model that will alleviate the data exchange conundrum.

In the first, he uses PDF and ends up with a huge, 77 page file that would be daunting for even the most conscientious doctor to wade through. In the second example, he uses the CCD standard, which provides a concise overview of his medical record in a common Web-based document format with embedded hyper-links.

While Halamka uses this demonstration as an example of why standards such as CCD need to be adopted making the argument in his post. But when I look at the two examples, I find the CCD easily readable but sorely lacking in information. The PDF on the other hand, while lrage is quite comprehensive and one can easily search on terms in the PDF to find relevant information, e.g., what actually happened when Halamka contracted Lyme’s disease.

Now I am certainly no physician and have never claimed such but if I were a physician and I did have a choice, I’d take the PDF over the CCD as my propensity is to err on the side of safety. The CCD, at least in this example, simply does not provide sufficient information to provide quality care.

Read Full Post »

Last week, the HIMSS Electronic Health Record Vendors Association EHRVA announced the availability of a “Quickstart Guide for CCD Standard.”  The guide is structured to assist the multitude of electronic medical record (EMR) vendors, both large and small, in how to adopt the recently released (January 2007) Continuity of Care Document (CCD) standard in their current and future products.  By adopting this standard the EHRVA hopes that the industry will move closer to that elusive goal of interoperability across the various EMR solutions in use today.

Of course, this is not completely altruistic (is any vendor sponsored initiative altruistic?) as EHRVA would like to have some control over the situation rather than have some federal entity like the Certification Commission for Health Information Technology (CCHIT) force it upon them.

One question does arise when looking at such developments, especially those promoted by one distinct, albeit important group like the EHRVA and that is how will these standards be adopted and used by the multitude of other healthcare IT vendors such as those creating personal health records, enabling telehealth and the like.  The industry as a whole is moving towards greater involvement of the consumer in managing their health and wellness and I do not see the involvement of such stakeholders in this effort, which is unfortunate and seemingly myopic.

Read Full Post »