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.

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: Execution of Plans

When a duly authorized care team member is viewing the planned actions (interventions) of a plan, that user should be able to directly activate that planned action and monitor its status. Some actions consist in a single step of short duration, while others entail sequences of activity among multiple stakeholders. Nevertheless, any planned action should have a meaningful notion of "start". If, in the local environment, more information needs to be gathered than has been recorded in the planned action, then that information can be collected by the relevant program.

In the case of resource scheduling, the user may request a resource in a time range and then subsequently receive confirmation or conflict notices.

Plan execution functions constitute a large body of implementation complexity; and not all CCS implementers will care to implement such functions. For these reasons the plan execution features will be organized into their own conformance profile, and an effort will be made to leverage preexisting applicable standards.

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: Deployment of Plan Templates

Just as a human care team member might raise a caution or suggest plan changes for a specific patient, so might a CDS agent. The state of artificial intelligence science is such that few vendors would attempt to make a CDS agent carry on a fully human-like conversation with the care team, nor would that even be desirable. Nevertheless, without trying to appear human the CDS agent can be made to interject brief, relevant advice into CCS discussion threads, with links to its underlying evidence.

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

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.