NeoTool — Singular Focus, Healthcare Integrated

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.

Review the recorded webinar on this topic presented August 7, 2007.

There is a very informative article on what the first-movers in Electronic Health Records (EHR) are doing next. The article is in Health Data Management and is entitled “EHR Pioneers Try to Stay Out Front: Latest projects include adding decision support, improving connectivity and developing PHRs.” 

Several months ago, I had written a post about All Healthcare Integration Is Local. The EHR pioneers article illustrates how EHR successes are occurring in various locations around the country.

The next level of value that the EHR pioneers are striving for is greater interoperability between providers. As the article states, “Connectivity is the next step; we have to go beyond ‘electrified’ paper. Every hospital should be able to electronically deliver to physicians on Monday morning all the details of their patients who were treated in the emergency department over the weekend.”

There are several initiatives that are facilitating greater connectivity between healthcare providers, including:

• The Certification Commission for Healthcare Information Technology (CCHIT) now has introduced an EHR interoperability certification for vendors.
• The HL7 and ASTM have “harmonized” the continuity of care standards to bring together the HL7 CCD and ASTM CCR standards.

Although there is so much more work that needs to be done, momentum is gaining through the efforts of the EHR pioneers and the support of the people involved in the standards developing organizations.

The HIMSS annual conference has now passed. The presentations are over; the exhibitor booths are gone; and the attendees are back to work. It will be interesting to measure the impact of HIMSS on initiatives with the thousands of healthcare provider attendees or with the hundreds of healthcare vendor exhibitors. What will change? What new thoughts will be considered? What new solutions will be considered? What existing solutions will be re-considered?

From our vantage point, there were several themes evident in our various discussions with attendees.

• EMR / EHR: How do we integrate to hospitals, clinics, labs, and imaging centers? What is the best approach?
  • Read a best practices white paper entitled What Is Your EMR Connectivity Strategy? Defining the Best Attributes to Approaching a Connected Physician Community.
• Continuity of Care Record (CCR) and Continuity of Care Document (CCD): How do these new standards impact EMR integration efforts?
  • Read blog posts on CCR, CDA, CCD, or just search our blog site.
• For vendors, buy or build a healthcare interface solution? There is so much flexibility with the “healthcare standards” so how do we focus, adapt, or handle integration?
  • Answer five questions outlined in a white paper entitled Before You Build a Healthcare Communication Subsystem…
• Simplicity, speed of healthcare interfacing: How can we build healthcare interfaces simply with limited or hard-to-find resources and build them quickly?
  • Review solutions available to speed the healthcare interfacing process.

The themes that you heard or championed may be different. Please feel free to post your insights as a comment. We welcome the interaction.

We found the dialogue at HIMSS extremely valuable. The important element now is to do something with what each of us learned and apply it in our initiatives. Next year, we can revisit how much progress was made.

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.

HL7’s Clinical Document Architecture (CDA) stores or moves clinical documents between medical systems. Documents are things like discharge summaries, progress notes, history and physical reports, prior lab results, etc. The CDA uses XML for encoding of the documents and breaks down the document in generic, unnamed, and non-templated sections.

HL7’s CDA defines a very generic structure for delivering “any document” between systems. What is missing in the CDA standard proper is a listing of the sections of that document. That is, a template of the expected sections that will appear in a given type of document. For example, on a history and physical document, sections could be named Current Medications, Prior Immunizations, Social History, etc.

Ignoring the political or technical motivation, an independent group at the ASTM was formed and worked to define an XML standard for moving documents between systems. Initially, this standard was unrelated to HL7’s CDA standard. It is fair to say the standards competed for mind share and each expressed a different integration philosophy.

In later efforts, the two standards groups agreed to effectively make the standards compatible with each other. The Memorandum of Understanding (MOU) between HL7 and ASTM says that they will “harmonize” the two competing standards. That’s a fancy way of saying they will play nicely.

In short, although not 100% technically correct, in training I like to describe the CCR as a specialization of the CDA. That is, the CCR provides a template of the expected sections that will be provided in CDA format. This CCR “content profile” is a tightly controlled list of document sections answering the “What major bits of data will be sent?” question. The CDA, then, is the structure of how the document will be formatted in XML.

There is a good overview of CDA and CCR over at the American Academy of Family Physicians web site.

There are also several related postings on this blog site:

1. What is the Relationship Between the Continuity of Care Record (CCR) and HL7 2.X Messaging?
2. What is the Continuity of Care Record (CCR)?