ELR, HL7, and FHIR: a practical implementation guide
What actually has to be configured to get a state feed live, and why onboarding a new jurisdiction doesn't mean a new build.
A lab is only as useful as its ability to report
Salus generates standards-compliant electronic lab reporting, HL7 v2 ORU^R01 messages with a custom ZLR segment and CLIA as the universal identifier, and exchanges data over FHIR for partners and programs that have moved to it. LOINC is mapped to the observation (OBX-3) and SNOMED CT to the coded result (OBX-5), and both are validated before transmission.
Configuration, not code
The identifiers and facility details every jurisdiction wants slightly differently, MSH, FHS, and BHS facility identifiers, CLIA, and OBX-15, live in configuration and are edited on a Settings screen. That single decision is what makes onboarding a new state feed a configuration change instead of a software release: a new jurisdiction's identifiers are set, and the feed is live.
Multiple ELR destinations and an export queue are managed from the same interface, so you can see exactly what is staged, sent, and acknowledged, rather than inferring delivery status from a state partner's silence.
Where AI fits in this path
Andre, the interoperability persona, validates HL7/FHIR messages and LOINC/SNOMED coding before transmission, so coding problems are caught inside the lab, not returned days later in a state reject report. That validation step is what turns "we sent it and hope it was accepted" into a checked, auditable step in the workflow.
Instruments, not just state feeds
Interoperability isn't only outbound. Standardized instrument interfaces connect analyzers directly, so results land in the same verification workflow as any manually entered result, one results pipeline regardless of where a result originated.
See it in your laboratory's context.
Explore the live demo, no login and no request form.