Search loading...


Explore and Make use of Nationally Defined Messaging APIs


UEC Digital Integration Programme | Care Plan

CarePlan resource implementation guidance

CarePlan: Implementation Guidance


Within the Clinical Decision Support API implementation, the CarePlan resource will be used to carry the care advice recommendation given by the CDSS.
This resource may also carry a recommendation of self-care.


When the outcome of triage is to recommend self care, this will be carried as follows:

  • A GuidanceResponse returned to the EMS by the CDSS will carry a reference to a RequestGroup resource which will reference a relevant CarePlan
  • Identifying the CarePlan which specifically represents self-care as opposed to general care advice can be done by checking the careTeam.participant element within the CarePlan
  • If there is only a single instance of participant and the participant.role is ‘Patient’ (Snomed CT code of 116154003), then the recommendation is for self-care

The table below gives implementation guidance in relation to the elements within a CarePlan:

Name Cardinality Type FHIR Documentation CDS Implementation Guidance
identifier 0..* Identifier External Ids for this plan
definition 0..* Reference
(PlanDefinition |
Protocol or definition
basedOn 0..* Reference
Fulfils care plan
replaces 0..* Reference
CarePlan replaced by this CarePlan
partOf 0..* Reference
Part of referenced CarePlan
status 1..1 code draft | active | suspended | completed | entered-in-error | cancelled | unknown CarePlanStatus (Required) This element SHOULD be populated with 'active' when the advice is given by the CDSS. Once the advice has been given, it SHOULD be updated by the EMS to show a value of 'completed'.
intent 1..1 code proposal | plan | order | option CarePlanIntent (Required)
title 0..1 string Human-friendly name for the CarePlan
description 0..1 string Summary of nature of plan
subject 1..1 Reference
(Patient |
Who care plan is for This MUST be populated with a reference to the Patient resource.
context 0..1 Reference
(Encounter |
Created in context of This MUST be populated with the Encounter for this journey, from the ServiceDefinition.$evaluate.encounter
period 0..1 Period Time period plan covers
author 0..* Reference
(Patient |
Practitioner |
RelatedPerson |
Organization |
Who is responsible for contents of the plan
careTeam 0..* Reference
Who's involved in plan? A CareTeam resource having a single instance of a participant element with a participant.role of 'Patient' indicates a triage outcome of self-care.
addresses 0..* Reference
Health issues this plan addresses
supportingInfo 0..* Reference
goal 0..* Reference
Desired outcome of plan
activity 0..* BackboneElement Action to occur as part of plan - provide a reference or detail, not both This SHOULD be populated by the CDSS using either the reference or the detail element. For example, it could carry a medication to be used, self-monitoring activities, laboratory tests planned.
activity.outcomeCodeableConcept 0..* CodeableConcept Results of the activity Care Plan Activity Outcome (Example)
activity.outcomeReference 0..* Reference
Appointment, Encounter, Procedure, etc.
activity.progress 0..* Annotation Comments about the activity status/progress
activity.reference 0..1 Reference
(Appointment |
CommunicationRequest |
DeviceRequest |
MedicationRequest |
NutritionOrder |
Task |
ProcedureRequest |
ReferralRequest |
VisionPrescription |
Activity details defined in specific resource This element of note SHOULD be populated by the CDSS, if the information relating to the planned activity is to be carried in a resource.
activity.detail 0..1 BackboneElement In-line definition of activity This element of note SHOULD be populated by the CDSS, if the planned activity is not linked to specific resources such as a MedicationRequest or a Procedure.
activity.detail.category 0..1 CodeableConcept diet | drug | encounter | observation | procedure | supply | other CarePlanActivityCategory (Example) This element of note SHOULD be populated by the CDSS to provide a high-level categorisation of the type of planned activity.
activity.detail.definition 0..1 Reference
(PlanDefinition |
ActivityDefinition |
Protocol or definition
activity.detail.code 0..1 CodeableConcept Detail type of activity Care Plan Activity (Example)
activity.detail.reasonCode 0..* CodeableConcept Why activity should be done or why activity was prohibited Activity Reason (Example)
activity.detail.reasonReference 0..* Reference
Condition triggering need for activity
activity.detail.goal 0..* Reference
Goals this activity relates to
activity.detail.status 1..1 code not-started | scheduled | in-progress | on-hold | completed | cancelled | unknown CarePlanActivityStatus (Required)
activity.detail.statusReason 0..1 string Reason for current status
activity.detail.prohibited 0..1 boolean Do NOT do
activity.detail.scheduled[x] 0..1 Timing
When activity is to occur
activity.detail.location 0..1 Reference
Where it should happen
activity.detail.performer 0..* Reference
(Practitioner |
Organization |
RelatedPerson |
Patient |
Who will be responsible?
activity.detail.product[x] 0..1 CodeableConcept
(Medication) |
What is to be administered/supplied SNOMED CT Medication Codes (Example)
activity.detail.dailyAmount 0..1 SimpleQuantity How to consume/day?
activity.detail.quantity 0..1 SimpleQuantity How much to administer/supply/consume
activity.detail.description 0..1 string Extra info describing activity to perform
note 0..* Annotation Comments about the plan

CarePlan Elements of Note

Activity.reference element of the CarePlan

This element carries details of the proposed activity represented in a specific referenced resource. For example, if care advice which is a component of a triage outcome involves advice about how to give CPR, this could be modelled as a ProcedureRequest which could be referenced from the element.

Activity.detail element of the CarePlan

This element carries a simple summary of a planned activity which would be suited for a general care plan system, for example a form-driven system. Such a system would not know about a specific resource and therefore this element would be populated, as an alternative to the activity.reference element in a CarePlan.

Note that the above two elements are mutually exclusive within a FHIR CarePlan, so it is not possible to populate both elements within one CarePlan.

Activity.detail.category element of the CarePlan

This element carries a high-level categorisation of the type of activity in a CarePlan, for example describing whether it relates to diet, drug, procedure, etc. An example could be care advice about administering epi-pens to a patient suffering an allergic reaction, which might be modelled as a drug category.

Tags: rest fhir api

All content is available under the Open Government Licence v3.0, except where otherwise stated