Difference between revisions of "Care Coordination Capabilities"
Line 1,419: | Line 1,419: | ||
None | None | ||
|} | |} | ||
− | |||
− | |||
=<span style="color:blue">Clinical Appropriateness Capability</span>= | =<span style="color:blue">Clinical Appropriateness Capability</span>= |
Revision as of 03:47, 14 March 2013
Return to: Care Coordination Service
Contents
- 1 Business Purpose of the Specification
- 2 Overview of Coordination of Care Capabilities
- 3 Business Capabilities
- 4 Care Plan Capability Set
- 5 Care Collaboration - Mark Action Items Capability Set
- 6 Care Collaboration - Care Team Capability Set
- 7 Care Collaboration - Care Team Conversation Capability Set
- 8 Care Collaboration - Participant Availability Capability Set
- 9 Patient Observations Capability Set
- 10 Link Supportive Content
- 11 Clinical Appropriateness Capability
- 12 Recommend Plan Template Capability
- 13 Care Plan Implementation Capability Set
- 14 Care Review Capability Set
- 15 Consolidation/Reconciliation Capability Set
- 16 Documentation Template for Capability Details
Business Purpose of the Specification
Presently in the Health Care industry, a patient may be under concurrent treatment by a variety of physicians and specialists, and each of these maintains a “plan” that suits their perspectives, purposes, and time horizons. Without mechanism to positively coordinate these plans, gaps and overlaps emerge, leading to compromised quality and efficiency of care. These stakes are especially high in cases of chronic conditions (or multiple chronic conditions, such as Diabetes plus Cardiovascular disease).
The purpose of the HSSP Care Coordination Service (CCS) is to support collaborative planning and execution of operational health care around a “coordinating” care plan that is live and shared among a multi-disciplinary care team. The care team may be dynamically managed to consist of members from either the same or different organizations (e.g. primary care clinic, home care, allied health professionals, hospital, skilled nursing facility, etc.)
There exist standards from HL7 and IHE by which specialty or episodic “plans of care” may be exchanged as CDA documents or sections therein, but there is no standard structure or service that unifies them or directly supports the collaboration, reconciliation, consolidation, and sharing of the “cleaned-up” or reorganized plan.
As regards this sharing, the CCS will allow changes made or proposed by one participant to be immediately viewable by all, and will even support concurrent editing by multiple authors. With that foundation, the CCS allows a primary provider (for example) to raise a controlled discussion around a specified topic,for some selected plan items, or for the plan as a whole. Even a Clinical Decision Support System may participate as a first-class team member, contributing to discussions or raising new discussions.
The CCS should allow for greatly increased manageability of care plans.
Overview of Coordination of Care Capabilities
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.
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 care coordination 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.
Care Plan Capability Set
Create Care Plan
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
This capability establishes a new plan for the patient. A plan can be either a Care Plan, a Plan of Care or a Treatment Plan as defined in the HL7 Patient Care workgroup's Care Plan domain analysis model.
Preconditions |
none |
Inputs |
|
Outputs |
none |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Edit Care Plan
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
This capability supports editing of the intrinsic "plan" attributes.
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Close Care Plan
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
This capability marks the plan as inactive.
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Read Care Plan
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
<<Description here>>
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
<<Description here>>
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Synchronize Care Plan
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
<<Description here>>
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Care Collaboration - Mark Action Items Capability Set
These capabilities allow care team members to organize plan items into groups in support of discussions and actions.
For example:
- To specify a set of conflicting goals that need to be discussed
- To designate two plans to merge
- To specify plan items requiring review or comment
Many operations can be performed on groups of plan items.
Tag Plan Item
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
<<Insert Capability Description Here>>
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
none |
Exception Conditions |
none |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Retrieve Tag Group
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
Retrieve plan item set based on tag names.
Preconditions |
none |
Inputs |
|
Outputs |
Plan Item Set |
Postconditions |
none |
Exception Conditions |
none |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Care Collaboration - Care Team Capability Set
Find Person
Invite Collaboration Participants
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
An invitation is a request from one individual to another to participate as a collaborator in care coordination activities for one patient. Participants join the the Care Team via an invitation based process which results in organically growing the patient's care team. Instead of making a phone call and 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 care coordination 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).
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 |
edit here |
Outstanding Issues |
Discuss role of treatment plan |
Respond to Collaboration Invitation
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
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 invitation token. |
Inputs |
|
Outputs |
none |
Postconditions |
Invited participant becomes a new member of the care team with access to patient care context. |
Exception Conditions |
|
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Add Care Team Member
Remove Care Team Member
Find Collaborator Relationships
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
Care coordinators are collaborators working towards the patient's health goals and execution of care plan and plans of care. Their relationships form a social graph used to support collaboration in care coordination 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 transitions, follow up, closing the loop, etc. This capability helps to identify who is involved and what their role in care is.
These relationships grow organically as the care team sends invitations to collaborate on care coordination activities. For example, an invitation from a licensed independent practitioner (LIP) to a cardiologist results in two new relationship links from the new provider to the patient and between the existing and new providers.
Note: The contents of social 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 Collaboration - Care Team Conversation Capability Set
Care Team Conversation Thread
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
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. 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 (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 a 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 |
edit here |
Outstanding Issues |
|
Invite New Conversation Participants
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
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 |
edit here |
Outstanding Issues |
edit here |
Respond to Conversation Invitation
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
An 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 |
edit here |
Exception Conditions |
Delegated individual not entitled for conversation visibility |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Identity Conversation Thread Participants
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
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 |
edit here |
Outstanding Issues |
edit here |
Care Collaboration - Participant Availability Capability Set
Participant availability the care team's virtual presence for involvement in collaborative interactions to support care coordination activities.
Participants control their online or offline virtual presence as a way to indicate their availability to other members of the care team.
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 Personal Availability for Collaboration
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
Care coordination participants indicate their availability in order to facilitate conversations with collaborating care team members. Availability may include work hours supplemented with online/offline preferences.
Preconditions |
none |
Inputs |
|
Outputs |
none |
Postconditions |
none |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Find Collaborator Availability
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
Care team members may query the availability of other care team members to discover times when joint care coordination conversations may occur.
Preconditions |
Requester must share a care team with the individual whose availability is being requested |
Inputs |
Role and Person information for individual whose availability is being requested |
Outputs |
Availability |
Postconditions |
none |
Exception Conditions |
none |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Patient Observations Capability Set
This capability set supports capture and querying of patient observations. 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:
- Problems
- History (social, family)
- Diagnostic Study Results (lab, radiology)
- Therapeutic Procedure/intervention
- H&P - History and Physical Exam
- Assessment
- Risk
Capture Patient Observations
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
This capability supports capturing of observations. This may include either a single observation or a group of related observations.
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
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
This capability supports association of 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 |
edit here |
Outstanding Issues |
|
Edit Observations
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
This capability supports changing the values of an existing Observation or ObservationGroup.
Preconditions |
none |
Inputs |
|
Outputs |
none |
Postconditions |
none |
Exception Conditions |
none |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Retrieve Observations
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
The retrieve observations capability supports query of patient observations based on time frame and type filters.
Example uses:
- Retrieve patient's problems
- Retrieve patient's family history observations
- Retrieve patient's social history observations
- Retrieve patient's diagnostic results
- Retrieve patient's vital signs
Preconditions |
edit here |
Inputs |
|
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
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).
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
This capability identifies assessment scales to use as part of an observational PlanAction.
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 |
edit here |
Outstanding Issues |
edit here |
Link Supportive Content
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
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. 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 a plan. Any supportive content linked to the care plan level can then be made easily accessible by the UI of a CS-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.
In some cases the content item can be linked via a URL, while in other cases it cannot. Therefore this operation permits links that are not machine processible.
A CCS-enabled client application would make these links to supportive content easily accessible and hard to miss.
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 |
The item is linked to the care plan as supportive content. |
Exception Conditions |
None |
Included in Profiles |
edit here |
Outstanding Issues |
None |
Clinical Appropriateness Capability
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
This capability determines whether a planned action is appropriate given health concerns, health goals, health risks, and existing planned actions.
Preconditions |
Clinical Decision Support System (CDSS) is utilized in the implementation of a CSS collaborative participant. |
Inputs |
Some combination of health concerns, goals and risks, and planned actions have been specified as discussion context. This establishes the scope of the analysis to be performed. |
Outputs |
CDS advice is provided in the form of communications within the discussion. |
Postconditions |
If the CDS advice includes suggestions to add, remove, or modify goals or planned actions, then proposed changes have been attached to the thread (for review and acceptance) |
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 |
edit here |
Outstanding Issues |
JF see phoenix notes and flesh this out |
Recommend Plan Template Capability
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
Definition: A plan template consists of predefined plan elements which are commonly included when addressing one or more health concerns 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.
This capability seeks a recommendation for applicable plan templates given the patient's health concerns, health goals, health risks and care barriers.
Preconditions |
At a minimum, HealthConcern(s) are identified |
Inputs |
|
Outputs |
A CarePlan, PlanOfCare or TreatmentPlan |
Postconditions |
none |
Exception Conditions |
none |
Included in Profiles |
edit here |
Outstanding Issues |
Resolve context which determines how the result plan type is determined (CarePlan, PlanOfCare or TreatmentPlan) |
Care Plan Implementation Capability Set
Mark Start
Minimally this capability records that a specified planned action is started. Optionally, the process is made to actually start, perhaps triggering an HL7 interaction.
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
<<Insert Capability Description Here>>
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Mark Suspend
This capability starts the specified planned action - by whatever means are available to the implmentation
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
<<Insert Capability Description Here>>
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Mark Resume
This capability starts the specified planned action - by whatever means are available to the implmentation
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
<<Insert Capability Description Here>>
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Mark Cancel
This capability starts the specified planned action - by whatever means are available to the implmentation
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
<<Insert Capability Description Here>>
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Mark Complete
This capability starts the specified planned action - by whatever means are available to the implmentation
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
<<Insert Capability Description Here>>
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Monitor Status
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
<<Insert Capability Description Here>>
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Set Execution Status
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
<<Insert Capability Description Here>>
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Allocate Resources
- Human Resources, Rooms, and Materials
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
<<Insert Capability Description Here>>
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Allocate Resources
- Human Resources, Rooms, and Materials
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
<<Insert Capability Description Here>>
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Care Review Capability Set
Acceptance Review
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
Acceptance reviews capture understanding and agreement to adopt a proposal for health goals, interventional actions or the plan itself. E.g. Upon review of the goals and planed actions a care manager (e.g. nurse case manager, social worker, physical therapist, 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.
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Activity Outcome Review
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
An action outcome review measures the result of individual implemented action (observational or interventional) against goal success criteria. The action outcome review might address only a subset of goal success criteria.
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Goal Review
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
Goal reviews reference multiple action outcomes reviews which support overall assessment of a HealthGoal.
Do we still have an appropriate target for these actions that are being undertaken?
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Plan Review
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
Plan reviews are performed at periodic intervals to assess the overall consistency, appropriateness, completeness and effectiveness of the plan. The plan review includes comprehensive review of all the goals.
Preconditions |
edit here |
Inputs |
edit here |
Outputs |
edit here |
Postconditions |
edit here |
Exception Conditions |
edit here |
Included in Profiles |
edit here |
Outstanding Issues |
edit here |
Consolidation/Reconciliation Capability Set
These capabilities operate on multiple plans that are present in the same workspace.
Consolidate Plans Capability
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
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
Capability Status |
2-26-2012 |
Proposed |
Reviewers Here |
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 |