Difference between revisions of "Care Coordination Capabilities"
m |
|||
(238 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
+ | [[category:Patient Care]] [[category:Service Oriented Architecture]] [[category:Care Coordination Service]] | ||
+ | |||
+ | [[File:go_back.png|32px|link=Coordination of Care Services Specification Project]] | ||
+ | '''Return to:''' [[Coordination of Care Services Specification Project]] | ||
+ | |||
+ | <div style="border:1px solid lightgrey;padding:8px;"> | ||
+ | [[image:notice.png|48x48px]] <b>Please refer to the latest version of the HL7 published Coordination of Care Services Functional model. This page was last updated February 2014.</b> | ||
+ | </div> | ||
+ | <br /> | ||
+ | |||
+ | =<span style="color:blue">Business Purpose of the Specification</span>= | ||
+ | The Care Coordination Service (CCS) specification is designed to support care team oriented coordinated care, collaboration and communication. The specification provides the operation sets for dynamic care team interactions unfolding through time in diverse care settings. In our view the care team may include the patient, patient’s family, medical providers, care givers and other supporting individuals involved in the patient’s care. The care team interacts through a common context composed of the patient’s care plan and continuity of care record. Each interaction in turns incrementally adds content and information which must be synchronized for the care team to avoid gaps and delays in understanding, breakdowns in communication and to provide improved awareness and visibility of required activities which must be performed. | ||
+ | |||
+ | The CCS specification complements existing health care document and messaging standards by specifying a mechanism for mediating care team member interactions though the process of assessment, care planning and providing care based on a shared care plan and continuity of care record. The CCS mediates by supporting a harmonized care plan and continuity of care record among all the participants. Individual interactions result in new information, updates and changes which are synchronized for all care team stakeholders. This way the care team knows (in a timely manner) when there are corrections, changes and additions to specific elements of the plan and care record. | ||
+ | |||
+ | Some key principles: | ||
+ | |||
+ | #Each patient has their own care team | ||
+ | #The care team is formed on a trusted relationship based model | ||
+ | #Any care team member can contribute information at anytime | ||
+ | ##E.g. Adding or changing health goals, concerns, risks, interventions, plan and outcome reviews, etc. | ||
+ | ##This information actively synchronized to maintain a shared care team context | ||
+ | #The care team maintains visibility and awareness of the process in order to support closed loop interactions, avoid information gaps and eliminate delays due to manual processes. | ||
+ | |||
=<span style="color:blue">Business Capabilities</span>= | =<span style="color:blue">Business Capabilities</span>= | ||
− | + | <nowiki>Capabilities express "abilit[ies] that an organization, person or system possesses" [</nowiki>[http://www.opengroup.org/soa/source-book/soa_refarch/capabilities.htm 1]]. Capabilities are independent of business process and business rules; capabilities express the "what" rather than the "how". | |
− | Capabilities express "abilit[ies] that an organization, person or system possesses" | + | |
+ | The Care Coordination Service (CCS) capabilities comprise the core of the normative content of the HL7 SOA Service Functional Model (SFM) based on the [http://hssp.wikispaces.com/Methodology+and+Architecture+Material Health Services Specification Program (HSSP)] methodology. | ||
+ | |||
+ | These capabilities naturally fall into logical groupings which we'll also represent as UML interfaces in the informative part of the HL7 SOA SFM. The logical groupings will be referred to as capability sets in this document. Please note that this grouping is merely an organizational method for managing the capabilities work product. Individual capabilities will also be mapped to service functional profiles which will guide vendor implementations and conformance. | ||
+ | |||
+ | As a rule the capabilities are independent from organizational policies and business rules. This decoupling allows the CCS capabilities to be combined to support various business processes and organizational policies. This is key for realizing care coordination services through the continuum of care. | ||
+ | |||
+ | The HL7 CCS service functional model (SFM) specifies business service capabilities to support collaboration on coordination of care activities. These business service capabilities are intentionally expressed in terms of the HL7 patient care domain analysis models. A follow up effort by this group in collaboration with OMG will focus on the development of a technical specification which will define services, messages and network communications interactions. | ||
+ | |||
+ | =<span style="color:blue">Plan Capability Set</span>= | ||
+ | |||
+ | The CCS approach to coordination of care is centered on a shared Care Plan which supports a holistic and cross functional view of the patient’s health concerns, health goals, health risks, care barriers and the proposed and implemented interventional actions performed to carry out the plan. The Care Plan is be shared across the continuum of care as the patient interacts with many providers and care givers. The Care Plan is a living object created based on care team conversations (including the patient). It’s a living object in the sense that it unfolds and changes through the progression of care. As such it has the potential to maintain team awareness and eliminate issues and gaps which may occur during transitions of care. | ||
+ | |||
+ | The plan capabilities support the ability of the care team to establish and maintain care plans, plans of care and treatment plans. The capabilities also support synchronizing plan changes in order to maintain the team context current (e.g. were lab tests resulted post discharged communicated to the skilled nursing facility). | ||
+ | |||
+ | The diagram below illustrates the patient’s journey, which can either be a fragmented one or one where care is coordinated by a shared Care Plan. | ||
+ | |||
+ | [[Image:Shared_CarePlan_CareTeamStory.png|624x500px]] | ||
− | + | Unless otherwise noted, Plan refers to Care Plan, Plan of Care or Treatment Plan. | |
− | |||
− | + | ==<span style="color:blue">Find Plan</span>== | |
− | + | The “Find Plan” capability supports the ability of care team users to discover existing care plans, plans of care or treatment plans which have been previously created for the patient. The resulting plans may be either active or archived. | |
− | |||
− | == | + | {| style="border-spacing:0;" |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
− | = | + | |- |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Patient information | ||
+ | * Active or Archived flag | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Zero or more CarePlan(s), PlanOfCare(s), TreatmentPlan(s) | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
− | |||
− | |||
− | | | ||
− | |||
|} | |} | ||
+ | ==<span style="color:blue">Find Plan Template</span>== | ||
− | + | '''''Definition:''''' ''A plan template consists of predefined plan elements which are commonly included when addressing a combination of patient health concerns, health risks and health goals. The plan templates could be based on research, clinical evidence or best practices. For example, there could be a plan template to treat patients with diabetes mellitus and cardiovascular disease which could serve as a starter base Care Plan for such patients.'' | |
− | + | The “Find Plan Template” capability supports the ability of users to locate a best practice Care Plan, PlanOfCare or Treatment Plan for re-use. Plan templates are not associated with individual patients but instead capture re-usable plan elements targeting patient with specific characteristics expressed by health concerns, health risks, health goals and care barriers. Users are expected to personalize and tailor the “plan” based on the patient’s needs and preferences. | |
− | |||
− | |||
− | + | {| style="border-spacing:0;" | |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Patient assessment and screening complete | ||
+ | * At a minimum, HealthConcern(s) are identified | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * <nowiki>HealthConcern(s) [required]</nowiki> | ||
+ | * <nowiki>HealthGoal(s) [optional]</nowiki> | ||
+ | * <nowiki>HealthRisk(s) [optional]</nowiki> | ||
+ | * <nowiki>CareBarrier(s) [optional]</nowiki> | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Zero or more CarePlan(s), PlanOfCare(s) or TreatmentPlan(s) | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Resolve context which determines how the result plan type is determined (CarePlan, PlanOfCare or TreatmentPlan) |
− | | | + | |
− | The | + | |} |
− | + | ||
− | + | ==<span style="color:blue">Create Plan</span>== | |
− | + | ||
− | + | The “Create Plan” capability supports the ability of a user to establish a new plan for the patient. | |
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | '''Inputs''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Patient who is the subject of the plan |
− | * | + | * Plan Type (CarePlan, PlanOfCare, TreatmentPlan) |
− | * | + | * Licensed independent practitioner (LIP) responsible for the CarePlan, PlanOfCare or TreatmentPlan |
− | * | + | * Steward organization |
− | * | + | * Additional care team participants if known (Provider, CareGiver, SupportingMember) |
+ | * Plan details and optional HealthConcern(s), HealthGoal(s), HealthRisk(s), CareBarriers, ProposedAction(s) | ||
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | '''Outputs''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | '''Postconditions''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | '''Exception Conditions''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | '''Included in Profiles''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | '''Outstanding Issues''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|} | |} | ||
− | ==<span style="color:blue"> | + | ==<span style="color:blue">Associate Plans</span>== |
+ | |||
+ | The “Associate Plans” capability supports the ability of users to include discipline specific ''Plans of Care'' in a multidisciplinary ''Care Plan''. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * ''Care Plan'' (container) | ||
+ | * ''Plan of Care'' to be added to ''Care Plan'' | ||
+ | |||
+ | Or | ||
+ | |||
+ | * ''Plan of Care'' (container) | ||
+ | * ''Treatment Plan'' to be added to ''Plan of Care'' | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| one | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Plan type cannot be used as container (e.g. it does not make sense to add a care plan to a plan of care). | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
− | |||
− | |||
− | | | ||
− | |||
|} | |} | ||
− | + | ==<span style="color:blue">Change Plan</span>== | |
− | * | + | |
− | * | + | The “Change Plan” capability supports the ability of users to make changes to existing plans. The changes may include modification of the intrinsic plan attributes or changes to related plan items such as Health Concern(s), Health Risks(s), Health Goals, etc. |
− | + | ||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Patient | ||
+ | * Plan identifier | ||
+ | |||
+ | Only one of the following plan items: | ||
+ | |||
+ | * Plan (intrinsic class attributes only) | ||
+ | * HealthConcern | ||
+ | * HealthRisk | ||
+ | * HealthGoal | ||
+ | * CareBarrier | ||
+ | * ProposedAction | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Plan version is updated | ||
+ | * Plan changes are propagated to care team members | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | + | |} | |
+ | ==<span style="color:blue">Close Plan</span>== | ||
+ | |||
+ | The “Close Plan” capability supports the ability of users to indicate the plan is no longer used. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | '''Inputs''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Plan identifier |
− | * | + | * Plan status |
− | * | + | * <nowiki>[if the plan is abandoned for any reason] AbandonmentReason [optional]</nowiki> |
− | + | ||
− | *<nowiki>[if | + | |
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | '''Outputs''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | '''Postconditions''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Plan status change is propagated to care team members |
− | + | ||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | '''Exception Conditions''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Plan already closed |
− | | | + | |
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | '''Included in Profiles''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | '''Outstanding Issues''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|} | |} | ||
+ | ==<span style="color:blue">Read Plan</span>== | ||
+ | |||
+ | The “Read Plan” capability supports the ability of users to retrieve content of plans for reading. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Patient information | ||
+ | * Plan identifier | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| CarePlan, PlanOfCare or TreatmentPlan | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
− | |||
− | |||
− | | | ||
− | |||
|} | |} | ||
− | + | ==<span style="color:blue">Share Plan</span>== | |
+ | |||
+ | The “Share Plan” capability supports the ability of users to share the Care Plan with new care team members. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Patient information | ||
+ | * Care Plan identifier | ||
+ | * Provider, CareGiver or SupportingMember information | ||
+ | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | '''Preconditions''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | + | |- | |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Care Plan has restricted visibility for sharing with target team member (as defined by organization policies) | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | |||
+ | |} | ||
+ | ==<span style="color:blue">Synchronize Plan</span>== | ||
+ | |||
+ | |||
+ | The “Synchronize Plan” capability supports the CCS system in maintaining up to date context by propagating Care Plan changes to all care team members. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | '''Inputs''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Plan item changes |
− | + | ||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | '''Outputs''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | '''Postconditions''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| All care team member views of the Care Plan are synchronized |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | '''Exception Conditions''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | '''Included in Profiles''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | '''Outstanding Issues''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|} | |} | ||
+ | ==<span style="color:blue">Publish Plan Template</span>== | ||
+ | |||
+ | The “Publish Plan Template” capability supports the ability of users to publish condition specific re-usable plans. | ||
+ | |||
− | = | + | {| style="border-spacing:0;" |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
− | == | + | |- |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Care Plan, Plan Of Care or Treatment Plan made up with a subset of the following | ||
+ | |||
+ | * One or more HealthConcern(s) | ||
+ | * One or more ProposedAction(s) | ||
+ | * Optional HealthRisk(s) | ||
+ | * Optional CareBarrier(s) | ||
+ | |||
+ | Optional Plan identifier if the publish operation is replacing an existing Plan template | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
− | |||
− | |||
− | | | ||
− | |||
|} | |} | ||
− | + | =<span style="color:blue">Manage Supportive Plan Content Capability Set</span>= | |
+ | |||
+ | ==<span style="color:blue">Associate Supportive Content</span>== | ||
+ | |||
+ | The “Associate Supportive Content” capability supports the ability of users to link relevant historical content to an active Care Plan, Plan of Care or Treatment Plan. This historical content may originate from either prior non-active plans or from the patient’s care record. For example, a kidney transplant procedure note would stay relevant to care planning for the life of the patient. A duly authorized user should be able to link (or unlink) supportive content to the plan. Any supportive content linked to the care plan level can then be made easily accessible by the UI of a CCS-enabled client application (subject to access controls). However, any supportive content linked to a lower-level (plan of care or treatment plan) will "fall off" the care plan as soon as the plan of care is closed. | ||
+ | |||
+ | Supportive content from the care record may include allergies, medications, procedures, diagnostic tests, etc. | ||
+ | |||
+ | Supportive content may also originate from historical plans. The majority of plan items contained in plans of care and treatment plans will have no continuing relevance after the plan is closed. However, there will be some items - whether from closed care plans or from the health record - that will stay important for future planning. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| There exists some content from the health record or from a closed plan that is of lasting relevance to care planning. | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Plan Identifier of the plan to which content is to be linked. | ||
+ | * Title (to be used in a compact list of the care plan's supportive items) | ||
+ | * Identifier for supportive content item | ||
+ | * <nowiki>Comments [optional]</nowiki> | ||
− | |||
− | |||
− | + | |- | |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * The linked supportive content is propagated to all care team member views of the care plan | ||
+ | * The supportive content item is linked to the care plan. | ||
+ | |||
+ | |||
− | + | |- | |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None | ||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | The | + | |} |
+ | ==<span style="color:blue">Dissociate Supportive Content</span>== | ||
+ | |||
+ | The “Dissociate Supportive Content” capability supports the ability of users to undo associations created through the use of the “Associate Supportive Content” capability. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | '''Inputs''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Plan Identifier of the plan to which content is linked. |
− | * | + | * Identifier for supportive content item to unlink |
− | + | * <nowiki>Comments [optional]</nowiki> | |
− | * | + | |
− | * | + | |
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | '''Outputs''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | '''Postconditions''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * The unlinked supportive content change is reflected in all care team member views of the care plan |
− | + | * The supportive content item is unlinked from the care plan. | |
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | '''Exception Conditions''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | '''Included in Profiles''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | '''Outstanding Issues''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | |||
|} | |} | ||
− | ==<span style="color:blue"> | + | =<span style="color:blue">Mark Plan Items for Action Capability Set</span>= |
− | {| | + | |
+ | In the world of paper care plans we can take a red pen and make markings. As an example, these markings may indicate to follow up, to correct, to consolidate or reconcile, etc. CCS defines a set of common markings which may be applied to electronic care plan items but also allows users to use their own marking names. | ||
+ | |||
+ | The “Mark Plan Items for Action” capabilities support the ability of users to make these markings in the electronic equivalent of the care plan, plan of care or treatment plan. Markings with the same name form groupings, made explicit by CCS as a way to form working sets to support collaborative care team discussions and actions. | ||
+ | |||
+ | For example: | ||
+ | |||
+ | * Care team members can mark conflicting goals that need to be discussed | ||
+ | * Care team members can mark two plans to merge | ||
+ | * Care team members can mark plan items requiring review or follow-up. | ||
+ | |||
+ | Many operations can be performed on groups of plan items. The “Mark Plan Items” capabilities support free form expression as the care team reflects and reacts to information and makes it known to other members of the care team. | ||
+ | |||
+ | A Marking captures a name, an optional time point or time period in which the Marking is relevant and a reference to one or more target objects to which the marking has been applied. | ||
+ | |||
+ | [[Image:]] | ||
+ | |||
+ | ==<span style="color:blue">Mark Plan Item</span>== | ||
+ | |||
+ | The “Mark Plan Item” capability supports the ability of users to tag or label elements of the plan for discussion and action. Markings may be selected from CCS predefined types or they may also be defined by the users. The marking of items could also be performed by a clinical decision support agent. | ||
+ | |||
+ | '''Example Markings:''' Follow up item, Conflicting item, Duplicate item, No Longer Relevant Item, Item Review required | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Marking name | ||
+ | * One or more plan items (e.g. concern, goal) or care record items (allergy, medication) | ||
+ | * <nowiki>[optional] Applicability time point or time period </nowiki> | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
− | |||
− | |||
− | | | ||
− | |||
|} | |} | ||
+ | ==<span style="color:blue">Retrieve Marking Group</span>== | ||
+ | |||
+ | The “Retrieve Marking Group” capability supports users in obtaining plan or care record items marked with a specific label and applying to a specific context. These items form a working set which may be used during discussions and as team action lists. | ||
+ | |||
+ | Examples: | ||
+ | |||
+ | * List items requiring reconciliation | ||
+ | * List post discharge items requiring follow up | ||
+ | * List contraindicated items marked by clinical decision support agent | ||
− | |||
− | {| | + | {| style="border-spacing:0;" |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Patient information | ||
+ | * <nowiki>Plan identifier [optional]</nowiki> | ||
+ | * Marking name | ||
+ | * Applicability time point or time period (a TimeRecord) | ||
+ | * Include historical flag | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Plan item set or care record item set | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | + | |} | |
− | + | ||
+ | =<span style="color:blue">Care Team Capability Set</span>= | ||
+ | |||
+ | |||
+ | Coordination of care is a capability of care teams. It requires a persistent communication channel, common objectives and consistent plan of actions (non-contradictory and non-duplicative efforts which support each other). | ||
+ | |||
+ | With the context of a shared Care Plan: A care team comes together as the patient moves through the continuum of care. A grandfather is admitted to the ER with myocardial infarction, a heart attack. He is suddenly in the surgery room and subsequently finds himself with complications in the hospital. He is eventually discharged to a skilled nursing facility and within the first week visits his primary care provider. | ||
+ | |||
+ | The CCS Care Team capabilities support forming of connected care team. A working care team is the foundation of effective communication, interaction channels and maintenance of current clinical context awareness. Care team, communication and interactions are the heart of collaborative coordination of care. | ||
+ | |||
+ | '''Note:''' A provider has a distinct care team for each of his or her patients. | ||
+ | |||
+ | |||
+ | ==<span style="color:blue">Find Person</span>== | ||
+ | |||
+ | The “Find Person” capability supports the ability of users to locate potential participants for care team collaboration. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Precondition''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Individuals registered in some directory | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | '''Inputs''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Personal information of individual |
− | * | + | * Role type of participant (e.g. social worker) |
− | + | ||
− | * Role | + | |
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | '''Outputs''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Person |
− | + | * Role identifier and credentials | |
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | '''Postconditions''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | '''Exception Conditions''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | '''Included in Profiles''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | '''Outstanding Issues''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|} | |} | ||
+ | ==<span style="color:blue">Invite Collaboration Participants</span>== | ||
+ | |||
+ | An invitation is a request from one individual to another to participate as a collaborator in coordination of care activities for one patient. Participants join the '''Care Team''' via an invitation based process which results in organically growing the patient's care team. Instead of making a phone call or sending faxes a licensed independent practitioner, a nurse or a physician, would send an invitation to collaborate. This invitation is the first step to initiate interactions with new care team members for referrals, transitions of care, consultations, etc. | ||
+ | |||
+ | * A patient can directly invite providers and care givers to join his or her care team (as the patient is the primary member of the care team). | ||
+ | * An invitation may be sent from any existing care team participant to new care team member. | ||
+ | |||
+ | * The patient's delegated steward of their care plan, a licensed independent practitioner (LIP) such as a PCP, nurse manager or other professional care plan facilitators will typically serve as the "seed" of the collaboration forest as they invite other providers to collaborate in coordination of care activities. | ||
+ | |||
+ | Policies and rules regarding who is entitled to send and receive invitations for collaboration and the corresponding level of visibility into patient care activities will continue to be dictated by existing processes (e.g. policies that allow a provider to fax clinical information to a specialist or have a phone conversation about my health conditions). | ||
+ | |||
+ | Invitations are required for inter-organization interactions but optional when working within a single organization where a privileged user could directly add new care team members. | ||
+ | |||
+ | '''Note:''' Invitations are expected to expire after some period of time determined as an implementation option. An invitation could also be recalled by the placer. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Precondition''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| The invitation placer must be an existing member of the patient's care team. This may include the following roles as defined in the HL7 Care Plan model: | ||
+ | |||
+ | * Patient | ||
+ | * Provider | ||
+ | * Care Giver | ||
+ | * Support Member | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Role and Person details for initiating collaborator | ||
+ | * Patient details | ||
+ | * New collaborator Role and Person details | ||
+ | * Collaboration Type (e.g. referral, care transition, consultation) | ||
+ | * Secure Link to Care Plan | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| New collaborator receives a secure message with request for collaboration | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| New collaborator not vetted by external policy checks | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Discuss role of plan of care and treatment plan. Do invitations apply to these? |
− | | | + | |
− | |||
− | |||
− | |||
− | | | ||
− | |||
|} | |} | ||
+ | ==<span style="color:blue">Respond to Collaboration Invitation</span>== | ||
+ | |||
+ | The “Respond to Collaboration Invitation” capability supports the ability of individuals to accept, reject or delegate an invitation to join a patient’s care team. | ||
+ | |||
+ | An invitation response results in the addition of a new care team participant upon acceptance. The recipient of the invitation may also reject the invitation or delegate to a colleague. | ||
+ | |||
+ | Allowed response types are: | ||
+ | |||
+ | * Accept request for collaboration | ||
+ | * Delegate request for collaboration to another participant | ||
+ | * Delegate request but choose to stay in the collaboration loop (e.g. supervising provider) | ||
+ | * Reject request for collaboration | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| A collaboration invitation has been initiated by an active member of the care team and received in the form of a secure message containing a unique and expiring invitation token. | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Invitation Token | ||
+ | * Response Type (Accept, Reject, Delegate_Completely, Accept_And_Delegate) | ||
+ | * Invitation recipient Role and Person details | ||
+ | * <nowiki>[if response type is delegation] New Collaborator Role and Person Details</nowiki> | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Invited participant becomes a member of the care team with access to patient care context but filtered based on organizational role based access controls. | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Invitation has been recalled by placer | ||
+ | * Invitation has expired due to inaction | ||
+ | * Invitation cannot be delegated | ||
− | |||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | + | |- | |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | |||
+ | |} | ||
+ | ==<span style="color:blue">Add Care Team Member</span>== | ||
+ | |||
+ | The “Add Care Team Member” capability supports the ability of a privileged user to bypass the invitation process and directly add members to the team. Invitations are required for inter-organization interactions but can be un-necessary when working within a facility or department. For example, for a patient being scheduled for a surgery, a nurse manager could directly add the surgery team without the need of explicit invitations. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| User performing this capability must have administrative privileges | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | '''Inputs''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Patient details |
− | * | + | * New collaborator Role and Person details |
− | * | + | * Collaboration Type (e.g. surgery team, consultation) |
− | * | + | * Secure Link to Care Plan |
− | + | ||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | '''Outputs''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | '''Postconditions''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | '''Exception Conditions''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | '''Included in Profiles''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | '''Outstanding Issues''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|} | |} | ||
+ | ==<span style="color:blue">Remove Care Team Member</span>== | ||
+ | |||
+ | The “Remove Care Team Member” capability supports the ability of a privileged user to remove an individual from the Care Team. | ||
+ | |||
+ | An individual may also remove themselves from the Care Team. | ||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| User performing this capability must have administrative privileges | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Patient details | ||
+ | * Collaborator to be deleted - Role and Person details | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
− | |||
− | |||
− | | | ||
− | |||
|} | |} | ||
− | << | + | ==<span style="color:blue">Find Collaborator Relationships</span>== |
+ | |||
+ | Care team collaborators work towards the patient's health goals and carry out care plans, plans of care and treatment plans. Their relationships form a social graph used to support collaborative coordination of care activities. This capability supports awareness of the patient's circle of care for all participants of the care team and is the foundation for effective and meaningful communications to support transition follow up communications and closing the loop on pending post-discharge interventions. This capability helps to identify who is involved and what their role in care in order to maintain unbroken context and support effective care team communication. | ||
+ | |||
+ | '''Note:''' The relationship graph may be filtered based on policies and business rules. For example, it may not be desirable for certain team members to discover that a patient is seeing a mental health provider. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Patient Role and Person information |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Persons, the roles they are playing and links based on their role relationships. |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| edit here |
− | | | + | |
− | edit here | ||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| edit here |
− | | | + | |
− | + | |} | |
+ | |||
+ | =<span style="color:blue">Care Team Conversation Capability Set</span>= | ||
+ | |||
+ | |||
+ | Support for effective communication is a key characteristic of collaborating care teams. Conversations may occur at any phase of planning or execution. To be meaningful CCS communications are associated with the clinical context in which they occur. The following diagram illustrates communications pertaining to Health Concerns, Health Risks, Health Goals, Plan Actions, Care Barriers. These are just some examples; a communication could also pertain to the patient’s medications, allergies, family history, etc. | ||
+ | |||
+ | [[Image:]] | ||
+ | |||
+ | ==<span style="color:blue">Care Team Conversation Thread</span>== | ||
+ | |||
+ | Conversation is the heart of collaboration. Any member of the care team may initiate a conversation with another member of the care team at any time in order to coordinate care. CCS conversations cannot occur with individuals outside of the care team. By default the conversation is private to the participants involved. Organizational policies and business rules may determine if a conversation is visible beyond the direct participants. | ||
+ | |||
+ | The CCS conversation model: | ||
+ | |||
+ | * Captures the free form text, natural language, content of business interactions | ||
+ | * May capture structured observations resulting from question/answer electronic form interactions. | ||
+ | * Links to the semantic structured context pertaining to the conversation (structured “clinical statements”) | ||
+ | |||
+ | A conversation may simply consist of free text such as a questions from a patient to his or her provider. A conversation may also pertain to some aspect of the care plan such as: a communication about a specific health goal, health concern, health risk, intervention outcome, associated plan and goal reviews or some diagnostic observation about the patient. The semantic links put the conversation in context. | ||
+ | |||
+ | Conversations will naturally form threads containing multiple communications about some topic. | ||
+ | |||
+ | Care team communications may also have optional multimedia support (attached photograph of video clip) | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| The receiving individual is in an active care team member for the associated patient. | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Patient |
− | + | * Scoping care plan, plan of care or treatment plan | |
− | + | * Communication free form text content | |
+ | * Link to structured semantic context (e.g. Plan, HealthGoal, HealthConcern, Outcomes, Team Member, Reviews, Medications, Allergies, any PlanItemSet, etc.) | ||
+ | * <nowiki>[optional] Observations capturing structured answers to questions or forms</nowiki> | ||
+ | |||
+ | |||
− | = | + | |- |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | | | ||
− | + | |- | |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | + | |} | |
+ | ==<span style="color:blue">Invite New Conversation Participants</span>== | ||
+ | |||
+ | As a default conversations are private to the original participants. The invitation concept allows new participants to join the conversation. | ||
+ | |||
+ | An invitation may be sent by a conversation participant to a member who was not involved in the original thread. The invitation enables the new participant to follow the existing conversation thread and also respond to specific communication entries. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Invitation placer must be a participant in the existing conversation. | ||
+ | * New conversation participant must already be a member of the care team | ||
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Link to existing conversation |
− | + | * Role and Person details of the invitation placer | |
+ | * Role and Person details of invited participant(s) | ||
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| New collaborator receives a secure message with request to join existing conversation |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
− | |||
− | |||
− | | | ||
− | |||
|} | |} | ||
+ | ==<span style="color:blue">Respond to Conversation Invitation</span>== | ||
+ | |||
+ | A conversation invitation response results in the addition of a new participant to the conversation thread upon their acceptance. The recipient of the invitation may also reject the invitation or delegate to a colleague. | ||
+ | |||
+ | Allowed response types are: | ||
+ | |||
+ | * Accept to join conversation | ||
+ | * Delegate to a different participant | ||
+ | * Delegate request but choose to stay in the conversation loop | ||
+ | * Reject to join conversation | ||
+ | |||
− | + | {| style="border-spacing:0;" | |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| There is a pending invitation to join a conversation | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * A unique and expiring invitation Link |
− | + | * Response Type (Accept, Reject, Delegate, Accept_And_Delegate) | |
+ | * Invitation recipient Role and Person Details | ||
+ | * <nowiki>[if response type is delegation] Delegated participant Role and Person details</nowiki> | ||
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Delegated individual not entitled for conversation visibility |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | |
− | + | ||
− | |||
− | |||
− | | | ||
− | '''Outstanding Issues''' | ||
− | | | ||
− | |||
|} | |} | ||
− | =<span style="color:blue"> | + | ==<span style="color:blue">Identify Conversation Thread Participants</span>== |
+ | |||
+ | This capability supports identification of participants involved in a specific conversation thread and their relationships. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Patient role and Person information |
− | + | * Plan identifier | |
− | | | + | * Conversation thread identifier |
− | + | ||
− | |||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Persons, the roles they are playing and links based on their role relationships. |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | + | |} | |
+ | |||
+ | =<span style="color:blue">Participant Availability Capability Set</span>= | ||
+ | |||
+ | Participant availability defines the care team's virtual visibility for involvement in collaborative interactions with other care team members. An individual’s availability is defined by their work schedule and their indication of online or offline settings they control at any time. | ||
+ | |||
+ | '''Online''' indicates that the individual is available. Possible values are: | ||
+ | |||
+ | * Available for all | ||
+ | * Available but away from computers (e.g. don't expect a reply) | ||
+ | * Do not disturb - unless critical | ||
+ | * Do not disturb - unless message pertains to a specific patient identified by the provider | ||
+ | ** e.g. don't bother me during office visits unless it pertains to the patient I am meeting | ||
+ | |||
+ | '''Offline''' indicates that the individual is not available for any interactions with his or her care team. | ||
+ | |||
+ | ==<span style="color:blue">Indicate Availability for Collaboration</span>== | ||
+ | |||
+ | The “Indicate Availability” capability supports the ability of users to indicate their virtual presence for interaction with other care team members. Availability may include work hours supplemented with online/offline preferences. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Role and Person information setting his or her Availability |
− | + | * Availability, work schedule | |
+ | * Indication of online/offline preferences | ||
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | ||
− | |||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Individual visibility to all care teams changes to show their online status |
− | | | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | | | ||
− | + | |- | |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | + | |} | |
+ | ==<span style="color:blue">Find Collaborator Availability</span>== | ||
+ | |||
+ | The “Find Collaborator Availability” capability supports the ability of users to discover when their peers are available for joint online conversations. Note that offline conversations can occur all the time. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Role and Person information for individual whose availability is being requested |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Availability information |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | ||
− | |||
− | | | ||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
− | |||
− | |||
− | | | ||
− | |||
|} | |} | ||
− | << | + | =<span style="color:blue">Patient Observations Capability Set</span>= |
+ | |||
+ | |||
+ | Patient care observations may be made at any stage of the care process. | ||
+ | |||
+ | '''For example:''' | ||
+ | |||
+ | * Subjective and objective observations are made in support of the assessment and screening processes. | ||
+ | * Observations capture intervention outcomes | ||
+ | * Observations capture results of forms questionnaires | ||
+ | * Observations capture results of assessment scales and instruments | ||
+ | |||
+ | '''Some example observation types include:''' | ||
+ | |||
+ | * Problem | ||
+ | * History (social, family) | ||
+ | * Diagnostic Study Results (lab, radiology) | ||
+ | * Therapeutic Procedure/intervention | ||
+ | * H&P - History and Physical Exam | ||
+ | * Assessment | ||
+ | * Risk | ||
+ | * … | ||
+ | |||
+ | [[Image:]] | ||
+ | |||
+ | ==<span style="color:blue">Capture Patient Observations</span>== | ||
+ | |||
+ | The “Capture Patient Observations” capability supports the ability of users to record either single observations or observation groups. Observations may be either qualitative, quantitative/measurements or free form language observations. | ||
+ | |||
+ | [[Image:]] | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| New Observation or ObservationGroup |
− | | | + | |
− | + | The Observation Type can be: | |
+ | |||
+ | * QualitativeObservation | ||
+ | * Measurement | ||
+ | * NaturalLanguageObservation | ||
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Observations made out of range |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| edit here |
− | | | + | |
− | edit here | ||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| edit here | |
− | + | ||
− | |||
− | |||
− | | | ||
− | '''Outstanding Issues''' | ||
− | | | ||
− | edit here | ||
|} | |} | ||
− | == | + | ==<span style="color:blue">Associate Observations</span>== |
− | {| | + | |
+ | The “Associate Observations” capability supports the ability of users to define logical links between related observations. For example, a diagnosis may be associated with the observations which lead to the diagnosis. In this case, the diagnosis observation would be an interpretation of one or more observations. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Source observation |
− | + | * Target observation | |
− | | | + | * Association Type (e.g. interpretation, evaluation, cause) |
− | + | ||
− | |||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Inconsistent association (e.g if source and target were reversed when associating a diagnosis with its supporting observations) |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Identify enumeration of association types |
− | + | ||
+ | |||
+ | |||
+ | |} | ||
+ | |||
+ | ==<span style="color:blue">Edit Observations</span>== | ||
+ | |||
+ | The “Edit Observations” capability supports the ability of users to make changes to previously made observations or observation groups. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Existing Observation or ObservationGroup |
− | + | * New Observation or ObservationGroup | |
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Post conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | | | ||
− | + | |- | |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | + | |} | |
+ | ==<span style="color:blue">Retrieve Observations</span>== | ||
+ | |||
+ | The “Retrieve Observations” capability supports the ability of users to query patient observations based on time frame and observation type filters. | ||
+ | |||
+ | Example uses: | ||
+ | |||
+ | * Retrieval of patient's problems | ||
+ | * Retrieval of patient's family history observations | ||
+ | * Retrieval of patient's social history observations | ||
+ | * Retrieval of patient's diagnostic results | ||
+ | * Retrieval of patient's vital signs | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Patient |
− | + | * Date Range | |
+ | * Encounter Identifier | ||
+ | * Observation Type Code | ||
+ | ** Problems | ||
+ | ** History (social, family) | ||
+ | ** Diagnostic Study Results | ||
+ | ** Therapeutic Procedure/intervention | ||
+ | ** H&P History and Physical Exam | ||
+ | ** Assessment | ||
+ | ** Risk | ||
+ | ** etc... | ||
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| ObservationGroup(s) or Observation(s) |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | ||
− | |||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Kevin: Get more requirements |
− | + | * Document observation types | |
− | + | ||
− | + | ||
− | + | ||
− | |||
|} | |} | ||
+ | ==<span style="color:blue">Identify Health Assessment Scales</span>== | ||
+ | |||
+ | '''Assessment Scale:''' A measurement instrument used to evaluate the health status of a person (e.g. quantitative, qualitative and psychometric assessment scales). | ||
+ | |||
+ | This capability identifies assessment scales to use in support of the execution of a plan action. | ||
− | + | '''Note:''' The HL7 Patient Care Workgroup Assessment Scales topic was balloted as DSTU on December 2012. More information here: [http://wiki.hl7.org/index.php?title=Assessment_Scales http://wiki.hl7.org/index.php?title=Assessment_Scales] | |
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Assessment scale identifier | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | + | |} | |
+ | =<span style="color:blue">Clinical Appropriateness Capability</span>= | ||
+ | |||
+ | The “Clinical Appropriateness Check” capability supports the ability of users and the CCS system to solicit input regarding the appropriateness of a proposed action. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Clinical Decision Support System (CDSS) is utilized in the implementation of a CSS collaborative participant. | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Current Plan Context:''' |
− | + | ||
− | + | * Health Concern(s) | |
+ | * Health Goal(s) | ||
+ | * Health Risk(s) | ||
+ | * Current Plan Action(s) | ||
+ | |||
+ | and | ||
+ | |||
+ | * Proposed Action | ||
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| CDS advice is provided in the form of a Communication and Marking (e.g. a contraindication marking) associated with the evaluated plan items. This may be incorporated into an existing conversation thread or create a new thread depending on the context of the request. |
− | | | + | |
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | | | ||
− | + | |- | |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| If the request activates CDS rules that require additional data, then a notice to that effect is given in the discussion thread, and the implementation may prompt for the required data elements. | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | + | |} | |
+ | |||
+ | =<span style="color:blue">Care Plan Action Capability Set</span>= | ||
+ | |||
+ | |||
+ | The CCS action model captures the essential elements for organizing and tracking actions that define the plan. Actions proposed and implemented by the care team reflect the dynamic nature of an unfolding plan. The “Care Plan Action” capabilities support allocation of required resources and tracking execution status of interventions for the benefit and awareness of the care team. | ||
+ | |||
+ | The Plan Action model: | ||
+ | |||
+ | * Specifies requester(s) | ||
+ | * Specifies performer(s) | ||
+ | * Specifies place of service | ||
+ | * Specifies resource requirements (human resources, assets, consumable materials and services) | ||
+ | * Relates plan actions to outcomes results | ||
+ | * Captures different levels of review (acceptance, authorization, outcome review) | ||
+ | |||
+ | [[Image:]] | ||
+ | |||
+ | ==<span style="color:blue">Propose Action</span>== | ||
+ | |||
+ | The “Propose Action” capability supports the ability of users to specify planned observational, interventional, administrative, logistic or other actions in support of the patient’s care. For example, planning a procedure, diagnostic testing, specifying observations to done for determining follow up care, planning a discharge, etc. This capability may interact with clinical decision support systems in order to check for contraindications or clinical appropriateness based on the action context. Implementations have the option to provide custom behavior as the full context of the action is available to this capability. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | + | * New ProposedAction | |
− | + | * '''<nowiki>[optional]</nowiki>''' Context (Health Concern, HealthGoal, HealthRisk, Care Barrier, other ProposedAction(s) or ImplementedAction(s). | |
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Action is contraindicated |
− | + | * Duplicate Action | |
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
− | |||
− | |||
− | | | ||
− | |||
|} | |} | ||
+ | ==<span style="color:blue">Start Action</span>== | ||
+ | |||
+ | The “Start Action” capability supports the ability of users to indicate the start of an action in order to communicate awareness of status to the care team, and optionally trigger feedback from a clinical decision support agent. Depending on the type of action, implementations might produce interactions with other systems such as HL7 V2 order entry in the case of lab and imaging diagnostic orders. Implementations have the option to provide custom behavior as the full context of the action is available to this capability. | ||
+ | |||
− | + | {| style="border-spacing:0;" | |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | + | * ProposedAction (some actions must be reviewed but that is determined based on configured policy or rules). | |
− | + | * '''<nowiki>[optional]</nowiki>''' Context (Health Concern, HealthGoal, HealthRisk, Care Barrier, other ProposedAction(s) or ImplementedAction(s). | |
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| ImplementedAction |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Required resources not allocated |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | |
− | + | ||
− | |||
− | |||
− | | | ||
− | '''Outstanding Issues''' | ||
− | | | ||
− | |||
|} | |} | ||
− | =<span style="color:blue"> | + | ==<span style="color:blue">Suspend Action</span>== |
+ | |||
+ | The “Suspend Action” capability supports the ability of users to indicate suspension of an action. The status change is synchronized to all members of the care team in order to produce team awareness. Implementations have the option to provide custom behavior as the full context of the action is available to this capability. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| This capability applies to an action which has been started | ||
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * ImplementedAction |
− | + | * Suspension Reason | |
− | | | + | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * ImplementedAction state is synchronized for all care team participants |
− | + | ||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Invalid state exception |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | + | |} | |
+ | ==<span style="color:blue">Resume Action</span>== | ||
+ | |||
+ | The “Resume Action” capability supports the ability of users to resume a previously suspended action. The status change is synchronized to all members of the care team in order to produce team awareness. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| This capability applies to an action which has been suspended | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * ImplementedAction |
− | + | ||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | ||
− | |||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * ImplementedAction state is synchronized for all care team participants |
− | + | ||
− | | | + | |
− | |||
− | |||
− | |||
− | |||
− | + | |- | |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Invalid state exception | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | + | |} | |
+ | ==<span style="color:blue">Cancel Action</span>== | ||
+ | |||
+ | The “Cancel Action” capability supports the ability of users to abandon an action which has not been completed. The status change is synchronized to all members of the care team in order to produce team awareness. Implementations have the option to provide custom behavior as the full context of the action is available to this capability. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| This capability applies to an action which has not been completed | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * ImplementedAction |
− | + | * Reason for abandoning the action | |
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * ImplementedAction state is synchronized for all care team participants |
− | + | ||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Invalid state exception |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | ||
− | |||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
− | |||
− | |||
− | | | ||
− | |||
|} | |} | ||
+ | ==<span style="color:blue">Complete Action</span>== | ||
+ | |||
+ | The “Complete Action” capability supports the ability of users to mark actions as completed. The status change is synchronized to all members of the care team in order to produce team awareness. Implementations have the option to provide custom behavior as the full context of the action is available to this capability. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Applies to actions which have been started and are not suspended or abandoned | ||
− | + | |- | |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| ImplementedAction | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * ImplementedAction state is synchronized for all care team participants |
− | + | ||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | + | |} | |
+ | ==<span style="color:blue">Find Available Resources</span>== | ||
+ | |||
+ | The “Find Available Resources” capability supports the ability of users to determine specific resources which can be scheduled in support of plan actions. Resources include human resources, assets such as room and equipment resources, service resources and consumable material resources such as medicines and controlled substances. | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Specific resource Entity (person, room, material, substance, etc) |
− | + | * Resource capacity or role | |
+ | * Time period | ||
+ | * <nowiki>[optional] quantity</nowiki> | ||
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Potential ResourceAllocation(s) such as ConsumableAllocation, AssetAllocation or ServiceAllocation |
− | | | + | |
− | |||
− | | | ||
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | | | ||
− | + | |- | |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | + | |} | |
+ | ==<span style="color:blue">Check Resource Availability</span>== | ||
+ | |||
+ | The “Check Resource Availability” capability supports the ability of users to determine the status of a resource (whether it is available or already booked). | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| A ResourceAllocation |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Available or booked flag |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | ||
− | |||
− | | | ||
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
− | |||
− | |||
− | | | ||
− | |||
|} | |} | ||
+ | ==<span style="color:blue">Allocate Resource</span>== | ||
+ | |||
+ | The “Allocate Resource” capability supports the ability of users to reserve or book resources for use in support of planning and execution. | ||
+ | |||
− | + | {| style="border-spacing:0;" | |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Proposed ResourceAllocation (ConsumableAllocation, AssetAllocation, ServiceAllocation) |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Resource is booked |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | |
− | + | ||
− | |||
− | |||
− | | | ||
− | '''Outstanding Issues''' | ||
− | | | ||
− | |||
|} | |} | ||
+ | |||
=<span style="color:blue">Care Review Capability Set</span>= | =<span style="color:blue">Care Review Capability Set</span>= | ||
− | == Acceptance Review | + | The care review capabilities enable users to capture shared agreements, authorizations, and acknowledgements to move forward with a planned course of action. The capabilities also enable users to capture their evaluation of whether the plan is progressing as expected. As with all other capabilities, the information is synchronized to other care team members. |
− | {| | + | |
+ | ==<span style="color:blue">Acceptance Review</span>== | ||
+ | |||
+ | The “Acceptance Review” capability supports the ability of users to indicate their agreement, acknowledgement or authorization or plan items such as health goals, proposed actions, or care plans. For example, upon review of the goals and planed actions a care manager (e.g. nurse case manager, social worker, physical therapist, or pharmacist), PCP, nurse and patient will indicate understanding and acceptance of the Care Plan. Acceptance reviews may be used to indicate a provider’s authorization to perform an intervention and another’s provider acknowledgement (e.g. in the case where one provider is in a supervising capacity). | ||
+ | |||
+ | [[Image:]] | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Focus plan item (HealthGoal, ProposedAction, or “Plan”) | ||
+ | * AcceptanceReview object | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| none | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * Review status is synchronized for all care team participants | ||
+ | |||
+ | |||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
− | |||
− | |||
− | | | ||
− | |||
|} | |} | ||
+ | ==<span style="color:blue">Activity Outcome Review</span>== | ||
− | << | + | The “Activity Outcome Review” capability supports the ability of users to evaluate the results of interventions. The review pertains to an individual implemented action against goal success criteria which apply to the specific intervention. The action outcome review might address only a subset of goal success criteria. |
+ | |||
+ | [[Image:]] | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| Implemented Action is completed or abandoned | ||
+ | |||
+ | |- | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| | ||
+ | * ActionOutcomeReview | ||
+ | * <nowiki>[if action completed] Observation outcome</nowiki> | ||
+ | |||
+ | '''Note: '''An action could be abandoned mid-way with a bad outcome review which would be captured when the action is canceled (see Cancel Action capability) | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Review status is synchronized for all care team participants |
− | + | ||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| edit here |
− | | | + | |
− | + | |} | |
+ | ==<span style="color:blue">Goal Review</span>== | ||
+ | |||
+ | The “Goal Review” capability supports the ability of users to reference multiple “Action Outcomes Reviews” which support overall evaluation of a HealthGoal. | ||
+ | |||
+ | [[Image:]] | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * HealthGoal |
− | + | * GoalReview | |
+ | * ActionOutcomeReview(s) supporting the goal review | ||
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | |||
− | |||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Review status is synchronized for all care team participants |
− | + | ||
− | | | + | |
− | |||
− | |||
− | |||
− | |||
− | + | |- | |
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None | ||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | + | |} | |
+ | ==<span style="color:blue">Plan Review</span>== | ||
+ | |||
+ | The “Plan Review” capability supports the ability of users to perform periodic evaluations of the overall consistency, appropriateness, completeness and effectiveness of the plan. The plan review includes comprehensive review of all the goals which in-progress interventions. | ||
+ | |||
+ | [[Image:]] | ||
+ | |||
+ | |||
+ | {| style="border-spacing:0;" | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Preconditions''' | ||
+ | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None | ||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Inputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Care Plan, Plan of Care or Treatment Plan |
− | + | * Plan Review | |
+ | * Included GoalReview(s) | ||
+ | |||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outputs''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Postconditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | * Review status is synchronized for all care team participants |
− | + | ||
+ | |||
+ | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Exception Conditions''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| None |
− | | | + | |
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Included in Profiles''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | ||
− | |||
− | | | ||
− | |||
− | |||
|- | |- | ||
− | | | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| '''Outstanding Issues''' |
− | ''' | + | | style="background-color:#f9f9f9;border:0.75pt solid #aaaaaa;padding:0.0333in;"| |
− | | | + | |
− | |||
− | |||
− | |||
− | | | ||
− | |||
|} | |} | ||
− | << | + | =<span style="color:blue">Consolidation/Reconciliation Capability Set</span>= |
+ | These capabilities operate on multiple plans that are present in the same workspace. | ||
+ | |||
+ | ==<span style="color:blue">Consolidate Plans Capability</span>== | ||
+ | Produce a plan that is the superset of all plan items from the specified original plans. | ||
+ | |||
+ | Unlike the reconciliation capability, this capability actually creates a new resulting plan. As a safety precaution, the consolidation function does not overwrite any of its sources. The new plan may, as a separate operation, be made to overwrite one of the source plans. | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
| | | | ||
'''Preconditions''' | '''Preconditions''' | ||
+ | |||
| | | | ||
− | + | Two or more plans have been included in the working set | |
|- | |- | ||
| | | | ||
'''Inputs''' | '''Inputs''' | ||
+ | |||
| | | | ||
− | + | Reference to a working set that contains to two or more plans (the plans need not be structured yet) | |
+ | |||
+ | Multi-level Override option (to allow consolidation even of plans at multiple levels). If this is not set then the server will consolidate items only of the same level (CPs with CPs, POCs with POCs, TPs with TPs) | ||
+ | |||
|- | |- | ||
| | | | ||
'''Outputs''' | '''Outputs''' | ||
+ | |||
| | | | ||
− | + | Reference to the newly created plan | |
+ | |||
|- | |- | ||
| | | | ||
'''Postconditions''' | '''Postconditions''' | ||
+ | |||
| | | | ||
− | + | A new plan has been created (but not activated). The original plans are '''not''' affected. The content of the new plan is the union of all plan items of the original plans. | |
+ | |||
|- | |- | ||
| | | | ||
'''Exception Conditions''' | '''Exception Conditions''' | ||
+ | |||
| | | | ||
− | + | Specified plans must be of same level (care plan, plan of care, or treatment plan) but override was not requested | |
+ | |||
|- | |- | ||
| | | | ||
− | ''' | + | '''Part of Profiles''' |
+ | |||
| | | | ||
− | + | ||
+ | |||
|- | |- | ||
| | | | ||
− | ''' | + | '''Aspects Left to OMG to Specify''' |
+ | |||
| | | | ||
− | + | <nowiki>[</nowiki>'''Optional]''' | |
− | + | <nowiki>Enumeration of aspects left to the technical specification [may be null]</nowiki> | |
− | |||
− | |||
|- | |- | ||
| | | | ||
− | ''' | + | '''Outstanding Issues''' |
| | | | ||
− | + | <nowiki>[</nowiki>'''Optional]'''If no issues but expect some while the capability is being worked out by the team | |
− | |||
− | |||
− | |||
− | |||
|} | |} | ||
− | << | + | ==<span style="color:blue">Get Reconciliation Work List Capability</span>== |
+ | |||
+ | Given a set of plans or plan items, sort the items by item type (e.g. problems, interventions) and flag those item sets that are suspected as being redundant. This resulting structure could then be the basis for letting the user select the items to remove or to generate proposed removals. | ||
+ | |||
+ | The plans or plan items of concern could be at different levels or at the same level. For example, two "plans of care" are including medication for the same period for the same condition. As another example, a "care plan" and a "plan of care" show the same type of redundancy, but the POC has not been included under the CP. | ||
+ | |||
+ | Note that the CCS server, in order to avoid "false negatives" (falsely concluding that items are not redundant), must utilize terminology assets in order to detect whether an item A "covers" item B even if their concept codes are different (for example Tylenol and Acetaminophen are equivalent and hence to be suspected as redundant) | ||
{| class="wikitable" | {| class="wikitable" | ||
Line 1,419: | Line 2,154: | ||
'''Preconditions''' | '''Preconditions''' | ||
| | | | ||
− | + | Plans of interest are in the working set, even if POCs are not yet linked under PCs | |
|- | |- | ||
| | | | ||
'''Inputs''' | '''Inputs''' | ||
| | | | ||
− | + | Selections of the content to be considered (plan items or entire plans) | |
|- | |- | ||
| | | | ||
'''Outputs''' | '''Outputs''' | ||
| | | | ||
− | + | An ordered collection of Sets of plan items (goals, barriers, interventions, etc.) with flags on items suspected as being redundant. For example, if the input plan items consisted of problems and goals, then the output would contain two major sets (problems and goals) with each major set listing nonredundant items of its type as well as "redundancy" groups for its type. In a "problems and medications" reconciliation, the medications major group might look like the following | |
+ | |||
+ | Medications: (major group) | ||
+ | |||
+ | Ibuprofen (from POC a) | ||
+ | |||
+ | Redundant Group 1 | ||
+ | |||
+ | Tylenol (from POC b) | ||
+ | |||
+ | Acetaminophen (from POC a) | ||
+ | |||
+ | Accolate (from POC b) | ||
+ | |||
|- | |- | ||
| | | | ||
'''Postconditions''' | '''Postconditions''' | ||
| | | | ||
− | + | no effects (the reconciliation work list is delivered as output, but it is not presumed to be stored) | |
|- | |- | ||
| | | | ||
'''Exception Conditions''' | '''Exception Conditions''' | ||
| | | | ||
− | + | None | |
|- | |- | ||
| | | | ||
Line 1,449: | Line 2,197: | ||
'''Outstanding Issues''' | '''Outstanding Issues''' | ||
| | | | ||
− | + | Should this operation "provide the option" to generate proposed item removals? How would it know which items are the keepers. Perhaps at the workspace level the user (the client app) can set precedence rules (the "pecking order" to control what carries). | |
+ | |||
+ | To Do: See HL7 Medication Statement Service (MSS) Profile, balloted in Sep 2012 for DSTU. The CCS output for this capability will be aligned with the MSS structure, but generalized so that reconciliation worksheets for other plan structures (e.g. problems) are supported. | ||
|} | |} | ||
+ | |||
=<span style="color:blue">Documentation Template for Capability Details</span>= | =<span style="color:blue">Documentation Template for Capability Details</span>= | ||
The following template captures the level of detail required for the HL7 SOA HSSP Service Functional Model specification. The details make up section 5 of of the [http://hssp.wikispaces.com/space/showimage/SFM_Boilerplate_V_2-1.rtf SFM boiler plate template] which captures the "Detailed Functional Model for each Interface". | The following template captures the level of detail required for the HL7 SOA HSSP Service Functional Model specification. The details make up section 5 of of the [http://hssp.wikispaces.com/space/showimage/SFM_Boilerplate_V_2-1.rtf SFM boiler plate template] which captures the "Detailed Functional Model for each Interface". |
Latest revision as of 20:53, 9 September 2016
Return to: Coordination of Care Services Specification Project
Please refer to the latest version of the HL7 published Coordination of Care Services Functional model. This page was last updated February 2014.
Contents
- 1 Business Purpose of the Specification
- 2 Business Capabilities
- 3 Plan Capability Set
- 4 Manage Supportive Plan Content Capability Set
- 5 Mark Plan Items for Action Capability Set
- 6 Care Team Capability Set
- 7 Care Team Conversation Capability Set
- 8 Participant Availability Capability Set
- 9 Patient Observations Capability Set
- 10 Clinical Appropriateness Capability
- 11 Care Plan Action Capability Set
- 12 Care Review Capability Set
- 13 Consolidation/Reconciliation Capability Set
- 14 Documentation Template for Capability Details
Business Purpose of the Specification
The Care Coordination Service (CCS) specification is designed to support care team oriented coordinated care, collaboration and communication. The specification provides the operation sets for dynamic care team interactions unfolding through time in diverse care settings. In our view the care team may include the patient, patient’s family, medical providers, care givers and other supporting individuals involved in the patient’s care. The care team interacts through a common context composed of the patient’s care plan and continuity of care record. Each interaction in turns incrementally adds content and information which must be synchronized for the care team to avoid gaps and delays in understanding, breakdowns in communication and to provide improved awareness and visibility of required activities which must be performed.
The CCS specification complements existing health care document and messaging standards by specifying a mechanism for mediating care team member interactions though the process of assessment, care planning and providing care based on a shared care plan and continuity of care record. The CCS mediates by supporting a harmonized care plan and continuity of care record among all the participants. Individual interactions result in new information, updates and changes which are synchronized for all care team stakeholders. This way the care team knows (in a timely manner) when there are corrections, changes and additions to specific elements of the plan and care record.
Some key principles:
- Each patient has their own care team
- The care team is formed on a trusted relationship based model
- Any care team member can contribute information at anytime
- E.g. Adding or changing health goals, concerns, risks, interventions, plan and outcome reviews, etc.
- This information actively synchronized to maintain a shared care team context
- The care team maintains visibility and awareness of the process in order to support closed loop interactions, avoid information gaps and eliminate delays due to manual processes.
Business Capabilities
Capabilities express "abilit[ies] that an organization, person or system possesses" [1]. Capabilities are independent of business process and business rules; capabilities express the "what" rather than the "how".
The Care Coordination Service (CCS) capabilities comprise the core of the normative content of the HL7 SOA Service Functional Model (SFM) based on the Health Services Specification Program (HSSP) methodology.
These capabilities naturally fall into logical groupings which we'll also represent as UML interfaces in the informative part of the HL7 SOA SFM. The logical groupings will be referred to as capability sets in this document. Please note that this grouping is merely an organizational method for managing the capabilities work product. Individual capabilities will also be mapped to service functional profiles which will guide vendor implementations and conformance.
As a rule the capabilities are independent from organizational policies and business rules. This decoupling allows the CCS capabilities to be combined to support various business processes and organizational policies. This is key for realizing care coordination services through the continuum of care.
The HL7 CCS service functional model (SFM) specifies business service capabilities to support collaboration on coordination of care activities. These business service capabilities are intentionally expressed in terms of the HL7 patient care domain analysis models. A follow up effort by this group in collaboration with OMG will focus on the development of a technical specification which will define services, messages and network communications interactions.
Plan Capability Set
The CCS approach to coordination of care is centered on a shared Care Plan which supports a holistic and cross functional view of the patient’s health concerns, health goals, health risks, care barriers and the proposed and implemented interventional actions performed to carry out the plan. The Care Plan is be shared across the continuum of care as the patient interacts with many providers and care givers. The Care Plan is a living object created based on care team conversations (including the patient). It’s a living object in the sense that it unfolds and changes through the progression of care. As such it has the potential to maintain team awareness and eliminate issues and gaps which may occur during transitions of care.
The plan capabilities support the ability of the care team to establish and maintain care plans, plans of care and treatment plans. The capabilities also support synchronizing plan changes in order to maintain the team context current (e.g. were lab tests resulted post discharged communicated to the skilled nursing facility).
The diagram below illustrates the patient’s journey, which can either be a fragmented one or one where care is coordinated by a shared Care Plan.
Unless otherwise noted, Plan refers to Care Plan, Plan of Care or Treatment Plan.
Find Plan
The “Find Plan” capability supports the ability of care team users to discover existing care plans, plans of care or treatment plans which have been previously created for the patient. The resulting plans may be either active or archived.
Preconditions | none |
Inputs |
|
Outputs | Zero or more CarePlan(s), PlanOfCare(s), TreatmentPlan(s) |
Postconditions | none |
Exception Conditions | none |
Included in Profiles | |
Outstanding Issues |
Find Plan Template
Definition: A plan template consists of predefined plan elements which are commonly included when addressing a combination of patient health concerns, health risks and health goals. The plan templates could be based on research, clinical evidence or best practices. For example, there could be a plan template to treat patients with diabetes mellitus and cardiovascular disease which could serve as a starter base Care Plan for such patients.
The “Find Plan Template” capability supports the ability of users to locate a best practice Care Plan, PlanOfCare or Treatment Plan for re-use. Plan templates are not associated with individual patients but instead capture re-usable plan elements targeting patient with specific characteristics expressed by health concerns, health risks, health goals and care barriers. Users are expected to personalize and tailor the “plan” based on the patient’s needs and preferences.
Preconditions |
|
Inputs |
|
Outputs | Zero or more CarePlan(s), PlanOfCare(s) or TreatmentPlan(s) |
Postconditions | none |
Exception Conditions | none |
Included in Profiles | |
Outstanding Issues | Resolve context which determines how the result plan type is determined (CarePlan, PlanOfCare or TreatmentPlan) |
Create Plan
The “Create Plan” capability supports the ability of a user to establish a new plan for the patient.
Preconditions | None |
Inputs |
|
Outputs | none |
Postconditions | none |
Exception Conditions | none |
Included in Profiles | |
Outstanding Issues |
Associate Plans
The “Associate Plans” capability supports the ability of users to include discipline specific Plans of Care in a multidisciplinary Care Plan.
Preconditions | none |
Inputs |
Or
|
Outputs | none |
Postconditions | one |
Exception Conditions | Plan type cannot be used as container (e.g. it does not make sense to add a care plan to a plan of care). |
Included in Profiles | |
Outstanding Issues |
Change Plan
The “Change Plan” capability supports the ability of users to make changes to existing plans. The changes may include modification of the intrinsic plan attributes or changes to related plan items such as Health Concern(s), Health Risks(s), Health Goals, etc.
Preconditions | none |
Inputs |
Only one of the following plan items:
|
Outputs | none |
Postconditions |
|
Exception Conditions | none |
Included in Profiles | |
Outstanding Issues |
Close Plan
The “Close Plan” capability supports the ability of users to indicate the plan is no longer used.
Preconditions | none |
Inputs |
|
Outputs | none |
Postconditions |
|
Exception Conditions | Plan already closed |
Included in Profiles | |
Outstanding Issues |
Read Plan
The “Read Plan” capability supports the ability of users to retrieve content of plans for reading.
Preconditions | none |
Inputs |
|
Outputs | CarePlan, PlanOfCare or TreatmentPlan |
Postconditions | none |
Exception Conditions | none |
Included in Profiles | |
Outstanding Issues |
The “Share Plan” capability supports the ability of users to share the Care Plan with new care team members.
Preconditions | none |
Inputs |
|
Outputs | none |
Postconditions | none |
Exception Conditions |
|
Included in Profiles | |
Outstanding Issues |
Synchronize Plan
The “Synchronize Plan” capability supports the CCS system in maintaining up to date context by propagating Care Plan changes to all care team members.
Preconditions | none |
Inputs |
|
Outputs | none |
Postconditions | All care team member views of the Care Plan are synchronized |
Exception Conditions | none |
Included in Profiles | |
Outstanding Issues |
Publish Plan Template
The “Publish Plan Template” capability supports the ability of users to publish condition specific re-usable plans.
Preconditions | none |
Inputs | Care Plan, Plan Of Care or Treatment Plan made up with a subset of the following
Optional Plan identifier if the publish operation is replacing an existing Plan template |
Outputs | |
Postconditions | None |
Exception Conditions | none |
Included in Profiles | |
Outstanding Issues |
Manage Supportive Plan Content Capability Set
Associate Supportive Content
The “Associate Supportive Content” capability supports the ability of users to link relevant historical content to an active Care Plan, Plan of Care or Treatment Plan. This historical content may originate from either prior non-active plans or from the patient’s care record. For example, a kidney transplant procedure note would stay relevant to care planning for the life of the patient. A duly authorized user should be able to link (or unlink) supportive content to the plan. Any supportive content linked to the care plan level can then be made easily accessible by the UI of a CCS-enabled client application (subject to access controls). However, any supportive content linked to a lower-level (plan of care or treatment plan) will "fall off" the care plan as soon as the plan of care is closed.
Supportive content from the care record may include allergies, medications, procedures, diagnostic tests, etc.
Supportive content may also originate from historical plans. The majority of plan items contained in plans of care and treatment plans will have no continuing relevance after the plan is closed. However, there will be some items - whether from closed care plans or from the health record - that will stay important for future planning.
Preconditions | There exists some content from the health record or from a closed plan that is of lasting relevance to care planning. |
Inputs |
|
Outputs | None |
Postconditions |
|
Exception Conditions | None |
Included in Profiles | |
Outstanding Issues | None |
Dissociate Supportive Content
The “Dissociate Supportive Content” capability supports the ability of users to undo associations created through the use of the “Associate Supportive Content” capability.
Preconditions | |
Inputs |
|
Outputs | None |
Postconditions |
|
Exception Conditions | None |
Included in Profiles | |
Outstanding Issues | None |
Mark Plan Items for Action Capability Set
In the world of paper care plans we can take a red pen and make markings. As an example, these markings may indicate to follow up, to correct, to consolidate or reconcile, etc. CCS defines a set of common markings which may be applied to electronic care plan items but also allows users to use their own marking names.
The “Mark Plan Items for Action” capabilities support the ability of users to make these markings in the electronic equivalent of the care plan, plan of care or treatment plan. Markings with the same name form groupings, made explicit by CCS as a way to form working sets to support collaborative care team discussions and actions.
For example:
- Care team members can mark conflicting goals that need to be discussed
- Care team members can mark two plans to merge
- Care team members can mark plan items requiring review or follow-up.
Many operations can be performed on groups of plan items. The “Mark Plan Items” capabilities support free form expression as the care team reflects and reacts to information and makes it known to other members of the care team.
A Marking captures a name, an optional time point or time period in which the Marking is relevant and a reference to one or more target objects to which the marking has been applied.
[[Image:]]
Mark Plan Item
The “Mark Plan Item” capability supports the ability of users to tag or label elements of the plan for discussion and action. Markings may be selected from CCS predefined types or they may also be defined by the users. The marking of items could also be performed by a clinical decision support agent.
Example Markings: Follow up item, Conflicting item, Duplicate item, No Longer Relevant Item, Item Review required
Preconditions | none |
Inputs |
|
Outputs | none |
Postconditions | none |
Exception Conditions | none |
Included in Profiles | |
Outstanding Issues |
Retrieve Marking Group
The “Retrieve Marking Group” capability supports users in obtaining plan or care record items marked with a specific label and applying to a specific context. These items form a working set which may be used during discussions and as team action lists.
Examples:
- List items requiring reconciliation
- List post discharge items requiring follow up
- List contraindicated items marked by clinical decision support agent
Preconditions | none |
Inputs |
|
Outputs | Plan item set or care record item set |
Postconditions | none |
Exception Conditions | none |
Included in Profiles | |
Outstanding Issues |
Care Team Capability Set
Coordination of care is a capability of care teams. It requires a persistent communication channel, common objectives and consistent plan of actions (non-contradictory and non-duplicative efforts which support each other).
With the context of a shared Care Plan: A care team comes together as the patient moves through the continuum of care. A grandfather is admitted to the ER with myocardial infarction, a heart attack. He is suddenly in the surgery room and subsequently finds himself with complications in the hospital. He is eventually discharged to a skilled nursing facility and within the first week visits his primary care provider.
The CCS Care Team capabilities support forming of connected care team. A working care team is the foundation of effective communication, interaction channels and maintenance of current clinical context awareness. Care team, communication and interactions are the heart of collaborative coordination of care.
Note: A provider has a distinct care team for each of his or her patients.
Find Person
The “Find Person” capability supports the ability of users to locate potential participants for care team collaboration.
Precondition | Individuals registered in some directory |
Inputs |
|
Outputs |
|
Postconditions | None |
Exception Conditions | None |
Included in Profiles | |
Outstanding Issues |
Invite Collaboration Participants
An invitation is a request from one individual to another to participate as a collaborator in coordination of care activities for one patient. Participants join the Care Team via an invitation based process which results in organically growing the patient's care team. Instead of making a phone call or sending faxes a licensed independent practitioner, a nurse or a physician, would send an invitation to collaborate. This invitation is the first step to initiate interactions with new care team members for referrals, transitions of care, consultations, etc.
- A patient can directly invite providers and care givers to join his or her care team (as the patient is the primary member of the care team).
- An invitation may be sent from any existing care team participant to new care team member.
- The patient's delegated steward of their care plan, a licensed independent practitioner (LIP) such as a PCP, nurse manager or other professional care plan facilitators will typically serve as the "seed" of the collaboration forest as they invite other providers to collaborate in coordination of care activities.
Policies and rules regarding who is entitled to send and receive invitations for collaboration and the corresponding level of visibility into patient care activities will continue to be dictated by existing processes (e.g. policies that allow a provider to fax clinical information to a specialist or have a phone conversation about my health conditions).
Invitations are required for inter-organization interactions but optional when working within a single organization where a privileged user could directly add new care team members.
Note: Invitations are expected to expire after some period of time determined as an implementation option. An invitation could also be recalled by the placer.
Precondition | The invitation placer must be an existing member of the patient's care team. This may include the following roles as defined in the HL7 Care Plan model:
|
Inputs |
|
Outputs | none |
Postconditions | New collaborator receives a secure message with request for collaboration |
Exception Conditions | New collaborator not vetted by external policy checks |
Included in Profiles | |
Outstanding Issues | Discuss role of plan of care and treatment plan. Do invitations apply to these? |
Respond to Collaboration Invitation
The “Respond to Collaboration Invitation” capability supports the ability of individuals to accept, reject or delegate an invitation to join a patient’s care team.
An invitation response results in the addition of a new care team participant upon acceptance. The recipient of the invitation may also reject the invitation or delegate to a colleague.
Allowed response types are:
- Accept request for collaboration
- Delegate request for collaboration to another participant
- Delegate request but choose to stay in the collaboration loop (e.g. supervising provider)
- Reject request for collaboration
Preconditions | A collaboration invitation has been initiated by an active member of the care team and received in the form of a secure message containing a unique and expiring invitation token. |
Inputs |
|
Outputs | None |
Postconditions | Invited participant becomes a member of the care team with access to patient care context but filtered based on organizational role based access controls. |
Exception Conditions |
|
Included in Profiles | |
Outstanding Issues |
Add Care Team Member
The “Add Care Team Member” capability supports the ability of a privileged user to bypass the invitation process and directly add members to the team. Invitations are required for inter-organization interactions but can be un-necessary when working within a facility or department. For example, for a patient being scheduled for a surgery, a nurse manager could directly add the surgery team without the need of explicit invitations.
Preconditions | User performing this capability must have administrative privileges |
Inputs |
|
Outputs | none |
Postconditions | none |
Exception Conditions | none |
Included in Profiles | |
Outstanding Issues |
Remove Care Team Member
The “Remove Care Team Member” capability supports the ability of a privileged user to remove an individual from the Care Team.
An individual may also remove themselves from the Care Team.
Preconditions | User performing this capability must have administrative privileges |
Inputs |
|
Outputs | none |
Postconditions | None |
Exception Conditions | None |
Included in Profiles | |
Outstanding Issues |
Find Collaborator Relationships
Care team collaborators work towards the patient's health goals and carry out care plans, plans of care and treatment plans. Their relationships form a social graph used to support collaborative coordination of care activities. This capability supports awareness of the patient's circle of care for all participants of the care team and is the foundation for effective and meaningful communications to support transition follow up communications and closing the loop on pending post-discharge interventions. This capability helps to identify who is involved and what their role in care in order to maintain unbroken context and support effective care team communication.
Note: The relationship graph may be filtered based on policies and business rules. For example, it may not be desirable for certain team members to discover that a patient is seeing a mental health provider.
Preconditions | none |
Inputs | Patient Role and Person information |
Outputs | Persons, the roles they are playing and links based on their role relationships. |
Postconditions | none |
Exception Conditions | none |
Included in Profiles | edit here |
Outstanding Issues | edit here |
Care Team Conversation Capability Set
Support for effective communication is a key characteristic of collaborating care teams. Conversations may occur at any phase of planning or execution. To be meaningful CCS communications are associated with the clinical context in which they occur. The following diagram illustrates communications pertaining to Health Concerns, Health Risks, Health Goals, Plan Actions, Care Barriers. These are just some examples; a communication could also pertain to the patient’s medications, allergies, family history, etc.
[[Image:]]
Care Team Conversation Thread
Conversation is the heart of collaboration. Any member of the care team may initiate a conversation with another member of the care team at any time in order to coordinate care. CCS conversations cannot occur with individuals outside of the care team. By default the conversation is private to the participants involved. Organizational policies and business rules may determine if a conversation is visible beyond the direct participants.
The CCS conversation model:
- Captures the free form text, natural language, content of business interactions
- May capture structured observations resulting from question/answer electronic form interactions.
- Links to the semantic structured context pertaining to the conversation (structured “clinical statements”)
A conversation may simply consist of free text such as a questions from a patient to his or her provider. A conversation may also pertain to some aspect of the care plan such as: a communication about a specific health goal, health concern, health risk, intervention outcome, associated plan and goal reviews or some diagnostic observation about the patient. The semantic links put the conversation in context.
Conversations will naturally form threads containing multiple communications about some topic.
Care team communications may also have optional multimedia support (attached photograph of video clip)
Preconditions | The receiving individual is in an active care team member for the associated patient. |
Inputs |
|
Outputs | none |
Postconditions | none |
Exception Conditions | none |
Included in Profiles | |
Outstanding Issues |
Invite New Conversation Participants
As a default conversations are private to the original participants. The invitation concept allows new participants to join the conversation.
An invitation may be sent by a conversation participant to a member who was not involved in the original thread. The invitation enables the new participant to follow the existing conversation thread and also respond to specific communication entries.
Preconditions |
|
Inputs |
|
Outputs | none |
Postconditions | New collaborator receives a secure message with request to join existing conversation |
Exception Conditions | none |
Included in Profiles | |
Outstanding Issues |
Respond to Conversation Invitation
A conversation invitation response results in the addition of a new participant to the conversation thread upon their acceptance. The recipient of the invitation may also reject the invitation or delegate to a colleague.
Allowed response types are:
- Accept to join conversation
- Delegate to a different participant
- Delegate request but choose to stay in the conversation loop
- Reject to join conversation
Preconditions | There is a pending invitation to join a conversation |
Inputs |
|
Outputs | none |
Postconditions | |
Exception Conditions | Delegated individual not entitled for conversation visibility |
Included in Profiles | |
Outstanding Issues |
Identify Conversation Thread Participants
This capability supports identification of participants involved in a specific conversation thread and their relationships.
Preconditions | none |
Inputs |
|
Outputs | Persons, the roles they are playing and links based on their role relationships. |
Postconditions | none |
Exception Conditions | none |
Included in Profiles | |
Outstanding Issues |
Participant Availability Capability Set
Participant availability defines the care team's virtual visibility for involvement in collaborative interactions with other care team members. An individual’s availability is defined by their work schedule and their indication of online or offline settings they control at any time.
Online indicates that the individual is available. Possible values are:
- Available for all
- Available but away from computers (e.g. don't expect a reply)
- Do not disturb - unless critical
- Do not disturb - unless message pertains to a specific patient identified by the provider
- e.g. don't bother me during office visits unless it pertains to the patient I am meeting
Offline indicates that the individual is not available for any interactions with his or her care team.
Indicate Availability for Collaboration
The “Indicate Availability” capability supports the ability of users to indicate their virtual presence for interaction with other care team members. Availability may include work hours supplemented with online/offline preferences.
Preconditions | none |
Inputs |
|
Outputs | none |
Postconditions | Individual visibility to all care teams changes to show their online status |
Exception Conditions | |
Included in Profiles | |
Outstanding Issues |
Find Collaborator Availability
The “Find Collaborator Availability” capability supports the ability of users to discover when their peers are available for joint online conversations. Note that offline conversations can occur all the time.
Preconditions | |
Inputs | Role and Person information for individual whose availability is being requested |
Outputs | Availability information |
Postconditions | none |
Exception Conditions | none |
Included in Profiles | |
Outstanding Issues |
Patient Observations Capability Set
Patient care observations may be made at any stage of the care process.
For example:
- Subjective and objective observations are made in support of the assessment and screening processes.
- Observations capture intervention outcomes
- Observations capture results of forms questionnaires
- Observations capture results of assessment scales and instruments
Some example observation types include:
- Problem
- History (social, family)
- Diagnostic Study Results (lab, radiology)
- Therapeutic Procedure/intervention
- H&P - History and Physical Exam
- Assessment
- Risk
- …
[[Image:]]
Capture Patient Observations
The “Capture Patient Observations” capability supports the ability of users to record either single observations or observation groups. Observations may be either qualitative, quantitative/measurements or free form language observations.
[[Image:]]
Preconditions | none |
Inputs | New Observation or ObservationGroup
The Observation Type can be:
|
Outputs | none |
Postconditions | none |
Exception Conditions | Observations made out of range |
Included in Profiles | edit here |
Outstanding Issues | edit here |
Associate Observations
The “Associate Observations” capability supports the ability of users to define logical links between related observations. For example, a diagnosis may be associated with the observations which lead to the diagnosis. In this case, the diagnosis observation would be an interpretation of one or more observations.
Preconditions | none |
Inputs |
|
Outputs | none |
Postconditions | none |
Exception Conditions | Inconsistent association (e.g if source and target were reversed when associating a diagnosis with its supporting observations) |
Included in Profiles | |
Outstanding Issues |
|
Edit Observations
The “Edit Observations” capability supports the ability of users to make changes to previously made observations or observation groups.
Preconditions | none |
Inputs |
|
Outputs | none |
Post conditions | none |
Exception Conditions | none |
Included in Profiles | |
Outstanding Issues |
Retrieve Observations
The “Retrieve Observations” capability supports the ability of users to query patient observations based on time frame and observation type filters.
Example uses:
- Retrieval of patient's problems
- Retrieval of patient's family history observations
- Retrieval of patient's social history observations
- Retrieval of patient's diagnostic results
- Retrieval of patient's vital signs
Preconditions | |
Inputs |
|
Outputs | ObservationGroup(s) or Observation(s) |
Postconditions | |
Exception Conditions | |
Included in Profiles | |
Outstanding Issues |
|
Identify Health Assessment Scales
Assessment Scale: A measurement instrument used to evaluate the health status of a person (e.g. quantitative, qualitative and psychometric assessment scales).
This capability identifies assessment scales to use in support of the execution of a plan action.
Note: The HL7 Patient Care Workgroup Assessment Scales topic was balloted as DSTU on December 2012. More information here: http://wiki.hl7.org/index.php?title=Assessment_Scales
Preconditions | none |
Inputs | Assessment scale identifier |
Outputs | none |
Postconditions | none |
Exception Conditions | none |
Included in Profiles | |
Outstanding Issues |
Clinical Appropriateness Capability
The “Clinical Appropriateness Check” capability supports the ability of users and the CCS system to solicit input regarding the appropriateness of a proposed action.
Preconditions | Clinical Decision Support System (CDSS) is utilized in the implementation of a CSS collaborative participant. |
Inputs | Current Plan Context:
and
|
Outputs | CDS advice is provided in the form of a Communication and Marking (e.g. a contraindication marking) associated with the evaluated plan items. This may be incorporated into an existing conversation thread or create a new thread depending on the context of the request. |
Postconditions | |
Exception Conditions | If the request activates CDS rules that require additional data, then a notice to that effect is given in the discussion thread, and the implementation may prompt for the required data elements. |
Included in Profiles | |
Outstanding Issues |
Care Plan Action Capability Set
The CCS action model captures the essential elements for organizing and tracking actions that define the plan. Actions proposed and implemented by the care team reflect the dynamic nature of an unfolding plan. The “Care Plan Action” capabilities support allocation of required resources and tracking execution status of interventions for the benefit and awareness of the care team.
The Plan Action model:
- Specifies requester(s)
- Specifies performer(s)
- Specifies place of service
- Specifies resource requirements (human resources, assets, consumable materials and services)
- Relates plan actions to outcomes results
- Captures different levels of review (acceptance, authorization, outcome review)
[[Image:]]
Propose Action
The “Propose Action” capability supports the ability of users to specify planned observational, interventional, administrative, logistic or other actions in support of the patient’s care. For example, planning a procedure, diagnostic testing, specifying observations to done for determining follow up care, planning a discharge, etc. This capability may interact with clinical decision support systems in order to check for contraindications or clinical appropriateness based on the action context. Implementations have the option to provide custom behavior as the full context of the action is available to this capability.
Preconditions | none |
Inputs |
|
Outputs | none |
Postconditions | none |
Exception Conditions |
|
Included in Profiles | |
Outstanding Issues |
Start Action
The “Start Action” capability supports the ability of users to indicate the start of an action in order to communicate awareness of status to the care team, and optionally trigger feedback from a clinical decision support agent. Depending on the type of action, implementations might produce interactions with other systems such as HL7 V2 order entry in the case of lab and imaging diagnostic orders. Implementations have the option to provide custom behavior as the full context of the action is available to this capability.
Preconditions | none |
Inputs |
|
Outputs | ImplementedAction |
Postconditions | none |
Exception Conditions | Required resources not allocated |
Included in Profiles | |
Outstanding Issues |
Suspend Action
The “Suspend Action” capability supports the ability of users to indicate suspension of an action. The status change is synchronized to all members of the care team in order to produce team awareness. Implementations have the option to provide custom behavior as the full context of the action is available to this capability.
Preconditions | This capability applies to an action which has been started |
Inputs |
|
Outputs | None |
Postconditions |
|
Exception Conditions | Invalid state exception |
Included in Profiles | |
Outstanding Issues |
Resume Action
The “Resume Action” capability supports the ability of users to resume a previously suspended action. The status change is synchronized to all members of the care team in order to produce team awareness.
Preconditions | This capability applies to an action which has been suspended |
Inputs |
|
Outputs | None |
Postconditions |
|
Exception Conditions | Invalid state exception |
Included in Profiles | |
Outstanding Issues |
Cancel Action
The “Cancel Action” capability supports the ability of users to abandon an action which has not been completed. The status change is synchronized to all members of the care team in order to produce team awareness. Implementations have the option to provide custom behavior as the full context of the action is available to this capability.
Preconditions | This capability applies to an action which has not been completed |
Inputs |
|
Outputs | None |
Postconditions |
|
Exception Conditions | Invalid state exception |
Included in Profiles | |
Outstanding Issues |
Complete Action
The “Complete Action” capability supports the ability of users to mark actions as completed. The status change is synchronized to all members of the care team in order to produce team awareness. Implementations have the option to provide custom behavior as the full context of the action is available to this capability.
Preconditions | Applies to actions which have been started and are not suspended or abandoned |
Inputs | ImplementedAction |
Outputs | None |
Postconditions |
|
Exception Conditions | None |
Included in Profiles | |
Outstanding Issues |
Find Available Resources
The “Find Available Resources” capability supports the ability of users to determine specific resources which can be scheduled in support of plan actions. Resources include human resources, assets such as room and equipment resources, service resources and consumable material resources such as medicines and controlled substances.
Preconditions | None |
Inputs |
|
Outputs | Potential ResourceAllocation(s) such as ConsumableAllocation, AssetAllocation or ServiceAllocation |
Postconditions | None |
Exception Conditions | None |
Included in Profiles | |
Outstanding Issues |
Check Resource Availability
The “Check Resource Availability” capability supports the ability of users to determine the status of a resource (whether it is available or already booked).
Preconditions | None |
Inputs | A ResourceAllocation |
Outputs | Available or booked flag |
Postconditions | None |
Exception Conditions | None |
Included in Profiles | |
Outstanding Issues |
Allocate Resource
The “Allocate Resource” capability supports the ability of users to reserve or book resources for use in support of planning and execution.
Preconditions | None |
Inputs | Proposed ResourceAllocation (ConsumableAllocation, AssetAllocation, ServiceAllocation) |
Outputs | None |
Postconditions | Resource is booked |
Exception Conditions | |
Included in Profiles | |
Outstanding Issues |
Care Review Capability Set
The care review capabilities enable users to capture shared agreements, authorizations, and acknowledgements to move forward with a planned course of action. The capabilities also enable users to capture their evaluation of whether the plan is progressing as expected. As with all other capabilities, the information is synchronized to other care team members.
Acceptance Review
The “Acceptance Review” capability supports the ability of users to indicate their agreement, acknowledgement or authorization or plan items such as health goals, proposed actions, or care plans. For example, upon review of the goals and planed actions a care manager (e.g. nurse case manager, social worker, physical therapist, or pharmacist), PCP, nurse and patient will indicate understanding and acceptance of the Care Plan. Acceptance reviews may be used to indicate a provider’s authorization to perform an intervention and another’s provider acknowledgement (e.g. in the case where one provider is in a supervising capacity).
[[Image:]]
Preconditions | |
Inputs |
|
Outputs | none |
Postconditions |
|
Exception Conditions | |
Included in Profiles | |
Outstanding Issues |
Activity Outcome Review
The “Activity Outcome Review” capability supports the ability of users to evaluate the results of interventions. The review pertains to an individual implemented action against goal success criteria which apply to the specific intervention. The action outcome review might address only a subset of goal success criteria.
[[Image:]]
Preconditions | Implemented Action is completed or abandoned |
Inputs |
Note: An action could be abandoned mid-way with a bad outcome review which would be captured when the action is canceled (see Cancel Action capability) |
Outputs | None |
Postconditions |
|
Exception Conditions | |
Included in Profiles | |
Outstanding Issues | edit here |
Goal Review
The “Goal Review” capability supports the ability of users to reference multiple “Action Outcomes Reviews” which support overall evaluation of a HealthGoal.
[[Image:]]
Preconditions | None |
Inputs |
|
Outputs | None |
Postconditions |
|
Exception Conditions | None |
Included in Profiles | |
Outstanding Issues |
Plan Review
The “Plan Review” capability supports the ability of users to perform periodic evaluations of the overall consistency, appropriateness, completeness and effectiveness of the plan. The plan review includes comprehensive review of all the goals which in-progress interventions.
[[Image:]]
Preconditions | None |
Inputs |
|
Outputs | None |
Postconditions |
|
Exception Conditions | None |
Included in Profiles | |
Outstanding Issues |
Consolidation/Reconciliation Capability Set
These capabilities operate on multiple plans that are present in the same workspace.
Consolidate Plans Capability
Produce a plan that is the superset of all plan items from the specified original plans.
Unlike the reconciliation capability, this capability actually creates a new resulting plan. As a safety precaution, the consolidation function does not overwrite any of its sources. The new plan may, as a separate operation, be made to overwrite one of the source plans.
Preconditions |
Two or more plans have been included in the working set |
Inputs |
Reference to a working set that contains to two or more plans (the plans need not be structured yet) Multi-level Override option (to allow consolidation even of plans at multiple levels). If this is not set then the server will consolidate items only of the same level (CPs with CPs, POCs with POCs, TPs with TPs) |
Outputs |
Reference to the newly created plan |
Postconditions |
A new plan has been created (but not activated). The original plans are not affected. The content of the new plan is the union of all plan items of the original plans. |
Exception Conditions |
Specified plans must be of same level (care plan, plan of care, or treatment plan) but override was not requested |
Part of Profiles |
|
Aspects Left to OMG to Specify |
[Optional] Enumeration of aspects left to the technical specification [may be null] |
Outstanding Issues |
[Optional]If no issues but expect some while the capability is being worked out by the team |
Get Reconciliation Work List Capability
Given a set of plans or plan items, sort the items by item type (e.g. problems, interventions) and flag those item sets that are suspected as being redundant. This resulting structure could then be the basis for letting the user select the items to remove or to generate proposed removals.
The plans or plan items of concern could be at different levels or at the same level. For example, two "plans of care" are including medication for the same period for the same condition. As another example, a "care plan" and a "plan of care" show the same type of redundancy, but the POC has not been included under the CP.
Note that the CCS server, in order to avoid "false negatives" (falsely concluding that items are not redundant), must utilize terminology assets in order to detect whether an item A "covers" item B even if their concept codes are different (for example Tylenol and Acetaminophen are equivalent and hence to be suspected as redundant)
Preconditions |
Plans of interest are in the working set, even if POCs are not yet linked under PCs |
Inputs |
Selections of the content to be considered (plan items or entire plans) |
Outputs |
An ordered collection of Sets of plan items (goals, barriers, interventions, etc.) with flags on items suspected as being redundant. For example, if the input plan items consisted of problems and goals, then the output would contain two major sets (problems and goals) with each major set listing nonredundant items of its type as well as "redundancy" groups for its type. In a "problems and medications" reconciliation, the medications major group might look like the following Medications: (major group) Ibuprofen (from POC a) Redundant Group 1 Tylenol (from POC b) Acetaminophen (from POC a) Accolate (from POC b) |
Postconditions |
no effects (the reconciliation work list is delivered as output, but it is not presumed to be stored) |
Exception Conditions |
None |
Included in Profiles |
edit here |
Outstanding Issues |
Should this operation "provide the option" to generate proposed item removals? How would it know which items are the keepers. Perhaps at the workspace level the user (the client app) can set precedence rules (the "pecking order" to control what carries). To Do: See HL7 Medication Statement Service (MSS) Profile, balloted in Sep 2012 for DSTU. The CCS output for this capability will be aligned with the MSS structure, but generalized so that reconciliation worksheets for other plan structures (e.g. problems) are supported. |
Documentation Template for Capability Details
The following template captures the level of detail required for the HL7 SOA HSSP Service Functional Model specification. The details make up section 5 of of the SFM boiler plate template which captures the "Detailed Functional Model for each Interface".
Please include at a minimum the mandatory fields when describing new capabilities.
Capability Status |
2-26-2012 |
Proposed |
Link of reviewers doodle poll when approved |
Name |
[Mandatory] A business-friendly name describing the context of the motivating scenario, and is unique within this Functional Model (e.g., “Find a Person” vs. FindPerson)
|
Description |
[Mandatory] High-level [functional] description of the expected behavior
|
Preconditions |
[Mandatory] Business Pre-conditions [may be null], i.e. what conditions must have been satisfied before the action can be requested or carried out |
Inputs |
[Mandatory] Inputs [include both mandatory and optional] |
Outputs |
[Mandatory] Outputs [include both mandatory and optional] |
Postconditions |
[Optional] Business Post-conditions, i.e. what conditions will result from the action being carried out. |
Exception Conditions |
[Mandatory] Business Exception Conditions [may be null] |
Part of Profiles |
[Optional] Specify service functional profiles which include the capability. Please specify if it is required or optional for profile conformance.
|
Aspects Left to OMG to Specify |
[Optional] Enumeration of aspects left to the technical specification [may be null] |
Outstanding Issues |
[Optional]If no issues but expect some while the capability is being worked out by the team |