Terminology derived invariants in FHIR

Feb 17, 2014

Over on David More’s generally controversial Australian Health IT Blog, I’ve been drawn into a discussion about a number of weaknesses in the FHIR examples with Eric Browne, who says (among other things):

The FHIR development community is still driven predominantly by technical software people. It shows in the quality of the few clinical resources and samples that I’ve looked at. E.g. instance data not matching the resource profiles and incorrect LOINC codes and mismatches to units - mmol/L is a substance concentration not a mass concentration

Eric made a number of other points and subsequent discussion etc-  you read it on David’s blog, and I thank Eric for his contribution (I would’ve preferred this stuff prior to closing the DSTU, but late is better than never, and these things will be fixed in the development version, once I do the work to publish that).

In this post, I want to pick up on the last point, about mismatches between LOINC codes and units on observed values.

Firstly, several general points to make:

  • The offending examples mostly came from the Standard Australian example set (they used to be posted on ahml.com.au, but I can’t find that or them right now), but they may have come from elsewhere too
  • This is a very subtle point. I very much doubt it will matter in clinical practice - since it’s so common, if you really cared about the difference enough, you’d have to handle the error
  • This is a common in error in practice
  • LOINC often has a code for mass concentration and not molar concentration, or vice versa
  • Practice in USA tends to be mass concentration, while practice in Australia tends to be molar concentration, so it’s particularly common to see a mass code with a molar unit in Australia, since LOINC usually follows US practice
  • I don’t see how this demonstrates the point about technical software people, btw - though scientists might be less likely to make it (though I am one, and I glossed over it when I reviewed the example)

However, even given all that, we certainly should get the official examples correct. And our natural impulse in the FHIR project would be to write a validation rule for the validation engine. That way, it runs on all the published examples, and also on every other example that is ever validated. In this case, the rule would say something like:

If one of the codes in observation.name implies a unit kind, then the unit in the value should match that kind

Or, if we can assume UCUM, then the rule becomes:

If one of the codes in observation.name implies a canonical UCUM unit, then the unit in the value SHALL compare to that unit

However I’m not entirely sure we can assume UCUM, though. Of course, in v3, HL7 insists on UCUM so you can do this type of reasoning, but we backed away from that in FHIR because the real world doesn’t actually align with UCUM (much as I think it should).

Right now, in FHIR, we have no systematic way of making this kind of assertion at the element level. We do have a way of stating XPath assertions, but this rule above, which involves multiple terminological look ups, and a UCUM code comparison - is far outside the scope of what you could do with XPath. (Well, I lie - there’s an xpath implementation of UCUM, though as far as I can find, it’s not public.)

Generally, there’s a few different paths we could take for this kind of thing:

  • Assume that you can get there in XPath
  • Define a sophisticated web service to support the xpath invariants, and assume people will implement it (is there a standard one? I don’t think so, though FHIR itself is getting there)
  • Choose some other language to make these type of assertions in (and assume people will develop tooling for it)

I don’t know which of those to pursue. I know I hate doing real programming in XPath. Comments are welcome…