longitudinal coordination of care (lcc) workgroup (wg) hl7 tiger team patient care wg care plan dam...
TRANSCRIPT
Longitudinal Coordination of Care (LCC) Workgroup (WG)HL7 Tiger Team Patient Care WG Care Plan DAM
July 3, 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 611 AM ET
Discussion Plan Activity Data
Element Attributes
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
• Can data elements (each of health concern, goal, and intervention) be associated with zero care team members (other than the patient, who would be associated by default)?• In other words, zero to many team members associated
with the data element (0…* cardinality)• Can examples of this situation be provided?
• If there should be a team member associated with each of the data elements, the statement would be SHALL.
Tiger Team Discussion Points
8
• Can data Health Concern be associated with zero care team members (other than the patient, who would be associated by default)?• Can be zero: if patient is keeping his/her own care plan
and not sharing it (in personal health record) they would be sole member of care team, or where patient says it’s only my business and not yours—I want information there so that a healthcare proxy could be aware of it.
• Patient has hazardous occupation but no one else has an association with that (but this is a risk that’s a health concern, so the primary provider might list this as a concern)
• Fitness level that allows them to run Boston marathon (wellness concern) but not reasonably a requirement that other team members would have other than overarching goal to run in marathon
Health Concern to Team Member Cardinality
9
• Patient has concern that is not a “medical” condition that needs treatment (ex: nutritional concepts that have no medical basis)
• If patient has concerns (such as home cleanliness, compulsive cleansing, etc.) that other members of the care team don’t see as health concerns
• Pattern of utilization and nature of utilization goes on the care plan, not necessarily the condition itself (ex: not the bump, but rather the somatic/compulsivity issues would be addressed)
• Conclusion: in terms of model, Health Concern can be zero to many
• Recommended conformance: SHOULD
Health Concern to Team Member Cardinality
10
• Can Goal be associated with zero care team members (other than the patient, who would be associated by default)?• Conclusion on this is yes, since overarching goals are
patient’s goals (this would be a much more common occurrence than with health concern)• There will often be patient goals that would not be
associated with another care team member• Care team’s goals could be subject to negotiation• Definition would have to be within constraints of the
funding vehicle (ex: patient goal might be ambulation rather than fine motor dexterity, which is care team’s goal, and this would be recorded)
• There’s a difference between the strategic and the tactical issues
• Recommended conformance: SHOULD
Goal to Team Member Cardinality
11
• Can Intervention be associated with zero care team members (other than the patient, who would be associated by default)?• If it’s a self care issue it could be zero (self care meaning
requiring no reasonable instructions by the care team)• Conclusion: this can be zero cardinality• Recommended conformance: SHOULD
Intervention to Team Member Cardinality
12
• Would the patient be the only care team member associated with a health concern, goal, or intervention? • That is, beyond their default association with all, might
there be instances where they would be the only care team member associated with a data element and would have accountability for that element?
Intervention to Team Member Cardinality
13
• Establish attributes for Plan Activity• Pull elements from Health Concern and Goal as baseline• Include role(s): individual/organization• Include level(s) of association
Plan Activity Attributes Discussion
14
Care Plan DAM – Team Member View
class Team Members
Common::Patient
::Role+ address :Address+ identifier :Identifier [1..*]
Roles::CareGiv er
::Role+ address :Address+ identifier :Identifier [1..*]
Roles::Prov ider
::Role+ address :Address+ identifier :Identifier [1..*]
Roles::SupportingMember
::Role+ address :Address+ identifier :Identifier [1..*]
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
::Activity+ applicabil ity :TimeRecord [0..1]+ classification :Code+ description :Code+ endDate :DateTime+ frequency :Frequency [0..1]+ functionalArea :Code [0..*]+ postcondition :Criterion [0..*]+ precondition :Criterion [0..*]+ priority :Priority+ startDate :DateTime+ supportiveContent
:ClinicalObjectReference [0..*]
Observation
HealthGoal
+ goal :Code+ milestoneGoal :HealthGoal [0..*] {ordered}+ narrative :String+ planStatus :ExecutionStatusType+ priority :Priority [1..*]+ successCriteria :Criterion [0..*]+ targetDate :DateTime::Observation+ applicabil ityTime :TimeRecord+ capturedTime :DateTime+ description :Code+ historical :Boolean [0..1] = false+ interpretation :Code [0..1]+ method :Code [0..1]+ targetSite :Code [0..1]
Activity
ImplementedActiv ity
::Activity+ applicabil ity :TimeRecord [0..1]+ classification :Code+ description :Code+ endDate :DateTime+ frequency :Frequency [0..1]+ functionalArea :Code [0..*]+ postcondition :Criterion [0..*]+ precondition :Criterion [0..*]+ priority :Priority+ startDate :DateTime+ supportiveContent :ClinicalObjectReference [0..*]
Common::Role
+ address :Address+ identifier :Identifier [1..*]
+concern
0..*
+goal
0..*
addressesConcern
+targetConcern 0..*
+presentingRisk
*
«participation»
+subject 1..* +familyCareGiver 0..*
«participation»
+proposedAction
1..*
+professionalCareTeam
1..*
«participation»
+presentingRisk
0..*
+presentingRisk
0..*
0..1
proposalExecution
1
+requiredPerformer 1..*{subsets performer}
«participation»
+nonfamilyCareGiver 0..*
+mitigatesRisk
0..*
+goalTarget
0..*
«participation»
+administrativeSupportMember
0..*
+implementedAction 0..*
15
Care Plan DAM – Health Concern
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}
Includes “expressed by” role but no association role(s)
16
Care Plan DAM – Goal
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}
Does not include any role(s) for expressed by or association
17
Care Plan DAM – Plan Activity (Intervention)
Does this need additional attributes? —need to define
class Team Members
Activity
PlanActiv ity
::Activity+ applicability :TimeRecord [0..1]+ classification :Code+ description :Code+ endDate :DateTime+ frequency :Frequency [0..1]+ functionalArea :Code [0..*]+ postcondition :Criterion [0..*]+ precondition :Criterion [0..*]+ priority :Priority+ startDate :DateTime+ supportiveContent
:ClinicalObjectReference [0..*]
18
Questions/Comments to PCWG
• Comment:
Proposed Next Steps
• Discussion for next week:• Next Touch Point meeting with PCWG is TBD (either July
10 or July 24, or both)• Update discussion schedule• Finalize LCC’s Comments by August 4, 2013 for
submittal as part of September Ballot
20
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]
21
Background Slides
22
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
23
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
24
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
25
"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…
26
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 ]
27
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).
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).
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).
• 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.
30
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.
31
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".
32
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.
33
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>
34
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.