NeoTool — Singular Focus, Healthcare Integrated

Any “feed”, whether an ADT feed, ORU feed or ORM feed, is basically a streamlined way of getting messages. In the HL7 standards world, ADT, ORU (order messages) and ORM (results messages) are the most common HL7 messages. Of those three, ADT messages are the most commonly used.

ADT stand for “admissions, discharges, and transfers”. It basically means demographics; anytime you think of ADTs, think demographics: the patient’s name, the patient’s location in the hospital, his or her address, phone number, gender, etc.

There are many different types of ADT message types, such as:

• Registering a patient
• Discharging a patient
• Merging patient files to avoid duplication

An ADT feed is one way an application or a provider can get all that information from a clinic or hospital information system (HIS). With the constant updating of a client, customer or patient’s data, ADTs comprise the most HL7 messaging traffic. Change of address, addition of a middle name, and addition of next of kin are all examples of the type of data updates that make up ADT messages. Upon updating, this clinical data will then flow out to different places such as outpatient clinics or laboratories, dependent on who needs that information in their database.

Typically, a hospital registration database will have the master of the patient data and information. Each time patient information is updated, the updates will be pushed out in the form of an ADT message to the appropriate applications in facilities such as labs or clinics.

ADT feeds are usually received through either an interface engine or direct (point-to-point) interface.

In the case of an interface engine, clinical data can be provided to a variety of places. An export can be set up so there can be a one-on-one connection where, for example, a hospital registration system can establish a connection to a lab outside of the hospital. “Data dumps” are also possible, where one end of the application has all the files and the other doesn’t and through the connection, the patient data can all be transferred.

In summary, ADT feeds are the most common and high volume feed used. The updating of patient information eclipses the volume of order and result feeds. Having up-to-date patient information, though, is a critical component in streamlining and improving the continuity of patient care.

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.

HL7 Standards Update. HL7 2.X continues to march forward with new releases. HL7 2.6 is done (just published this week) and proposals for 2.7 have closed — the first ballot for HL7 2.7 will be in May 2008. From a practical perspective, this means that 2.7 will hit the streets sometime in late 2009.

Most users of HL7 2.X don’t pay attention to the newer releases of HL7 (both HL7 2.X and 3.X) because these current users are building interfaces between existing applications. These applications typically have “more-or-less 2.3″ interfaces and, broadly, those interfaces are “good enough” for most users. There is a comparatively small group that helps create new releases of HL7 or that has an opportunity to improve a vendor’s interface by upgrading to a new release of the HL7 Standard.

It is always interesting to see how the HL7 community continues to push HL7 2.X forward. It is fair to say that HL7 2.6 and, soon, HL7 2.7 are better standards than prior releases. They both have more functionality, better descriptions, and fewer errors.

In a free market, buyers choose (directly or indirectly) the version of HL7 they ask their vendor to create. With time, I hope that many vendors will move to the more-complete standards. In the United States, we must rely on market (buyer’s) pressure to ask purveyors of software to improve the functionality of their interfaces.

This blog post was entered in NEOTOOL’s HL7 Blogging Contest.

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.

HL7 is extensively adopted within the healthcare community. The HL7 standards has been under development since the late 1980s and represents the de facto method of moving clinical healthcare data. To clarify, the term “HL7″ can mean many different things based on who asks the question. However, when most people say “HL7″ they mean the “HL7 2.X messaging standard.” A much smaller number of people mean HL7 3.X, CCOW, EHR, CCD, CCR, CDA, etc.

If we use the common definition of HL7 (HL7 2.X), it is fair to say that most hospital-based clinical software applications support HL7. “Support” in this context means that they can send or receive a subset of the HL7 2.X messages. Specifically, a typical software application will use between five and twenty HL7 triggers (messages) out of a total set of 300 or so provided in the full standard. So, take “applications support HL7″ with a grain of salt in all cases.

If we expand the scope to “all healthcare software,” the adoption of HL7 drops off and becomes spotty based on the needs of the facility. For example, an EMR application running in a five physician office might use HL7 for lab results (ORU) but not for demographics (ADT), orders (ORM), or scheduling (SIU) messages at all.

HL7 2.X is an implementation-driven “standard.” This means it has been pieced together over the last 20 years and works “most of the time” for “most of the people.” It is fair to call it a “standard” in quotes because the implicit goal of HL7 is to reflect the specialization of clinical settings. As I teach in HL7 training class, clinical settings demand specialization of applications, data models, and work flows. The HL7 standards cannot fix this need for specialization and, therefore, HL7 is purposefully-flexible in many areas.

On the other hand, HL7 3.X is model-driven. From a practical standpoint, it means that some of the brightest minds in healthcare informatics have spent ten years developing a rather clever model for the representation of clinical data. Some argue the model is either too clever or not clever enough. Regardless, so far, the depth of adoption for HL7 3.X has not come close to HL7 2.X.

Specifically, within the United States, the use of HL7 3.X is painfully small if we measure use of 3.X by real production interfaces moving real “average” healthcare data in real “average” facilities.

In short, the industry is caught with a huge adoption problem on five fronts with respect to HL7 2.X / 3.X in general and “standard interfacing” in particular:

1. There is no such thing as a “standard healthcare workflow” or “standard healthcare data model used to store real data in a real database.” If you spread the issue across different healthcare settings, the specialization so broad it is virtually impossible to standardize anything. If you take political or geographic settings into consideration, it is impossible to build one useful standard — even a very broad standard — that works just one way.
2. In HL7 training class, I twist the meaning of Metcalfe’s law and apply it to standards. Specifically, the value of a standard like HL7 is proportional to the square of the number of users of the standard  (n^2). This means that the value of an installed based (HL7 2.X) is much higher as more users adopt the installed standard. Regardless of clever factor, competing standards (in or out of the same family) have far less value.
3. HL7 2.X is the workhorse that gets the job done while HL7 3.X is new, better, and — when compared with 2.X — very hard for the average user to understand. An unimplemented or under-implemented standard has little value — recall the(n^2) problem.
4. Both HL7 2.X and 3.X were developed with a depth of complexity that meets acute care (hospital) requirements. This means that smaller, simpler environments have a complex “non-standard standard” to use even if they just want “a little interfacing.” Standards profiling helps resolve this issue.
5. Often clinical software vendors consider integration functionality late in the product lifecycle and often do not consider it strategic to sales or deployments. This means that the depth of support for HL7 is sometimes shallow and the interfaces are fragile.

In summary, HL7 is very widely used within healthcare. Each interface is slightly-to-very different based on the trading partners and healthcare setting. HL7 can not totally standardize clinical data models or workflow because every facility is special or different in some boring or very critical way.

HL7 is the best standard we have in healthcare — best in the sense that many users move real messages between real applications every day. Ultimately, HL7 makes building interfaces vastly easier than using custom formats like a custom CSV, XML, or flat files.

Some of these topics are covered in more depth in a 14 page whitepaper entitled, The HL7 Evolution (PDF).

A healthcare environment typically has multiple systems that need to be interfaced. From the HIS to the RIS to the LIS, these systems all need to be able to exchange data via HL7 messaging. While most of these systems today have an HL7 interface, these interfaces are not compatible out of the box. There is no plug-and-play interfacing in the world of healthcare integration today.

When one of these systems needs to send data to another, there usually will need to be some modifications to the message structure that is sent. This is because these applications all speak a ‘custom’ version of the HL7 standards. In order to successfully interface the applications, one of two things has to happen.

1. One or both vendors will need to make customizations to their applications and/or their interfaces to be able to send and receive the other vendor’s custom version of HL7. This is a point-to-point approach to interfacing.
2. Another approach is to take the data that is coming from an application, modify the data in an interface engine, and then send the resulting message structure to the receiving application in their custom version of HL7. With this approach, no modifications are required by the applications.

In either case, outlined below are the requirements in three key categories: must have, should have, and nice to have.

Must have:

• An export from the sending application
• A method for moving data
• An import into the receiving application

Should have:

• A method to queue messages
• A method for logging messages

Nice to have:

• Resend capability
• Monitoring and alerting

Additional resources:

• Read include a white paper entitled What Is Your Healthcare Interface Method?
• Watch a 15-minute recorded webinar on Point-to-Point Interfaces vs. Interface Engine – What Do You Really Get with Each?

This week I’m at the May 2007 HL7 Working Group Meeting in Cologne, Germany. Although I travel extensively, almost all my travel is typically within the United States. Thus, dropping into a country with a culture and environment so different than my own has me deeply thinking about the international community of “real” users of HL7 for healthcare integration. I ran an informal survey to see if my thoughts about HL7’s use would be in line with other HL7 experts.

Background: As you probably know, HL7 is a family of international standards that are endorsed by or used within many countries. The HL7 standards — be them older V2.X messaging, new 3.X messaging, CDA/CCR/CDA, etc — reflect input from many realms. This internationalization of HL7 has been on-going since the early 2000s.

The premise: Despite the huge push to internationalize the standard, the total HL7 uptake (as measured by live use of a standard) outside the United States is still small when compared with total deployments within the US.

The motivation: This is an interesting topic for many reasons and was driven by a committee meeting where we were talking about HL7’s market position and brand.

The non-scientific survey: Over the course of the last few days, I’ve talked with about ten “Grand HL7 Gurus” about the topic of where HL7 is really used.

The question:

Assume that an ‘HL7 user’ is a hospital, clinic, RHIO, provincial health board, etc. that makes use of any HL7 standard. Include all HL7 2.X and 3.X messaging, CDA, CDD, Arden Syntax, etc. Estimate the percentage of ‘HL7 users’ in the world that are within the US.

The reaction: Some Grand Gurus asked for clarification such as, “How do you count a user? Per site? Per interface? Per install? Per clinician?” In all cases of clarification, I simply said that the Guru should make some assumptions on their counting and then should give me number. I did not want to constrain the Guru’s thinking because, well, they are Gurus.

The results:

In short, the general feeling is that 90% or more of HL7’s users are still within the United States. Interestingly, the lowest estimate I got from anyone was 80%; the highest was 98%.

With Gurus from across the globe generally agreeing that “most” of the HL7 users are in the US, it is deeply interesting to think about adoption rates and what this same survey will show in another five years. I think the non-US user count is growing much more quickly than even the fast-paced growth in the US. Thus, I posit that the non-US users will be on par with US users “soon”.

The interesting question will be what standard they will be using — most of HL7’s work in the last five years has been on the RIM, HL7 3.X, and CDA. In the US, most “HL7 users” are really HL7 2.X messaging users.

HL7 typically involves moving message data between two or more software applications within a clinical setting. Without a standard way of defining the types of data that can be sent, messaging is very difficult. Therefore, HL7 outlines the data model and workflows that are broadly supported.

What is HL7? Radiology Today published a good article that provides an HL7 tutorial. In addition, on this web site, you can read a 14-page white paper that outlines HL7 standards version 2 and HL7 version 3 — including a background and tutorial on HL7.