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.

HIMSS EHRVA developed a Quick Start Guide for implementing the Continuity of Care Document (CCD). HIMSS EHRVA is a trade association of Electronic Health Record (EHR) vendors. Included in the file are two sample CCDs. The guide seems to be a useful resource for implementers of integrated healthcare systems.

A few past posts and insights that you may want to explore:

• What is the CCD?
• EMR Interfacing Best Practices
• Get the Workflow Right First
• Comparing HL7 Messages to HL7 Documents

Please post any experiences that you have in implementing the CCD or using this Quick Start Guide.

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

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.

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.