Monthly Archives: August 2014

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

Question:

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)

Answers:

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:

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

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"> 
 <code>
  <coding>
   <system value="http://www.nlm.nih.gov/research/umls/rxnorm"/>
   <code value="856903"/>
   <display value="HYDROCODONE 5MG/ACETAMINOPHEN 500MG TAB"/>
  </coding>
 </code>
</Medication>

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"/>
 <product>
   <ingredient> 
     <item>
       <reference value="Medication/hydrocone"/>
     </item>
     <amount>
      <numerator>
        <value value="5"/>
        <system value="http://unitsofmeasure.org"/>
        <code value="mg"/>
      </numerator>
      <numerator>
        <value value="10"/>
        <system value="http://unitsofmeasure.org"/>
        <code value="mL"/>
      </numerator>
    </amount>
  </ingredient>
  <ingredient> 
     <item>
       <reference value="Medication/acetaminophen"/>
     </item>
     <amount>
      <numerator>
        <value value="500"/>
        <system value="http://unitsofmeasure.org"/>
        <code value="mg"/>
      </numerator>
      <numerator>
        <value value="10"/>
        <system value="http://unitsofmeasure.org"/>
        <code value="mL"/>
      </numerator>
    </amount>
  </ingredient>
 </product> 
</Medication>

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?

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

or

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

Question: sending PDFs via HL7 v2

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

Question:

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?

Answer:

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.