Creating your lab source file for mapping to LOINC

Your ability to accurately map to LOINC depends on having sufficient information about the tests of interest. In general, the more information you have on hand, the better and faster the mapping process will be.

The typical process is to export or extract your master test file (a.k.a. service catalog, test catalog, data dictionary, etc) out of your laboratory information system (LIS) or other information system and into a spreadsheet or delimited text file. I call this exported file your source file.

Preparing your source files to support an optimal mapping sequence

When you start mapping, you could just go through the codes one by one in whatever order they happen to appear. I don’t recommend that. You’ll end up doing mental gymnastics as you jump from chemistry to genetics to hematology and back again. It is much more difficult to be consistent in your mapping approach this way. Thinking ahead means that we are going to be intentional about how we setup our source files.

I recommend that you start first with your observation codes. If you are going to map your order codes to LOINC, come back to them after you’ve finished your observation codes. Only after you map the elements of the panel (observations) will you be able to tell if the panel has an equivalent representation in LOINC. To support this approach, I recommend that you create separate source files for your observation codes and your order codes (including panels).

Creating a source file of observation codes

The end goal of this process is to have a single spreadsheet or delimited text file with one row per observation. As you gather all the key information, you may have to merge multiple files from your information system into this one source file. For example, you may have an LIS data dictionary that has a list of test orders and observations in one file and a separate laboratory test catalog with additional information like specimen collection requirements, when the tests are performed, details on the testing methodology, etc.

The goal is to get all of this information into a single source file for import into RELMA. If you get stuck, you may want to bring in some IT help.

Bare essentials

For your source file of observation codes, at a bare minimum, you will need these fields:

1. Local Test Code – The unique identifier for your test or observation variable. This could be a number or alphanumeric string.
2. Local Test Name – The primary display name for your test or observation variable. If you have multiple names for the same variable, choose the most descriptive one as your primary name.
3. Units – The units of measure associated with this test or observation. Units are essential for mapping all quantitative measurements.

The information included in local test names can vary a lot across institutions. For mapping laboratory tests, you need to know the analyte being measured, specimen, timing (e.g. spot vs 24H), how the results are reported (quantitative, categorical, narrative, etc), and optionally the testing method. If your system has any of this information in other fields, you’ll want to export those fields too.

Special considerations about specimens and panels

To set yourself up for optimal success, I recommend that you create your source file by including the order or panel code associated with each observation. Let me illustrate with a small snippet of what your file might look like:

Here, we are mapping our observation codes PCO2, PH, PO2, HEMATOCRIT, HEMOGLOBIN, etc. But, notice how each row repeats the order panel information. For the whole blood glucose test (first row), the order code and the observation code are the same.

Including the order information enables two key techniques. First, you can sort the file by panel, which gives it a logical sequence for mapping. This avoids the unnecessary mental gymnastics of bouncing from domain to domain.

But, you’ll also need to determine whether there are cases where the context of the panel influences your mapping choices. The classic case is blood gases, included in my file snippet above. Measurements like pH exist both in an arterial blood gas panel (shown above) and a venous blood gas panel (not shown above). Notice that the testing specimen is indicated only in the panel name. Measurements of pH in arterial blood and pH in venous blood would get mapped to different LOINC codes. So in this case, your mapping of the code “PH” depends on the panel that contains is. Without including the panel information in your observation source file, you would have no way of knowing which was which.

Even if you don’t have any of these situations, I still recommend you include the panel information in your source file, primarily because it can be helpful for sorting. Plus, if you are going to map your order codes to LOINC, you will need to know the LOINC codes for the elements in the panel. Including them both in the observation file makes that much simpler.

Next, determine whether there are different codes for the same test done in multiple panels. For example, a serum Alanine aminotransferase measurement may be in your comprehensive metabolic panel, hepatic function panel, preeclampsia monitoring panel, etc. If observation codes are repeated in multiple panels, we can bootstrap one mapping to the others. You don’t have to do anything now to handle this situation. We’ll cover techniques you can use for these situations in Chapter 4.

When you extract your observation codes, be sure to include any accessory tables or add-on variables that could be part of an optional work-up. For example, some laboratory systems may have accessory tables for red cell morphology, urinalysis cellular elements, blood bank antigens, or microorganism susceptibilities. Because they are reportable items, you’ll want to include them in your source file for mapping.

Other information that can help the mapping process

In my view, the more information you have on hand about the tests you are mapping, the better. RELMA can import many accessory attributes for each term. While not absolutely essential, here are the ones I think are most helpful.

Section Categories

In general, I think it’s easier to go through similar tests together. In your system, is there a way to label observations by sections (e.g. chemistry, hematology, etc)? Perhaps you could extract them separately, identify a common pattern in their codes, or some other means. If the number of codes is relatively small, you might manually tag them into categories. Tagging can be done either before importing into RELMA or after (Chapter 4). Doing it before is probably easiest. Just add another column to your spreadsheet titled “Keywords” and fill in the relevant laboratory section for each test.

Sample Results, Average Values, Reference Ranges

Local test names often lack enough information to accurately choose the appropriate LOINC code. In some cases, sample results, average values, and reference ranges can help you identify key distinctions. For example, reference ranges might help distinguish high sensitivity tests from low sensitivity ones. Sample results might help differentiate between quantitative tests with ranked results (e.g. 1+, 2+, 3+) and categorical ones (e.g. pink, yellow, clear). All of these distinctions are relevant when mapping.

If you can’t extract sample results, you may have a field that indicates whether the result is alphanumeric, numeric, etc. Sometimes this is called a “datatype” or a “result type”. This classification can be a helpful proxy to actual result values.

It may be difficult to extract these extra data elements, but it will help your mapping if you can.

LOINC Code

If you have some LOINC code mappings already loaded into your system, you’ll want to include them in your source file. This will let you take advantage of RELMA’s features for maintenance and updating with new LOINC releases.

Specimen details

Ideally, your local test names will include the specimen upon which the test is performed. Nevertheless, if you have other information about the specimen stored in another field, export that too.

Comments

If you have any other descriptive information about the tests performed that you can link to the observation codes, be sure to export those columns too.

Optionality and the relationship of observations to panels

In LOINC, panels are defined by their set of constituent elements. We’re going to cover the details of mapping to order panels later, but here’s what you need to know about it in terms of creating your source file of observation codes.

Each element of a panel in LOINC is labeled as being required, optional, or conditionally present. Conditionality for some elements in the panel definition allows flexibility in how different institutions can use them. For example, LOINC’s definition of a CBC panel contains two codes for Erythrocyte distribution width (EDW), one for when it is reported with units of % (788-0) and other for when it is reported in volume units like fL (21000-5). Both LOINC codes are included in the panel definition, but they are marked as Optional. A laboratory can choose which one is appropriate for how it reports this measurement.

It would be rare to have this kind of Conditionality designation about which variables could be “added on” in commercial, off-the-shelf laboratory systems. Some of these relationships may be stored in additional tables. For example, there may be a table listing red cell morphological conditions that can be added onto a differential that needs an abnormal annotation. So, when creating your source file for order panels, be sure to pull in accessory tables as necessary for any similar “add-on” tests. You might find them for things like urinalysis cellular elements, blood bank antigens, or microorganism susceptibilities.

Last, when you’re done, take a step back and ask: can all the possible result codes the lab produces be found in this file? You may also want to have a senior lab expert review the file for completeness.

File format and delimiters for your source files

For RELMA to import your local codes, they must be in a delimited file. This file may be delimited by either tabs, semi-colons, commas or the vertical bar character ( | ). RELMA can import your local codes directly from Excel, but I’ve noticed a few bugs in the process, so for now I recommend using Excel to get your source files in good shape, and then export them (save as) to a CSV (comma separated values) text file.

For any delimiters other than the Tab or vertical bar character, all text should be surrounded by quotes to ensure proper parsing by RELMA. Excel will do this for you automatically when you save as a CSV file.