Scope - Wikispaceshssp.wikispaces.com/...+Submission+Template+v1.5.docx · Web viewiv Title, version. Title, version ... This is the OMG submission template in Word and ODT

Date: July 2014

E This is the OMG submission template in Word and ODT. The OMG document number is pas/2012-04-08. The template was updated with a new Cover and Preface and supersedes OMG document pas/2008-10-01.

Coordination of Care Service (CCS)Version (draft)

__________________________________________________

OMG Document Number:

Normative reference: http://www.omg.org/spec/acronym/1.0/

Machine readable file(s): http://www.omg.org/acronym/20120401

Normative: http://www.omg.org/spec/acronym/20120401/foo.xmi

Non-normative: http://www.omg.org/spec/acronym/20120401/non_normative_foo.xmi

__________________________________________________

Copyright © 2014, company nameCopyright © 2014, Object Management Group, Inc.Copyright © 2014, company name

USE OF SPECIFICATION - TERMS, CONDITIONS & NOTICES

The material in this document details an Object Management Group specification in accordance with the terms, conditions and notices set forth below. This document does not represent a commitment to implement any portion of this specification in any company's products. The information contained in this document is subject to change without notice.

LICENSES

The companies listed above have granted to the Object Management Group, Inc. (OMG) a nonexclusive, royalty-free, paid up, worldwide license to copy and distribute this document and to modify this document and distribute copies of the modified version. Each of the copyright holders listed above has agreed that no person shall be deemed to have infringed the copyright in the included material of any such copyright holder by reason of having used the specification set forth herein or having conformed any computer software to the specification.

Subject to all of the terms and conditions below, the owners of the copyright in this specification hereby grant you a fully-paid up, non-exclusive, nontransferable, perpetual, worldwide license (without the right to sublicense), to use this specification to create and distribute software and special purpose specifications that are based upon this specification, and to use, copy, and distribute this specification as provided under the Copyright Act; provided that: (1) both the copyright notice identified above and this permission notice appear on any copies of this specification; (2) the use of the specifications is for informational purposes and will not be copied or posted on any network computer or broadcast in any media and will not be otherwise resold or transferred for commercial purposes; and (3) no modifications are made to this specification. This limited permission automatically terminates without notice if you breach any of these terms or conditions. Upon termination, you will destroy immediately any copies of the specifications in your possession or control.

PATENTS

The attention of adopters is directed to the possibility that compliance with or adoption of OMG specifications may require use of an invention covered by patent rights. OMG shall not be responsible for identifying patents for which a license may be required by any OMG specification, or for conducting legal inquiries into the legal validity or scope of those patents that are brought to its attention. OMG specifications are prospective and advisory only. Prospective users are responsible for protecting themselves against liability for infringement of patents.

GENERAL USE RESTRICTIONS

Any unauthorized use of this specification may violate copyright laws, trademark laws, and communications regulations and statutes. This document contains information which is protected by copyright. All Rights Reserved. No part of this work covered by copyright herein may be reproduced or used in any form or by any means--graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems--without permission of the copyright owner.

DISCLAIMER OF WARRANTY

WHILE THIS PUBLICATION IS BELIEVED TO BE ACCURATE, IT IS PROVIDED "AS IS" AND MAY CONTAIN ERRORS OR MISPRINTS. THE OBJECT MANAGEMENT GROUP AND THE COMPANIES LISTED ABOVE MAKE NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS PUBLICATION, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF TITLE OR OWNERSHIP, IMPLIED WARRANTY OF MERCHANTABILITY OR WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE OR USE. IN NO EVENT SHALL THE OBJECT MANAGEMENT GROUP OR ANY OF THE COMPANIES LISTED ABOVE BE LIABLE FOR ERRORS CONTAINED HEREIN OR FOR DIRECT, INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, RELIANCE OR COVER DAMAGES, INCLUDING LOSS OF PROFITS, REVENUE, DATA OR USE, INCURRED BY ANY USER OR ANY THIRD PARTY IN CONNECTION WITH THE FURNISHING, PERFORMANCE, OR USE OF THIS MATERIAL, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

The entire risk as to the quality and performance of software developed using this specification is borne by you. This disclaimer of warranty constitutes an essential part of the license granted to you to use this specification.

RESTRICTED RIGHTS LEGEND

Use, duplication or disclosure by the U.S. Government is subject to the restrictions set forth in subparagraph (c) (1) (ii) of The Rights in Technical Data and Computer Software Clause at DFARS 252.227-7013 or in subparagraph (c)(1) and (2) of the Commercial Computer Software - Restricted Rights clauses at 48 C.F.R. 52.227-19 or as specified in 48 C.F.R. 227-7202-2 of the DoD F.A.R. Supplement and its successors, or as specified in 48 C.F.R. 12.212 of the Federal Acquisition Regulations and its successors, as applicable. The specification copyright owners are as indicated above and may be contacted through the Object Management Group, 109 Highland Avenue, Needham, MA 02494, U.S.A.

TRADEMARKS

IMM®, MDA®, Model Driven Architecture®, UML®, UML Cube logo®, OMG Logo®, CORBA® and XMI® are registered trademarks of the Object Management Group, Inc., and Object Management Group™, OMG™ , Unified Modeling Language™, Model Driven Architecture Logo™, Model Driven Architecture Diagram™, CORBA logos™, XMI Logo™, CWM™, CWM Logo™, IIOP™ , MOF™ , OMG Interface Definition Language (IDL)™ , and OMG SysML™ are trademarks of the Object Management Group. All other products or company names mentioned are used for identification purposes only, and may be trademarks of their respective owners.

COMPLIANCE

The copyright holders listed above acknowledge that the Object Management Group (acting itself or through its designees) is and shall at all times be the sole entity that may authorize developers, suppliers and sellers of computer software to use certification marks, trademarks or other special designations to indicate compliance with these materials.

Software developed under the terms of this license may claim compliance or conformance with this specification if and only if the software compliance is of a nature fully matching the applicable compliance points as stated in the specification. Software developed only partially matching the applicable compliance

points may claim only that the software was based on this specification, but may not claim compliance or conformance with this specification. In the event that testing suites are implemented or approved by Object Management Group, Inc., software developed using this specification may claim compliance or conformance with the specification only if the software satisfactorily completes the testing suites.

OMG’s Issue Reporting Procedure

All OMG specifications are subject to continuous review and improvement. As part of this process we encourage readers to report any ambiguities, inconsistencies, or inaccuracies they may find by completing the Issue Reporting Form listed on the main web page http://www.omg.org, under Documents, Report a Bug/Issue (http://www.omg.org/report_issue.)

Table of Contents

1 Scope.........................................................................................................................................12 Conformance.............................................................................................................................13 References.................................................................................................................................14 Terms and Definitions...............................................................................................................15 Symbols.....................................................................................................................................26 Additional Information..............................................................................................................2

6.1 Changes to Adopted OMG Specifications [optional]........................................................................26.2 Acknowledgments...............................................................................................................................2

7 Coordination of Care Services Platform Independent Model....................................................37.0 Overview...........................................................................................................................................37.1 Foundational Model Elements..........................................................................................................4

7.1.1 Identifier 47.1.2 Period 47.1.3 DateTime 47.1.4 Reference 5

7.2 Care Team Membership Domain Model...........................................................................................67.2.1 CareTeam 67.2.2 CareTeamParticipant.................................................................................................................7

7.2.2.4 CareTeamParticipant roles.............................................................................................................................7.2.3 CareTeamMember.....................................................................................................................87.2.4 Practitioner 87.2.5 Organization 87.2.6 Patient 87.2.2 RelatedPerson 8

7.3 Care Team Membership Operations.................................................................................................97.3.1 FindCareTeam 127.3.2 GetCareTeam 127.3.3 AddCareTeam 137.3.4 DeleteCareTeam 137.3.5 ModifyCareTeam 137.3.6 InviteCareTeamParticipant......................................................................................................137.3.7 AddCareTeamParticipant........................................................................................................147.3.8 RemoveCareTeamParticipant..................................................................................................147.3.9 FindCareTeamMember...........................................................................................................147.3.10 AddCareTeamMember..........................................................................................................147.3.11 ModifyCareTeamMember.....................................................................................................147.3.12 CareTeamChangeNotification...............................................................................................147.3.13 AcceptInvitation147.3.14 RejectInvitation 147.3.15 ForwardInvitation..................................................................................................................14

7.4 Care Team Permissions Domain Model..........................................................................................157.4.1 Permissions model...................................................................................................................167.4.2 Security Model – relationship between Operation Permissions, Activities and the Participant167.4.3 Care Team Note Security Model.............................................................................................177.4.4 SecurityRole 177.4.5 SecurityPermission..................................................................................................................177.4.6 SecurityActivity 177.4.7 CareTeamNoteSecurityLevel..................................................................................................17

7.5 Care Team Permissions Operations................................................................................................18

Title, version i

7.5.1 GetSecurityActivities..............................................................................................................187.5.2 GetSecurityRoles 187.5.3 GetSecurityRole 187.5.4 GetSecurityParticipantRoles...................................................................................................187.5.5 AddSecurityRole 187.5.6 ModifySecurityRole................................................................................................................187.5.7 DeleteSecurityRole..................................................................................................................187.5.8 AddSecurityPermission...........................................................................................................187.5.9 ModifySecurityPermission......................................................................................................187.5.10 DeleteSecurityPermission.....................................................................................................197.5.11 AddCareTeamNoteSecurityLevel.........................................................................................197.5.11 ModifyCareTeamNoteSecurityLevel....................................................................................197.5.12 DeleteCareTeamNoteSecurityLevel......................................................................................197.5.13 AddDeniedActivity...............................................................................................................197.5.14 ModifyDeniedActivity..........................................................................................................197.5.15 DeleteDeniedActivity............................................................................................................19

7.6 Care Team Communications Domain Model..................................................................................207.6.1 Notifications 207.6.2 Referenced information...........................................................................................................217.6.3 CareTeamNote 217.6.4 CareTeamNoteComment.........................................................................................................217.6.5 ReferenceInformation..............................................................................................................217.6.6 ClinicalReference217.6.7 DocumentReference................................................................................................................217.6.8 CareTeamNoteNotificationIgnoreRules..................................................................................21

7.7 Care Team Communications Operations........................................................................................217.7.1 AddCareTeamNote..................................................................................................................217.7.2 ModifyCareTeamNote............................................................................................................217.7.3 DeleteCareTeamNote..............................................................................................................217.7.4 AddCareTeamNoteComment..................................................................................................227.7.5 ModifyCareTeamNoteComment.............................................................................................227.7.6 DeleteCareTeamNoteComment..............................................................................................227.7.7 FindNote 227.7.8 GetNote 227.7.9 IgnoreParticipant 227.7.10 UnignoreParticipant..............................................................................................................227.7.11 IgnoreSubject 227.7.12 UnignoreSubject22

7.8 Care Plan Domain Model................................................................................................................237.9 Care Plan Operations.......................................................................................................................247.10 Care Plan Exchange Model...........................................................................................................257.11 Care Plan Exchange Operations....................................................................................................27

7.11.1 MatchPatient 277.11.2 ShareCarePlan 277.11.3 ConsolidatedCarePlanChangeNotification............................................................................277.11.4 RetrieveConsolidatedCarePlan..............................................................................................27

7.12 Reconciliation Domain Model......................................................................................................287.13 Reconciliation Operations.............................................................................................................29

7.13.1 ReconcileGoals 297.13.2 ReconcileInterventions..........................................................................................................297.13.3 ReconcileHealthConcerns.....................................................................................................297.13.4 ReconcileOutcomes...............................................................................................................297.13.5 ReconcileProblems................................................................................................................297.13.6 ReconcileMedications...........................................................................................................297.13.7 ReconcileMedicationAllergies..............................................................................................297.13.8 Other considerations..............................................................................................................30

ii Title, version

7.14 Coordination of Care Services Implementation Considerations...................................................317.14.1 Security 317.14.2 Sharing of information..........................................................................................................317.14.3 Clinical Decision Support.....................................................................................................317.14.4 Identifiers 327.14.4 Screen Sharing and Collaborative Review and Editing........................................................33

8 Coordination of Care Services Platform Specific Model for Web Services...........................348.1 General............................................................................................................................................348.2 PSM for Web Services Specific Conformance Criteria..................................................................34

8.2.1 Security 348.3 Reference to WSDL........................................................................................................................34

9 Coordination of Care Services Platform Specific Model for CCDA......................................359.1 General............................................................................................................................................359.2 PSM for CCDA Specific Conformance Criteria.............................................................................35

8.2.1 Identifiers 358.2.2 Mapping of domain Models to CCDA....................................................................................35

10 Coordination of Care Services Platform Specific Model for FHIR........................................3610.1 General..........................................................................................................................................3610.2 PSM for FHIR Specific Conformance Criteria.............................................................................36

10.2.1 Security 3610.3 Reference to Profile.......................................................................................................................36

11 Coordination of Care Services Platform Specific Model for IHE...........................................3711.1 General..........................................................................................................................................3711.2 PSM for IHE Specific Conformance Criteria...............................................................................37


12 Coordination of Care Services Platform Specific Model for Direct........................................3812.1 General..........................................................................................................................................3812.2 PSM for Direct Specific Conformance Criteria............................................................................38


A.2.1 The following capabilities taken from the HL7 SFM are included within the Submission: 40

Title, version iii

Preface

OMG

Founded in 1989, the Object Management Group, Inc. (OMG) is an open membership, not-for-profit computer industry standards consortium that produces and maintains computer industry specifications for interoperable, portable, and reusable enterprise applications in distributed, heterogeneous environments. Membership includes Information Technology vendors, end users, government agencies, and academia.

OMG member companies write, adopt, and maintain its specifications following a mature, open process. OMG’s specifications implement the Model Driven Architecture® (MDA®), maximizing ROI through a full-lifecycle approach to enterprise integration that covers multiple operating systems, programming languages, middleware and networking infrastructures, and software development environments. OMG’s specifications include: UML® (Unified Modeling Language™); CORBA® (Common Object Request Broker Architecture); CWM™ (Common Warehouse Metamodel); and industry-specific standards for dozens of vertical markets.

More information on the OMG is available at http://www.omg.org/.

OMG SpecificationsAs noted, OMG specifications address middleware, modeling and vertical domain frameworks. All OMG Specifications are available from the OMG website at:http://www.omg.org/spec

Specifications are organized by the following categories:

Business Modeling Specifications

Middleware Specifications• CORBA/IIOP

• Data Distribution Services

• Specialized CORBA

IDL/Language Mapping Specifications

Modeling and Metadata Specifications• UML, MOF, CWM, XMI

• UML Profile

Modernization Specifications

Platform Independent Model (PIM), Platform Specific Model (PSM), Interface Specifications• CORBAServices

• CORBAFacilities

iv Title, version

CORBA Embedded Intelligence Specifications

CORBA Security Specifications

OMG Domain Specifications

Signal and Image Processing Specifications

All of OMG’s formal specifications may be downloaded without charge from our website. (Products implementing OMG specifications are available from individual suppliers.) Copies of specifications, available in PostScript and PDF format, may be obtained from the Specifications Catalog cited above or by contacting the Object Management Group, Inc. at:

OMG Headquarters109 Highland AvenueNeedham, MA 02494USATel: +1-781-444-0404Fax: +1-781-444-0320Email: [email protected]

Certain OMG specifications are also available as ISO standards. Please consult http://www.iso.org

Typographical ConventionsThe type styles shown below are used in this document to distinguish programming statements from ordinary English. However, these conventions are not used in tables or section headings where no distinction is necessary.

Times/Times New Roman - 10 pt.: Standard body text

Helvetica/Arial - 10 pt. Bold: OMG Interface Definition Language (OMG IDL) and syntax elements.

Courier - 10 pt. Bold: Programming language elements.

Helvetica/Arial - 10 pt: Exceptions

NOTE: Terms that appear in italics are defined in the glossary. Italic text also represents the name of a document, specification, or other publication.

Issues

The reader is encouraged to report any technical or editing issues/problems with this specification to http://www.omg.org/report_issue.htm.

Title, version v

http://www.omg.org/report_issue.htm

1 ScopeThis specification specifies a platform-independent model (PIM) and a platform-specific model (PSM) for Web services that define the capabilities and interfaces of a DSS. These models fulfill the requirements specified in the normative sections of the HL7 ‘Coordination of Care’ Service Function Model while improving the simplicity and functional completeness of the service interface.

2 ConformanceThe Conformance clause identifies which clauses of the specification are mandatory (or conditionally mandatory) and which are optional in order for an implementation to claim conformance to the specification.

Note: For conditionally mandatory clauses, the conditions must, of course, be specified.

3 References

3.1 Normative ReferencesThe following normative documents contain provisions which, through reference in this text, constitute provisions of this specification. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply.

List of normative references.

3.2 Non-normative References1 Laura Heermann Langford RN PhD, Stephen Chu MD PhD. “HL7 Care Plan Domain Information Model September 2013 Informative Ballot.” http://wiki.hl7.org/index.php?title=Care_Plan_Project

2 World Health Organization, http://www.who.int/features/factfiles/noncommunicable_diseases/en/index.html

3 Coleman, MD. MPH, Eric A. "Preparing Patients and Caregivers to Participate in Care Delivered Across Settings: The Care Transitions Intervention." Journal of the American Geriatric Society 52, (2004): 1817-1825.

4 Institute of Medicine. “Crossing the Quality Chasm: A New Health System for the 21st Century.” http://www.edu/~/media/Files/Report%20Files/2001/Crssing-theQuality-Chasm/Quality%20Chasm%202001%20%20report%20brief.pdf

4 Terms and DefinitionsFor the purposes of this specification, the following terms and definitions apply.

Term

Definition

Title, version 1

5 SymbolsList of symbols/abbreviations.

6 Additional Information

6.1 Changes to Adopted OMG Specifications [optional]

This specification completely replaces the xxx specification.

6.2 AcknowledgmentsThe following companies submitted this specification:

xxxxx xxxxx xxxxx

The following companies supported this specification:

xxxxx xxxxx xxxxx

2 Title, version

7 Coordination of Care Services Platform Independent Model

7.0 Overview

The following model should the main services and how they are usedcmp Care Plan Exchange Components

«Contributing System»Ambulatory EHR

«In the cloud»Care Coordination Hub

«Contributing System»Acture EHR

«Contributing System»Post-Acuste EHR

«Contributing System»Other clinical system

«interface»CarePlanExchange

Serv ices

«In the cloud»Care Coordination

Application

«interface»Reconciliation Serv ices

«interface»CareTeamMembership

Serv ices

Connectivity for one EHRis shown here

«interface»CareTeamPermission

Serv ices

«interface»CareTeamCommunications

Serv ices

«interface»CarePlan Serv ices


(Optional)

Required

(Dotted) Optional

Legend

(Optional)(Optional)

(Optional)

There are a number of services that enable the management of Care Team, Communication between participant and the exchange of Care Plans.There is also a fine grained Care Plan service through which any element of a Care plan can be updated. Support for this is optional for the EHRs.Finally, there is a reconciliation service that performs reconciliation. It is stateless and can be leveraged by an participating EHR.

Title, version 3

The following model provides an overview of the main objects of the domain models

class Care Management - High Lev el

CareTeam

- ActivePeriod :Period- Identifiers :Identifier[1..*]- LastModifiedDate :DateTime- Name :string

Patient

CareTeamParticipant

- ActivePeriod :Period- Id :Identifier- ParticipantType :CodeableConcept

CareTeamPermissions

- MembershipType :MembershipTypeEnum

CareTeamNote

- Active :boolean- ID :Identifier- LastTimeModified :DateTime- Subject :string

Care Plan

0..*

+Patient

0..1

1

+Participant

0..*

1

1

0..*

0..*

+Patient 1

Figure 0.1 Relationships between the main models described in this PIM

Is there any other relationship between the Care Team and the Care Plan other than that they share a common patient? Yes, update this diagram

7.1 Foundational Model Elements<Diagram to be provided>

7.1.1 Identifier

7.1.2 Period

7.1.3 DateTime

7.1.4 Reference

4 Title, version

7.2 Care Team Membership Domain ModelThe Care Team Membership Domain model is shown below

class Care Team Membership model

CareTeamParticipant


CareTeam

- ActivePeriod :Period- Identi fiers :Identifier[1..*]- LastModifiedDate :DateTime- Name :string

Practitioner Organization Patient RelatedPerson Group

CareTeamMember

- PrimaryContactMethod :intConstraint: The DomainResource must be one of the following types

CareTeamParticipationStatus

- AcceptanceStatus :AcceptanceStatusEnum

+SubjectGroup 0..1

1

+ForwardedTo

0..*

0..*

+Patient 0..1

0..*

1

+Members

0..*1

+Participant

0..*

Figure 1.1 - Care Team Membership Domain model

7.2.1 CareTeam

Description

The Care Team object represents the root of the Care Team. The Care Team contains all the Care Team Members that participate in the care of the Patient. A Care Team is always about a particular patient, so patient is a required attribute

Attributes

ActivePeriod: Period [0..1]

Identifiers:Identifier[1..*]

Specifies the period for which this care team is (or was) active. One or more identifiers associated with the

Title, version 5

Care TeamName:string The name of the Care Team

LastModified:DateTime The last time the Care Team was updated

Associations

Patient : Patient [0..1] References the Patient that the Care Team is treating. Either a patient or a SupportGroup needs to be provided

SubjectGroup:Group[0..1] References the SupportGroup that the Care Team is treating. Either a patient or a SupportGroup needs to be provided

Participants:CareTeamParticipant[0..*] References the Care Team Members participating in the Care Team

7.2.2 CareTeamParticipant

TBD

Membership type (Professional, Person)

Participant type

7.2.2.4 CareTeamParticipant roles

The role is a ValueSet that is based on Snomed. The full ValueSet can be found here https://www.hl7.org/fhir/valueset-participant-role.html

Question: – is ref to FHIR ok, or is there a better ValueSet?

The following table list some examples

Code Display

270002 Female first cousin (person)

375005 Sibling (person)

444000 Legal sibling

609005 Adoptive father (person)

1421009

Specialized surgeon (occupation)

3430008

Radiation therapist (occupation)

3842006

Chiropractor

6 Title, version

https://www.hl7.org/fhir/valueset-participant-role.html

https://www.hl7.org/fhir/valueset-participant-role.html

4162009

Dental assistant (occupation)

7.2.3 CareTeamMember

TBD

7.2.4 Practitioner

A practitioner as defined by HL7 – details TBD

7.2.5 Organization

An organization as defined by HL7 – details TBD

7.2.6 Patient

A patient as defined by HL7 – details TBD

7.2.2 RelatedPerson

A related person as defined by HL7 – details TBD

Title, version 7

7.3 Care Team Membership OperationsDiagram needs to be regenerated for the new operations

8 Title, version

The following diagram describes the Workflow for inviting a Care Team Member to participate in Care Team. Please note that this diagrams uses the Add Care Team member workflow described in diagram nnnn

act Care Team Membership Inv itation

Initial

Accept

Reject

Forward

Inv ite a CareTeamParticipant and set status as prov isional using the

Inv iteCareTeamParticipant operation

Start

Does the CareTeam Member exist?

Lookup Cate Team member using the

FindCareTeamMember Operation

:CareTeamMember

:CareTeamMemberAdd Care Team Member

Please see the following diagram for more detail

Care Team Member must have a primary contact method

Send an inv itation to the CareTeamMember v ia their

preferred contact method

Invitation contains links for Accept Reject Forward

See the Accept, Reject or Forward swimlanes

User signals acceptance

:CareTeamParticipant

:CareTeamParticipantMark Status as Accepted

End AcceptVia link.Link contains reference to the CareTeamParticipant

User signals rejection:CareTeamParticipant

Mark Status as Rejected

End RejectVia link.Link contains reference to the CareTeamParticipant

User signals forward:CareTeamParticipant

Mark Status as Forwarded

End Forward

Via link.Link contains reference to the CareTeamParticipant

:CareTeamParticipationStatus

Care Team Member Inv itation (This Activ ity Diagram)f or a

the member(s) that you forward to

Associate the members to the current participant

:CareTeamMember

:CareTeamMember

[Yes]

[No]

Title, version 9

The following diagram describes the Workflow for adding Care Team member i.e. A Provider, Organization, Patient, RelatedPerson and Group

act Add Care Team Member

Search

Not Found

Found

Start

Retrieve / Find prospective CareTeamMember in the local system, Prov ider

Directory or Patient Directory

SearchoObject :CareTeamMember

Populate the Provider, Patient, Organization, Related Person based on the information you looked up

Lookup CareTeamMembers that match this

CareTeamMember search object using the

FindCareTeamMember operation

Member found?

Add the CareTeamMember as a new object

Update the appropriate fields. This should at least

be the identifier in your system. Might be other

fields

Not FoundFinal

Found Final

Update the eMPI, if appropriate (Done by the

CCC Serv ice)

[Not Found]

[Found]

10 Title, version

Please note that the following operations have not all been updated with the latest information

7.3.1 FindCareTeam

Description

Finds a Care Team object based on search parameters

Attributes

PatientIdentifier: Identifier [0..1]

CareTeamMemberIdentifier:Identifier[0..1

Find Care Teams that are treating this patient. Find Care Teams that this member is participating in.CareTeamMemberIdentifier can be a Practitioner, Organization, Patient or RelatedPerson Identifier, and cascade to groups

Name:string A substring of the name of the care teamPeriod

Returns

:CareTeam[0..*] The care teams that meet the search criteria. Only the CareTeam is returned.Use GetCareTeam to get the detailed information.

Note: By default the activePeriods should be checked and only active records should be included

7.3.2 GetCareTeam

Description

Gets a Care Team object. The Care Team contains all of the CareTeam contained objects, including the participants.

If no status is specified, only participants that have accepted are returned.

Attributes

Identifier: Identifier [0..1] The identifier of a specific Care TeamStatus: CareTeamParticipationStatusEnum[0..*]

One or more CareTeamParticipation

Returns

:CareTeam The care teams that matches the identifier. The Care Team contains all of the CareTeam contained objects, including the participants. The CareTeamParticipationStatus is typically not returned, but will be returned if the Enum is passed in.If the Enum is not passed in, then only

Title, version 11

participants that have accepted will be returned.

7.3.3 AddCareTeam

Description

Adds a new Care Team

Attributes

CareTeam:CareTeam Adds a new Care Team. The CareTeam must contain a Patient Reference, and may contain participants

Returns

:Identifier The identifier for the new Care Team in the system it was added to.

7.3.4 DeleteCareTeamTDB

7.3.5 ModifyCareTeamTDB

7.3.6 InviteCareTeamParticipant

Description

Invites a new participant to join a Care Team. The participant is already existing, i.e. has been added before

Attributes

Participant:CareTeamParticipant Adds a new Care Team participant. The CareTeam participant must contain a Care Team Member

Returns

:Identifier The identifier for the new Care Team participant in the system it was added to.

Please see the activity diagram (Figure nnnn) for more detail on how the invitation process works

12 Title, version

7.3.7 AddCareTeamParticipant

TBD – adds an existing Provider, Patient, … to a CareTeam

This is a privileged operation, used for Admin operations (e.g. when someone calls the Family member, and the don’t have email)

7.3.8 RemoveCareTeamParticipantTDB

7.3.9 FindCareTeamMemberTDB

Please see the activity diagram (Figure nnnn) for more detail on how the a Care Team Member can be looked up from a local system or from an HPD

7.3.10 AddCareTeamMemberTDBAdd provider, patient, etc

7.3.11 ModifyCareTeamMemberTDB

7.3.12 CareTeamChangeNotificationTDB

7.3.13 AcceptInvitationTDBImplementation detail: Please note that we see this being implemented typically as a URL, not a SOAP service endpoint. In other words the Prospective Participant can click on a link to signal their response

7.3.14 RejectInvitationTDBPlease note that we see this being implemented typically as a URL, not a SOAP service endpoint.Implementation detail: Please note that we see this being implemented typically as a URL, not a SOAP service endpoint. In other words the Prospective Participant can click on a link to signal their response

7.3.15 ForwardInvitationTDBImplementation detail: Please note that we see this being implemented typically as a URL, not a SOAP service endpoint. In other words the Prospective Participant can click on a link to signal their response

Title, version 13

7.4 Care Team Permissions Domain ModelThe Care Team permissions Domain model is shown below

class Care Team Permissions Model

CareTeam

- Identifiers :Identifier[1..*]- LastModifiedDate :DateTime

CareTeamParticipant


SecurityActiv ity

- ActivityType :ActivityTypeEnum- ID :Identifier

SecurityPersmission

- Granted :boolean- ID :Identifier

SecurityRole

- ID :Identifier- Name :string- Predefined :bool

CareTeamNote


The participant will only be able to see ProfessionalNotes if they are granted the permission to the ViewProfessionalCareTeamNote activity

CareTeamNoteSecurityLev el

- CareTeamNoteType :CareTeamNoteTypeEnum- ID :Identifier- Predefined :boolean

1

0..*

1

0..*

1

1

+RequiredRoles0..*

1

1

+Participant

0..*

+DeniedActivities

Figure 2.1 - Care Team permissions Domain model

A Participant is assigned one and only one Role. While this may seem restrictive, keep in mind that a Care Team Member can participate in a Care Team as multiple participants. Each time they participate they are assigned a different Security Role.

For example, if a practitioner is the PCP in one role, and the Patient in another (Need a better example) the following relationships will be defined

14 Title, version

Care Team Participant Security Role Member (Practitioner)

Care Team One

ParticipantType = Primary care physician (446050000)

Care Team Leader (Secondary)

Steve Smith MD

ParticipantType = Patient (116154003)

Care Team Member (Personal)

7.4.1 Permissions model

The permissions model is a form of an Access Control List, specifically it is a form of Role Based Access Control, where only groups (roles) have permissions associated with them, and not individual users.An exception is that Participants can be denied specific Activities within the CareTeam. This is intended to avoid conflicts (i.e. someone is in the CareTeam is a particular role but might also be the patient’s parent and they want to prevent access)

Permission precedence logic If an activity is denied for a Participant, then the permission is not granted If no Permission object is present, then the permission shall be treated as NotGranted (Permission.Granted =

False) If multiple permissions are available for a participant (typically due to them having multiple roles)

o If any one of the permission is granted, then the permission shall be granted, even if some permis-sions are not granted or not specified.

Default permissionsWhile it is up to an implementing organization to set the default permissions, the following is an example of how the permissions could be setup

7.4.2 Security Model – relationship between Operation Permissions, Activities and the Participant

While a lot of the detail of the security model is deferred to the Platform Specific Models, then follow will be true regardless and can assist in the understanding of how the permissions and activities will be used.

The first assumption is that the security model for access to operations will be claims or token based. While other models are possible and are not excluded, they share the same primary concern, that the user is identified securely authenticated, and authorization information is available during the execution of any operation.

Title, version 15

The way in which the authorization information will be provided is via the CareTeamParticipant.ID

Any operation will know what SecurityActivity Permissions must be granted for the operation (the RemoveCareTeamParticipant operation would require the Delete Care Team Members activity to be granted).

The operation can then determine if the permission is granted by the Security Role the Participant is associated with.

Using the Participant as the object that provides the security information also allows us to handle the case where a practitioner or other member is part of multiple Care Teams, with different permissions (role) in the Care Teams.

7.4.3 Care Team Note Security Model

Each Care Team Note is associated with a Security Level. Examples of security levels could be

General Note - Entire care team can access this note

Professional Care Team Note - All care team members Care Team members with Professional roles can access this note but no others

Each Security Level is associated with multiple roles.

The logic is the following when determining access to a Note for a Participant.

Lookup the roles of the Participant

Lookup the roles required for the Security Level

Perform an intersection

o If the intersection is not empty, then the participant has access to the Note.

7.4.4 SecurityRoleTBD

7.4.5 SecurityPermissionTBD

7.4.6 SecurityActivityTBD

Note: It is expected that the allowed activities is defined for each implementation. The list of suggested activities can be found in section 7.4.1. Activities cannot be added through the service contract.

7.4.7 CareTeamNoteSecurityLevelTBD

Note: It is expected that some predefined Security Levels are is defined for each implementation. Additional Security Levels can be added through the service contract.

16 Title, version

7.5 Care Team Permissions OperationsThis section lists the operation for Permissions

7.5.1 GetSecurityActivitiesTBD

7.5.2 GetSecurityRolesGet the roles. Only the Security Roles are returned, not any associated objects.

7.5.3 GetSecurityRoleGets a specific role. Returns the SecurityPermissions and SecurityActivities associated with the role

7.5.4 GetSecurityParticipantRolesTBD

7.5.5 AddSecurityRoleTBD

7.5.6 ModifySecurityRoleTBDPredefined (System defined) roles cannot be modified

7.5.7 DeleteSecurityRoleTBDPredefined (System defined) roles cannot be deleted

7.5.8 AddSecurityPermissionTBD

7.5.9 ModifySecurityPermissionTBD

7.5.10 DeleteSecurityPermissionTBD

Title, version 17

7.5.11 AddCareTeamNoteSecurityLevelTBD

7.5.11 ModifyCareTeamNoteSecurityLevelTBDPredefined (System defined) ) Security Levels cannot be modified

7.5.12 DeleteCareTeamNoteSecurityLevelTBDPredefined (System defined) Security Levels cannot be deleted

7.5.13 AddDeniedActivityTBD

7.5.14 ModifyDeniedActivityTBD

7.5.15 DeleteDeniedActivityTBD

18 Title, version

7.6 Care Team Communications Domain ModelThe Care Team Communications Domain model is shown below

class Care Team Communication model

CareTeam

- ActivePeriod :Period- Identifiers :Identifier[1..*]- LastModifiedDate :DateTime- Name :string

CareTeamNote


CareTeamNoteComment

- Active :boolean- DataCreated :DataTime- FormatAsHTML :boolean- NoteTexr :string

CareTeamParticipant

- ActivePeriod :Period- Id :Identi fier- ParticipantType :CodeableConcept

CareTeamNoteNotificationIgnoreRules

- ID :Identifier

ReferenceInformation

ClinicalReference

- reference :Reference

DocumentReference


Subject is unique across all notes associated with the Care Team

1

0..*

+Participant 0..*

1

1 0..*

+Associated Information 0..*

+ParticipantsToIgnoe

0..*

+SubjectsToIgnore0..*

Figure 3.1 - Care Team Communications Domain model

The way to visualize the Care Team Note concept is that it similar to a multi-party conversation over Instant Messaging or text. The Care Team Note (or Subject) is the conversation thread, and the Care Team note Comments are the individual messages that make up the conversation.

The server gives each comment a timestamp when it is received, and that becomes the ordering rule for the comments.

All users that have access to a Care Team Note can see all comments. A Care Team Note has a security associated with it, please see section 7.4.3 for more details.

7.6.1 Notifications

By default a Participant will be notified of any Care Team Notes (Subjects or Conversations) where there have been new comments. The Participant will have the option of ignoring notifications from specific notes, or from specific participants.

Title, version 19

7.6.2 Referenced information

A comment can reference information. This can be to a document (e.g. an image that was uploaded) or to a clinical or care plan item that is part of a Care Plan for the patient.

7.6.3 CareTeamNoteTBD

7.6.4 CareTeamNoteCommentTBD

7.6.5 ReferenceInformationTBD

7.6.6 ClinicalReferenceTBD

7.6.7 DocumentReferenceTBD

7.6.8 CareTeamNoteNotificationIgnoreRulesTBD

7.7 Care Team Communications OperationsThis section lists the operation for Permissions

7.7.1 AddCareTeamNoteTBD

7.7.2 ModifyCareTeamNoteTBD

7.7.3 DeleteCareTeamNoteTBDThis operation hides the note

20 Title, version

7.7.4 AddCareTeamNoteCommentTBDIncludes the ability to specify a reference

7.7.5 ModifyCareTeamNoteCommentTBDIncludes the ability to specify a reference, or change or remove the reference

7.7.6 DeleteCareTeamNoteCommentTBDThis operation hides the note comment

7.7.7 FindNoteTBDThis operation can be used for Notification as well, i.e you can find Notes that have had changes since the last time you checked.Only the Care Team Note objects are returned, not any Comments

7.7.8 GetNoteTBDThis operation can be used for to get Comments as well, including Comments that have had changes since the last time you checked, or are new.

7.7.9 IgnoreParticipantTBD

7.7.10 UnignoreParticipantTBD

7.7.11 IgnoreSubjectTBD

7.7.12 UnignoreSubjectTBD

Title, version 21

7.8 Care Plan Domain ModelThe Care plan Domain model has generated a lot of discussions and revisions, and should be considered the most incom-plete of the PIMs

class Care Plan

Care PlanPatient

- ActivePeriod :string

Goal

- ActivePeriod :Period- Code :int- Confidence :ConfidenceEnum- DeferredUnti l :int- HCPPriority :PriorityEnum- Name :int- PatientPriority :PriorityEnum- State :GoalStateEnum

GoalMilestone

- ProgessFreeText :string- ProgressPercentage :bool- Time :DateTime

Outcome

- State :StateEnum

Problem

Barrier

Intervention

- ActivePeriod :Period- AssociatedItemStatus :StatusEnum- Code :int- FreeText :string- Frequency :Period- HoldReviewDate :Date- PlannedReviewDate :DateTime- Reocurance :Period?- Status :StausEnum

Instruction Medication Order

HealthConcern

- ActivePeriod :Period- Code :int- FreeText :string- Status :StatusEnum

CareteamInterventionRelationship

- CareTeamMembertType/Role- OwneshiprPeriod :Period

CareTeamParticipant


InterventionEvaluation

- Code :int- FreeText :string- FutureDate :DateTime

MedicationAdministration ResultClinicalReference


e.g. a finding

Can be a Document Reference

SocialHistoryFamilyHistory PastSurgicalHistory PastMedicalHistory

If the HealthConcern is a problem, link to the same orders and medications as the Problem

HealthConcern set?

CDS rules?

GoalEvaluation

- Code :int- DateTime :DateTime- FreeText :string- MeasurementPeriod :Period- Modifier :ModifierType

Strategy

- Notes :string

InterventionRev iew

- ReviewDate :DateTime

Activ ity

Has task like attributes

Observation

Clinical Element part of encounter or cl inical information

Legend

GoalRev iew

0..*

0..*

0..*

+Patient

1

+RelatedInterventions

+WhenAchieved

1

0..*

0..*0..*

0..*

1

+ContainedCarePlans (Proposed)0..*

0..* 1

0..*

0..*

DeferredReason

1+RelatedGoals0..*

1..*

1..*

0..*

0..*

22 Title, version

Working on: Tagging Templates

7.9 Care Plan OperationsThe Care plan Domain model has generated a lot of discussions and revisions, and should be considered the most incom-plete of the PIMs. Operations will only be defined once the model is stable

Add/Update/Delete operations forCare Plan

Goals Interventions Health Concerns Outcomes Etc

Plus any necessary operations for associations and associated objects.

These operations are intended to allow for the adding, updating deleting of an individual Care Plan and pertinent information captured during a visit or encounter

Title, version 23

7.10 Care Plan Exchange Model

cmp Care Plan Exchange Components

«Contributing System»Ambulatory EHR

«In the cloud»Care Coordination Hub

«Contributing System»Acture EHR

«Contributing System»Post-Acuste EHR

«Contributing System»Other clinical system

«interface»CarePlanExchange

Serv ices

«In the cloud»Care Coordination

Application

«interface»Reconciliation Serv ices

«interface»CareTeamMembership

Serv ices

Connectivity for one EHRis shown here

«interface»CareTeamPermission

Serv ices

«interface»CareTeamCommunications

Serv ices



(Optional)

Required

(Dotted) Optional

Legend

(Optional)(Optional)

(Optional)

The following Activity Diagram shows of how the Care Plan exchange of information works. Please see Section A3 for a more detailed description

24 Title, version

act Care Plan Exchange

Contributing System A CareManager in the Cloud CareManagement Application Contributing System B

Start

Clinical and/or Care plan information is captured in the EHR (Acute, Post-Acute or

Ambulatory).

Information entered is marked as complete and ready to be shared

Information is compiled (e.g. CCDA doc)

Find the Patient Identfier

Patient Matching

MatchingCriteria :Patient

:Identifier

Share the compiled information

Receiv e the Information

Patient and Identity Management

Store the document

Extract the information

Technical Reconciliation

Clinical reconciliation

«Optional»Consolidate the Information (e.g. CCDA document w ith

Consolidated Care Plan)

Notification of update

Notification of update

Notify User

:Care Plan

User v iews the CarePlan (e.g. as a document)

«Optional»If discrete information is

av ailable. Incorporate the information

«Optional»Care Manager makes

changes to the Care Plan

Consolidate the Information (e.g. CCDA document w ith

Consolidated Care Plan)

Reconciliation is performed for every clinical item, e.g. medication and every care plan item, e.g. goals

Local and external items

Update, Add or Delete ClinicalItem

Local only, external only, similar, exact match

This step illustrated other actors updating the Care Plan

Title, version 25

7.11 Care Plan Exchange Operations

7.11.1 MatchPatientTBD

7.11.2 ShareCarePlanTBD

7.11.3 ConsolidatedCarePlanChangeNotificationTBD

7.11.4 RetrieveConsolidatedCarePlanTBD

26 Title, version

7.12 Reconciliation Domain Model

Please see section A.4 for more information on how Reconciliation will work.

The diagram below shows the output of the technical reconciliation which will be consumed by the clinical reconciliation (UI)

class Reconciliation

ReconciliationResult

- Errors :string[]

ReferenceInformationClinicalReference


Goal

SimilarObject

SimilarAttribute

- AttributeName :string- ExternalValueFormattedString :string- LocalValueFormattedString :string Attribute reference is

implicit via the Attribute Name

+Identical

0..*

+LocalUnique

0..*

+ExternalUnique

0..*

+Similar

0..*

+LocalObject

1

+ExternalObject

1

+SimilarAttributes

0..*

The following is an example of the structure of a reconciliation result

Reconciliation-Result | |-- Source Unique (Type List<Medication> | |-- External Unique (Type List<Medication> | |-- Identical (Type List<Medication> | |--Similar (Type List<SimilarObject> | … | First SimilarObject | |--Source object (Type Object<Medication> | |--External object (Type Object<Medication> | |-- Similar attributes (Type List<SimilarAttributes>

Title, version 27

| … | First SimilarAttribute | |--LocalValueFormattedString (string) | |-- ExternalValueFormattedString (string) | |--AttributeName (string) | |--Errors (Type List<Error>

7.13 Reconciliation Operations

7.13.1 ReconcileGoalsTBD

7.13.2 ReconcileInterventionsTBD

7.13.3 ReconcileHealthConcernsTBD

7.13.4 ReconcileOutcomesTBD

7.13.5 ReconcileProblemsTBD

7.13.6 ReconcileMedicationsTBD

7.13.7 ReconcileMedicationAllergiesTBD

28 Title, version

7.13.8 Other considerations

The Reconciliation UI (Clinical Reconciliation) allows the user to make decisions as to what changes to apply back to the local system, e.g. Add, Modify, Delete. It is important to understand that these should be the final decisions and input from the user, and that another reconciliation should not happen in the local system.

The Reconciliation UI should use the Care Plan Service operations to apply the user changes back into the database. If such a service is not available, e.g. if an EHR is using reconciliation but does not have the Care Plan Service operations implemented, it can use the following structure to communicate the changes back to the EHR.

Title, version 29

7.14 Coordination of Care Services Implementation Considerations

7.14.1 Security

Security is deferred to the Platform Specific Model. However, implementers should understand that, except where prohibited by other standards, all operations will be secured by Claims presented in a Token, and that the Token will contain a reference to the User’s or System’s Identity.

7.14.2 Sharing of information

Information can be shared at a document level or at the discrete level. For this version of the standard the sharing of information via a document is required. This is because almost all EHRs and other systems can produce and consume CCDA documents, largely because of efforts like Meaningful Use and standards bodies like HL7.

Sharing via discrete objects is allowed, but not required. We expect that HL7 Fast Healthcare Interoperability Resources (FHIR) will mature rapidly and be adopted, and therefore implementers may want to wait and support sharing of discrete objects via FHIR. We expect that the second version of this standard will contain a Platform Specific Model for FHIR. In the meantime we do supply a PSM for Web Services for sharing Care Plan and Clinical information via Web Services.

We expect the implementation matrix to be the followingDiscrete Object Sharing required

Care Coordination Hub RParticipating system that only shares information (no incorporation)

O

Participating system that incorporates information (pulls information back from the service)

R

Also, there is information that may not be described in a Care Plan structure. There are many reasons for this, not the least being that the system may not have implemented support for Care Planning, or that the provider has not documented such.However, this information is still valuable, and worth sharing. An example could be a medication list. A Care Team Participant can still derive value form a medication list that is shared, because it can help identify incompatible drug therapies.

7.14.3 Clinical Decision Support

This standard is not prescriptive wrt CDS systems, but we would expect the implementation to support CDS scenarios, for example Drug-Drug interactions, or for the Technical Reconciliation

30 Title, version

7.14.4 Identifiers

All items represented in this model that are shared (e.g. Clinical, CarePlan and Person) have a list of Identifiers. While the list needs to contain at least one identifier, it is strongly suggested that all known identifiers are stored and pro-vided when sharing information, so that update, de-duplication and reconciliation can take advantage of that.

The only reason is that this is not required is that we do not want to exclude information from systems that may not have support for multiple identifiers.

Title, version 31

7.14.4 Screen Sharing and Collaborative Review and Editing

In this version of the standard we do not require a native capability to edit the Care Plan. In future we do see that we may want to describe functionality, similar to Google Docs, which may allow multiple participants to edit the Care Plan simultaneously.For this release, the capability must be provided to share the Care Manager Application via some form of screen sharing technology such as Join.me, WebEx or GotoMeeting, or technologies used for Telemedicine of Video Conferencing

Business Associates Agreement would have to cover the security/privacy requirements of this kind of collaboration. Patient Consent will be required as well.

32 Title, version

8 Coordination of Care Services Platform Specific Model for Web Services

8.1 GeneralA PSM model for Web Services will be supported for all services, with the following exceptions:

AcceptInvitation We see this being implemented typically as a URL, not a SOAP service endpoint. In other words the Prospective Participant can click on a link to signal their response

RejectInvitation We see this being implemented typically as a URL, not a SOAP service endpoint. In other words the Prospective Participant can click on a link to signal their response

ForwardInvitation We see this being implemented typically as a URL, not a SOAP service endpoint. In other words the Prospective Participant can click on a link to signal their response

MatchPatient Not required if PIX is supported

ShareCarePlan (Document) Not Required if XDS.b is supported

8.2 PSM for Web Services Specific Conformance Criteria

8.2.1 Security

TLS

WS-Security

WS-Federation

8.3 Reference to WSDLWill be provided for a later submission once the PIM is stable

Title, version 33

9 Coordination of Care Services Platform Specific Model for CCDA

9.1 GeneralThis section describes how the Care Plan model described above maps into a CCDA document. Clients that use the AddCarePlanDocument operation need to make sure that this mapping is followed correctly.

Do we do a similar mapping for Care Team in CCDA

9.2 PSM for CCDA Specific Conformance Criteria

8.2.1 Identifiers

All items represented in this model that are shared (e.g. Clinical, CarePlan and Person) have a list of Identifiers. While the list needs to contain at least one identifier, it is strongly suggested that all known identifiers are stored and pro-vided when sharing information, so that update, de-duplication and reconciliation can take advantage of that.

8.2.2 Mapping of domain Models to CCDACare TeamCare Plan

Will be provided for a later submission once the PIM is stable. Changes to HL7 CCDA Care Plan may be suggested at the same time.

34 Title, version

10 Coordination of Care Services Platform Specific Model for FHIR

10.1 GeneralWill be provided for a later submission once the PIM is stable.

The goal with this standard is definitely to support FHIR, since we feel that this is a standard that is gaining a lot of traction in the Healthcare industry. However, FHIR, and especially the Care Team and Care Plan FHIR resources are immature. We will track FHIR closely and make a decision whether we will support FHIR for the first final submission later.

Because we see that FHIR is a REST-full implementation, we are not, at this point, planning to provide a specific REST implementation as part of this standard. We might change our opinion later, if FHIR adaption lags or if FHIR fails to meet it’s promises. But at this time developing another RESTful PSM does not make sense to the authors.

10.2 PSM for FHIR Specific Conformance CriteriaA FHIR conformance profile will be provided.

10.2.1 Security

We will use the base FHIR security (OAuth based)

10.3 Reference to ProfileThe plan is to develop a Coordination of Care Services profile for FHIR. This will support the Care Team Membership operations, as well as extensions to the core Care Plan.

Title, version 35

11 Coordination of Care Services Platform Specific Model for IHE

11.1 GeneralWill be provided for a later submission.

We are expecting the following IHE profiles to be used by this standardPIXXDS.bHPD

11.2 PSM for IHE Specific Conformance Criteria

11.2.1 Security

N/A

11.3 Reference to Profile

36 Title, version

12 Coordination of Care Services Platform Specific Model for Direct

12.1 GeneralWill be provided for a later submission.

We are expecting the following Direct profiles to be used by this standard

DirectMessaging

DirectText

12.2 PSM for Direct Specific Conformance Criteria

12.2.1 Security

N/A

12.3 Reference to Profile

Title, version 37

A: Non Normative Contents

A.1 Problem addressed by the specification

The World Health Organization (WHO) defines chronic diseases as “diseases that are of long duration and generally slow progression (http://www.who.int/topics/chronic diseases/en/)” and can have long-term effects. “Chronic” is usually applied to diseases lasting over 3 months (World Health Organization). Individuals of all ages are living longer with chronic illness and disability. The World Health Organization estimates 63% of all annual deaths (~36 million people) are attributable to non-communicable or chronic diseases. As the number and complexity of health conditions increase over time and episodes of acute illness are superimposed, the number of care providers contributing to individual care increases as well. With this complexity, it becomes significantly more difficult to align and coordinate care among diverse providers who frequently span multiple sites.

The numbers of health care service delivery encounters required by individuals, as well as the failure to deliver and coordinate needed services are significant sources of frustration and errors and are drivers of health care expenditures. According to claims data reported for US Medicare beneficiaries in 2003-2004, 19.6% of re-hospitalizations occurred 30 days after discharge. This translated into $17.4 billion dollars in hospital payments from Medicare in 20043. Providing person-centered care is particularly important for medically-complex and/or functionally impaired individuals given the complexity, range, and on-going and evolving nature of their health status and the services needed. Effective, collaborative partnerships between service providers and individuals are necessary to ensure that individuals have the ability to participate in planning their care and that their wants, needs, and preferences are respected in health care decision making.

The ability to target appropriate services and to coordinate care over time, across multiple clinicians and sites of service, with the engagement of the individual (i.e. longitudinal coordination of care) is essential to alleviating fragmented, duplicative and costly care for these medically complex and/or functionally impaired persons.

Efficient health information exchange to support coordination of care across multiple clinicians and care sites requires more than medication reconciliation and care summary exchanges. The availability and adoption of standards to support and inform care delivery independent of care setting is essential to alleviating fragmented, duplicative and costly care.

Without a process to reconcile potentially conflicting plans created by multiple providers, it is difficult, if not impossible to avoid unnecessary and potentially harmful interventions. Without such a process, it is also difficult to shift the perspective of providers from the management of currently active issues to consideration of future goals and expectations. Similarly, the challenge of establishing a consensus driven process across multiple disciplines and settings is confounded by a fragmented system of policies, technologies and services.

As information moves across settings in the longitudinal care space, care team members need more information than standard chart summaries typically provide. Care team members, including patients, benefit from sharing comprehensive patient data and information, including the care plan. In addition, the contributions of the care team to this information needs to be current for all stakeholders as it changes in order to avoid communication gaps and conflicting interventions.

There is growing recognition of the need for and benefits of fully interoperable Health Information Technology (HIT) capabilities across care provider groups. Of importance are the information or data needs of the medically complex and/or functionally impaired individuals. Effective, collaborative partnerships among service providers and individuals are necessary to ensure that individuals have the ability to participate in planning their care and that their wants, needs, and preferences are respected in health care decision making4.

38 Title, version

The identification and harmonization of standards for the longitudinal coordination of care will improve efficiencies and promote collaboration by:

• Improving provider’s workflow by enabling secure, single-point data entry for data related to care coordination

• Eliminating the large amount of time wasted in phone communication and the frustrations on the side of the receiving provider in not always obtaining care transition and care planning information in a timely manner

• Reducing paper and fax, and corresponding manual processes during care coordination

• Supporting the timely transition of relevant clinical information at each point of care transition and as the patient’s condition changes

• Enabling sending and receiving provider groups to initiate and/or recommend changes to patient interventions more promptly

A.2 Functional Capabilities of Coordination of Care Service

A.2.1 The following capabilities taken from the HL7 SFM are included within the Submission:

The “Coordination of Care” Service Functional Model (SFM) specifies discrete functions or capabilities required for the development of electronic systems which support coordination of care by a collaborating care team. The functional capabilities represent discrete steps in dynamic coordination of care interactions.

The capabilities are described in terms of business level pre-conditions, inputs, outputs, exception conditions and post-conditions. The inputs and outputs will have representations mainly as patient care information model classes but sometimes the specification will indicate service centric concepts such as acknowledgements of requests.

The capabilities are grouped into related groups as follows:

Care Team Membership Capabilities Care Team Communication Capabilities Care Team Availability/Scheduling Capabilities Care Plan Management Capabilities Plan Templates Plan Resource Support Capabilities Progress and Outcome Review Capabilities Observations and Supportive Content Capabilities

Care Team Membership Capabilities

Request Participation

This capability shall support participants to 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.

Title, version 39

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 any roles as defined in the HL7 Care Plan model like Patient, Patient Provider, Care Giver, Support Member

Inputs/

Request placer : Subject of Care : Request recipient :

Request text or information from request placer : Communication Class

Outputs Acknowledgement of receipt of request

Postconditions New collaborator receives a secure message with request for collaboration

Exception Conditions

Invitation has been recalled by placer Invitation has expired due to inaction

Included in Profiles Care Team Communication

Data Attributes Defined below

Attribute Name Data Type Description

receiver Role Specifies the receiver of the communication

source Role Specifies the source or sender of the communication

topic String Specifies the subject of the communication

content String Specifies the content of the communication

Response type String Specifies the type of response -

effectiveDate DateTime Specifies the date/time of the communication

Dateofexpiry Datetime Specifies the date/time of expiring the communication

40 Title, version

Respond to Participation Request

The “Respond to Collaboration Invitation” capability shall support 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

PreconditionsA 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

o (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 Acknowledge receipt by recepient

Post conditions Invited participant becomes a member of the care team with access to patient care context but filtered based on organizational role based access controls.


Invitation has been recalled by placer Invitation has expired due to inaction Invitation cannot be delegated




receiver Role Specifies the receiver of the communication


topic String Specifies the subject of the communication

Title, version 41

content String Specifies the content of the communication

Response type String Specifies the type of response -

effectiveDate DateTime Specifies the date/time of the communication

Dateofexpiry Datetime Specifies the date/time of expiring the communication

Add Care Team Member

The “Add Care Team Member” capability shall support 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.

The capability assumes the existence of an administrative role which has been granted access to plan and assign mem-bers of the care team. This capability can help streamline establishment of the care team when the patient is receiving care within a single institution and an initial group of individuals is identified during care planning.

Preconditions User performing this capability should have administrative privileges

Inputs

Primary Care Team Member, Patient, primary Physician Subject of Care : New care team member:

Request text or information with reason for addition to be sent to new care team member : Communication Class

Outputs Acknowledgement of addition of new care team member

Postconditions

New and existing care team members receive communication informing them of new membership and reason as indicated by administrative user.

New individual joins the patient’s care team and starts receiving change up-dates.

Exception Conditions none



Attribute Name Data Type DescriptionName String Specifies the

name of Care Team members

42 Title, version

AddressCityStateZip code

String Specifies the address, city, state and zipcode of Care Team members

Phone Number Specifies the phone number of the Care team member

effectiveDate DateTime Specifies the date/time of care team enrolment

Membership type

String Specifies the type of Membership – Personal, professional

Relationship String Specifies the relationship – Family member, Primary Care Providers, Care Coordinator

List My Care Teams

The “List my Care Teams” capability shall support the ability of an individual to list all care teams for which they have an active membership.

Preconditions Care team membership

Inputs Any care team member – eg - Patient, PCP, Care CoordinatorMembership type :

Outputs Zero or more persons who are Care team members

Data Attributes Refer below table

Attribute Name Data Type DescriptionName String Specifies the name of Care Team memberseffectiveDate DateTime Specifies the date/time of care team enrolmentMembership type String Specifies the type of Membership – Personal,

professionalRelationship String Specifies the relationship – Family member,

Primary Care Providers, Care Coordinator

Remove Care Team MemberThe “Remove Care Team Member” capability shall support the ability of an authorized user to either permanently remove or inactivate an individual from the care team. Care team members who are permanently removed no longer

Title, version 43

have access to the care plan. Care team members who are inactivated continue to have access but no longer receive full communication of updates (unless there is an explicit request to re-engage them).

Preconditions Performer should be a privileged user with rights to remove individuals from the patient’s care team.

InputsCare team member to remove : Removal type : Permanent or InactiveReason for removal :

OutputsAcknowledgement of care team member removalCommunication of removal is sent indicating details of removal including date, performing person, patient and reason.

Postconditions Individual stops being part of the care team. Individual loses access to patient’s care plan and associated coordination of care communications.


Include in the profiles Care Team Communication


Attribute Name Data Type DescriptionReason for removal String Specifies the reason for removal

Discover Care Team

The “Discover Care Team” capability shall support the ability of a user to determine who the other members of the care team are in order to engage them in communication, negotiation, harmonization and coordinated execution of the plan (via the other capabilities defined in this specification). This capability shall allow care team individuals to know about each other

Preconditions Care Team membership is established

Inputs Name (Care Team Member) Relationship Membership

Outputs List of Care Team members

Postconditions None




44 Title, version

Attribute Name Data Type DescriptionName String Specifies the name of Care Team memberseffectiveDate DateTime Specifies the date/time of care team enrolmentMembership type String Specifies the type of Membership – Personal,

professionalRelationship String Specifies the relationship – Family member,

Primary Care Providers, Care Coordinator

Care Team Communication

Care Team Negotiation

The Care Team capability shall support the ability to interact between two or more parties to reach an agreement.

This capability shall be supported in two ways

As free form “electronic secured message” communication resulting in care team individuals taking specific actions. The mode of communication during the negotiation process could be asynchronous or synchronous. As a structured content contribution to the care plan, which occurs when a care team member adds a health goal, a health concern or a care activity or intervention. Depending on the role and situation, the added goal, concern or intervention may be in a non-finalized proposed state. The proposal could be accepted, rejected or an alternative could be counter-proposed. The flow in this style of negotiation is one where the care team contributes to the same plan shared content; but the plan or its elements are not accepted (via a team acceptance review) until agreement has been reached

Preconditions

Un-finalized care plan aspects requiring proposals of changes or new issues/new clinical information becomes available necessitate change(s) to care plan

Disagreement on a course of action Detection of conditions which may lead to an un-harmonized plan and suboptimal

outcomes

Inputs

Initiating user : Any Care Team member Focus of negotiation : Plan, Health Goal, Health Concern or Care Activity Class (aka

Intervention) Free form expression via messaging/notes.

Outputs Plan, Health Goal, Health Concern or Care Activity Classes are annotated with Ob-

ject Tags capturing the negotiation mode of propose, accept, reject, counter pro-pose

Postconditions Participating care team members receive communication of negotiation response



Attribute Name Data Type Descriptionassociated Communication

Communication Specifies past associated communications pertaining to negotiation

effectiveDate DateTime Specifies the date/time of the communicationreceiver Role Specifies the receiver of the communication

Title, version 45


topic String Specifies the subject of the communicationnegotiation mode String Specifies the mode negotiation – Propose,

Accept, reject, counter propose

Care Plan Management Capabilities

Create Plan

Description

The “Create Plan” capability supports the ability of a care team member (which includes the patient) to establish a new plan for the patient; or for a patient to create a plan for herself without the need or involvement of other care team members. The capability may not always result in the creation of a complete plan but may simply create the shell of a plan to which one or more care team members in coordinated effort with the patient will contribute information about health goals, heath concerns, health risks, care barriers and plan activities or interventions. The completeness is a mat-ter of perspective and is something that is continuously evolving with future findings so it is expected that whether the created plan is “complete” or a shell it will still undergo changes through contributions from the various care team members.

Preconditions User must be the patient or some other validated member of the patient’s care team.

Inputs

Plan : Plan ClassRequire either health concerns or health goals: Zero or more health goals : Health Goal Class Zero or more health concerns : Health Concern Class Zero or more health risks : Health Risk Class Zero or more care barriers : Care Barrier Class Zero or more planned interventions : Care Activity Class

At least one health goal or one health concern is required.

Outputs Acknowledgement of creation of plan Notification to care team about existence of new plan

Postconditions Plan is created and synchronized with patient’s care team

Exception Conditions Unauthorized if individual not a member of the care team Duplicate or existing plan already in place which could lead to diverging and un-rec-

onciled care.


Care Plan ID String or Code Specifies the care plan ID

Care Plan Display Name

String Specifies the care plan display name

46 Title, version

Care Plan Type String or Code Specifies the care plan type.

Care Plan Template ID

String(s) or Code(s) Specifies the care plan templates contained in the care plan

Health Concern(s)

String or Code Specifies health concern(s) within the care plan

Health Problem(s)

String or Code Specifies health problem(s) within the care plan

Health Goal String or Code Specifies health goal(s) within the care plan

Planned Interventions

String or Code Specifies planned intervention(s) within the care plan

Care Barrier String or Code Specifies care barrier(s) within the care plan

Care Activity String or Code Specifies care activity performed according to care plan

Creation Date Date/Time Specifies date and time the care plan or care plan item is created

Creator Role Specifies the creator the care plan.

Security String or Code Specifies the security level of the care plan or care plan items.

Confidentiality String or Code Specifies the confidentiality level of the care plan or care plan items.

Description String or Code Provides a description of the care plan or care plan items

Status String Specifies the status of the care plan or care plan items.

Priority String Specifies the priority of care plan items

Outcome String Specifies the outcome of the care plan or care plan items

Change Plan

Description

Title, version 47

The “Change Plan” capability supports the ability of care team members (which includes the patient) to make changes to an existing plan. The changes may include modification to intrinsic plan attributes such as confidentiality, description, display name and discipline or changes (including addition) of related plan elements such as health concerns, health goals, health risks, care barriers and plan activity or interventions. A change could represent the removal of plan elements either because they are no longer pertinent or because they were added due to some error. Changes to the plan may also include status changes such as placing the plan on hold or suspending the plan for a period of time.

Preconditions User must be the patient or some other member of the patient’s care team

Inputs

Plan : Plan Class capturing the changed intrinsic attributes

Addition or removal of any of the following: One or more health goals : Health Goal Class One or more health concerns : Health Concern Class Zero or more health risks : Health Risk Class Zero or more care barriers : Care Barrier Class Zero or more planned interventions : Care Activity Class

Changes to intrinsic properties of health concerns, health goals, health risks, care barriers and care activity

Outputs Acknowledgement of successful modification of plan Notification to care team about changes to the plan Synchronization of the plan change updates to shared copies of the plan

Postconditions Plan is updated and care team is aware of change updates


Notes This capability will expand into multiple technical specification operations to support making changes to different component parts of the plan.






Care Plan Template ID

String(s) or Code(s) Specifies the care plan templates contained in the care plan

Health Concern(s) String or Code Specifies health concern(s) within the care plan

Health Problem(s) String or Code Specifies health problem(s) within the care plan

48 Title, version

Health Goal String or Code Specifies health goal(s) within the care plan

Planned Interventions

String or Code Specifies planned intervention(s) within the care plan

Care Barrier String or Code Specifies care barrier(s) within the care plan

Care Activity String or Code Specifies care activity performed according to care plan

Action Add, Edit, Inactivate, Delete, Close Specifies the action taken on a care plan or care plan item.

Created Date Date/Time Specifies date and time the care plan or care plan item is created


Updated Date Date/Time Specifies date and time the care plan or care plan item is updated

Updated By User Role Specifies the user who update the care plan or care plan item

Security String or Code Specifies the security level of the care plan or care plan items.

Confidentiality String or Code Specifies the confidentiality level of the care plan or care plan items.



Priority String Specifies the priority of care plan items

Outcome String or Code Specifies the outcome of the care plan or care plan items

Monitor Plan

The “Monitor Change” capability supports the ability of users to indicate their desire to be alerted regarding specific changes to the care plan content such as health concerns, health goals, health risks, care barriers, care preferences and care activities or interventions. As specified by the “Plan Synchronization” capability, the care plan content is already expected to be synchronized across all shared instances. The key distinction of the “Monitor Change” capability and

Title, version 49

basic synchronization is that synchronization is a passive behavior of the system; whereas “Monitor Change” supports intentional and proactive care team behavior.

Preconditions Existing plan is in place and the care team which includes the patient has agreed to it.

Inputs

One or more care team members (including patient) interested in monitoring : Person Class Tagged plan elements or health events with indication for monitoring Monitor criteria : Criterion Class

o These are rules that define what to monitor

Outputs A communication is sent to the user with links to the relevant plan elements : Communication Class

Postconditions Users receive communication with links to plan element and criteria used as the trigger



Care Plan Item Name


Care Plan Items Type

String or Code Specifies the care plan type.

Care Plan Item tags

String(s) or Code(s) Specifies the tags associated with care plan items. (Care team can monitor tags)

Action Add, Edit, Inactivate, Delete, Close Specifies the action taken on a care plan or care plan item.



Updated Date Date/Time Specifies date and time the care plan or care plan item is updated

Updated By User

Role Specifies the user who update the care plan or care plan item

Monitoring Requestor

Role Specifies the user who requests monitoring

50 Title, version




Find Plan

The “Find Plan” capability supports the ability of care team members to discover existing plans for a patient in order to make the plan accessible for reading, reviewing and changing. The resulting plans may be either active or archived. Ide-ally there is one active plan for a patient as the capabilities do not support coordination of care based on multiple un-reconciled plans.

Preconditions Individual must either be a patient or another member of the care team in order to look up a plan.

Inputs User : Person Class User role : Role Class Subject of Care : PersonAsPatient Class

Outputs

Plan : Plan Classo The plan class has associations to health concerns, health goals, health

risks, car barriers, patient preferences, care activities, etc.o These associated elements are available to the individuals requiring ac-

cess to the plan.

Postconditions Plan becomes accessible to care team member


Unauthorized if individual not a member of the care team








Title, version 51



Requestor Role Specifies user who is requesting the list of current care plans

Synchronize Plan

The “Plan Synchronization” capability supports system level data synchronization of changes to the care plan for all care team participants who have accessed an earlier version of the plan and who may make mistakes unless they are aware of changes to the plan. The capability supports users by providing an up to date view and awareness of changes to the plan by other care team members. Synchronization of change updates to the coordinating care team raises awareness of potential changes resulting from new findings.

Preconditions Multiple care team members with access to the plan which becomes out of date when modified by another care team member possibly in a different setting and organization.

Inputs Change updates: Requires a system level synchronization protocol to be determined at the technical specification level.

Outputs Production of change update summary with special emphasis in tracking changes with temporal significance.

Postconditions Out of date versions of the plan held by coordinating care team members are updated

Exception Conditions System level unavailability exceptions which may require re-attempting the synchronization process.



Synchronization Date

DateTime Specifies the synchronization date and time

Synchronization ID

String Specifies a specific synchronization transaction

Version ID String Specifies the master document version resulting from the synchronization

Close Plan

The “Close Plan” capability supports the ability of users to indicate a plan is no longer used.

Preconditions An active or current plan

52 Title, version

InputsUser : Person ClassUser role : Role ClassSubject of Care : PersonAsPatient Class

Outputs The status of the plan is set to “closed”

Postconditions The plan is no longer available for use and modification by the care team. The plan will be available as a result in the find plan capability when if the query indi-

cates retrieval of historical plans.




Reason for Closure

String Specifies the reason for closure: Duplicate, resolution, death, etc.

Tag PlanIn the world of paper care plans, one could take a red pen and make “markings” to identity items of interest for planning and discussion. As an example, these markings may indicate to follow up, to correct, to consolidate or reconcile various plan sections or items. The “Tag Plan Items” capability supports the ability of users to make such markings by tagging any object within the plan with a label (which could be a predefined or coded label). The markings could be either system defined or user defined.Markings with the same label or code form groupings of related content for organizational purposes or to highlight them for future action by the care team.

Care team members may tag conflicting goals that need to be discussed Care team members may tag two plans to merge Care team members may tag plan items requiring review or follow-up.

Preconditions User is a member of the care team

Inputs

User : Person Class User role : Role Class Tag : ObjectTag Class

o Captures label or codeo Timepoint or time period for which the tag is relevanto A reference to one or more target objects from the plan to which the tag is

applied

Outputs Acknowledgement confirming tagging was successful

Postconditions Application of tags is synchronized to plans held by other care team members


NotesThe reverse capability to untag or to remove a tag should also be supported by the specification.This should be optional.

Title, version 53


Tag Class String or Code Specifies Tag Class

Effective Date DateTime Specifies the date the tag is effective

Expiration Date:

DateTime Specifies the expiration date for the tag

Tag Status String Code Indicates whether or not the tag is active or inactive

Tagging User Role User who tags the care plan line item

Lookup Tagged ItemsThe “Lookup Tagged Items” capability supports users in identifying plan items tagged with a given label. Tag with the same label or code form groupings of related content for organizational purposes or to highlight them for future action by the care team.

List items tagged for reconciliation List post discharge items tagged for follow up List conflicting items tagged by clinical decision support agent

Preconditions User is a member of the are team

Inputs

User : Person ClassUser Role : Role ClassSubject of Care : PersonAsPatient Class Tag : ObjectTag Class to be used as prototype for query

May indicate applicability time period (as tag may no longer be “active”)

Outputs Information used by computer system to locate and present tagged plan objects to user

Postconditions User is given access to tagged item(s)

Exception Conditions User does not have authorization to view tagged item(s)


Tag Class String or Code Specifies Tag Class

Effective Date DateTime Specifies the date the tag is effective

Expiration Date:

DateTime Specifies the expiration date for the tag

Tag Status String or Code Indicates whether or not the tag is active or inactive

Subject String or Code Specifies subject or criteria of lookup

54 Title, version

Requestor Role User who requests tagged items

Define Plan TemplateThe “Define Plan Template” capability supports the ability of users to create or update condition specific re-usable plan “fragments”.This capability is similar to creating or changing a plan, except that the plan does not specify a patient or any other member of the care team.

Preconditions User has administrative privileges to publish a plan template or a plan template update

Inputs

User : Person ClassUser role : Role ClassA plan : Plan Class

A fragment plan containing health concerns, health goals, health risks and activities/interventions.

Outputs Acknowledgement of creation or update of plan template

Postconditions Plan fragment representation is stored for retrieval via “Find Plan Template”

Notes The technical specification needs to consider how to represent relative times and timeframes.


Template Name String or Code Specifies Template Name

Template ID String or Code Specifies Template ID

Template Class DateTime Specifies the template class

Fragment Class String or Code Specifies fragment class i.e.

Creator Role User who created template

Find Plan TemplateThe “Find Plan Template” capability supports the ability of users to locate a predefined “standardized” plan fragment to address a subset of health concerns, health goals and health risks. Users are expected to personalize and tailor the “plan” based on the patient’s needs and preferences.Plan templates are not associated with individual patients but instead capture re-usable plan elements targeting classes of patients sharing health concerns, health risks and health goals. A provider looks up a plan template based on guidelines for treating patients with diabetes mellitus and subsequently customizes and personalizes a plan for her patient.

Inputs One or more health concerns : Health Concern Class

Title, version 55

One or more health goals : Health Goal Class One or more health risks : Health Risk Class

OutputsA Plan : Plan Class

Same plan class used for a patient but with no associations to a patient or other care team members.


Template Name String or Code Specifies Template Name

Template ID String or Code Specifies Template ID

Template Class DateTime Specifies the template class

Fragment Class String or Code Specifies fragment class i.e.

Creator Role User who created template

Progress and Outcome Review Capabilities – ReviewThese capabilities enable users to evaluate of whether the plan is progressing as expected based on review of goals and outcomes. Ability to validate interventions through activity data. May also include delivery/fulfilment of an order (i.e. medication, transition of care). May be result of assessment.

PreconditionsRequires read-only access to plan that includes goals and outcomes plus observation data

Inputs Plan : Plan Class uniquely identifying the patient and plan period Intervention: Intervention Class Outcome: Outcome Class

Outputs Progress towards goal observation: Mood EVN

Postconditions

Include in the profiles


Attribute Name Data Type DescriptionPlan Int Care PlanHealth Concern Varchar Concern or riskGoal Varchar Refers to health concernIntervention Varchar Has reason to goalOutcome Varchar {Met, Not Met}Progress Varchar {No Progress, Regression, Progress made,

56 Title, version

Achieved/Met, N/A}

Progress and Outcome Review Capabilities – Acceptance ReviewThese capabilities enable users to accept the evaluation of whether the plan is progressing as expected based on review of goals and outcomes

Preconditions Requires read-only access to plan that includes goals and outcomes plus observation data plus permission to accept

InputsPlan : Plan Class uniquely identifying the patient and plan periodIntervention: Intervention ClassOutcome: Outcome Class

Outputs Progress towards goal observation: Mood EVN

Postconditions Progress and outcome is accepted or rejected


Data Attributes

Attribute Name Data Type DescriptionPlan Int Care PlanHealth Concern Varchar Concern or riskGoal Varchar Refers to health concernIntervention Varchar Has reason to goalOutcome Varchar {Met, Not Met}Progress Varchar {No Progress, Regression, Progress made,

Achieved/Met, N/A}Accepted Bit {True = Accept, False = Reject}User ID Id Unique identifier for accepting/rejecting team

memberComments Varchar Comments to support accept/reject of

progressTimestamp datetime Time of accept/reject

Make Observation

Capabilities enable users to capture observations specifically related to care coordination. Observations documented elsewhere in the EHR may be associated with care coordination data point(s) on activities against goals or interventions. Determine observations based on a visit or assessment should be attached to care plan (goals, interventions).

Preconditions Requires access to post observation against goals and outcomes

Inputs Plan : Plan Class uniquely identifying the patient and plan period Health Concern: Health Concern Class Goal: Goal Class

Outputs Acknowledgement

Title, version 57

Postconditions Observation data point on progress and outcome is posted


Data Attributes

Attribute Name Data Type DescriptionPlan Int Care PlanHealth Concern Varchar Concern or riskGoal Varchar Refers to health concernObservation Type varchar Category of observationObservation Value varchar Data value of observationObserver Int Identifier of team member making

observationObservation TimeStamp Datetime Date/Time of observationObservation Comments varchar Comments to support observation

Query Observationcapabilities enable users to retrieve data point(s) on goals or interventions at a given point in time

Preconditions Requires read-only access to view observations

Inputs Plan : Plan Class uniquely identifying the patient and plan period Health Concern: Health Concern Class Goal: Goal Class Observation (qualitative, quantitative, free-form text)

Outputs Observation class

Postconditions Observation data point(s) returned


Data Attributes

Attribute Name Data Type DescriptionPlan Int Care PlanHealth Concern Varchar Concern or riskGoal Varchar Refers to health concernObservation Type varchar Category of observationObservation Value varchar Data value of observationObserver Int Identifier of team member making

observationObservation TimeStamp Datetime Date/Time of observationObservation Comments varchar Comments to support observation

Associate Supportive Contentcapabilities enable users associate supportive content with goals or interventions within a plan period

58 Title, version

Preconditions Requires access to post supportive content to plan period

Inputs

Plan : Plan Class uniquely identifying the patient and plan period One or more health concerns : Health Concern Class One or more goals : Goal Class Zero or more interventions : Intervention Class Supportive Content (text, image, file, metadata): Supportive Content Class

Outputs Confirmation that Supportive Content has been associated with Plan and Goal/In-

tervention

Postconditions Supportive Content has been associated with Plan and Goal/Intervention


Data Attributes

Remove Supportive ContentThese capabilities enable users remove associated supportive content from a plan period. Remove should be a soft delete, rather than actual delete.

Preconditions Requires access to remove supportive content from plan period

Inputs

Plan : Plan Class uniquely identifying the patient and plan period Supportive Content Identifier: Supportive Content Class Comment Field (remove reason, comment)

Outputs Confirmation that Supportive Content has been removed/unlinked from Care Plan

Postconditions Supportive Content has been removed from Plan


Data Attributes

A.3 How sharing of Care Plans to Coordinate Care will be achieved, and how the Care Plan can be considered Dynamic

DescriptionThis is a big, high level use case (EPIC) that combines a number of individual's actions, but serves in explaining how Dy-namic Coordinated Care Planning works

Assumptions1. EHR has a Care plan module2. The User's Organization has been registered with the Care Coordination Hub3. A Care Team has been created for the patient, with the current user's system participating

Title, version 59

4. Patient has been registered with eMPI

Work Flow

1. Clinical and/or Care plan information is captured in the EHR (Acute, Post-Acute or Ambulatory)a. User enters clinical information associated with a Visit or Encounterb. [Optional] User enters or updates Care Plan

a. Assessmentb. Health concernsc. Problems (could interchange with Health concerns)d. Goalse. Interventionsf. Evaluationg. Outcomea. Please note: We expect every EHR to be able to capture a Care Plan, but not every en-

counter or Visit may modify the Care Planc. Information entered is marked as complete

a. Acute?b. Ambulatory: Provider signs the notec. Please note: The decision is up to the EHR

2. The EHR shares the information with the Care Coordination Huba. A CCDA document is generated

a. Preferably automatedb. An appropriate CCDA template is used that contains all clinical and Care plan information

that was captured during the Visit / Encounterc. Care Plan information is pulled from the appropriate place in the EHR database (i.e. the

table or tables that the Care plan module writes and reads from)b. PIX is used to identify the patientc. XDS.b is used to upload the CCDA document to Care Coordination Hub

60 Title, version

3. Care Coordination Hub receives the CCDA documenta. The correct patient is identified or added using the PIX workflowb. Care Coordination Hub adds the information in the CCDA to it's CDR

a. Both discrete and documentc. Collected information includes, at least

a. PAMIb. Other Clinical Informationc. Care Plan

d. Information can be discrete or a CCDA document or section or Human Readablee. Reconciliation (Technical and Clinical)f. Care Coordination Hub produces a new "Consolidated" CCDA document that contains all current

information as well as the new informationa. Note: Where data is not codified, such as for Care Plan, we can use references to the orig-

inal CCDA document sectionsg. Care Coordination Hub keeps track of which Care Plans have changed

4. Steps 1-4 are repeated for all the EHRs and other data sources as they are shared5. Notification of Changes to the Care Plan

a. This can be via a pollb. Can be via a push

a. e.g. email to a non-EHR user6. EHR receives the notification

a. EHR notifies the Care Team user(s) of changes to the Care Planb. EHR retrieves the new " Consolidated " CCDA document(s)

7. On demand, the new Care Plan is displayed to the user8. User can import the CCDA document into the record

Notes:1. The workflow describes exchange of information via CCDA, as documents. In future, the option is to

allow for sharing of information discretely via FHIR2. Workflow stays substantially the same, sharing is just discrete

The following are illustrations of how the Combined Care Plan could be communicatedOption 1 - grouped by Care Team member

Title, version 61

62 Title, version

Option 2 - grouped by section (goal, intervention, etc)

Title, version 63

A.4 Approach for Reconciliation

There are two portions to the reconciliation process. The first is the Reconciliation Matching Logic – this can be considered the technical reconciliation. This process takes two input lists, the local and and external items, and produces 5 lists,

Local Unique

External Unique

Identical

Source Similar

External Similar

These 5 lists are then fed into a User Interface to allow a user to make decisions about what to import or modify in the local system. These decisions typically lead to the following outcomes

An item is added to the local system

An item in the local system is modified

An item in the local system is discontinued or marked inactive (“deleted”)

64 Title, version

The user outcomes are applied to the system using the Care Plan operations, e.g. AddMedicationAllergy(), UpdateGoal()

The following is an example of the User Interface, based on the TwinList model (reference: )

Quality of the reconciliationThe infrastructure above allows for the reconciliation to be done well, but does not guarantee it.

Technical reconciliation is very dependent on how the data is codified and how it adheres to standards. This is too large a problem to be solved by this specification, but the reconciliation logic should take advantage of medical terminologies, vocabularies and semantics to make decisions on whether two items or concepts are similar.

In the worst case, where the technical reconciliation can make no determination of similarity, only the local unique and external unique lists will be populated.

For the clinical reconciliation using the user interface, similar logic applies. Even in the case where there is a lot of information about similar items, a user can decide not to add the items or to add them all as new items.

Title, version 65

In the case where the technical reconciliation does not find any or many similar items, the burden falls onto the clinician. The clinician can use their interpretation of the textual information to make decisions.

It is possible for the technical reconciliation to do string and substring matching to determine whether something should go into the similar lists. This standard is not prescriptive on whether this should be done or not, it is up to the implementers.

IdentitiesEvery clinical item needs to have a list of identities.

When items are merged or added, the external identities need to be added to the identity list.

When the local lists are produced for technical reconciliation, then all known identities need to be provided

66 Title, version

Annex B: Title

(normative)

B.1 Sample IDL

#pragma prefix “http_//example.com"

module stockquote_wsdl {interface StockQuotePortType { typedef sequence<float> ArrayOfFloat;

typedef struct TimePeriod {wstring startTime;wstring endTime;

};ArrayOfFloat GetTradePrices(

in wstring tickerSymbol,in TimePeriod timePeriod,out float frequency);

};};

B.2 Sample Code

<?xml version="1.0"?>

<definitions name="StockQuote" targetNamespace="http://example.com/stockquote.wsdl"

xmlns:tns="http://example.com/stockquote.wsdl"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:xsd1="http://example.com/stockquote/schema"xmlns="http://schemas.xmlsoap.org/wsdl/">

<types><schema targetNamespace="http://example.com/stockquote/schema"

xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"xmlns="http://www.w3.org/2001/XMLSchema"><complexType name="TimePeriod">

<all><element name="startTime" type="xsd:string"/><element name="endTime" type="xsd:string"/>

</all></complexType><complexType name="ArrayOfFloat">

<complexContent><restriction base="soapenc:Array">

Title, version 67