NeoTool — Singular Focus, Healthcare Integrated

Posted in HL7 Standard, HL7 Integration

The HL7 standard defines the maximum field length and field cardinality in an effort to help developers define their clinical databases and interfacing requirements. The field length has always been the “recommended maximum” and, frankly, the idea has historically been pretty much ignored. The field cardinality provides a minimum and maximum number of times that a value should be sent on the HL7 2.X interface and, in general, is more strictly followed by applications.

In short, if HL7 messages are to be exchanged, both the sender and receiver must agree what elements will be sent (field cardinality) and how long each element will be (field or component length). These two terms are critical to understanding how data will move within an integration project:

Cardinality: Sometimes an element will be considered required (minimum cardinality of one) and sometimes optional (minimum cardinality of zero). When you add the complexity of repeating elements (maximum cardinality of n), you can provide for all element constraints - e.g., “optional and repeating element” (such as patient alias) becomes a minimum of zero and a maximum of n (0 to n or 0:n).

Length: Both ends of an interface ultimately need to agree on the lengths of the elements that are to be exchanged. For example, assume the sender delivers a patient name of “Ivanov Ivan Ivanovich-Novak” and the receiver supports 10 characters for first name, a single character for middle name, and 12 characters for the last name. The receiver will see a patient named “Ivanov I Ivanovich-No” - to a human, it looks almost the same. But to a computer, it could be very different.

The challenge with HL7 integration is that often clinical software vendors (or ISVs) define their database structures before they adopt HL7. The story often goes something like this:

We’ve got 352 customers running version 4.2 of our product and in version 5.0 we want to add a little HL7 interfacing to populate the patient roster. This will allow our larger customers to avoid duplicate entry of patient demographics in our application. Thus, we need an inbound ADT (admit, discharge, transfer) interface. The application database cannot drastically change while adding HL7 functionality. The application developers need to add an HL7 subsystem to the application and then reconcile the differences between our database and HL7’s data model.

In order to make the process of adopting HL7 easier, often developers use an HL7 toolkit. Using such an interface engine makes the HL7 communications, parsing, interfacing monitoring, etc. problems go away. The challenge left is the data model reconciliation. Ultimately what the late adoption of HL7 in a product’s life cycle means is that the choices made early in an application development live on for many years. For example, initial development efforts often build databases that look like this:

Patient Table
Column 1: Last name, required, string type, 50 characters long
Column 2: First name, optional, string type, 30 characters long
Column 3: Middle initial, optional, character type, 1 character long
Column 4: Date of birth, required, native date type
Column 5: Gender, optional, native integer (0 = male, 1 = female, 2 = unknown/other)
…

The point is that developers think about data elements one at a time. In the HL7 standard, we call these values components. If you look at the HL7 standard, there is a PID segment which contains a fifth field (PID-5) that field uses the XPN (eXtended Person Name) data type. That data type has changed substantially over time.

Prior to HL7 2.3.1, the XPN data type (back then often called just the PN) looked like this:

1. family name
2. given name
3. middle initial or name
4. suffix (e.g., JR or III)
5. prefix (e.g., DR)
6. degree (e.g., MD)

This means that the widely-adopted versions of the HL7 standard allow six components in a name. Note that the example legacy database design discussed above only supports three of these elements (last, first, middle.) Also note that the database has a single character for “middle initial” while HL7 allows for the squishy idea of “middle initial or name.” Remember that the product management team said, “When adding HL7 to version 5.0, you can’t make major database changes.” Thus the reconciliation is pretty easy: “We’ll support what we can with the existing database and ignore the rest of HL7.”

A related HL7 integration problem occurs on two fronts: Note the database requires last name and date of birth. HL7 just says that the name is required, but it does not specify what pieces of the name must be sent. HL7 also marks the date of birth (PID-8) as optional. So the inbound interface must do something if the remote application sends a message to create a new patient but leaves out either the last name or DOB.

Ultimately, this is why HL7 allows a development team substantial latitude to include or exclude elements in the interface. In the on-going example, the vendor will probably make some note in their HL7 interface specification like this:

• Only the first three components of the PID-5 field are supported (i.e., prefixes like “Mr.” or a suffixes like “Sr.” will be dropped.)
• The length restrictions are:
  • First name 30 characters
  • Last name 50 characters
  • Middle name 1 character
• If the message does not contain a patient last name, the value Unknown will be defaulted into the patient’s record.

In future posts, I will address the issue of component-level cardinality and HL7’s new direction in HL7 2.7 regarding field and component lengths.

Last 5 posts by Dave Shaver

• HL7 Working Group Meeting Includes Strong International Attendance - September 16th, 2008
• Integrating EMRs with Reference Labs - September 3rd, 2008
• Massachusetts Hospitals Must Have CPOE by 2012 and CCHIT-Certified EHRs by 2015 - August 13th, 2008
• HL7 Dates and Times - July 25th, 2008
• HL7 Time Zone Qualification - July 25th, 2008