The first three levels can often be bounded with strong schemas, source evidence, terminology, and deterministic validation. Levels four and five require much stronger clinical governance, intended-use analysis, qualified review, and potentially regulatory assessment depending on the software function.

LOINC provides universal identifiers for laboratory and clinical observations. It is useful when local lab names need to be mapped into a consistent terminology so results from different systems can be exchanged, grouped, and queried with less ambiguity.

A LOINC map should never replace the raw source label. Store the local name and code, the mapped LOINC code where appropriate, mapping version, mapping method, and review state. A wrong standardized code is harder to notice than an unfamiliar local label.

Reference intervals are not universal constants. They can depend on the performing laboratory, method, specimen, population, age, sex, pregnancy status, units, and other factors. A robust system should first preserve the interval and flag supplied by the reporting laboratory.

CMS CLIA materials state that pertinent reference intervals or normal values, as determined by the laboratory performing the tests, must be available with test reporting. The software should not silently substitute its own generic "normal range" for the range attached to the source result.

Longitudinal analysis is useful only when the system knows it is comparing compatible measurements. The same display name can hide different methods, specimens, units, or reference intervals.

{
  "patient_ref": "patient_123",
  "report_status": "final",
  "performing_lab": "Example Lab",
  "collection_at": "2026-08-20T09:14:00-05:00",
  "results": [{
    "raw_name": "Analyte A",
    "loinc_code": null,
    "value": 13.4,
    "unit": "unit_example",
    "reference_low": 12.0,
    "reference_high": 16.0,
    "source_page": 1,
    "evidence_text": "Analyte A 13.4 unit_example 12.0-16.0",
    "validation_state": "accepted"
  }],
  "requires_review": false
}

The example is intentionally non-clinical. In production, the schema should also support textual results, qualitative values, repeated components, comments, specimen context, preliminary status, unbounded reference intervals, and explicit uncertainty.

If lab reports containing ePHI are processed by cloud storage, OCR, AI, logging, queueing, or other vendors on behalf of a HIPAA covered entity or business associate, the architecture must evaluate those vendors and the actual data flow. HHS guidance states that a cloud service provider creating, receiving, maintaining, or transmitting ePHI on behalf of a regulated entity is generally a business associate and requires an appropriate BAA.

Software that only transfers, stores, converts, or displays data presents a different regulatory question from software that interprets laboratory results and gives patient-specific clinical recommendations. FDA's January 2026 final Clinical Decision Support Software guidance explains the criteria used to distinguish certain non-device CDS functions from functions that remain device software.

Do not infer regulatory status from the label "AI" or "lab analysis." Evaluate each software function based on intended use, user, input, output, recommendation, transparency, and whether the healthcare professional can independently review the basis for the recommendation. Patient-facing and caregiver-facing functions can raise different considerations.