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

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

June 26, 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

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

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

Schedule – June/July 2013SUNDAY MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY SATURDAY

2 3 4 5 6 7 8

11 AM ET: Discussion

Prioritization

9 10 11 12 13 14 1511 AM ET Meeting

Canceled

Tentative Presentation to

HL7 (TBD)

16 17 18 19 20 21 2211 AM ET HL7

Preference and Priority as shown

in DAM

23 24 25 26 27 28 2911 AM ET

Discussion Connections, Crosswalks

30 JULY 1 JULY 2 JULY 3 JULY 4 JULY 5 JULY 6

Work Group SchedulesLCC WG

SWG Meeting LCC Leads Date/ Time Projects

LTPAC SWG Larry GarberTerry O'Malley

Weekly Mondays, 11-12pm EST

C-CDA: Transfer Summary, Consult Note, Referral Note

LCC HL7 Tiger Team

Russ Leftwich Weekly Wednesdays, 11- 12pm EST

LCC WG comments for HL7 Care Plan DAM

LCP SWG Bill RussellSue MitchellJennie Harvell

Weekly Thursdays 5-6pm EST

C-CDA: Care Plan, HomeHealth Plan of Care

HL7 WGSWG Meeting HL7 Lead Participating LCC

MembersDate/ Time Projects

HL7 Patient Care WG Russ LeftwichElaine Ayers Stephen Chu Michael Tan Kevin Coonan

Susan Campbell Laura H Langford Lindsey Hoggle

Bi-weekly Weds, 5 -6pm EST

Care Plan DAMCare Coordination Services (CSS)

HL7 Structured Documents WG

Bob DolinBrett Marquard

Sue MitchellJennie Harvell

Weekly Thursdays, 10-12pm EST

CDA (various)

HL7 SOA WG CCS Project Jon Farmer Enrique Meneses (facilitators) Stephen Chu

Susan Campbell Weekly Tuesdays 5 - 6pm EST

Care Coordination Services (CSS)

HL7 Patient Generated Document

Leslie Kelly Hall Weekly Fridays, 12-1pm EST

Patient-authored Clinical Documents

7

• Associations between Care Team Members and Health Concerns/Goals/Interventions• Is it sufficient to associate one or more Care Team Members

with a data element or should the model include levels of association?• If so, what is the value set for those role/relationship

levels? How many levels should there be and how are they represented (e.g. primary/secondary,/tertiary, or lead/support, or other)

Tiger Team Discussion Points

8

• Can team members be associated with an intervention but not associated with any health concerns/goals?• Do association need to be separated out or do we

assume that if a team member is associated with a health concern that they’re associated with an intervention and/or a goal?

• Can data elements (health concern/goal/intervention) be associated with zero care team members (other than the patient, who would be associated by default)?

• Current model includes “Role” attribute in Health Concern but not in Health Goal or Plan Activity (Intervention)

• Need to define and establish attributes for Plan Activity (Intervention)

Tiger Team Discussion Points

9

Care Plan DAM – Team Member View class Team Members

Common::Patient Roles::CareGiv erRoles::Prov ider Roles::SupportingMember

Act

Plan

+ clinicalSpecialty :Code [0..*]+ completeDate :DateTime+ confidentiality :ConfidentialityType+ createDate :DateTime+ displayName :String+ effectiveDate :DateTime+ id :Identifier+ latestUpdateDate :DateTime+ planClass :PlanClassType+ version :String

A

ClinicalObjectReference

HealthConcern

+ description :Code+ effectiveTime :DateTime+ expressedBy :Role [1..*]+ priority :Priority [1..*]+ reason :ClinicalObjectReference [0..*]+ resolvedTime :DateTime

HealthRisk

+ description :Code+ effectiveTime :DateTime+ levelOfRisk :LevelType+ observer :Role+ resolvedTime :DateTime

Activity

PlanActiv ity

Observation

HealthGoal

+ goal :Code+ milestoneGoal :HealthGoal [0..*] {ordered}+ narrative :String+ planStatus :ExecutionStatusType+ priority :Priority [1..*]+ successCriteria :Criterion [0..*]+ targetDate :DateTime

Activity

ImplementedActiv ity

Common::Role

+ address :Address+ identifier :Identifier [1..*]

«participation»

+administrativeSupportMember

0..*

«participation»

+nonfamilyCareGiver 0..*

+professionalCareTeam

1..*

«participation»

+familyCareGiver 0..*

«participation»«participation»

+subject 1..*

+concern

0..*+presentingRisk

0..*

+presentingRisk

*

+mitigatesRisk

0..*

+presentingRisk

0..*

+proposedAction

1..*

+goalTarget 0..*

addressesConcern

+targetConcern 0..*

+goal

0..*

+implementedAction

0..*

0..1

proposalExecution1

+requiredPerformer 1..*{subsets performer}

10

Care Plan DAM – Health Concern

class Team Members


Act

Plan


A


HealthConcern


HealthRisk


Activity

PlanActiv ity

Observation

HealthGoal


Activity


Common::Role


«participation»


0..*

«participation»



1..*

«participation»



+subject 1..*

+concern

0..*+presentingRisk

0..*

+presentingRisk

*

+mitigatesRisk

0..*

+presentingRisk

0..*

+proposedAction

1..*

+goalTarget 0..*

addressesConcern

+targetConcern 0..*

+goal

0..*

+implementedAction

0..*

0..1

proposalExecution1


Includes “expressed by” role but no association role(s)

11

Care Plan DAM – Goal

class Team Members


Act

Plan


A


HealthConcern


HealthRisk


Activity

PlanActiv ity

Observation

HealthGoal


Activity


Common::Role


«participation»


0..*

«participation»



1..*

«participation»



+subject 1..*

+concern

0..*+presentingRisk

0..*

+presentingRisk

*

+mitigatesRisk

0..*

+presentingRisk

0..*

+proposedAction

1..*

+goalTarget 0..*

addressesConcern

+targetConcern 0..*

+goal

0..*

+implementedAction

0..*

0..1

proposalExecution1


Does not include any role(s) for expressed by or association

12

Care Plan DAM – Plan Activity (Intervention)

class Team Members


Act

Plan


A


HealthConcern


HealthRisk


Activity

PlanActiv ity

Observation

HealthGoal


Activity


Common::Role


«participation»


0..*

«participation»



1..*

«participation»



+subject 1..*

+concern

0..*+presentingRisk

0..*

+presentingRisk

*

+mitigatesRisk

0..*

+presentingRisk

0..*

+proposedAction

1..*

+goalTarget 0..*

addressesConcern

+targetConcern 0..*

+goal

0..*

+implementedAction

0..*

0..1

proposalExecution1


Does not currently include any attributes—need to define

13

Questions/Comments to PCWG

• Is it sufficient to associate one or more Care Team Members with a data element or should the model include levels of association?• If so, what is the value set for those role/relationship

levels? How many levels should there be and how are they represented (e.g. primary/secondary,/tertiary, or lead/support, or other)• Comment: These associations must be expressed as

part of the model so it can trace back to whoever has responsibility assigned to the health concern, goal or intervention so they can get paid for it.

• Comment: It’s critical to assign a team member’s role and responsibility. The model needs to support some kind of self-identification as well as the ability to tag another individual as being engaged.

14


• Can team members be associated with an intervention but not associated with any health concerns/goals?• Do association need to be separated out or do we assume

that if a team member is associated with a health concern that they’re associated with an intervention and/or a goal?• Comment: Roles should be assigned at the

intervention level with a relationship to the goal, but we don’t need an explicit connection between the team member and the goal. The roles shouldn’t be dependent on the health concern or who assigned the health concern.

15


• Can data elements (health concern/goal/intervention) be associated with zero care team members (other than the patient, who would be associated by default)?• NOTE: No feedback—not discussed during this session

16


• Current model includes “Role” attribute in Health Concern but not in Health Goal or Plan Activity.• Comment: It would be helpful to establish a taxonomy to

support how the association/relationship will be used (e.g., as a messaging filter to only send information to certain entities and/or showing who is involved and their sub-roles and/or other).

17

Questions/Comments to PCWG• Need to define and establish attributes for Plan Activity

(Intervention)• Recommendation: List attributes that can currently be defined

and then, if feasible, list placeholders or blank space for attributes that need to be defined at a later time:• Attribute 1: goalAssociation• Attribute 2: TBD (goalRole, goalRelationship or other)

• NOTE: “Additional attributes” would be listed as placeholders so that the model can be flexible enough to continue to enable the standard, which will evolve with future needs.

• Recommendation: Add association attribute(s) to the Activity level data element (perhaps as part of +performer and +requester as they relate to Role component.

• Recommendation: Association should include both individual and organization under functional role in addition to level of association/relationship (who would see the information at any given time).

Proposed Next Steps

• Next Touch Point meeting with PCWG is TBD• Update discussion schedule• Finalize LCC’s Comments by August 4, 2013 for

submittal as part of September Ballot

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 [email protected]

• Sub Work Group Lead• Russ Leftwich [email protected]

• Program Management• Lynette Elliott [email protected]• Becky Angeles [email protected]

20

Background Slides

21

3.4 Observation, Condition, Diagnosis, ConcernNOTE: 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

22

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…


23

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.



24

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


25

HL7 v3 SNOMED CT Definitions• 3.4 Observation, 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 ]

26

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

27

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

28

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.

29

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.

30

HL7 v3 SNOMED CT XML Examples: Clinical Finding

• Example 16. Assertion of a clinical finding<observation classCode="OBS" moodCode="EVN"> <code code="ASSERTION"

codeSystem="2.16.840.1.113883.5.4"/> <text>Headache</text> <value xsi:type="CD" code="25064002|Headache|"

codeSystem="2.16.840.1.113883.6.96"> <displayName value="Headache"/> </value></observation>

• The observation is asserting a clinical finding of "headache".

31

HL7 v3 SNOMED CT XML Examples: Diagnosis

• Example 17. Context-dependent (administrative) assertion of a diagnosis<act classCode="DOCSECT" moodCode="EVN"> <code code="8646-2" codeSystem="2.16.840.1.113883.6.1"

codeSystemName="LOINC"/> <title>Hospital Admission Diagnosis</title> <text>Hospital admission diagnosis of headache</text> <actRelationship typeCode="COMP"> <observation classCode="OBS" moodCode="EVN"> <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/> <value xsi:type="CD" code="25064002|Headache|"

codeSystem="2.16.840.1.113883.6.96"> <displayName="Headache"/> </value> </observation> </actRelationship></act>

• That a given diagnosis is, for instance, an Admission Diagnosis, can be asserted by wrapping the observation within a particular organizer.

32

HL7 v3 SNOMED CT XML Examples: Concerns

• Example 18. Example of a problem list containing concerns<act classCode="DOCSECT" moodCode="EVN"> <code code="11450-4" codeSystem="2.16.840.1.113883.6.1"

codeSystemName="LOINC"/> <title>Problem List</title> <text> <list> <item>Headache</item> <item>Osteoarthritis of knee</item> </list> </text> <actRelationship typeCode="COMP"> <act classCode="CONCERN" moodCode="EVN"> <actRelationship typeCode="SUBJ"> <observation classCode="OBS" moodCode="EVN"> <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/> <value xsi:type="CD" code="25064002|Headache|"

codeSystem="2.16.840.1.113883.6.96"> <displayName value="Headache"/> </value> </observation> </actRelationship> </act>

33

HL7 v3 SNOMED CT XML Examples: Concerns, cont’d…

</actRelationship> <actRelationship typeCode="COMP"> <act classCode="CONCERN" moodCode="EVN"> <actRelationship typeCode="SUBJ"> <observation classCode="OBS" moodCode="EVN"> <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/> <value xsi:type="CD" code="239873007|Osteoarthritis of knee|"

codeSystem="2.16.840.1.113883.6.96"> <displayName value="Osteoarthritis of knee"/> </value> </observation> </actRelationship> </act> </actRelationship></act>.

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