Skip to content

MessageHeader Profile

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

Nexus EMR profile for MessageHeader -- the routing envelope on an eReferral message bundle, consumed by the gateway's operation-routing middleware. Infrastructure rather than clinical content: no effective date, and R4 gives it no identifier element. First pass: the event vocabulary is not settled.

Overview

Overview

The Nexus EMR Core MessageHeader profile is the routing envelope on an eReferral message Bundle. It says what kind of message this is, who sent it, who it is for, and what it is about, so that a receiver can dispatch it. The gateway's operation-routing middleware reads MessageHeader to route inbound eReferral traffic, which makes this a live consumption surface.

This is infrastructure, not clinical content. A MessageHeader carries no patient data of its own and is not patient-compartment content: the clinical content sits in the other Bundle entries, pointed at by focus. Two consequences follow, both differing from every clinical profile in this IG. The profile declares no effective date -- a routing envelope has no clinical date, and the message's send time (Bundle.timestamp on the enclosing Bundle) is transport metadata rather than a fact about a patient, so it must not date a chart surface. And there is no identifier constraint, because R4 MessageHeader has no identifier element at all; the house identifier invariant deliberately does not apply. Correlate messages by Bundle.identifier, not by anything on this resource.

The profile is draft and experimental. It carries one invariant, messageheader-routable: event and source must both be present, since a receiver cannot dispatch without the event and cannot reply or attribute without the source.

The event is a choice type, and its vocabulary is a first pass

event[x] is 1..1 and is the routing key, but it is deliberately unbound. R4 permits either a Coding or a uri, each eReferral partner brings its own event vocabulary, and binding a local set would make otherwise-conformant partner traffic non-conformant. Two implications:

  • Consumers must handle both forms. Reading only eventCoding silently fails to route a partner that sends eventUri.
  • The event vocabulary is expected to change. Do not build logic that assumes a fixed, enumerable set of event codes.

Sender, source, and focus

source (1..1, with source.endpoint 1..1) is the technical sending system and where replies go. sender and responsible are separate concepts: they name the Practitioner, PractitionerRole, or Organization accountable for the message content, usually an Organization for inbound partner traffic.

focus points at the other entries in the same message Bundle, typically a ServiceRequest or Task plus the Patient. These are intra-bundle references: they resolve within the Bundle, not against the server, so a resolver that only attempts server resolution will report them as missing.

response.identifier is an id, not an Identifier

response is present only when this message answers an earlier one, and it holds a type trap. Despite the element name, response.identifier is the R4 primitive id -- a bare string matching [A-Za-z0-9\-\.]{1,64} -- not the Identifier datatype. A urn:uuid:... value is invalid because colons are not permitted, and a system + value object will not parse. It holds the plain id of the message being answered, so cross-boundary correlation with a partner's own message identifier cannot ride here; use Bundle.identifier for that.

response.code is 1..1 and is load-bearing: a partner reporting fatal-error has rejected the referral. A consumer that ignores this element will display a submitted referral as in-flight indefinitely.