Monthly Archives: April 2012

Question: Interpreter Needed flag in HL7 v2

We’ve been asked to update a patient’s “Interpreter Needed” flag across HL7 V2.x. I can see the Primary Language field as part of the PID, but cant see any reference to “Interpreter Required” in my reading of the specs. Have you come across this being sent as HL7 in your travels?

Well, no. I’ve seen the field in Patient Admin Systems, but I’ve not seen it in any HL7 message. And as you say, there’s no field for it. I’ve asked around, and no one else has seen it either. I have no idea why. I mean, you could assume that if the patient’s primary language isn’t the local language, an interpreter would be required… or maybe not. Whether you could or not would at least be dependent on local clerical policy. And obviously not in this case, or the question wouldn’t have come up.

So, it’s going to be yet another custom interface negotiation between you and the destination system vendor (or the source system).

In principle, there’s two ways to do this, both equally dubious. The first is simply to add a Z-segment, usually after the PID segment. This would look something like this:


Any random inspector of the message would have no idea what ZPD-1 meant – but you would, and anyone you told. This is actually the correct way, but people really hate Z-Segments because who knows what they mean? (Particularly next year when you’ve moved on, and the hospital loses the documentation).

An alternative is to use OBX. Let’s assume you’re using A01, in version 2.5. It has an OBX segment which can repeat after the PID, and you could add an observation about the patient that they need an interpreter. This wanton abuse of observations is a classic pattern of use of HL7 (both v2 and v3) … anyway, it would look like this:


There’s no boolean data type, so the nominal type is ST. The [code] value is some code that identifies whether an interpreter is required. Since there’s no vaguely appropriate code in loinc, you could make any old code up, which means that the OBX is as uninterpretable as the Z-segment approach, though this does offer the interesting possibilities of bringing other poorly written systems (they abound) down when they try to make sense of you custom observation.

There is a better option though: SNOMED-CT has the term 315594003, which is a clinical finding with the preferred description: Interpreter needed. Frankly, for most systems, this would be no different than an invented code, but it does leave a clear signpost for anyone following later:

 OBX|1|ST|315594003^Interpreter needed^SCT||true

I’d choose the OBX method, simply because there happens to be a good SNOMED-CT code. If there wasn’t…. it’s toss a coin territory.


Kestral Computing P/L: Serious HL7 supporter

Prior to setting up Health Intersections, I used to work for Kestral Computing P/L, the leading provider of Radiology and Pathology Information systems in Australia. A big part of Kestral’s business is Interoperability, which is how I got my first exposure to HL7.

Kestral has been a long term committed supporter of HL7. As well as supporting my attendance and involvement in HL7 for over ten years, Kestral have also sent other staff to US working group meetings as well. My count is 6 people other than me (not including the several that went to the Sydney WGM).

The next meeting is in Vancouver, and Kestral will be sending yet another staff member (Sarah McGree).

Kestral is a serious supporter of interoperability standards – no other Australian company has a record anything like that.

Question: What are the rules around use of SUBJ relationship in CDA?

In the following example from CCD there is an EntryRelationship has a type code of “SUBJ” However the CDA spec says the following which is only valid for OBS to OBS.

From the payers section (entry level template):

<entryRelationship typeCode="REFR">
 <act classCode="ACT" moodCode="EVN">
  <templateId root='2.16.840.1.113883.'/>
  <id root="f4dce790-8328-11db-9fe1-0800200c9a66"/> 
  <code nullFlavor="NA"/>
  <entryRelationship typeCode="SUBJ">
   <procedure classCode="PROC" moodCode="PRMS">
    <code code="73761001" codeSystem="2.16.840.1.113883.6.96" 

The restriction from the CDA spec is (section

SUBJ (has subject) [Observation | RegionOfInterest]
[Observation | ObservationMedia]
Used to relate a source region of interest to a target image, or to relate an observation to its subject observation (for instance, source “moderate severity” has subject target “chest pain”).The ActRelationshipType “has subject” is similar to the ParticipationType “subject”.Entries that primarily operate on physical subjects use the Participation, whereas entries that primarily operate on other entries use the ActRelationship.

Note the all important text at the top of that table, however:

NOTE: The CDA specification permits any CDA entry to relate to any CDA entry using any of the following relationship types. In many cases, this would result in nonsensical relationships. The following table is a guideline for reasonable relationships between CDA entries, and is not a conformance constraint.

So that’s just a guideline. A lot of implementers get caught out by that. Because of the shortness of the allowed list of act relationships, SUBJ and COMP are (ab)used quite a lot. This CCD usage is common.

Further SUBJ seems to be a strange choice of ER type code To me at least) it would seem to be more like a COMP.  What is the purpose of having the procedure nested within an Entity Relationship.  I cannot see what you gain over having the PROC ER directly under the . policy activity.

No, indeed, not in this case. However the key answer is here (from CCD spec):

NOTE: To the extent possible, the conformance statements in this section are isomorphic and compatible with the HL7 Financial Management (FM) domain model. In some cases, CDA R2 lacks class codes or other RIM components used by FM, in which case the closest corresponding CDA R2 representation is used.

The reasoning is not evident either in the CCD examples or the specification, but the full blown model (the claims and billing domain model) contains a richer model where the introduction of the intermediate act makes sense (aligns with a policy statement act, and the procedure is extra to the DMIM).

More generally, SUBJ is used where the extra information is “about” the act, whereas COMP is used when the extra information is “part” of the act. Sometimes, that’s a sensible differentiation, but often, from the perspective of the use case, it’s an arbitrary decision which to use (but note, in this case, that DMIM uses “PERT”, and that would sway me to SUBJ over COMP since I can’t use PERT in CDA R2).

FHIR Licensing Update

I’ve had a number of queries about the status of FHIR licensing. Here’s an update.


HL7 standards are not free for use. In order to use the standards in derived standards research or or production systems, implementers must pay a licensing fee. This can be done by joining HL7, or by purchasing the standards on a commercial basis. Neither option is particularly cheap; it costs a lot of money to produce, publish, and maintain the standards. Note that HL7 is a not-for-profit organization, and no one is drawing profits from selling the standards.

The fact that a licensing cost is required bothers many implementers, especially in countries where governments mandate use of HL7 standards, and the users don’t get to opt-in. HL7 is continually criticized for this, and compared to radically different standards organizations such as W3C, or OMG, which produce specifications that are not “encumbered” by having to pay for their use.

Not surprisingly, HL7 has looked repeatedly at how it converts it’s IP into a revenue stream, but each time, it elects not to change. Fundamentally the problem is that while these other models have been proven to work, no one knows whether they’ll work for HL7, and no one knows how to go about transitioning from where we are.

Hence, HL7 mostly is locked into a encumbrance model, though some newer products are being made available for free.


Though FHIR is built entirely on the strengths of the existing standards HL7 has,in form and implementation it is entirely new. I’ve developed it personally, and while I’ve consulted widely, and there’s been a small team who’ve contributed, the entire content of FHIR is mine (© Health Intersections P/L). I’ve developed it with the express purpose of gifting it to the public domain.

Beyond the general principles of encumbered IP, and the question of why a bunch of volunteers would develop product in order to give it to some other organivation to sell, there’s a practical reason for that: existing HL7 members have spent many millions of dollars on existing HL7 standards. For all their flaws, they’re naturally going to be reluctant to implement new specifications, at least until their utility is well proven in practice. That’s a reasonable position to take. So how is a new specification going to become well proven in practice?

The answer is that the implementation experience is going to have to come from a new set of implementers, outside the HL7 community. And who is going to be doing interoperability in healthcare, who’s not an HL7 member? The answer is mobile apps, a tsunami of healthcare integration already winding up into high gear. These communities need a practical lightweight exchange standard, which is exactly what FHIR is. And if FHIR is going to appeal to them, it at least has to be free for use (it has to be other things too. for instance, I’d like to provide FHIR with an out of the box ObjectiveC reference implementation – I’m looking for volunteers to work on that).

So I’ve made an offer to HL7: I’ll gift FHIR to HL7 if HL7 will make it available to the public for free.

Specifically, we’re talking around something like this:

  • The FHIR IP would remain the property of HL7, along with the right to continue to maintain it
  • The base FHIR standard would be published freely (perhaps at though is also reserved for this purpose)
  • HL7 would grant implementers the right to use the FHIR standard for free, for production/research systems or derived products such as implementation guides
  • HL7 and affiliates (and members?) may develop derived specifications and make these available on a commercial basis. Other parties may not?

The agreement would hold until the first full normative publication of FHIR, after which the impact of this would be reassessed and other models could be considered.

I’ve been in discussions with the HL7 Board, and we seem to be in general agreement to this. I’m just waiting to get the agreement formalized, and then I’ll turn FHIR over to HL7.


Question: OIDs for v2 tables

Is there an oid for HL7V2 Tables, ideally with an extension matching the table number for each V2 table? (We have created a local one, but wonder if there is an official one.)

Yes, there is. The HL7 OID space .12 is reserved for HL7 v2 tables. The node after that is the leaf, and is the table number. In other words, HL7 v2 table 0078 has the OID 2.16.840.1.113883.12.78.

Note that this OID can be used to identify HL7 v2 codes in v3 CD (and related) data types, as can be seen in “Representation of Common Australian Identifiers in v2 and CDA“. The OID doesn’t actually identify the implicit value set associated with the table. (Last I heard, the vocab committee was still deliberating on the subject of that OID).

You should replace your local one.

On the same subject can you please tell us where to go to find official oids?

The only place (which makes it the least worst option) is the HL7 OID registry. Actually finding OIDs in it is an art. And then knowing whether they’re official – that’s arcane. (but check the status – if the status is not complete, treat the OID with suspicion).

Note that none of the .12 branch is actually registered in the HL7 OID registry. I just happened to be in committee at the right time to know this one.