Kona Design
[pic] [pic]
HL7 Implementation Guide:
CDA Release 2 – Continuity of Care Document (CCD)
A CDA implementation of ASTM E2369-05
Standard Specification for Continuity of Care Record© (CCR)
which may be used in lieu of ASTM ADJE2369
1st Informative Ballot
April 03, 2006
|Co-Chair: |Liora Alschuler |
| |Alschuler Associates |
| |Liora@ |
|Co-Chair: |Calvin Beebe |
| |Mayo Clinic |
| |cbeebe@mayo.edu |
|Co-Chair: |Fred M. Behlen, PhD |
| |American College of Radiology |
| |fbehlen@ |
|Editor: |Keith W. Boone |
| |Dictaphone Corporation |
| |keith.boone@ |
|Co-Chair: |Robert H. Dolin, MD |
| |Kaiser Permanente |
| |robert.h.dolin@ |
|Editor: |Rick Geimer |
| |Alschuler Associates |
| |rick@ |
|Editor: |V. "Juggy" Jagannathan, PhD |
| |MedQuist |
| |juggy@ |
|Editor: |Patrick Mitchell-Jones |
| |patrick.mitchell-jones@cfh.nhs.uk |
|Editor: |Rick Peters, MD |
| |rpeters@ |
|Editor: |Dan Russler, MD |
| |McKesson |
| |Dan.Russler@ |
|Editor: |Amnon Shabo (Shvo), PhD |
| |IBM Research Lab in Haifa |
| |shabo@il. |
|Editor: |Steven E. Waldren, MD, MS |
| |Center for Health Information Technology, AAFP |
| |swaldren@ |
|Editor: |Bob Yencha |
| |Alschuler Associates |
| |bob@ |
|Editor: |Alan Zuckerman, MD |
| |aez@georgetown.edu |
Table of Contents
Table of Contents 3
Figures 5
Tables 6
1 Introduction 7
1.1 Scope 7
1.2 Approach 7
2 General Constraints 9
2.1 Data Types 9
2.2 Source 18
2.3 Identifiers 19
2.4 Roles 20
2.5 Terminology conformance 21
3 CCD Header 24
3.1 Document ID 25
3.2 Language 26
3.3 Creation Date 26
3.4 Patient 27
3.5 From 29
3.6 To 31
3.7 Purpose 31
3.8 CCR Footer 31
4 CCD Body 34
4.1 Payers 35
4.2 Support 35
4.3 Healthcare Providers 36
4.4 Functional Status 36
4.5 Problems 36
4.6 Family History 43
4.7 Social History 52
4.8 Allergies and Adverse Reactions 52
4.9 Medications 72
4.10 Immunizations 83
4.11 Vital Signs 83
4.12 Results 85
4.13 Procedures 94
4.14 Encounters 94
4.15 Plan of Care 94
5 References 96
6 Appendix 97
6.1 Extensions to CDA R2 97
6.2 Change Log 98
Figures
Figure 1. Clinical Statement Model for Conditions 36
Figure 2. CDA R2 clinical statement model for family history (constrained and extended) 45
Figure 3. Clinical Statement model for Allergies and other Intolerances 64
Figure 4. CDA R2 clinical statement model for medications 73
Figure 5. CDA R2 clinical statement model for vital signs 83
Figure 6. CDA R2 clinical statement model for results 86
Figure 7. Extensions to CDA Header 98
Figure 8. CDA R2 clinical statement model for family history (constrained and extended) 98
Figure 9. Mapping based on Clinical Genomics approach 99
Figure 10. Mapping based on Clinical Genomics approach (contd) 99
Figure 11. Mapping based on new roles of mother and father scoped by the relative entity (SubjectPerson) 100
Figure 12. Mapping based on a family member 'registry' 101
Tables
Table 1. CCR correspondence to CDA 9
Table 2. CCR correspondence to CDA mapping - Examples 10
Table 3. CCR correspondence to CDA 14
Table 4. CCR correspondence to CDA - Examples 15
Table 5. CCR correspondence to CDA 16
Table 6. CCR correspondence to CDA - Examples 16
Table 7. CCR correspondence to CDA 17
Table 8. CCR correspondence to CDA - Examples 18
Table 9. CCR correspondence to CDA 18
Table 10. Common OIDs assigned by HL7 19
Table 11. CCR correspondence to CDA 19
Table 12. CCR correspondence to CDA 20
Table 13. CCR correspondence to CDA 21
Table 14. CCR correspondence to CDA - Examples 21
Table 15. CCR values and corresponding CDA CD.codeSysytem values 22
Table 16. CCR correspondence to CDA 24
Table 17. CCR correspondence to CDA 31
Table 18. CCR Body Elements and their correspondence to CDA 34
Table 19. CCR correspondence to CDA 35
Table 20. CCR correspondence to CDA 35
Table 21. CCR correspondence to CDA 36
Table 22. CCR correspondence to CDA 38
Table 23. CCR correspondence to CDA 46
Table 24. Clone Name: AllergyIntolerance 54
Table 25. Clone Name: AssignedConditionName 55
Table 26. Clone Name: ConditionNodeEvent 55
Table 27. Clone Name: LinksCNOD 56
Table 28. Clone Name: SupportCNOD 56
Table 29. Clone Name: ActChoiceBox 56
Table 30. Clone Name: CausalityAssessment 57
Table 31. Clone Name: CausalityAssessmentSubject 58
Table 32. Clone Name: Observation 58
Table 33. Clone Name: ImplicatesSubstanceAdministration 60
Table 34. Clone Name: Exposure 60
Table 35. Clone Name: AllergyTest 62
Table 36. ASTM CCR TABLE A2.13 Object Type Definition Table 66
Table 37. ASTM CCR TABLE A2.12 Object Type (StructuredProductType) Definition Table 75
Table 38. CCR correspondence to CDA 88
Table 39. CCR correspondence to CDA 89
Introduction
1 Scope
The purpose of this document is to describe constraints on the HL7 Clinical Document Architecture, Release 2 (CDA) specification in accordance with requirements set forward in ASTM E2369-05 Standard Specification for Continuity of Care Record (CCR).
The CCR is a core data set of the most relevant administrative, demographic, and clinical information facts about a patient's healthcare, covering one or more healthcare encounters. It provides a means for one healthcare practitioner, system, or setting to aggregate all of the pertinent data about a patient and forward it to another practitioner, system, or setting to support the continuity of care. The primary use case for the CCR is to provide a snapshot in time containing the pertinent clinical, demographic, and administrative data for a specific patient.
The HL7 Clinical Document Architecture (CDA) is a document markup standard that specifies the structure and semantics of clinical documents for the purpose of exchange. From its inception, CDA has supported the ability to represent professional society recommendations, national clinical practice guidelines, and standardized data sets. From the perspective of CDA, the CCR is a standardized data set that can be used to constrain CDA specifically for summary documents.
The resulting specification, known as the Continuity of Care Document (CCD), is developed as a collaborative effort between ASTM and HL7. It is intended as an alternate implementation to the one specified in ASTM ADJE2369 for those institutions or organizations committed to implementation of the HL7 Clinical Document Architecture.
Note: The HL7 Implementation Guide for CDA Release 2 – Level 1 and 2 – Care Record Summary (US realm) (CRS) will be superseded by a CCD implementation guide as this project completes the analysis and inclusion of the full set of CRS requirements into CCD.
2 Approach
The approach taken in the development of this specification is intended to reflect the ASTM CCR requirements in an HL7 CDA R2 framework, and to do so in such a way that CDA is constrained in accordance with models being developed by other HL7 committees.
The general steps taken include:
• Review a section of CCR, focusing on identifying the data requirements. For instance, review the CCR section describing the representation of lab results.
• Review overlapping HL7 domain models to see how similar data requirements have been represented. For instance, review the domain model from the Lab committee to see how it accommodates lab results.
• Review additional relevant references and standards for further cross-validation of requirements.
• Represent the CCR data requirements as a set of constraints against the HL7 Clinical Statement model, in a way that is isomorphic to existing HL7 domain models. This constrained Clinical Statement model can then be used by any HL7 committee wanting to implement similar requirements in their own specifications.
• Reflect the Clinical Statement constraints as constraints against CDA R2, making minor adjustments as necessary to accommodate the differences between the models.
General Constraints
1 Data Types
Various CCR data types can be directly mapped onto HL7 RIM classes or data types. These mappings are described in the sections below.
1 Dates and Times
CCR elements are typically represented in CDA using the HL7 TS, IVL_TS or PPD_TS data types. Some elements may be represented as PQ or IVL_PQ (e.g., age is one such measurement). Values which give just a narrative or text representation will also need to be stored using PQ.
1. CCR correspondence to CDA
|CCR data element |CDA R2 correspondence |Comments |
| |Any element using GTS or derived data type | |
| |(e.g. effectiveTime) | |
| |Not Explicitly Modeled |ASTM: The list of values for |
| | |includes numerous values, but has not been |
| | |formally constrained by the standard. |
| | |HL7: The type of the date time is implicity |
| | |determined its location within the XML |
| | |structure. |
| |TS |HL7: HL7 time stamps are recorded using ISO |
| | |8601 without any delimiters (hyphens, colons, |
| | |the letter T between date and time). |
| | |ASTM: ASTM time stamps are recored using ISO |
| | |8601 with delimiters (hyphens, colons, and the|
| | |letter T between date and time). |
| |IVL_TS, PPD_TS, PQ |ASTM: Age less than 2 weeks is expressed in |
| | |days, less than 2 months in weeks, and less |
| | |than 2 years in months. All others expressed |
| | |in years. |
| | |HL7: Age can be expressed as an interval in |
| | |time in HL7 or a physical quantity, however, |
| | |when points in time are used to represent |
| | |dates within HL7 structures, these dates must |
| | |be computed based on the known or estimated |
| | |date of birth, or expressed in related |
| | |observations |
| | |PPD_TS is an informative data type, not a |
| | |normative one. There is an explicit |
| | |conversion described between TS instances with|
| | |limited precision and the PPD_TS data type. |
| | |To convert a point in time to a PPD_TS, one |
| | |ensures that two standard deviations cover the|
| | |range, and the interval is specified at the |
| | |midpoint. The units are specified using the |
| | |HL7 UnitsOfMeasureCaseSensitive vocabulary, |
| | |where: |
| | |d = day |
| | |mo = month |
| | |a = year |
| |PQ |ASTM: There is no specified mechanism or |
| | |vocabulary to express an approximate date |
| | |time. These are represented in CCR using the |
| | |Coded Description Type. |
| | |HL7: Approximate date times may only be |
| | |recorded in a CDA when they can be recorded in|
| | |a related observation whose subject is the |
| | |primary act. The code of this act should |
| | |describe the purpose of the date time, and the|
| | |value of this act should use the CD data type,|
| | |so that it can fully represent the Coded |
| | |Descrition Type allowed by a CCR. |
| |IVL_TS | |
| | | |
| |TS | |
| |PPD_TS | |
| |PQ | |
| | | |
| |TS | |
| |PPD_TS | |
| |PQ | |
2. CCR correspondence to CDA mapping - Examples
|CCR Data Representation |CDA R2 Data Representation |
| | |
|2004 | |
| | |
| | |
|2004-09 | |
| | |
| | |
|2004-09-01 | |
| | |
| | |
|2004-09-01T13-0500 | |
| | |
| | |
|2004-09-01T1325-0500 | |
| | |
| | |
|2004-09-01T132534-0500 | |
| | |
| | |
| | |
|5 | |
|Days | |
| | |
| | |
| | |
| | |
|3 | |
|Weeks | |
| | |
| | |
| | |
| | |
|18 | |
|Months | |
| | |
| | |
| | |
| | |
|45 | |
|Years | |
| | |
| | |
| | |
| | |
|One Week Ago | |
| | |
| | |
| | |
| | |
|As a Child | |
| | |
| | |
| | |
| | |
|Thirty Years Ago | |
| | |
| | |
| | |
| | |
|In 30s | |
| | |
| | |
| | |
| | |
| | |
|1965-09-01 | |
| | |
| | |
| | |
| | |
| | |
| | |
|2004-09-01 | |
| | |
| | |
| | |
| | |
| | |
| | |
|1965-09-01 | |
| | |
| | |
|2004-09-01 | |
| | |
| | |
| | |
1 to RIM/CDA Vocabulary
The CCR vocabulary for identifying dates is very rich in what information can be provided, but the vocabulary has not been formally constrained. This section describes how dates in a CCR are mapped into relevant data structures within a CDA.
ED NOTE: These constraints are typically needed in only one or two sections. Should they be moved to the relevant section (e.g., Advance Directives, Medications…)
1 Appointment Date, Visit Date, Procedure Date
Appointment, Visit and Procedure dates may be proposed, planned, or ordered, or may have already occurred.
1: These dates shall be recorded in the of an with an appropriate moodCode (e.g., INT, PRMS, RQO, EVN).
2: Dates that are related to the age of the patient or are approximated shall be recorded in a related observation using an act relationship.
3: The subject of the related observation shall be the act being described.
4: The of this related observation shall indicate the significance of the date.
5: The of this related observation shall indicate the age or approximation given for the date.
|CCR Data Representation |CDA R2 Data Representation |
|Example using Appointment Date | |
|Example using Visit Date | |
|Example using Procedure Date | |
2 Benefit Start Date, Benefit Stop Date, Effective Date, Effective Period, Start Date, Stop Date and Termination Date
6: These dates may appear in the Insurance section of the CCR when related to payer benefits.
7: The times related to payer benefits appears shall be recorded in the element of the that holds the policy being described.
8: These dates shall not be recorded as approximate or age related dates.
|CCR Data Representation |CDA R2 Data Representation |
|Example using Benefit Start Date/Stop Date | |
|Example using Effective Date | |
|Example using Effective Period | |
|Example using Termination Date | |
3 Collection Date, Collection Start Date, Collection Stop Date, Measurement Date, Measurement Start Date, Measurement Stop Date
9: Date of collection or measurement when related to values determined for vital signs, laboratory results, or other types of results (e.g., EKG), shall be recorded in the appropriate components of the elements reporting those results.
10: These dates shall not be recorded as approximate or patient age related dates.
|CCR Data Representation |CDA R2 Data Representation |
|Example using Collection Date | |
|Example using Collection Start/Stop Date | |
|Example using Measurement Date | |
|Example using Measurement Start/Stop Date | |
4 Date of Last Exposure, Date of Onset
11: These dates are used to record the exposure [to a hazardous material] or onset [of an illness or symptom].
12: A primary observation shall record the exposure to a hazardous material or onset of a condition.
13: This shall have a indicating that this is an exposure or condition.
14: The of this shall indicate the hazardous material, and illness or symptom as appropriate.
15: The date of last exposure to a hazardous material, or onset of a condition shall be recorded in the element of the primary recording the exposure or onset when known exactly or known to be within a range of dates.
16: The last exposure to a hazardous material or onset of a condition shall be related to the age of the patient in a related observation.
17: When the age or date is approximated, it shall be recorded in a related observation, whose indicates approximate age or time of onset or exposure, and whose is of type CD.
18: The of an approximate date shall be translated using the rules for coded types where the original text representing the value shall also be present.
|CCR Data Representation |CDA R2 Data Representation |
|Example using Date of Last Exposure | |
|Example using Date of Onset | |
5 Time of Death
These dates are used with the cause death of the patient or related subject.
19: The principal observation being recorded shall be the condition [problem, illness, diagnosis, et cetera] of the patient or related subject that was the cause of death.
20: A related observation describing death shall be recorded using act relationship whose cause is the principal observation.
21: This related observation shall have a indicating that the observation is death.
22: The of this related observation shall not be present.
23: The of this observation shall be the exact date and time of death if known.
24: The age at death, when known, shall be recorded in a related observation, whose indicates age at death and whose indicates the age of the patient at death.
25: When the age or date is approximated, it shall be recorded in a related observation, whose indicates approximate age or time of death, and whose is of type CD.
26: The of an approximate date shall be translated using the rules for coded types where the original text representing the value shall also be present.
|CCR Data Representation |CDA R2 Data Representation |
|Example using Date of Last Exposure | |
|Example using Date of Onset | |
|Example using Time of Death | |
6 Renewal Date, Last Refill, Start Date, Stop Date
These dates may be used to record information about the administration, application, use, or ordering of medications or medical devices.
27: Dates recording information about the administration, application, use, or ordering of medications or medical devices shall be recorded in the appropriate fields of a or act.
See the section on medications for more detail.
|CCR Data Representation |CDA R2 Data Representation |
|Example using Renewal Date | |
|Example using Last Refill Date | |
|Example using Start/Stop Date | |
7 Last Recorded
28: When used to record activity relevant to Advance Directives, the Last Recorded date of an Advance Directive shall be recorded in the of participation of the of the describing the Advance Directive.
|CCR Data Representation |CDA R2 Data Representation |
|Example using Last Recorded | |
8 Last Verified with __
These dates are used to record activity relevant to the verification of advance directives.
29: The date upon which an advance directive was been verified shall be recorded as the of participation of the party that verified the Advance Directive.
30: The advance directive shall be recorded as an .
31: This shall have at least one of type AUTHEN and/or LA which identifies the role and person with whom the Advance Directive was verified.
|CCR Data Representation |CDA R2 Data Representation |
|Example using Last Verified with Durable Power of Attorney | |
|Example using Last Verified with Family | |
|Example using Last Verified with Parent | |
|Example using Last Verified with Patient | |
|Example using Last Verified with Treating Physician | |
2 Names
3. CCR correspondence to CDA
|CCR data element |CDA R2 correspondence |Comments |
| | |ASTM: The CCR current name is the current |
| | |legal name. |
| | | |
| | |HL7: HL7 Version 3 does not distinguish |
| | |between "First" and "Middle" given names |
| | |except by position. |
| | | |
| | |ASTM: The suffix is for "parts of the name", |
| | |such as Jr., Sr., III, et cetera. |
| | |HL7: A suffix appears after a name component.|
| | |Jr., Sr., III, et cetera, would be suffixes |
| | |in an HL7 name, but so would Ph.D. or M.D. |
| | |(but see below for Title). |
| | |ASTM: Examples of titles in the CCR |
| | |implementation guide show Ph.D., MD, which |
| | |would be suffixes. It is not clear how Dr., |
| | |Mr., Miss, Ms. or Mrs. would be handled in a |
| | |CCR. |
| | |HL7: The TITLE qualifier indicates that the |
| | |prefix or suffix applies to the whole name, |
| | |rather than just the preceeding or following |
| | |component. |
| | |HL7: The use of the "Call Me" coded value in |
| | |qualifier indicates that this is what the |
| | |person would like to be called. |
| | | |
| | |HL7: The use of the "Birth Name" coded value |
| | |in qualifier indicates that this represents |
| | |the value at or near birth. |
| | |ASTM: The display name in the CCR is not |
| | |marked up. |
| | |HL7: Within HL7, a name need not be marked |
| | |up. To represent the CCR display name, the |
| | |name entry should not contain any markup, |
| | |just text. |
4. CCR correspondence to CDA - Examples
|CCR encoded |CDA R2 encoded |Comments |
| | | |
| | |Separate the nickname from |
| | |the legal name in a separate |
| | | element as shown |
| | |below. |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | |Don't use Title or NickName |
| | |with BirthName |
| | | |
| | | |
| | | |
| | | |
| | |Record the display name |
| | |without delimiters. |
| | | |
3 Addresses
5. CCR correspondence to CDA
|CCR data element |CDA R2 correspondence |Comments |
| |addr | |
| |addr.use |ASTM: The ASTM recommended value set |
| | |includes Home and Office. |
| | |HL7: The use attribute indicates the type of |
| | |address. Set addr.use='H' or addr.use='HP' |
| | |for Home, addr.use='WP' for Office. |
| |addr.streetAddressLine | |
| |addr.streetAddressLine |HL7: Use one streetAddressLine for each line.|
| |addr.city | |
| |addr.county | |
| |addr.state | |
| |addr.country | |
| |addr.postalCode | |
| |addr.use |ASTM: The ASTM recommended value set includes|
| | |Primary - Preferred and Secondary. |
| |addr.use |ASTM: The ASTM recommended value set includes|
| | |Active and Temporary. |
| | |HL7: Set addr.use='TMP' to indicate a |
| | |temporary address. |
6. CCR correspondence to CDA - Examples
|CCR encoded |CDA R2 encoded |Comments |
| | |
| | |
| | |
| | |
|2004 |Acute Antereoseptal Myocardial Infarction |
| | |
| | |
|22298006 | |
|SNOMED CT | |
| | |
| | |
| | |
|Acuity | |
|Acute | |
|53737009 | |
|SNOMED CT | |
|20050131 | |
| | |
| | |
| | |
| | |
|Site | |
| | |
|Antereoseptal | |
| | |
|20706007 | |
|SNOMED CT | |
|20050131 | |
| | |
| | |
| | |
| | |
2 Coding System Usage
The CCR states that Problems should be coded using SNOMED CT, and ICD-9 CM codes, Procedures using SNOMED CT, LOINC and CPT codes, Products and Agents using RxNorm, and Results using CPT and LOINC. In order to utilize these coding systems, an agreement must be reached upon how to represent these systems within a CCR. The table below shows how to map values from a CCR into the codeSystem attribute of an HL7 Version 3 CD data type.
15. CCR values and corresponding CDA CD.codeSysytem values
|CCR |CD.codeSystem |CD.codeSystemName |
|CPT-4 |2.16.840.1.113883.6.12 |CPT-4 |
|ICD-9 CM |2.16.840.1.113883.6.1 |ICD-9 CM |
|LOINC |2.16.840.1.113883.6.1 |LOINC |
|NDC |2.16.840.1.113883.6.69 |NDC |
|RxNorm |2.16.840.1.113883.6.88 |RxNorm |
|SNOMED CT |2.16.840.1.113883.6.96 |SNOMED CT |
39: When representing the any of the coding systems listed above, the codeSystem attribute shall be present using the values listed in that table.
40: When the codeSystemName attribute is present, it shall be valued with the appropriate values from Table 15 above.
41: Where SNOMED CT is used, it shall be used per the "Using SNOMED CT in HL7 Version 3" Implementation Guide.
CCD Header
16. CCR correspondence to CDA
|CCR data element |CDA R2 correspondence |Comments |
| |ClinicalDocument.id |ASTM: This must be a unique ID |
| | |within the generating system. |
| | |ASTM recommends the use of OID, |
| | |UUID or similar mechanism. |
| | |HL7: This is represented using an|
| | |OID or UUID and an optional |
| | |extension. |
| |ClinicalDocument.languageCode |ASTM: No controlled vocabulary has|
| | |been specified. |
| |ClinicalDocument.typeID |ASTM: For this version of the CCR,|
| | |it must state V1.0 |
| | |HL7: The typeID performs the same |
| | |function for HL7 CDA Release 2.0. |
| |ClinicalDocument.effectiveTime |ASTM: The exact clock time that |
| | |this CCR was created/generated. |
| | |HL7: The time that the document |
| | |was created. |
| |recordTarget.patientRole |ASTM: The CCR can only be about |
| | |one patient with the extreme |
| | |exception of Siamese twins. |
| | |HL7: The recordTarget identifies |
| | |the patient or patients chart that|
| | |is being updated. |
| |author |ASTM: Identifies who or what |
| | |created the document. |
| | |HL7: Identifies the author of the |
| | |document. |
| referencing a person |author.assignedAuthor | |
| |author.functionCode |ASTM: Representative values given |
| |assignedAuthor.code |in the CCR Implementation Guide |
| | |are Primary Care Provider. |
| referencing an |author.assignedAuthoringDevice | |
|Information System | | |
| |assignedAuthoringDevice.code | |
| |code.originalText | |
| referencing an |author.representedOrganization | |
|Organization |patient.providerOrganization | |
| |representedOrganization. standardIndustryClassCode |ASTM: Representative values given |
| | |in the CCR Implementation Guide |
| | |are Care Facility and Long Term |
| | |Care Facility. |
| |standardIndustryClassCode.originalText | |
| |informationRecipient |ASTM: Identifies to whom or what |
| | |the CCR is targeted. |
| | |HL7: Identifies the intended |
| | |recipient of the document. |
| referencing a person |informationRecipient. | |
| |rmationRecipient | |
| referencing an |Not modeled | |
|Information System | | |
| referencing an |informationRecipient. | |
|Organization |intentedRecipient.recievedOrganization | |
| | | |
| | | |
| | | |
| |ClinicialDocument.title | |
| |ClinicialDocument.code | |
| | | |
| | | |
| | | |
| | | |
1 Document ID
The document identifier must be represented as an OID. This will be recorded in root, and extension will be empty. This OID furthermore defines the assigning authority for identifiers represented within the CCR dataset (e.g., ActorID).
1 Conformance
42: The document identifier shall be an OID.
43: The document identifier shall be recorded in ClinicalDocument.id.root.
44: ClinicalDocument.id.extension shall not be present.
2 Example
1 CDA-encoded
This example shows how the document identifier is represented in a CCD.
:
.
:
.
2 CCR-encoded
1.3.6.4.1.4.1.2835.2.999021
:
.
2 Language
Language is represented in the CCR data set as a coded description, and would typically specified only as text. In CDA R2, the language is represented by a coded value using RFC-1766.
1 Conformance
45: The language shall be recorded as defined by the Care Record Summary.
2 Example
1 CDA-encoded
This example shows how the document identifier is represented in a CCD.
:
.
:
.
2 CCR-encoded
:
.
English
en-US
IETF1766
199503
.
:
3 Creation Date
46: The creation date shall be expressed as an exact date time with the explicit time zone offset recorded (Z shall not be used, rather +0000 or –0000).
1 Example
1 CDA-encoded
This example shows how the creation date is represented in CDA R2.
:
.
:
.
2 CCR-encoded
This example shows how the creation date is represented in the CCR data set.
:
.
Created
2005-03-03T17:15:04+0500
.
:
4 Patient
The patient is recorded in ClinicalDocument.recordTarget. Except in the extreme case of Siamese twins, the CCD will only record information about one patient.
1 Conformance
47: There shall be at least one instance and at most two instances of ClinicalDocument.recordTarget that identify the patient or patients for whom the CCR data set was created.
48: There shall be two instances of ClinicalDocument.recordTarget only when both patients are conjoined Siamese twins.
2 Example
1 CDA-encoded
This example shows how patient is represented in CDA R2.
17 Daws Rd.
Blue Bell
MA
02368
USA
Mrs.
Ellen
Ross
2 CCR-encoded
This example shows how patient is represented in CCR.
:
.
Patient-1
.
:
Patient-1
EllenRoss
Mrs. Ellen Ross
19600127
Female
12345
Good Health Clinic
Home
17 Daws Rd
Blue Bell
MA
02368
USA
Primary - Preferred
Active
(781)555-1212
Home
Primary - Preferred
Active
.
:
5 From
The "From" section of the CCR data set represents information about the creator of the data, including the person, application, and scoping organization. These are recorded as the author, assigned authoring device, and scoping organization of the author respectively in CDA R2.
1 Conformance
49: A CCD shall have at least one assignedAuthor.assignedPerson.
50: A CCD may have one or more assignedAuthor.assignedAuthoringDevice.
51: A CCD should have at least one assignedAuthor.representedOrganization.
2 Example
1 CDA-encoded
This example shows how various authors are represented in CDA R2.
21 North Ave
Burlington
MA
01803
USA
Bernard
Wiseman
Sr.
M.D.
Dr. Bernard Wiseman Sr.
Good Health Clinic
21 North Ave
Burlington
MA
01803
USA
21 North Ave
Burlington
MA
01803
USA
Good Health Clinic System v1.0
2 CCR-encoded
This example shows how the producer is represented in CCR.
:
.
From-1
From-2
From-3
.
:
.
:
From-1
Bernard
Wiseman
Sr.
M.D.
Dr. Bernard Wiseman Sr.
From-2
Good Health Clinic
M345
2.16.840.1.113883.3.933
Office
21 North Ave
Burlington
MA
01803
USA
(999)555-1212
Office
Primary - Preferred
Active
From-3
Good Health Clinic System v1.0
.
:
6 To
The "To" section of the CCR data set represents information about the proposed destination of the data, including persons, applications or organizations. These are recorded as the intended recipients of the information in the CDA R2.
1 Conformance
52: An intended recipient may be present.
7 Purpose
1 Conformance
8 CCR Footer
1 Actors
Within the CCR data set, an Actor is a , or . These correspond to the HL7 RIM Entity classes: LivingSubject, Person, Organization or Device, and are mapped accordingly to these classes as exposed in a CDA document.
17. CCR correspondence to CDA
|CCR data element |CDA R2 correspondence |Comments |
| | | |
| |Person | |
| | | |
| |Person.name |HL7: To represent the "Birth" name, include |
| | |qualifier='BR' on one of the name components.|
| |name.given | |
| |name.given |HL7: A middle name is a given name. By |
| | |convention, the middle name should be |
| | |recorded as a second given name. |
| |name.family | |
| |name.suffix | |
| |name.prefix | |
| |name.given qualifier='CM' |HL7: Use the qualifier attribute on the given|
| | |name to indicate the nickname. |
| |Person.name |HL7: As many names as neccesary can be |
| | |represented for any Person. |
| |Person.name |HL7: Can be represented using to indicate the legal name. |
| |Person.name |HL7: Can use just with no |
| | |subcomponents. |
| |patient.birthTime |HL7: Date of Birth is only present for the |
| |subject.relatedSubject.subject.birthTime |patient or subject. It is not used elsewhere|
| | |in the CDA. |
| |patient.administrativeGenderCode |ASTM: Value set limited to Male, Female, |
| |subject.administrativeGenderCode |Other and Unknown. |
| | |HL7: Gender is only present for the patient |
| | |or subject. It is not used elsewhere in the |
| | |CDA. HL7 AdministrativeGender vocabulary |
| | |covers Male, Female and Undifferentiated. |
| | |Need to extend this CWE domain to accommodate|
| | |the CCR value set. |
| |assignedAuthor.representedOrganization | |
| |assignedEntity.representedOrganization | |
| |intendedRecipient.recievedOrganization | |
| |associatedEntity.scopingOrganization | |
| |assignedAuthoringDevice | |
| |playingDevice | |
| |Entity.id |HL7: Entities and Roles can have |
| |Role.id |identifiers. Role identifiers are related to|
| | |a specific role, but entities may participate|
| | |in more than one role (and thus have more |
| | |than one identifier). However, CDA Release |
| | |2.0 does not usually allow for Persons to |
| | |have identifiers. The Care Record Summary |
| | |provides an extension that would allow |
| | |recording of an arbitrary identifier for a |
| | |person. |
| |Person.crs:asPatientRelationship |HL7: The relationship between the patient and|
| | |an actor cannot be specifically represented. |
| | |However, the Care Record Summary has provided|
| | |an extension (asPatientRelationship), which |
| | |accomodates this field. |
| |performer.functionCode | |
| |Role.address |HL7: Both roles and entities can have |
| | |addresses. Storing these on the Entity is |
| | |most closely aligned with the CCR notion of |
| | |an Actor, however CDA Release 2.0 often |
| | |limits storage of this information to Roles. |
| |Role.telecom |HL7: Both roles and entities can have |
| | |telephjone numbers. Storing these on the |
| | |Entity is most closely aligned with the CCR |
| | |notion of an Actor, however CDA Release 2.0 |
| | |often limits storage of this information to |
| | |Roles |
| |Role.telecom |HL7: Both roles and entities can have e-mail |
| | |addresses. Storing these on the Entity is |
| | |most closely aligned with the CCR notion of |
| | |an Actor, however CDA Release 2.0 often |
| | |limits storage of this information to Roles |
| |Role.telecom |HL7: Both roles and entities can have web |
| | |addresses. Storing these on the Entity is |
| | |most closely aligned with the CCR notion of |
| | |an Actor, however CDA Release 2.0 often |
| | |limits storage of this information to Roles |
| |None | |
| |None | |
2 Conformance
3 ASTM CCR Mapping
CCD Body
Prototype Section
NOTE: This section will be removed from the document. It is here to ensure consistency between the sections as they are developed by different editors.
• Section
[General introduction to the section, described mainly in narrative. Needs to define the scope of the section as precisely as possible.]
o Section conformance
[Conformance rules for the section, using formal conformance verbs. Includes section cardinality and section.code value at a minimum. May also give guidance on section.title.]
o Clinical statement conformance
[Conformance rules for the entries, using formal conformance verbs. Things not specifically precluded are allowed. Include a figure that is a subset of the CDA Clinical Statement model containing those classes being constrained or referred to ]
o Extensions
[Extensions to the model are summarized here.]
o ASTM CCR Mapping
[Use the definition tables from the CCR appendix for the scope of mapping. Add columns for CDA R2 correspondence and for comments. Include comments relevant to mapping in either direction.]
• break out common section conformance rules, such as Keith's recommendations for section.title:
o Section.title SHALL be present and shall contain text.
o Section.title SHALL indicate the content of the section in the langage
o specified in ClinicalDocument.languageCode.
o Section.title SHALL NOT conflict with Section.code.
• include all the CCR sections (at a minimum, include the stuff in CRS, even where we haven't gone into detail about the level 3 stuff in the body)
CCR Body Data Objects are listed in the table below. Within a CDA Document, these correspond most closely to sections, or in some cases, specific portions of the CDA header. Clinical data about the patient is found in sections of the CDA, whereas administrative data (providers, payers, demographics, et cetera), can be found in the header of the CDA document. The table below illustrates this division of information.
18. CCR Body Elements and their correspondence to CDA
|CCR data element |CDA R2 correspondence |Comments |
| |ClinicalDocument.participant |HL7: See CRS: 2.2.9.2 |
| |section |HL7: See CRS: 3.3.3 |
| |ClinicalDocument.participant |HL7: See CRS: 2.2.9.1 |
| |section |HL7: See CRS: 3.3.5 |
| |section |HL7: See CRS: 3.2.1 |
| |section |HL7: See CRS: 3.3.6 |
| |section |HL7: See CRS: 3.3.7 |
| |section |HL7: See CRS: 3.2.2 |
| |section |HL7: See CRS: 3.2.3 |
| |section | |
| |section |HL7: See CRS: 3.3.8 |
| |section |HL7: See CRS: 3.3.13 |
| |section |HL7: See CRS: 3.3.15 |
| |section |HL7: See CRS: 3.3.9 |
| |section |HL7: See CRS: 3.3.10 |
| |section |HL7: See CRS: 3.3.16 |
| |serviceEvent.performer |HL7: See CRS: 2.2.10, L1-57 |
1 Payers
19. CCR correspondence to CDA
|CCR data element |CDA R2 correspondence |Comments |
| |participant | |
| | | |
| |participant.associatedEntity.scopingOrganization | |
| |participant.time | |
| |participant.functionCode |HL7: The vocabulary for |
| | |ParticipantFunction is CWE, and can |
| | |further define the function of the |
| | |participant (HLD), (e.g., holder of |
| | |a PPO Insurance policy) |
| |participant.associatedEntity.associatedPerson | |
| |participant.associatedEntity.id | |
| |Can be modeled through an Act where the type of act is | |
| |Authorization (Act.code = AUTH). | |
| |Not modeled |HL7: The source of information from |
| | |the header is explicitly from the |
| | |author, an informant, or the subject|
| | |of the clinical document. |
| |None | |
| |None | |
| |None | |
2 Support
20. CCR correspondence to CDA
|CCR data element |CDA R2 correspondence |Comments |
| | | |
| |participant | |
| | | |
| | | |
3 Healthcare Providers
21. CCR correspondence to CDA
|CCR data element |CDA R2 correspondence |Comments |
| | | |
| |performer | |
| |performer.assignedEntity.id | |
| |performer. assignedEntity.code | |
4 Functional Status
5 Problems
This section contains the conditions (problems) for the patient that may require management activities.
53: This section SHALL comply to all conformance statements for Section Conformance in the CCD
54: This section SHALL be present, and SHALL NOT be present more than once.
55: Section.code SHALL be valued with LOINC 11450-4 (PROBLEM LIST).
56: If present, the section SHALL include section.title, which SHOULD be valued with a text string containing the document language equivalent of "Problem List".
1 Clinical statement conformance
Error! Reference source not found. shows a subset of the Clinical Statement model for Conditions containing those classes being constrained or referred to in the conformance statements that follow. Other portions of the model may be used (e.g. participations such as authorship), but are not included in the figure since there are no constraints currently defined for them. In addition, the SPRT ActRelationship below ConditionNode may reference any Act that is related to the management of the condition in any way.
1. Clinical Statement Model for Conditions
57: [pic]
58: At least one “Condition Structure” SHALL be present in the section, even if no conditions are present.
59: Condition SHALL include Contition.classCode, which SHALL be valued with "COND".
60: Condition SHALL include Contition.moodCode, which SHALL be valued with "EVN".
61: Condition SHALL include Condition.id, which SHALL be valued with a UUID that is at least unique to the document.
62: Condition SHALL include Condition.code, which SHALL be valued with the HL7 Vocabulary Domain “ “ value set xxxx and other values MAY be included as translations.
63: Condition SHALL include Condition.value, which SHALL be valued with HL7 “Flavors of Null” or with the HL7 Vocabulary Domain “ ” value set xxxx and other values MAY be included as translations..
64: Condition SHALL include Condition.statusCode, which SHALL be valued with the HL7 Vocabulary Domain “ActStatus” value set xxxx.
65: Condition SHALL include Condition.effectiveTime. If statusCode is valued “Active,” only the “low value = ‘’ ” attribute in the datatype will be populated with a time.
66: Condition MAY include Condition.methodCode which SHALL be valued with the HL7 Vocabulary Domain “DecisionObservationMethod” value set xxxx.
67: “Supporting Information Reference” May be included and when included SHALL include the “Condition Node Structure” and SHALL include one or both: a reference to any Act related to the management of the condition; an external reference via the ActRelationship “ELNK.”
68:
2 Extensions
There are no extensions to the CDA R2 model for Allergies and Adverse Reactions.
3 ASTM CCR Mapping
22. CCR correspondence to CDA
|CCR data element |CDA R2 correspondence |Comments |
| |Section | |
| | | |
| |effectiveTime |Both ASTM and HL7 define methods for exact DateTime, approximate |
| | |DateTime, and ranges. |
| |Observation.id | |
| |Condition.code |ASTM: Values include: Problem, Condition, Diagnosis, Symptom, |
| | |Finding, Complaint, Functional Limitation |
| | | |
| | |HL7: This field could hold similar values, but the vocabulary is |
| | |currently undefined. It is meant to hold the kind of assessment |
| | |that lead to the value in condition.value. LOINC and CPT are |
| | |among the candidate vocabularies. |
| |Condition.value |ASTM: Values listed include: Myocardial Infarction, Nausea, |
| | |Headache, Parkinson’s Disease, etc. and list ICD9, ICD10, SNOMED,|
| | |or both. |
| | | |
| | |HL7: This field is intended to hold similar values, but the |
| | |vocabulary is currently undefined. ICD, SNOMED, and NANDA are |
| | |among the candidate vocabularies. |
| |Condition.statusCode |ASTM: Active, Inactive, Chronic, Intermittent, Recurrent, Rule |
| | |Out, Ruled Out, Resolved |
| | | |
| | |HL7: Purely intended for management of the instance, e.g. Active,|
| | |Complete, etc. which correspond to Active and Resolved in ASTM. |
| | |Chronic, Intermittent, and Recurrent could be coordinated into |
| | |the vocabulary for value, In addition, truly recurrent conditions|
| | |(new instances of condition) would be modeled with the Succeeds |
| | |ActRelationship as in 1st pregnancy, 2nd pregnancy, or perhaps |
| | |multiple instance of acute bronchitis. Acute exacerbations of |
| | |chronic can also be modeled in HL7 as “sub-conditions” under |
| | |chronic. |
| |ELINK |ASTM: Used when recurrent or repetitive problems, etc, rather |
| | |than listing a problem multiple times in the problem list for |
| | |each episode. |
| | | |
| | |HL7: Used to link to previous ConditionNodes belonging to the |
| | |same episode of illness. Focuses on Episode of Illness rather |
| | |than Episode of Care. Need to work out the exact semantics of |
| | |mappings. |
| on each |Modifier on each Condition.value |ASTM: Alive & Well; In Remission; Symptom Free; Ill; Chronically |
|Problem | |Ill; Severely Ill; Critical; Terminal; Disabled; Severely |
| | |Disabled; Deceased (used in Family History) all of which may be |
| | |modified by |
| | | |
| | |HL7: This roughly maps to a potential modifier vocabulary for |
| | |Condition.value when SNOMED is used or for use of the Severity |
| | |observation (when ICD is used) or even |
| | |Condition.interpretationCode. HL7 uses a system of “instance |
| | |versions” to track the values of condition attributes over time. |
| | |Another approach is to make this an entirely separate assessment |
| | |observation in itself which can be tracked over time. |
|Child of HealthStatus |Attribute on Entity |ASTM: defines if this condition was the cause of death of the |
| | |actor to whom this condition applies. Values are “Yes” “No” and |
| | |“Unknown.” |
| | |HL7: This would be a separate observation in HL7 or a modifier if|
| | |using SNOMED. |
| |Participation.awarenessCode |ASTM: Yes; No; Unkown. Patient |
| | |Request Not to Know; Family Request for Patient Not to Know; |
| | |Durable Power Request for Patient Not to Know. |
| | | |
| | |HL7: Needs a vocabulary set bound to a vocabulary domain for |
| | |Participation.awarenessCode that goes on the subject or |
| | |recordTarget participations. |
4 Example
1 Rendered
This example shows how an allergy section might be rendered.
| | | |
| | | |
2 CDA-encoded
This example shows how the rendered results above can be represented in CDA R2.
Problems
Onset
Condition Severity
Condition Type
Condition
HealthStatus
PatientKnowledge
Comments
11/2004
Severe
Diagnosis
Asthma
Chronically Ill
Yes
Adequate control
11/2004,
Severe
Diagnosis
Asthma
Chronically Ill
Yes
Adequate control
Begins the nesting that links Condition to supporting management actions
hydrocortisone 10mg tabs
3 CCR-encoded
This example shows how the rendered results above can be represented in ASTM CCR XML markup.
BB0001
Date of Onset
2004-01-09T05:00:00Z
Diagnosis
Diagnosis
Myocardial Infarction
22298006
SNOMED CT
2005
Acuity
Acute
53737009
SNOMED CT
2005
Site
Anterioseptal
20706007
SNOMED CT
2005
410.1
ICD-9 CM
2004
Resolved
75307
Primary Care Provider
2
Age At Onset
35
Years
Resolved
75307
Primary Care Provider
75307
Primary Care Provider
6 Family History
This section contains data defining the patient’s blood or genetic relatives in terms of possible or relevant health risk factors that have a potential impact on the patient’s healthcare risk profile.
69: This section SHOULD contain all family history that has a potential impact on the patient’s healthcare risk profile.
1 Section conformance
70: This section MAY be present, and SHALL NOT be present more than once.
71: If present, the section MAY include organizer elements, one for each family member and the problems associated with that member.
72: If present, the section SHALL include Section.code, which SHALL be valued with LOINC 10157-6 (HISTORY OF FAMILY MEMBER DISEASES).
73: Section.title SHALL be present and shall contain text that SHALL indicate the content of the section in the language specified in ClinicalDocument.languageCode. Section.title SHALL NOT conflict with Section.code
74: Section subject participant SHALL NOT be used.
75: A clinicalStatement choice box subject participant SHALL be used to represent a family member.
2 Clinical statement conformance
Figure 2 shows a subset of the CDA Clinical Statement model containing those classes being constrained or extended and are referred to in the conformance statements that follow. Note that the subject participant associated with the CDA Clinical Statement is a shadow (exact duplicate) of the subject associated with the CDA Section class. For the sake of clarity of figure 1, the original class was associated with the CDA Clinical Statement (the two forms are semantically equivalent). Therefore, the subject model is constrained at the Section level in the same way it is constrained at the Clinical Statement level. In the CDA model, The Section subject participant is used to describe a patient's relative so that all data within this section relates to that relative. Nevertheless, the section titled "Family History" SHALL NOT be present more than once (see Error! Reference source not found.) thus relatives SHALL be identified only through the Clinical Statement subject participant and the Section subject participant SHALL NOT be used (see Error! Reference source not found.).
The model in figure 2 is for illustration purposes and thus only two entries (acts) and two act relationships were included in the clinicalStatement choice box as theses classes are the ones that were actually used in this version of the mapping. Nevertheless, all entries of the clinicalStatement choice box are available in CCD implementation guide.
Supporting the construction of a pedigree graph:
The model in figure 2 doesn't support the construction of a pedigree graph which is needed for risk assessment purposes commonly used in genetic counseling of certain diseases (e.g., breast and ovarian cancers). A graph structure (typically a hierarchy with the exception of intermarriages for example) in HL7 can be represented in different ways such as a recursive data structure or the inclusion of mother and father ids for each relative. Each of the various options we have identified has disadvantages and in this release of the CCD Implementation Guide, these options are discussed separately (appendix 6.2) and the issue will be resolved in the next release of this guide. This resolution will also be based on the results of the harmonization of the HL7 Clinical Genomics Family History Model and the HL7 Clinical Statement effort which also has machinery for representing relatives of a patient.
2. CDA R2 clinical statement model for family history
(constrained and extended)
[pic]
76: If Organizer is present, Organizer.classCode SHALL be valued with the code "CLUSTER".
77: If Organizer is present, Organizer.statusCode SHALL be valued with the code "completed".
78: If RelatedSubject is present, RelatedSubject.id SHALL be valued with the ActorID.
79: If RelatedSubject is present, RelatedSubject.classCode SHALL be valued with the code "PRS".
80: If RelatedSubject is present, RelatedSubject.code SHOULD be valued with one of the codes in the domain "FamilyMember (FAMMEMB)" (id= S17926) of the HL7 Vocabulary "RoleCode", in accordance with the relation of the RelatedSubject (relative) to the patient.
81: If RelatedSubject is present, RelatedSubject.addr MAY be valued with the addresses of the patient's relative.
82: If RelatedSubject is present, RelatedSubject.telecom MAY be valued with the telephone numbers of the patient's relative.
83: If SubjectPerson is present, SubjectPerson.name MAY be valued with the names of patient's relative.
84: If SubjectPerson is present, SubjectPerson.administrativeGenderCode SHOULD be valued with the gender of patient's relative.
85: If SubjectPerson is present, SubjectPerson.birthTime SHOULD be valued with the birth time of patient's relative.
3 Extensions
o There is a need for a deceasedInd attribute in the SubjectPerson class and it was added to this class in the constrained/extended model presented in figure 2. In addition to the boolean indicator, the deceasedTime was added as well.
o The CCR ActorID does not have a corresponding attribute so an id attribute was added to the RelatedSubject class.
o Mother and father ids for each relative are discussed in detail in an appendix of this document.
o The issue of representing ages in HL7 might require extensions in codes, attributes or data types:
o In particular, the CCR "Age At Onset" is, in HL7 language, the estimated age of a subject of an act (e.g., observation) at the effective time of that act.
o An attempt to represent age through the effectiveTime attribute is being pursued.
o In the current CDA encoding included in this document, the following SNOMED code was used along with the original text in CCR which is "Age At Onset":
o The way age data is modeled it in the Clinical Genomics Family History spec is by using a class (clone) name dedicated to that age observation. A few comments on the CG model:
▪ Appropriate codes drawn from a recognized controlled terminology are still missing;
▪ Most of the use cases have age intervals (e.g., the patient says that her aunt was diagnosed with cancer sometime in her forties);
▪ Adding age attributes to the RIM was proposed by the Clinical Genomics SIG to RIM harmonization but got rejected.
4 ASTM CCR Mapping
23. CCR correspondence to CDA
|CCR data element |CDA R2 correspondence |Comments |
| |Section | |
| |Organizer |ASTM: is optional and bound to one |
| | |instance (0..1). The child element |
| | | is required and unbounded (1..*)|
| | |and contains data defining the patient’s blood or |
| | |genetic relatives in terms of possible or relevant risk|
| | |factors. Nevertheless, per the CCR implementation |
| | |guide, each FamilyProblemHistory can only hold one |
| | |family member. |
| | | |
| | |HL7: If there are multiple FamilyProblemHistory |
| | |elements in CCR they should all nest within a single |
| | |"Family History" section in CDA. The organizer element |
| | |in CDA holds multiple problems for a family member, |
| | |thus it is mapped to the CCR FamilyProblemHistory |
| | |element. |
|< CCRDataObjectID > |Organizer.id |HL7: This CCR element identifies all data about a |
| | |family member and is mapped to the organizer.id |
| | |attribute. |
| | |CCRDataObjectID is required and thus organizer.id |
| | |cardinality is constrained from 0..* to 1..1 in the |
| | |constrained model. |
| |Observation or Condition |HL7: This CCR element should be modeled in CDA after |
| | |the Problems section in this document. |
| | | |
| | |NOTE: holding the age of the subject at diagnosis (CCR:|
| | |"Age At Onset") is currently done by associating an age|
| | |observation to the diagnosis observation and place the |
| | |age in its value attribute (see the CDA sample below |
| | |and the age discussion in the extensions section |
| | |above). |
| |subject |ASTM: ) is a link to an through |
| |RelatedSubject |an of type xs:string. must |
| |SubjectPerson |include an . |
| | | |
| | |HL7: The CCR FamilyMember is represented in HL7 by an |
| | |entity (SubjectPerson) who is playing a role |
| | |(RelatedSubject) that participates (subject) in an act |
| | |(the problem). See details in the following |
| | |sub-elements. |
| |No correspondence in the current CDA |HL7: There is no correspondence in CDA to ActorID |
| |model. |because there is no id attribute in the RelatedSubject |
| | |nor in the SubjectPerson class. Nevertheless, an id was|
| | |added to RelatedSubject in the extended model. The |
| | |ActorID value SHALL be placed in this id attribute (see|
| | |Error! Reference source not found.). |
| |RelatedSubject.code |ASTM: Each should reflect |
| | |the of that to the .|
| | | |
| | |HL7: ActorRole has two key elements: code and text. |
| | |These elements are mapped to the sub-components of the |
| | |RelatedSubject.code attribute (see below). |
| |RelatedSubject.code.code |ASTM: The CCR sample doesn't show the use of this |
| | |attribute. |
| | | |
| | |HL7: This attribute is controlled by an HL7 vocabulary |
| | |– see Error! Reference source not found. in this |
| | |document. |
| |RelatedSubject.inalText |HL7: The originalText sub-component of the |
| | |RelatedSubject.code attribute can hold the text element|
| | |of ActorRole. |
| |No correspondence in the current CDA |ASTM: HealthStatus is part of . Note |
| |model. |that under the CCR can record the |
| | |current health status relative to this problem as well |
| | |as if the problem was or was not the and|
| | |a Time Of Death as a under . |
| | | |
| | |HL7: Added the deceasedInd and deceasedTime attributes |
| | |to the SubjectPerson class to explicitly indicate |
| | |health status. In the current CDA encoding, this piece |
| | |of data is represented by an observation of death which|
| | |is associated with a CAUS entryRelationship to the |
| | |diagnosis observation (see in the sample). |
| | |In CCR, in order to indicate that a specific problem |
| | |was the cause of death you need to populate the |
| | | element with a code like |
| | |"Indication" (see page 50 in CCR and note that this |
| | |list of enumerated values is not yet in place). In the |
| | |CDA-encoded XML below it was assumed that the CCR |
| | |sample indicates the problem of Myocardial Infarction |
| | |is the cause of death, jus for the purpose of |
| | |illustration. |
5 Example
1 Rendered
This example shows how the Family History section might be rendered. Note that it is based on the CCR sample data along with additional data items which were added to illustrate the case of multiple family members (mother was added) and multiple problems for each family member (a second problem for the father).
FAMILY HISTORY
Family Member: Father; Status: deceased
|Diagnosis |Age At Onset |
|Myocardial Infarction |57 |
|Hypertension |40 |
Family Member: Mother; Status: alive
|Diagnosis |Age At Onset |
|Asthma |30 |
2 CDA-encoded
This example shows how the rendered Family History above can be represented in CDA R2, following the CCR Family History section.
Family history
Family Member: Father; Status: deceased
Diagnosis
Age At Onset
Myocardial Infarction
57
Hypertension
40
Family Member: Mother; Status: alive
Diagnosis
Age At Onset
Asthma
30
Myocardial Infarction
Age At Onset
Hypertension
Age At Onset
Age At Onset
3 CCR-encoded
___________
____
________
Father
Deceased
Yes
____
____
Diagnosis
Diagnosis
Myocardial Infarction
22298006
SNOMED CT
20050131
1
_____________
Age At Onset
57
Years
____
____
____
7 Social History
8 Allergies and Adverse Reactions
This section contains the allergy or intolerance conditions and the associated adverse reactions suffered by the patient.
86: This section SHALL comply to all conformance statements for Section Conformance in the CCD
87: This section SHALL be present, and SHALL NOT be present more than once.
88: Section.code SHALL be valued with LOINC 10155-0 (HISTORY OF ALLERGIES).
89: If present, the section SHALL include section.title, which SHOULD be valued with a text string containing the document language equivalent of "Allergies and Adverse Reactions".
1 Clinical statement conformance
Error! Reference source not found. shows a subset of the Clinical Statement model for the Allergies and Adverse Reactions Section containing those classes being constrained or referred to in the conformance statements that follow. Other portions of the model may be used (e.g. participations such as authorship), but are not included in the figure since there are no constraints currently defined for them. “Interventions” as noted in the CCR are added in the conformance statements as if they were present in Figure 2.
These Conformance Statements should be consistent with the following table from the HL7 Care Provision Domain for the AllergyIntolerance clinical statement model.
A_AllergyIntolerance (REPC_RM000320)
Diagram
Link to wide graphic (opens in a new window)
Description
|Parent: |Care Provision (REPC_DM000000) |
AllergyIntolerance Structure
The AllergyIntolerance Structure is a collection of classes that represent the allergic conditions, the intolerances, and the adverse reactions that occur because of these conditions in a living subject.
This structure is used to support the creation of implementation guides for messages, documents, services, and rules. More detail on the definitions and use of this structure may be found in the reference document, “Explanations and Guidance for the Care Provision Domain.”
AllergyIntolerance Structure Walk-through:
AllergyIntoleranceStructure Overview:
The AllergyIntolerance Structure includes a collection of classes including Observation, Substance Administration, and Control Acts. It also includes modeling of materials and numerous Act Relationships. These will be described in detail here, beginning with the Act classes.
The definitions for class attributes are available in Reference Information Model (RIM) documentation and will not be repeated here. However, the description of the attribute meaning in a message or other communication after the constraints are applied will be described for each class attribute. For a full description of the application of various constraints, please see the associated RIM documentation. A short synopsis is included for ease of reference:
Structural Attribute: attribute that is constrained to “immutable,” i.e. constrained from being changed once the instance is created. The list of these attributes is documented in the RIM.
Mandatory Attribute: bolded attribute means that the field/association must be present in the message (or other implementation guide), otherwise the message is invalid and is non-conformant. For Mandatory fields, HL7 sets the minimum cardinality to 1 (a value must be present) and set the additional requirement that the attribute shall not be valued with HL7 Flavors of Null
Required Attribute: * attribute which places a constraint on the sending system. If the data is available to the sending system, then the field/association is included in the message. If the minimum cardinality is 0 and the data is not available, the field/association may be omitted from the message and still be conformant. If the minimum cardinality is 1 and the data is not available, a NullFlavor is required.
Optional Attribute: (0…1) attribute without a * may or may not be present in a message (check the specific qualified meaning of this notation when found with a * in the “Required Attribute” definition above).
Datatype: a specification for the information model of the attribute value, often a complex pattern that builds upon the traditional computer science ontology of “primitive datatypes,” e.g. string; float; real number; etc.
Vocabulary Domain: an attribute constraint that allows implementation guides to bind a specific set of codes (value set) to a specific attribute.
X_Value Set: an attribute constraint that blocks implementation guides from extending or constraining the named value set in the diagrams by binding other HL7 value sets to the attribute.
CWE: an attribute whose vocabulary domain may be extended by codes outside a value set published in an implementation guide
CNE: an attribute whose vocabulary domain shall not be extended by codes outside a value set published in an implementation guide
AllergyIntolerance Classes
24. Clone Name: AllergyIntolerance
|Attribute |Constraint |Constrained Attribute Description |
|classCode |Immutable: Yes |A mandatory attribute constrained to Condition (COND),|
| |Optionality: B* (1…1) |which is a subclass of Observation (OBS)—see Care |
| |Datatype: CS |Provision Domain Explanation and Guidance for the |
| |Vocabulary Domain: |implications of this constraint. |
| |CNE =COND | |
|moodCode |Immutable: Yes |A mandatory attribute which is constrained to the |
| |Optionality: B* (1…1) |values in the X_Value Set that the Clinical Statement |
| |Datatype: CS |Pattern has decided to allow in the completion of the |
| |Vocabulary Domain: |Business Cycle of Acts. |
| |CNE | |
| |=X_ClinicalStatement-ObservationMood | |
|id |Immutable: Yes |A required attribute that shall be present and shall |
| |Optionality: * (1…*) |be valued with NullFlavor or an id; multiple id’s may |
| |Datatype: SET |be present. Updates may add id’s to the set, but may |
| |Vocabulary Domain: |not change an id. |
| |Not Applicable | |
|code |Immutable: No |A mandatory attribute constrained to the types of |
| |Optionality: B* (1…1) |intolerances from which a living subject may suffer |
| |Datatype: CD |e.g. medication, food, and environmental types of |
| |Vocabulary Domain: |allergies and other sensitivities. The specific value |
| |CWE [pic]
[pic]
[pic]
[pic]
[pic]
[pic]
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- 3d design something
- 2019 toyota highlander design change
- product design website
- design something online
- design your own monogram free
- design your own tea towel
- design your dream house virtual
- 3d virtual home design free
- design a virtual house free
- design things online for free
- 2020 toyota highlander design change
- design something for free