Wednesday, February 25, 2015

CDISC Therapeutic Areas and LOINC

In a recent discussion with an important CDISC representative (well, they are all important), I heard the remark that the therapeutic area user guides (TAUGs) may be the perfect forum to introduce people to LOINC coding for lab tests. So I downloaded them all, and searched them for:
  • whether LOINC is mentioned at all
  • whether there are lab tests described which are / maybe important for the specific therapeutic area
  • whether the important lab tests that are described come with their LOINC code
  • whether example of LB domain tables have the LOINC code (in LBLOINC) included
So, let's go!

TAUG multiple sclerosis

  •  mentioned that --LOINC variable is not to be used in domains NV and OE
  • no lab tests described
TAUG virology
  • LOINC mentioned many times as standard reference technology for tests in the domains VR, PR.
  • Shows up in many of the example tables, for example PFTSTRCD=48005-3, PFTSTRNM=LOINC
  • No specific laboratory tests described
TAUG Influenza
  •  LOINC not mentioned at all
  • A few lab tests are described (e.g. nucleic acid amplification techniques - NAAT) for which LOINC coding exists (e.g. 68987-7, 38270-5), but the LOINC codes are not provided
TAUG Cardiovascular Studies
  •  LBLOINC field and values provided in all LB example tables
  • Not further explained what LOINC is, supposed to be known by the users
TAUG Asthma
  • LOINC not mentioned at all
  •  Different lab tests extensively described (e.g. Leukotriene E4, Immunoglobulin E) but no LOINC codes provided, though they exist (e.g. 33344-3, 62621-8, ...)
TAUG Alzheimer (2.0)
  •  Mentioned as standard technology for genomic tests (PFTCVNM, PFTTESTCV)
  • No specific laboratory tests described
TAUG Diabetes
  •  LOINC not mentioned at all
  • A good amount of proposed lab tests is defined in detail, but no LOINC codes are given, although they exist for each of the described test
So, the use of LOINC seem to be very different: in some cases, LOINC is used all the way (even expected to be known by the user - cardiovascular), and in other cases, the authors of the TAUG seem even not to be aware of LOINC as a coding system for the exact identification of lab tests.

In the case of the TAUG diabetes, I added the LOINC codes myself to one of the tables describing a set of lab tests. It took me less than 10 minutes to do so (thanks WWW!). Here is the result:

Personally, I strongly believe that providing/suggesting LOINC codes for lab tests in a TAUG is a very good thing, as it can be copied into the protocol, so that the protocol writers / investigators / SDTM generators do not need to interprete / guess which test exactly must be done or was done.


Sunday, February 8, 2015

The power of UCUM: unit conversions using web services

Yesterday, one of my smaller dreams came true.

Some years ago, when I started working with electronic health records (EHRs), I discovered UCUM, the "Unified Code for Units of Measure"  which is used for all quantitative data in them. So I started teaching UCUM to my students. UCUM also publishes an XML file, the "ucum-essence.xml" file, which in principle should allow to do automated unit conversions, as it allows to decompose each string that is in UCUM-notation into the base units (m,g,s,...).

So I found a student, Milos Ilic, who agreed to develop a Java programm for unit conversion with a nice graphical user interface, as part of his Bachelor thesis. He succeeded doing so (well done!) - here is a snapshot of his application:

It allows the user to select a property (pressure in this case), and then allows to select a source unit plus a prefix for it (cm water column in this case) and a target unit plus a prefix (mm mercury column in this case), and then do the unit conversion.
Just to be clear, the application does not use a conversion table, it decomposes both cm[H2O] and mm[Hg] into its base units (m,g,s) allowing to generate the conversion factor "on the fly".

But this was just a first step, as the Java application (though excellenly made) still has a number of disadvantages:
  • it requires a human to use it
  • you can't call it from within your own application e.g. saying "please let me know how many mm mercury column 100 cm water column is"
  • it does not support more complex, composite UCUM strings like "mm[Hg]/min pressure decrease"
  • it does not support annotations, like in mmol{creatinine}/ml

So a "web service" was due.

And yesterday, I finally could finalize writing (and especially testing) the code. The service is a RESTful web service, allowing any modern computer application to ask the service questions like: "please let me know how much 0.25 pounds per square inch per minute" is in "millimeter mercury per hour". Here is the result when displayed in a browser:

You can find all the details about the web service at:

So how could this web service be used in healthcare and in clinical research? Here are a few possibilities:
  • allow EHR implementations to do unit conversions automatically
  • if CDISC would allow / mandate UCUM units (it only very partially does so for lab units), automate the process of converting original results (--ORRES) to standardized units (--STRESN)
  • allow the FDA tools to validate whether a conversion between original result and standardized has been done correctly
  • allow the FDA to compare lab results across studies and sponsors (they can't right know) - another requirement for this is that they use LOINC for lab test codes
  • and much much more
The web service is not perfect yet, there still are a small number of limitations which we are working on.
But I do encourage you to at least use this web service in your pilot applications!