Skip to content

Specimen Profile

Canonical../StructureDefinition/nexus-emr-core-specimen
Statusdraft (experimental) · 1.26.0
BaseSpecimen (constraint)
SourceFSH · JSON

Nexus EMR profile for Specimen -- the physical sample a lab result was produced from. Currently a pass-through type: the platform resolves ServiceRequest.specimen references and traverses into Specimen from DiagnosticReport, but reads none of its own fields. First pass; the heritage-EMR reconciliation is unresolved.

Overview

Overview

The Nexus EMR Core Specimen profile represents the physical sample a lab result was produced from. In this platform it is chiefly a pass-through and correlation resource: ServiceRequest.specimen references are resolved and rewritten when an eReferral message bundle is relayed, and the patient chart traverses into Specimen from DiagnosticReport.specimen. Neither reads a Specimen's own fields, and nothing in the platform currently consumes status, type or accessionIdentifier.

The profile is #draft and experimental = true. It is a first pass, and the shape it pins is deliberately minimal to match a type the platform passes through rather than interprets. It is reachable by a SMART on FHIR app for read and search only: the profile declares smart-exposed -- this guide's positive flag for app reachability -- and the server capability statement lists it read-only, because nothing in this platform writes a Specimen. Container and processing modelling are out of scope for the same reason: nothing consumes below study level.

accessionIdentifier is the correlation key. identifier frequently is not

identifier (0..*, system and value each 1..1 when present) is the specimen's own id in whatever system minted it. Carry it where the source has it -- the warning-severity specimen-has-raw-identifier invariant that used to ask for it was removed in 1.21.0. accessionIdentifier (0..1) is specifically the performing lab's accession number: the value that ties a result back to the physical sample, reveals when several results derive from one draw, and is what a human reads off a requisition when phoning the lab. Do not merge the two.

For data derived from a source EMR:

  • Heritage EMRs generally carry no first-class specimen record. A result arrives as an HL7 v2 message or a rendered report in which the specimen is implicit in the OBR segment, and no stable specimen identifier is minted. Where ingest populates identifier the value is typically synthesized and therefore not stable across re-ingests -- do not build correlation on it.
  • accessionIdentifier is the one specimen field heritage sources reliably do carry, because it rides in the inbound lab message. Correlate on that instead.
  • But accessionIdentifier.system is currently unconstrained, and an accession is scoped to the performing laboratory rather than globally unique, so two labs can legitimately issue the same string. Treat an accession as unique only within a known performing organization; per-lab namespacing is not yet defined.

Whether ingest should mint synthetic specimen identifiers at all, and how to make them stable if so, is an open decision.

Absent and text-only are the expected shapes, not the exception

  • status (0..1: available | unavailable | unsatisfactory | entered-in-error). Absence must not be read as available, and heritage-derived specimens usually carry no status. unsatisfactory is clinically load-bearing: a rejected sample means the test was not performed, so a consumer treating the linked result as pending rather than failed will wait indefinitely.
  • type (0..1) has no binding. The SNOMED specimen hierarchy is large and no agreed subset exists for this EMR, so readers must tolerate text-only -- heritage lab messages typically supply at most a free-text specimen-source string from the OBR segment, making text-only the normal case here.
  • collection.bodySite (0..1) is likewise to be read as possibly text-only.

Dating, subject, and links

THE effective date is collection.collected[x], falling back to receivedTime (0..1). Collection is the clinically meaningful moment -- a result's relevance dates to the draw, not the lab's intake. collected[x] is a choice of dateTime or Period in R4 and both must be handled; heritage lab messages often carry only a received or report time, in which case the date falls through.

subject (0..1, NexusEmrCorePatient) is optional because R4 permits environmental and device-derived specimens, but anything appearing in a patient chart must carry it. Where a Specimen is synthesized during lab ingest the patient link is inferred from the enclosing DiagnosticReport rather than asserted by the source message, so a mis-matched report propagates its error into the specimen silently. Whether such specimens should assert subject at all, versus leaving it absent so consumers reach the patient through DiagnosticReport.subject, is unresolved -- so a consumer should be able to fall back to the enclosing report.

request (0..*, NexusEmrCoreServiceRequest) is the inverse of ServiceRequest.specimen and, per the NexusEmr EMR logical-reference model, may be identifier-only. collection.collector is 0..1 (NexusEmrCorePractitioner or NexusEmrCorePractitionerRole).