I read with interest the blogs by Anderegg and Woo about the need for interoperability and standards to permit better specialty pharmacy operations. I agree wholeheartedly about the need to have standards, and to support the standards that we have. While their emphasis appears primarily to be on clinical data, I would like to advocate for better standardization of operational data. Indeed, as I will further explain, it is my assertion that we as a profession have not exactly stepped up to the plate to advocate for our operational needs in the HL7 arena.
A very brief HL7 tutorial for those who may see it as voodoo:
HL7 is a syntax standard; it describes a message structure to communicate healthcare events, and a series of sentence structures by which two systems can communicate information. Each "sentence" in a message is a single line of text (called a "segment") that contains conceptually related data.
Each segment starts with a three-character "name" that identifies what the segment is and what conceptual data that segment contains (as defined by the HL7 standard). For example, a PID segment describes a patient, while a PV1 segment describes an encounter, and an ORC segment describes a common patient-care order. There are lots and lots of segments (last I looked, the HL7 standard fills more than 8 binders) so, in theory, the HL7 standard provides us with an exceptionally large tool set by which we could communicate our operational data.
Well... not really....
You see, the HL7 standard describes something called a "Z-segment", which is a custom segment invented by two interface partners to carry information that the HL7 standard doesn't support. The minute that an HL7 message set contains a Z-segment, it is no longer standard; it has become proprietary. And you don't exactly have to look far in pharmacy operational transactions to find Z-segments. Indeed, when I was chair of the SOPIT executive committee, one of the pain points that people expressed was that any time you changed HIS vendors or ADC vendors, you had to completely redo your interface (at additional cost in both time and money) and the reason primarily is the proliferation of Z-segments.
There is a Master File Notification (MFN) message set in HL7 that is intended to describe file contents, but you need a Z-segment to contain the richness of information we need about a formulary item. The MFN message has a number of variants including (in one of the later versions) the ability to generally describe an inventory item, but it still lacks the detail needed to describe a medication item.
There are order messages that we conscript to describe individual orders, but those require Z-segments to describe individual doses and their timing such as would be needed for an IV workflow system.
There is a Detailed Financial Transaction message (DFT) that is intended to drop a charge for a patient that can be used to describe a dispense from an ADC to a patient, but it lacks the richness to describe the detail about that dispense, and so requires the use of a Z-segment to describe that richness. There are not good messages to describe other operational data about ADC's (such as loads, unloads, stock-outs, discrepancies, witnessing, etc.) so Z-segments are required for these purposes.
So as long as we have no standard way in HL7 to describe the operations of these systems, we are going to have to have Z-segments, which means that our operational messaging is proprietary to specific vendors of ADC's, IV workflow systems, and HIS/PIS products. It appears that we are well beyond the phase where these could be considered passing fancies. So I propose that we need to get the players to the table, describe message sets that could standardize the operational data that we need, and get those standards built into the HL7 standard in a version of the standard that is commonly in use.
Or am I completely nuts, and have we become so accustomed to the current state of affairs that it is no longer a problem that needs to be solved?
What do you think?
Dennis A. Tribble, Pharm.D., FASHP
Ormond Beach, FL
DATdoc@aol.com
The opinions expressed herein are my own, and not necessarily those of my employer or of ASHP