This wiki has undergone a migration to Confluence found Here

Care Plan Storyboards with care coordination services scenarios

From HL7Wiki
Revision as of 00:41, 7 February 2013 by Jfarmerwiki (talk | contribs) (first posted draft of CCS functional profiles)
Jump to navigation Jump to search

Return to: Care Plan Project 2012

The following are a set of Care Plan Storyboards under development. These storyboards extend on the approved care plan to include scenarios to support care activities planning, resources scheduling, and orchestration. The extensions are intended to provide sufficient details to support the definition of care coordination services and policy.

Acute/Emergency Condition Care Plan Storyboard

Chronic Condition Care Plan Storyboard

CCS Functional Profiles

The following set of profiles is in-process, to be included into the S-FM when stabilized.

Plan Reading

- Read Care Plan and its (possibly distributed) related plans; subscribe to updates to some parts or to the plan as a whole

- Support on-demand reads (pull) as well as pub-subscribe (push) modes

Plan Authoring

Note: Single author and collaborative will use same operations.

- Initialize and maintain a plan, apply reusable parts (e.g. a protocol); individualize goals and interventions, etc.

- Save plans or portions of plans as named reusable components for later reuse

- Support online discussions of specified topics; allow for participants to propose, accept, reject changes

Execution Support

- We wish to avoid (at least in the first version) full-blown workflow schemas such as BPMN or GLIFs. Rather, we expect workflow to be “emergent”; that is, the next actions are authored into place by various care team members. Decisions may be prompted by a "Decision" plan item that may provide alternatives for consideration. Care team members activate planned actions that are already in place, and they maintain the "horizon" of new planned actions.

- Decisions are distinct from the triggering of actions. Actions may be triggering based on preconditions.

- Order entry: Place orders from predefined order sets

- Resource scheduling - seek simple case in first version; query availability (just resource type, time slots request, server seeks to avoid collisions), Then the client can choose a candidate and issue the ‘assign” operation. Defer:for later version: ability to refine search subject to environment, credentialing distance, financial constraints.

Progress Tracking

- Query for progress data

- Subscribe to alerts upon unmet incremental milestones/goals, planned but overdue actions.

- As a principle, we support detection and recording of events by humans or by machine. the API will support but not require the automatic detection of events by the server.

Plan Reconciliation Support

(We need to clarify the dinstincion between "requesting CDS advice" and invoking gap/overlap analysis. The gap/overlap analysis will employ machine logic, but this is not necessarily clinical rules (other than equivalence based on codes and subsumptions).

- Support analysis and clean-up disjoint, redundant, or conflicting plans; Can be invoked over a single plan or multiple plans.

- automatically organize POCs under CPs; combine POCs for the same specialty.

- any generated suggestions are "proposed" - not automatically accepted.

- Could propose alternatives.

- In addition to on-demand invocations, an implementation could provide that an agent process suggests gaps and overlaps asynchronoiusly (upon some change, or evaluated periodically)

Clinical Decision Support Integration

- Include operations from the CDS swim lane of the generic Car Plan process model (recommend goals; planned actions, etc.)

- Connect the CDS agent as a collaboration participant, so that CDS output is delivered as correspondence inside the CCS "collaboration" framework. the responses may attached suggested plan items in a "proposed" status.

- a care team member can request advice on some selected plan components (some or all of the plan)

- As an implementation note, if the CCS implementation virtualizes its plan items as vMR constructs, then third-party HL7-standard knowledge modules could be invoked on its plans.