If you have been following HealthCare Interoperability Standards at
all you will know its loaded with acronyms and is rapidly evolving with
the onset of Meaningful Use adoption requirements. I took a specific
Deep Dive into unraveling the confusing
CDA/CCD/CCR and CCDA acronyms and feel I now have a pretty good grip on the definition of each, including the backstory on adoption of the standards and where they are headed. Read on as I attempt to break these down with a simplicity I think you will appreciate. Taking a step back for comparison, the DICOM standard accomplished healthcare interoperability in the mid-nineties, when PACS was replacing film workflow in Radiology. Outside of the workflows for patient care, Radiology Films were able to be transported by patients between facilities. Though primitive, an x-ray from one hospital could be “read” between light boxes at another facility. PACS needed to accommodate this workflow as film use declined and accomplished this through the DICOM standard Part 10. The standard allowed Study information to be exported to removable media, most frequently to CD, which could be taken to another facility and imported into the Hospital PACS. It has its problems, but all in all, the solution is beautiful. DICOM provides transmission capability, document capability, and interoperability capabilities all in one nice standard. Efforts to provide similar patient workflow for EMR’s by making the entire patient story portable have been in the works for quite some time, but have been slow to adoption in the United States. Most of the effort in the healthcare space over the last 10 years has been replacing workflows in hospitals with little attention to the interoperability components until recently. One could argue the HL7 standards are solid and provide quite a bit to the workflow component for care givers. In retrospect, I guess we could of handed an HL7 message to a patient and sent them on their way right ? However, the message would have to be all inclusive of the patient snapshot, or embed some sort of document in it to be reviewed on the potential downstream system. The transmission was taken care of, but you’d still run into a format problem of the document embedded. If you look at it that way, this is an interoperability problem the Clinical Document Architecture is trying to accomplish. Rolling up the transmission, export format, and interoperability all in one shot… So to tell you my interpretation as to where we are at,
I want you to meet some acronyms: CDA-Clinical Document Architecture CCR-Continuity of Care Record CCD-Continuity of Care Document CCDA-Consolidated Clinical Document Architecture Most works I have reviewed to come to this conclusion have done a pretty good job of explaining these guys to me, so Im going to take the approach of letting them explain who they are by introducing themselves one by one.
CDA For those of you who don’t know me, I am commonly mistaken for a document. I take pretty big offense to this as I am a complete architecture that should be used to create documents and template methodologies. My parents are from the HL7 Standard, and my stewardship is through the Health Level 7 organization. I was born in 1999, with the release name of CDA Release 1, and my adoption has been pretty steady in the all but United States markets where I was a foreigner for about 8 years. As you will quickly find out, I accommodate more than just summaries and snapshot stories for patients, I am in fact a methodology for all types of medical documents. My DNA is the HL7 Reference Information Model (RIM), but I am flexible enough to accommodate user defined fields (typical HL7), and I can store complete documents, binary data, and multimedia as well in my body. My legitimacy was consummated in 2010 by ANSI.
CCR I’m CCR, short for Continuity of Care Record. I was born in 2004 as the CCR Release 1a, and my DNA is not the CDA. I don’t like to do much, but I do serve a single purpose pretty well. I was initially created as a word document that helped interoperability between PCP’s for patient summary information. I am a document only, and don’t ask me to do anything else like story binary data or multi-media information. I do support interoperability though in regards to what I do, and the ASTM standards group has got my back. I was cool enough for absolute adoption with EMR’s and PHR’s and was the document of choice for the now deprecated Google Health.
CCD Hi, Im CCD, the Continuity of Care Document. I am the product of a huge “fist bump” between ASTM and HL7 to help kick start interoperability in the United States and get along. My DNA is a subset of the CDA, with a lot of the great ideas the CCR had implemented, so I am a comprise of the two. Since my birth in 2007, I have never actually been overseas, but hope to some day. Like CCR, I am just a document. You cant store any binary data in me I can however support user-defined fields. I’ve been cloned to meet different purposes, which makes me a bit of a template derived from the CDA, but I am by no means an architecture.
CCDA
Starting December 2011, I am the new architecture in town, the Consolidated Clinical Document Architecture, and I will cleanup this mess that CCD/CCR created without discounting their feelings. Im all about making CDA Templates, and guess what? CCD is one of my templates! I will be adopted by the United States through Meaningful Use efforts, and I will make it incrementally easy to achieve through attrition. Someday the world will all use me hopefully, and deliver the promise of persistence, stewardship, potential authentication, context, wholeness and human readability I promised out of the gate in 1999.
In my humble opinion though, the coolest thing about CDA is its attention of the ability for human consumption. If everybody has their own way of reporting the “patient story” and sends the patient down the road with it, it would take an enormous amount of attention to getting to the point quickly for another care giver (think book comprehension here). So, enter the idea of templates, which at the end of the day is all about aiding human consumption too, so caregivers will know where to go for the information they are specifically looking for. Still though, these types of documents are really just about a bunch of facts. Some facts are chronologically presented which gives them some sort of context, but really a bunch of facts is more like a really bad set of cliff notes in relation to a sometimes huge patient story that needs to be interpreted. The Clinical Document Architecture gives us context by promoting a clinical document that tells a specific story about the care provided to the patient for the problems. The Clinical Document Architecture also promotes wholeness between the facts it provides, by supporting relation between the facts and statements contained in the document. The Clinical Document Architecture supports human readability too, for both patient and provider, and you’d probably be surprised the CDA supports video and audio too complete with interoperability between systems. You cant even do that with your social networks yet.
CDA/CCD/CCR and CCDA acronyms and feel I now have a pretty good grip on the definition of each, including the backstory on adoption of the standards and where they are headed. Read on as I attempt to break these down with a simplicity I think you will appreciate. Taking a step back for comparison, the DICOM standard accomplished healthcare interoperability in the mid-nineties, when PACS was replacing film workflow in Radiology. Outside of the workflows for patient care, Radiology Films were able to be transported by patients between facilities. Though primitive, an x-ray from one hospital could be “read” between light boxes at another facility. PACS needed to accommodate this workflow as film use declined and accomplished this through the DICOM standard Part 10. The standard allowed Study information to be exported to removable media, most frequently to CD, which could be taken to another facility and imported into the Hospital PACS. It has its problems, but all in all, the solution is beautiful. DICOM provides transmission capability, document capability, and interoperability capabilities all in one nice standard. Efforts to provide similar patient workflow for EMR’s by making the entire patient story portable have been in the works for quite some time, but have been slow to adoption in the United States. Most of the effort in the healthcare space over the last 10 years has been replacing workflows in hospitals with little attention to the interoperability components until recently. One could argue the HL7 standards are solid and provide quite a bit to the workflow component for care givers. In retrospect, I guess we could of handed an HL7 message to a patient and sent them on their way right ? However, the message would have to be all inclusive of the patient snapshot, or embed some sort of document in it to be reviewed on the potential downstream system. The transmission was taken care of, but you’d still run into a format problem of the document embedded. If you look at it that way, this is an interoperability problem the Clinical Document Architecture is trying to accomplish. Rolling up the transmission, export format, and interoperability all in one shot… So to tell you my interpretation as to where we are at,
I want you to meet some acronyms: CDA-Clinical Document Architecture CCR-Continuity of Care Record CCD-Continuity of Care Document CCDA-Consolidated Clinical Document Architecture Most works I have reviewed to come to this conclusion have done a pretty good job of explaining these guys to me, so Im going to take the approach of letting them explain who they are by introducing themselves one by one.
CDA For those of you who don’t know me, I am commonly mistaken for a document. I take pretty big offense to this as I am a complete architecture that should be used to create documents and template methodologies. My parents are from the HL7 Standard, and my stewardship is through the Health Level 7 organization. I was born in 1999, with the release name of CDA Release 1, and my adoption has been pretty steady in the all but United States markets where I was a foreigner for about 8 years. As you will quickly find out, I accommodate more than just summaries and snapshot stories for patients, I am in fact a methodology for all types of medical documents. My DNA is the HL7 Reference Information Model (RIM), but I am flexible enough to accommodate user defined fields (typical HL7), and I can store complete documents, binary data, and multimedia as well in my body. My legitimacy was consummated in 2010 by ANSI.
CCR I’m CCR, short for Continuity of Care Record. I was born in 2004 as the CCR Release 1a, and my DNA is not the CDA. I don’t like to do much, but I do serve a single purpose pretty well. I was initially created as a word document that helped interoperability between PCP’s for patient summary information. I am a document only, and don’t ask me to do anything else like story binary data or multi-media information. I do support interoperability though in regards to what I do, and the ASTM standards group has got my back. I was cool enough for absolute adoption with EMR’s and PHR’s and was the document of choice for the now deprecated Google Health.
CCD Hi, Im CCD, the Continuity of Care Document. I am the product of a huge “fist bump” between ASTM and HL7 to help kick start interoperability in the United States and get along. My DNA is a subset of the CDA, with a lot of the great ideas the CCR had implemented, so I am a comprise of the two. Since my birth in 2007, I have never actually been overseas, but hope to some day. Like CCR, I am just a document. You cant store any binary data in me I can however support user-defined fields. I’ve been cloned to meet different purposes, which makes me a bit of a template derived from the CDA, but I am by no means an architecture.
CCDA
Starting December 2011, I am the new architecture in town, the Consolidated Clinical Document Architecture, and I will cleanup this mess that CCD/CCR created without discounting their feelings. Im all about making CDA Templates, and guess what? CCD is one of my templates! I will be adopted by the United States through Meaningful Use efforts, and I will make it incrementally easy to achieve through attrition. Someday the world will all use me hopefully, and deliver the promise of persistence, stewardship, potential authentication, context, wholeness and human readability I promised out of the gate in 1999.
In my humble opinion though, the coolest thing about CDA is its attention of the ability for human consumption. If everybody has their own way of reporting the “patient story” and sends the patient down the road with it, it would take an enormous amount of attention to getting to the point quickly for another care giver (think book comprehension here). So, enter the idea of templates, which at the end of the day is all about aiding human consumption too, so caregivers will know where to go for the information they are specifically looking for. Still though, these types of documents are really just about a bunch of facts. Some facts are chronologically presented which gives them some sort of context, but really a bunch of facts is more like a really bad set of cliff notes in relation to a sometimes huge patient story that needs to be interpreted. The Clinical Document Architecture gives us context by promoting a clinical document that tells a specific story about the care provided to the patient for the problems. The Clinical Document Architecture also promotes wholeness between the facts it provides, by supporting relation between the facts and statements contained in the document. The Clinical Document Architecture supports human readability too, for both patient and provider, and you’d probably be surprised the CDA supports video and audio too complete with interoperability between systems. You cant even do that with your social networks yet.
No comments :
Post a Comment