Care Plan

Care Plan Model Overview

The Care Plan structure is used to define the management action plans for the various concerns identified for the target of care. It is the structure in which the care planning for all individual professions or for groups of professionals can be organized, planned and checked for completion. Communicating explicitly documented and planned actions and goals greatly aids the team in understanding and coordinating the actions that need to be performed for the person. Care plans also permit the monitoring and flagging of unperformed activities and unmet goals for later follow up.

“The Care Plan represents the synthesis and reconciliation of the multiple plans of care produced by each provider to address specific health concerns. It serves as a blueprint shared by all participants to guide the individual’s care. As such, it provides the structure required to coordinate care across multiple sites, providers and episodes of care.” Care Plan Terms & Proposed Definitions (DRAFT v24), S&I Longitudinal Coordination of Care WG (S&I LCC Glossary).

The HL7 patient care “Plan” model supports the documentation and execution of a plan tailored for different health care scenarios. The plan represents an emergent process, unfolding process, which is continuously changing based on feedback from various participants which include: the patient, the patient’s family, the care team and other support individuals such as those dealing with financial aspects. The model is structured in such a way to support the following views based on the S&I Longitudinal Care Coordination glossary definitions.

1. The “Plan of Care” view supports individual providers in addressing either single or multiple conditions
2. The “Care Plan” supports a composite and reconciled view of multiple “Plans of Care” addressing multiple provider care specialty perspectives (e.g. cardiology, nutrition, physical therapy, pharmacist, etc.)

In the HL7 patient care model the “Care Plan” and “Plan of Care” share the same essential characteristics of goals, concerns, plan actions, care team, etc. As such, the “Care Plan” is modeled to inherit the characteristics of the “Plan of Care” but in addition the “Care Plan” also supports composition of multiple specialized “Plans of Care”. The structuring is flexible in order to accommodate different organization process and policy decisions.

The “Plan” model consists following key structural and content characteristics:

1. Health concerns which represent the focus or reason for establishing the plan.
2. Health goals mutually agreed on by the patient and one or more care team members
3. Proposed actions to address the goals and any required acceptance reviews necessary for implementation
4. Implemented actions and outcomes which are reviewed against the health goals
5. Known health risks requiring management via mitigating actions
6. Care barriers blocking progress towards the wellbeing of the patient and success towards goals

The planning process which leads to the establishment of the “Care Plan” is a dynamic and emergent process with the following aspects:

1. It involves dynamic and unpredictable interactions between care planning and execution participants
   • patient, family, care team or administrative support staff
2. It requires constant communication between participants who may change the state of individual actions at any time
3. The progression of actions may follow any sequencing or may happen in parallel in an unpredictable manner
4. Goals may change at any time based on feedback from any of the participants
5. Actions may be suspended, changed or abandoned at any time based on new knowledge from any of the participants due to patient preferences, barriers or the outcome of interventions.

Care Plan and Plan of Care – Structure Overview

Plan Actions

Plan Resources

624x320px

Care Plan and Plan of Care – Detailed Model

CCS Functional Profiles

The following set of profiles is in-process, to be included into the S-FM when stabilized.

Plan Reading

- Read Care Plan and its (possibly distributed) related plans; subscribe to updates to some parts or to the plan as a whole

- Support on-demand reads (pull) as well as pub-subscribe (push) modes

Plan Authoring

Note: Single author and collaborative will use same operations.

- Initialize and maintain a plan, apply reusable parts (e.g. a protocol); individualize goals and interventions, etc.

- Save plans or portions of plans as named reusable components for later reuse

- Support online discussions of specified topics; allow for participants to propose, accept, reject changes

Execution Support

- We wish to avoid (at least in the first version) full-blown workflow schemas such as BPMN or GLIFs. Rather, we expect workflow to be “emergent”; that is, the next actions are authored into place by various care team members. Decisions may be prompted by a "Decision" plan item that may provide alternatives for consideration. Care team members activate planned actions that are already in place, and they maintain the "horizon" of new planned actions.

- Decisions are distinct from the triggering of actions. Actions may be triggering based on preconditions.

- Order entry: Place orders from predefined order sets

- Resource scheduling - seek simple case in first version; query availability (just resource type, time slots request, server seeks to avoid collisions), Then the client can choose a candidate and issue the ‘assign” operation. Defer:for later version: ability to refine search subject to environment, credentialing distance, financial constraints.

Progress Tracking

- Query for progress data

- Subscribe to alerts upon unmet incremental milestones/goals, planned but overdue actions.

- As a principle, we support detection and recording of events by humans or by machine. the API will support but not require the automatic detection of events by the server.

Plan Reconciliation Support

(We need to clarify the dinstincion between "requesting CDS advice" and invoking gap/overlap analysis. The gap/overlap analysis will employ machine logic, but this is not necessarily clinical rules (other than equivalence based on codes and subsumptions).

- Support analysis and clean-up disjoint, redundant, or conflicting plans; Can be invoked over a single plan or multiple plans.

- automatically organize POCs under CPs; combine POCs for the same specialty.

- any generated suggestions are "proposed" - not automatically accepted.

- Could propose alternatives.

- In addition to on-demand invocations, an implementation could provide that an agent process suggests gaps and overlaps asynchronoiusly (upon some change, or evaluated periodically)

Clinical Decision Support Integration

- Include operations from the CDS swim lane of the generic Car Plan process model (advise on goals; planned actions, contraindications, etc.)

- Connect the CDS agent as a collaboration participant. CDS output is routed conversationally (always or optionally?) into the "collaboration" framework.

- a care team member can request advice on some selected plan components (some or all of the plan)

- As an implementation note, if the CCS implementation virtualizes its plan items as vMR constructs, then third-party HL7-standard knowledge modules could be invoked on its plans.