View raw Markdown
type: resourceresource: CarePlan

CarePlan

Introduction

Scope and Usage

CarePlan is one of the request resources in the FHIR workflow specification.

Care Plans are used in many areas of healthcare with a variety of scopes. They can be as simple as a general practitioner keeping track of when their patient is next due for a tetanus immunization through to a detailed plan for an oncology patient covering diet, chemotherapy, radiation, lab work and counseling with detailed timing relationships, pre-conditions and goals. They may be used in veterinary care or clinical research to describe the care of a herd or other collection of animals. In public health, they may describe education or immunization campaigns.

This resource takes an intermediate approach to complexity. It captures basic details about who is involved and what actions are intended without dealing in discrete data about dependencies and timing relationships. These can be supported where necessary using the extension mechanism.

The scope of care plans may vary widely. Examples include:

This resource can be used to represent both proposed plans (for example, recommendations from a decision support engine or returned as part of a consult report) as well as active plans. The nature of the plan is communicated by the status. Some systems may need to filter CarePlans to ensure that only appropriate plans are exposed via a given user interface.

Boundaries and Relationships

CarePlan activities can be defined using references to the various "request" resources. These references could be to resources with a status of "planned" or to an active order. It is possible for planned activities to exist (e.g. appointments) without needing a CarePlan at all. CarePlans are used when there's a need to group activities, goals and/or participants together to provide some degree of context.

The CarePlan resource represents an authorization as well as fulfillment on the service provided, while not necessarily providing all the details of such fulfillment. Further details about the fulfillment are handled by the Task resource. For further information about this separation of responsibilities, refer to the Fulfillment/Execution section of the Request pattern.

CarePlans can be tied to specific Conditions, however they can also be condition-independent and instead focused on a particular type of care (e.g. psychological, nutritional) or the care delivered by a particular practitioner or group of practitioners.

An ImmunizationRecommendation can be interpreted as a narrow type of CarePlan dealing only with immunization events. Where such information could appear in either resource, the immunization-specific resource is preferred.

CarePlans represent a specific plan instance for a particular patient or group. It is not intended to be used to define generic plans or protocols that are independent of a specific individual or group. CarePlan represents a specific intent, not a general definition. Protocols and order sets are supported through PlanDefinition.

Notes

Notes

The Provenance resource can be used for detailed review information, such as when the care plan was last reviewed and by whom.

Open Issues

StructureDefinition

Elements (Simplified)

Mappings

Implementation Guide

implementationguide-CarePlan-core.xml

<?xml version="1.0" encoding="UTF-8"?>

<ImplementationGuide xmlns="http://hl7.org/fhir">
  <id value="CarePlan-core"/>
  <identifier>
    <system value="urn:ietf:rfc:3986"/>
    <value value="urn:oid:2.16.840.1.113883.4.642.30.4"/>
  </identifier>
  <name value="CommonCarePlanExtensions"/>
  <title value="Common  Care  Plan  Extensions"/>
  <status value="draft"/>
  <date value="2015-03-27T00:00:00.000"/>
  <publisher value="Health Level Seven, Inc. - Patient Care WG"/>
  <description value="A set of commonly used extensions that don't make the usage requirements for inclusion in the resource itself"/>
</ImplementationGuide>

Resource Packs

list-CarePlan-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir">
  <id value="CarePlan-packs"/>
  <status value="current"/>
  <mode value="working"/>
  <entry>
    <item>
      <reference value="ImplementationGuide/CarePlan-core"/>
    </item>
  </entry>
</List>

Search Parameters

Full Search Parameters

Examples

Full Examples

Mapping Exceptions

careplan-fivews-mapping-exceptions.xml

Unmapped Elements

careplan-request-mapping-exceptions.xml

Divergent Elements

Note: This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number. | resource=This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.

A status of completed for a "doNotPerform" request indicates that the period of non-performance is now satisfied and the request no longer holds. | resource=The unknown code is not to be used to convey other statuses. The unknown code should be used when one of the statuses applies, but the authoring system doesn't know the current state of the care plan.

This element is labeled as a modifier because the status contains the code entered-in-error that marks the plan as not currently valid.

One exception to this is that the granularity of Request.intent is allowed to change. For example, a Request identified as an "order" might later be clarified to be a "filler-order". Or, in rarer cases (to meet recipient constraints), the reverse might also occur.

When resources map to this element, they are free to define as many codes as necessary to cover their space and will map to "proposal, plan or order". Can have multiple codes that map to one of these. E.g. "original order", "encoded order", "reflex order" would all map to "order". Expectation is that the set of codes is mutually exclusive or a strict all-encompassing hierarchy. | resource=This element is labeled as a modifier because the intent alters when and how the resource is actually applicable. This element is expected to be immutable. E.g. A "proposal" instance should never change to be a "plan" instance or "order" instance. Instead, a new instance 'basedOn' the prior instance should be created with the new 'intent' value.

Unmapped Elements