Longitudinal Coordination of Care (LCC) Workgroup (WG)HL7 Tiger Team Service Oriented Architecture (SOA) Care Coordination Services (CCS)

April 10, 2013

1

Meeting Etiquette

• Remember: If you are not speaking, please keep your phone on mute

• Do not put your phone on hold. If you need to take a call, hang up and dial in again when finished with your other call o Hold = Elevator Music = frustrated speakers and

participants• This meeting is being recorded

o Another reason to keep your phone on mute when not speaking

• Use the “Chat” feature for questions, comments and items you would like the moderator or other participants to know.o Send comments to All Participants so they can

be addressed publically in the chat, or discussed in the meeting (as appropriate).

From S&I Framework to Participants:Hi everyone: remember to keep your phone on mute

All Participants

Agenda

• Introductions

• Goals

• Schedule

• Overview of HL7 Service Oriented Architecture Care Coordination Service (CSS) ballot document

– Assignment of sections for Tiger Team review and comments

– Reminder to sign up for the SOA CCS Ballot Pool (deadline Monday April 22):

• http://www.hl7.org/documentcenter/public/ballots/2013MAY/announcements/Announcement%20of%20Ballot%20Openings%20for%20May%202013%20Ballot%20Cycle.pdf

• Next Steps

3

4

• For this initiative:• Interoperable and shared patient assessments across

multiple disciplines

• Shared patient and team goals and desired outcomes

• Care plans which align, support and inform care delivery regardless of setting or service provider

• For this Tiger Team:• Alignment of HL7 artifacts with LCC artifacts to

support care plan exchange

• HL7 CCS provides Service Oriented Architecture

• Care Plan DAM provides informational structure

• LCC Implementation Guides provide functional requirements

Goals

Schedule – April 2013SUNDAY MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY SATURDAY

1 2 3 4 5 6

7 8 9 10 11 12 13

11 AM ET: HL7 Care Coordination Services Overview

to LCC

14 15 16 17 18 19 20

11 AM ET: LCC Tiger Team

Meeting for CCS Ballot

Preliminary CCS Ballot

Comments Due

21 22 23 24 25 26 27

11 AM ET: Final LCC CCS Ballot

Review Meeting

Final CCS Ballot

Comments Due

28 29 30

LCC CCS Ballot

Comments Due to HL7

6

• http://www.hl7.org/ctl.cfm?action=ballots.loginchoice

• V3_SOA_CSS_R1_O1_2013MAY.pdf• CCS_Ballot_HL7 Care Plan Model Overview

Supplement.pdf

Ballot Artifacts

7

• HSSP Objectives (page 5)• HL7 Responsibilities (page 5)• SFM Context (page 5)

• HL7 Process Context (page 6)

• Plan Capability Set (page 28)

• Template Definition (page 29)

• Care Team Conversation Thread Capability Set (page 50)

• Data Associations (page 74)

• Appendix F: “Functional” Roles (page 91)

• Assignments for Offline Review

Ballot Document Overview

8

• HSSP Objectives

• To stimulate the adoption and use of standardized “plug-and-play” services by healthcare software product vendors

• To facilitate the development of a set of implementable interface standards supporting agreed upon services specifications to form the basis for provider purchasing and procurement decisions.

• To complement and not conflict with existing HL7 work products and activities, leveraging content and lessons learned from elsewhere within the organization.

Reference 1.1 HL7-OMG Healthcare Services Specification Project (HSSP) page 5

HSSP Objectives

9

• Within the process, HL7 has the primary responsibility for:

• Identifying and prioritizing services as candidates for standardization

• Specifying the functional requirements and conformance criteria for these services in the form of Service Functional Model (SFM) specifications

• Adopting these SFMs as balloted HL7 standards

• It is important to note that the HL7 SFMs will focus on specifying the functional requirements of a service, while OMG specifications will focus on specifying the technical interface requirements of a service.

Reference 1.1 HL7-OMG Healthcare Services Specification Project (HSSP) page 5

HL7 Responsibilities

10

• 1.2 Context of this SFM within HSSP Process• As described above, the purpose of an HL7 SFM is to identify

and document the functional requirements of services important to healthcare. Accordingly, this SFM seeks to define the functional requirements of a care coordination service (CCS).

• The Care Coordination Service specifies a service interface to support care management professionals who manage patient care by creating and applying “Treatment Plans” and “Plans of Care.” Additionally, the CCS enables its users to organize these plans into a non-duplicative “care plan” structure with unified collaboratively defined goals, and then to collaboratively manage that structure going forward.

• Once adopted as an HL7 standard, it is anticipated that this SFM will serve as the basis for one or more OMG technical specifications for care coordination services.

SFM Context

11

• 1.2.1.1 HL7 Process Context• Prior to defining the detailed capabilities, the CSS project team assisted the

CP DAM project in order to help develop the information model that is at the heart of the CCS. This CCS SFM has been defined with that model constantly in view. This CCS SFM is under present ballot “for comments” in the May 2013 HL7 ballot cycle.

• Even though the CP DAM is now stable, it will not be submitted for ballot until the September cycle; but in that cycle, the following three related artifacts are to be concurrently balloted:

• The Care Coordination Service SFM, for Draft Standard for Trial Use (DSTU)

• The Care Plan Domain Analysis Model (CP DAM), for DSTU

• The Care Plan CDA Implementation Guide for DSTU

• The CP DAM in-process is included as an addendum to this CCS SFM. The CCS project team therefore hopes to receive ballot comments that are instructive to the CP DAM work as well. Such feedback will benefit all three of these closely related September submissions.

HL7 Process Context

12

• 4.1.1 Plan Capability Set

Plan Capability Set

13

• 4.1.1.2 Find Plan Template

• Definition: A plan template consists of predefined plan

elements which are commonly included when addressing

a combination of patient health concerns, health risks and

health goals. The plan templates could be based on

research, clinical evidence or best practices. For example,

there could be a plan template to treat patients with

diabetes mellitus and cardiovascular disease which could

serve as a starter base care plan for such patients.

Template Definition

14

• 4.1.6 Care Team Conversation Thread Capability SetThe CCS conversation model works as follows:

• Captures the free form text, natural language, content of business interactions

• May capture structured observations resulting from question/answer electronic form interactions.

• Discussions may links to the semantic structured context pertaining to the conversation (structured “clinical statements”)

• A conversation may simply consist of free text such as a question from a patient to his or her provider. A conversation may also pertain to some aspect of the care plan such as: a communication about a specific health goal, health concern, health risk, intervention outcome, associated plan and goal reviews or some diagnostic observation about the patient. The semantic links put the conversation in context.

• Conversations will naturally form threads containing multiple communications about some topic.

• Care team communications may also have optional multimedia support (attached photograph of video clip)

Care Team Conversation Thread

15

• 6.3.1 Data – Special vs. Simple AssociationsWhile some organizations link the common plan items (e.g. HealthConcern,

Goal, PlannedAction, Barrier) directly to plans alone, others link these items in more elaborate paths - for example

• Concern to Goal

• Goal to Planned Action

• Goal to Barrier

Seeking the greatest common factor, the CP DAM supports the tying the common items directly to plans, and supports the special associations as well. If a CCS implementation converts these special links to direct links as plans are being written into a CCS server, but then cannot serve up the indirect versions to a read request at a later time, then some data precision is lost. There is no loss in accuracy, just in precision.

In practice, this problem is somewhat mitigated if the Case Manager that is consolidating plans can manually restore some of the special connections to their correct locations. If the user interface permits drag/drop for specifying associations, then such corrections are easy to perform.

Data Associations

16

• Appendix F: Representative “Functional” Roles in Care Management

• The following is “one way” to functionally organize the roles of care team members. This set is merely informative, not normative:

• Convenor

• Facilitator

• Assessor

• Member

• Patient

• Participant

• Enabler

Functional Roles

17

• Governance• Pages 6-14: section 1.2.11 through 2.3.1• Pages 44-54: section 4.1.4.2 through 4.1.7.2

• Scenarios and Functions• Pages 29-39: section 4.1.1.1 through 4.1.2.2• Pages 61-71: Clinical Appropriateness Capability

section through 4.1.15.2

Assignments for Offline Review

Proposed Next Steps

• Offline review of Ballot Artifacts (Governance and/or Scenarios and Functions)

• Sign up for Ballot Pool – Deadline Monday April 22

– Ballot voting close date Monday April 29

• Generate Ballot Comments in the next 2 weeks• Finalize LCC’s Ballot Comments by Friday April 26th• Submit Ballot Comments to HL7 by Monday, April 29th

19

Contact Information

We’re here to help. Please contact us if you have questions, comments, or would like to join other projects.

• S&I Initiative Coordinator• Evelyn Gallego evelyn.gallego@siframework.org

• Sub Work Group Lead• Russ Leftwich cmiotn@gmail.com

• Program Management• Lynette Elliott lynette.elliott@esacinc.com• Becky Angeles becky.angeles@esacinc.com