Skip to content

Communication Profile

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

Nexus EMR profile for Communication, covering two distinct populations: WELL-internal staff chat about a patient, and eReferral correspondence passed through from or to external partners. First pass -- the pass-through boundary and message threading are not yet settled.

Overview

Handbook: Conversation Threading

The narrative treatment -- what this is for, why it is shaped this way, and how it is used.

Nexus EMR Core Communication Profile

Overview

The Nexus EMR Core Communication profile covers a message about a patient. Two genuinely different populations share this resource type, and the profile models both rather than pretending they are one thing: internal staff chat about a patient, an operational read/write surface inside the EMR; and eReferral correspondence exchanged with external partners, where the shape is the partner's rather than this IG's. category is what tells them apart, and readers should scope on it -- the two populations have different authorities over their content.

The profile is #draft and experimental = true, and that marking should be taken literally. It is a first pass, committing to a skeleton, the category discriminator, and the constraints that keep internal chat readable. It is now reachable by a SMART on FHIR app for read, search, create and update: the profile declares smart-exposed -- this guide's positive flag for app reachability -- and the server capability statement lists it. Deletion is not granted; a message that should not have been sent is withdrawn through its own status, never removed.

THE effective date is sent, falling back to received. A message with neither is undatable and cannot join any date-driven chart surface.

What is settled

  • status (1..1). Internal chat writes completed on send. For eReferral traffic the partner's lifecycle applies and status is pass-through -- do not infer local workflow state from it.
  • identifier (0..*, system and value each 1..1 when present). For eReferral traffic this is where the partner's own message identifier belongs: it is the only governed way to correlate a reply with what it replies to across the boundary. Carry it. The warning-severity communication-has-raw-identifier invariant that used to nudge for it was removed in 1.21.0, so nothing checks it.
  • subject (0..1, NexusEmrCorePatient) is optional per R4 but should be carried for chat about a patient. A message with no subject cannot be scoped into a chart, and cannot be filtered out of one either, which is the access-control consequence.
  • sender (0..1) may be a Practitioner, PractitionerRole, Patient, Organization or AppDevice -- Organization covers a partner system on inbound traffic, Device covers system-generated messages. recipient (0..*) spans the same set plus CareTeam.
  • payload (0..*) varies by population. Internal chat writes contentString; eReferral traffic may carry contentAttachment or contentReference. Handle all three -- a reader assuming contentString renders an empty message instead of failing visibly.

Category has no value set yet, and that is deliberate

category is 0..* with a warning-severity invariant (communication-has-category) recommending its presence, because without it the populations are indistinguishable and a chat query can surface partner correspondence into a panel never designed for it.

No value set is bound, because binding one requires first settling the pass-through boundary -- which elements an external partner may set freely -- so that a partner-supplied category stays conformant. Until then category is text-or-code and readers must tolerate text-only. A local category value set is the intended follow-up, so expect codes to appear: do not assume a fixed enumerable set today, and do not treat an unrecognized category as invalid.

Migration of message history from heritage EMRs is also open. Heritage systems model messaging as local tables with their own threading, read state and routing, and nothing currently maps them into this resource. If that history is ever migrated it becomes a third population, and this element is where the distinction would live -- which is what anyone binding a value set here has to resolve first.

Do not build on threading yet

inResponseTo is declared (0..*, NexusEmrCoreCommunication) but conversation structure is not settled. Order is currently reconstructed from timestamps, which cannot separate messages sent concurrently, and whether a conversation is an inResponseTo chain or a partOf grouping is undecided -- as is whether internal chat belongs on Communication at all rather than on a non-clinical transport. Declaring the element is the first step, not the contract: treat thread structure read from either element as advisory, and do not persist a derived conversation graph expecting it to stay valid.