Archive for the ‘CDA’ Category

CDA stands for Clinical Document Architecture, and it is under the HL7 umbrella of healthcare standards.

What is HL7 CDA? It is a healthcare standard which uses XML for encoding of documents and breaks down the document in generic, unnamed, and non-templated sections. Documents can include discharge summaries, progress notes, history and physical reports, prior lab results, etc. HL7’s CDA defines a very generic structure for delivering “any document” between systems. CDA was previously known as the Patient Record Architecture (PRA).

CDA is complex, and HL7 is now working on ways to simplify it. The simplification project is called Green CDA.

According to Keith W. Boone, “Green CDA isn’t a solution that’s just around the corner.  Gestation of a new standard isn’t sped up by setting unrealistic goals…” Read his blog post called Birthing of a New Standard to gain more insight on the research underway to simplify CDA.

Even though Green CDA sounds distant in being achieved, the initial comments are positive. In the Life as a Healthcare CIO blog, John D. Halamka MD describes Green CDA in a recent post entitled Introducing the Green CDA: “It’s a streamlined, human readable and computable lighter version of CDA that includes just the data and metadata necessary to do the job of representing a clinical summary….  When I first saw the Green CDA XML, I was so impressed that I asked the question – why not use Green CDA as CDA…”

Green CDA will be an interesting project to watch and understand, and it definitely seems to be headed in the right direction. Simplified approaches to working with CDA will facilitate greater adoption of the standard and also the realization of real connected and interoperable health care.

Prior to the approval of the Continuity of Care Document (CCD) as an ANSI Standard in 2007, electronic clinical document exchange could utilize one of two formats: HL7 Clinical Document Architecture (CDA) or ASTM Continuity of Care Record (CCR). In an effort to combine the two closely related formats, the Continuity of Care Document was created.

CCD harmonizes the two separate standards by using CCR within the broader context of CDA. It shares summary information about the patient in an easy-to-read format, using CCD templates to constrain the data. The information can be read by the human eye or processed by a machine (such as an EMR system), and can be sent electronically or manually carried by the patient.

CCD is widely compatible with new and existing technology/standards because it is based on HL7 CDA – a RIM-based specification. It can work with existing applications, browsers, EMRs and even legacy systems. Because of its small fixed XML tag set, CCD can be rendered as HTML or PDF, and requires no specialized communication efforts or changes to existing processes.

For patients, this means less loss of meaning and misinterpretation of data by providers. For physicians, this means easier access to vital health information and better patient care.

Moving into the future

New CCHIT certification criteria require all ambulatory and inpatient EHRs to be CCD compatible, making CCD the preferred standard for clinical document exchange as we move forward into the future. The new criteria is also instrumental in encouraging the use of an electronic health record within the healthcare community.

Those implementing CCD will be readily compatible with new technology, while simultaneously opening the doors to greater compatibility and better care for patients.

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.