Care Coordination Business Scenarios

Return to: Care Coordination Service

The CP DAM document includes storyboards that conceptually describe types and structures of plans (care plans, plans of care, and treatment plans). The CCS builds on that work by support the ongoing collaborative collection, organization, reconciliation, consolidation, and maintenance of those plans. None of these “verbs” is peculiar to “healthcare”. For example, these same functions would be needed in a large construction project (general contractors trying to coordinate with subcontractors that are interdependent and not talking turns) or cooking (“too many chefs in the kitchen!”).

Primary Business Scenario: Collaborative Contribution to an Integrated Care Plan

As its essence, the Care Coordination Service supports collaborative management of a shared, comprehensive “care plan” that serves to reconcile and unify its contained “plans of care” and “treatment plans”. The overarching care plan is concerned with longer term and continuing elements; It informs the plans of care. In turn, those plans of care continually precipitate important adjustments up to the care plan and record important observations into evidence. This pattern could repeat many times in the course of a typical patient with a major chronic condition. The care plan at the top of the structure will typically have a primary physician as its key contributor, while the specialized or episodic “plans of care” that are embedded or linked under it may each have other providers as key contributors.

In order to robustly support any enterprise’s governance policies for care planning, the CCS provides functions for:

• identifying the scope of discussions by tagging plan items of interest
• inviting participants to those discussions, even a Clinical Decision Support agent as a participant
• reviewing, accepting, or rejecting change proposals
• putting duly approved plan elements into effect

The CP DAM information model and the CCS function are both adequately rich and well-factored so that, even though the CCS doesn’t “solve” process and policy enforcement issues, an implementation can be made support even the richest of policies. For example, role-based access controls could be tied to combinations of functions and plan types, and instance-based controls could limit access rights on a “plan of care” to the primary physician and to the specialist that functions as its steward.

As a practical reality relevant to any access control policy, there occasionally arises the situation in which a provider must go “off-plan” to deliver needed care in an emergency, taking full responsibility for it; But even the typical emergency situation may precipitate a need for collaborative adjustments to treatments and goals going forward.

In summary, subject to local process controls and access controls the CCS allows care team members to gain:

• the “productivity” benefit of being able to work concurrently with their respective plan components; and
• the “coordination and consistency” benefits of the integrated plan structure and collaborative change management operations.

Secondary Scenarios

Scenario: Sequential Transitions of Care

(Summarized version of scenario Emma Jones submitted with schematic - "Explanation of how CP, POC, TP and Inst fit together"). Point out the opportunities for discontinuity due to change in clinical focus or administrative oversight. Show how the shared care plan provides continuity at transitions.

Note: Jon is updating the scenario to show how particular "plan items" of completed plans (plans of care and treatment plans) can be flagged as still being of potential relevance to the care plan or to future transient plans.

Media:Condensed_version_of_Emma_Jones_document_-_how_CP-POC-TP_Inst_fit_together_-_as_business_scenario.docx

Scenario: Iterative Plan Reviews and Revisions

The following schematic illustrates the "general" workflow of care planning (with comments to follow):(3 swimlanes).

Please note:

• The center lane is characterized by its loops, reflecting the need for continual review and update cycles.
• The center lane’s title. There are multiple providers “packed into the lane” as described in scenario 1. Each provider may have “their own” plan of particular time scope and specialty, but they must be reconciled and consolidated (virtually if not physically). It is not uncommon in chronic condition cases to have 5 providers sharing authorship (including the patient) plus as many participants in read-only mode.
• The decision support swim lane accurately reflects both human and machine advice that may give rise to revisions.
• The plan undergoes continual change and it must be possible to see a plan “as of” a specified date and time, and perhaps within the scope of just one plan of care.

Scenario: Simple Starting and Monitoring of Planned Actions

A physician is viewing the planned actions (interventions) of an inpatient care plan, and decides to directly activate several of the actions and monitor their completion status. Some of the actions of interest consist in a single simple action, such as a complete blood count (CBC) test. Other actions such as the diagnostic imaging require credentials verification and resource scheduling. Other actions involve daily repetitions over the course of the episode.

The physician or care manager issues a "start" command on several distinct planned actions. In response, several of those actions are started with no more interaction. In two cases the start command causes application screens to open and prompt for more information. The dietary order could not be started automatically from within the care plan display, so the user engages the diet ordering application for starting that action.

The user monitors the completion statuses of most actions directly from the care plan display. the display shows overdue and unstarted items with an exclamation point; actions in-process with an ellipsis, and completed actions with a checkmark. The user manually sets the completion status of the dietary order.

This scenario illustrates that the CCS does not attempt to directly support all the interactions that are needed to carry out complex orders, but will provide a very basic degree of execution support. There are various ways that a CCS "start" operation could be connected with its required interactions, but to the CCS these are implementation details.

Scenario: Deployment of Plan Templates

Note: We are using the term "template here" in the sense of a "pattern". We are not referring to the constraint language used to validate HL7 V3 messages. Various organizations presently publish clinical care guidelines for internal or external use. If such organizations were to create CCS-compatible care plan "templates" that also included their evidence citations and (the sub populations for which each recommendation applies), then those templates could have contraindicated (or merely not indicated elements omitted) and offered to the care team for use. At that point, the care plan is still likely to need individualized based on patient-specific factors and preferences, but nevertheless dramatic savings could accrue from the automated omission of ineffectual order sets. To the extent that care plans have encoded their planned actions, CCS implementations could look up procedure prices to estimate costs of alternative plans.

Scenario: Clinical Decision Support Agent as a Discussion Participant

Just as a human care team member might suggest plan changes for a specific patient, so might a CDS agent. therefore the CCS seeks to have the CDS agent interject brief, relevant advice into CCS discussion threads, with links to its underlying evidence. The CDS Agent may be activated by a request_clinical_evaluation operation, or may "speak up" into a discussion asynchronously, from a background process.

Examples

The following list provides examples of useful CDS contributions to be made during plan design, plan execution, or both:

• Identify Risks: The plan data itself includes associations (to conditions) that represent medical risks. The CDS agent could propose to add, change, or remove these risks.
• Identify disease stage: The agent could assert a disease stage or classification, and should explain its criteria
• Choose guidelines: The agent could provide (or point to) guidelines documents or URLs to guidelines
• Suggest order sets: The agent could provide tailored order sets, complete with rationale. Human usrs could then further tailor them and activate them.
• Identify contraindications - even across plans: A CCS implementation could utilize CDS clinical advice that is based upon not only one care plan at a time, but any number of care plans for the same patient, considered as one. If items from multiple plans are placed into the discussion context, then all those plan items should be supplied as CDS inputs.
• Suggest consolidations: the agent could suggest “piecemeal” deletions of redundant items, or could suggest a consolidated plan. A good implementation will utilize terminology assets such as mappings and classifications to avoid suggesting therapies that are already in the plan. Obtaining Inputs
• Raise decisions: The agent could raise new “decision points” by inserting them as a proposed decision item along with supporting reference materials such as drug selection charts. Even though the first versions of the CP DAM or CCS has no formal notion of a “decision point”, the CDS agent could raise the need for a decision by communicating in a discussion thread.

Forms of CDS Contributions to Plans

In general, the CDS agent would make discussion contributions in several different forms, none of which requires operations apart from those invoked on behalf of humans:

• Brief natural language comments inserted into discussion threads. CDS advice in general is greatly appreciated to the extent that its points are timely, relevant, and concise. This poses a challenge for CDS vendors to generate content that meets these criteria, but it is also a user interface design challenge to those that develop CCS client applications.
• Pointers to supporting evidence. In addition to its textual suggestions, a CDS agent should be able to point to the evidence underlying its advice.
• Proposed changes to plan items. The CDS agent could construct the set of plan items that would implement its advice; then the human users could selectively discuss and incorporate those items into the plan.

Users of CDS systems need the ability to control the overall rate of CDS interjections. The CCS should include the ability to set a "threshold for strength of evidence” as an attribute of a discussion.

Inputs

In general, most CDS advice requires as input some combination of demographics, conditions, and therapies; it potentially may also need information from the health record.

The CDS agent can of course obtain the conditions and planned actions that have been placed into the plan context; but it is up to the implementation to establish its means of gathering patient demographics and any other needed data from the patient’s health record.

In summary, there are numerous points in care planning and execution at which CDS advice can be usefully applied. CDS advice can be explicitly requested using the request_clinical_evaluation operation on a supplied discussion context, but an implementation can permit the CDS agent to speak into discussions at any time (as an implementation choice). The CDS advice is particularly useful if the agent can also propose computable plan item changes for consideration.