NeoTool — Singular Focus, Healthcare Integrated

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.

Moving dates and times between systems via HL7 has two primary challenges:

1. Clock skew/drift — the systems don’t agree on the definition of “now”
2. Time zones — the systems differ in their offset from UTC/GMT

While both problems are easy to understand, the two challenges are solved in very different ways. Here is a summary of each problem:

• Clock Skew or Clock Drift: Systems exchanging data “almost agree” on the current date and time — but not quite. For example, the RIS system thinks it is 4:15pm while the registration system thinks it is 4:17pm.
• Time Zone: The receiver of a message needs to know if the dates and times in the message are using the same time zone as the receiver or a different one. e.g., a radiology clinic based in Tucson receives an order from a referring physician in California. The time zone on the message says the order was generated at “8:15am.” The clinic needs to know if the time is California time or Arizona time. The answer is, “It depends!” The challenge is that depending on the time of year, Arizona and California share a common time zone and at other times they do not.

The Clock drift problems cause issues in annoying, silly ways — i.e., actual events that are happening in the real world appear to be impossible based on the disagreement about the current time. e.g., the RIS system thinks it is 4:15pm while the registration system thinks it is 4:17pm. An HL7 ADT admission message is generated recording the date and time of admission is “4:17pm”. Within seconds the RIS receives the message and claims that this date is “in the future” so it does not process the message correctly.

The solution to clock drift is twofold:

1. Attempt to synchronize clocks to one true time or a shared view of “correct time.” Many operating systems (including Windows) can automatically adjust the system clock based on a reference to a known, good time.
2. Alternatively, there can be a shared, collective view of time using something like the Network Time Protocol (NTP). Ultimately the OS can maintain the clocks within a few milliseconds. Sadly, many Hospital IT shops do not use a system to synchronize times.

The solution to the time zone problem is simple: All systems should send time zone along with every date and time. Sadly most HL7 interfaces do not include the time zone. This issue is covered in detail in another posting.

Both HL7 V2.x and V3.x support complex date structures. In the real world most V2.x messages are encoded using the local time on the system that generates the message. In addition, many interfaces do not support the concept or use of time zone.

This can be a big challenge when building interfaces and often site-to-site negotiation is required should the data moving across the interface need interpretation in another facility in a different time zone.

Said another way, historically HL7 messages were “always local” within a hospital or clinic. As the scope of using these messages pushes to regional or national level, the time zone is much more critical. In addition, the challenge of time zones directly applies even at the local level when daylight savings time kicks in and out.

As noted in chapter two of the HL7 specification, the time zone of the sender “should” be sent as an offset from the coordinated universal time (UTC) (previously known as Greenwich Mean Time or GMT). The problem is that the time zone specification is optional in V2.x — it “should be sent” but is “not required.”

This means that we need some general guidance on how to interpret an unadorned time. The rule proposed in the HL7 standard is that when the time zone is not present in a particular field but is included as part of the date/time field in the MSH segment, the MSH value will be used as the default time zone. Otherwise, the time is understood to refer to the local time of the sender.

In the real world most HL7 2.X interfaces

1. Assume that “all dates and times” are local to the sender
2. Never apply the MSH time zone to other, non-qualified times in the message
3. Don’t even support specification of time zones on any dates/times.

Ultimately the conversion of a time to a different time zone is almost always the responsibility of the receiver.

HL7 V3 has an almost obscene number of words regarding dates and times. Ultimately, the typical use for time stamps is summed up very nicely:

The value of a point in time is represented using the ISO 8601 compliant form traditionally in use with HL7. This is the form that has no decorating dashes, colons and no “T” between the date and time. In short, the syntax is “YYYYMMDDHHMMSS.UUUU[+|-ZZzz]” where digits can be omitted from the right side to express less precision. Common forms are “YYYYMMDD” and “YYYYMMDDHHMM”, but the ability to truncate on the right side is not limited to these two variants.

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.