Skip to content

Care Plan Profile

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

Nexus EMR profile for CarePlan -- the management plan tying goals, conditions and activities together (CDM flowsheets, care gaps). First pass: status/intent, category, goal/addresses linkage, minimal activity. Closed to SMART apps pending an exposure decision.

Overview

Overview

The Nexus EMR Core CarePlan profile represents the management plan that ties goals, conditions and planned activities together. It is the structural half of chronic-disease-management content: a flowsheet or care-gap view is Goal targets read against the chronic Conditions a CarePlan says it manages, with the CarePlan supplying the grouping, the intent and the period.

This is a first pass. It models the linkage skeleton and a minimal activity surface only. Care-team linkage, richer activity scheduling, and the protocol surface (instantiatesCanonical / instantiatesUri) are deliberately unmodelled, so do not treat their absence as a statement that they will stay unmodelled. The profile is closed to SMART apps pending an exposure decision.

The linkage triple

Three references carry the meaning of a CarePlan here, and all three are type-constrained:

  • subject is 1..1 and only Reference(NexusEmrCorePatient).
  • addresses is 0..* and only Reference(NexusEmrCoreCondition) -- the condition(s) being managed.
  • goal is 0..* and only Reference(NexusEmrCoreGoal) -- the measurable targets, one per flowsheet row.

addresses and goal are both optional, so a conformant CarePlan can exist with neither. A consumer building a flowsheet should treat a CarePlan with no goal as having no rows rather than as malformed. status (1..1) and intent (1..1) are the only other required elements; intent is normally plan.

period is 0..1 and, with created, supplies the profile's declared effective date (period.start | created). A CarePlan with neither will not sort onto a chart timeline by date.

Activity: a reference or an inline detail

activity is 0..*, and each entry expresses the planned action one of two ways:

  • activity.reference (0..1) -- the action already exists as its own resource (ServiceRequest, MedicationRequest, Appointment, Task), and the CarePlan just points at it.
  • activity.detail (0..1) -- an inline description for the case where no request resource exists. Inside a detail, status is 1..1 and code is 0..1.

Nothing in the profile forces a choice between the two, so a reader must handle an entry that carries either, both, or -- because both are optional -- neither.

Draft and proposed plans

status is a modifier element: it changes how the whole resource is to be read, and a consumer that ignores it will surface plans that were never adopted. A draft or proposed plan produced by an AI suggestion does not sit first-class in the chart: it rides contained in its review Task, the same as every other suggested resource. Only plans that exist in their own right appear as standalone CarePlan resources.

Each CarePlan SHOULD carry a business identifier from the originating system. It is a recommendation, not a hard requirement, and as of 1.21.0 it is not checked either: the warning-severity careplan-has-raw-identifier invariant was removed with nothing replacing it.

See CarePlan/nexus-emr-careplan-example for a worked instance.