Storing Quantities: Original Unit, Canonical Unit, or Both

A source lab sends glucose in mg/dL. Your integration ingests it, and downstream your FHIR store holds it. Do you store the original mg/dL, convert to canonical mmol/L, or keep both? Each choice has real consequences for downstream analytics, clinical alerting, and vendor comparability. Making the choice deliberately once beats making it inconsistently forever. The site's Clinical UCUM unit converter handles the conversion; the storage decision lives with the platform. For the wider FHIR framing, the rest of our FHIR series has more.

Store Original Only

Pro: no conversion at ingest, no loss of information, source system is authoritative.

Con: downstream analytics and alerting have to know the unit at query time. Cross-source comparability requires per-query conversion.

Use this when: the workload is source-specific, downstream consumers know the source's conventions, or the source's unit is regulatory.

Store Canonical Only

Pro: uniform downstream queries, alerting rules that work across sources, comparable across labs and payers.

Con: source's original unit is lost. Roundtrip to the source is not possible. Conversion errors at ingest propagate silently.

Use this when: downstream analytics dominate, cross-source comparability is high-value, and you trust your conversion pipeline.

Store Both

Pro: everything above, plus roundtrip preservation and audit visibility.

Con: two fields per quantity — slight schema overhead and the responsibility to keep them in sync.

Use this when: you can afford the storage overhead and you value both source fidelity and downstream ergonomics.

Most CMS-relevant systems store both.

The FHIR-Native Way To Store Both

Observation.valueQuantity holds the primary value. Extensions on the Quantity can hold the alternative representation:

The primary is either the source's unit or the canonical unit
Quantity.extension carries the other via a well-known extension URL
Downstream systems dispatch on whichever the primary carries

That is FHIR-native and does not violate the Observation contract.

For the analyte-specific conversion pitfalls, unit conversion errors that reach clinical decisions is the entry.

What Not To Do

Do not silently rewrite unless the pipeline logs the original
Do not lose the source system reference — you may need to roundtrip later
Do not use free-text unit fields — every downstream converter will guess

Reference Ranges Follow The Unit

If your Observation stores mg/dL, the reference range should be in mg/dL. If canonical is mmol/L, the reference range should also be mmol/L. Mixing scales in one Observation is where "clinician sees a green result on a value that would be red in the other unit" happens.

For the strict-form contract, UCUM in Observation.valueQuantity: the strict version covers the mechanics.

Cross-Source Comparability Costs

A canonical-only store makes cross-source comparability cheap. An original-only store makes it expensive per query. A both-store makes it cheap but requires ongoing pipeline discipline.

Pick per your workload's cost sensitivity.

Alerting Rules That Survive Ingest Changes

Alerting rules keyed to a specific unit break when the ingest pipeline changes. Canonical storage protects against this. Original storage does not.

For safety-critical workflows, canonical (or both) is the safer choice.

The Short Version

Original preserves fidelity. Canonical preserves ergonomics. Both preserve everything and requires discipline. Pick per workload and stick with it. For the canonical set, canonical UCUM units the FHIR spec assumes you'll use is the entry.