1. Longitudinal Coordination of Care (LCC) Workgroup (WG) HL7 Tiger Team Patient Care WG Care Plan DAM July 10, 2013 1

2. 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

3. 3 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

4. Agenda Introductions Goals Schedule Discussion of Prioritizations –Ongoing comments can be submitted and viewed on wiki: http://wiki.siframework.org/LCC+HL7+Tiger+Team+SWG Next Steps 4

5. Schedule – July 2013 SUNDAYMONDAYTUESDAYWEDNESDAYTHURSDAYFRIDAYSATURDAY 123456 11 AM ET Discussion Plan Activity Data Element Attributes 78910111213 11 AM ET Discussion Team Member Relationship to Patient 14151617181920 11 AM ET Discussion TBD 21222324252627 11 AM ET Discussion TBD 28293031 11 AM ET Discussion TBD

6. Work Group Schedules LCC WG SWG MeetingLCC LeadsDate/ TimeProjects LTPAC SWGLarry Garber Terry O'Malley Weekly Mondays, 11-12pm EST C-CDA: Transfer Summary, Consult Note, Referral Note LCC HL7 Tiger Team Russ LeftwichWeekly Wednesdays, 11- 12pm EST LCC WG comments for HL7 Care Plan DAM LCP SWGBill Russell Sue Mitchell Jennie Harvell Weekly Thursdays 5-6pm EST C-CDA: Care Plan, HomeHealth Plan of Care HL7 WG SWG MeetingHL7 LeadParticipating LCC Members Date/ TimeProjects HL7 Patient Care WGRuss Leftwich Elaine Ayers Stephen Chu Michael Tan Kevin Coonan Susan Campbell Laura H Langford Lindsey Hoggle Bi-weekly Weds, 5 - 6pm EST Care Plan DAM Care Coordination Services (CSS) HL7 Structured Documents WG Bob Dolin Brett Marquard Sue Mitchell Jennie Harvell Weekly Thursdays, 10-12pm EST CDA (various) HL7 SOA WG CCS ProjectJon Farmer Enrique Meneses (facilitators) Stephen Chu Susan CampbellWeekly Tuesdays 5 - 6pm EST Care Coordination Services (CSS) HL7 Patient Generated Document Leslie Kelly HallWeekly Fridays, 12- 1pm EST Patient-authored Clinical Documents

7. 7 Need to identify Team Member’s responsibility and type of responsibility for the following data elements (to align with LCC Use Case 2): Health Concerns Interventions Goals How to represent these responsibilities Primary, secondary? Other? Is Team Member’s responsibility for the Care Plan represented in the model? Care Planning Care Plan Governance Does the Care Team Member need to accept/acknowledge their association? Tiger Team Discussion Points

8. 8 Need to establish Team Member’s relationship to Patient Is this represented in current model? Does it need to be? Is it the individual involved in care planning process, do they have a role in intervention(s), or do they simply have access to the Care Plan? Tiger Team Discussion Points

9. 9 Need to identify Team Member’s responsibility and type of responsibility for the following data elements (to align with LCC Use Case 2): Health Concerns Interventions Goals How to represent these responsibilities Primary, secondary? Other? Question posed: Would this be access control/level of access to information? How would this be expressed? Recommendation: Provide a bucket for association/responsibility level and bucket for functional role Team Member Responsibility Discussion

10. 10 Identify Team Member’s responsibility and type of responsibility for Health Concerns Team Member Responsibility – Health Concerns

11. 11 Identify Team Member’s responsibility and type of responsibility for Interventions Team Member Responsibility – Interventions

12. 12 Identify Team Member’s responsibility and type of responsibility for Goals Team Member Responsibility – Goals

13. 13 Is Team Member’s responsibility for the Care Plan represented in the model? Care Planning Care Plan Governance Question posed: Is there a way to account for facilitation of the Care Plan? Comment: This might relate to the “steward” idea from previous discussions. Optional choice by Patient or assigned by organization. Comment: The governance would seem to be the responsibility of the organization and the policy they have. Comment: Idea of “the money follows the patient.” Comment: Rules will probably be set by CMS as far as payments are concerned (probably not at the level of Plan of Care, however). We should work within that in how we manage this. Team Member Responsibility – Care Plan

14. 14 Does the Care Team Member need to accept/acknowledge their association? Recommendation: Care Team Member needs the ability to accept/acknowledge their association Team Member Acceptance/Acknowledgment

15. 15 Need to establish Team Member’s relationship to Patient Is this represented in current model? Does it need to be? Is it the individual involved in care planning process, do they have a role in intervention(s), or do they simply have access to the care plan? How to represent this Team Member Relationship to Patient

16. Proposed Next Steps Next Touch Point meeting with PCWG is July 10 Update discussion schedule Finalize LCC’s Comments by August 4, 2013 for submittal as part of September Ballot

17. 17 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.orgevelyn.gallego@siframework.org Sub Work Group Lead Russ Leftwich cmiotn@gmail.comcmiotn@gmail.com Program Management Lynette Elliott lynette.elliott@esacinc.comlynette.elliott@esacinc.com Becky Angeles becky.angeles@esacinc.combecky.angeles@esacinc.com

18. 18 Background Slides

19. 19 Care Plan DAM – Team Member View

20. 20 Care Plan DAM – Health Concern Includes “expressed by” role but no association role(s)

21. 21 Care Plan DAM – Goal Does not include any role(s) for expressed by or association

22. 22 Care Plan DAM – Plan Activity (Intervention) Does this need additional attributes? —need to define

23. 23 3.4Observation, Condition, Diagnosis, Concern NOTE: The HL7 Patient Care Technical Committee is developing a formal model for condition tracking. The examples provided here are greatly simplified so as to illustrate certain aspects of SNOMED CT implementation. Observations, Conditions, Diagnoses, and Concerns are often confused, but in fact have distinct definitions and patterns. "Observation" and "Condition": An HL7 observation is something noted and recorded as an isolated event, whereas an HL7 condition is an ongoing event. Symptoms and findings (also know as signs) are observations. The distinction between "seizure" and "epilepsy" or between "allergic reaction" and "allergy" is that the former is an observation, and the latter is a condition. SNOMED CT distinguishes between "Clinical Findings" and "Diseases", where a SNOMED CT disease is a kind of SNOMED CT clinical finding that is necessarily abnormal: [ 404684003 | Clinical finding ] [ 64572001 | Disease ] SNOMED IG Definitions Continued on next slide

24. 24 The SNOMED CT finding/disease distinction is orthogonal to the HL7 observation/condition distinction, thus a SNOMED CT finding or disease can be an HL7 observation or condition. "Diagnosis": The term "diagnosis" has many clinical and administrative meanings in healthcare A diagnosis is the result of a cognitive process whereby signs, symptoms, test results, and other relevant data are evaluated to determine the condition afflicting a patient. A diagnosis often directs administrative and clinical workflow, where for instance the assertion of an admission diagnosis establishes care paths, order sets, etc. A diagnosis is often something that is billed for in a clinical encounter. In such a scenario, an application typically has a defined context where the billable object gets entered. "Concern": A concern is something that a clinician is particularly interested in and wants to track. It has important patient management use cases (e.g. health records often present the problem list or list of concerns as a way of summarizing a patient's medical history). SNOMED IG Definitions, cont’d… Continued on next slide

25. 25 Differentiation of Observation, Condition, Diagnosis, and Concern in common patterns: "Observation" and "Condition": The distinction between an HL7 Observation and HL7 Condition is made by setting the Act.classCode to "OBS" or "COND", respectively. The distinction between a SNOMED finding and SNOMED disease is based on the location of the concept in the SNOMED CT hierarchy. There is no flag in a clinical statement instance for distinguishing between a SNOMED CT finding vs. disease. "Diagnosis": Result of a cognitive process: Could potentially be Indicated by post-coordinating a SNOMED CT finding method attribute with a procedure such as "cognitive process". Directs administrative and clinical workflow: These use cases typically rely more on the context in which the diagnoses are entered (e.g. where an order set has a field designated for the admission diagnosis). In such a case, the distinction of a (particular kind of) diagnosis is that it occurs within a particular organizer (e.g. a condition within an Admission Diagnosis section is an admission diagnosis from an administrative perspective). Something that is billed for: The fact that something was billed for would be expressed in another HL7 message. There is nothing in the pattern for a diagnosis that says whether or not it was or can be billed for. SNOMED IG Definitions, cont’d… Continued on next slide

26. 26 "Concern": The HL7 Patient Care Technical Committee is developing a formal model for condition tracking. In that model, a problem (which may be an Observation, a Procedure, or some other type of Act) is wrapped in an Act with a new Act.classCode “CONCERN”. The focus in this guide is on the use of SNOMED CT, whereas the Patient Care condition tracking model is the definitive source for the overall structure of a problem list. It should be noted that the administrative representation of a diagnosis and the representation of a concern break the rules from section 3.1.1 Observations vs. Organizers, in that these designations are based on context, whereas the designation of something as an Observation vs. Condition is inherent in the clinical statement itself. SNOMED IG Definitions, cont’d…

27. 27 HL7 v3 SNOMED CT Definitions 3.4Observation, Condition, Diagnosis, Concern NOTE: The HL7 Patient Care Technical Committee is developing a formal model for condition tracking. The examples provided here are greatly simplified so as to illustrate certain aspects of SNOMED CT implementation. Observations, Conditions, Diagnoses, and Concerns are often confused, but in fact have distinct definitions and patterns. "Observation" and "Condition": An HL7 observation is something noted and recorded as an isolated event, whereas an HL7 condition is an ongoing event. Symptoms and findings (also know as signs) are observations. The distinction between "seizure" and "epilepsy" or between "allergic reaction" and "allergy" is that the former is an observation, and the latter is a condition. SNOMED CT distinguishes between "Clinical Findings" and "Diseases", where a SNOMED CT disease is a kind of SNOMED CT clinical finding that is necessarily abnormal: [ 404684003 | Clinical finding ] [ 64572001 | Disease ]

28. 28 HL7 v3 SNOMED CT Definitions, cont’d… "Diagnosis": The term "diagnosis" has many clinical and administrative meanings in healthcare A diagnosis is the result of a cognitive process whereby signs, symptoms, test results, and other relevant data are evaluated to determine the condition afflicting a patient. A diagnosis often directs administrative and clinical workflow, where for instance the assertion of an admission diagnosis establishes care paths, order sets, etc. A diagnosis is often something that is billed for in a clinical encounter. In such a scenario, an application typically has a defined context where the billable object gets entered. "Concern": A concern is something that a clinician is particularly interested in and wants to track. It has important patient management use cases (e.g. health records often present the problem list or list of concerns as a way of summarizing a patient's medical history).

29. 29 HL7 v3 SNOMED CT Definitions, cont’d… Differentiation of Observation, Condition, Diagnosis, and Concern in common patterns: "Observation" and "Condition": The distinction between an HL7 Observation and HL7 Condition is made by setting the Act.classCode to "OBS" or "COND", respectively. The distinction between a SNOMED finding and SNOMED disease is based on the location of the concept in the SNOMED CT hierarchy. There is no flag in a clinical statement instance for distinguishing between a SNOMED CT finding vs. disease. "Diagnosis": Result of a cognitive process: Could potentially be Indicated by post- coordinating a SNOMED CT finding method attribute with a procedure such as "cognitive process". Directs administrative and clinical workflow: These use cases typically rely more on the context in which the diagnoses are entered (e.g. where an order set has a field designated for the admission diagnosis). In such a case, the distinction of a (particular kind of) diagnosis is that it occurs within a particular organizer (e.g. a condition within an Admission Diagnosis section is an admission diagnosis from an administrative perspective).

30. 30 HL7 v3 SNOMED CT Definitions, cont’d… Differentiation of Observation, Condition, Diagnosis, and Concern in common patterns: "Observation" and "Condition": The distinction between an HL7 Observation and HL7 Condition is made by setting the Act.classCode to "OBS" or "COND", respectively. The distinction between a SNOMED finding and SNOMED disease is based on the location of the concept in the SNOMED CT hierarchy. There is no flag in a clinical statement instance for distinguishing between a SNOMED CT finding vs. disease. "Diagnosis“: Result of a cognitive process: Could potentially be Indicated by post-coordinating a SNOMED CT finding method attribute with a procedure such as "cognitive process". Directs administrative and clinical workflow: These use cases typically rely more on the context in which the diagnoses are entered (e.g. where an order set has a field designated for the admission diagnosis). In such a case, the distinction of a (particular kind of) diagnosis is that it occurs within a particular organizer (e.g. a condition within an Admission Diagnosis section is an admission diagnosis from an administrative perspective). Something that is billed for: The fact that something was billed for would be expressed in another HL7 message. There is nothing in the pattern for a diagnosis that says whether or not it was or can be billed for.

31. 31 HL7 v3 SNOMED CT Definitions, cont’d… "Concern": The HL7 Patient Care Technical Committee is developing a formal model for condition tracking. In that model, a problem (which may be an Observation, a Procedure, or some other type of Act) is wrapped in an Act with a new Act.classCode “CONCERN”. The focus in this guide is on the use of SNOMED CT, whereas the Patient Care condition tracking model is the definitive source for the overall structure of a problem list. It should be noted that the administrative representation of a diagnosis and the representation of a concern break the rules from section 3.1.1 Observations vs. Organizers, in that these designations are based on context, whereas the designation of something as an Observation vs. Condition is inherent in the clinical statement itself.

32. 32 HL7 v3 SNOMED CT XML Examples: Clinical Finding Example 16. Assertion of a clinical finding Headache The observation is asserting a clinical finding of "headache".

33. 33 HL7 v3 SNOMED CT XML Examples: Diagnosis Example 17. Context-dependent (administrative) assertion of a diagnosis Hospital Admission Diagnosis Hospital admission diagnosis of headache That a given diagnosis is, for instance, an Admission Diagnosis, can be asserted by wrapping the observation within a particular organizer.

34. 34 HL7 v3 SNOMED CT XML Examples: Concerns Example 18. Example of a problem list containing concerns Problem List Headache Osteoarthritis of knee

35. 35 HL7 v3 SNOMED CT XML Examples: Concerns, cont’d…. That a given clinical statement is a part of a condition tracking structure can be asserted by containing the clinical statement within the concern act, using the mechanism defined by the HL7 Patient Care Technical Committee, as shown here.