Observation of Titers in HL7 Content

Several important diagnostic measures take the form of a Titer. Quoting from Wikipedia:

A titer (or titre) is a way of expressing concentration. Titer testing employs serial dilution to obtain approximate quantitative information from an analytical procedure that inherently only evaluates as positive or negative. The titer corresponds to the highest dilution factor that still yields a positive reading. For example, positive readings in the first 8 serial twofold dilutions translate into a titer of 1:256 (i.e., 2−8). Titers are sometimes expressed by the denominator only, for example 1:256 is written 256.

A specific example is a viral titer, which is the lowest concentration of virus that still infects cells. To determine the titer, several dilutions are prepared, such as 10−1, 10−2, 10−3, … 10−8.

So the higher the titer, the higher the concentration. 1:2 means a lower concentration than 1:128 (note that this means the clinical intent is the opposite of the literal numeric intent – as the titre gets lower, the concentration gets higher).

Titers are pretty common in clinical diagnostics – I found about 2600 codes for titer type tests in LOINC v2.48 (e.g. Leptospira sp Ab.IgG).

Representing Titers in HL7 Content

In diagnostic reports, titers are usually presented in the text narrative (or the printed form) using the form 1:64, since this makes clear the somewhat arbitrary nature of the numbers in the value. However it’s not unusual for labs to report just the denominator (e.g. “64″) and the person interpreting the reports is required to understand that this is a titer test (this is usually stated in the name).

When it comes to reporting a Titer in structured computable content, there’s several general options:

  • represent it as a string, and leave it up to the recipient to parse that if they really want
  • represent it as an integer, the denominator
  • use a structured form for representing the content

Each of the main HL7 versions (v2, CDA, and FHIR) offer options for each of these approaches:

String Integer Structured
V2 OBX||ST|{test}||1:64 OBX||NM|{test}||64 OBX||SN|{test}||^1^:^64
CDA <value xsi:type=”ST”> 1:64 </value> <value xsi:type=”INT”> 1:64 </value> <value xsi:type=”RTO_INT_INT”> <numerator value=”1”/> <denominator value=”64”> </value>
FHIR “valueString “ : “1:64” “valueInteger” : ”64” “valueRatio”: { “numerator” : { “value” : “1” }, “denominator” : { “value” : “64” } }

(using the JSON form for FHIR here)

One of the joys of titres is that there’s no consistency between the labs – some use one form, some another. A few even switch between representations for the same test (e.g. one LOINC code, different forms, for the same lab).

This is one area where there would definitely be some benefit – to saying that all labs should use the same form. That’s easy to say, but it would be really hard to get the labs to agree, and I don’t know what the path to pushing for conformance would be (in the US, it might be CLIA; in Australia, it would be PITUS; for other countries, I don’t know).

One of the problems here is that v2 (in particular) is ambiguous about whether OBX-5 is for presentation or not. It depends on the use case. And labs are much more conservative about changing human presentation than changing computable form – because of good safety considerations. (Here in Australia, the OBX05 should not be used for presentation, if both sender and receiver are fully conformant to AS 4700.2, but I don’t think anyone would have any confidence in that). In FHIR and CDA, the primary presentation is the narrative form, but the structured data would become the source of presentation for any derived presentation; this is not the primary attested presentation, which generally allays the lab’s safety concerns around changing the content.

If that’s not enough, there’s a further issue…

Incomplete Titers

Recently I came across a set of lab data that included the titer “<1:64″. Note that because the intent of the titre is reversed, it’s not perfectly clear what this means. Does this mean that titre was <64? or that the dilution was greater than 64. Well, fortunately, it’s the first. Quoting from the source:

There are several tests (titers for Rickettsia rickettsii, Bartonella, certain strains of Chlamydia in previously infected individuals, and other tests) for which a result that is less than 1:64 is considered Negative.  For these tests the testing begins at the 1:64 level and go up, 1:128, 1:256, etc.   If the 1:64 is negative then the titer is reported as less than this.

The test comes with this sample interpretation note:

Rickettsia rickettsii (Rocky Mtn. Spotted Fever) Ab, IgG:

  • Less than 1:64: Negative – No significant level of Rickettsia rickettsii IgG Antibody detected.
  • 1:64 – 1:128: Low Positive – Presence of Rickettsia rickettsii IgG Antibody detected
  • 1:256 or greater: Positive – Presence of Rickettsia rickettsii IgG Antibody, suggestive of recent or current infection.

So, how would you represent this one in the various HL7 specifications?

String Integer Structured
V2 OBX||ST|{test}||<1:64 {can’t be done} OBX||SN|{test}||<^1^:^64
CDA <value xsi:type=”ST”> &lt;1:64 </value>  {can’t be done} <value xsi:type=”IVL_RTO_INT_INT”> <high> <numerator value=”1”/> <denominator value=”64”> </high> </value>
FHIR “valueString “ : “<1:64” {can’t be done} “valueRatio”: { “numerator” : { “comparator” : “<”, “value” : “1” }, “denominator” : { “value” : “64” } }

This table shows how the stuctured/ratio form is better than the simple numeric – but there’s a problem: the CDA example, though legal in general v3, is illegal in CDA because CDA documents are required to be valid against the CDA schema, and IVL_RTO_INT_INT was not generated into the CDA schema. I guess that means that the CDA form will have to be the string form?



Caption Contest

I don’t get humorous stuff on this blog often enough. However, my attention has just been drawn to this picture of one the followers of this blog posing with a projection of the RIM:

Caption Contest

I’ll buy a beer at the next (HL7 meeting, HIMSS, or whereever) for the person who nominates the funniest caption for this picture.

p.s. be funny. I’ll moderate these comments if I have to

Question: Using Medication resources in FHIR


What’s the implementation extent for representing medication prescriptions with:

  1.  escalating dosage (eg,take 2 at each meal first week, then 1 at each meal)
  2. multi-drug medications (eg HYDROCODONE 5MG/ACETAMINOPHEN 500MG)


1. Variable Dosage

There is a variety of approaches to this in existing systems – sometimes text focused. But in the prescription resource, this is handled by repeating the dose instructions:

    <low value="2014-08-14"/>
    <high value="2014-08-21"/>
    <value value="2"/>
    <units value="tablet"/>
    <low value="2014-08-22"/>
    <value value="1"/>
    <units value="tablet"/>

2. Multi-Drug Medications

The MedicationPrescription resource refers to a Medication resource for the details of what is prescribed, and this offers 2 different ways to deal with this situation. The common way this works is that there is a single code for the medication, taken out of something like RxNorm.:

<Medication xmlns="http://hl7.org/fhir"> 
   <system value="http://www.nlm.nih.gov/research/umls/rxnorm"/>
   <code value="856903"/>

Since the code itself is explicit about the multiple ingredients, then there is no need to say anything further. However in the case of extemporaneous medications, there is no extant code, so you would so something like:

<Medication xmlns="http://hl7.org/fhir">
 <name value="My Custom Elixir"/>
 <kind value="product"/>
       <reference value="Medication/hydrocone"/>
        <value value="5"/>
        <system value="http://unitsofmeasure.org"/>
        <code value="mg"/>
        <value value="10"/>
        <system value="http://unitsofmeasure.org"/>
        <code value="mL"/>
       <reference value="Medication/acetaminophen"/>
        <value value="500"/>
        <system value="http://unitsofmeasure.org"/>
        <code value="mg"/>
        <value value="10"/>
        <system value="http://unitsofmeasure.org"/>
        <code value="mL"/>

Although, of course, this particular custom elixir doesn’t seem like a very likely real world case.

Update – related question:

“tid” is not the same thing as “q8h”.  Can they be differentiated in FHIR?

  <frequency value="3"/>
  <duration value="1"/>
  <units value="d"/>


  <frequency value="1"/>
  <duration value="8"/>
  <units value="h"/>

Question: sending PDFs via HL7 v2

This question is a follow up to one asked on Stack Overflow


On stack overflow you asked me to look at MDM message type. My question is that I know some systems can’t handle MDM message types so if this is the case how could sending of a url for a pdf be handle in that case?

What is the best way(appropriate message/event type) to put a url for a pdf in an hl7 message(ie what are the message types and segment, etc.. that are appropriate)?

Also does the HL7 standard allow for the unsolicited pushing of pdf messages whether it be a url to a message or an actual pdf document encoded in hl7? For example if an ADT message came in and was successfully loaded into my system and I wanted to create an hl7 message to send out with the link or embeded pdf that i created. What hl7 message would i use to send?


Most systems would have no concept of why they’d accept an unsolicited PDF – where would it go? what’s it’s workflow? If they do know the answer to that question, and they can accept it, then they should implement the MDM messages (T12, T14, T15 maybe), since that’s the correct message type for that functionality.

If the destination system doesn’t handle MDM messages, then it most likely doesn’t handle unsolicited PDF messages, but you’d have to ask (or consult the documentation if it exists). It’s going to be a per system thing – but it is anyway, since systems vary so much.

You can send an ORU message with an OBX segment with an RP data type in OBX-5 which is a reference to a PDF(or even an ED data type with the entire PDF in it). But whether systems can accept ORU messages like this, and whether they can correctly represent an RP/ED like this… again, that’s a question for each individual system.

#FHIR CDA Position Statement & Roadmap: Joint Statement with Lantana

Lantana Consulting Group invited me to take part in the Spring CDA Academy after the HL7 Working meeting in Phoenix in May, which I enjoyed greatly. While I was there, we spent some time discussing the relationship between CDA and FHIR, both where things are today, and where we think they should be.

This is a pretty important subject, and from the beginning of our work on FHIR, one of the most common questions that we have been asked about FHIR is “what about CDA?”. Sometime, we get asked a more specific question:  “What does Lantana think about FHIR?”.

Since the CDA Academy, we’ve been working on a joint statement that summarizes the outcome of our discussions, a shared expression of where we believe that we are, and should be. Today, Lantana Consulting Group have posted our position statement on FHIR and CDA (see their blog post):

This position statement addresses the relationship between HL7’s Clinical Document Architecture (CDA) product line and the Fast Health Interoperability Resource (FHIR) product line. It was prepared jointly by Lantana Consulting Group—a recognized leader in the CDA community—and Grahame Grieve, Health Intersections, the FHIR project lead. This statement is not official policy. It is our hope that it will stimulate discussion and possibly guide policy makers, architects, and implementers as well as standards developers.

An underlying key concept for this position statement is that difference between a “package of data and narrative” and interactive access to the narrative and data in a patient or institution’s record, and that both have their place for exchange. Quoting from the document: 

CDA addresses interoperability for clinical documents, mixing narrative and structured data. FHIR provides granular access to data, a contemporary, streamlined approach to interoperability, and is easy to implement. FHIR can be the future of CDA, but it is not there yet.

FHIR offers considerable promise, but it’s certainly true that we have a long way to go yet. The joint statement issues a call to action:

FHIR DSTU 1 is not a replacement for CDA or C-CDA. Building out the specification so that it can represent existing documents as FHIR resources, and ensuring that FHIR resources can be integrated into CDA documents should be the focus of the next iteration of the DSTU

This is explicitly part of the scope of the next DSTU version of FHIR: to address the areas that CCDA covers, and several Lantana employees have already been working with us on this; I look forward to increased focus on this work.

Question: NEHTA CDA & GP referrals


Is there any example of NEHTA compliant CDA document that I can look at from a perspective of a GP referral form ( http://nhv.org.au/uploads/cms/files/VIC%20-%20GP%20Referral%20(March%202013).rtf )? Is there a tool that can be used to navigate and generate the CDA from a HL7 v2 message?


There’s been a lot of discussion over the last decade or so about creating a CDA document for these kind of referral forms. I saw a pretty near complete set of functional requirements at one point. But for various reasons, the project to build this has got any funding, either as a NEHTA project, or a standards Australia project (it’s actually been on the IT-14-6-6 project list for a number of years, mostly with my name on it).

So right now, there’s no NEHTA compliant document. As a matter of fact, I don’t know of anything quite that like that from any of the national programs, though no doubt one of my readers will – please comment if you do. There is a project investigating this in the US National Program (S&I framework( but they’re not using CDA.

On the other part of the question, no, unfortunately not. NEHTA provides both C# and java libraries that implement the NEHTA described CDA documents, but it’s an exercise left to the implementer to convert from a v2 message to a CDA document. That’s primarily because there’s so much variability between v2 messages that there’s no safe way to write a single converter

I tried to do that with just AS 4700.2 messages, which are much more constrained than the general case, and it wasn’t really successful; the PITUS project is working on the fundamental alignment needed to get ti right in the future.

#FHIR Connectathon 7, Chicago Sept 13-14

We will be holding the next FHIR connectathon in Chicago on Sept 13/14 associated with the HL7 Plenary Meeting. Once again, anyone interested in implementing FHIR is welcome to attend.

This connectathon, we have 4 tracks (we’re expanding!):

  1. Our standard introductory Patient Track. This is generally the one that’s appropriate for first time attendees
  2. A new track focusing on the conformance resources (Profile and ValueSet), testing interoperability between the various tools and users that are starting to see these used in anger now
  3. Our standard experimental track, focusing on the cutting edge. This time, we’re doing something quite different: we’re going to be testing a basic SMART on FHIR EHR/plug-in scenario
  4. A joint track with DICOM exploring interoperability between the DICOM RESTful services and the FHIR API

What’s really exciting about these is that we’re starting to move into real world interoperability contexts now, focusing more on how FHIR is used in practice than exploring areas of the standard.

There’s full details about the connectathon on the HL7 wiki, with registration details.

I’ll look forward to seeing you there!

License Restrictions on Terminologies

One of the things that we can do in FHIR that can make a significant contribution to interoperability in FHIR is to describe how to use common terminologies in a common fashion. Interoperability is a waste of time if the way one organization uses a code system is different to way another one does. And I’ve learnt, through my implementation experience, that it’s not just enough to say “use this code system”, or “this is the namespace for the code system”. There’s a lot more to say, about what valid  codes are, how versions should be identified consistently, how to exchange information about subsets – which relates heavily to agreeing how to use the code system, etc.

But the terminologies themselves seem hell-bent on making this impossible by their licenses. The problem is that the licenses divide the world into three categories: the provider of the terminology, the creators of implementation systems, and the rest: unlicensed entities who have no rights to the code system.

HL7 and it’s specifications don’t fit into the first two, so end up in the 3rd category. Consider these two license statements:

Licensee is prohibited from distributing the [tx] or subsets of it, except (a) as an integral part of computer applications developed by Licensee for a purpose other than redistribution of vocabulary sources contained in the [tx] and (b) as also subject to (additional rules)…

and this one:

The Licensed Materials may be used only internally at a single entity within your  facilities in the United States or its territories, only by you, your employees, or agents

You may not sell, sublicense, assign or transfer the Agreement or the Licensed Materials or any copy, modification or merged portion or version of the Licensed Materials to any party

With licenses like these, it’s not possible for HL7 to say some really important things about how code systems are used, or to provide examplar information. Or sometimes, to even mention their existence.

And also, btw, there is no way to seek assistance from some external provider of specialist advice. I know that goes on all the time anyway, despite the license, but when you’re writing an open public specification, that’s not really an option.

So for the meantime, the FHIR specification will not be able to describe to it’s user’s how to interoperably use a set of useful and important code systems. Because remember, corporate control over licensed materials (even if they are free) is more important than making things work well in the real world.



Joint openEHR/FHIR review of Allergy/Intolerance

I previously announced that:

we’re going to do a joint review of the FHIR resources for Allergy/Intolerance (AllergyIntolerance and AdverseReaction), and the openEHR archetype for the equivalent content (openEHR-EHR-EVALUATION.adverse_reaction.v1). The review is going to be done on the openEHR CKM, on a newly prepared archetype that shows the essential content models of the existing archetypes and resources (they’re quite different)

Well, the review is now open on the openEHR CKM, and will close on 28th July. We invite all interested parties – clinicians, programmers, systems analysts, etc, to contribute to the review. Even if all you contribute is a list of what fields you presently support in your existing system, this is a valuable contribution.

This blog post has some further details to help the FHIR/HL7 community with this process.

The archetype that is being reviewed is the result of a thorough review of both the FHIR and openEHR content, informed by the HL7 Allergy DAM and the joint NHS/Microsoft CUI documents.

There are 3 sections below:

  • Discussion of specific issues that arose during the editorial preparation
  • Map between the review archetype and the existing FHIR resources
  • Notes about the review process for the FHIR community

Specific Issues for the Review

1. Who is invited to participate

The review of this archetype is open to everyone, whether they are HL7 members, members of the openEHR community, the FHIR community, or otherwise unengaged. We would like as many people as possible to review the content. Although the content is primarily clinical, and for this reason clinical review is the main focus of this review, we are also very much interested in review from technical people (developers, analysts, standards folks), particularly in regard to whether there are obstacles in this design that would make it difficult to represent existing legacy content (whether in databases or some exchange format) using this logical model.

2. Split between AllergyIntolerance/AdverseReaction

The FHIR archetype is split into 2 parts; the AllergyIntolerance resource that represents the notification of a risk of reaction, and the AdverseReaction that describes specific past reactions. The allergy intolerance resource references 0..* past reactions. This means that you can describe an adverse reaction event without providing an overall assessment of risk.

This proposed archetype does not allow for this separability, and the reaction event details can only be used in the context of the evaluation/notification of the risk. The editorial team expects that there will be a need for an Adverse Event report content model, but that this will need a different content model to the one for reaction event details in this archetype.

This raises design questions about the other resources that currently use AdverseReaction. We are seeking comment about this issue, and there will be further discussion of this on the FHIR and Patient Care mailing lists.

3. Collapsing Exposure

The FHIR AdverseReaction allows for a single event with multiple possible causative agents. This archetype doesn’t. This is related to the previous issue, in that we are reporting issues with substances here, not reporting of Adverse Events. We are seeking comment as to whether existing systems do or should allow for multiple causative agents in the context of evaluating a propensity to a reaction.

4. Element Names

The names of the fields in the archetype are not valid FHIR element names. In the Archetype, these names have UI implications, where they do not necessarily do so in the FHIR resource. Reviewers should assume that the archetype field names will be converted to valid (and sometimes shorter) element names in the resulting FHIR resource, so extensive comment on this is not needed.

5. Core (or 80/20)

OpenEHR and FHIR have different models for extensibility. This influences the way that openEHR and FHIR handle assessment of core. This archetype includes some specific elements that were not part of the FHIR resources. Some of them may become core elements of the FHIR resources, while others might be relegated to extensions. We are interested in comment on this. In particular, we are seeking comment/input from both clinicians and technicians as to which fields in this archetype that existing systems support/collect/(could) populate, as this will help guide this decision.

6. Exposure Category

This is a common feature in many models, but the editorial team is not sure why, and proposes to remove it. We are interested in both clinical arguments for and against its presence, as well as input as to whether existing systems populate it, and if so, how.

Map between the review archetype and the existing FHIR resources

This table provides a basic map between the review archetype and the existing FHIR resources, to assist FHIR reviewers to make their comments.

Open EHR Existing FHIR Resources
Header Scope and Use




 Reaction Type


 Reaction Event

  Specific Substance


  Manifestation Details



  Reaction Description

  Onset of Reaction

  Duration of Reaction

  Severity of Reaction

  Reaction Details

  Duration of Exposure

  Exposure Category

  Initial Exposure

  Exposure Description

  Exposure Details

  Clinical Management Description

  Reporting Details


  Information Source

  Reaction Comment


AllergyIntolerance.substance (.code)





AdverseReaction / AllergyIntolerance.reaction











n/a (nearest is AdverseReaction.exposure.date)








~AdverseReaction.recorder + Provenance




 Date Recorded

 Supporting Clinical Record Information

 Reporting Details

 Reaction Reported?

 Report Comment

 Adverse Reaction Report

 FHIR Record Provenance






AllergyIntolerance.sensitivityTest + .extension









Note: all the fields labelled as “n/a” in the second column have no direct equivalent in FHIR. Maybe they should, or perhaps they should just be extensions? The fields that are directly mapped to extensions in the table above are where the archetype fields are openEHR extensibility points, and it wouldn’t make sense to define FHIR elements for them.

The following Resource contents have no direct equivalent in the new archetype. If you think they are still needed, you can make a comment about this in the general comments section of the review.

  • AdverseReaction.identifier (not needed if event is not a separable model)
  • AdverseReaction.didNotOccur (when would this be used?)

Notes about the review process for the FHIR community

We highly recommend that you read the HL7 Allergy and Intolerance DAM (http://wiki.hl7.org/images/1/1b/Allergy_and_Intolerance_INFORM_2013_MAY.pdf), and the MSCUI Allergies documentation (www.mscui.net/DesignGuide/DisplayingAllergies.aspx + www.mscui.net/DesignGuide/RecordingAllergies.aspx) prior to participating in the review.

Also, in the review, remember to review all 3 sections – Header, Data, and Protocol.

To sign up to participate in the review, Go to http://www.openehr.org/ckm/#. You’ll get this page:


Click on the Sign-up link on the top right:


Fill it out, and submit:


Then you get a confirmation Email:


Click on the Activate your account, and you get this:


Now, sign in (top right), and then find the FHIR/OpenEHR adverse reaction:


Double click on it, and you get this:


The content of the archetype is divided into 4 sections:

  • Header: the scope, purpose, use etc for the archetype, along with a set of references
  • Data: the core clinical content of the archetype
  • Protocol: data elements that relate to how the evaluation was performed
  • Reference Model: underlying content that isn’t important for the review process


Exchanging Codes with Translations in practice

All the mainstream clinical coding data types across HL7 (v2, v3, FHIR) and elsewhere (openEHR, IHE, DICOM to a lesser degree) allow for a translations of codes. These are provided because institutions are often not able to get consistency over which terminologies are in use. On the other hand, actually exchanging translations of codes is not that common in my experience. I’ve seen it in the following cases:

  • Coding for lab tests and panels (typically, a combination of local, LOINC, and Snomed codes)
  • Translations for medication codes in the Australian PCEHR (from one system only)

That’s the cases where I’ve seen it in practice. Where else have you actually seen it used? Can we gather some specific cases where it *has* been used (not where it might be a good idea, since complexity always sounds like a good idea at first).

If you have, make a comment on this post, please