Archive for the ‘CCR’ Category

There has been a great deal of discussion on what is happening – and will happen – with the two continuity of care standards. As a refresher, the two are:

• ASTM Continuity of Care Record (CCR):  an XML-based standard for the movement of “documents” between clinical applications. Furthermore, it responds to the need to organize and make transportable a set of basic information about a patient’s health care that is accessible to clinicians and patients.
• Continuity of Care Document (CCD):  the result of a collaborative effort between the Health Level Seven (HL7) and American Society for Testing Materials (ASTM) to “harmonize” the data format between ASTM’s Continuity of Care Record (CCR) and HL7’s Clinical Document Architecture (CDA) specifications.

We ran a poll asking “if you could just vote for one, which would it be?” The results are outlined below.

• For CCD: 70%
• For CCR: 30%

We also wrote a post about Chilmark Research’s blog on the two patient care summary standards. Recently, I discovered a response to the Chilmark post, and it was by the e-CareManagement blog entitled Chilmark Needs to Chill Out on CCR/CCD Findings. From the post:

“Here’s another metaphor: asking a HIE whether they prefer CCR or CCD is like asking an ancient Roman whether they would prefer to converse in Latin or Swahili.  The obvious answer will be “Latin” — not because Latin is a better language, but  because they already have sunk costs into learning Latin. If you already speak Latin, it won’t bother you that Latin is complex, archaic and difficult to learn.”

Take a few minutes to read the blog post, and be sure to read all the comments below his post, including one from Chilmark Research.

Vince Kuraitis from e-CareManagement blog responded to one of our earlier posts with a similar argument. The argument is that CCR is more usable and appropriate for the ambulatory setting while CCD is geared more towards HIEs and larger health care institutions. The discussion is healthy. A few other highlights from others include:

• David C. Kibbe, MD MBA:  “This isn’t really a standards problem at all. It’s a business model problem. Businesses that want to exchange data have always found a means of doing so, and now, in health care, it’s gotten much, much easier to do so. It helps that the feds are behind this movement.”
• John at Chilmark:  “The issue is not Linux or .Net, Latin or Swahli, that is too simplistic. What is at issue is what standard will help an organization do the work they need to do. CCR may be fine in a small ambulatory practice with limited IT resources and simple data mgmt requirements/workflow. CCR though is not flexible enough to allow larger practices, clinics and hospitals to create document structures, add data types, etc. to meet their internal operational needs. As David rightly pointed out, it is a business issue.”
• John D. Halamka, MD, MS:  “We noted that CCR is a fine patient summary standard, but for other uses such as reporting the actors/actions/events in clinical workflow needed for quality measurement, CCD is preferred over CCR.”

In the Healthcare Standards IFR, it states that both CCR and CCD are allowed initially, but the direction needs to be move to one continuity of care “standard.” This consolidation needs to occur by 2013.

The arguments are correct – one is more heavy duty and the other easier to work with; one is for HIEs and large organizations, and the other is for ambulatory settings. In fact, the poll we conducted may reflect this sentiment. Thirty percent in favor of CCR may reflect more ambulatory responses than others, or it may be the people who have tried to work with the existing CCD standard!

At some point, CCD and CCR need to come together more closely. It will assist in the exchange of patient data between smaller ambulatory,  larger care delivery organizations, and HIEs. These type of exchanges will ensure really meaningful use, not just hype or getting half-way there. Green CDA may be the approach that resolves the discussion.

There is an interesting blog post made by Chilmark Research, a healthcare industry analyst firm, which is very relevant to the current discussion on CCD (HL7 Continuity of Care Document) vs. CCR (Continuity of Care Record). Their post is entitled CCD Standard Gaining Traction, CCR Fading. Other than Google Health, HL7 CCD seems to be the most requested approach.  (Google Health’s data specification is based on CCR.)

According to their blog post:

“Today, CCD is seen as a more flexible standard that is not nearly as prescriptive as CCR.”

Chilmark Research’s post is a quick read, and it is very relevant to our poll and the discussion taking place on these two healthcare standards.

We are starting a new healthcare standards poll today (see lower right column of this site). In the Healthcare Standards IFR, Stage 1 (2011) calls for an option:  (1) Use the Continuity of Care Record (CCR) standard or (2) HL7 Continuity of Care Document (CCD) standard. It is your choice, but it will be “converged” later.

“Converging” or “harmonizing” CCR and CCD is a good direction, as pointed out in a recent ZDNet healthcare blog post, yet too many options create hurdles which need to be overcome and add time to implementation schedules.

With all of the effort being placed on implementing projects to achieve Meaningful Use, clarity - rather than vagueness – is essential. By not clearly defining a direction upfront, healthcare providers have to support the complexity of multiple healthcare standards rather than focusing implementation efforts on a more definitive approach. This is frustrating, especially when it is stated that this will be converged later.

In 2008, we wrote a satirical blog entitled What If There Was an Election on Healthcare Standards? In retrospect, it is closer to where we are today than we knew!

Regardless, now is your opportunity to vote. Rather than wait until after 2011 to determine which one wins, let’s vote today. Which standard should be used — CCD or CCR? Vote now to clarify the direction!

By now, you may have had enough of primaries and election results. What if, however, we applied the primary election process to healthcare standards? What would happen?

Just as there are factions the political candidates are trying to pull together to win, they probably have not seen as many factions as there are in healthcare standards. There is a major faction called the HL7 Standards, but emerging factions are getting noticed which are XML related – from Continuity of Care Record (CCR) to a faction-within-a faction, that is, HL7 V2, HL7 V3, HL7 Clinical Document Architecture (CDA), and HL7 Continuity of Care Document (CCD).

We don’t need new healthcare standards. We just need to enforce the ones we have.

What about the X12, DICOM, NCPDP, ASTM, LOINC, and SNOMED factions? And, let us not forget the common person’s healthcare standard – plain ol’ CSV file formats.

If the United States was going to eventually elect a healthcare standard to lead us in the 21st century, which one would win? All we need is a little harmony.

Harmony may be over-rated. How could someone from SNOMED endorse the LOINC? What do you mean CCR is campaigning with CCD? If these events happened, some people may just sit out the healthcare standards election.

What about the special interests? Each healthcare vendor has their own standard. Let’s hope that someone doesn’t “swift boat” one of the healthcare standard candidates.

The campaign slogans:  Healthcare standards are broken. We just don’t need to move the same standards to different chairs. We need to stand for change. We need hope! We need a healthcare standard ready to solve all of our problems Day 1!

Or, maybe what we need is another healthcare standard – a “third party” candidate – that can just end all of the “politics” and work for the people in health care. A “uniter” of healthcare standards. Some standard that can “reach across the aisle” and reach consensus.

Can’t we all just get along in the healthcare integration world?

Yes, this is a parody of sorts on healthcare standards, but it is the practical world that we live in. There are many standards, and we do all need to get along in order to deliver the best possible care for patients. Each healthcare standard faction delivers an essential piece in the healthcare puzzle, but putting the puzzle together can be challenging at times.

Maybe the final rallying cry should be:  “Read my lips. No new healthcare standards!”

The demand for healthcare interfaces with Electronic Medical Records (EMR) is increasing. This increase is due to the rising adoption of EMR systems, emerging clinical healthcare data standards (HL7, CCR, CDA, CCD, ELINCS), and increasing interoperability requirements, such as CCHIT (Certification Commission for Healthcare Information Technology).

To achieve the most effective and efficient EMR connectivity, the following steps should be included in the process:

1. Understand workflow:  Define the workflow within your organization and between your organization and the organization with the EMR system
2. Document requirements:  Define the data requirements of your systems and the EMR in which you will be exchanging patient information
3. Implement interfaces:  Build the interfaces to facilitate the workflow and meet each application’s requirements

Understand workflow.  Understanding the healthcare data flow within your organization and then the data flow of the organization with the EMR system is critical when you start automating the healthcare workflow. You cannot successfully automate a system or workflow which you do not fully understand.

Document the requirements.  Documenting the requirements for both applications in terms of the standards being used to transmit the clinical data in the specific data format will help identify the gaps between the two clinical applications. The interface can then bridge the identified gaps between the EMR and your application.

Implement interfaces.  A systematic approach to interface implementation should include the basic stages of developing, testing, implementing, and maintaining the interfaces. An effective and flexible approach, that can include tools, will help overcome common challenges such as technology, patient matching, procedure or physician code matching, and lack of cooperation to meet the end goals.

In summary, an interface to or from an EMR application is no different than an interface for any other healthcare application. Connectivity is achieved by acquiring knowledge regarding the workflow and the requirements, plus utilizing effective methodologies or solutions to implement the interfaces.

There are a number of ‘new’ healthcare standards that are beginning to be implemented in clinical interfacing today. Acronyms such as CCR, CDA, and CCD are becoming common words in everyday interfacing discussions. While most interfaces today are using the HL7 2.x encoded format, these new standards are choosing to use XML as their message format.

The healthcare integration standards are new, but the idea of using XML to transmit clinical information has been around for a long time. In fact, the HL7 organization actually publishes a set of XML schemas for rendering HL7 version 2 messages in an XML format. This format is more commonly known as HL7 2.XML.

While this HL7 2.XML format is not widely used, these other XML based standards are beginning to be implemented by vendors and asked for by providers. As the new standards become more prevalent, we are beginning to get some interesting questions about how they can work together with the current HL7 2.x encoded interfaces that are deployed today.

Question: Do tools exist to help me map a HL7 version 2.4 ORU message into an XML formatted CCR document?

This question really should be broken into 2 separate questions:

1) Do tools exist to help me map from HL7 encoded messages to XML based formats?
The answer to this question is “yes.” There are a number of interface solutions available that can map between HL7 and XML. Healthcare integration engines today can typically map between a number of different file formats including HL7 2.x, XML (including CDA, CCR, CCD), CSV, fixed length record files, or even custom file formats.

2) Does it make sense to take an HL7 2.4 ORU message and convert it to an XML formatted CCR document?
HL7 2.x messages are really focused on the real-time delivery of patient data. An ORU message typically contains the result of a single order, or possibly the results of multiple orders that were performed at the same time. This single message is in no way a summary of all procedures that may have been performed on the patient.

The purpose of a CCR is to create a summary document for a patient that contains all of the information that a provider would need to continue caring for a patient. Things such as allergies, current medications, recent diagnosis or notes from recent office visits would typically be included in a CCR.

So while it is technically possible to take data out of an HL7 message and map it into an XML format, the resulting document would not contain the required patient data to make it useful for its purpose as a CCR.

Question: If I cannot do a real time conversion of the data, how do HL7 2.x interfaces help me create the XML based CCR documents that I need to export from my EMR system?

An EMR application will usually have the ability to receive HL7 2.x information from other systems. This information will be imported into the system, and the patient’s record will be continuously updated.

When a user of the application chooses to create a CCR export, the data stored in the database can be queried, and the relevant information copied into the XML document. This document can then be delivered to the remote system for import.

As new healthcare integration standards emerge it is important to gain a thorough understanding of their intended purpose, and focus not just on the format of these new standards, but also on the workflow and business rules that need to be applied when creating or processing these new XML based documents.

The Continuity of Care Document (CCD) was approved earlier this week. The CCD is a collaborative effort between the HL7 standards and ASTM International organizations. To add to confusion, there are multiple standards for electronic patient record (EMR / EHR) integration. They are:

• Continuity of Care Record (CCR) – authored by ASTM
• HL7 Clinical Document Architecture (CDA) – authored by HL7
• Care Record Summary (CRS) – original HL7 attempt at patient care integration standard, later incorporated into HL7 CDA
• Continuity of Care Document (CCD) – jointly agreed to by ASTM and HL7 and endorsed by the Healthcare Information Technology Standards Panel (HITSP)

CCD is a part of the healthcare interface standards “harmonization” effort, which is worthwhile and needed. Regardless, it creates confusion in the marketplace as to which standard to use or ask for when evaluating EMR and EHR systems as well as in determining the overall connected healthcare community strategy for a hospital, lab, clinic, or imaging center.  Which one?  CCR, CDA, or CCD? 

In a Modern Healthcare article entitled CCD Standard Up for a Vote, there is a quote from the American Academy of Family Physician’s Center for Health Information Technology as to why the different standards.

“There isn’t really a rift between ASTM and HL7. I think where the rift starts to come is between legacy vendors and some of the Internet-technology-based vendors. You have the large hospital vendors (more or less in the HL7 camp) and the smaller physician office system vendors (using CCR). That’s where the controversy starts to explode.”

Peter Waegemann, chief executive officer of the Medical Records Institute, adds to this in a subsequent Modern Healthcare article entitled Standards Rivals’ Collaboration Could Have Major Impact:

“Vendors and users of large IT “legacy” systems that are backers of HL7’s Clinical Document Architecture will gain the most benefit from the CCD because they will be able to use the CCR format in their systems, Waegemann said. But the collaboration with HL7 on the CCD further establishes the CCR, he said.”

Both are valid points. The good news in this announcement is that CCR and CCD will work well together. This will facilitate a more integrated healthcare environment. As clinics, hospitals, labs, and imaging centers move forward, they will need to continue to be adaptive in their integration approach. Flexibility is essential in the near term.

The HL7 Continuity of Care Document (CCD) is the result of a collaborative effort between the Health Level Seven and ASTM organizations to “harmonize” the data format between ASTM’s Continuity of Care Record (CCR) and HL7′s Clinical Document Architecture (CDA) specifications. 

The CCD will enable greater interoperability or healthcare integration of clinical data and “allow physicians to send electronic medical information to other providers without loss of meaning.”

With CCD, the CCR is represented and mapped into the HL7 CDA. These are structured XML standards for clinical information exchange. The harmonized standards should support greater streamlined exchanges with Electronic Medical Record (EMR) and Electronic Health Record (EHR) systems as well as various healthcare providers.

As mentioned in previous posts, the Continuity of Care Record (CCR) provides a way to send data between clinics, hospitals, labs, etc that are using various EMR, HIS, RIS, PACS, dictations, etc systems. The CCR is an XML-based standard that is related to and different from the HL7 2.X messaging standard.

While I posted a short description comparing CDA and CCR, there is a formal article written by Ed Hammond et al and is titled, The Clinical Document Architecture and the Continuity of Care Record: A Critical Analysis. This article was published in the Journal of the American Medical Informatics Association (JAMIA). Later in the month, I’ll summarize this article. For now, here is the abstract:

The Clinical Document Architecture and the Continuity of Care Record: A Critical Analysis

Jeffrey M. Ferranti, MD, R. Clayton Musser, MD, MS, Kensaku Kawamoto and W. Ed Hammond, PhD

Health care provides many opportunities in which the sharing of data between independent sites is highly desirable. Several standards are required to produce the functional and semantic interoperability necessary to support the exchange of such data: a common reference information model, a common set of data elements, a common terminology, common data structures, and a common transport standard. This paper addresses one component of that set of standards: the ability to create a document that supports the exchange of structured data components. Unfortunately, two different standards development organizations have produced similar standards for that purpose based on different information models: Health Level 7 (HL7)’s Clinical Document Architecture (CDA) and The American Society for Testing and Materials (ASTM International) Continuity of Care Record (CCR). The coexistence of both standards might require mapping from one standard to the other, which could be accompanied by a loss of information and functionality. This paper examines and compares the two standards, emphasizes the strengths and weaknesses of each, and proposes a strategy of harmonization to enhance future progress. While some of the authors are members of HL7 and/or ASTM International, the authors stress that the viewpoints represented in this paper are those of the authors and do not represent the official viewpoints of either HL7 or of ASTM International.

In prior posts I described the Continuity of Care Record (CCR) and the relationship between HL7 2.X and CCR. This article addresses a need to mix the two formats. Specifically, the desire to move a CCR document via HL7 messaging.

Previously I established that HL7 2.X is typically used to move data within a facility in a real time fashion while CCR was designed to move data between facilities in a summarized fashion.

In HL7 training classes, I talk about the “sphere of influence” of healthcare systems deployment. Mostly what I mean by sphere of influence is that HL7 2.X messaging is often used to move data between clinical systems that are owned by one organization.

That is, I want my hospital information system (HIS) system to talk to my lab information system (LIS) and my radiology information system (RIS). Having purchased these systems and customized them to my institution’s clinical and business work flows, I want them to exchange data in my own special way. The HL7 standard has lots of flexibility built in to support each facility’s “special” needs.

Suppose that you want to move a CCR document between two systems by having the CCR document encapsulated inside an HL7 message? The motivation for this touch point could be that there is already an interface between two applications. For example, an HIS might be delivering ADT (registration) data and lab results to an outpatient clinic. That clinic now wants to use “the same” interface to receive discharge summaries. So, if both the HIS and EMR vendors support this additional data flow, we could package the CCR inside of an HL7 message. How?

From an HL7 2.X standpoint, moving a CCR document is no different than encoding / sending a Word document, PDF file, DICOM image, or even a .wav sound file inside of an HL7 message.

The method proposed by HL7 2.X to move such an object is using an OBX segment with and OBX-5 flavor of encapsulated data (ED) or reference pointer (RP). 

The details of this HL7 integration approach are covered in another post here on this site.