NeoTool — Singular Focus, Healthcare Integrated

The Continuity of Care Document (CCD) defines a detailed set of constraints, or templates, for CDA elements. Each template may have further supporting templates as required. The data contained in each of the templates is set by CCR.

Below is an overview of the templates (excludes supporting templates) and how they are used.

Header
Defines the type of document being created, who the document is regarding (patient, physician, author) and how the document relates to other existing documents (if applicable).

Purpose
States the reason the document was generated, but only if a specific purpose is known (i.e., a referral, transfer, or by request of the patient).

Problems
Provides a list of relevant clinical problems, both current and historical, that are present for the patient at the time the document was created.

Procedures
Provides a list of all relevant and notable procedures or treatments, both current and historical, for the patient.

Family history
Gives relevant family health information that may have an impact on the patient’s healthcare risk profile.

Social history
Describes the patient’s lifestyle, occupation, and environmental health risks plus patient demographics such as marital status, ethnicity and religion.

Payers
Provides payment and insurance data pertinent to billing and collection, plus any authorization information that might be required.

Advance directives
Includes information about wills, healthcare proxies and resuscitation wishes, including both patient instructions and references to external documents.

Alerts
Provides a list of allergies and adverse reactions that are relevant for current medical treatment.

Medications
Provides a list of current medications and relevant historical medication usage.

Immunizations
Gives information the patient’s current immunization status plus pertinent historical information about past immunizations.

Medical equipment
Provides a list of medical equipment and any implanted or external devices relevant to patient treatment.

Vital signs
Details information about vital signs for the time period including at a minimum the most recent vital signs, trends over time, and a baseline.

Functional stats
Details information about what is normal for the patient, deviations from the norm (both positive and negative) and extensive examples.

Results
Lists lab and procedure results, and at a minimum lists abnormal results or trends for the time period.

Encounters
Details relevant past healthcare encounters including the activity and location.

Plan of care
Lists active, incomplete or pending activities for the patient that are relevant for ongoing care - including orders, appointments, procedures, referrals and services.

For additional information on getting started with CCD, please read the post on the quick start guide provided by EHRVA.

At last week’s HL7 Working Group meeting, it became clear that US adoption of the HL7 Version 3 Standard is still years away, with one lone exception:  Clinical Document Architecture (CDA). 

It seems as though implementation of the larger standard is still seen as a herculean task, requiring not just a rework of HL7 2.X import/export modules but also a potential overhaul of applications’ underlying database schema and object model. But the Structured Documents committee (SDTC) has done a nice job of achieving one of its primary design principles concerning HL7 CDA – minimizing technical barriers to implementation. That mantra has no doubt helped the SDTC create a standard that comprises the ‘piece’ of HL7 V3 that American vendors are willing to incorporate in the not-so-distant future.

Given the lack of a national mandate to move to HL7 Standard V3 that exists in other countries, as well as the lack of demand for V3 in the US marketplace, CDA could be the much needed beachhead for the standard in this country.  As more and more vendors implement CDA and get a small taste of the V3 methodology and associated benefits, the more adventurous (and deep-pocketed) software providers will tip-toe further into the newer HL7 standard.

Until then, the burning question remains:  which comes first – provider demand for or vendor support of V3?

Yesterday I wrote an article about formatted documents and HL7 2.X. The focus of that posting was to suggest that in the real world HL7 does not control the formatting of a document on a receiving system.

René Spronk wrote an interesting reply that I did not want to get lost:

From the blog it isn’t clear whether you’d like HL7 to address the formatting of documents or not. The fact that the FT datatype is rarely implemented seems to suggest that there is no underlying requirement. Otherwise, implementers would use it and request enhancement of those features (maybe even to make them mandatory) as part of the development standard of the v2.x standard.

The CDA standard (HL7 v3) contains markup with a functionality akin to FT. It focuses on medical content, not on font-size. CDA is usually displayed using a style-sheet - albeit one that the receiver chooses, which may be a different one than was used by the document creator.

In case of CDA HL7 leaves it up to the communicating parties to “contractually” agree to use a specific style-sheet. Whether or not such agreements are in place depends on the jurisdiction where CDA is used.

Are there uses cases and jurisdictions where it makes sense to give more control to the sender of how the receiver should view the data? Yes.

One of the enhancement requests for the next release of CDA (CDA R3) is to support a much larger set of XHTML tags for formatting. This is however a balancing act - I wouldn’t want to support all of XHTML (including scripting stuff) in a CDA. The more formatting we introduce in a CDA, the more we’ll be moving away from the actual content, and the more things will be focused on formatting. I’m not sure if we should go there…

As always, René made some great points; thanks for your comments. I think that users of HL7 (either 2.X or 3.0 family) wish for many things — mostly they wish that the standard will make their lives easier. Often they look to HL7 to “force” an application to do something that “seems obvious” to them and their world. In terms of document formats from the perspective of a sending application, they wish that their “pretty report” would be displayed correctly by the receiver.

Once a week I hear someone wish they could force that mainframe or mumps application (which was coded in the early 1980s) to take an HTML or PDF document.

“Why can’t it display bold text? Our paragraphs are not wrapping correctly! The reason people use our service is that we produce these great reports. It is one of our key selling features! We just hate to fax or email them. Can’t HL7 deliver the same thing? Can’t I force that receiving HIS/CDR/EMR at my customer site to take this document via an interface? What does HL7 say about that? Can’t HL7 make the receiver display this correctly? I wish this was easier!”

To answer the questions above, read my posting. In short, HL7 does not force a receiver to format a document in a particular manner.

As noted in René’s comment, HL7’s CDA standard is mostly focused on the content and coding of the information — the display or rendering was, IMO, a secondary aspect. In fact, one of the key points of CDA is that the same document can be rendered on many devices — cell phone, printer, HTML, thick client, thin client, PDF, etc. As noted by René, the receiver’s style-sheet controls the final display.

IMO, the major display advantage of CDA is that it provides a much more structured starting point. In theory, we no longer have to worry about boring stuff like word wrapping or section headers — these display features “come for free” with the style-sheet used by the receiver.

Hopefully as a community we will not lose track of the fact that what CDA is really about is coded documents — the “easier display” is just a bonus.

It is interesting, however, to note that often what real world users of either HL7 2.X or CDA want is a mechanism to get a document “nicely displayed” on the receiving system. Sure, the informatics geeks can talk about the coding/format of the document and how many places we have clever OIDS, but ultimately it seems that much of healthcare is still about paper documents. Kudos to the CDA visionaries who seemed to get this up front — allow for lots of coding but also allow for simple blobs of text split into sections.

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!”

For those who have been involved with the HL7 Standards over these past decade, there has been a slow evolution to expand the standards, change the approach (i.e., HL7 V2 to HL7 V3), and include clinical documentation. Healthcare integration initiatives are benefiting from the changes, but confusion rises as to the differences and the growing complexity.

One question that arises is:  what is the difference between HL7 messages and HL7 documents? Outlined below is quick review of differences.

HL7 Messages:  HL7 messaging is usually a real-time flow of patient and clinical information. They convey current information about a patient, including updates to admissions or discharges (ADT), orders for tests (ORM), and test results (ORU). The more current the data, the more relevant it is in the delivery of patient care. HL7 messaging impacts the ongoing process of delivering care by delivering the most current, updated patient information available.

HL7 Documents:  HL7 documents are static - accurate given the point-in-time in which the information was captured. HL7 documents contain important information, but it is a snapshot. The documents are useful in providing relevant information in referrals to other physicians or healthcare organizations. Accordingly, it provides a starting point for the next step in patient care.

The differences in HL7 messages and HL7 documents can be summarized as active vs. passive information. HL7 messages are continuously delivered as status changes or new information is obtained. HL7 documents contain information at one specific point in time. Both are critical, however, especially when delivering connectivity or integration to Electronic Medical Record (EMR) applications in various healthcare provider offices.

How do the healthcare standards apply? In HL7 messaging, HL7 V2.X and HL7 V3 apply. In HL7 documents, HL7 Clinical Document Architecture (CDA) and ASTM Continuity of Care Record (CCR) standards apply. Both approaches deliver value to healthcare integration initiatives.

In the HL7 Standard, there are two versions that people think of - Version 2 (V2) and Version 3 (V3). Outlined below are some of the differences between V2 and V3.

HL7 V2

• Not “Plug and Play” - it provides 80 percent of the interface and a framework to negotiate the remaining 20 percent on an interface-by-interface basis
• Historically built in an ad hoc way because no other standard existed at the time
• Generally provides compatibility between 2.X versions
• Messaging-based standard built upon pipe and hat encoding
• In the U.S., V2 is what most people think of when people say “HL7″

HL7 V3

• Approaching “Plug and Play” - less of a “framework for negotiation”
• Many decades of effort over ten year period reflecting “best and brightest” thinking
• NOT backward compatible with V2
• Model-based standard built upon Reference Information Model (RIM) provides consistency across entire standard
• In the U.S., when Clinical Document Architecture (CDA) is what most people in the U.S. think of when people say “HL7 V3″

Learn more about preparing for HL7 V3 or more about the HL7 standards, including HL7 V3, through an in-depth white paper entitled The Evolution of HL7 (PDF).

For a 15-minute recorded presentation on HL7 V3, please click here.

While HL7 V3 is still in the “early adopter” phase, there are now over 100 registered projects in progress worldwide involving V3 – the overwhelming majority being outside the United States. Some important points to keep in mind with this HL7 standard still in an early adopter phase:

• Most deployments turn out to be rather custom based on realm-specific changes and that the current V3 standard is used as a starting point for a project – rather than the ending point.
• V3 appears to be morphing even more into a reference model and less of a messaging standard.
• Things are still in a relative state of flux as far as how V3 will be implemented by entities as evidenced with the National Health Service’s shift in the UK from using “V3 messaging” to “V3 CDA” for the Spine.

Keeping the above caveats in mind, it is still a good idea to prepare for V3 by acquainting yourself with some fundamentals.

With V3 being a model-driven standard, a logical starting point for preparation means starting with the information model upon which all V3 standards are based on – the Reference Information Model (RIM). This means that both V3 HL7 messaging standards (e.g., Inpatient Encounter, Ambulatory Encounter, etc.) and V3 Documents standards (e.g., CDA, CCD, etc.) are all based on the RIM.

As a side note, HL7 users in the United States generally think “HL7″ means HL7 2.X messaging standard. Thus, when they think V3, they think about V3 messages replacing the V2 messages. While this is technically possible, market forces are not likely to make the leap to V3 for HL7 messaging anytime soon. If you work for a healthcare provider in the United States, outside of Clinical Document Architecture (CDA), there appears to be little movement towards V3. Some of these topics on the HL7 standards - V2 and V3 - are covered in more depth in a 14-page white paper entitled, The HL7 Evolution (PDF).

With this understanding, we can now get back to V3 and the RIM. With the RIM being an object-oriented methodology implemented via XML, a good starting point to understanding it is to familiarize yourself with the six core classes of the RIM:

1. Act - represents the actions that are executed and must be documented as health care is managed and provided
2. Participation - expresses the context for an act in terms such as who performed it, for whom it was done, where it was done, etc.
3. Entity - represents the physical things and beings that are of interest to, and take part in health care
4. Role - establishes the roles that entities play as they participate in health care acts
5. ActRelationship - represents the binding of one act to another, such as the relationship between an order for an observation and the observation event as it occurs
6. RoleLink - represents relationships between individual roles

With a firm understanding of the above six core classes and their associated attributes (see the latest HL7 Version 3 Normative Edition for details on associated attributes), you should be better prepared to more quickly analyze and implement your first HL7 Standard V3 interface, regardless of whether it is a V3 message or V3 document.

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.

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.