This wiki has undergone a migration to Confluence found Here

Care Coordination Business Scenarios

From HL7Wiki
Jump to navigation Jump to search

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

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

Given any planned action, any (authorized) user should be able to start the action and get status updates. If the action is not startable, then the server should be able to convey the reason at least in human-readable terms.

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 citationsBold text and indications Bold text(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.