LOINC Panels and Tests, Biomedical Concepts and Define-XML

 

A CDISC "Biomedical Concept" (BC) has been defined as "a generic description of something that can be measured on a subject ... or other information such as events happened" or "A high-level building block of clinical research and/or healthcare information that encapsulates lower level implementation details like variables and terminologies" and also have been mentioned to be used as "building blocks in protocols".

Does this help us for use in software?

Unfortunately, CDISC has not yet published a specification for an exchange format for BCs, and only published pictures, usually for very simple BCs, such as for blood pressure, so it is pretty hard to demonstrate BCs, especially in software.

Fortunately, with the CDISC 360 project, CDISC started an initiative to retrieve BCs from Define-XML files from sponsors. So, one may ask "why from Define-XML files?". These are for describing metadata for SDTM, SEND and ADaM submissions isn't it?

The reason is simple: BCs are essentially nothing else than normal medical concepts, enriched with SDTM or ADaM information (no attempts have been done for SEND so far). As such, they are very similar to OpenEHR archetypes, HL7-FHIR profiles, and ... LOINC panels for tests. As LOINC codes for defining test and test panels are enormously used in healthcare, one wonders whether it would be possible to generate CDISC-BCs directly from LOINC panels and tests. After all, we do have a LOINC-SDTM mapping published by CDISC, considerably extended by us, i.e. "enriching" these existing medical concepts with SDTM information to make them "biomedical concepts". After all, we don't want to reinvent the wheel from bottom up, isn't it?

Some time ago, we already showed that this is possible and presented, and demonstrated software to do so. We published a pretty large number of such example BCs as graphs in Turtle format so that these can be exchanged. Turtle is however a format that, unfortunately, is not well understood nor used within the CDISC community. Furthermore, graph visualizations of Turtle files can be a bit challenging for CDISC aficionados, who are (also unfortunately) used to work with ... tables.

Here is a relative simple one, others can be much more complicated ...

This is where Define-XML comes into play. CDISC people do usually understand Define-XML very well (unless they generate define.xml files using "black box software", usually "post dataset-generation"), and there are very good stylesheets to visualize the contents of define.xml files, as ... tables.
Also, BCs can be represented by define.xml "value lists" as has been shown before. And as CDISC is now starting "Define-XMLmining" to generate BCs, why not generate Define-XMLs for our from LOINC panels generated BCs too? This would surely help CDISC community members to understand BCs, and also enormously increase the understanding why LOINC is such an important standard for research too.

So we extended the software to also generate Define-XML files in addition to Turtle files. We will soon publish this extension as open source. You can find all the files and their visualizations (using the CDISC stylesheet) on our "Automated Generation of CDISC Biomedical Concepts starting from LOINC Panels" website.

This website (and the LOINC website of course) also clearly shows that LOINC is not only limited to lab tests, but also includes vital signs, ECGs, questionnaires, and much much more.

Here are two examples:

LOINC panel 94503-0 "SARS-CoV-2 (COVID-19) Ab panel - Serum, Plasma or Blood by Rapid immunoassay" which maps to SDTM MB (Microbiology). Here is just one screenshot from part of the define.xml visualization, displaying the value lists for MBMETHOD (method) and MBSPEC (specimen):

 

LOINC panels can be nested. An example is LOINC panel 85353-1: "Vital signs, weight, height, head circumference, oxygen saturation and BMI panel", containing a total of 24 tests. A screenshot of the visualization for the codelists and valuelists for VSLOC, VSLAT and VSMETHOD:

and for VSORRESU:

 

All this has been generated nearly fully automatically. There is still a small amount of user interaction necessary when using the program. For example, if the software does not find a mapping for a LOINC code, it asks the user what it needs to be mapped to, or to make it a supplemental qualifier variable, or to skip it. An example is LOINC code 8361-8 "Body position with respect to gravity", which of course maps to VSPOS, but as this is not in the LOINC-CDISC mapping, the software doesn't know. This is something we surely want to do better, e.g. by having the software inspect a file with such "additional" mappings that are used in many panels.

But have a look for yourself! All files are at http://xml4pharma.com/CDISC_Biomedical_Concepts_From_LOINC/ and we plan to add much more examples in the coming weeks. So, stay tuned!

And ... as always, comments are very welcome! 

 

 

 

 

Automated Generation of CDISC Biomedical Concepts starting from LOINC codes. Part 1: first beginnings

 

CDISC is more and more working on "biomedical concepts", also in order to be able to move away from the "table thinking" caused by SDTM. The original idea of SDTM has probably been to mimic a relational database, but that did not work anymore after a while: the relations are more and more implicit (you have to learn about them in an Implementation Guide usually in PDF or HTML form). This was fine 20 years ago, but it is, especially to the strong growth of as well SDTM domains as variables), not good enough anymore in 2020.

We find such "biomedical concepts" (I will further abbreviate this as "BCs"), in a lot of the "CDISC Therapeutic Area User Guides" (TAUGs), usually as "mind map" images (mostly generated by the CMap software) embedded in the PDF, so not electronically. The way these "mind maps", representing the BCs, were set up differed quite a lot in the past, but it looks as consensus has been found in the last years on the color coding and shape conventions.
However, as long as there are no real guidelines on how to develop and generate such BCs, such a diversity will remain. There is also currently no good way to compare BCs, as these are currently not available in a machine-readable form.
Especially the latter is and will be a serious "show stopper" for the use of BCs in real life.

Very recently, during the US CDISC Interchange, CDISC coworker Sally Cassells came with the announcement that CDISC wants to start using Define-XML files to store BCs. This is indeed a very good idea, as, first of all BCs are about metadata (so is Define-XML), and the Define-XML's "ValueLists" indeed are used to keep relations between items, such as "when VSTESTCD=SYSBP or DIABP, then VSSRESTC=mmHg"

A bit problematic about this approach however would be that the BCs defined and stored in this way are extremely "SDTM-centric" (or SEND or ADAM-centric), neglecting "the rest of the world". I will explain this in more detail in an example later on.

Biomedical concepts are not new, neither are they limited to clinical research. Such concepts have been used for many many years in health care, only they use other names there.
For example, OpenEHRArchetypes are very close to BCs. And in FHIR, we have "FHIR profiles" such as for blood pressure. Such "profiles" usually use LOINC coding for describing the "observations" (named "Findings" at CDISC).
Also LOINC is more and more developing links between codes, e.g. using "panels". Classically in medical laboratory language, a "panel" is a set of lab tests that are usually ordered, and reported as a whole set. A typical such panel is the "Hepatic Function Panel 2000" (LOINC code 24325-3) containing 7 tests (each of course with their own test code):

It is usually ordered by medical doctors to obtain information on how well the liver is functioning. LOINC is also more and more publishing "LOINC answers to LOINC codes" and linking them to other coding systems.

For example, for "Rhesus Type in Blood" (LOINC code 10331-7):

 

including the SNOMED-CT code for the answer, which is usually used in electronic health records.

This looks pretty like a Define-XML ValueList "LBORRES where LBTESTCD='RH'' (where "RH" is "Rhesus Factor") isn't it?
CDISC calls this "Codetables" and has published a number of them (not for LB however), but unfortunately without linking to other coding systems such as SNOMED-CT which is heavily used all over the world in healthcare.

So, and this is question I have been asking myself already for a longer time: now that we have the CDISC LOINC-LB mapping that is also available as a RESTful web service, and that even has been extended for VS and MB (currently only for COVID-19 tests), wouldn't it be possible to automatically generate CDISC BCs automatically (or semi-automatically) directly from LOINC panels? This would allows us to auto-generate BCs and their Define-XML ValueList prototypes for hundreds, maybe thousands of panels that are routinely used in hospitals anyway. We would then not only store these BCs as Define-XMLs, but also make them available as a kind of "knowledge graphs", e.g. in the modern RDF format, so really machine-readable, and transformable to mind maps such as currently used in TAUGs.

This week, I finally found the time to start on such an attempt.
A well documented example of a BC is that for "vital signs blood pressure", but I did not want to take that, as there are already some people within the CDISC community who think that BCs are only applicable to blood pressure. So, I looked for something a bit more difficult, but not something too difficult either. 

After inspecting the LOINC database, I decided to start with the LOINC panel "Microalbumin Urin 24 hours panel" (LOINC code 58431-8): 

 

This panel is used to obtain information about microalbumin excretion in urine collected over a (planned) time span of 24 hours. The tests are:

- total concentration of microalbumin in the 24 hour urine
- excretion rate of microalbumin (2 codes)
- the actual collection duration
- the total volume of urine collected over the collection duration

In order to retrieve all metadata, I refreshed my SQL knowledge, and wrote the following SQL statement:

SELECT loinc_num, component, property, time_aspct, system, scale_typ, method_typ, class, unitsrequired, shortname, cdisc_common_tests, example_units, long_common_name, example_ucum_units
FROM loincdb_268.loinc
WHERE loinc_num IN (SELECT loinc FROM loincdb_268.panelsandforms WHERE ParentLoinc = '58431-8' and loinc != ParentLoinc);

leading to:

  

I then started thinking "how to start"?

So, I started looking at a number of CDISC BC "concept maps", trying to find out how they exactly work. I then decided to take the BC "Glycosylated Hemoglobin A1c Assay", which has been presented as part of the "CDISC 360" project and is a little bit less complicated than the BC for "Hemoglobin A1C to Hemoglobin Ratio Measurement".

I soon found out that even within these, there seems to be different approaches how to develop such a BC, and especially in the order the concepts are treated and the naming of the relations. The latter is however of ultimate importance for enabling to compare BCs, merge them, make subsets and supersets.
I hope and presume that such exact instructions ("how to") will be an outcome of the CDISC project.

What I also soon found out is that, these BCs are extremely "CDISC-centric", i.e. they exclude everything that is outside the CDISC world. That is a pity, as that would mean that they are e.g. unusable for the use case that "real world data" (RWD) and electronic health records (EHRs) are used as the source. So, in my own attempts, I tried to avoid this pitfall, and also try to use other coding systems where useful.

Just as an example from the CDISC 360 project:

 

This map suggests that "blood" is only a CDISC-CT "specimen type" and does not exist outside the "CDISC world". This is of course not true. My own approach (also found in BCs from some TAUGs) is that there is a specimen "blood", that is categorized as "LBSPEC" with the NCI code C12434 and the name "BLOOD" in CDISC-CT.
In SNOMED-CT however, the same concept has code 119297000 (blood specimen).
So I decided to use the "classic" approach of the TAUGs to just take "specimen" as a "general" concept, and color-code it as explained in the TAUGs:

so that I can then both refer to as well the CDISC code for "blood" as a specimen, as well as to the SNOMED-CT code.

Below is a very first map that I generated manually. It is far from perfect, far from complete, and only 1 way of the many that are possible. Please think about that when starting throwing rotten tomatoes.
I do however think it contains the most important information, including some (but not all) that can be very useful when using RWD or EHRs.
Please also remark that I take the freedom to update this picture as I proceed in my project.

An example of using this "non-CDISC-exclusive" approach is that I have "Volume" as a property of the specimen. Even if CDISC did not exist, the volume is still there, but in the scope of a SDTM submission, it maps to LBTESTCD=VOLUME with NCI code C74720.

Next steps:

Now that we have the (extended) LOINC-LB mapping, we can start thinking about the best strategy to try to automate the generation of such BC maps, and/or to generate Define-XML "ValueLists".

A few of the principles (to be translated in algorithms) are:

- the LOINC code maps to LBTESTCD
- the LOINC "Component" maps to both LBTESTCD and LBTEST. In our case, we have three distinct "Components":"Collection Duration", "Volume" and "Albumin" (but we have to take special attention to "Albumin ug/min" which, according to the LOINC website, is an exception to the rule)
- the LOINC "System" usually maps to LBSPEC (specimen), but sometimes it maps to LBLOC (location)
- the LOINC "property" maps to SUPPLB.LBRESTYP
- the LOINC "time aspect" maps to SUPPLB.LBPDUR (planned duration)
- the LOINC "scale" maps to SUPPLB.LBRSLSCL (result scale)

For the LOINC "method" we need to be extremely careful. In many cases it will map to LBMETHOD, but sometimes "method" contains information about the lower limit of detection in which case it maps to LBLLOD. There might however also be cases where it maps to LBTSTCND (test condition).

Furthermore, generating the Define-XML ValueLists (and also the graphs) will require to do some "GROUP BY" for the different LOINC codes in a test set. Probably (but I haven't tried anything yet), we will need first to group by the analyte (LOINC "component") and then by the specimen (LOINC "System"), and then group by any other of the LOINC properties, with the last one being the "example unit". An example of this is where there are 2 codes for exactly the same measurement, but where one is in SI units and the other is in "US conventional units".
An example from vital signs is "height" which can either be reported in cm or in inches.

I will keep you informed about my progress! But please feel free to comment!