190 likes | 332 Views
Longitudinal Coordination of Care (LCC) Workgroup (WG). HL7 Tiger Team Service Oriented Architecture (SOA) Care Coordination Services (CCS) April 10, 2013. Meeting Etiquette. Remember: If you are not speaking, please keep your phone on mute
E N D
Longitudinal Coordination of Care (LCC) Workgroup (WG) HL7 Tiger Team Service Oriented Architecture (SOA) Care Coordination Services (CCS) April 10, 2013
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 • Hold = Elevator Music = frustrated speakers and participants • This meeting is being recorded • 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. • 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
Goals • 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
Ballot Artifacts • 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 Document Overview • 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
HSSP Objectives • 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
HL7 Responsibilities • 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
SFM Context • 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.
HL7 Process Context • 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.
Plan Capability Set • 4.1.1 Plan Capability Set
Template Definition • 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.
Care Team Conversation Thread • 4.1.6 Care Team Conversation Thread Capability Set • The 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)
Data Associations • 6.3.1 Data – Special vs. Simple Associations • While 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.
Functional Roles • 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
Assignments for Offline Review • 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
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
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 Gallegoevelyn.gallego@siframework.org • Sub Work Group Lead • Russ Leftwichcmiotn@gmail.com • Program Management • Lynette Elliott lynette.elliott@esacinc.com • Becky Angeles becky.angeles@esacinc.com