LOINC Device Integration

What is LOINC device integration?

LOINC device integration is the practice of labelling every measurement a device produces with a standard LOINC code that says what was measured, and a UCUM unit that says how it is expressed. It lets an EHR, registry or analytics tool recognize a reading from any device without knowing anything about the vendor.

LOINC answers the question "what is this number?" and UCUM answers "in what unit?". Both are needed: a code without a unit is ambiguous, and a unit without a code is meaningless.

Device measurements need LOINC codes because vendor labels vary and receivers cannot map every vendor separately. One device calls it "pulse", another "HR", a third "heart_rate_bpm". A single standard code removes that guesswork for every system downstream, and the benefits show up in several places at once.

• EHR filing: Interface teams map incoming codes to flowsheet rows once, instead of once per device model.
• FHIR conformance: The FHIR R4 vital signs profile requires specific LOINC codes for common measurements.
• Analytics: Population queries work across devices only when the same quantity has the same code.
• Billing evidence: Remote monitoring programs need clear records of which physiologic data was collected and when.

Which LOINC codes does the FHIR vital signs profile use?

The FHIR R4 vital signs profile names one LOINC code for each common vital sign, and any Observation claiming to be a vital sign must use it. Additional, more specific codes can be added alongside, but the profile code must be present.

• 85353-1: Vital signs panel, used to group a set of vital signs taken together.
• 9279-1: Respiratory rate, in breaths per minute with the UCUM unit /min.
• 8867-4: Heart rate, in beats per minute with the unit /min.
• 2708-6: Oxygen saturation in arterial blood, in percent, where 59408-5 for pulse oximetry may be added as a second code.
• 8310-5: Body temperature, in Cel or [degF].
• 8302-2: Body height, in cm or [in_i].
• 29463-7: Body weight, in g, kg or [lb_av].
• 39156-5: Body mass index, in kg/m2.
• 85354-9: Blood pressure panel, with systolic and diastolic as components.

The profile also requires each vital signs Observation to carry a status, the vital-signs category, a code, the patient, an effective time and a numeric value with a UCUM unit, or a reason the value is absent.

How should blood pressure be coded from a device?

Blood pressure should be sent as one Observation coded 85354-9, with systolic 8480-6 and diastolic 8462-4 as components, each in mm[Hg]. Sending systolic and diastolic as two separate Observations is a common mistake that breaks EHR display and queries.

• Panel code: 85354-9 on the Observation itself.
• Systolic component: Code 8480-6, value in mm[Hg].
• Diastolic component: Code 8462-4, value in mm[Hg].
• Pulse: Most cuffs also report pulse, which belongs in its own heart rate Observation coded 8867-4.
• Context: Body position, cuff site and cuff size can be added where the device reports them.

There is a search consequence too. The FHIR specification notes that searching by code 85354-9 does not return the component codes, so a query for systolic values needs the combined code and component search parameter. Build your queries with that in mind.

What role does UCUM play in device data?

UCUM, the Unified Code for Units of Measure, gives each unit a precise, machine-readable code so systems can convert and compare values safely. It covers units used in science, engineering and business, and was created in 1999 by Gunther Schadow and Clem McDonald.

• Exact syntax: UCUM codes are case sensitive and precise, such as mm[Hg], /min, Cel and kg/m2.
• Display versus code: The display text can say "bpm" for people, while the coded unit is /min for machines.
• Conversion: A receiver can convert [lb_av] to kg because both are defined units, which fails with free text like "lbs".
• Annotations: Curly-brace annotations such as {beats} are display hints and should not replace a proper unit code.

Unit errors are the most dangerous coding bug because the value still looks plausible. A weight of 80 that is really pounds, filed as kilograms, can change a medication dose. Validate the unit for every code in your mapping tests.

How do IEEE 11073 codes relate to LOINC?

IEEE 11073 codes come from the device world and LOINC codes from the clinical world, and integrations often need both. Hospital devices following IHE PCD send ISO/IEEE 11073-10101 nomenclature in OBX-3 of the PCD-01 message, while EHRs and FHIR profiles expect LOINC for vital signs.

In practice, the gateway or interface engine keeps the device code and adds or translates to LOINC where the receiver needs it. In FHIR, an Observation can carry both codings in its code element, which preserves the device's precise meaning while satisfying the vital signs profile.

• Keep the source code: The 11073 code is often more specific, such as which method or site produced the value.
• Add the profile code: Include the LOINC code the receiving profile requires.
• Map carefully: Not every 11073 parameter has a LOINC equivalent, so some stay device-only.

How are LOINC codes carried in HL7 v2 messages?

In HL7 v2, the LOINC code travels in the OBX segment, with the code system marked as LN, the value in OBX-5, the unit in OBX-6 and the measurement time in OBX-14. Many EHRs still receive device data this way, so the same mapping table has to serve v2 and FHIR.

• OBX-2: The value type, NM for a numeric reading.
• OBX-3: The observation identifier, such as 8867-4 with the display Heart rate and the system LN.
• OBX-5: The numeric value itself, without units or text.
• OBX-6: The unit, coded with UCUM where the receiver supports it.
• OBX-14: The date and time of the observation, which should be the measurement time.

Check what the receiving interface actually expects. Some EHR interfaces map on their own local codes and ignore LOINC, while others require it. Agreeing a sample message with the receiving team before you build removes most of the back and forth during testing.

How should remote monitoring readings be grouped and timed?

Group readings the way they were taken and time them by when they were measured. A blood pressure and pulse taken in one cuff cycle belong together, while a weight taken an hour later is a separate event, even if both arrive in the same upload.

For home devices, the measurement time comes from the device clock, which may be wrong after a battery change or time zone shift. Store the device time, the time your system received the reading and a flag when the two differ by more than you expect, so reviewers can spot suspicious timestamps.

Record the device too. A FHIR Observation can reference a Device resource with the manufacturer, model and serial number, which helps clinicians judge a reading and helps your team trace a mapping problem to one model.

How do you build a device to LOINC mapping table?

Build the mapping table one device model at a time, listing every parameter the device can send, its vendor code and unit, and the LOINC code, UCUM unit and conversion your system will use. Review it with a clinician before any data flows.

• Inventory: Pull the parameter list from the device's interface specification, not from sample data, which may miss rare values.
• Columns: Vendor label, vendor code, vendor unit, LOINC code, LOINC display, UCUM unit, conversion factor and notes.
• Unmapped values: Decide whether each unmapped parameter is dropped, stored only in raw form or given a local code.
• Versioning: Store the table in version control, since firmware updates can add or rename parameters.
• Ownership: Name one clinical informatics owner who approves changes.

Resist the urge to pick the most specific LOINC code available for every value. A code the receiving EHR does not recognize is worse than the profile code it does. Agree the target codes with the receiving systems first.

Where do LOINC device mappings go wrong?

• Split blood pressure: Systolic and diastolic sent as separate Observations instead of components of 85354-9.
• Free text units: Units such as "bpm" or "lbs" in the code field instead of UCUM codes.
• Wrong SpO2 code: Pulse oximetry sent without the required 2708-6 profile code.
• Lost precision: Values rounded during conversion, such as temperature converted twice between scales.
• Missing time: Using the time the message was sent instead of when the measurement was taken.
• Missing category: Observations without the vital-signs category, which FHIR validators reject.

Most of these are caught by running every message through a FHIR validator with the vital signs profile in a test pipeline. Add a small set of hand-checked messages per device model, and rerun the set whenever the mapping table changes.

How Agnotic can help

Agnotic Technologies builds device and wearable integrations that produce correctly coded data from the start. We write mapping tables with your clinical team, implement LOINC and UCUM normalization in gateways and pipelines, and validate output against FHIR profiles and the receiving EHR.

For existing integrations, we audit codes and units in your stored data, find mismatches and fix the mapping without losing history. Where a device fleet spans several vendors, we build one shared mapping table so every model lands on the same codes, and we add validation to your pipeline so new firmware cannot slip in unmapped values.

Sources

• HL7 FHIR R4: Vital signs profile
• UCUM: The Unified Code for Units of Measure
• IHE PCD Technical Framework, Volume 2: Transactions