This wiki has undergone a migration to Confluence found Here

Care Coordination Business Scenarios

From HL7Wiki
Jump to navigation Jump to search

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: Multiple Concurrent Authors

If participants will be taking turns as authors, working "sequentially" as the patient moves across care settings, then coordination consists in controlled hand-offs and distribution of updates at those transition times. However, if the participants must work "concurrently", then coordination consists in providing a current image (of the shared thing) to "all participants" at "all points in time." Over time, it is expected that end users will less and less often feel a need to "get a document" (or a set of them) just to determine the current (and complete) care plan for a patient.

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.


Scenario: Iterative Plan Reviews and Revisions

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

HSSP HL7 SOA Care Process View wCarePlanning.png

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.


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.


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.