Care Coordination Capabilities

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.

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:

1. Each patient has their own care team
2. The care team is formed on a trusted relationship based model
3. Any care team member can contribute information at anytime
   1. E.g. Adding or changing health goals, concerns, risks, interventions, plan and outcome reviews, etc.
   2. This information actively synchronized to maintain a shared care team context
4. 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	Patient information Active or Archived flag
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	Patient assessment and screening complete At a minimum, HealthConcern(s) are identified
Inputs	HealthConcern(s) [required] HealthGoal(s) [optional] HealthRisk(s) [optional] CareBarrier(s) [optional]
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	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)
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	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
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	Patient Plan identifier Only one of the following plan items: Plan (intrinsic class attributes only) HealthConcern HealthRisk HealthGoal CareBarrier ProposedAction
Outputs	none
Postconditions	Plan version is updated Plan changes are propagated to care team members
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	Plan identifier Plan status [if the plan is abandoned for any reason] AbandonmentReason [optional]
Outputs	none
Postconditions	Plan status change is propagated to care team members
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	Patient information Plan identifier
Outputs	CarePlan, PlanOfCare or TreatmentPlan
Postconditions	none
Exception Conditions	none
Included in Profiles
Outstanding Issues

Share Plan

The “Share Plan” capability supports the ability of users to share the Care Plan with new care team members.

Preconditions	none
Inputs	Patient information Care Plan identifier Provider, CareGiver or SupportingMember information
Outputs	none
Postconditions	none
Exception Conditions	Care Plan has restricted visibility for sharing with target team member (as defined by organization policies)
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	Plan item changes
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 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
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	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 Comments [optional]
Outputs	None
Postconditions	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.
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	Plan Identifier of the plan to which content is linked. Identifier for supportive content item to unlink Comments [optional]
Outputs	None
Postconditions	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.
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	Marking name One or more plan items (e.g. concern, goal) or care record items (allergy, medication) [optional] Applicability time point or time period
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	Patient information Plan identifier [optional] Marking name Applicability time point or time period (a TimeRecord) Include historical flag
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	Personal information of individual Role type of participant (e.g. social worker)
Outputs	Person Role identifier and credentials
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: Patient Provider Care Giver Support Member
Inputs	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
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	Invitation Token Response Type (Accept, Reject, Delegate_Completely, Accept_And_Delegate) Invitation recipient Role and Person details [if response type is delegation] New Collaborator Role and Person Details
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	Invitation has been recalled by placer Invitation has expired due to inaction Invitation cannot be delegated
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	Patient details New collaborator Role and Person details Collaboration Type (e.g. surgery team, consultation) Secure Link to Care Plan
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	Patient details Collaborator to be deleted - Role and Person details
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	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.) [optional] Observations capturing structured answers to questions or forms
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	Invitation placer must be a participant in the existing conversation. New conversation participant must already be a member of the care team
Inputs	Link to existing conversation Role and Person details of the invitation placer Role and Person details of invited participant(s)
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	A unique and expiring invitation Link Response Type (Accept, Reject, Delegate, Accept_And_Delegate) Invitation recipient Role and Person Details [if response type is delegation] Delegated participant Role and Person details
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	Patient role and Person information Plan identifier Conversation thread identifier
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	Role and Person information setting his or her Availability Availability, work schedule Indication of online/offline preferences
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: QualitativeObservation Measurement NaturalLanguageObservation
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	Source observation Target observation Association Type (e.g. interpretation, evaluation, cause)
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	Identify enumeration of association types

Edit Observations

The “Edit Observations” capability supports the ability of users to make changes to previously made observations or observation groups.

Preconditions	none
Inputs	Existing Observation or ObservationGroup New Observation or ObservationGroup
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	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...
Outputs	ObservationGroup(s) or Observation(s)
Postconditions
Exception Conditions
Included in Profiles
Outstanding Issues	Kevin: Get more requirements Document observation types

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: Health Concern(s) Health Goal(s) Health Risk(s) Current Plan Action(s) and Proposed Action
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	New ProposedAction [optional] Context (Health Concern, HealthGoal, HealthRisk, Care Barrier, other ProposedAction(s) or ImplementedAction(s).
Outputs	none
Postconditions	none
Exception Conditions	Action is contraindicated Duplicate Action
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	ProposedAction (some actions must be reviewed but that is determined based on configured policy or rules). [optional] Context (Health Concern, HealthGoal, HealthRisk, Care Barrier, other ProposedAction(s) or ImplementedAction(s).
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	ImplementedAction Suspension Reason
Outputs	None
Postconditions	ImplementedAction state is synchronized for all care team participants
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	ImplementedAction
Outputs	None
Postconditions	ImplementedAction state is synchronized for all care team participants
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	ImplementedAction Reason for abandoning the action
Outputs	None
Postconditions	ImplementedAction state is synchronized for all care team participants
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	ImplementedAction state is synchronized for all care team participants
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	Specific resource Entity (person, room, material, substance, etc) Resource capacity or role Time period [optional] quantity
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	Focus plan item (HealthGoal, ProposedAction, or “Plan”) AcceptanceReview object
Outputs	none
Postconditions	Review status is synchronized for all care team participants
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	ActionOutcomeReview [if action completed] Observation outcome 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	Review status is synchronized for all care team participants
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	HealthGoal GoalReview ActionOutcomeReview(s) supporting the goal review
Outputs	None
Postconditions	Review status is synchronized for all care team participants
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	Care Plan, Plan of Care or Treatment Plan Plan Review Included GoalReview(s)
Outputs	None
Postconditions	Review status is synchronized for all care team participants
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) Please specify as a subsection of a logical capability set grouping
Description	[Mandatory] High-level [functional] description of the expected behavior Please document as free form paragraph after capability title header
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