Device Unit Conversions: Reconcile Displayed, Stored, and Exported Values

FDA does not prescribe a named rounding or unit-conversion test. Instead, regulators expect risk-scaled design and verification evidence proving that your device software preserves numeric fidelity across every representation a clinical value passes through: internal memory storage, on-screen user display, and external message export. When a device stores a patient measurement or dose in one unit and binary format, rounds it for a bedside display, and serializes a decimal string with a unit code to a hospital electronic health record (EHR) or therapy controller, any unverified drift or unit mismatch across those boundaries is a design and verification gap.

Under FDA's final guidance Content of Premarket Submissions for Device Software Functions (issued June 14, 2023), which superseded the May 11, 2005 software guidance, recommended premarket software documentation scales to either a Basic or Enhanced Documentation Level. FDA recommends Enhanced documentation where a failure or flaw of any device software function could present a hazardous situation with a probable risk of death or serious injury, assessed before risk control measures are applied. Separately, under the Quality Management System Regulation (QMSR) in force since February 2, 2026, 21 CFR 820.10(c) requires manufacturers of Class II and Class III devices, and of Class I devices automated with computer software (plus a short list of other Class I devices), to comply with Design and Development, Clause 7.3 and its subclauses of ISO 13485 (incorporated by reference through 21 CFR 820.10(a)). For connected systems, FDA's final guidance Design Considerations and Pre-market Submission Recommendations for Interoperable Medical Devices (September 6, 2017) names the exact unit failure to guard against—the transmission of weight in kilograms when the receiving medical device assumes the measurement is in pounds—and warns that such errors "could lead to patient harm and even death". It recommends documentation showing that the device interface meets its design specifications and that the device performs safely when it receives data outside of specification.

What Regulators Actually Require (and Do Not Name) for Unit Conversions and Rounding

When regulatory affairs, quality assurance, and software engineering teams prepare a premarket submission or defend a design history file (or its ISO 13485 design and development file equivalent), they often search for an official FDA rounding table or a standard conversion tolerance. None exists. FDA's software guidance does not prescribe universal decimal digit counts, and no single digit rule could fit every parameter: a 0.1-unit discrepancy means something completely different for an adult body-weight entry in kilograms than for a neonatal opioid bolus in milligrams.

Instead, FDA and incorporated quality-system regulations establish a three-part evidentiary structure that governs how numeric values are represented, converted, displayed, and exchanged:

1. Quality-system design and development (21 CFR 820.10(c)): FDA published the QMSR final rule on February 2, 2024 (89 FR 7496), effective February 2, 2026; it amended 21 CFR Part 820 to incorporate ISO 13485:2016 by reference (21 CFR 820.10(a), see 820.7). Under 21 CFR 820.10(c), manufacturers of Class II and Class III devices and of listed Class I devices—including any Class I device "automated with computer software"—must comply with Design and Development, Clause 7.3 and its subclauses of ISO 13485. As the QMSR note at the front of FDA's 2023 software guidance explains, the QMSR does not use terms such as "Design Controls" and "Design Validation"; the elements behind those terms are described in ISO 13485:2016 Clause 7.3 and its subclauses. Consequently, numeric precision, unit conversion factors, rounding modes, and acceptable cross-representation tolerances belong in your design inputs and software requirements, and their verification records belong in your design and development file.

2. Premarket software documentation and V&V scaling (June 14, 2023 FDA final guidance): In Content of Premarket Submissions for Device Software Functions, FDA scales recommended submission content to a Basic or Enhanced Documentation Level, assessed for the device as a whole and before risk controls. If a flaw in unit conversion, floating-point serialization, or display rounding could present a hazardous situation with a probable risk of death or serious injury—such as a 2.2-fold weight-based dosing error or a truncated decimal on a high-potency infusion—that points to the Enhanced Documentation Level. For software testing as part of verification and validation (Section VI.H), FDA recommends at Basic a summary description of unit, integration, and system testing (including the software version tested and overall pass/fail results), regression analysis and testing where applicable, and a system-level test protocol and report with expected results derived from software requirements, actual results, and pass/fail determination. Enhanced adds all unit- and integration-level test protocols and reports, with expected results derived from software requirements and design alongside actual results.

3. Architecture and interface verification (2023 Software Guidance and 2017 Interoperability Guidance): The 2023 software guidance recommends system and software architecture design charts that depict modules, layers, and interfaces, their relationships, the data inputs and outputs, and the flow of data. For devices that exchange data with other medical devices or hospital IT systems, FDA's September 6, 2017 final guidance on interoperable medical devices recommends premarket performance testing covering verification that the device interface meets its design specifications, validation that the interface performs as intended, and testing that corrupted or out-of-bounds received data can be detected and appropriately managed. Note that because the 2017 interoperability guidance predates the 2026 QMSR, it uses legacy design-control vocabulary; teams should read its technical interface verification expectations alongside current 21 CFR 820.10(c) legal obligations.

For the software development, configuration management, and maintenance practices element, the 2023 guidance also lets a sponsor provide a Declaration of Conformity to the FDA-recognized version of IEC 62304 instead of the narrative documentation—at the Enhanced level, including subclause 5.1 (software development planning), clause 6 (software maintenance process), and clause 8 (software configuration management process), among others as applicable. That option is tied to the FDA-recognized edition: a revision still moving through IEC committee stages is not a recognized standard, and neither committee progress nor publication of a new edition is the same as FDA recognition or legal adoption. For lifecycle structuring details, see our IEC 62304 Medical Device Software Lifecycle Implementation Guide.

Where One Value Becomes Three: Display, Storage, and Export

In a regulated medical device, a single quantitative clinical parameter rarely exists as a single immutable data structure. Even when no unit conversion takes place, software architecture routinely splits one measurement or therapy setting into three distinct representations:

• The internal stored representation: The binary value held in RAM, non-volatile device logs, or a local database—typically an IEEE Std 754-2019 binary floating-point type (binary32 or binary64), a decimal floating-point type (decimal64), or a fixed-point scaled integer (for example, micrograms per hour stored as an integer count of nanograms per hour).

• The on-screen displayed representation: A human-readable character string rendered on the clinician or patient user interface, formatted to a fixed number of decimal places or significant digits so operators can read and confirm settings rapidly without visual clutter. (Note that runtime software display formatting is distinct from static packaging and IFU artwork control; for artwork reconciliation under QMSR 820.45 and EU MDR GSPR 23, see Device Label Translation: Reconciling Units, Symbols, and Released Versions.)

• The exported interface representation: A serialized decimal string paired with a unit identifier inside an external communication payload—such as an HL7 v2 OBX segment, an HL7 FHIR R5 Quantity structure, or an IEEE 11073 nomenclature frame—transmitted to an EHR, patient monitor gateway, or closed-loop controller.

Why do these three representations diverge even in well-engineered code? The underlying mechanics are defined by IEEE Std 754-2019, IEEE Standard for Floating-Point Arithmetic. IEEE describes the standard as specifying interchange and arithmetic formats and methods for binary and decimal floating-point arithmetic, together with exception conditions and their default handling, and notes that numerical results are uniquely determined by the input values, the sequence of operations, and the destination formats. Conversion between floating-point numbers and decimal strings has been within the standard's scope since the original IEEE 754-1985. In practice, the storage format and the order of conversion and rounding steps are design decisions that change the number a device ends up showing or sending.

In binary floating-point (binary64 / standard IEEE double precision), only fractions whose denominators are powers of two can be represented exactly. A decimal value such as 0.1, 12.35, or 74.84 has a non-terminating binary expansion. When the software converts a decimal string entered by a clinician into binary64, multiplies it by a unit-conversion factor (for example, 0.45359237 kilograms per avoirdupois pound), and later formats the result into a decimal string for display or JSON/XML export, rounding can occur at each step: when the entered decimal string is parsed into binary64, when the product is rounded to binary64 precision, and when the result is formatted back into a decimal string. If the display layer formats 12.34999999999999964473... to one decimal place using naive half-up rounding on the binary approximation rather than decimal-aware rounding anchored to the original value, the screen shows 12.3 while a round-half-to-even decimal rule on 12.35 yields 12.4 and the exported FHIR payload sends "12.35".

At the export boundary, numeric divergence compounds with unit-coding ambiguity. Maintained by the Regenstrief Institute and originally created in 1999 by Gunther Schadow and Clem McDonald, the Unified Code for Units of Measure (UCUM) provides a computer-processable code system intended to cover all units of measure used in international science, engineering, and business. In HL7 FHIR R5 (Quantity datatype definitions), Quantity.code represents the computer-processable form of the unit, and the specification explicitly states: "The preferred system is UCUM, but SNOMED CT can also be used (for customary units)". Furthermore, FHIR invariant qty-3 enforces a strict structural rule: If a code for the unit is present, the system SHALL also be present. An export module that sends a human display label (Quantity.unit = "lbs") without a canonical Quantity.code ("[lb_av]") and Quantity.system ("http://unitsofmeasure.org") forces the receiving system to guess the unit—setting up the exact interoperability hazard FDA warns against.

flowchart TD
    A["Source Measurement or Operator Entry<br/>(Original Value + Native Unit)"] --> B["Immutable Reference Record<br/>(Audit Anchor in Native Unit)"]
    B --> C["Internal Storage Boundary<br/>(IEEE 754-2019 Binary/Decimal or Scaled Integer)"]
    B --> D["Clinician UI Display Boundary<br/>(Formatted String + NIST SP 811 B.7 Rounding)"]
    B --> E["External Export Boundary<br/>(Decimal String + FHIR Quantity.code & system in UCUM)"]
    C --> F["Internal Dose / Therapy / Alarm Algorithm"]
    D --> G["Operator Visual Confirmation"]
    E --> H["Receiving Device or Hospital EHR Interface"]
    F --> I{"Cross-Representation Verification<br/>(Unit, Integration & System Tests)"}
    G --> I
    H --> I
    I -->|"Within Manufacturer Tolerance"| J["Verified Design File Evidence<br/>(21 CFR 820.10(c) & 2023 FDA Guidance)"]
    I -->|"Exceeds Tolerance or Unit Mismatch"| K["Software Anomaly / Risk & CAPA Evaluation"]

The Documented Failures: Kilograms Assumed as Pounds, Key Bounce, and Panama

Regulators scrutinize numeric representation, unit conversion, and input-to-display verification because failures at these boundaries have a long, documented history of severe patient harm and high-volume recalls. Four primary sources illustrate how representation defects manifest in clinical environments:

1. Kilograms Transmitted When Pounds Are Assumed (FDA 2017 Interoperability Guidance)

In its September 6, 2017 final guidance Design Considerations and Pre-market Submission Recommendations for Interoperable Medical Devices, FDA uses a unit-of-measure mismatch as its example of an error stemming from inadequate interoperability: "the transmission of weight in kilograms when the receiving medical device assumes the measurement is in pounds, and could lead to patient harm and even death." Because 1 kilogram equals approximately 2.20462 avoirdupois pounds, a receiving device that interprets a transmitted 70 (meant as kilograms) as 70 lb—or a transmitted 154 (meant as pounds) as 154 kg—scales any weight-based calculation by a factor of about 2.2 while still showing a plausible-looking number on screen.

2. Key Bounce and Pounds-Versus-Kilograms Confusion (FDA Infusion Pump Initiative)

In the White Paper: Infusion Pump Improvement Initiative, FDA reported receiving approximately 56,000 adverse-event reports associated with infusion pumps from 2005 through 2009, a period in which firms conducted 87 infusion pump recalls. FDA reported that the most common types of reported problems were associated with software defects, user-interface issues, and mechanical or electrical failures, and concluded that many problems appear related to deficiencies in device design and engineering. Two numeric-representation examples from the white paper are directly relevant:

• Key bounce: FDA describes a software problem in which a pump occasionally registered one keystroke as multiple keystrokes—a single "0" registered as "00". One extra digit changes the programmed magnitude (an intended 10 becomes 100, for example), which is why entry-to-display-to-internal-value verification matters.

• Unclear weight units: FDA notes that a pump screen may not make clear which units of measurement (for example, pounds versus kilograms) should be used to enter patient data, leading to inappropriate dosing.

For a broader breakdown of how software and alarm failures continue to drive postmarket enforcement, see our analysis of FDA Infusion Pump Recalls and Class I Software-and-Alarm Causes.

3. Software Defects Across 627 Recalled Devices (Milbank Quarterly Analysis)

The infusion-pump experience reflects a wider pattern across regulated medical software. A peer-reviewed study by Ronquillo and Zuckerman published in The Milbank Quarterly (2017; 95(3):535–553) examined FDA recall records from 2011 through 2015 and found 627 software devices encompassing 1,447,134 units (about 1.4 million units) recalled due to software defects, including 12 devices (190,596 units) classified in the highest-risk Class I recall tier. Keep the evidentiary boundary of this dataset clear: the Milbank study covers the 2011–2015 period (predating both the June 2023 FDA software guidance and the 2026 QMSR) and establishes that software defects are a persistent, high-volume recall driver, though it does not isolate a specific contemporary recall percentage for unit-conversion defects alone.

4. Identical Display Diagrams Hiding Doubled Treatment Times (IAEA Panama Investigation)

The most sobering historical lesson on why visual display checks cannot substitute for underlying numeric verification comes from the International Atomic Energy Agency's investigation in Panama, documented in IAEA Report Pub1114: Investigation of an Accidental Exposure of Radiotherapy Patients in Panama. Between August 2000 and March 2001, 28 patients treated for prostate cancer and cancer of the cervix were overexposed after the department changed the way it digitized shielding blocks into its computerized treatment planning system (TPS), entering several blocks as if they were a single block to get around the system's limit of four blocks per field. By the time of the IAEA mission in May 2001, eight of the 28 patients had died, and at least five of those deaths were probably radiation-related.

As the IAEA report details, the TPS accepted several different ways of digitizing the blocks, gave no on-screen warning when blocks were digitized differently from the way prescribed in the manual, and—when blocks were digitized incorrectly—produced a diagram that was the same as the one produced for a correct entry, giving the impression that the calculated results were correct. For at least one of these entry methods the computed treatment times were about twice those required, and the modified protocol was used without a verification test such as an independent manual calculation of treatment time. Note the exact scope of this evidence: the Panama overexposures arose from hospital treatment-planning practice and an untested data-entry pathway, not from a decimal-rounding algorithm or a US FDA recall. The engineering lesson for device software teams is that a representation that looks right on screen can mask a severe underlying computational discrepancy. The IAEA recommended that treatment-planning quality control include verification by manual calculation of treatment time and dose, that software be tested to make it as foolproof as possible, and that deviations from the instructed entry steps be prevented by warnings in the instructions and on the screen.

A Synthetic Precision and Rounding Crosswalk That Preserves the Original Unit

To prevent silent divergence between what a device stores, what it displays, and what it exports, engineering teams need a disciplined mathematical anchor for unit conversions and rounding. While FDA does not mandate a specific metrological standard for decimal rounding, US manufacturers can anchor their software requirements to NIST Special Publication 811 (2008 edition), Appendix B: Conversion Factors.

Keep NIST SP 811's scope and date in view: it is the 2008 edition (NIST's SP 811 landing page notes that it has not yet been updated for the changes in the SI that took effect on May 20, 2019), and it is a metrological guide for unit conversion rather than an FDA medical-device regulation. Nevertheless, Sections B.7.1 and B.7.2 give a transparent, non-arbitrary way to reason about the "how many digits should we keep after converting units?" question:

• Rounding mechanism (NIST SP 811 Section B.7.1): When rounding a number to fewer digits, if the digits to be discarded begin with a 5 followed only by zeros (or nothing), NIST B.7.1's third rule applies round-to-even (also aligned with IEEE 754's default roundTiesToEven attribute for binary results): the preceding digit is left unchanged if it is even and increased by 1 if it is odd. If a clinical risk analysis requires a different rounding rule for a specific therapy parameter (such as conservative downward rounding on a maximum dose ceiling), that deviation and its clinical rationale must be explicitly owned and documented in the design file.

• Significant-digit retention after conversion (NIST SP 811 Section B.7.2): Section B.7.2 says proper conversion procedure rounds the converted numerical value to the number of significant digits consistent with the maximum possible rounding error of the unconverted value. NIST reasons in relative rounding error and acknowledges that one must often choose between discarding information (rounding too coarsely) and providing unwarranted information (retaining false precision), with the end use of the converted value helping decide.

Worked Digit-Discipline Example: From NIST's 36 ft Benchmark to a Bedside Weight Conversion

NIST SP 811 Section B.7.2 illustrates the rule by converting 36 ft with the exact factor 0.3048 m/ft: 36 ft × 0.3048 m/ft = 10.9728 m, which NIST reports as 11.0 m. Its reasoning uses relative maximum possible rounding error (RE). The value "36" could have resulted from rounding any number between 35.5 and 36.5, so its RE is ±0.5/36 = ±1.4%. The converted value 11.0 has an RE of ±0.05/11.0 = ±0.45%, one-third of the source's. Rounding to 11 instead would give an RE of ±0.5/11 = ±4.5%, three times the source's, and information contained in the original value would be lost. NIST draws the general lesson that, when selecting the digits to retain in a converted value, one must often choose between discarding information and providing unwarranted information, and that the end use of the converted value can help decide. In a follow-up note, where the 36 ft value is known more precisely (RE ±0.23%), NIST still gives 11.0 m because its RE is comparable, and says 10.97 would give excessive unwarranted information.

Now transpose that logic to a device value. An operator enters a patient weight of 165 lb from a scale that reads in whole pounds, so the entry could stand for anything from 164.5 to 165.5 lb: an RE of ±0.5/165 ≈ ±0.30% (±0.227 kg after conversion). Multiplying by the exact avoirdupois factor 0.45359237 kg/lb gives 74.84274105 kg. Three display candidates bracket the decision: 75 kg (RE ±0.67%, about 2.2 times the source's, which discards information and shifts this value by +0.157 kg); 74.8 kg (RE ±0.067%, less than one-quarter of the source's); and 74.84 kg (RE ±0.0067%, roughly 1/45 of the source's, which plainly provides unwarranted information). Against NIST's own examples—where a converted RE of one-third and of roughly twice the source's were both accepted, while three times and one-fifth were rejected—75 kg and 74.8 kg both sit near the edges, which is exactly the situation in which B.7.2 says the end use should decide. If the converted weight feeds a weight-based dose calculation, a team may justify displaying and exporting 74.8 kg so that the conversion step adds less error than the scale already carries, while retaining the original 165 lb entry as the audit reference. A team that displays 75 kg instead should show that its risk analysis accepts the extra rounding. Either way, the digit count is a documented design decision with a stated rationale, not a value read off a NIST table.

Look closely at the third and fourth rows of the crosswalk. In Row 3 (12.35 mL/h), storing the number in IEEE 754 binary64 produces 12.34999999999999964473... because 12.35 cannot be represented exactly in base-2 floating-point. If a UI formatting routine applies standard half-up or half-even rounding directly to that slightly smaller binary approximation without decimal-aware scaling, it rounds down to 12.3 mL/h instead of 12.4 mL/h. In Row 4 (37.55 °C), converting to Fahrenheit for display (99.6 °F) and then reconverting that displayed number back into Celsius yields 37.56 °C—a +0.01 °C drift on a single round trip. If software overwrites the stored value each time a user toggles units on screen, repeated toggles will walk the stored value away from the true measurement. Keeping the original-unit value as the read-only reference eliminates round-trip creep entirely.

Turning the Crosswalk into Requirement and Risk Evidence

A crosswalk table only protects patients and satisfies reviewers when its rules are embedded into your design and development records under 21 CFR 820.10(c) (ISO 13485:2016 Clause 7.3) and scaled to the premarket submission deliverables in FDA's June 14, 2023 software functions guidance. During design reviews and premarket audits, four practical implementation questions consistently arise:

1. Where Should the Precision Requirement Live—Software, Display/Labeling, or Both?

It must live in both your software requirements specification (SRS) and your user-interface/display design specification, linked by a single traceability chain to your risk management file:

• Software requirements (data layer & business logic): Specify the internal storage format (for example, scaled integer nanograms or IEEE 754 binary64), mandate retention of the original-unit value and native unit code as the reference record, define the exact conversion factor (such as 0.45359237 kg/lb for the international avoirdupois pound rather than a rounded 2.2 lb/kg), and prohibit back-computing internal control variables from rounded display strings.

• User-interface and display requirements: Specify the exact number of displayed decimal places or significant digits per parameter and unit, the rounding mode applied at the display boundary (such as NIST B.7.1 round-half-to-even), whether trailing zeros are shown or suppressed, and the visual prominence of the unit symbol (for example, distinguishing kg from lb so operators cannot confuse them).

• External interface requirements: Specify the serialized decimal precision, the mandatory UCUM unit code and system URI, and the rejection behavior when incoming messages omit unit codes or fall outside physiological or device-operating bounds.

2. How Does Verification Evidence Scale Between Basic and Enhanced Documentation Levels?

Under Section VI.H of the 2023 FDA Software Functions Guidance, every representation boundary in your crosswalk should be verified across three testing levels—unit, integration, and system—with the submission package scaled to your Documentation Level:

• Unit-level testing: Exercises the conversion, rounding, and serialization functions in isolation across boundary inputs: exact halfway ties (.x5, .x5000), minimum and maximum physiological limits, zero and negative inputs, high-precision repeating decimals, and IEEE 754 exception values (NaN, +Infinity, -Infinity, subnormal numbers).

• Integration-level testing: Verifies data handoffs between software modules depicted on your architecture diagram—confirming that the storage module, dosing/therapy engine, UI presentation layer, and FHIR/HL7 serializer preserve numeric equivalence and unit codes across module interfaces.

• System-level testing: Executes end-to-end clinical workflows on the integrated device: entering a value at the UI (including rapid keypress testing to verify absence of key bounce), verifying the displayed value and unit, confirming the internal therapy output or alarm trigger, and inspecting the exported message payload.

At the Basic Documentation Level, FDA recommends a summary description of these unit, integration, and system testing activities (identifying the software version tested and the overall pass/fail results), regression analysis and testing where applicable, and the system-level test protocol and report, with expected results derived from software requirements, actual results, and an objective pass/fail determination. At the Enhanced Documentation Level, FDA additionally recommends all unit- and integration-level test protocols and reports, showing the expected results derived from software requirements and design alongside the actual results observed during test execution. For crosswalk rows, that means even a Basic submission should carry system-level expected-versus-actual evidence for end-to-end conversions, while Enhanced puts the unit-level rounding and serialization cases themselves in front of the reviewer. For deeper guidance on structuring protocols and traceability matrices, see our Medical Device Software Verification vs. Validation Guide.

3. Using Architecture Diagrams to Map Conversion Boundaries

The 2023 FDA guidance recommends system and software architecture diagrams that clearly illustrate modules, layers, and interfaces, their relationships, the data inputs and outputs, and the flow of data. Annotating your architecture diagram with the native unit and representation type on every internal connector—for example, showing that the Sensor Acquisition Module outputs uint32_t microliters_per_hour, the Therapy Controller consumes uint32_t microliters_per_hour, the UI Presenter converts to mL/h (1 decimal, ties-to-even), and the Telemetry Adapter serializes mL/h (2 decimals, UCUM 'mL/h')—shows reviewers exactly where display rounding is isolated from closed-loop therapy calculations.

4. When Does a Display-Versus-Storage Difference Become a Software Anomaly?

Not every numerical difference between stored and displayed values is a bug. A difference that falls within the specified display-rounding step—where the internal reference value remains intact, the displayed digit matches the documented rounding rule, and the risk analysis accepts the display step—is an accepted, specified representation artifact. IEEE Std 754-2019 explains why such differences arise and NIST SP 811 B.7 gives a principled basis for choosing the step, but the acceptance criterion itself is the manufacturer's to set and justify.

Conversely, a discrepancy becomes a software anomaly that must enter your problem-resolution process, risk management evaluation, and (when systemic or postmarket) Corrective and Preventive Action (CAPA) system whenever any of the following occur:

• The difference between any two representations exceeds the documented requirement tolerance in your crosswalk.

• A unit toggle or round-trip conversion mutates the underlying reference value stored in memory.

• A therapy calculation, bolus limit, or clinical alarm threshold is inadvertently driven by the rounded display string rather than the reference value (or vice versa, causing an alarm to fire while the screen displays an in-range rounded number without explanation).

• An exported message strips the unit code, substitutes an ambiguous display label, or transmits a value in a unit different from what the interface contract specifies.

Verifying the Exported Side of the Interface

Internal software verification is only half of the interoperability problem. As FDA's September 6, 2017 final guidance on interoperable medical devices emphasizes, a device that exports a numerically accurate number can still contribute to patient harm if the receiving system misinterprets the unit of measure or fails to handle out-of-bounds or corrupted data. To address the 2017 guidance's premarket performance-testing recommendations, your interface verification and validation suite should cover three concrete test domains:

1. Verification that the interface meets design specifications: Inspect serialized payloads at the byte/message level to verify that every exported numeric value is accompanied by its machine-readable unit code and coding system. When using HL7 FHIR R5 Quantity, verify compliance with invariant qty-3 (if code is present, system SHALL be present) and confirm that Quantity.code uses the exact case-sensitive UCUM syntax (for example, "kg", "[lb_av]", "mg", "ug", "mL/h", "Cel", "[degF]").

2. Validation that the interface performs as intended: Test the complete sender-to-receiver workflow with representative hospital interface engines or simulated receiving devices, confirming that the receiving clinical display and dosing calculator interpret both the numeric magnitude and the unit identically to the source device.

3. Detection and management of corrupted or out-of-bounds data: Inject fault cases at the interface boundary: missing Quantity.code or Quantity.system, unrecognized unit strings (such as "lbs" or "mcg" where UCUM "[lb_av]" or "ug" is required), locale-corrupted decimal separators ("74,8" vs "74.8"), IEEE 754 non-finite strings ("NaN", "Inf"), and out-of-bounds magnitudes (such as a pediatric weight payload of 150 kg caused by an upstream pound-to-kilogram entry error). Verify that the software rejects the invalid message, logs a diagnostic event, and alerts the operator rather than silently defaulting to a local unit assumption.

{
  "resourceType": "Observation",
  "id": "example-verified-body-weight-export",
  "status": "final",
  "code": {
    "coding": [
      {
        "system": "http://loinc.org",
        "code": "29463-7",
        "display": "Body weight"
      }
    ]
  },
  "valueQuantity": {
    "value": 74.8,
    "unit": "kg",
    "system": "http://unitsofmeasure.org",
    "code": "kg"
  }
}

In the FHIR R5 Observation payload above, valueQuantity.unit carries the human-readable unit ("kg"), while valueQuantity.system ("http://unitsofmeasure.org") and valueQuantity.code ("kg") carry the UCUM coding and satisfy rule qty-3. Remember the specification boundary in HL7 FHIR R5 datatypes-definitions: at the base Quantity datatype, UCUM is the preferred system (SNOMED CT can also be used for customary units), and the specification adds that the context of use may additionally require a code from a particular system. Your interface design specification should therefore state explicitly which UCUM codes your device emits and accepts, and whether any receiving profile requires them.

Boundaries: Non-Device Relay Software, Assay Precision, and What This Guide Does Not Claim

Because unit conversion and numerical precision touch several adjacent regulatory domains, RA/QA teams should keep three explicit boundaries in mind when applying this guide:

1. Regulated Device Software vs. Non-Device-MDDS Data-Relay Software

Not every software function that converts formats or displays medical data is a regulated medical device. In Step 5 of FDA's Digital Health Center of Excellence software decision tree, FDA explains that software functions solely intended for transferring, storing, converting formats, or displaying clinical laboratory test or other device data and results are not medical devices; FDA refers to them as Non-Device-MDDS, excluded from the device definition by section 520(o)(1)(D) of the FD&C Act. The same page explains that a software function may be a device if it controls or alters the functions or parameters of a connected medical device, generates alarms or alerts or provides active patient monitoring, or analyzes or interprets medical device data.

This boundary matters directly to unit-conversion architecture. If a standalone hospital middleware utility merely converts an HL7 message format into a FHIR JSON structure without altering clinical meaning or driving therapy, it may sit in the Non-Device-MDDS lane. By contrast, software embedded in a regulated medical device (or SaMD) that converts patient units to compute a drug dose, scales a physiological waveform, or evaluates an alarm threshold is a regulated device software function subject to 21 CFR 820.10(c) and, where a premarket submission is required, to the documentation recommendations in the 2023 FDA Software Functions Guidance. If a nominally Non-Device-MDDS relay applies its own rounding or unit transformation, reassess it against Step 5: once its function goes beyond transferring, storing, converting formats, or displaying—for example, by interpreting values or altering a connected device's parameters—it no longer fits the Non-Device-MDDS description.

2. Software Representation Fidelity vs. IVD Analytical Performance (LoD / LoQ)

Do not conflate software representation precision with in vitro diagnostic (IVD) assay analytical performance. In IVD validation, terms such as Limit of Detection (LoD), Limit of Quantitation (LoQ), repeatability, and intermediate imprecision measure the wet-lab chemical or biological variability of an assay across replicates and reagent lots. Software floating-point representation and display rounding govern how a computed digital number is stored, formatted, and transmitted after the analytical signal has been processed. Assay-specific analytical limits (LoD/LoQ) must never be extrapolated as software rounding tolerances, and software digit consistency never substitutes for wet-lab analytical validation. For IVD assay validation requirements, see our dedicated IVD Analytical Performance Validation: LoD, LoQ, Precision and Stability Guide.

3. Nonbinding Guidance, Historical Evidence, and Clinical Independence

• Guidance vs. law: FDA's June 14, 2023 software guidance and September 6, 2017 interoperability guidance represent FDA's current thinking and contain nonbinding recommendations. The binding US quality-system legal requirement is 21 CFR 820.10 (incorporating ISO 13485:2016 Clause 7.3).

• Historical and metrological context: The FDA Infusion Pump White Paper (2005–2009 data), the IAEA Panama report (2000–2001 event), and the Milbank Quarterly recall analysis (2011–2015 data) establish real-world failure modes and hazard severity; they do not define current submission formatting rules. Similarly, NIST SP 811 (2008 edition) provides metrological conversion and rounding principles rather than medical-device law.

• Manufacturer-owned tolerances: This article provides engineering and regulatory design-control methodology, not individualized clinical, dosing, or legal advice. Every pass/fail tolerance in a device crosswalk must be established and justified by the manufacturer's own clinical and risk-management team.

Pre-Release Cross-Representation Reconciliation Checklist

Before freezing software requirements or assembling a premarket submission package under FDA's 2023 Device Software Functions Guidance and 21 CFR 820.10(c), run every unit-bearing parameter in your device through this six-step engineering and RA/QA reconciliation checklist: