View source for Care Coordination Business Scenarios

[[category:Patient Care]] [[category:Service Oriented Architecture]] [[category:Care Coordination Service]]

[[File:go_back.png|32px|link=Care Coordination Service]]
'''Return to:''' [[Care Coordination Service]]


<div style="border:1px solid lightgrey;padding:8px;">
[[image:notice.png|48x48px]] <b>This content is based in an early draft and requires many updates to reflect changes for in progress ballot reconciliation.</b>
</div>
<br />

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 taking turns) or cooking (“too many chefs in the kitchen!”).  

=Primary Business Scenario: Collaborative Contribution to an Integrated Care Plan=
The Care Coordination Service introduces online collaborative management of a shared, comprehensive, long-lived "care plans" that organize and harmonize their contained "plans of care” and “treatment plans”.  The integrated structure and the collaborative management functions lay the foundation for extremely rigorous coordination of care.

The overarching care plan is concerned with longer term and continuing goals and treatments; 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
*reviewing, accepting, or rejecting change proposals
*invoking a Clinical Decision Support agent for comment
*putting duly approved plan elements into effect

The CP DAM information model and the CCS function are both adequately rich and well-factored. Consequently, even though the CCS "specification" is not bound to any process or security policy, a CCS implementation can be made to support even the richest of policies. 

Some examples of process support are as follows:
*a simple (sequential) workflow process could call the CCS to automatically set up any or all of the activities listed above and include the right parties in various reviews.  
*If a provider goes “off-plan” to take emergency action and then records it, the CCS could be invoked to set up a discussion to reconsider goals and treatments goin forward. 

Some examples of access control support are as follows:
*Care team invitations and discussion invitations could be limited to persons that have been identity-certified and provisioned in the user directory.
*Role-based access controls could be tied to combinations of functions and plan types
*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
*Draft-stage plans may be kept visible to those working on them while other team members might be given visibility of only the latest "accepted" views. 
*A clinical decision support (CDS) participant is kept out of discussions except when invited
*When a CCS discussion is opened, the participants see only those plan items that have been tagged as context for the discussion;

The above two lists are not restrictions that the CCS specification calls for, but rather implementation options that the CP DAM model and CCS function sets could support. 

In summary, subject to any local process controls and access controls, the CCS allows care team members to gain:
*the “productivity” benefit of being able to manage their respective plans with appropriate participants;
*the “coordination and consistency” benefits of the integrated plan structure and collaborative change management;

=Secondary Scenarios=

==Scenario: Sequential Transitions of Care==
Shows how online collaboration on the shared, structured care plan enhances both coordination and productivity during episodes and at transitions.

[[Media:CCS_Scenario_-_Sequential_Transitions_of_Care.docx]]

==Scenario: Iterative Plan Reviews and Revisions ==
The following schematic illustrates the "general" workflow of care planning (with comments to follow):(3 swimlanes).

[[image:HSSP_HL7_SOA_Care_Process_View_wCarePlanning.png|624x302px]]

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 "mark start" command on several distinct planned actions.  In response: 
*several of those actions are started with no more interaction (activating staff persons to schedule services)
*in some cases the start command causes application screens to open and prompt for more information
*in some cases the needed target application was CCOW enabled (and so is the CCS implementation) so it opened on the right patient
*in some cases the needed application could not be started automatically

In the last case, the user engages the necessary 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 specification cannot know in advance what a target deployment environment can actually do with mark_start commands (and other control commands), but at least it can pass the directive from the CCS client to the CCS server and keep track of the statuses that have been "marked" (for the awareness of the care team).

==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" then those templates could be offered to providers for instantiation on individual cases. 

At that point, the care plan will typically still need to be individualized based on patient-specific factors and preferences, but nevertheless dramatic savings could accrue from the routine omission (from the templates) of any and all order types that have been proven ineffectual for conditions/stages.  

Plan templates could include links to evidence citations.  The evidence citations themselves could be structured according to Guideline Evidence Models (GEMs, see http://www.openclinical.org/gmm_gem.html), although this CCS functional description is not (at least yet) planning to propose GEMs as normative.

==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. 

subject to enterprise policy and CCS implementation features, the CDS agent may be activated in synchronous or asynchronous modes:
*The CDS agent may be activated synchronously (on demand) by directing an evaluate_clinical_appropriateness request to it (as the other participant in a CCS discussion)
*the CDS agent may asynchronously "speak up" into a discussion from a background process.

Forms of CDS Contributions

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 appreciated to the extent that its points are timely, relevant, and concise.  CDS vendors are challenged to generate content that meets these criteria, but it is also a user interface design challenge - to make the advice accesible but not intrusive.
*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 plan items (e.g. orders), proposed removals (e.g. contraindications) or changes to plan items (e.g. dosage advice).  Human users could selectively discuss and accept items into the plans.

Examples

The following list provides examples of useful CDS contributions to be made during plan design, plan execution, or both. Note that in all cases the CDS agent should be able to provide rationale for its advice (perhaps via a hyperlink)
*Identify Risks: The CDS agent could suggest the set of risks based on relevant case factors
*Identify disease stage: The agent could assert a disease stage or classification
*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. Human usrs could then further tailor them and activate them.
*Identify contraindications - especially across plans

Special "Cross-Plan" Examples
*Cross-plan evaluation for clinical appropriateness: omprehsive 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 multiple plans (or specific plan items from multiple plans) are tagged for inclusion into the discussion context, then those plan items are 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 one of the plans.
*Raising of decisions: The agent could raise new “decision points” by writing it into a discussion thread.

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 tagged into the discussion 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 open new discussions at will (if its volume of advice is not overwhelming). The CDS advice is particularly useful if the agent can also propose computable plan item changes for consideration.