Upload
others
View
6
Download
0
Embed Size (px)
Citation preview
A Gordon Point Informatics Ltd. eHealth Integration Specification
gpi
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard
Part II - Consolidated CDA Implementation Guide
Document Type Health Information Specification
Version & Status 1.35.00 Revision 3 (DSTU (Revision 2013))
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
Version: 1.35.00 Status: DSTU (Revision 2013) ii Printed: October 15, 2013
Copyright © 2012, 2013 BC Physician Information Technology Office, All rights reserved,
This Document and any associated technical files (“Artifacts”) form part of a set of specifications, collective called the Materials. The Materials are subject to change and the BC Physician Information Technology Office (PITO) reserves the right to periodically update the information in the Materials. It is necessary that you ensure that the version of the Materials being consulted is the most current available as of that date.
The Materials are provided "as is" without warranties or conditions of any kind either expressed or implied. To the fullest extent possible under applicable law, the BC Physician Information Technology Office, its staff, agents and contractors disclaim all warranties and conditions, expressed or implied, including but not limited to, implied warranties or conditions of merchantability and fitness for a particular purpose, non–infringement or other violation of rights.
PITO does not warrant or make any other representations regarding the use, accuracy, timelines, applicability, performance, security, availability or reliability of these Materials, or the results from the use of the Materials, or otherwise respecting the content in the Materials. Under no circumstances, including, but not limited to, negligence, shall PITO be liable for any direct, indirect, special, punitive, incidental, or consequential damages arising out of the use of, or the inability to use, the Materials and/or their contents.
The Materials contain information for which copyright is held by Health Level Seven, Inc. Implementers of the standards (those developing software or otherwise making use of the specification) are required to be members of either Health Level Seven Inc., HL7 Canada (through the Infoway Standards Collaborative) or one of the other HL7 affiliates. There is no such membership requirement for individuals and organizations which merely install or use software with built–in HL7 interfaces.
HL7® is registered trademark of Health Level Seven, Inc. (http://www.hl7.org)
The Materials may contain information for which copyright is held by Canada Health Infoway.
The Materials may include portions of SNOMED CT®. SNOMED CT® was originally created by The College of American Pathologists. “SNOMED” and “SNOMED CT” are registered trademarks of the International Health Terminology Standards Organization.
This material may include portions of LOINC®, originally created by Regenstrief Institute Inc. All rights reserved.
All other trademarks or registered marks belong to their respective owners.
Questions about this Document should be addressed to:
BC Physician Information Technology Office 1665 West Broadway Suite 250 Vancouver, BC V6J 5A4 See http://www.pito.bc.ca for additional contact information.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
Version: 1.35.00 Status: DSTU (Revision 2013) iii Printed: October 15, 2013
AUTHORITIES
Approved By Role & Approval Responsibilities Status
Jeremy Smith Executive Director (Project Sponsor) Approved
Carol Rimmer Director, Provincial Program Office Approved
EDITORS
Marc Koehn, Gordon Point Informatics ([email protected]);
Helen Stevens, Gordon Point Informatics ([email protected]).
AUTHORS
Marc Koehn, Gordon Point Informatics ([email protected]);
Helen Stevens, Gordon Point Informatics ([email protected]).
Iryna Roy, Gordon Point Informatics ([email protected])
Patrick Loyd, Gordon Point Informatics ([email protected]).
Iqbal Sian, Gordon Point Informatics ([email protected]).
RELEASE LOG
Ver. Status Release Date Notes
1.0 Preliminary Review Version 2012-04-12 Draft for external review with gaps as noted in the Known Issues section.
1.1 Draft Standard for Trial Use (DSTU)
2012-06-14 Baseline DSTU suitable for Generic Episodic Document implementation (further refinements to other document types pending)
1.2 Draft Standard for Trial Use (DSTU) – Revised
2012-07-13 Updated examples
1.30.00 DSTU (Revision 2013) 2013-06-18
Substantial corrections based on implementor feedback; inclusion of Nanaimo IDP referral project changes; creation of new templates to support 2013/2014 IDP initiatives.
1.35.00 DSTU (Revision Fall 2013) 2013-10-14 Revisions to address implementer feedback.
Document Control Version/Status 1.35.00 Revision 3 (DSTU (Revision 2013))
Publication Date Oct 15, 2013
Distribution/Audience PITO & Stakeholders
Keywords CDA Implementation Guide HL7 eHealth Data Exchange Standard GPi Generated
File PITO E2E-DTC - Part II - Consolidated Implementation Guide - v1-35-00 - 20131015
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
Version: 1.35.00 Status: DSTU (Revision 2013) iv Printed: October 15, 2013
ACKNOWLEDGMENTS
The editors and authors of this document would like to acknowledge the following individuals and groups
for their contribution to the development of the original specifications:
Group Participants
The PITO Management team who provided oversight and support throughout the duration of the project.
Jeremy Smith
Carol Rimmer
The E2E Clinician Panel whose members provided clinical requirements and guidance.
Anita Basic
Dr. Rob Carruthers
Dr. Bill Clifford
Dr. Bruce Hobson
Cathy Korn
Trina Langille
Dr. Willie Pewarchuck
Dr. Andre du Toit
Dr. Andre de Wit
The E2E Vendor Panel whose members provided technical and business requirements and guidance from an Electronic Medical Record (EMR) vendor perspective.
Rachel Barker (Intrahealth Canada Limited)
Shamir Mithani (Intrahealth Canada Limited)
Jack Pannekoek (Med Access Inc.)
Toni Foster (Osler Systems)
Sean Hillier (Wolf Medical Systems)
The extended GPi project team which provided subject matter expertise and support to the core design and authoring group.
Dr. Ray Simkus
Bradley MacDonald
Dr. Karim Keshavjee
.. and other GPi team members
Other stakeholders who took the time to review the materials and to kindly provide feedback.
The HL7 Structured Document group as well as the HL7/IHE Health Story Consolidation Project (http://www.healthstory.com/standards/sec/consolidate.htm) whose HL7 Implementation Guide for CDA® Release 2: IHE Health Story Consolidation, Release 1 - US Realm guide provided the inspiration for the creation of a consolidated CDA Implementation Guide and on whose format and structure this guide is broadly based and from which this guide has liberally repurposed content..
In addition, thanks must go to the various implementation projects and, particularly, the UBC/UVIC Lead
Lab team under the direcition of Dr. Morgan Price for providing thoughtful feedback on the June 2012
baseline version.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
Version: 1.35.00 Status: DSTU (Revision 2013) v Printed: October 15, 2013
Table of Contents
1.0 INTRODUCTION ....................................................................................................... 17
1.1 Purpose .......................................................................................................................................... 17 1.2 Governance and Maintenance ....................................................................................................... 17 1.3 Audience ........................................................................................................................................ 17 1.4 Scope ............................................................................................................................................. 18 1.5 Prerequisites .................................................................................................................................. 19 1.6 Caveats and Assumptions ............................................................................................................. 19 1.7 Specification Structure ................................................................................................................... 20 1.8 Organization of This Guide ............................................................................................................ 21 1.9 Conformance .................................................................................................................................. 22 1.10 greenCDA ...................................................................................................................................... 22
2.0 SPECIFICATION CONVENTIONS ................................................................................. 23
2.1 Overview ........................................................................................................................................ 23 2.2 Conformance Verbs (Keywords) .................................................................................................... 23 2.3 CDA Document Sections ............................................................................................................... 23
2.3.1 CDA Document Levels .......................................................................................................... 24 2.4 Templates ...................................................................................................................................... 25
2.4.1 Template Types ..................................................................................................................... 26 2.4.2 Template Identification .......................................................................................................... 29 2.4.3 Originator Responsibilities (General Case) ........................................................................... 29 2.4.4 Recipient Responsibilities (General Case) ............................................................................ 30 2.4.5 Common Template Pattern(s) ............................................................................................... 30
2.5 Unstructured Document Requirements .......................................................................................... 30 2.6 Conformance Statements .............................................................................................................. 31
2.6.1 Conformance Statement Identification .................................................................................. 32 2.6.2 Existence & Cardinality Conformance ................................................................................... 33 2.6.3 Vocabulary Conformance ...................................................................................................... 33 2.6.4 Tabular View .......................................................................................................................... 35
2.7 XML Examples and Sample Documents ....................................................................................... 35 2.8 Cardinality ...................................................................................................................................... 36 2.9 Mandatory / Optional / Required .................................................................................................... 36 2.10 Null Flavor ...................................................................................................................................... 37 2.11 Data Types ..................................................................................................................................... 38 2.12 CDA Schemas ................................................................................................................................ 39
2.12.1 CDA Schema Files ................................................................................................................ 39 2.12.2 CDA Schema Extension ........................................................................................................ 40
2.13 Embedded Samples and Sample Instances .................................................................................. 40
3.0 GENERAL HEADER TEMPLATE .................................................................................. 41
3.1 BC PITO Standard Header ............................................................................................................ 41 3.1.1 Core Elements ....................................................................................................................... 41 3.1.2 Information Recipient [informationRecipient] ........................................................................ 43 3.1.3 Author [author] ....................................................................................................................... 45 3.1.4 Custodian Organization [custodian] ...................................................................................... 48 3.1.5 Patient [recordTarget] ............................................................................................................ 50 3.1.6 Personal Contact [participant] ............................................................................................... 52 3.1.7 Healthcare Participant [participant] ....................................................................................... 54 3.1.8 Legal Authenticator Participant [legalAuthenticator] ............................................................. 56 3.1.9 Authenticator Participant [authenticator] ............................................................................... 59 3.1.10 Data Enterer Participant [dataEnterer] .................................................................................. 62 3.1.11 Informant Participant [informant] ........................................................................................... 65
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
Version: 1.35.00 Status: DSTU (Revision 2013) vi Printed: October 15, 2013
3.1.12 Parent Document [relatedDocument] .................................................................................... 68 3.1.13 Encompassing Encounter [componentOf] ............................................................................. 70 3.1.14 Order Fulfillment [inFulfillmentOf] .......................................................................................... 74 3.1.15 Service Event [documentationOf] .......................................................................................... 75 3.1.16 Authorization & Consent [authorization] ................................................................................ 78
4.0 DOCUMENT TEMPLATES .......................................................................................... 86
4.1 EMR Conversion ............................................................................................................................ 86 4.2 Generic Episodic Document ........................................................................................................ 100 4.3 Generic Structured Referral ......................................................................................................... 112 4.4 Generic Unstructured Referral ..................................................................................................... 124 4.5 Patient Transfer ............................................................................................................................ 126 4.6 Unstructured Document ............................................................................................................... 138
5.0 SECTION TEMPLATES ............................................................................................ 140
5.1 Advance Directives [42348-3] ...................................................................................................... 143 5.2 Alerts [ALERTS] ........................................................................................................................... 145 5.3 Allergies & Intolerances - Reaction List [48765-2] ....................................................................... 147 5.4 Appointments & Scheduling [56446-8] ......................................................................................... 150 5.5 Billing [BILLING] ........................................................................................................................... 152 5.6 Care Plan / Reminders / Tasks [56851-9] .................................................................................... 153 5.7 Clinically Measured Observations [CLINOBS] ............................................................................. 155 5.8 Current Medications [19009-0] ..................................................................................................... 158 5.9 Developmental Observations [11334-0] ....................................................................................... 160 5.10 Devices [46264-8] ........................................................................................................................ 161 5.11 Encounter History & Notes [46240-8] .......................................................................................... 165 5.12 Family History [10157-6] .............................................................................................................. 167 5.13 Immunizations List [11369-6] ....................................................................................................... 171 5.14 Investigative Procedure History [INVPROC] ................................................................................ 175 5.15 Laboratory Results & Reports [30954-2] ...................................................................................... 178 5.16 Medical History [11348-0] ............................................................................................................ 182 5.17 Medical Imaging Results & Reports [55115-0] ............................................................................ 184 5.18 Medications & Prescriptions - Medication List [10160-0] ............................................................. 186 5.19 Orders & Requests [REQS] ......................................................................................................... 193 5.20 Problems & Conditions - Problem List [11450-4] ......................................................................... 195 5.21 Purpose [42349-1] ........................................................................................................................ 199 5.22 Reproductive Observations [56833-7] ......................................................................................... 200 5.23 Risk Factors [46467-7] ................................................................................................................. 202 5.24 Surgical Procedure History [10167-5] .......................................................................................... 204 5.25 Treatment History [62387-6] ........................................................................................................ 207 5.26 Unclassified Documents [46450-3] .............................................................................................. 210
6.0 SECTION ENTRY TEMPLATES ................................................................................. 213
6.1 Advanced Directives Observation ................................................................................................ 213 6.2 Alert Observation ......................................................................................................................... 218 6.3 Allergy & Intolerance Observation ............................................................................................... 221 6.4 Appointment Observation ............................................................................................................ 235 6.5 Billing Attachment ........................................................................................................................ 239 6.6 Care History Event ....................................................................................................................... 241 6.7 Clinically Measured Observations Organizer ............................................................................... 248 6.8 Developmental Observations Organizer ...................................................................................... 252 6.9 Device Observation ...................................................................................................................... 255 6.10 Encounter Event ........................................................................................................................... 259 6.11 Family History Observation .......................................................................................................... 267 6.12 Immunization Observation ........................................................................................................... 275 6.13 Laboratory Observation................................................................................................................ 286
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
Version: 1.35.00 Status: DSTU (Revision 2013) vii Printed: October 15, 2013
6.14 Medical Imaging Observation ...................................................................................................... 292 6.15 Medication Event .......................................................................................................................... 297 6.16 Order Event .................................................................................................................................. 312 6.17 Problem List Observation ............................................................................................................. 318 6.18 Reproductive Observations Organizer ......................................................................................... 328 6.19 Risk Factors Organizer ................................................................................................................ 332 6.20 Unclassified Documents Organizer .............................................................................................. 337
7.0 ENTRY TEMPLATES ............................................................................................... 340
7.1 Attachment ................................................................................................................................... 340 7.2 Author Participation ...................................................................................................................... 344 7.3 Comment Observation ................................................................................................................. 346 7.4 Date Observation ......................................................................................................................... 349 7.5 Dispense Request (first fill) .......................................................................................................... 351 7.6 Dispense Request (part fill) .......................................................................................................... 353 7.7 Dispense Request (refill) .............................................................................................................. 355 7.8 Dose Observation ........................................................................................................................ 357 7.9 Encapsulated Data ....................................................................................................................... 361 7.10 Informant Participation ................................................................................................................. 366 7.11 Instruction Observation ................................................................................................................ 368 7.12 Lifestage Observation .................................................................................................................. 370 7.13 Location Participation ................................................................................................................... 372 7.14 Medication Administration Event .................................................................................................. 373 7.15 Medication Dispense Event ......................................................................................................... 378 7.16 Medication Fill Interval ................................................................................................................. 382 7.17 Medication Identification............................................................................................................... 383 7.18 Medication Prescription Event ..................................................................................................... 387 7.19 Order Indicator ............................................................................................................................. 394 7.20 Outcome Observation .................................................................................................................. 396 7.21 Performer Participation ................................................................................................................ 400 7.22 Provider Participation ................................................................................................................... 402 7.23 Qualifier Observation ................................................................................................................... 404 7.24 Reaction Observation ................................................................................................................... 406 7.25 Reason Observation .................................................................................................................... 409 7.26 Record ID Link ............................................................................................................................. 413 7.27 Result Component ....................................................................................................................... 414 7.28 Result Organizer .......................................................................................................................... 420 7.29 Secondary Code (Drug) ............................................................................................................... 422 7.30 Secondary Code (ICD-9).............................................................................................................. 423 7.31 Secondary Code (Unbound) ........................................................................................................ 424 7.32 Severity Observation .................................................................................................................... 426 7.33 Status Changes Audit Event ........................................................................................................ 427 7.34 Unbound Observation .................................................................................................................. 431
8.0 DATA TYPES ......................................................................................................... 433
8.1 Overview ...................................................................................................................................... 433 8.2 Implementation Considerations ................................................................................................... 435
8.2.1 Use of the ANY Data Type in Question / Response Structures .......................................... 435 8.3 Data Type Constraint Templates ................................................................................................. 436
8.3.1 Address (AD) pan-Canadian Data Type ............................................................................. 436 8.3.2 Coded With Equivalents (CE) pan-Canadian Data Type .................................................... 437 8.3.3 Concept Descriptor (CD) pan-Canadian Data Type ............................................................ 438 8.3.4 Encapsulated Data (ED) pan-Canadian Data Type ............................................................ 439 8.3.5 Identifier (II) pan-Canadian Data Type ................................................................................ 440 8.3.6 Person Name (PN) pan-Canadian Data Type ..................................................................... 441 8.3.7 Physical Quantity (PQ) pan-Canadian Data Type ............................................................... 442
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
Version: 1.35.00 Status: DSTU (Revision 2013) viii Printed: October 15, 2013
8.3.8 Telecom (TEL) pan-Canadian Data Type ........................................................................... 442 8.3.9 TimeStamp Interval (IVL_TS) pan-Canadian Data Type .................................................... 443
9.0 VOCABULARY ....................................................................................................... 444
9.1 Overview ...................................................................................................................................... 444 9.2 External References ..................................................................................................................... 444 9.3 ValueSet References ................................................................................................................... 445 9.4 Code Systems .............................................................................................................................. 477
10.0 IDENTIFIERS ......................................................................................................... 479
10.1 Background .................................................................................................................................. 479 10.2 Use of OIDs .................................................................................................................................. 480
10.2.1 Vocabulary ........................................................................................................................... 480 10.2.2 Instance Identifiers .............................................................................................................. 480
10.3 Assigned Identifiers ...................................................................................................................... 483 10.4 Implementer Assigned Identifiers ................................................................................................. 483 10.5 Governance .................................................................................................................................. 483 10.6 Instance Identifier OIDs................................................................................................................ 484
APPENDIX A KNOWN ISSUES & INSTABILITIES .............................................................. 485
APPENDIX B GLOSSARY & ABBREVIATIONS ................................................................. 487
B.1. Introduction .................................................................................................................................. 487 B.2. Specific Terms & Abbreviations ................................................................................................... 487
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
Version: 1.35.00 Status: DSTU (Revision 2013) ix Printed: October 15, 2013
List of Figures
Figure 1: Specification Structure ................................................................................................................. 20 Figure 2: Template Hierarchy ...................................................................................................................... 21 Figure 3: Template Relationships ............................................................................................................... 26 Figure 4: templateId element example XML ............................................................................................... 26 Figure 5: Document section constraints example with XML ....................................................................... 28 Figure 6: Conformance Statement Identifier Example ................................................................................ 32 Figure 7: Existence & Cardinality Conformance Example .......................................................................... 33 Figure 8: Existence & Cardinality Conformance Example .......................................................................... 33 Figure 9: Existence & Cardinality Conformance Example .......................................................................... 34 Figure 10: Example of <code> with nullFlavor where Originating System does not have a coded value .. 34 Figure 11: Example of <code> with nullFlavor where Originating System does not support codes ........... 34 Figure 12: Tabular Element View Example ................................................................................................. 35 Figure 13: Format of XML Examples .......................................................................................................... 35 Figure 14: nulFlavor Example ..................................................................................................................... 38 Figure 15: CDA Schema Overview ............................................................................................................. 39 Figure 16: Document/Header Core Elements entry example ..................................................................... 43 Figure 17: Information Recipient entry example ......................................................................................... 45 Figure 18: Author entry example ................................................................................................................. 48 Figure 19: Custodian Organization entry example ..................................................................................... 49 Figure 20: Patient entry example ................................................................................................................ 52 Figure 21: Personal Contact entry example ................................................................................................ 54 Figure 22: Healthcare Participant entry example ........................................................................................ 56 Figure 23: Legal Authenticator Participant entry example .......................................................................... 59 Figure 24: Authenticator Participant entry example .................................................................................... 62 Figure 25: Data Enterer Participant entry example ..................................................................................... 65 Figure 26: Informant Participant entry example .......................................................................................... 68 Figure 27: BC PITO Standard Header entry example ................................................................................ 85 Figure 28: Information Recipient nullFlavor example ................................................................................. 87 Figure 29: EMR Conversion entry example ................................................................................................ 97 Figure 30: Generic Episodic Document entry example ............................................................................ 110 Figure 31: Generic Structured Referral entry example ............................................................................. 122 Figure 32: Generic Unstructured Referral entry example ......................................................................... 126 Figure 33: Patient Transfer entry example ................................................................................................ 135 Figure 34: Unstructured Document entry example ................................................................................... 139 Figure 35: Advance Directives [with entries] entry example ..................................................................... 145 Figure 36: Alerts [with entries] entry example ........................................................................................... 147 Figure 37: Allergies & Intolerances (Reaction List) [with entries] entry example ...................................... 150 Figure 38: Appointments & Scheduling [with entries] entry example ....................................................... 151 Figure 39: Billing [with entries] entry example .......................................................................................... 153 Figure 40: Care Plan / Reminders / Tasks [without entries] entry example .............................................. 154 Figure 41: Clinical Measured Observations [with entries] entry example ................................................ 157 Figure 42: Current Medications [with entries] entry example .................................................................... 159 Figure 43: Developmental Observations [with entries] entry example ..................................................... 161 Figure 44: Devices [with entries] entry example ....................................................................................... 164 Figure 45: Encounter History & Notes [with entries] entry example ......................................................... 167 Figure 46: Family History [with entries] entry example ............................................................................. 171 Figure 47: Immunizations List [with entries] entry example ...................................................................... 175 Figure 48: Investigative Procedure History [with entries] entry example .................................................. 178 Figure 49: Laboratory Results & Reports [with entries] entry example .................................................... 182 Figure 50: Medical History [with entries] entry example ........................................................................... 184 Figure 51: Medical Imaging Results & Reports [with entries] entry example ........................................... 186 Figure 52: Medications & Prescriptions - Medication List [with entries] entry example ............................ 193
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
Version: 1.35.00 Status: DSTU (Revision 2013) x Printed: October 15, 2013
Figure 53: Orders & Requests [with entries] entry example ..................................................................... 195 Figure 54: Problems & Conditions - Problem List [with entries] entry example ........................................ 199 Figure 55: Purpose entry example ............................................................................................................ 200 Figure 56: Reproductive Observations [with entries] entry example ........................................................ 202 Figure 57: Risk Factors [with entries] entry example ................................................................................ 204 Figure 58: Surgical Procedure History [with entries] entry example ......................................................... 207 Figure 59: Treatment History [with entries] entry example ....................................................................... 210 Figure 60: Unclassified Documents [with entries] entry example ............................................................. 212 Figure 61: Advanced Directives Observation entry example .................................................................... 218 Figure 62: Alert Observation entry example ............................................................................................. 221 Figure 63: Example “Allergies not reviewed” ............................................................................................ 223 Figure 64: Example “Allergies Reviewed & None Identified” .................................................................... 223 Figure 65: Example “Allergies Reviewed & None Identified – structured data” ........................................ 224 Figure 66: Allergy & Intolerance Observation entry example ................................................................... 235 Figure 67: Appointment Observation entry example ................................................................................ 239 Figure 68: Billing Attachment entry example ............................................................................................ 241 Figure 69: Care History Event entry example ........................................................................................... 248 Figure 70: Clinically Measured Observations Organizer entry example ................................................... 252 Figure 71: Developmental Observations Organizer entry example .......................................................... 255 Figure 72: Device Observation entry example .......................................................................................... 258 Figure 73: Encounter Event entry example ............................................................................................... 267 Figure 74: Example “SNOMED CT® Diagnosis” ...................................................................................... 269 Figure 75: Example “ICD9 Diagnosis” ...................................................................................................... 269 Figure 76: Example “Other Coding System Diagnosis” ............................................................................ 270 Figure 77: Family History Observation entry example .............................................................................. 275 Figure 78: Immunization Observation entry example ............................................................................... 286 Figure 79: Example Anatomic Pathology Report Result value ................................................................. 287 Figure 80: Laboratory Observation entry example ................................................................................... 292 Figure 81: Medical Imaging Observation entry example .......................................................................... 297 Figure 82: Medication Model ..................................................................................................................... 299 Figure 83: Medication Event entry example .............................................................................................. 312 Figure 84: Order Event entry example ...................................................................................................... 318 Figure 85: Example “SNOMED CT® Diagnosis” ...................................................................................... 320 Figure 86: Example “ICD9 Diagnosis” ...................................................................................................... 320 Figure 87: Example “Other Coding System Diagnosis” ............................................................................ 320 Figure 88: Problem List Observation entry example ................................................................................. 327 Figure 89: Reproductive Observations Organizer entry example ............................................................. 332 Figure 90: Risk Factors Organizer entry example .................................................................................... 336 Figure 91: Unclassified Documents Organizer entry example .................................................................. 339 Figure 92: Attachment entry example ....................................................................................................... 344 Figure 93: Author Participation entry example .......................................................................................... 346 Figure 94: Comment Observation entry example ..................................................................................... 349 Figure 95: Date Observation entry example ............................................................................................. 351 Figure 96: Dispense Request (first fill) entry example .............................................................................. 353 Figure 97: Dispense Request (part fill) entry example .............................................................................. 355 Figure 98: Dispense Request (refill) entry example .................................................................................. 357 Figure 99: Dose Observation entry example ............................................................................................ 361 Figure 100: Example attachment embedded in document ....................................................................... 363 Figure 101: Example attachment included in message wrapper .............................................................. 363 Figure 102: Example attachment referenced by URL ............................................................................... 363 Figure 103: Example attachment referenced by absolute location ........................................................... 364 Figure 104: Example attachment referenced by relative location ............................................................. 364 Figure 105: Unique file reference example ............................................................................................... 364 Figure 106: Encapsulated Data entry example ......................................................................................... 366 Figure 107: Informant Participation entry example ................................................................................... 368
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
Version: 1.35.00 Status: DSTU (Revision 2013) xi Printed: October 15, 2013
Figure 108: Instruction Observation entry example .................................................................................. 370 Figure 109: Lifestage Observation entry example .................................................................................... 371 Figure 110: Location Participation entry example ..................................................................................... 373 Figure 111: Medication Administration Event entry example .................................................................... 378 Figure 112: Medication Dispense Event entry example ........................................................................... 382 Figure 113: Medication Fill Interval entry example ................................................................................... 383 Figure 114: Medication Identification entry example ................................................................................ 387 Figure 115: Medication Prescription Event entry example ....................................................................... 394 Figure 116: Order Indicator entry example ............................................................................................... 396 Figure 117: Outcome Observation entry example .................................................................................... 400 Figure 118: Performer Participation entry example .................................................................................. 402 Figure 119: Provider Participation entry example ..................................................................................... 404 Figure 120: Qualifier Observation entry example ..................................................................................... 406 Figure 121: Reaction Observation entry example .................................................................................... 409 Figure 122: Reason Observation entry example ...................................................................................... 412 Figure 123: Record ID Link entry example ............................................................................................... 414 Figure 124: Result Component entry example ......................................................................................... 420 Figure 125: Result Organizer entry example ............................................................................................ 421 Figure 126: Secondary Code (Drug) entry example ................................................................................. 423 Figure 127: Secondary Code (ICD-9) entry example ............................................................................... 424 Figure 128: Secondary Code (Unbound) entry example .......................................................................... 426 Figure 129: Severity Observation entry example ...................................................................................... 427 Figure 130: Status Changes Audit Event entry example .......................................................................... 431 Figure 131: Unbound Observation entry example .................................................................................... 432 Figure 132: Address (AD) pan-Canadian Data Type entry example ........................................................ 437 Figure 133: Coded With Equivalents (CE) pan-Canadian Data Type entry example ............................... 438 Figure 134: Concept Descriptor (CD) pan-Canadian Data Type entry example ...................................... 439 Figure 135: Encapsulated Data (ED) pan-Canadian Data Type entry example ....................................... 440 Figure 136: Identifier (II) pan-Canadian Data Type entry example .......................................................... 441 Figure 137: Person Name (PN) pan-Canadian Data Type entry example ............................................... 441 Figure 138: Physical Quantity (PQ) pan-Canadian Data Type entry example ......................................... 442 Figure 139: Telecom (TEL) pan-Canadian Data Type entry example ...................................................... 442 Figure 140: TimeStamp Interval (IVL_TS) pan-Canadian Data Type entry example ............................... 443 Figure 1: ISO OID Hierarchy ..................................................................................................................... 479
List of Tables
Table 1: Document Specifications by Use Case ......................................................................................... 22 Table 2: Cardinality Examples .................................................................................................................... 36 Table 3: Conformance Terms and Keywords ............................................................................................. 36 Table 4: nullFlavor codes ............................................................................................................................ 37 Table 5: CDA Schema Extensions .............................................................................................................. 40 Table 6: Core Elements Constraints Overview ........................................................................................... 41 Table 7: Information Recipient [informationRecipient] Constraints Overview ............................................. 43 Table 8: Author [author] Constraints Overview ........................................................................................... 45 Table 9: Custodian Organization [custodian] Constraints Overview........................................................... 48 Table 10: Patient [recordTarget] Constraints Overview .............................................................................. 50 Table 11: Personal Contact [participant] Constraints Overview ................................................................. 52 Table 12: Healthcare Participant [participant] Constraints Overview ......................................................... 54 Table 13: Legal Authenticator Participant [legalAuthenticator] Constraints Overview................................ 56 Table 14: Authenticator Participant [authenticator] Constraints Overview ................................................. 59 Table 15: Data Enterer Participant [dataEnterer] Constraints Overview .................................................... 62 Table 16: Informant Participant [informant] Constraints Overview ............................................................. 65 Table 17: Parent Document [relatedDocument] Constraints Overview ...................................................... 68
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
Version: 1.35.00 Status: DSTU (Revision 2013) xii Printed: October 15, 2013
Table 18: Encompassing Encounter [componentOf] Constraints Overview ............................................... 70 Table 19: Order Fulfillment [inFulfillmentOf] Constraints Overview ............................................................ 74 Table 20: Service Event [documentationOf] Constraints Overview ............................................................ 75 Table 21: Authorization & Consent [authorization] Constraints Overview .................................................. 78 Table 22: Template Containment for an EMR Conversion ......................................................................... 87 Table 23: Template Containment for a Generic Episodic Document ....................................................... 100 Table 24: Template Containment for a Generic Structured Referral ........................................................ 112 Table 25: Template Containment for a Generic Unstructured Referral .................................................... 125 Table 26: Template Containment for a Patient Transfer ........................................................................... 127 Table 27: Template Containment for an Unstructured Document ............................................................ 138 Table 28: Advance Directives [without entries] Template Context ........................................................... 143 Table 29: Advance Directives [with entries] Template Context ................................................................ 143 Table 30: Alerts [without entries] Template Context ................................................................................. 145 Table 31: Alerts [with entries] Template Context ...................................................................................... 146 Table 32: Allergies & Intolerances (Reaction List) [without entries] Template Context ............................ 148 Table 33: Allergies & Intolerances (Reaction List) [with entries] Template Context ................................. 149 Table 34: Appointments & Scheduling [with entries] Template Context ................................................... 150 Table 35: Billing [with entries] Template Context ...................................................................................... 152 Table 36: Care Plan / Reminders / Tasks [without entries] Template Context ......................................... 153 Table 37: Chronic Disease Capture Forms ............................................................................................... 155 Table 38: Clinical Measured Observations [without entries] Template Context ...................................... 155 Table 39: Clinical Measured Observations [with entries] Template Context ........................................... 156 Table 40: Current Medications [without entries] Template Context .......................................................... 158 Table 41: Current Medications [with entries] Template Context ............................................................... 159 Table 42: Developmental Observations [without entries] Template Context ............................................ 160 Table 43: Developmental Observations [with entries] Template Context ................................................. 160 Table 44: Devices [without entries] Template Context ............................................................................. 162 Table 45: Devices [with entries] Template Context................................................................................... 162 Table 46: Encounter History & Notes [without entries] Template Context ................................................ 166 Table 47: Encounter History & Notes [with entries] Template Context ..................................................... 166 Table 48: Family History [without entries] Template Context ................................................................... 169 Table 49: Family History [with entries] Template Context ........................................................................ 170 Table 50: Immunizations List [without entries] Template Context ............................................................ 173 Table 51: Immunizations List [with entries] Template Context ................................................................. 173 Table 52: Investigative Procedure History [without entries] Template Context ........................................ 176 Table 53: Investigative Procedure History [with entries] Template Context ............................................. 176 Table 54: Laboratory Results & Reports [without entries] Template Context ........................................... 179 Table 55: Laboratory Results & Reports [with entries] Template Context ................................................ 179 Table 56: Medical History [without entries] Template Context .................................................................. 182 Table 57: Medical History [with entries] Template Context ....................................................................... 183 Table 58: Medical Imaging Results & Reports [without entries] Template Context .................................. 184 Table 59: Medical Imaging Results & Reports [with entries] Template Context ....................................... 185 Table 60: Medications & Prescriptions - Medication List [without entries] Template Context .................. 191 Table 61: Medications & Prescriptions - Medication List [with entries] Template Context ....................... 192 Table 62: Orders & Requests [without entries] Template Context ............................................................ 193 Table 63: Orders & Requests [with entries] Template Context ................................................................. 194 Table 64: Problems & Conditions - Problem List [without entries] Template Context .............................. 197 Table 65: Problems & Conditions - Problem List [with entries] Template Context ................................... 197 Table 66: Purpose Template Context ....................................................................................................... 199 Table 67: Reproductive Observations [without entries] Template Context ............................................... 201 Table 68: Reproductive Observations [with entries] Template Context .................................................... 201 Table 69: Risk Factors [without entries] Template Context ...................................................................... 203 Table 70: Risk Factors [with entries] Template Context ........................................................................... 203 Table 71: Surgical Procedure History [without entries] Template Context ............................................... 205 Table 72: Surgical Procedure History [with entries] Template Context .................................................... 205
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
Version: 1.35.00 Status: DSTU (Revision 2013) xiii Printed: October 15, 2013
Table 73: Treatment History [without entries] Template Context .............................................................. 208 Table 74: Treatment History [with entries] Template Context ................................................................... 208 Table 75: Unclassified Documents [with entries] Template Context......................................................... 211 Table 76: Advanced Directives Observation Template Context ............................................................... 213 Table 77: Advanced Directives Observation Constraints Overview ......................................................... 213 Table 78: Alert Observation Template Context ......................................................................................... 218 Table 79: Alert Observation Constraints Overview ................................................................................... 219 Table 80: Allergy & Intolerance Observation Template Context ............................................................... 221 Table 81: Allergy & Intolerance Observation Constraints Overview ......................................................... 225 Table 82: Appointment Observation Template Context ............................................................................ 235 Table 83: Appointment Observation Constraints Overview ...................................................................... 235 Table 84: Billing Attachment Template Context ........................................................................................ 239 Table 85: Billing Attachment Constraints Overview .................................................................................. 240 Table 86: Care History Event Template Context ...................................................................................... 241 Table 87: Care History Event Constraints Overview ................................................................................ 241 Table 88: Clinically Measured Observations Organizer Template Context .............................................. 248 Table 89: Clinically Measured Observations Organizer Constraints Overview ........................................ 248 Table 90: Developmental Observations Organizer Template Context ..................................................... 252 Table 91: Developmental Observations Organizer Constraints Overview ............................................... 252 Table 92: Device Observation Template Context ..................................................................................... 255 Table 93: Device Observation Constraints Overview ............................................................................... 255 Table 94: Encounter Event Template Context .......................................................................................... 259 Table 95: PITO EMR-2-EMR Specification to HL7 v2.x ADT Mapping .................................................... 260 Table 96: Encounter Event Constraints Overview .................................................................................... 260 Table 97: Family History Observation Template Context ......................................................................... 267 Table 98: Family History Observation Constraints Overview ................................................................... 270 Table 99: Immunization Observation Template Context ........................................................................... 275 Table 100: Immunization Observation Constraints Overview ................................................................... 277 Table 101: Laboratory Observation Template Context ............................................................................. 286 Table 102: Laboratory Observation Constraints Overview ....................................................................... 288 Table 103: Medical Imaging Observation Template Context .................................................................... 292 Table 104: Medical Imaging Observation Constraints Overview .............................................................. 293 Table 105: Medication Event Template Context ....................................................................................... 297 Table 106: Medication Related Entry templates ....................................................................................... 298 Table 107: Medication Event Constraints Overview ................................................................................. 300 Table 108: Order Event Template Context ............................................................................................... 312 Table 109: Order Event Constraints Overview ......................................................................................... 314 Table 110: Problem List Observation Template Context .......................................................................... 318 Table 111: Problem List Observation Constraints Overview .................................................................... 322 Table 112: Reproductive Observations Organizer Template Context ...................................................... 328 Table 113: Reproductive Observations Organizer Constraints Overview ................................................ 328 Table 114: Risk Factors Organizer Template Context .............................................................................. 332 Table 115: Risk Factors Organizer Constraints Overview ........................................................................ 333 Table 116: Unclassified Documents Organizer Template Context ........................................................... 337 Table 117: Unclassified Documents Organizer Constraints Overview ..................................................... 337 Table 118: Attachment Template Context ................................................................................................ 340 Table 119: Attachment Constraints Overview ........................................................................................... 341 Table 120: Author Participation Template Context ................................................................................... 344 Table 121: Author Participation Constraints Overview ............................................................................. 344 Table 122: Comment Observation Template Context .............................................................................. 346 Table 123: Comment Observation Constraints Overview ......................................................................... 347 Table 124: Date Observation Template Context....................................................................................... 349 Table 125: Date Observation Constraints Overview ................................................................................. 350 Table 126: Dispense Request (first fill) Template Context ....................................................................... 351 Table 127: Dispense Request (first fill) Constraints Overview .................................................................. 351
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
Version: 1.35.00 Status: DSTU (Revision 2013) xiv Printed: October 15, 2013
Table 128: Dispense Request (part fill) Template Context ....................................................................... 353 Table 129: Dispense Request (part fill) Constraints Overview ................................................................. 353 Table 130: Dispense Request (refill) Template Context ........................................................................... 355 Table 131: Dispense Request (refill) Constraints Overview ..................................................................... 355 Table 132: Dose Observation Template Context ...................................................................................... 357 Table 133: Dose Observation Constraints Overview ................................................................................ 357 Table 134: Encapsulated Data Template Context .................................................................................... 361 Table 135: Encapsulated Data File Types ................................................................................................ 362 Table 136: Encapsulated Data Constraints Overview .............................................................................. 365 Table 137: Informant Participation Template Context .............................................................................. 366 Table 138: Informant Participation Constraints Overview ......................................................................... 367 Table 139: Instruction Observation Template Context ............................................................................. 368 Table 140: Instruction Observation Constraints Overview ........................................................................ 369 Table 141: Lifestage Observation Template Context ............................................................................... 370 Table 142: Lifestage Observation Constraints Overview .......................................................................... 371 Table 143: Location Participation Template Context ................................................................................ 372 Table 144: Location Participation Constraints Overview .......................................................................... 372 Table 145: Medication Administration Event Template Context ............................................................... 373 Table 146: Medication Administration Event Constraints Overview ......................................................... 374 Table 147: Medication Dispense Event Template Context ....................................................................... 378 Table 148: Medication Dispense Event Constraints Overview ................................................................. 378 Table 149: Medication Fill Interval Template Context ............................................................................... 382 Table 150: Medication Fill Interval Constraints Overview ......................................................................... 382 Table 151: Medication Identification Template Context ............................................................................ 383 Table 152: Medication Identification Constraints Overview ...................................................................... 384 Table 153: Medication Prescription Event Template Context ................................................................... 387 Table 154: Medication Prescription Event Constraints Overview ............................................................. 388 Table 155: Order Indicator Template Context ........................................................................................... 394 Table 156: Order Indicator Constraints Overview ..................................................................................... 395 Table 157: Outcome Observation Template Context ............................................................................... 396 Table 158: Outcome Observation Constraints Overview .......................................................................... 397 Table 159: Performer Participation Template Context .............................................................................. 400 Table 160: Performer Participation Constraints Overview ........................................................................ 400 Table 161: Provider Participation Template Context ................................................................................ 402 Table 162: Provider Participation Constraints Overview .......................................................................... 402 Table 163: Qualifier Observation Template Context ................................................................................. 404 Table 164: Qualifier Observation Constraints Overview ........................................................................... 404 Table 165: Reaction Observation Template Context ................................................................................ 406 Table 166: Reaction Observation Constraints Overview .......................................................................... 406 Table 167: Reason Observation Template Context .................................................................................. 409 Table 168: Reason Observation Constraints Overview ............................................................................ 410 Table 169: Record ID Link Template Context ........................................................................................... 413 Table 170: Record ID Link Constraints Overview ..................................................................................... 413 Table 171: Result Component Template Context ..................................................................................... 414 Table 172: Result Component Constraints Overview ............................................................................... 414 Table 173: Result Organizer Template Context........................................................................................ 420 Table 174: Result Organizer Constraints Overview .................................................................................. 420 Table 175: Secondary Code (Drug) Template Context ............................................................................ 422 Table 176: Secondary Code (Drug) Constraints Overview ....................................................................... 422 Table 177: Secondary Code (ICD-9) Template Context ........................................................................... 423 Table 178: Secondary Code (ICD-9) Constraints Overview ..................................................................... 423 Table 179: Secondary Code (Unbound) Template Context ...................................................................... 424 Table 180: Secondary Code (Unbound) Constraints Overview ................................................................ 425 Table 181: Severity Observation Template Context ................................................................................. 426 Table 182: Severity Observation Constraints Overview ........................................................................... 426
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
Version: 1.35.00 Status: DSTU (Revision 2013) xv Printed: October 15, 2013
Table 183: Status Changes Audit Event Template Context ..................................................................... 427 Table 184: Status Changes Audit Event Constraints Overview ................................................................ 428 Table 185: Unbound Observation Template Context ............................................................................... 431 Table 186: Unbound Observation Constraints Overview .......................................................................... 431 Table 187: Data Types .............................................................................................................................. 433 Table 188: Example Data Types in Question / Response Structures ...................................................... 436 Table 189: Address (AD) pan-Canadian Data Type Constraints Overview .............................................. 436 Table 190: Coded With Equivalents (CE) pan-Canadian Data Type Constraints Overview .................... 437 Table 191: Concept Descriptor (CD) pan-Canadian Data Type Constraints Overview ............................ 438 Table 192: Encapsulated Data (ED) pan-Canadian Data Type Constraints Overview ............................ 439 Table 193: Identifier (II) pan-Canadian Data Type Constraints Overview ................................................ 440 Table 194: Person Name (PN) pan-Canadian Data Type Constraints Overview ..................................... 441 Table 195: Physical Quantity (PQ) pan-Canadian Data Type Constraints Overview ............................... 442 Table 196: Telecom (TEL) pan-Canadian Data Type Constraints Overview ........................................... 442 Table 197: TimeStamp Interval (IVL_TS) pan-Canadian Data Type Constraints Overview .................... 443 Table 198: Incorporated External Vocabulary or Terminology Sources ................................................... 444 Table 199: ValueSet References & Bindings ............................................................................................ 445 Table 200: ActConsentType Definition ..................................................................................................... 447 Table 201: ActEncounterCode Definition .................................................................................................. 447 Table 202: ActOrderCode Definition ......................................................................................................... 447 Table 203: ActPriority Definition ................................................................................................................ 448 Table 204: ActStatus Definition ................................................................................................................. 448 Table 205: AdministerableDrugForm Definition ........................................................................................ 448 Table 206: AdministrativeGender Definition ............................................................................................. 449 Table 207: AdvanceDirectiveType Definition ............................................................................................ 449 Table 208: AlertDeviceType Definition ...................................................................................................... 450 Table 209: AlertType Definition ................................................................................................................. 450 Table 210: AllergenEntityCode Definition ................................................................................................. 450 Table 211: AllergyIntoleranceStatusCode Definition ................................................................................ 451 Table 212: AllergyTestValue Definition ..................................................................................................... 451 Table 213: AssignedEntityRoleCode Definition ........................................................................................ 452 Table 214: AttachmentObservationType Definition .................................................................................. 452 Table 215: CDAHeaderActClass Definition .............................................................................................. 452 Table 216: ClinicalDrug Definition ............................................................................................................. 453 Table 217: Clinically Measured Observations Codes Definition ............................................................... 453 Table 218: Developmental Observations Codes Definition ...................................................................... 453 Table 219: DiagnosisICD9CM Definition .................................................................................................. 453 Table 220: DiagnosisValuePrimary Definition ........................................................................................... 454 Table 221: DocumentType Definition ........................................................................................................ 454 Table 222: EncounterDischargeDisposition Definition .............................................................................. 454 Table 223: HealthcareProviderRoleType Definition .................................................................................. 455 Table 224: HumanLanguage Definition .................................................................................................... 455 Table 225: HumanSubstanceAdministrationSite Definition ...................................................................... 455 Table 226: IdentifierUse Definition ............................................................................................................ 456 Table 227: ImagingDetailObservationType Definition .............................................................................. 456 Table 228: ImagingProcedureObservationType Definition ....................................................................... 457 Table 229: InstructionTargetRole Definition .............................................................................................. 457 Table 230: ISO3166-1–CountryCodes Definition...................................................................................... 457 Table 231: ISO3166-2–State/Province Definition ..................................................................................... 458 Table 232: LifeStageObservationValue Definition .................................................................................... 458 Table 233: MaterialEntityClassType Definition ......................................................................................... 458 Table 234: MediaType Definition .............................................................................................................. 459 Table 235: ObservationInterpretation Definition ....................................................................................... 460 Table 236: ObservationInterpretationNormality Definition ........................................................................ 460 Table 237: ObservationMethod Definition ................................................................................................. 461
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
Version: 1.35.00 Status: DSTU (Revision 2013) xvi Printed: October 15, 2013
Table 238: ObservationValue Definition ................................................................................................... 461 Table 239: ParticipationFunction Definition .............................................................................................. 462 Table 240: ParticipationSignature Definition ............................................................................................. 462 Table 241: ParticipationType Definition .................................................................................................... 462 Table 242: PersonalRelationshipRoleType Definition .............................................................................. 463 Table 243: ProblemType Definition ........................................................................................................... 465 Table 244: Procedure Definition ............................................................................................................... 466 Table 245: ProviderRoleCode Definition ................................................................................................... 466 Table 246: ReactionTypeCode Definition ................................................................................................. 467 Table 247: ReasonObservationValue Definition ....................................................................................... 467 Table 248: Reproductive Observations Codes Definition ......................................................................... 467 Table 249: Reproductive Observations Organizer Codes Definition ........................................................ 468 Table 250: RiskFactorObservationType Definition ................................................................................... 468 Table 251: RoleClass Definition ................................................................................................................ 468 Table 252: RoleClassMutualRelationship Definition ................................................................................. 469 Table 253: RouteOfAdministration Definition ............................................................................................ 469 Table 254: ServiceDeliveryLocationRoleType Definition .......................................................................... 470 Table 255: UCUM Definition ..................................................................................................................... 471 Table 256: VaccineAdministeredNameCode Definition ............................................................................ 471 Table 257: x_ActRelationshipDocument Definition ................................................................................... 472 Table 258: x_ActStatusActiveComplete Definition ................................................................................... 472 Table 259: x_BasicAddressPartType Definition........................................................................................ 472 Table 260: x_BasicConfidentialityKind Definition ..................................................................................... 473 Table 261: x_BasicPersonNamePartQualifier Definition .......................................................................... 473 Table 262: x_BasicPersonNamePartType Definition ................................................................................ 473 Table 263: x_BasicPersonNameUse Definition ........................................................................................ 474 Table 264: x_BasicPostalAddressUse Definition ...................................................................................... 474 Table 265: x_BasicTelecommunicationsAddressUse Definition ............................................................... 475 Table 266: x_ComponentStartsBefore Definition ..................................................................................... 475 Table 267: x_EncounterParticipant Definition ........................................................................................... 475 Table 268: x_PhoneOrEmailURLScheme Definition ................................................................................ 476 Table 269: x_ServiceEventPerformer Definition ....................................................................................... 476 Table 270: Code Systems ......................................................................................................................... 477 Table 271: OID Tree ................................................................................................................................. 483 Table 272: Common Identifier OIDs ......................................................................................................... 484 Table 273: E2E Specification Stability Risks ............................................................................................ 485 Table 274: Internet Based Glossaries ....................................................................................................... 487 Table 275: Terms & Abbreviations ............................................................................................................ 487
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
17 DSTU (Revision 2013)
1.0 INTRODUCTION
1.1 PURPOSE
The Physician Information technology Office (PITO) EMR–to–EMR Data Transfer & Conversion Standard
(E2E–DTC) specifications support the standardized exchange of patient information between disparate
electronic medical record (EMR) systems in support of various business processes including single
patient chart transfers, conversions of multiple patient charts from one EMR to another as well as the
exchange of episodic documents.
The purpose of this Implementation Guide document is to provide formal, implementable specifications
for these information exchanges using the HL7 Clinical Document Architecture (CDA) 1. Specifically this
guide contains a portfolio of interrelated CDA templates to describe various documents using a common
set of information primitives. These primitives are also represented as CDA templates and arranged into
Section, Section-Entry and Entry groups.
1.2 GOVERNANCE AND MAINTENANCE
Governance and maintenance processes have not yet been established for these specifications.
However, it is currently anticipated that as and when the specifications will be finalized that these
processes will be established to ensure, among other things, that input from implementers as well as
newly emerging requirements can be duly considered and, where appropriate, incorporated into these
specifications in a timely and effective manner. Work to establish these processes is expected to
consider provisions pertaining to decision making, requirements/change tracking, the degree of backward
compatibility of changes, and any associated support arrangements that may be established.
1.3 AUDIENCE
The target audience for this document are those stakeholders seeking to establish standardized
information exchanges between and among electronic medical record (EMR) systems. This includes
customers, vendors of solutions, as well as agencies, such as PITO, charged either with the
establishment of standards, the validation of conformance to those standards, or policies pertaining to
eHealth standards and electronic data interchange.
Although the document is primarily directed at business analysts, software architects, and developers of
health information system (HIS) solutions, it is hoped that the form and content of these specifications
render them accessible to clinical and business professionals charged with evaluating these types of
specifications for business applicability.
1 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
18 DSTU (Revision 2013)
1.4 SCOPE
The scope of these specifications is constrained both in terms of the target use cases that are intended to
be supported, as well as the set of specific data categories to be incorporated in structured form. Please
consult the companion PITO EMR-to-EMR Data Transfer & Conversion Specification - Part I
Business Overview document for further elaboration of the business contexts in which these
specifications are intended to be used.
The technical approach for these specifications is constrained to clinical document representations of the
whole, or portions of, a single patient’s medical record for the purpose of exchange. The scope of
exchange includes supporting various non-specific episodic events in the care of the patient; transfer of
the (materially) complete patient chart as a single patient transfer; or in support of conversion of an entire
EMR system.
A clinical document is a defined as a complete information object that can include text, images, sounds,
and other multimedia content. The HL7 Clinical Document Architecture (CDA) defines a clinical
document as a documentation of clinical observations and services, with the following characteristics:
Persistence – A clinical document continues to exist in an unaltered state, for a time period defined
by local and regulatory requirements (NOTE: There is a distinct scope of persistence for a clinical
document, independent of the persistence of any XML-encoded CDA document instance).
Stewardship – A clinical document is maintained by an organization entrusted with its care.
Potential for authentication – A clinical document is an assemblage of information that is intended
to be legally authenticated.
Context – A clinical document establishes the default context for its contents.
Wholeness – Authentication of a clinical document applies to the whole and does not apply to
portions of the document without the full context of the document.
Human readability – A clinical document is human readable.
It should be noted that these characteristics provide a general context but do NOT necessarily apply
universally to all applications of the CDA data interchange paradigm; for example, in the case conversion
where a CDA document is used to represent an export of chart, the notions of stewardship, authentication
and, to a certain extent, human readability become less relevant, than the notions of persistence, context,
and wholeness.
Exchange of information between healthcare providers outside of this definition of a clinical document
(e.g. e-prescribing, e-ordering) is not within the scope of this specification.
The scope of this specification is to define the markup standard, structure and semantics for clinical
documents for the purposes of exchange; it does not address how documents are interchanged; nor does
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
19 DSTU (Revision 2013)
it consider any provisions for broader EHR-wide documentation management or the creation or
management of documents within an EMR system.
It is important to note that specifications of this type do establish functional demands on EMR systems to
the extent that these systems may need to structure data or be able to reliably transform data in a certain
way to enable compliance when sending or receiving information based on the specification. However,
other than this necessary and desirable side-effect, these specifications are not intended to establish
conformance requirements pertaining to EMR functionality.
1.5 PREREQUISITES
These specifications are based on and constraint as well as extend the HL7 Clinical Document
Architecture (CDA) Release 2 (R2) Standard. Although the specifications aim to provide sufficient detail
for implementers to build conformant solutions, readers are nevertheless assumed to have basic
familiarity with CDA, the HL7 Reference Information Model (RIM) and HL7 data types.
Further information on these health information standards and specification building blocks is available to
HL7 International or affiliate members at www.hl7.org. In Canada, the affiliate is established under the
auspices of the Infoway Standards Collaborative (https://www.infoway-inforoute.ca/standards).
1.6 CAVEATS AND ASSUMPTIONS
All examples are to be considered non–normative. If inconsistencies exist between the specification and
the examples, the specification supersedes the examples.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
20 DSTU (Revision 2013)
1.7 SPECIFICATION STRUCTURE
These specifications have been layered into multiple documents and technical artifacts which, together,
provide implementation direction and establish conformance requirements.
Figure 1: Specification Structure
This breakdown has been designed to minimize duplication and to streamline access to information for
prospective implementers. Moreover, recognizing that certain implementers will likely need to support
more than one of the identified use cases, these specification documents aim to offer an integrated view
for all three specifications.
Readers are advised to start their review with this Business Overview document.
This document is the Implementation Guide in this diagram.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
21 DSTU (Revision 2013)
Figure 2: Template Hierarchy
1.8 ORGANIZATION OF THIS GUIDE
This guide includes a portfolio of CDA Templates, and prescribes their use for a set of specific document
types. The main chapters are:
Specification Conventions. This chapter establishes and describes the conventions (e.g. special
notations and display formats) used in these specifications.
General Header Template: This chapter defines a template for the header constraints that apply
across all in-scope document types.
Document Level Templates. This chapter defines each of the supported document types. It defines
header constraints specific to each type as well as the Section templates established for each.
Section Level Templates. This
chapter defines the sections referenced
from the Document templates. Each
section will include reference to one or
more Section templates with alternate
requirements for the structure and
coding level within the section. Section
templates are independent specification
units that can be reused by future
document specifications. Section templates that do not support machine processable structured
entries will not reference a Section-Entry template.
Section-Entry Level Templates. This chapter defines the Section-Entry templates referenced by
the Section templates. Each Section-Entry template defines the entry level requirements for a
machine processable structured section and may reference one or more Entry templates for specific
data structures. All Section-Entry templates start with the Section/Entry CDASchema XPath and
are referenced from a Section template.
Entry Level Templates. This chapter defines the Entry templates referenced by the Section-Entry
templates. Each Entry template defines a specific clinical statement that is a re-usable machine
processable structure.
Data Types. This chapter outlines data type conformance expectations and other implementation
considerations pertaining to these specifications.
Vocabulary. This chapter outlines vocabulary conformance expectations and other implementation
considerations pertaining to these specifications.
This guide also contains several appendices which include non-normative content to support
implementers.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
22 DSTU (Revision 2013)
1.9 CONFORMANCE
This standard has been designed to enable customers to seek and vendors to claim conformance to one
or more of the following document specifications:
Table 1: Document Specifications by Use Case
Use Case Group Target Specifications
Conversion EMR Conversion Document Specification;
Transfer Patient Transfer Document Specification;
Episodic / Workflow Support
General Generic Episodic Document Specification;
Unstructured Document Specification;
Referral Generic Unstructured Referral Document Specification; and
Generic Structured Referral Document Specification.
Each of these document specifications establishes a specific set of conformance requirements either
implicitly through reference to the HL7 standard or explicitly through this Implementation Guide and
associated technical artifacts.
Please refer to Chapter 2 – Specification Conventions for further information on how conformance
requirements are documented and how these should be interpreted in the specification.
The first four specifications formed part of the initial publication while the two Generic Referral document
specifications build on the core templates. Please consult the applicable document-template specific
sections in this guide for futher information about each individual document.
1.10 GREENCDA
HL7 is currently exploring mechanisms to simplify its Implementation Technology Specifications (ITS).
One of these initiatives is the greenCDA project2 which is working to develop a pragmatic methodology
for creating simplified CDA schemas that can be transformed directly to or from normative CDA. At this
time these specifications have not taken a position on greenCDA and, consequently, no greenCDA
schema sets are included.
2 http://wiki.hl7.org/index.php?title=GreenCDA_Project
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
23 DSTU (Revision 2013)
2.0 SPECIFICATION CONVENTIONS
2.1 OVERVIEW
This chapter summarizes the key specification conventions in this implementation guide. It should be
reviewed prior to reading the rest of the guide. Readers familiar with the HL7 Implementation Guide for
CDA® Release 2: IHE Health Story Consolidation, Release 1 - US Realm guide published by the HL7
Structured Document group in collaboration with the HL7/IHE Health Story Consolidation Project3 will find
a significant degree of overlap in the conventions followed by both guides. Moreover, this guide has
repurposed substantial content from the HL7/IHE guide.
2.2 CONFORMANCE VERBS (KEYWORDS)
These specifications make intentional use of the formal keywords SHALL, SHALL NOT, SHOULD, SHOULD NOT,
MAY and NEED NOT which are to be interpreted as described in the HL7 Version 3 Publishing Facilitator's
Guide (http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm)4:
SHALL: an absolute requirement;
SHALL NOT: an absolute prohibition against inclusion;
SHOULD / SHOULD NOT: best practice or recommendation. There may be valid reasons to ignore an
item, but the full implications must be understood and carefully weighed before choosing a different
course; and
MAY / NEED NOT: truly optional; can be included or omitted as the author decides with no implications.
The subject of a conformance verb (keyword) in a top-level constraint is the template itself. In nested
constraints, the subject is the element in the containing constraint.
Conformance verbs may also be applied to other content in this guide that is intended to be normative.
Solutions claiming conformance with these specifications are required to adhere to the requirements so
identified.
2.3 CDA DOCUMENT SECTIONS
An HL7 Clinical Document Architecture (CDA) document is comprised of two parts, a header and a body.
The CDA document header identifies and classifies the document and provides information on
authentication, the encounter, the patient, and the involved providers etc. It is consistent in structure
across all CDA documents regardless of document type; however, different documents will support, or
require, different components of the document header.
3 http://www.healthstory.com/standards/sec/consolidate.htm
4 Please note that notwithstanding periodic review of HL7’s intellectual property policies, access to certain HL7 materials may
require registration and/or payment of membership/subscription fees.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
24 DSTU (Revision 2013)
The document body contains the clinical content, and can be a combination of unstructured content,
structured text and/or structured markup. Additional information on the CDA document section model
may be obtained from the HL7 5.
2.3.1 CDA Document Levels
The CDA standard describes conformance requirements in terms of three general levels corresponding to
three different, incremental types of conformance statements:
Document Header Level (CDA Level 1 or CDA-L1): This includes all the meta-data regarding the
document such as the document creation date/time; patient information, author, intended recipient
etc. The Document Header is based on discrete data elements, supported by appropriate coding and
vocabulary data sets. Any clinical observations or body content of a Level 1 document is a single part
and may be XML or an alternate allowed format (e.g. PDF). If XML, it must be CDA-conformant
markup.
Level 1 requirements impose constraints upon the CDA Header6.
Document Section Level (CDA Level 2 or CDA-L2): This type of document includes distinct body
sections for each type of clinical information such as medications, observations, alerts etc. Within
each section the content is represented as a single human-readable ‘text’ block or as an attachment
(e.g. PDF document, image, etc.).
Level 2 requirements specify constraints at the section level of a CDA XML document: most critically,
the section code and the cardinality of the sections themselves, whether optional or required.
Document Section Discrete Data (CDA Level 3 or CDA-L3): As for a Level 2 document, this type
of clinical document includes distinct body sections for each type of clinical information; however, in
addition to the human readable ‘text’ representation, the content of the section is also duplicated
through inclusion of discrete data elements. Each data element will have an associated data type
(address, code, identifier etc.) associated with it and where appropriate it will be coded using
standards-based terminologies.
Level 3 requirements specify constraints at the entry level within a section. A specification is
considered “Level 3” if it requires any entry-level templates.
Note that these levels are rough indications of what a recipient can expect in terms of machine-
processable coding and content reuse. They do not reflect the level or type of clinical content, and many
additional levels of reusability could be defined.
In all cases, required clinical content must be present. For example, a CDA Procedure Note carrying the
templateId that asserts conformance with Level 1 may use a PDF (portable document format) or HTML
5 http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7
6 Within the CDA R2 Standard, Level 1 is identified as an unconstrained CDA specification. However, in practice level 1 is
generally used to denote a document with a constrained header and an unstructured body.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
25 DSTU (Revision 2013)
(hypertext markup language) format for the body of the document that contains the required clinical
content. Conformance, in this case, to the clinical content requirements could not be validated without
human review.
The Document templates for each document type list the required and optional sections.
Each section of a CDA document can be either in the form of just free text or can also be defined to have
discrete data elements in addition to the free text representation.
2.4 TEMPLATES
This implementation guide is constructed using a template based model. Templates, in the HL7 context,
are a formal framework to document and re-use specific sets of constraints on an information model.
CDA supports the broad intent of the HL7 templates framework in order to support two objectives:
First, templates allow specification designers to segment the specification into components that can
be published and maintained as distinct entities.
Second, templates can be combined and reused to meet specific use cases and requirements.
Templates allow a concept (such as a reaction observation or prescription) to be defined once and then
used wherever that concept needs to be applied within the specification. By referencing templates and
combining them to meet the business requirements, specifications can be built that are both rich in
flexibility and function; but also optimized to improve consistency of implementation and increased ease
of maintenance.
There are two flavors of templates; those that constrain the document sections based on the type of
document and those that constrain the entries within document sections.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
26 DSTU (Revision 2013)
2.4.1 Template Types
In this implementation guide we have further refined the templates as follows:
Figure 3: Template Relationships
2.4.1.1 Document Templates
Document Templates define and constrain the sections supported for each type of document as well as
any constraints on the applicable header template.
For example, the EMR Conversion document template will specify that the header is constrained so as
not to support the Service Event, Order and Encompassing Encounter elements; and to support the
Billing section. Whereas the General Episodic Document template specifies that the Billing section is not
supported and that the Service Event and Encompassing Encounter header elements are optional.
Document templates are always identified using a ClinicalDocument/templateId element:
<ClinicalDocument classCode=”DOCCLIN” moodCode=”EVN”>
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<!-- Conforms to the BC PITO EMR Conversion Document specification -->
<templateId root="2.16.840.1.113883.10.20.22.1.1" assigningAuthorityName=”bcPITO”/>
...
</ClinicalDocument>
Figure 4: templateId element example XML
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
27 DSTU (Revision 2013)
2.4.1.2 Header Templates
Header Templates define and constrain the elements of the document header. Each Document Template
will reference a single Header Template that includes the appropriate header constraints for that
document type. Moreover, a Document Template may further refine that header.
2.4.1.3 Section Templates
Section Templates define and constrain the format of a CDA body section. There are three possible
flavours of Section template within this guide: Section with entries required (CDA-L3), Section with entries
disallowed (CDA-L2) and Section with entries allowed.
The Section Template will always start at the <Section> element. If entries are allowed (optional or
required) the applicable Section Template will have an <entry> component and a reference to the
Section-Entry template that is applicable to the section.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
28 DSTU (Revision 2013)
For example:
<section>
<templateId root="2.16.840.1.113883.3.1818.10.2.2.1"/>
<code code="42348-3"
displayName=" Advance Directives [with entries]"
codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
<title>Advance Directives</title>
<text>
...
</text>
<entry typeCode="DRIV">
<act classCode="ACT" moodCode="EVN">
<templateId root=" 2.16.840.1.113883.3.1818.10.3.1"/>
<!-- Advanced Directives Observation template -->
...
</act>
</entry>
</section>
Figure 5: Document section constraints example with XML
Indicates the whether a section SHALL, SHALL NOT or MAY be included.
Indicates the type of section template that SHALL, SHOULD or MAY be applied
Example template Object Identifier (OID) in a conforming document instance.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
29 DSTU (Revision 2013)
Section templates are independent specification elements that can be reused by future document
specifications. Note that section templates that do not support machine processable structured entries
(i.e. CDA Level 2 section templates) will not reference a Section-Entry template.
2.4.1.4 Section-Entry Templates
Section-Entry Templates define and constrain the format of a CDA-L3 body section. The Section
template will always start at the <Entry> element and may reference Entry templates if required.
2.4.1.5 Entry Templates
Entry Templates define reusable section components that may be called from another Entry template or a
Section-Entry template. Entry templates may start with any clinical statement entry point such as a
participation or act relationship (e.g. <entryRelationship> or <author>).
2.4.1.6 Data Type Templates
Data Type Templates define the constraints for compound data types supported by the specification and
is called by the Header, Section Entry and Entry Templates where compound data types are assigned to
data elements.
2.4.2 Template Identification
Template identifiers (templateId) are assigned to all templates including Document, Section, Section-
entry and Entry templates. When valued in an instance, the template identifier signals the imposition of a
set of template-defined constraints. The value of this attribute (e.g. <templateID
@root="2.16.840.1.113883.10.20.22.4.8"/>) provides a unique identifier for the template in
question.
Within the implementation guide, each template is documented in a distinct section. Following the
template name, the templates are identified using the following convention:
[template type: templateId OID (open/closed)]
Bracketed information following each template title indicates the template type (section, observation, act,
procedure, etc.), the templateId, and whether the template is open or closed.
2.4.2.1 Open and Closed Templates
In open templates, all of the features of the CDA R2 base specification are allowed except as constrained
by the templates. By contrast, a closed template specifies everything that is allowed and nothing further
may be included. Open templates allow implementers to develop additional structured content not
constrained within this guide.
2.4.3 Originator Responsibilities (General Case)
An originator can apply a templateId if there is a desire to assert conformance with a particular
template. In the most general forms of CDA exchange, an originator need not apply a templateId for
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
30 DSTU (Revision 2013)
every template to which an object in a document instance conforms. The implementation guide (IG) for a
particular interface shall assert whenever templateIds are required for conformance.
These specifications do establish the formal use and specification of a template in conformant
exchanges. In general, a templateId is to be included at the document, section and section entry
levels.
2.4.4 Recipient Responsibilities (General Case)
A recipient may reject an instance that does not contain a particular templateId (e.g., a recipient
looking to receive only Procedure Note documents can reject an instance without the appropriate
templateId).
A recipient may process objects in an instance document that do not contain a templateId (e.g., a
recipient can process entries that contain Observation acts within a Problems section, even if the
entries do not have templateIds).
These specifications do require that recipients that have declared their systems to be conformant with
one or more documents in this specification be able to accurately process all information in received
documents – particularly information that is defined in accordance with the templates established herein.
2.4.5 Common Template Pattern(s)
Although templates are intended to reflect a particular pattern or grouping of information, there are
situations where it may be advantageous to create distinct templates that follow the same pattern. The
following section(s) highlight(s) pattern(s) used in this guide.
2.4.5.1 Organizer-Grouped Observations
The Organizer-Grouped Observations template pattern supports situations where individual observations
are to be grouped (i.e. linked to a particular idea) through an Organizer Code. The purpose for defining
multiple templates that follow the same or a very similar pattern is that this allows specific Value-Sets to
be assigned to the Organizer Code and Observation Code elements that are appropriate for the use
cases which the specific template is targeted to address.
2.5 UNSTRUCTURED DOCUMENT REQUIREMENTS
This guide contains one or more unstructured or Level 1 CDA Document templates. These types of
documents may be used to communicate clinical information when the patient record is captured in an
unstructured format or when it is desirable to send information in an unstructured manner to
accommodate the capabilities of the targeted receiving system. In this scenario the clinical information is
typically represented and transmitted in a “blob” of data that may originate in a text file, an image file, a
word processing or a Portable Document Format (PDF) file, among others.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
31 DSTU (Revision 2013)
An Unstructured Document (UD) document type can (1) include unstructured content, such as a graphic,
directly in a text element with a mediaType attribute, or (2) reference a single document file, such as a
word-processing document, using a text/reference element.
The Unstructured Document model does not support all possible file formats and it excludes structured
formats such as generic XML. For a full list of generally supported HL7 media types please consult the
MediaType value set definition in the vocabulary chapter.
The CDA Data Types specification provides an extensible value set of MIME (Multipurpose Internet Mail
Extensions) media types that are supported by base CDA. Exclusions from and extensions to that list are
discussed below:
Media type exclusions. This guide restricts usage of media types listed in the CDA Data Types
specification for embedded content. In the absence of a use case for a video format as part of the
patient record, video formats are not included. However, an unstructured document can link to a
video or other file format using the reference data element; for example, a Microsoft Word file can
contain a link to a video.
Media type extensions. Although the CDA Data Types specification indicates that
‘application/msword’ should not be used, that format is very common in use cases that apply to
Unstructured Documents and this guide allows it. The usage applies only to documents in binary
format; it is not appropriate for rich text format (RTF) which has a separate MIME type, or the .docx
format from MS-Word version 2007 or later, which is not currently recommended for use in an
Unstructured Document.
Local policy. Some content formats, in particular, tagged-image file format (TIFF), entail further
complexity. While this guide allows TIFF because it is in common use, its variants introduce profound
interoperability issues and therefore this format is not currently recommended.
2.6 CONFORMANCE STATEMENTS
This specification document makes use of formal Conformance Statements in order to support the
implementation of the specification and to form a rigorous basis for conformance testing and any solution
certification.
The conformance statements are automatically generated from an underlying reference data model using
an algorithm that converts constraints recorded in the Reference Data Model to a printable presentation.
This presentation is materially consistent with the convention for documenting conformance statements in
implementation guides for the HL7 CDA standard.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
32 DSTU (Revision 2013)
2.6.1 Conformance Statement Identification
The conformance statements are numbered uniquely and linked to the data element to which they apply,
if multiple conformance statements apply to a single data element they will have an appropriate suffix
added that references a particular rule element. These identifiers are persistent but not sequential.
c
Figure 6: Conformance Statement Identifier Example
Please note the following:
Each conformance statement may have a sub-rule with a specific rule suffix identified after the period
in the conformance number. These rule suffix numbers are not sequential but reflect a particular rule
that has been applied;
Conformance statements pertaining to document specific header constraints are prefixed with “MAN-“
and represent their own numbering series;
Conformance statements pertaining to Section inclusion at the Document level are prefixed with
“SEC-“ and represent their own numbering series; and
Conformance statements within the Data Type Templates are prefixed with “DT-“ and represent their
own numbering series;
Persistent Conformance Statement Identifier
Persistent Conformance Statement Identifier – with rule suffix identifier
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
33 DSTU (Revision 2013)
2.6.2 Existence & Cardinality Conformance
Figure 7: Existence & Cardinality Conformance Example
A primary use of conformance statements is to express explicit expectations on the existence and
cardinality of various data elements. The existence and cardinality expectations expressed in this
implementation guide are typically tighter than the default expectations expressed by the CDA R2
standard. However, where the existence and cardinality conformance listed echoes that of CDA R2, the
keyword {CDAR2} is included in the statement.
2.6.3 Vocabulary Conformance
Formal specifications for value-set constraints are based on the latest recommendations from the HL7
Vocabulary Committee. Value-set constraints can be “STATIC,” meaning that they are bound to a
specified version of a Value-Set, or “DYNAMIC,” meaning that they are bound to the most current version of
a Value-Set. A simplified constraint is used when binding is to a single code.
Vocabulary conformance constraints will also indicate whether a coded field can only be sent using
values from the Value-Set (coded no extension or CNE) through use of the phrase “SHALL contain” or
whether a sending system may use another code in situations where no appropriate code exists within
the bound Value-Set (coded with extension or CWE) through use of the phrase “SHOULD contain”.
Notwithstanding the fact that a binding may be designated as “CWE” conformant systems SHALL always
send a code from the specified value-set when the concept being communicated exists in the value-set
unless stated otherwise in this implementation guide. In other words, extensions apply only to concepts
which are not represented in the value-set.
The following figure provides an example of the syntax for vocabulary binding to either DYNAMIC or STATIC
Value-Sets. It also shows how additional constraints may be specified that limit the permitted choices:
Figure 8: Existence & Cardinality Conformance Example
Conformance statements provide specific direction regarding the presence of XML elements and the number of repeats (cardinality)
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
34 DSTU (Revision 2013)
Syntax for vocabulary binding to a single code:
Figure 9: Existence & Cardinality Conformance Example
IF a system supports local codes for elements where this specification has designated a specific
CodeSystem and/or a specific ValueSet, then a conformant system SHALL map those local codes to the
equivalent designated codes and SHALL support the applicable conformant code when exporting or
importing a document conformant with this specification.
If a system does not support codes for an element where this specification requires a code, then the
system SHALL send a nullFlavor=”NI” for the Code as illustrated in the figure below.
<code nullFlavor="NI" displayName="Resuscitation">
Figure 10: Example of <code> with nullFlavor where Originating System does not have a coded value
In some templates, a <text> element has been provided to allow for the equivelant textual information to
be communicated as illustrated in the figure below.
<code nullFlavor="NI"/>
<text>DNR 4 (full resuscitation)</text>
Figure 11: Example of <code> with nullFlavor where Originating System does not support codes
Additional information on vocabulary binding has been included in the Vocabulary Chapter.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
35 DSTU (Revision 2013)
2.6.4 Tabular View
These specifications also incorporate tabular views of the individual elements to provide additional
business data in a more easily digestible format. These views are structured as follows:
Figure 12: Tabular Element View Example
2.7 XML EXAMPLES AND SAMPLE DOCUMENTS
XML examples appear in various figures in this document in this monospace font. Portions of the
required XML content may be omitted from each example for brevity; these omissions are marked by an
ellipsis (…) as shown in the example below:
<ClinicalDocument xmins='urn:h17-org:v3'>
...
<!-- An illustrative comment -->
</ClinicalDocument>
Figure 13: Format of XML Examples
Examples in this guide may also include XML comments. Except as noted, inclusion of these comments
in actual document instances is optional but recommended. In other words, in order to improve human
readability, systems sending conformant documents SHOULD include comments where appropriate and
SHALL include comments when explicitly directed by this implementation guide.
Links to the applicable conformance statement are provided
Business name and description columns are empty for structural / technical elements to reduce clutter and improve readability.
Data types are shown to highlight overrides or constraints
Business name and description columns provide more detail for business level elements
Existence & Cardinality Conformance is shown for convenience
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
36 DSTU (Revision 2013)
2.8 CARDINALITY
Cardinality rules exist for each section and each individual data element within a section. Cardinality
reflects the number of occurrences that may or must be provided for a particular section or element, and
is represented by a 0, 1, * or another number indicating the minimum cardinality, followed by two
periods and a *, 0, 1, or other number indicating the maximum cardinality. For example, 0..*
indicates a minimum cardinality of 0 and maximum cardinality of many.
The following table gives examples of the different types of cardinalities that may be defined for sections
and data elements:
Table 2: Cardinality Examples
Cardinality Description
0..1 The section or data element may have zero or one instance.
1..1 The section or data element may have one and only one instance.
0..* The section or data element may have zero or more instances.
1..* The section or data element may have one or more instances.
1..4 The section or data element may have one to four instances.
2..2 The section or data element must have two instances.
2.9 MANDATORY / OPTIONAL / REQUIRED
Each section and each data element within a section is defined as mandatory, optional or required
(M/O/R). The following table outlines how these technical requirements are mapped to conformance
verbs and how these designations are generally to be interpreted.
Table 3: Conformance Terms and Keywords
Conformance Term
Description Conformance Keyword
Mandatory If a section or data element is mandatory (denoted by ‘M’), it must be present in the document, otherwise the document is invalid and is non-conformant. The minimum cardinality for all mandatory items is 1.
SHALL
Required
If a section or data element is required (denoted by ‘R’), the sending application SHALL support this field. In other words, if the data is available, then the field SHALL be included in the document. If the minimum cardinality is 0 and the data is not available, the field may be omitted from the document and said document would still be conformant. If the minimum cardinality is 1 and the data is not
available, a NullFlavor code SHALL be sent (e.g. no information, unknown,
masked, not asked and asked, but unknown).
SHOULD
Optional
If a section or data element is optional (denoted by ‘O’), the section or data element MAY or MAY NOT be sent by conformant originating systems and MAY or MAY NOT be supported by conformant receiving systems. The receiving application SHALL not assume the presence of this item in a document nor SHALL it assume that the absence of this data means that the associated information is not asserted (e.g. absence of an allergy record can never be assumed to imply that there are no allergies)..
MAY
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
37 DSTU (Revision 2013)
Note: If an element is [R:1..x] the sending system SHALL send a valid value or a nullFlavor code. If
the element is [R:0..x] the sending system MAY omit the element if the data is not available.
If a section or data element is not supported or encoded the section or data element SHALL NOT be
included in the document. Inclusion of the item in the document is non-conformant.
Special Requirements for EMR Conversion & Patient Chart Transfer
The standard HL7 conformance presents a problem for these specifications since the Conversion and
Chart Transfer use cases (and the associated document specifications) are intended to support a
maximal extract of structure and unstructured data from a source system as well as, ideally, a complete
and accurate load of such data into appropriate data structures of a destination system. Since not all
systems are likely to support structured data in all areas this means that the specification has applied
optionality in certain areas. Notwithstanding this optionality, systems claiming conformance with the PITO
E2E-DTC specification SHALL include all optional elements if these elements can reasonably and safely
be included in an EMR Conversion or Patient Chart Transfer document instance. Furthermore, recipients
of these documents who claim conformance with the PITO E2E-DTC specification and who have
analogous data elements or capabilities to store this data SHALL support the import of these document
instances.
2.10 NULL FLAVOR
Information technology solutions store and manage data, but sometimes data is not available: an item
may be unknown, not relevant, or not computable or measureable. In HL7, a flavor of null, or
nullFlavor, describes the reason for missing data. The ability to disambiguate between data that is
unknown from data that is simply not sent is particularly critical in information exchanges where the
absence of a data element (e.g. the absence of alert or allergy data) could be misinterpreted as a lack of
alerts or allergies. Similarly, some data may not be known at a particular point in time but become
available at a later date.
For example, if a patient arrives at an Emergency Department unconscious and without identification, a
nullFlavor code is used to represent the lack of information. The patient’s birth date would be
represented with a nullFlavor code of “NAV”, which is the code for “temporarily unavailable”. When
the patient regains consciousness or a relative arrives, one may be able to determine this information and
include it in subsequent communications.
Use nullFlavor codes for unknown, required, or optional attributes as follows:
Table 4: nullFlavor codes
Null Flavor Description
NI No information. This is the most general and default nullFlavor
NA Not applicable. Known to have no proper value (e.g., last menstrual period for a male).
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
38 DSTU (Revision 2013)
Null Flavor Description
UNK Unknown. A proper value is applicable, but is not known.
ASKU Asked, but not known. Information was sought, but not found (e.g., the patient was asked but did not know).
NAV Temporarily unavailable. The information is not available, but is expected to be available later.
NASK Not asked. The patient was not asked.
MSK There is information on this item available but it has not been provided by the sender due to security, privacy, or other reasons. There may be an alternate mechanism for gaining access to this information.
This above list contains those null flavors that are commonly used in clinical documents. For the full list
and descriptions, see the nullFlavor vocabulary domain in the CDA normative edition.
Any SHALL conformance statement may use nullFlavor, unless the attribute is required or the
nullFlavor is explicitly disallowed. SHOULD and MAY conformance statement may also use
nullFlavor.
<!-- 1. SHALL contain at least one [1..*] id -->
<!-- 2. SHALL contain exactly one [1..1] code -->
<!-- 3. SHALL contain exactly one [1..1] effectiveTime -->
<entry>
<observation classCode="OBS" moodCode="EVN">
<id nullFlavor="NI"/>
<code nullFlavor="OTH"> <originalText>New Grading system</originalText> </code>
<effectiveTime nullFlavor="UNK"/>
</observation>
</entry>
Figure 14: nulFlavor Example
The use of a nullFlavor code is generally preferred over the use of “Other” or “Unknown” codes within
Value-Sets for coded data elements.
2.11 DATA TYPES
This specification uses pan-Canadian data types to support compatibility with other pan-Canadian
specifications. These data types are also more suitable thant R1 data types for several data elements
described by this specification, because some properties of Data Types R2 are required and pre-adopted
by the pan-Canadian data types.
Please see the Data Type Chapter for additional information.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
39 DSTU (Revision 2013)
2.12 CDA SCHEMAS
2.12.1 CDA Schema Files
A schema is set of requirements that need to be met in order for a document or set of data to be a valid
expression within the context of a particular grammar. The HL7 v3 Clinical Document Architecture R2
Normative Standard and these specifications include the following schema files:
Schema File Description
CDA-PITO-E2E.xsd Schema filed for used for clinical document validation. Constraint on the universal CDA.xsd for CDA R2. Includes the POCD_MT000040-PITO-E2E.xsd schema.
POCD_MT000040-PITO-E2E.xsd
Schema file used for the E2E message type validation. Constraint on the universal POCD_MT000040.xsd for CDA R2. Includes the EXTENSION-V2_0.xsd, Narrativeblock.xsd, datatypes.xsd, dataypes-base.xsd and the voc.xsd schemas.
EXTENSION-V2_0.xsd Schema file used for validations of extensions to POCD_MT000040-PITO-E2E.xsd.
Narrativeblock.xsd Schema file used for validations of the structure of the Narrative Blocks in the clinical document.
Voc.xsd Schema file used for vocabulary validation.
Datatypes.xsd Schema file that defines the representation of HL7 V3 data types in XML. Simple and complex data types (e.g. IVL_TS). Includes Datatypes-based.xsd.
Datatypes-base.xsd Schema file that defines the representation of the base HL7 V3 data types in XML. These are mostly simple data types (e.g. TS).
The following diagram, from the HL7 v3 CDA specification, demonstrates the relationship of the schema
files:
Figure 15: CDA Schema Overview
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
40 DSTU (Revision 2013)
2.12.2 CDA Schema Extension
The CDA Schema has been modestly extended to support the requirements of these specifications in
terms of additional data elements which are not present in the original design of CDA. Specifically, the
following attributes are extensions to the HL7 v3 Clinical Document Architecture R2 Normative Standard:
Table 5: CDA Schema Extensions
Context Attribute / Component Schema
IntendedRecipient code POCD_MT000040BC.xsd
Observation confidentialityCode POCD_MT000040BC.xsd
LabeledDrug desc POCD_MT000040BC.xsd
LabeledDrug formCode POCD_MT000040BC.xsd
LabeledDrug Ingredient POCD_MT000040BC.xsd
For the extensions to the CDA payload schema itself (POCD_MT00040UV), these are documented using
a foreign namespace as specified by the CDA Standard. xmlns:e2e=” http://standards.pito.bc.ca/E2E-
DTC/cda”.
2.13 EMBEDDED SAMPLES AND SAMPLE INSTANCES
Any embedded XML sample snippets as well as any sample document instances distributed with this
guide are solely informative content. In the case of discrepancies between these samples and the
specification, the latter SHALL prevail.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
41 DSTU (Revision 2013)
3.0 GENERAL HEADER TEMPLATE
3.1 BC PITO STANDARD HEADER
[ClinicalDocument: templateId 2.16.840.1.113883.3.1818.10.7.1(open)]
This header reflects the standard header for all documents in the PITO EMR-to-EMR Data Transfer and
Conversion specification. It has been adapted from the Interior Health Authority (IHA) header. A detailed
assessment of the gaps between the constraints established by this header and the IHA header has been
included in the Appendix.
3.1.1 Core Elements
Table 6: Core Elements Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
2 Clinical Document ClinicalDocument M:1..1
3 typeId M:1..1
4 realmCode M:1..1 CS
5 templateId M:2..2 II
6 @classCode M:1..1
7 @moodCode M:1..1
8 Unique Document Identifier Unique Identifier for this instance of the document as assigned by the authoring system.
id M:1..1 II
9 Document Type The type of document encoded using standard document type codes. (e.g. referral, consult, medical summary).
code M:1..1 CE
10 Document Title Title of the document, not to conflict with the Document Type (e.g. Referral Request).
title M:1..1 ST
11 Document Creation Time Date and time that the document was created. Note that this is NOT necessarily the same as the date/time the document was sent/transmitted.
effectiveTime M:1..1 TS
12 Document Confidentiality Level of confidentiality of the document coded with a default value of Normal.
confidentialityCode M:1..1 CE
13 Document Language The language in which the clinical document is written.
languageCode M:1..1 CS
14 setId O:0..1 II
15 versionNumber O:0..1 INT
1) SHALL contain exactly one [1..1] ClinicalDocument [CONF:2] such that it,
a) SHALL be a ClinicalDocument element from the urn:hl7-org:v3 namespace [CONF:2.8].
b) SHALL contain exactly one [1..1] typeId [CONF:3] such that it,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
42 DSTU (Revision 2013)
i) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.1.3" [CONF:3.10].
ii) SHALL contain exactly one [1..1] @extension="POCD_HD000040" [CONF:3.11].
c) SHALL contain exactly one [1..1] realmCode="CA-BC" Canada (British Columbia) (CodeSystem:
hl7Realm 2.16.840.1.113883.5.1124) [CONF:4].
d) SHALL contain exactly 2 [2..2] templateId [CONF:5] such that each,
i) SHALL contain exactly one [1..1] @root element; one occurrence of
templateId/@root="2.16.840.1.113883.3.1818.10.7.1" and the second occurrence of
templateId/@rootshall be the OID of the applicable document template [CONF:5.78].
e) SHALL contain exactly one [1..1] @classCode="DOCCLIN" clinical document (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:6].
f) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:7].
g) SHALL contain exactly one [1..1] id [CONF:8] such that it,
i) SHALL contain @root=X where X is a GUID [CONF:8.29].
h) SHALL contain exactly one [1..1] code, which SHOULD be selected from ValueSet DocumentType
2.16.840.1.113883.1.11.10870 DYNAMIC {CDAR2} [CONF:9].
i) SHALL contain exactly one [1..1] title [CONF:10] such that it,
i) SHALL NOT conflict with the meaning intended by ClinicalDocument/code [CONF:10.28].
j) SHALL contain exactly one [1..1] effectiveTime [CONF:11] such that it,
i) SHALL be precise to the day and SHOULD be precise to the minute; if precise to the minute, value SHALL include a time zone offset [CONF:11.18].
k) SHALL contain exactly one [1..1] confidentialityCode, which SHALL be selected from
ValueSet x_BasicConfidentialityKind 2.16.840.1.113883.2.20.3.139 STATIC {CDAR2} [CONF:12].
l) SHALL contain exactly one [1..1] languageCode="en-CA" English Canadian (CodeSystem:
iso639-3 1.0.639.3) [CONF:13].
m) MAY contain zero or one [0..1] setId [CONF:14] such that it,
i) SHALL, when present, contain @root=X where X is a GUID [CONF:14.1].
ii) SHALL be present when versionNumber is present [CONF:14.2].
n) MAY contain zero or one [0..1] versionNumber [CONF:15] such that it,
i) SHALL, when present, contain an integer representing the version of the document, with the initial version of 1, incrementing by one with each version of the document [CONF:15.3].
ii) SHALL be present when setId is present [CONF:15.4].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
43 DSTU (Revision 2013)
The following XML example outlines how to use the Document/Header Core Elements:
<?xml version="1.0" encoding="UTF-8"?>
<ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:hl7-org:v3 Schemas/CDA-PITO-E2E.xsd"
xmlns="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:e2e="http://standards.pito.bc.ca/E2E-DTC/cda">
<realmCode code="CA" />
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<id extension="12345" root="2.16.840.1.113883.3.933"/>
<code code="34140-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Referral"/>
<title>PITO EMR-2-EMR Complete Instance Example</title>
<effectiveTime value="201201091422"/>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
Figure 16: Document/Header Core Elements entry example
3.1.2 Information Recipient [informationRecipient]
Table 7: Information Recipient [informationRecipient] Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
16 Information Recipient The Information Recipient provides demographic information on the receiver of the document. The recipient may be a professional care provider, organization, and clinic/hospital or may be the patient themselves. The Information Recipient may also be the "health chart". The recipient may include the primary receiver and any “copy to” or secondary recipients. If a delegate receives the document on behalf of the actual intended recipient, the intended recipient’s information will appear in the information recipient information; the delegate information is not tracked. This may be a specific person, more than one person (primary and secondary recipients) or an organization. The Information Recipient may repeat to support multiple recipients.
informationRecipient R:1..*
17 @typeCode M:1..1
18 intendedRecipient M:1..1
19 @classCode M:1..1
20 Provider Unique Identifier Identifier of the healthcare provider that is clinically responsible for receiving the document.
id M:1..* II
22 Information Recipient Specialty The clinical specialty of the person or organization that is the intended recipient of
e2e:code O:0..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
44 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
the document.
23 Recipient's Address addr O:0..* AD
24 Recipient's Telecommunication Information
telecom O:0..* TEL
25 informationRecipient R:0..1
26 @classCode M:1..1
27 @determinerCode M:1..1
28 Recipient's Name name M:1..1 PN
29 Recipient's Organization receivedOrganization R:0..1
30 @classCode M:1..1
31 @determinerCode M:1..1
32 Recipient's Organization Name Name of the organization that is the intended recipient of the document.
name R:1..1 ON
o) SHALL contain one or more (or a nullFlavor value) [1..*] informationRecipient
[CONF:16].
i) SHALL contain exactly one [1..1] @typeCode [CONF:17] such that it,
(1) SHALL contain "PRCP" primary information recipient for the first occurrence of
informationRecipient and "TRC" tracker (CodeSystem: 2.16.840.1.113883.5.90) for any
subsequent occurrences, if applicable. [CONF:17.145].
ii) SHALL contain exactly one [1..1] intendedRecipient [CONF:18].
(1) SHALL contain exactly one [1..1] @classCode="ASSIGNED" assigned (CodeSystem:
RoleClass 2.16.840.1.113883.5.110) [CONF:19].
(2) SHALL contain at least one [1..*] id [CONF:20].
(3) MAY contain zero or one [0..1] e2e:code, which SHOULD be selected from ValueSet
ProviderRoleCode 2.16.840.1.113883.2.20.3.265 DYNAMIC {CDAR2} (CDA R2 Extension) [CONF:22].
(4) MAY contain zero or more [0..*] addr [CONF:23] such that each,
(a) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.1) [CONF:23.5].
(5) MAY contain zero or more [0..*] telecom [CONF:24] such that each,
(a) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.2) [CONF:24.5].
(6) SHALL contain zero or one if available [0..1] informationRecipient [CONF:25] such
that it,
(a) SHALL be present if receivedOrganization Is not included but MAY be omitted if
receivedOrganization Is included [CONF:25.23].
(b) SHALL contain exactly one [1..1] @classCode="PSN" person (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:26].
(c) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:27].
(d) SHALL contain exactly one [1..1] name [CONF:28] such that it,
(i) SHALL, when present, conform to the Person Name (PN) pan-Canadian Data
Type data type constraint template (2.16.840.1.113883.3.3068.10.5.3)
[CONF:28.5].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
45 DSTU (Revision 2013)
(7) SHALL contain zero or one if available [0..1] receivedOrganization [CONF:29] such
that it,
(a) SHALL be present if receivedRecipient Is not included but MAY be omitted if
receivedRecipient Is included [CONF:29.24].
(b) SHALL contain exactly one [1..1] @classCode="ORG" organization (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:30].
(c) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:31].
(d) SHALL contain exactly one (or a nullFlavor value) [1..1] name [CONF:32].
The following XML example outlines how to use the Information Recipient object:
<informationRecipient typeCode="PRCP">
<intendedRecipient classCode="ASSIGNED">
<id extension="ppump" root="DCCD2C68-389B-44c4-AD99-B8FB2DAD1493"/>
<e2e:code code="MD" codeSystem="2.16.840.1.113883.5.111"
codeSystemName="RoleCode" displayName="Medical Doctor"/>
<addr>
<streetAddressLine>4444 Healthcare Drive</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-1009" use="WP"/>
<informationRecipient classCode="PSN" determinerCode="INSTANCE">
<name>
<prefix>Dr.</prefix>
<given>Patrick</given>
<given>P.</given>
<family>Pump</family>
<suffix>Sr.</suffix>
</name>
</informationRecipient>
<receivedOrganization classCode="ORG" determinerCode="INSTANCE">
<name>Level 7 Healthcare, Inc</name>
</receivedOrganization>
</intendedRecipient>
</informationRecipient>
Figure 17: Information Recipient entry example
3.1.3 Author [author]
Table 8: Author [author] Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
33 Author The Author provides demographic information on the author(s) of the document, as well as the software system used to create the document. The Author is the primary care provider who is responsible for composing the document. A document may
author M:1..*
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
46 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
not be edited and forwarded under the previous author’s name. The author will always be the person who last edited the document. If a delegate sends a document on behalf of another care provider the clinically responsible person’s information will appear in the author information. Note that the custodian, not the author, represents the organization from which the document originates and that is in charge of maintaining the document. Author information also describes the source system that composed the document. The Author MAY occur twice: once for human author information and once for source system information.
34 @typeCode M:1..1
35 @contextControlCode M:1..1
36 Author Time Date and time stamp when document was created.
time M:1..1 TS
37 assignedAuthor M:1..1
38 @classCode M:1..1
39 Provider Unique Identifier Identifier of individual that is clinically responsible for authoring the document.
id M:1..* II
41 Author Address addr O:0..1 AD
42 Author Telecommunication Information telecom R:0..* TEL
43 assignedPerson M:1..1
44 @classCode M:1..1
45 @determinerCode M:1..1
46 Authoring Person(s) Name name R:1..1 PN
47 Authoring Person(s) Specialty code O:0..1 CE
48
assignedAuthoringDevice
O:0..1
49 @classCode M:1..1
50 @determinerCode M:1..1
51 Authoring System Device Software Name Code and name of the software system that authored the document.
softwareName M:1..1 SC
p) SHALL contain at least one [1..*] author [CONF:33].
i) SHALL contain exactly one [1..1] @typeCode="AUT" author (CodeSystem: ParticipationType
2.16.840.1.113883.5.90) [CONF:34].
ii) SHALL contain exactly one [1..1] @contextControlCode="OP" overriding propagating
(CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:35].
iii) SHALL contain exactly one [1..1] time [CONF:36] such that it,
(1) SHALL be precise to the day and SHOULD be precise to the minute; if precise to the minute, value SHALL include a time zone offset [CONF:36.18].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
47 DSTU (Revision 2013)
iv) SHALL contain exactly one [1..1] assignedAuthor [CONF:37].
(1) SHALL contain exactly one [1..1] @classCode="ASSIGNED" assigned (CodeSystem:
RoleClass 2.16.840.1.113883.5.110) [CONF:38].
(2) SHALL contain at least one [1..*] id [CONF:39] such that each,
(a) SHALL be the BC Ministry of Health Practitioner ID, for which the OID root is
2.16.840.1.113883.3.40.2.11 if the identified person is a Provider; MAY be a
locally assigned identifier if and only if the identified person is not a Provider [CONF:39.25].
(b) MAY be a locally assigned identifier, if the author is a not a Provider [CONF:39.13].
(c) MAY contain a NullFlavor if the id is not known and the name is included
[CONF:39.14].
(3) MAY contain zero or one [0..1] addr [CONF:41] such that it,
(a) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.1) [CONF:41.5].
(4) SHALL contain zero or more if available [0..*] telecom [CONF:42] such that each,
(a) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.2) [CONF:42.5].
(5) SHALL contain exactly one [1..1] assignedPerson [CONF:43] such that it,
(a) SHALL be included if and only if assignedAuthoringDevice is not included such
that either an assignedPerson or an assignedAuthoringDevice is included
but not both [CONF:43.15].
(b) SHALL contain exactly one [1..1] @classCode="PSN" person (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:44].
(c) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:45].
(d) SHALL contain exactly one (or a nullFlavor value) [1..1] name [CONF:46] such that
it,
(i) SHALL, when present, conform to the Person Name (PN) pan-Canadian Data
Type data type constraint template (2.16.840.1.113883.3.3068.10.5.3)
[CONF:46.5].
(6) MAY contain zero or one [0..1] code, which SHOULD be selected from ValueSet
ProviderRoleCode 2.16.840.1.113883.2.20.3.265 DYNAMIC {CDAR2} [CONF:47].
(7) MAY contain zero or one [0..1] assignedAuthoringDevice [CONF:48] such that it,
(a) SHALL be included if and only if assignedPerson is not included such that either an
assignedPerson or an assignedAuthoringDevice is included but not both
[CONF:48.16].
(b) SHALL contain exactly one [1..1] @classCode="DEV" device (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:49].
(c) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:50].
(d) SHALL contain exactly one [1..1] softwareName [CONF:51] such that it,
(i) SHALL be included to identify the originating system if and only if assignedAuthoringDevice is included [CONF:51.17].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
48 DSTU (Revision 2013)
The following XML example outlines how to use the Author object:
<author typeCode="AUT" contextControlCode="OP">
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<code code="07Q00000X" displayName="Family Practice"
codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7 RoleCode" />
<addr>
<streetAddressLine>4444 Healthcare Drive</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-1003" use="WP"/>
<telecom value="fax: (555) 555-1133" use="WP"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>
<prefix>Dr.</prefix>
<given>Harold</given>
<given>H.</given>
<family>Hippocrates</family>
<suffix>the 1st</suffix>
</name>
</assignedPerson>
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<name>Healthcare Drive Clinical Centre</name>
</representedOrganization>
</assignedAuthor>
</author>
<!-- If document is authored by device, then include this section instead of
assignedPerson
<assignedAuthoringDevice classCode="DEV" determinerCode="INSTANCE">
<softwareName code="TBD" codeSystem="TBD" codeSystemName="TBD"
displayName="Authoring Software Application Name" />
</assignedAuthoringDevice>
-->
Figure 18: Author entry example
3.1.4 Custodian Organization [custodian]
Table 9: Custodian Organization [custodian] Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
52 Custodian Organization The Custodian represents the organization from which the document originates and that is in charge of maintaining the document. The custodian is the steward that is entrusted with the care of the document; every CDA document must have exactly one custodian. Because this specification is an
custodian M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
49 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
exchange standard and may not represent the original form of the authenticated document, the custodian represents the steward of the original source document.
53 @typeCode M:1..1
54 assignedCustodian R:1..1
55 @classCode M:1..1
56
representedCustodianOrgan
ization
R:1..1
57 @classCode M:1..1
58 @determinerCode M:1..1
59 Organization Identifier Identifier of the custodian organization.
id M:1..1 II
60 Organization name Name of the custodian organization.
name O:0..1 ON
q) SHALL contain exactly one [1..1] custodian [CONF:52].
i) SHALL contain exactly one [1..1] @typeCode="CST" custodian (CodeSystem:
ParticipationType 2.16.840.1.113883.5.90) [CONF:53].
ii) SHALL contain exactly one (or a nullFlavor value) [1..1] assignedCustodian
[CONF:54].
(1) SHALL contain exactly one [1..1] @classCode="ASSIGNED" assigned (CodeSystem:
RoleClass 2.16.840.1.113883.5.110) [CONF:55].
(2) SHALL contain exactly one (or a nullFlavor value) [1..1]
representedCustodianOrganization [CONF:56].
(a) SHALL contain exactly one [1..1] @classCode="ORG" organization (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:57].
(b) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:58].
(c) SHALL contain exactly one [1..1] id [CONF:59].
(d) MAY contain zero or one [0..1] name [CONF:60].
The following XML example outlines how to use the Custodian Organization object:
<custodian typeCode="CST">
<assignedCustodian classCode="ASSIGNED">
<representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">
<id extension="123" root="7EEF0BCC-F03E-4742-A736-8BAC57180C5F"/>
<name>Level 7 Healthcare, Inc</name>
</representedCustodianOrganization>
</assignedCustodian>
</custodian>
Figure 19: Custodian Organization entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
50 DSTU (Revision 2013)
3.1.5 Patient [recordTarget]
Table 10: Patient [recordTarget] Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
61 Patient The Patient Demographics (Record Target) includes all the information regarding the patient. This may include patient identifiers, name, address, contact information, gender, birth date and location, marital status, religion, race, ethnic group, guardians, etc.
recordTarget M:1..1
62 @typeCode M:1..1
63 @contextControlCode M:1..1
64 patientRole M:1..1
65 @classCode M:1..1
67 Patient’s Identifier(s) BC Personal Health Number (PHN), if available, as well as any, applicable Non-PHN identifiers for the Patient, including but not limited to identifiers from other Provinces or agencies (e.g. worker's compensation; RCMP; local identifier).
id M:1..* II
68 Patient’s Address This element may repeat to accommodate all available addresses for the patient (e.g. home, work, vacation, temporary).
addr R:0..* AD
69 Patient’s Telecommunication Information telecom R:0..* TEL
70 patient R:1..*
71 Patient’s Name name R:0..* PN
72 Administrative Gender
administrativeGenderCode
R:1..1 CE
73 Birth Date/Time birthTime R:1..1 TS
74 Patient’s Language This element may repeat to accommodate all languages supported by the patient including proficiency level.
languageCommunication O:0..*
75 languageCode O:0..* CS
r) SHALL contain exactly one [1..1] recordTarget [CONF:61].
i) SHALL contain exactly one [1..1] @typeCode="RCT" record target (CodeSystem:
ParticipationType 2.16.840.1.113883.5.90) [CONF:62].
ii) SHALL contain exactly one [1..1] @contextControlCode="OP" overriding propagating
(CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:63].
iii) SHALL contain exactly one [1..1] patientRole [CONF:64].
(1) SHALL contain exactly one [1..1] @classCode="PAT" patient (CodeSystem: RoleClass
2.16.840.1.113883.5.110) [CONF:65].
(2) SHALL contain at least one [1..*] id [CONF:67] such that each,
(a) set SHOULD include at least one id which is the BC Personal Health Number (PHN)
for the patient, if availablle; the BC PHN OID root is 2.16.840.1.113883.4.50
[CONF:67.19].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
51 DSTU (Revision 2013)
(b) set MAY contain local identifiers, out of province health numbers or other relevant identifiers [CONF:67.20].
(c) SHALL include the assigningAuthority applicable to each included id
[CONF:67.21].
(3) SHALL contain zero or more if available [0..*] addr [CONF:68] such that each,
(a) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.1) [CONF:68.5].
(4) SHALL contain zero or more if available [0..*] telecom [CONF:69] such that each,
(a) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.2) [CONF:69.5].
(5) SHALL contain one or more (or a nullFlavor value) [1..*] patient [CONF:70].
(a) SHALL contain zero or more if available [0..*] name [CONF:71].
(b) SHALL contain exactly one (or a nullFlavor value) [1..1]
administrativeGenderCode, which SHALL be selected from ValueSet
AdministrativeGender 2.16.840.1.113883.1.11.1 STATIC {CDAR2} [CONF:72].
(c) SHALL contain exactly one (or a nullFlavor value) [1..1] birthTime [CONF:73]
such that it,
(i) SHALL be precise to the month, and SHOULD be precise to the day [CONF:73.22].
(d) MAY contain zero or more [0..*] languageCommunication [CONF:74].
(i) MAY contain zero or more [0..*] languageCode, which SHALL be selected from
ValueSet HumanLanguage 2.16.840.1.113883.1.11.11526 DYNAMIC {CDAR2} [CONF:75].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
52 DSTU (Revision 2013)
The following XML example outlines how to use the Patient object:
<recordTarget typeCode="RCT" contextControlCode="OP">
<patientRole classCode="PAT">
<id extension="9999999999" root="2BFBA1E9-79C2-4bbb-B589-41B949BD6A3B"
assigningAuthorityName="BC-PHN"/>
<id extension="99999-9" assigningAuthorityName="WCB"/>
<addr>
<streetAddressLine>2222 Home Street</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-2003" use="HP"/>
<telecom value="mailto: [email protected]" use="HP"/>
<patient>
<name>
<prefix>Mrs.</prefix>
<given>Eve</given>
<given>E.</given>
<family>Everywoman</family>
<suffix>Jr.</suffix>
</name>
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"
codeSystemName="HL7 - Administrative Gender" displayName="Female"/>
<birthTime value="19470516"/>
<languageCommunication>
<languageCode code="EN"/>
</languageCommunication>
</patient>
</patientRole>
</recordTarget>
Figure 20: Patient entry example
3.1.6 Personal Contact [participant]
Table 11: Personal Contact [participant] Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
76 Personal Contact The Personal Participant includes any participants in the patient’s care who are personal to the patient. This would include emergency contact, next of kin and any other personal relationships relevant to the subject of the document.
participant O:0..*
77 Contact Type Code The role of the personal contact. This would normally be set to "IND" to indicate that the personal contact is an indirect participant in the patient's care such as an emergency contact, spouse or related care giver.
@typeCode M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
53 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
78 Function Type The role that the contact plays in relationship with the patient for example Caregiver.
functionCode R:0..1 CE
79 @contextControlCode M:1..1
80 associatedEntity M:1..1
81 @classCode M:1..1
82 Contact Type The relationship of the contact to the patient. Examples may include husband/wife, daughter/son, friend, neighbour etc.
code M:1..1 CE
83 Address The personal contact's address.
addr R:0..1 AD
84 Personal Contact Telecommunication Information
telecom R:0..1 TEL
85 associatedPerson R:0..1
86 Name name M:1..1 PN
s) MAY contain zero or more [0..*] participant [CONF:76].
i) SHALL contain exactly one [1..1] @typeCode, which SHALL be selected from ValueSet
ParticipationType 2.16.840.1.113883.1.11.10901 STATIC {CDAR2} [CONF:77].
ii) SHALL contain zero or one if available [0..1] functionCode, which SHALL be selected from
ValueSet ParticipationFunction 2.16.840.1.113883.2.20.3.87 STATIC {CDAR2} [CONF:78].
iii) SHALL contain exactly one [1..1] @contextControlCode="OP" overriding propagating
(CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:79].
iv) SHALL contain exactly one [1..1] associatedEntity [CONF:80].
(1) SHALL contain exactly one [1..1] @classCode [CONF:81].
(2) SHALL contain exactly one [1..1] code, which SHALL be selected from ValueSet
PersonalRelationshipRoleType 2.16.840.1.113883.2.20.3.90 STATIC {CDAR2} [CONF:82].
(3) SHALL contain zero or one if available [0..1] addr [CONF:83] such that it,
(a) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.1) [CONF:83.5].
(4) SHALL contain zero or one if available [0..1] telecom [CONF:84] such that it,
(a) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.2) [CONF:84.5].
(5) SHALL contain zero or one if available [0..1] associatedPerson [CONF:85].
(a) SHALL contain exactly one [1..1] name [CONF:86] such that it,
(i) SHALL, when present, conform to the Person Name (PN) pan-Canadian Data
Type data type constraint template (2.16.840.1.113883.3.3068.10.5.3)
[CONF:86.5].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
54 DSTU (Revision 2013)
The following XML example outlines how to use the Personal Contact object:
<participant typeCode="NOT" contextControlCode="OP">
<associatedEntity classCode="CON">
<code code="HUSB" codeSystem="F05716F7-BA77-4641-A8D8-6E3948CCD321"
codeSystemName="HL7: PersonalRelationshipRoleType" displayName="Husband"/>
<addr>
<streetAddressLine>2222 Home Street</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-5001" use="HP"/>
<telecom value="mailto: [email protected]" use="HP"/>
<associatedPerson>
<name>
<prefix>Mr.</prefix>
<given>Neville</given>
<given>N.</given>
<family>Nuclear</family>
<suffix>III</suffix>
</name>
</associatedPerson>
</associatedEntity>
</participant>
Figure 21: Personal Contact entry example
3.1.7 Healthcare Participant [participant]
Table 12: Healthcare Participant [participant] Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
87 Healthcare Participant The Healthcare Provider Participant provides details for any member of the clinical team (e.g. the primary physician or members of a circle of care) when he or she is not identified under other document participations already. Where a document is providing information related to a specific encounter (for Instance, Discharge Summary), the providers associated with that encounter (Attending Physician, Referring Physician, Consultant, etc.) are recorded as participants in the Encompassing Encounter. In the case where the Primary Care Physician is not part the encounter, but should be included in the document, the Primary Care Physician is included in the Generic Participant construct, with appropriate codes to indicate his or her role.
participant R:0..*
88 Participant Type The role of the healthcare participant. This would normally be sent to "IND" to indicate
@typeCode M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
55 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
that the healthcare participant is an indirect participant in the patient's care as relevant to this document.
89 Function Type The role of the healthcare participant in the care of the patient. For example, PCP to indicate primary care provider.
functionCode R:0..1 CE
90 @contextControlCode M:1..1
91 associatedEntity R:0..1
92 Participant type @classCode M:1..1
93 Participant Identifier The identifier for the healthcare participant. This element should be the BC Ministry Practitioner ID for the provider if this is known; otherwise, it may be a locally assigned identifier.
id R:0..1 II
94 Participant Address The healthcare participant's postal address.
addr R:0..* AD
95 Healthcare Participant Telecommunication Information
telecom R:0..* TEL
96 associatedPerson R:0..1
97 Participant Name name M:1..1 PN
98 scopingOrganization O:0..1
99 Participant Organization Name A "doing business as" appellation of the work location that is familiar to the provider and is often a practice name, e.g. Dr Primary Medical Clinic.
name R:0..* ON
t) SHALL contain zero or more if available [0..*] participant [CONF:87].
i) SHALL contain exactly one [1..1] @typeCode, which SHALL be selected from ValueSet
ParticipationType 2.16.840.1.113883.1.11.10901 STATIC {CDAR2} [CONF:88].
ii) SHALL contain zero or one if available [0..1] functionCode, which SHALL be selected from
ValueSet ParticipationFunction 2.16.840.1.113883.2.20.3.87 STATIC {CDAR2} [CONF:89].
iii) SHALL contain exactly one [1..1] @contextControlCode="OP" overriding propagating
(CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:90].
iv) SHALL contain zero or one if available [0..1] associatedEntity [CONF:91].
(1) SHALL contain exactly one [1..1] @classCode [CONF:92].
(2) SHALL contain zero or one if available [0..1] id [CONF:93].
(3) SHALL contain zero or more if available [0..*] addr [CONF:94] such that each,
(a) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.1) [CONF:94.5].
(4) SHALL contain zero or more if available [0..*] telecom [CONF:95] such that each,
(a) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.2) [CONF:95.5].
(5) SHALL contain zero or one if available [0..1] associatedPerson [CONF:96].
(a) SHALL contain exactly one [1..1] name [CONF:97] such that it,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
56 DSTU (Revision 2013)
(i) SHALL, when present, conform to the Person Name (PN) pan-Canadian Data
Type data type constraint template (2.16.840.1.113883.3.3068.10.5.3)
[CONF:97.5].
(6) MAY contain zero or one [0..1] scopingOrganization [CONF:98].
(a) SHALL contain zero or more if available [0..*] name [CONF:99].
The following XML example outlines how to use the Healthcare Participant object:
<participant typeCode="IND">
<functionCode code="PCP"/>
<associatedEntity classCode="PROV">
<id root="8FF6156A-0CE8-11E0-BE3B-6C69DFD72085" extension="TBD"/>
<code code="TBD" codeSystem="TBD" codeSystemName="TBD" displayName="Primary Care
Provider" />
<addr use="WP">
<streetAddressLine>4444 Healthcare Drive</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-1009" use="WP"/>
<telecom value="fax: (555) 555-1199" use="WP"/>
<associatedPerson classCode="PSN" determinerCode="INSTANCE">
<name>
<prefix>Dr.</prefix>
<given>Patrick</given>
<given>P.</given>
<family>Pump</family>
<suffix>Sr.</suffix>
</name>
</associatedPerson>
<scopingOrganization>
<name>Level 7 Healthcare, Inc</name>
</scopingOrganization>
</associatedEntity>
</participant>
Figure 22: Healthcare Participant entry example
3.1.8 Legal Authenticator Participant [legalAuthenticator]
Table 13: Legal Authenticator Participant [legalAuthenticator] Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
100 Legal Authenticator Participant The Legal Authenticator represents a participant who has legally authenticated the accuracy of the document. A document can reflect unauthenticated, authenticated, or legally authenticated state. The unauthenticated state exists when no authentication information has been recorded (i.e., it is the absence of being either
legalAuthenticator O:0..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
57 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
authenticated or legally authenticated). While electronic signatures are not captured the authentication requires that a document has been signed manually or electronically by the responsible individual. A legal authenticator has a required legalAuthenticator.time indicating the time of authentication, and a required legalAauthenticator.signatureCode, indicating that a signature has been obtained and is on file.
101 @typeCode M:1..1
102 @contextControlCode M:1..1
103 Legal Authenticator Time The date/time that the document was legally authenticated.
time R:1..1 TS
104 Legal Authenticator Signature Code signatureCode R:1..1 CS
105 assignedEntity R:0..1
106 @classCode M:1..1
107 Legal Authenticator Identifier id M:1..1 II
108 code O:0..1 CE
109 Address Address of the legal authenticator.
addr O:0..* AD
110 Telecommunications telecom O:0..* TEL
111 assignedPerson R:0..1
112 @classCode M:1..1
113 @determinerCode M:1..1
114 Person Name name M:1..1 PN
115 Represented Organization
representedOrganization
R:0..1
116 @classCode M:1..1
117 @determinerCode M:1..1
118 Organization Identifier Identifier of the organization represented by the legal authenticator.
id M:1..1 II
119 Organization Name name O:0..1 ON
120 Organization Address addr O:0..* AD
121 Organization Telecommunications telecom O:0..* TEL
u) MAY contain zero or one [0..1] legalAuthenticator [CONF:100].
i) SHALL contain exactly one [1..1] @typeCode="LA" legal authenticator (CodeSystem:
ParticipationType 2.16.840.1.113883.5.90) [CONF:101].
ii) SHALL contain exactly one [1..1] @contextControlCode="OP" overriding propagating
(CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:102].
iii) SHALL contain exactly one (or a nullFlavor value) [1..1] time [CONF:103].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
58 DSTU (Revision 2013)
iv) SHALL contain exactly one (or a nullFlavor value) [1..1] signatureCode, which SHALL be
selected from ValueSet ParticipationSignature 2.16.840.1.113883.2.20.3.88 STATIC {CDAR2} [CONF:104].
v) SHALL contain zero or one if available [0..1] assignedEntity [CONF:105].
(1) SHALL contain exactly one [1..1] @classCode="ASSIGNED" assigned (CodeSystem:
RoleClass 2.16.840.1.113883.5.110) [CONF:106].
(2) SHALL contain exactly one [1..1] id [CONF:107] such that it,
(a) MAY be a locally assigned identifier, if the author is a not a Provider [CONF:107.13].
(b) SHALL be the BC Ministry of Health Practitioner ID, for which the OID root is
2.16.840.1.113883.3.40.2.11 if the identified person is a Provider; MAY be a
locally assigned identifier if and only if the identified person is not a Provider [CONF:107.25].
(c) MAY contain a NullFlavor if the id is not known and the name is included
[CONF:107.14].
(3) MAY contain zero or one [0..1] code, which SHOULD be selected from ValueSet
HealthcareProviderRoleType 2.16.840.1.113883.2.20.3.48 DYNAMIC {CDAR2} [CONF:108].
(4) MAY contain zero or more [0..*] addr [CONF:109] such that each,
(a) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.1) [CONF:109.5].
(5) MAY contain zero or more [0..*] telecom [CONF:110] such that each,
(a) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.2) [CONF:110.5].
(6) SHALL contain zero or one if available [0..1] assignedPerson [CONF:111].
(a) SHALL contain exactly one [1..1] @classCode="PSN" person (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:112].
(b) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:113].
(c) SHALL contain exactly one [1..1] name [CONF:114] such that it,
(i) SHALL, when present, conform to the Person Name (PN) pan-Canadian Data
Type data type constraint template (2.16.840.1.113883.3.3068.10.5.3)
[CONF:114.5].
(7) SHALL contain zero or one if available [0..1] representedOrganization [CONF:115].
(a) SHALL contain exactly one [1..1] @classCode="ORG" organization (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:116].
(b) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:117].
(c) SHALL contain exactly one [1..1] id [CONF:118].
(d) MAY contain zero or one [0..1] name [CONF:119].
(e) MAY contain zero or more [0..*] addr [CONF:120] such that each,
(i) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type
data type constraint template (2.16.840.1.113883.3.3068.10.5.1)
[CONF:120.5].
(f) MAY contain zero or more [0..*] telecom [CONF:121] such that each,
(i) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type
data type constraint template (2.16.840.1.113883.3.3068.10.5.2)
[CONF:121.5].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
59 DSTU (Revision 2013)
The following XML example outlines how to use the Legal Authenticator Participant object:
<legalAuthenticator>
<time value="200910201235" />
<signatureCode code="S" />
<assignedEntity>
<id root="B8E71AC2-0CD0-11E0-8746-CE50DFD72085" />
<code code="MD" codeSystem="2.16.840.1.113883.5.111" codeSystemName="RoleCode"
displayName="Medical Doctor"/>
<addr use="WP">
<streetAddressLine>4444 Healthcare Drive</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-1009" use="WP"/>
<telecom value="fax: (555) 555-1199" use="WP"/>
<assignedPerson>
<name>
<prefix>Dr.</prefix>
<given>Good</given>
<family>Doctor</family>
</name>
</assignedPerson>
<representedOrganization>
<name>Good Health Clinic</name>
</representedOrganization>
</assignedEntity>
</legalAuthenticator>
Figure 23: Legal Authenticator Participant entry example
3.1.9 Authenticator Participant [authenticator]
Table 14: Authenticator Participant [authenticator] Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
122 Authenticator Participant The Authenticator represents a participant who has attested to the accuracy of the document, but who does not have privileges to legally authenticate the document (see Legal Authenticator). An example would be a resident physician who sees a patient and dictates a note, then later signs it. A clinical document can have zero to many authenticators. While electronic signatures are not captured the authentications require that a document has been signed manually or electronically by the responsible individual. An authenticator has a required authenticator.time indicating the time of authentication, and a required authenticator.signatureCode, indicating that a signature has been obtained and is on file.
authenticator O:0..*
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
60 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
123 @typeCode M:1..1
124 Authenticator Time The date/time that the document was authenticated.
time R:1..1 TS
125 Authenticator Signature Code signatureCode R:1..1 CS
126 assignedEntity R:0..1
127 @classCode M:1..1
128 Authenticator Identifier id M:1..1 II
129 code O:0..1 CE
130 Address Address of the authenticator.
addr O:0..* AD
131 Telecommunications telecom O:0..* TEL
132 assignedPerson R:0..1
133 @classCode M:1..1
134 @determinerCode M:1..1
135 Authenticator Person Name name M:1..1 PN
136 Represented Organization
representedOrganization
R:0..1
137 @classCode M:1..1
138 @determinerCode M:1..1
139 Organization Identifier id M:1..1 II
140 Organization Name name O:0..1 ON
141 Organization Address addr O:0..* AD
142 Organization Telecommunications telecom O:0..* TEL
v) MAY contain zero or more [0..*] authenticator [CONF:122].
i) SHALL contain exactly one [1..1] @typeCode="AUTHEN" authenticator (CodeSystem:
ParticipationType 2.16.840.1.113883.5.90) [CONF:123].
ii) SHALL contain exactly one (or a nullFlavor value) [1..1] time [CONF:124].
iii) SHALL contain exactly one (or a nullFlavor value) [1..1] signatureCode, which SHALL be
selected from ValueSet ParticipationSignature 2.16.840.1.113883.2.20.3.88 STATIC {CDAR2} [CONF:125].
iv) SHALL contain zero or one if available [0..1] assignedEntity [CONF:126].
(1) SHALL contain exactly one [1..1] @classCode="ASSIGNED" assigned (CodeSystem:
RoleClass 2.16.840.1.113883.5.110) [CONF:127].
(2) SHALL contain exactly one [1..1] id [CONF:128] such that it,
(a) MAY be a locally assigned identifier, if the author is a not a Provider [CONF:128.13].
(b) SHALL be the BC Ministry of Health Practitioner ID, for which the OID root is
2.16.840.1.113883.3.40.2.11 if the identified person is a Provider; MAY be a
locally assigned identifier if and only if the identified person is not a Provider [CONF:128.25].
(c) MAY contain a NullFlavor if the id is not known and the name is included
[CONF:128.14].
(3) MAY contain zero or one [0..1] code, which SHOULD be selected from ValueSet
HealthcareProviderRoleType 2.16.840.1.113883.2.20.3.48 DYNAMIC {CDAR2} [CONF:129].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
61 DSTU (Revision 2013)
(4) MAY contain zero or more [0..*] addr [CONF:130] such that each,
(a) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.1) [CONF:130.5].
(5) MAY contain zero or more [0..*] telecom [CONF:131] such that each,
(a) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.2) [CONF:131.5].
(6) SHALL contain zero or one if available [0..1] assignedPerson [CONF:132].
(a) SHALL contain exactly one [1..1] @classCode="PSN" person (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:133].
(b) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:134].
(c) SHALL contain exactly one [1..1] name [CONF:135] such that it,
(i) SHALL, when present, conform to the Person Name (PN) pan-Canadian Data
Type data type constraint template (2.16.840.1.113883.3.3068.10.5.3)
[CONF:135.5].
(7) SHALL contain zero or one if available [0..1] representedOrganization [CONF:136].
(a) SHALL contain exactly one [1..1] @classCode="ORG" organization (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:137].
(b) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:138].
(c) SHALL contain exactly one [1..1] id [CONF:139].
(d) MAY contain zero or one [0..1] name [CONF:140].
(e) MAY contain zero or more [0..*] addr [CONF:141] such that each,
(i) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type
data type constraint template (2.16.840.1.113883.3.3068.10.5.1)
[CONF:141.5].
(f) MAY contain zero or more [0..*] telecom [CONF:142] such that each,
(i) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type
data type constraint template (2.16.840.1.113883.3.3068.10.5.2)
[CONF:142.5].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
62 DSTU (Revision 2013)
The following XML example outlines how to use the Authenticator Participant object:
<authenticator>
<time value="200910201235"/>
<signatureCode nullFlavor="NI"/>
<assignedEntity>
<id root="B8E71AC2-0CD0-11E0-8746-CE50DFD72085" />
<code code="TBD" codeSystem="2.16.840.1.113883.12.443" codeSystemName="HL7
Provider Role" displayName="Resident" />
<addr use="WP">
<streetAddressLine>4444 Healthcare Drive</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-1009" use="WP"/>
<telecom value="fax: (555) 555-1199" use="WP"/>
<assignedPerson>
<name>
<prefix>Dr.</prefix>
<given>Allright</given>
<family>Resident</family>
</name>
</assignedPerson>
<representedOrganization>
<name>Good Health Clinic</name>
</representedOrganization>
</assignedEntity>
</authenticator>
Figure 24: Authenticator Participant entry example
3.1.10 Data Enterer Participant [dataEnterer]
Table 15: Data Enterer Participant [dataEnterer] Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
143 Data Enterer Participant The Data Enterer identifies the person who has transformed a dictated note into text such as a transcriptionist. In cases of a patient transfer or episodic document where the Medical Office Assistant (MOA) is responsible for preparing the chart or consolidating the information to be included the MOA should be identified as the data enterer. If the data enterer is different from the author, this information should be provided.
dataEnterer O:0..1
144 @typeCode M:1..1
145 @contextControlCode M:1..1
146 Data Enterer Time The date/time that the data was entered.
time R:0..1 TS
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
63 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
147 assignedEntity R:0..1
148 @classCode M:1..1
149 Data Enterer Identifier Identifier of the healthcare provider participating in the encounter.
id M:1..1 II
150 code O:0..1 CE
151 Address Address of the provider.
addr O:0..* AD
152 Telecommunications telecom O:0..* TEL
153 assignedPerson R:0..1
154 @classCode M:1..1
155 @determinerCode M:1..1
156 Name name M:1..1 PN
157 Represented Organization
representedOrganization
R:0..1
158 @classCode M:1..1
159 @determinerCode M:1..1
160 Organization Identifier id M:1..1 II
161 Organization Name name O:0..1 ON
162 Organization Address addr O:0..* AD
163 Organization Telecommunications telecom O:0..* TEL
w) MAY contain zero or one [0..1] dataEnterer [CONF:143].
i) SHALL contain exactly one [1..1] @typeCode="ENT" enterer (CodeSystem: ParticipationType
2.16.840.1.113883.5.90) [CONF:144].
ii) SHALL contain exactly one [1..1] @contextControlCode="OP" overriding propagating
(CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:145].
iii) SHALL contain zero or one if available [0..1] time [CONF:146].
iv) SHALL contain zero or one if available [0..1] assignedEntity [CONF:147].
(1) SHALL contain exactly one [1..1] @classCode="ASSIGNED" assigned (CodeSystem:
RoleClass 2.16.840.1.113883.5.110) [CONF:148].
(2) SHALL contain exactly one [1..1] id [CONF:149] such that it,
(a) MAY be a locally assigned identifier, if the author is a not a Provider [CONF:149.13].
(b) SHALL be the BC Ministry of Health Practitioner ID, for which the OID root is
2.16.840.1.113883.3.40.2.11 if the identified person is a Provider; MAY be a
locally assigned identifier if and only if the identified person is not a Provider [CONF:149.25].
(c) MAY contain a NullFlavor if the id is not known and the name is included
[CONF:149.14].
(3) MAY contain zero or one [0..1] code, which SHOULD be selected from ValueSet
HealthcareProviderRoleType 2.16.840.1.113883.2.20.3.48 DYNAMIC {CDAR2} [CONF:150].
(4) MAY contain zero or more [0..*] addr [CONF:151] such that each,
(a) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.1) [CONF:151.5].
(5) MAY contain zero or more [0..*] telecom [CONF:152] such that each,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
64 DSTU (Revision 2013)
(a) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.2) [CONF:152.5].
(6) SHALL contain zero or one if available [0..1] assignedPerson [CONF:153].
(a) SHALL contain exactly one [1..1] @classCode="PSN" person (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:154].
(b) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:155].
(c) SHALL contain exactly one [1..1] name [CONF:156] such that it,
(i) SHALL, when present, conform to the Person Name (PN) pan-Canadian Data
Type data type constraint template (2.16.840.1.113883.3.3068.10.5.3)
[CONF:156.5].
(7) SHALL contain zero or one if available [0..1] representedOrganization [CONF:157].
(a) SHALL contain exactly one [1..1] @classCode="ORG" organization (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:158].
(b) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:159].
(c) SHALL contain exactly one [1..1] id [CONF:160].
(d) MAY contain zero or one [0..1] name [CONF:161].
(e) MAY contain zero or more [0..*] addr [CONF:162] such that each,
(i) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type
data type constraint template (2.16.840.1.113883.3.3068.10.5.1)
[CONF:162.5].
(f) MAY contain zero or more [0..*] telecom [CONF:163] such that each,
(i) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type
data type constraint template (2.16.840.1.113883.3.3068.10.5.2)
[CONF:163.5].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
65 DSTU (Revision 2013)
The following XML example outlines how to use the Data Enterer Participant object:
<dataEnterer typeCode="ENT" contextControlCode="OP">
<time value="200910201235" />
<assignedEntity>
<id root="B8E71AC2-0CD0-11E0-8746-CE50DFD72085" />
<code code="TBD" codeSystem="2.16.840.1.113883.5.111" codeSystemName="RoleCode"
displayName="Transcriptionist" />
<addr use="WP">
<streetAddressLine>4444 Healthcare Drive</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-1009" use="WP"/>
<assignedPerson>
<name>
<prefix>Mr.</prefix>
<given>Typ</given>
<family>Fast</family>
</name>
</assignedPerson>
<representedOrganization>
<name>Good Health Clinic</name>
</representedOrganization>
</assignedEntity>
</dataEnterer>
Figure 25: Data Enterer Participant entry example
3.1.11 Informant Participant [informant]
Table 16: Informant Participant [informant] Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
164 Informant Participant The Informant (or source of information) provides information on a person that provides relevant information, such as the parent of a comatose patient who describes the patient's behavior prior to the onset of coma. An informant can be a person in one of two roles; an person not formally identified in the system (e.g. a parent or guy on the street) or an identified member of the care team. The non-formally identified informant bears some formal or personal relationship to the patient and the nature of the relationship with the patient can be captured.
informant O:0..*
165 @typeCode M:1..1
166 @contextControlCode M:1..1
167 assignedEntity R:0..1
168 @classCode M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
66 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
169 Informant Identifier Identifier of the informant if known.
id M:1..1 II
170 code O:0..1 CE
171 Address Address of the provider.
addr O:0..* AD
172 Telecommunications telecom O:0..* TEL
173 assignedPerson R:0..1
174 @classCode M:1..1
175 @determinerCode M:1..1
176 Name name M:1..1 PN
177 Represented Organization
representedOrganization
R:0..1
178 @classCode M:1..1
179 @determinerCode M:1..1
180 Organization Identifier id M:1..1 II
181 Organization Name name O:0..1 ON
182 Organization Address addr O:0..* AD
183 Organization Telecommunications telecom O:0..* TEL
184 Informant Relationship relatedEntity R:0..1
185 @classCode M:1..1
186 Informant Related Role Code The nature of the relationship between the patient and the informant.
code R:0..1 CE
187 Informant Address The address of the informant.
addr R:0..1 AD
188 Informant Telecommunication Information telecom R:0..* TEL
189 Informant Related Effective Time The effective time of the informant relationship.
effectiveTime R:0..1 IVL_TS
190 relatedPerson R:0..1
191 Informant Related Name Name of the informant who is related to the patient.
name R:0..1 PN
x) MAY contain zero or more [0..*] informant [CONF:164].
i) SHALL contain exactly one [1..1] @typeCode="INF" informant (CodeSystem:
ParticipationType 2.16.840.1.113883.5.90) [CONF:165].
ii) SHALL contain exactly one [1..1] @contextControlCode="OP" overriding propagating
(CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:166].
iii) SHALL contain zero or one if available [0..1] assignedEntity [CONF:167].
(1) SHALL contain exactly one [1..1] @classCode="ASSIGNED" assigned (CodeSystem:
RoleClass 2.16.840.1.113883.5.110) [CONF:168].
(2) SHALL contain exactly one [1..1] id [CONF:169] such that it,
(a) MAY be a locally assigned identifier, if the author is a not a Provider [CONF:169.13].
(b) SHALL be the BC Ministry of Health Practitioner ID, for which the OID root is
2.16.840.1.113883.3.40.2.11 if the identified person is a Provider; MAY be a
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
67 DSTU (Revision 2013)
locally assigned identifier if and only if the identified person is not a Provider [CONF:169.25].
(c) MAY contain a NullFlavor if the id is not known and the name is included
[CONF:169.14].
(3) MAY contain zero or one [0..1] code, which SHOULD be selected from ValueSet
AssignedEntityRoleCode 2.16.840.1.113883.3.3068.10.8.25 STATIC {CDAR2} [CONF:170].
(4) MAY contain zero or more [0..*] addr [CONF:171] such that each,
(a) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.1) [CONF:171.5].
(5) MAY contain zero or more [0..*] telecom [CONF:172] such that each,
(a) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.2) [CONF:172.5].
(6) SHALL contain zero or one if available [0..1] assignedPerson [CONF:173].
(a) SHALL contain exactly one [1..1] @classCode="PSN" person (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:174].
(b) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:175].
(c) SHALL contain exactly one [1..1] name [CONF:176] such that it,
(i) SHALL, when present, conform to the Person Name (PN) pan-Canadian Data
Type data type constraint template (2.16.840.1.113883.3.3068.10.5.3)
[CONF:176.5].
(7) SHALL contain zero or one if available [0..1] representedOrganization [CONF:177].
(a) SHALL contain exactly one [1..1] @classCode="ORG" organization (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:178].
(b) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:179].
(c) SHALL contain exactly one [1..1] id [CONF:180].
(d) MAY contain zero or one [0..1] name [CONF:181].
(e) MAY contain zero or more [0..*] addr [CONF:182] such that each,
(i) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type
data type constraint template (2.16.840.1.113883.3.3068.10.5.1)
[CONF:182.5].
(f) MAY contain zero or more [0..*] telecom [CONF:183] such that each,
(i) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type
data type constraint template (2.16.840.1.113883.3.3068.10.5.2)
[CONF:183.5].
iv) SHALL contain zero or one if available [0..1] relatedEntity [CONF:184].
(1) SHALL contain exactly one [1..1] @classCode, which SHALL be selected from ValueSet
RoleClassMutualRelationship 2.16.840.1.113883.1.11.19316 STATIC {CDAR2} [CONF:185].
(2) SHALL contain zero or one if available [0..1] code, which SHALL be selected from
ValueSet PersonalRelationshipRoleType 2.16.840.1.113883.2.20.3.90 STATIC {CDAR2} [CONF:186].
(3) SHALL contain zero or one if available [0..1] addr [CONF:187] such that it,
(a) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.1) [CONF:187.5].
(4) SHALL contain zero or more if available [0..*] telecom [CONF:188] such that each,
(a) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.2) [CONF:188.5].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
68 DSTU (Revision 2013)
(5) SHALL contain zero or one if available [0..1] effectiveTime [CONF:189] such that it,
(a) MAY be a partial date conforming to the TS data type constraints [CONF:189.62].
(6) SHALL contain zero or one if available [0..1] relatedPerson [CONF:190].
(a) SHALL contain zero or one if available [0..1] name [CONF:191] such that it,
(i) SHALL, when present, conform to the Person Name (PN) pan-Canadian Data
Type data type constraint template (2.16.840.1.113883.3.3068.10.5.3)
[CONF:191.5].
The following XML example outlines how to use the Informant Participant object:
<informant typeCode="INF" contextControlCode="OP">
<assignedEntity classCode="ASSIGNED">
<id root="B8E71AC2-0CD0-11E0-8746-CE50DFD72085"/>
<code code="MD" codeSystem="2.16.840.1.113883.5.111" codeSystemName="RoleCode"
displayName="Medical Doctor"/>
<addr use="WP">
<streetAddressLine>4444 Healthcare Drive</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-1009" use="WP"/>
<assignedPerson>
<name>
<prefix>Mr.</prefix>
<given>Gimme</given>
<family>Infoplease</family>
</name>
</assignedPerson>
<representedOrganization>
<name>Tellall Health Clinic</name>
</representedOrganization>
</assignedEntity>
</informant>
Figure 26: Informant Participant entry example
3.1.12 Parent Document [relatedDocument]
Table 17: Parent Document [relatedDocument] Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
192 Parent Document This element provides a way for a document that represents an addendum to or a revision of an existing document (Parent Document) instance to reference that document.
relatedDocument O:0..2
193 Document Related Type A code indicating the type of relationship between the document and the parent document. May include Append, Replace or Transform.
@typeCode M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
69 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
194 parentDocument M:1..1
195 @classCode M:1..1
196 @moodCode M:1..1
197 Parent Document Unique Identifier The identifier of the document that this document is related to.
id M:1..1 II
198 Parent Document Type The type of the document that this document is related to.
code M:1..1 CD
199 Parent Document Text The description and link to the related document.
text R:0..1 ED
200 Parent Document Set ID setId O:0..1 II
201 Parent Document Version versionNumber O:0..1 INT
y) MAY contain zero to 2 [0..2] relatedDocument [CONF:192].
i) SHALL contain exactly one [1..1] @typeCode, which SHALL be selected from ValueSet
x_ActRelationshipDocument 2.16.840.1.113883.1.11.11610 STATIC {CDAR2} [CONF:193] such that it,
(1) SHALL be constrained to either "RPLC" (Replace) or "XFRM" (Transform) type codes
[CONF:193.80].
ii) SHALL contain exactly one [1..1] parentDocument [CONF:194].
(1) SHALL contain exactly one [1..1] @classCode="DOCCLIN" clinical document
(CodeSystem: ActClass 2.16.840.1.113883.5.6) [CONF:195].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:196].
(3) SHALL contain exactly one [1..1] id [CONF:197].
(4) SHALL contain exactly one [1..1] code, which SHOULD be selected from ValueSet
DocumentType 2.16.840.1.113883.1.11.10870 DYNAMIC {CDAR2} [CONF:198].
(5) SHALL contain zero or one if available [0..1] text [CONF:199] such that it,
(a) MAY contain @mediaType to indicate the MIME type of the related document; a
related document SHALL NOT be embedded in ParentDocument/text
[CONF:199.9].
(6) MAY contain zero or one [0..1] setId [CONF:200] such that it,
(a) SHALL, when present, contain @root=X where X is a GUID [CONF:200.1].
(b) SHALL be present when versionNumber is present [CONF:200.2].
(7) MAY contain zero or one [0..1] versionNumber [CONF:201] such that it,
(a) SHALL, when present, contain an integer representing the version of the document, with the initial version of 1, incrementing by one with each version of the document [CONF:201.3].
(b) SHALL be present when setId is present [CONF:201.4].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
70 DSTU (Revision 2013)
3.1.13 Encompassing Encounter [componentOf]
Table 18: Encompassing Encounter [componentOf] Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
202 Encompassing Encounter The Encompassing Encounter provides information regarding the setting of the clinical encounter during which the patient care or service event(s) occurred that are described in the document. For example, a discharge summary would include information regarding the admittance.
componentOf O:0..1
203 @typeCode M:1..1
204 encompassingEncounter R:0..1
205 @classCode M:1..1
206 @moodCode M:1..1
207 Identifier Encounter identifier.
id O:0..* II
208 Code Code identifying the type of encounter (e.g. ambulatory, emergency, home health).
code O:0..1 CE
209 Time The date/time of the encounter. This may be a time interval so that the duration of the encounter can be captured (e.g. admission/discharge or arrival/departure).
effectiveTime M:1..1 IVL_TS
210 Discharge Disposition Code Code identifying the disposition at the conclusion of the encounter.
dischargeDispositionCode
O:0..1 CE
211 Healthcare Provider encounterParticipant R:0..*
212 @typeCode M:1..1
213 assignedEntity M:1..1
214 @classCode M:1..1
215 Provider Identifier Identifier of the healthcare provider participating in the encounter.
id M:1..1 II
216 Provider Role Code Code identifying the role of the provider participating in the encounter.
code O:0..1 CE
217 Provider Address addr O:0..* AD
218 Provider Telecommunications telecom O:0..* TEL
219 assignedPerson R:0..1
220 @classCode M:1..1
221 @determinerCode M:1..1
222 Provider Name Name of the provider.
name M:1..1 PN
1719 Responsible Party responsibleParty R:0..*
1720 @typeCode M:1..1
1721 assignedEntity M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
71 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1722 @classCode M:1..1
1723 Provider Identifier Identifier of the healthcare provider participating in the encounter.
id M:1..1 II
1724 Provider Role Code Code identifying the role of the provider participating in the encounter.
code O:0..1 CE
1725 Provider Address addr O:0..* AD
1726 Provider Telecommunications telecom O:0..* TEL
1727 assignedPerson R:0..1
1728 @classCode M:1..1
1729 @determinerCode M:1..1
1730 Provider Name Name of the provider.
name M:1..1 PN
223 Represented Organization
representedOrganization
R:0..1
224 @classCode M:1..1
225 @determinerCode M:1..1
226 Organization Identifier Identifier of the organization represented by the provider participating in the encounter.
id M:1..1 II
227 Organization Name name O:0..1 ON
228 Organization Address addr O:0..* AD
229 Organization Telecommunications telecom O:0..* TEL
230 Encounter Location location O:0..1
231 @typeCode M:1..1
232 Healthcare Facility Healthcare facility where the encounter occurred.
healthCareFacility O:0..1
233 @classCode M:1..1
234 Healthcare Facility Identifier Identifier for the healthcare facility where the encounter occurred.
id O:0..* II
235 Healthcare Facility Type Type of healthcare facility (e.g. hospital, clinic, home) where the encounter occurred.
code O:0..1 CE
236 location O:0..1
237 @classCode M:1..1
238 @determinerCode M:1..1
239 Location Place Name Name of the location where the encounter occurred.
name O:0..1 EN
240 Location Place Address Address of the location where the encounter occurred.
addr O:0..1 AD
z) MAY contain zero or one [0..1] componentOf [CONF:202].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
72 DSTU (Revision 2013)
i) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:203].
ii) SHALL contain zero or one if available [0..1] encompassingEncounter [CONF:204].
(1) SHALL contain exactly one [1..1] @classCode="ENC" encounter (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:205].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:206].
(3) MAY contain zero or more [0..*] id [CONF:207].
(4) MAY contain zero or one [0..1] code, which SHALL be selected from ValueSet
ActEncounterCode 2.16.840.1.113883.1.11.13955 STATIC {CDAR2} [CONF:208].
(5) SHALL contain exactly one [1..1] effectiveTime [CONF:209] such that it,
(a) SHALL contain exactly one [1..1] low value to indicate the Start Date/Time and MAY
contain zero or one [0..1] high values to indicate the End Date/Time [CONF:209.50].
(6) MAY contain zero or one [0..1] dischargeDispositionCode, which SHALL be selected
from ValueSet EncounterDischargeDisposition 2.16.840.1.113883.2.20.3.43 STATIC {CDAR2} [CONF:210].
(7) SHALL contain zero or more if available [0..*] encounterParticipant [CONF:211].
(a) SHALL contain exactly one [1..1] @typeCode, which SHALL be selected from ValueSet
x_EncounterParticipant 2.16.840.1.113883.1.11.19600 STATIC {CDAR2} [CONF:212].
(b) SHALL contain exactly one [1..1] assignedEntity [CONF:213].
(i) SHALL contain exactly one [1..1] @classCode="ASSIGNED" assigned
(CodeSystem: RoleClass 2.16.840.1.113883.5.110) [CONF:214].
(ii) SHALL contain exactly one [1..1] id [CONF:215] such that it,
1. MAY be a locally assigned identifier, if the author is a not a Provider
[CONF:215.13].
2. SHALL be the BC Ministry of Health Practitioner ID, for which the OID root is
2.16.840.1.113883.3.40.2.11 if the identified person is a Provider;
MAY be a locally assigned identifier if and only if the identified person is not a Provider [CONF:215.25].
3. MAY contain a NullFlavor if the id is not known and the name is included
[CONF:215.14].
(iii) MAY contain zero or one [0..1] code, which SHOULD be selected from ValueSet
HealthcareProviderRoleType 2.16.840.1.113883.2.20.3.48 DYNAMIC {CDAR2} [CONF:216].
(iv) MAY contain zero or more [0..*] addr [CONF:217] such that each,
1. SHALL, when present, conform to the Address (AD) pan-Canadian Data Type
data type constraint template (2.16.840.1.113883.3.3068.10.5.1)
[CONF:217.5].
(v) MAY contain zero or more [0..*] telecom [CONF:218] such that each,
1. SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data type constraint template
(2.16.840.1.113883.3.3068.10.5.2) [CONF:218.5].
(vi) SHALL contain zero or one if available [0..1] assignedPerson [CONF:219].
1. SHALL contain exactly one [1..1] @classCode="PSN" person (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:220].
2. SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:221].
3. SHALL contain exactly one [1..1] name [CONF:222] such that it,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
73 DSTU (Revision 2013)
a. SHALL, when present, conform to the Person Name (PN) pan-Canadian Data Type data type constraint template
(2.16.840.1.113883.3.3068.10.5.3) [CONF:222.5].
(8) SHALL contain zero or more if available [0..*] responsibleParty [CONF:1719].
(a) SHALL contain exactly one [1..1] {CDAR2} @typeCode="RESP" responsible
(CodeSystem: ParticipationType 2.16.840.1.113883.5.90) [CONF:1720].
(b) SHALL contain exactly one [1..1] assignedEntity [CONF:1721].
(i) SHALL contain exactly one [1..1] {CDAR2} @classCode="ASSIGNED" assigned
(CodeSystem: RoleClass 2.16.840.1.113883.5.110) [CONF:1722].
(ii) SHALL contain exactly one [1..1] id [CONF:1723] such that it,
1. MAY be a locally assigned identifier, if the author is a not a Provider
[CONF:1723.13].
2. SHALL be the BC Ministry of Health Practitioner ID, for which the OID root is
2.16.840.1.113883.3.40.2.11 if the identified person is a Provider;
MAY be a locally assigned identifier if and only if the identified person is not a Provider [CONF:1723.25].
3. MAY contain a NullFlavor if the id is not known and the name is included
[CONF:1723.14].
(iii) MAY contain zero or one [0..1] {CDAR2} code, which SHOULD be selected from
ValueSet HealthcareProviderRoleType 2.16.840.1.113883.2.20.3.48 DYNAMIC {CDAR2} [CONF:1724].
(iv) MAY contain zero or more [0..*] {CDAR2} addr [CONF:1725] such that each,
1. SHALL, when present, conform to the Address (AD) pan-Canadian Data Type
data type constraint template (2.16.840.1.113883.3.3068.10.5.1)
[CONF:1725.5].
(v) MAY contain zero or more [0..*] {CDAR2} telecom [CONF:1726] such that each,
1. SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data type constraint template
(2.16.840.1.113883.3.3068.10.5.2) [CONF:1726.5].
(vi) SHALL contain zero or one if available [0..1] assignedPerson [CONF:1727].
1. SHALL contain exactly one [1..1] {CDAR2} @classCode="PSN" person
(CodeSystem: EntityClass 2.16.840.1.113883.5.41) [CONF:1728].
2. SHALL contain exactly one [1..1] {CDAR2} @determinerCode="INSTANCE"
instance (CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:1729].
3. SHALL contain exactly one [1..1] name [CONF:1730] such that it,
a. SHALL, when present, conform to the Person Name (PN) pan-Canadian Data Type data type constraint template
(2.16.840.1.113883.3.3068.10.5.3) [CONF:1730.5].
(vii) SHALL contain zero or one if available [0..1] representedOrganization
[CONF:223].
1. SHALL contain exactly one [1..1] @classCode="ORG" organization
(CodeSystem: EntityClass 2.16.840.1.113883.5.41) [CONF:224].
2. SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:225].
3. SHALL contain exactly one [1..1] id [CONF:226].
4. MAY contain zero or one [0..1] name [CONF:227].
5. MAY contain zero or more [0..*] addr [CONF:228] such that each,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
74 DSTU (Revision 2013)
a. SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data type constraint template
(2.16.840.1.113883.3.3068.10.5.1) [CONF:228.5].
6. MAY contain zero or more [0..*] telecom [CONF:229] such that each,
a. SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data type constraint template
(2.16.840.1.113883.3.3068.10.5.2) [CONF:229.5].
(9) MAY contain zero or one [0..1] location [CONF:230].
(a) SHALL contain exactly one [1..1] @typeCode="LOC" location (CodeSystem:
ParticipationType 2.16.840.1.113883.5.90) [CONF:231].
(b) MAY contain zero or one [0..1] healthCareFacility [CONF:232].
(i) SHALL contain exactly one [1..1] @classCode="SDLOC" service delivery location
(CodeSystem: RoleClass 2.16.840.1.113883.5.110) [CONF:233].
(ii) MAY contain zero or more [0..*] id [CONF:234].
(iii) MAY contain zero or one [0..1] code, which SHALL be selected from ValueSet
ServiceDeliveryLocationRoleType 2.16.840.1.113883.2.20.3.182 STATIC {CDAR2} [CONF:235].
(iv) MAY contain zero or one [0..1] location [CONF:236].
1. SHALL contain exactly one [1..1] @classCode="PLC" place (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:237].
2. SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:238].
3. MAY contain zero or one [0..1] name [CONF:239].
4. MAY contain zero or one [0..1] addr [CONF:240] such that it,
a. SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data type constraint template
(2.16.840.1.113883.3.3068.10.5.1) [CONF:240.5].
3.1.14 Order Fulfillment [inFulfillmentOf]
Table 19: Order Fulfillment [inFulfillmentOf] Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
241 Order Fulfillment The Order Fulfilment provides details of those orders that are fulfilled by this document. For example, In the case of a Diagnostic Imaging Report. A provider has ordered an X-Ray, it is performed and a radiologist reads the X-Ray and generates the report. The X-Ray order identifier is included here and the performed X-Ray procedure in the Service Event. This allows the document to be associated with the originating order that it is fulfilling.
inFulfillmentOf O:0..*
242 @typeCode M:1..1
243 Order order O:0..*
244 @classCode M:1..1
245 @moodCode M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
75 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
246 Order Identifier id R:1..* II
247 Order Code Code identifying the order that was placed (e.g. chest x-ray).
code O:0..1 CE
248 Order Priority Code The priority code associated with the order (e.g. routine, emergency, elective).
priorityCode O:0..1 CE
aa) MAY contain zero or more [0..*] inFulfillmentOf [CONF:241].
i) SHALL contain exactly one [1..1] @typeCode="FLFS" fulfills (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:242].
ii) MAY contain zero or more [0..*] order [CONF:243].
(1) SHALL contain exactly one [1..1] @classCode, which SHALL be selected from ValueSet
CDAHeaderActClass 2.16.840.1.113883.3.3068.10.8.8 STATIC {CDAR2} [CONF:244].
(2) SHALL contain exactly one [1..1] @moodCode="RQO" request (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:245].
(3) SHALL contain one or more (or a nullFlavor value) [1..*] id [CONF:246].
(4) MAY contain zero or one [0..1] code, which SHOULD be selected from ValueSet
ActOrderCode 2.16.840.1.113883.3.3068.10.8.7 DYNAMIC {CDAR2} [CONF:247].
(5) MAY contain zero or one [0..1] priorityCode, which SHALL be selected from ValueSet
ActPriority 2.16.840.1.113883.2.20.3.15 STATIC {CDAR2} [CONF:248].
3.1.15 Service Event [documentationOf]
Table 20: Service Event [documentationOf] Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
249 Service Event The Service Event provides information on the service that is the subject of the document. Depending on the document type, an instance may contain documentation of a specific service event and the related performers (for instance, a Procedure Note would document the specific procedure event). If a Service Event is included in the document, it must be equivalent to, or further specialize, the value inherent in the Document Type; it shall not conflict with the document type as such a conflict would constitute an ambiguous situation.
documentationOf O:0..*
250 @typeCode M:1..1
251 serviceEvent O:0..*
252 @classCode M:1..1
253 @moodCode M:1..1
254 Service Event Identifier id O:0..* II
255 Code code O:0..1 CE
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
76 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
Code identifying the type of service event that is being documented. For example the type of surgical procedure, examination or service.
256 EffectiveTime The date/time that the service event occurred. This may be a time interval so that the duration of the service event can be captured (e.g. start/finish).
effectiveTime O:0..1 IVL_TS
257 Service Event Performer The healthcare provider who is responsible for performing the service event. This element may repeat to accommodate multiple service event performers.
performer O:0..*
258 @typeCode M:1..1
259 Function Code The function of the service event performer. For example, attending physician, nurse, and anesthetist.
functionCode O:0..1 CE
260 Event Date/Time The date/time interval when the performer was involved in the service event activity. This may be a time interval so that the duration of the service event can be captured (e.g. start/finish).
time O:0..1 IVL_TS
261 Assigned Provider assignedEntity M:1..1
262 @classCode M:1..1
263 Provider Identifier id M:1..1 II
264 Provider’s Code Code identifying the role of the provider participating in the encounter.
code O:0..1 CE
265 Provider’s Address Address of the provider.
addr O:0..* AD
266 Provider’s Telecommunications telecom O:0..* TEL
267 assignedPerson R:0..1
268 @classCode M:1..1
269 @determinerCode M:1..1
270 Provider’s Name name M:1..1 PN
271 Represented Organization
representedOrganization
R:0..1
272 @classCode M:1..1
273 @determinerCode M:1..1
274 Organization Identifier id M:1..1 II
275 Organization Name name O:0..1 ON
276 Organization Address addr O:0..* AD
277 Organization Telecommunications telecom O:0..* TEL
bb) MAY contain zero or more [0..*] documentationOf [CONF:249].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
77 DSTU (Revision 2013)
i) SHALL contain exactly one [1..1] @typeCode="DOC" documentation (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:250].
ii) MAY contain zero or more [0..*] serviceEvent [CONF:251].
(1) SHALL contain exactly one [1..1] @classCode, which SHALL be selected from ValueSet
CDAHeaderActClass 2.16.840.1.113883.3.3068.10.8.8 STATIC {CDAR2} [CONF:252].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:253].
(3) MAY contain zero or more [0..*] id [CONF:254].
(4) MAY contain zero or one [0..1] code, which SHOULD be selected from ValueSet Procedure
2.16.840.1.113883.3.3068.10.8.11 DYNAMIC {CDAR2} [CONF:255].
(5) MAY contain zero or one [0..1] effectiveTime [CONF:256] such that it,
(a) SHALL contain exactly one [1..1] low value to indicate the Start Date/Time and MAY
contain zero or one [0..1] high values to indicate the End Date/Time [CONF:256.50].
(6) MAY contain zero or more [0..*] performer [CONF:257].
(a) SHALL contain exactly one [1..1] @typeCode, which SHALL be selected from ValueSet
x_ServiceEventPerformer 2.16.840.1.113883.1.11.19601 STATIC {CDAR2} [CONF:258] such that it,
(i) SHALL be constrained to either "PPRF" (Primary Performer) or "SPRF"
(Secondary Performer) type codes [CONF:258.79].
(b) MAY contain zero or one [0..1] functionCode, which SHALL be selected from
ValueSet ParticipationFunction 2.16.840.1.113883.2.20.3.87 STATIC {CDAR2} [CONF:259].
(c) MAY contain zero or one [0..1] time [CONF:260].
(d) SHALL contain exactly one [1..1] assignedEntity [CONF:261].
(i) SHALL contain exactly one [1..1] @classCode="ASSIGNED" assigned
(CodeSystem: RoleClass 2.16.840.1.113883.5.110) [CONF:262].
(ii) SHALL contain exactly one [1..1] id [CONF:263] such that it,
1. MAY be a locally assigned identifier, if the author is a not a Provider
[CONF:263.13].
2. SHALL be the BC Ministry of Health Practitioner ID, for which the OID root is
2.16.840.1.113883.3.40.2.11 if the identified person is a Provider;
MAY be a locally assigned identifier if and only if the identified person is not a Provider [CONF:263.25].
3. MAY contain a NullFlavor if the id is not known and the name is included
[CONF:263.14].
(iii) MAY contain zero or one [0..1] code, which SHOULD be selected from ValueSet
HealthcareProviderRoleType 2.16.840.1.113883.2.20.3.48 DYNAMIC {CDAR2} [CONF:264].
(iv) MAY contain zero or more [0..*] addr [CONF:265] such that each,
1. SHALL, when present, conform to the Address (AD) pan-Canadian Data Type
data type constraint template (2.16.840.1.113883.3.3068.10.5.1)
[CONF:265.5].
(v) MAY contain zero or more [0..*] telecom [CONF:266] such that each,
1. SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data type constraint template
(2.16.840.1.113883.3.3068.10.5.2) [CONF:266.5].
(vi) SHALL contain zero or one if available [0..1] assignedPerson [CONF:267].
1. SHALL contain exactly one [1..1] @classCode="PSN" person (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:268].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
78 DSTU (Revision 2013)
2. SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:269].
3. SHALL contain exactly one [1..1] name [CONF:270] such that it,
a. SHALL, when present, conform to the Person Name (PN) pan-Canadian Data Type data type constraint template
(2.16.840.1.113883.3.3068.10.5.3) [CONF:270.5].
(vii) SHALL contain zero or one if available [0..1] representedOrganization
[CONF:271].
1. SHALL contain exactly one [1..1] @classCode="ORG" organization
(CodeSystem: EntityClass 2.16.840.1.113883.5.41) [CONF:272].
2. SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:273].
3. SHALL contain exactly one [1..1] id [CONF:274].
4. MAY contain zero or one [0..1] name [CONF:275].
5. MAY contain zero or more [0..*] addr [CONF:276] such that each,
a. SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data type constraint template
(2.16.840.1.113883.3.3068.10.5.1) [CONF:276.5].
6. MAY contain zero or more [0..*] telecom [CONF:277] such that each,
a. SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data type constraint template
(2.16.840.1.113883.3.3068.10.5.2) [CONF:277.5].
3.1.16 Authorization & Consent [authorization]
Table 21: Authorization & Consent [authorization] Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
278 Authorization & Consent The Authorization & Consent provides information regarding the consents associated with this document. The type of consent (e.g. consent to perform the related Service Event, consent for the information contained in the document to be released to a third party) is conveyed. Consents referenced must have been finalized (Consent.statusCode must equal "completed") and should be on file.
authorization O:0..*
279 @typeCode M:1..1
280 consent R:0..1
281 @classCode M:1..1
282 @moodCode M:1..1
283 Consent Identifier The identifier associated with the consent to be used as a link to any consent documentation.
id R:0..1 II
284 Consent Code The type of consent (e.g. consents to perform the related Service Event; consent for the information contained in the document
code R:0..1 CE
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
79 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
to be released to a third party).
285 Consent Status Code The status of the consent. This must be valued with "Completed" to indicate that consent has been finalized and is on file prior to the document release.
statusCode R:1..1 CS
cc) MAY contain zero or more [0..*] authorization [CONF:278].
i) SHALL contain exactly one [1..1] @typeCode="AUTH" authorization (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:279].
ii) SHALL contain zero or one if available [0..1] consent [CONF:280].
(1) SHALL contain exactly one [1..1] @classCode="CONS" consent (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:281].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:282].
(3) SHALL contain zero or one if available [0..1] id [CONF:283].
(4) SHALL contain zero or one if available [0..1] code, which SHOULD be selected from
ValueSet ActConsentType 2.16.840.1.113883.1.11.19897 STATIC {CDAR2} [CONF:284].
(5) SHALL contain exactly one (or a nullFlavor value) [1..1] statusCode="COMPLETED"
completed (CodeSystem: ActStatus 2.16.840.1.113883.5.14) [CONF:285] such that it,
(a) SHALL be constrained to either Active or Completed status codes [CONF:285.34].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
80 DSTU (Revision 2013)
The following XML example outlines how to use the BC PITO Standard Header template:
<?xml version="1.0" encoding="UTF-8"?>
<ClinicalDocument xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:hl7-org:v3 Schemas/CDA-PITO-E2E.xsd"
xmlns="urn:hl7-org:v3"
xmlns:hl7="urn:hl7-org:v3"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:e2e="http://standards.pito.bc.ca/E2E-DTC/cda">
<!--
********************************************************
CDA Header
********************************************************
-->
<realmCode code="CA" />
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<id extension="12345" root="2.16.840.1.113883.3.933"/>
<code code="34140-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Referral"/>
<title>PITO EMR-2-EMR Complete Instance Example</title>
<effectiveTime value="201201091422"/>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<!--
********************************************************
Record Target
********************************************************
-->
<recordTarget typeCode="RCT" contextControlCode="OP">
<patientRole classCode="PAT">
<id extension="9999999999" root="2BFBA1E9-79C2-4bbb-B589-41B949BD6A3B"
assigningAuthorityName="BC-PHN"/>
<id extension="99999-9" assigningAuthorityName="WCB"/>
<addr>
<streetAddressLine>2222 Home Street</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-2003" use="HP"/>
<telecom value="mailto: [email protected]" use="HP"/>
<patient>
<name>
<prefix>Mrs.</prefix>
<given>Eve</given>
<given>E.</given>
<family>Everywoman</family>
<suffix>Jr.</suffix>
</name>
<administrativeGenderCode code="F" codeSystem="2.16.840.1.113883.5.1"
codeSystemName="HL7 - Administrative Gender" displayName="Female"/>
<birthTime value="19470516"/>
<languageCommunication>
<languageCode code="EN"/>
</languageCommunication>
</patient>
</patientRole>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
81 DSTU (Revision 2013)
</recordTarget>
<!--
********************************************************
Author
********************************************************
-->
<author typeCode="AUT" contextControlCode="OP">
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<code code="07Q00000X" displayName="Family Practice"
codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7 RoleCode" />
<addr>
<streetAddressLine>4444 Healthcare Drive</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-1003" use="WP"/>
<telecom value="fax: (555) 555-1133" use="WP"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>
<prefix>Dr.</prefix>
<given>Harold</given>
<given>H.</given>
<family>Hippocrates</family>
<suffix>the 1st</suffix>
</name>
</assignedPerson>
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<name>Healthcare Drive Clinical Centre</name>
</representedOrganization>
</assignedAuthor>
</author>
<!-- If document is authored by device, then include this section instead of
assignedPerson
<assignedAuthoringDevice classCode="DEV" determinerCode="INSTANCE">
<softwareName code="TBD" codeSystem="TBD" codeSystemName="TBD"
displayName="Authoring Software Application Name" />
</assignedAuthoringDevice>
-->
<!--
********************************************************
Data Enterer
******************************************************** -->
<dataEnterer typeCode="ENT" contextControlCode="OP">
<time value="200910201235" />
<assignedEntity>
<id root="B8E71AC2-0CD0-11E0-8746-CE50DFD72085" />
<code code="TBD" codeSystem="2.16.840.1.113883.5.111" codeSystemName="RoleCode"
displayName="Transcriptionist" />
<addr use="WP">
<streetAddressLine>4444 Healthcare Drive</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
82 DSTU (Revision 2013)
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-1009" use="WP"/>
<assignedPerson>
<name>
<prefix>Mr.</prefix>
<given>Typ</given>
<family>Fast</family>
</name>
</assignedPerson>
<representedOrganization>
<name>Good Health Clinic</name>
</representedOrganization>
</assignedEntity>
</dataEnterer>
<!--
********************************************************
Informant
******************************************************** -->
<informant typeCode="INF" contextControlCode="OP">
<assignedEntity classCode="ASSIGNED">
<id root="B8E71AC2-0CD0-11E0-8746-CE50DFD72085"/>
<code code="MD" codeSystem="2.16.840.1.113883.5.111" codeSystemName="RoleCode"
displayName="Medical Doctor"/>
<addr use="WP">
<streetAddressLine>4444 Healthcare Drive</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-1009" use="WP"/>
<assignedPerson>
<name>
<prefix>Mr.</prefix>
<given>Gimme</given>
<family>Infoplease</family>
</name>
</assignedPerson>
<representedOrganization>
<name>Tellall Health Clinic</name>
</representedOrganization>
</assignedEntity>
</informant>
<!--
********************************************************
Custodian
******************************************************** -->
<custodian typeCode="CST">
<assignedCustodian classCode="ASSIGNED">
<representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">
<id extension="123" root="7EEF0BCC-F03E-4742-A736-8BAC57180C5F"/>
<name>Level 7 Healthcare, Inc</name>
</representedCustodianOrganization>
</assignedCustodian>
</custodian>
<!--
********************************************************
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
83 DSTU (Revision 2013)
Information Recipient
******************************************************** -->
<informationRecipient typeCode="PRCP">
<intendedRecipient classCode="ASSIGNED">
<id extension="ppump" root="DCCD2C68-389B-44c4-AD99-B8FB2DAD1493"/>
<e2e:code code="MD" codeSystem="2.16.840.1.113883.5.111"
codeSystemName="RoleCode" displayName="Medical Doctor"/>
<addr>
<streetAddressLine>4444 Healthcare Drive</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-1009" use="WP"/>
<informationRecipient classCode="PSN" determinerCode="INSTANCE">
<name>
<prefix>Dr.</prefix>
<given>Patrick</given>
<given>P.</given>
<family>Pump</family>
<suffix>Sr.</suffix>
</name>
</informationRecipient>
<receivedOrganization classCode="ORG" determinerCode="INSTANCE">
<name>Level 7 Healthcare, Inc</name>
</receivedOrganization>
</intendedRecipient>
</informationRecipient>
<!--
*******************************************************
Legal Authenticator
******************************************************** -->
<legalAuthenticator>
<time value="200910201235" />
<signatureCode code="S" />
<assignedEntity>
<id root="B8E71AC2-0CD0-11E0-8746-CE50DFD72085" />
<code code="MD" codeSystem="2.16.840.1.113883.5.111" codeSystemName="RoleCode"
displayName="Medical Doctor"/>
<addr use="WP">
<streetAddressLine>4444 Healthcare Drive</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-1009" use="WP"/>
<telecom value="fax: (555) 555-1199" use="WP"/>
<assignedPerson>
<name>
<prefix>Dr.</prefix>
<given>Good</given>
<family>Doctor</family>
</name>
</assignedPerson>
<representedOrganization>
<name>Good Health Clinic</name>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
84 DSTU (Revision 2013)
</representedOrganization>
</assignedEntity>
</legalAuthenticator>
<!--
********************************************************
Authenticator
******************************************************** -->
<authenticator>
<time value="200910201235"/>
<signatureCode nullFlavor="NI"/>
<assignedEntity>
<id root="B8E71AC2-0CD0-11E0-8746-CE50DFD72085" />
<code code="TBD" codeSystem="2.16.840.1.113883.12.443" codeSystemName="HL7
Provider Role" displayName="Resident" />
<addr use="WP">
<streetAddressLine>4444 Healthcare Drive</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-1009" use="WP"/>
<telecom value="fax: (555) 555-1199" use="WP"/>
<assignedPerson>
<name>
<prefix>Dr.</prefix>
<given>Allright</given>
<family>Resident</family>
</name>
</assignedPerson>
<representedOrganization>
<name>Good Health Clinic</name>
</representedOrganization>
</assignedEntity>
</authenticator>
<!--
********************************************************
Participant - Personal Contact
******************************************************** -->
<participant typeCode="NOT" contextControlCode="OP">
<associatedEntity classCode="CON">
<code code="HUSB" codeSystem="F05716F7-BA77-4641-A8D8-6E3948CCD321"
codeSystemName="HL7: PersonalRelationshipRoleType" displayName="Husband"/>
<addr>
<streetAddressLine>2222 Home Street</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-5001" use="HP"/>
<telecom value="mailto: [email protected]" use="HP"/>
<associatedPerson>
<name>
<prefix>Mr.</prefix>
<given>Neville</given>
<given>N.</given>
<family>Nuclear</family>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
85 DSTU (Revision 2013)
<suffix>III</suffix>
</name>
</associatedPerson>
</associatedEntity>
</participant>
<!--
********************************************************
Participant - Healthcare Participant
******************************************************** -->
<participant typeCode="IND">
<functionCode code="PCP"/>
<associatedEntity classCode="PROV">
<id root="8FF6156A-0CE8-11E0-BE3B-6C69DFD72085" extension="TBD"/>
<code code="TBD" codeSystem="TBD" codeSystemName="TBD" displayName="Primary Care
Provider" />
<addr use="WP">
<streetAddressLine>4444 Healthcare Drive</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-1009" use="WP"/>
<telecom value="fax: (555) 555-1199" use="WP"/>
<associatedPerson classCode="PSN" determinerCode="INSTANCE">
<name>
<prefix>Dr.</prefix>
<given>Patrick</given>
<given>P.</given>
<family>Pump</family>
<suffix>Sr.</suffix>
</name>
</associatedPerson>
<scopingOrganization>
<name>Level 7 Healthcare, Inc</name>
</scopingOrganization>
</associatedEntity>
</participant>”
Figure 27: BC PITO Standard Header entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
86 DSTU (Revision 2013)
4.0 DOCUMENT TEMPLATES This chapter includes the Document Templates that describe the purpose and rules for constructing each
of the PITO E2E-DTC Specification documents as conformant CDA documents. Document templates
include constraints on the CDA header and refer to Section Templates. The Document Types and
Required/Optional Sections table lists the sections used by each document type.
Refer to the PITO EMR-to-EMR Data Transfer & Conversion Specification - Part I Business
Overview for business context including the intended scope of use for each document type, uses cases
and explanatory narrative.
Each Document Template contains the following information:
Scope and intended use of the document type;
Description and explanatory narrative;
Template metadata (e.g. templateId, etc.);
Header constraints: this includes a reference to the BC specific Clinical Document Header template
and additional constraints specific to each document type; and
Required and optional Section Templates.
4.1 EMR CONVERSION
[ClinicalDocument: templateId 2.16.840.1.113883.3.1818.10.1.1(open)]
The EMR Conversion Document is designed to support the migration of practice and patient information
from one EMR system to another. This usually occurs when the provider's practice decides to change
EMR systems. However, it could also occur when a provider changes from one practice to another and
wants to take his or her patient records with him to the new practice.
Special Conformance Requirements for EMR Conversion
Support for Discrete Data Elements
The goal of this specification is to enable conversion of patient chart information at the maximum
granularity possible. That is to say, source systems that contain structured data (e.g. Problem Lists,
Medication Lists, etc.) SHALL include this data through the CDA level 3 structures provided by this
specification whenever possible. Similarly, receiving systems shall place this data into the applicable,
equivalent modules and/or data structures.
Notwithstanding the establishment of section or element optionality, systems claiming conformance with
the PITO E2E-DTC specification SHALL include all optional elements if these elements can reasonable
and safely be included in an EMR Conversion document instance. Furthermore, recipients of an EMR
Conversion document instance who claim conformance with the PITO E2E-DTC specification and who
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
87 DSTU (Revision 2013)
have analogous data elements or capabilities to store this data SHALL support the full and complete
import of such document instances.
Conformance Validation
The conformance validation process for this document template will include an inspection process that
will review one or more sample charts to confirm that data is included appropriately in export test
document instances and imported appropriately from conformance validation document instances.
Information Recipient
The Information Recipient section in the Document Header (ClinicalDocument/informaitonRecipeint) is
required with a minimum cardinality of one. When a Conversion document is generated it is possible that
the recipient provider or system for that conversion is not known. In this case a nullFlavor SHALL be used
as shown in the following example:
<!--Information Recipient not available --!>
<informationRecipient typeCode="PRCP" nullFlavor="NA">
<intendedRecipient/>
</informationRecipient>
Figure 28: Information Recipient nullFlavor example
Table 22: Template Containment for an EMR Conversion
Template Name Template Type Template ID (OID)
EMR Conversion Document 2.16.840.1.113883.3.1818.10.1.1
Advance Directives [with entries] Section 2.16.840.1.113883.3.1818.10.2.2.1
Advanced Directives Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.1
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Advance Directives [without entries] Section 2.16.840.1.113883.3.1818.10.2.2
Alerts [with entries] Section 2.16.840.1.113883.3.1818.10.2.3.1
Alert Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.2
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
88 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Alerts [without entries] Section 2.16.840.1.113883.3.1818.10.2.3
Allergies & Intolerances (Reaction List) [with entries]
Section 2.16.840.1.113883.3.1818.10.2.4.1
Allergy & Intolerance Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.3
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Lifestage Observation Entry 2.16.840.1.113883.3.1818.10.4.12
Reaction Observation Entry 2.16.840.1.113883.3.1818.10.4.23
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Status Changes Audit Event Entry 2.16.840.1.113883.3.1818.10.4.31
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Allergies & Intolerances (Reaction List) [without entries]
Section 2.16.840.1.113883.3.1818.10.2.4
Appointments & Scheduling [with entries] Section 2.16.840.1.113883.3.1818.10.2.5.1
Appointment Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.4
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Provider Participation Entry 2.16.840.1.113883.3.1818.10.4.21
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Billing [with entries] Section 2.16.840.1.113883.3.1818.10.2.6.1
Billing Attachment SectionEntry 2.16.840.1.113883.3.1818.10.3.5
Care Plan / Reminders / Tasks [without entries]
Section 2.16.840.1.113883.3.1818.10.2.7
Clinical Measured Observations [with entries]
Section 2.16.840.1.113883.3.1818.10.2.8.1
Clinically Measured Observations Organizer
SectionEntry 2.16.840.1.113883.3.1818.10.3.7
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Clinical Measured Observations [without entries]
Section 2.16.840.1.113883.3.1818.10.2.8
Current Medications [with entries] Section 2.16.840.1.113883.3.1818.10.2.9.1
Medication Event SectionEntry 2.16.840.1.113883.3.1818.10.3.18
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
89 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Medication Prescription Event Entry 2.16.840.1.113883.3.1818.10.4.20
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Dispense Request (first fill) Entry 2.16.840.1.113883.3.1818.10.4.14
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dispense Request (part fill) Entry 2.16.840.1.113883.3.1818.10.4.33
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dispense Request (refill) Entry 2.16.840.1.113883.3.1818.10.4.34
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dose Observation Entry 2.16.840.1.113883.3.1818.10.4.8
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Instruction Observation Entry 2.16.840.1.113883.3.1818.10.4.35
Medication Dispense Event Entry 2.16.840.1.113883.3.1818.10.4.7
Medication Administration Event
Entry 2.16.840.1.113883.3.1818.10.4.36
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Location Participation Entry 2.16.840.1.113883.3.1818.10.4.13
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Order Indicator Entry 2.16.840.1.113883.3.1818.10.4.37
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Reaction Observation Entry 2.16.840.1.113883.3.1818.10.4.23
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Unbound Observation Entry 2.16.840.1.113883.3.1818.10.4.32
Current Medications [without entries] Section 2.16.840.1.113883.3.1818.10.2.9
Developmental Observations [with entries] Section 2.16.840.1.113883.3.1818.10.2.10.1
Developmental Observations Organizer SectionEntry 2.16.840.1.113883.3.1818.10.4.6
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
90 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Developmental Observations [without entries]
Section 2.16.840.1.113883.3.1818.10.2.10
Devices [with entries] Section 2.16.840.1.113883.3.1818.10.2.11.1
Device Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.8
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Devices [without entries] Section 2.16.840.1.113883.3.1818.10.2.11
Encounter History & Notes [with entries] Section 2.16.840.1.113883.3.1818.10.2.12.1
Encounter Event SectionEntry 2.16.840.1.113883.3.1818.10.3.9
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Provider Participation Entry 2.16.840.1.113883.3.1818.10.4.21
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Encounter History & Notes [without entries]
Section 2.16.840.1.113883.3.1818.10.2.12
Family History [with entries] Section 2.16.840.1.113883.3.1818.10.2.13.1
Family History Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.10
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Lifestage Observation Entry 2.16.840.1.113883.3.1818.10.4.12
Secondary Code (ICD-9) Entry 2.16.840.1.113883.3.1818.10.4.28
Family History [without entries] Section 2.16.840.1.113883.3.1818.10.2.13
Immunizations List [with entries] Section 2.16.840.1.113883.3.1818.10.2.14.1
Immunization Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.11
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Location Participation Entry 2.16.840.1.113883.3.1818.10.4.13
Reaction Observation Entry 2.16.840.1.113883.3.1818.10.4.23
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
91 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Secondary Code (Drug) Entry 2.16.840.1.113883.3.1818.10.4.27
Immunizations List [without entries] Section 2.16.840.1.113883.3.1818.10.2.14
Investigative Procedure History [with entries]
Section 2.16.840.1.113883.3.1818.10.2.15.1
Care History Event SectionEntry 2.16.840.1.113883.3.1818.10.3.6
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Qualifier Observation Entry 2.16.840.1.113883.3.1818.10.4.22
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Secondary Code (Unbound) Entry 2.16.840.1.113883.3.1818.10.4.29
Investigative Procedure History [without entries]
Section 2.16.840.1.113883.3.1818.10.2.15
Laboratory Results & Reports [with entries]
Section 2.16.840.1.113883.3.1818.10.2.16.1
Laboratory Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.12
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Result Organizer Entry 2.16.840.1.113883.3.1818.10.4.26
Result Component Entry 2.16.840.1.113883.3.1818.10.4.25
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
92 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Laboratory Results & Reports [without entries]
Section 2.16.840.1.113883.3.1818.10.2.16
Medical History [with entries] Section 2.16.840.1.113883.3.1818.10.2.17.1
Problem List Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.15
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Lifestage Observation Entry 2.16.840.1.113883.3.1818.10.4.12
Secondary Code (ICD-9) Entry 2.16.840.1.113883.3.1818.10.4.28
Unbound Observation Entry 2.16.840.1.113883.3.1818.10.4.32
Medical History [without entries] Section 2.16.840.1.113883.3.1818.10.2.17
Medical Imaging Results & Reports [with entries]
Section 2.16.840.1.113883.3.1818.10.2.18.1
Medical Imaging Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.13
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Medical Imaging Results & Reports [without entries]
Section 2.16.840.1.113883.3.1818.10.2.18
Medications & Prescriptions - Medication List [with entries]
Section 2.16.840.1.113883.3.1818.10.2.19.1
Medication Event SectionEntry 2.16.840.1.113883.3.1818.10.3.18
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Medication Prescription Event Entry 2.16.840.1.113883.3.1818.10.4.20
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Dispense Request (first fill) Entry 2.16.840.1.113883.3.1818.10.4.14
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dispense Request (part fill) Entry 2.16.840.1.113883.3.1818.10.4.33
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dispense Request (refill) Entry 2.16.840.1.113883.3.1818.10.4.34
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dose Observation Entry 2.16.840.1.113883.3.1818.10.4.8
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
93 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Instruction Observation Entry 2.16.840.1.113883.3.1818.10.4.35
Medication Dispense Event Entry 2.16.840.1.113883.3.1818.10.4.7
Medication Administration Event
Entry 2.16.840.1.113883.3.1818.10.4.36
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Location Participation Entry 2.16.840.1.113883.3.1818.10.4.13
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Order Indicator Entry 2.16.840.1.113883.3.1818.10.4.37
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Reaction Observation Entry 2.16.840.1.113883.3.1818.10.4.23
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Unbound Observation Entry 2.16.840.1.113883.3.1818.10.4.32
Medications & Prescriptions - Medication List [without entries]
Section 2.16.840.1.113883.3.1818.10.2.19
Orders & Requests [with entries] Section 2.16.840.1.113883.3.1818.10.2.20.1
Order Event SectionEntry 2.16.840.1.113883.3.1818.10.3.14
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
94 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Result Organizer Entry 2.16.840.1.113883.3.1818.10.4.26
Result Component Entry 2.16.840.1.113883.3.1818.10.4.25
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Orders & Requests [without entries] Section 2.16.840.1.113883.3.1818.10.2.20
Problems & Conditions - Problem List [with entries]
Section 2.16.840.1.113883.3.1818.10.2.21.1
Problem List Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.15
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Lifestage Observation Entry 2.16.840.1.113883.3.1818.10.4.12
Secondary Code (ICD-9) Entry 2.16.840.1.113883.3.1818.10.4.28
Unbound Observation Entry 2.16.840.1.113883.3.1818.10.4.32
Problems & Conditions - Problem List [without entries]
Section 2.16.840.1.113883.3.1818.10.2.21
Reproductive Observations [with entries] Section 2.16.840.1.113883.3.1818.10.2.23.1
Reproductive Observations Organizer SectionEntry 2.16.840.1.113883.3.1818.10.3.16
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Reproductive Observations [without entries]
Section 2.16.840.1.113883.3.1818.10.2.23
Risk Factors [with entries] Section 2.16.840.1.113883.3.1818.10.2.24.1
Risk Factors Organizer SectionEntry 2.16.840.1.113883.3.1818.10.3.17
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Risk Factors [without entries] Section 2.16.840.1.113883.3.1818.10.2.24
Surgical Procedure History [with entries] Section 2.16.840.1.113883.3.1818.10.2.25.1
Care History Event SectionEntry 2.16.840.1.113883.3.1818.10.3.6
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
95 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Qualifier Observation Entry 2.16.840.1.113883.3.1818.10.4.22
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Secondary Code (Unbound) Entry 2.16.840.1.113883.3.1818.10.4.29
Surgical Procedure History [without entries]
Section 2.16.840.1.113883.3.1818.10.2.25
Treatment History [with entries] Section 2.16.840.1.113883.3.1818.10.2.26.1
Care History Event SectionEntry 2.16.840.1.113883.3.1818.10.3.6
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Qualifier Observation Entry 2.16.840.1.113883.3.1818.10.4.22
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Secondary Code (Unbound) Entry 2.16.840.1.113883.3.1818.10.4.29
Treatment History [without entries] Section 2.16.840.1.113883.3.1818.10.2.26
Unclassified Documents [with entries] Section 2.16.840.1.113883.3.1818.10.2.27.1
Unclassified Documents Organizer SectionEntry 2.16.840.1.113883.3.1818.10.3.19
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
96 DSTU (Revision 2013)
EMR Conversion Header Constraints
An EMR Conversion SHALL conform to the BC PITO Standard Header Template subject to additional
constraints as follows. Conformant documents:
1) SHALL contain exactly two [2..2] templateId elements such that it,
a) SHALL contain exactly one [1..1] templateId/@root="2.16.840.1.113883.3.1818.10.1.1" to declare conformance to
the EMR Conversion clinical document specification.
b) SHALL contain exactly one [1..1] templateId/@root="2.16.840.1.113883.3.1818.10.7.1" to declare conformance to
the required header template.
2) SHALL contain exactly one [1..1] code="11503-0" Medical records (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:4386].
EMR Conversion Body Constraints
An EMR Conversion contains both narrative sections and sections requiring coded clinical statements
subject to the following constraints.
An EMR Conversion (ClinicalDocument) element:
1) SHALL contain exactly one [1..1] {CDAR2} component [CONF:401].
a) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:402].
b) SHALL contain exactly one [1..1] @contextConductionInd [CONF:403].
c) SHALL contain exactly one [1..1] structuredBody [CONF:404].
i) SHALL contain exactly one [1..1] @classCode="DOCBODY" document body (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:405].
ii) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:406].
iii) MAY contain zero or one [0..1] {CDAR2} confidentialityCode, which SHALL be selected
from ValueSet x_BasicConfidentialityKind 2.16.840.1.113883.2.20.3.139 STATIC [CONF:407].
iv) MAY contain zero or one [0..1] {CDAR2} languageCode, which SHALL be selected from
ValueSet HumanLanguage 2.16.840.1.113883.1.11.11526 DYNAMIC {CDAR2} [CONF:408].
v) SHALL contain at least one [1..*] component [CONF:409].
(1) SHALL contain exactly one [1..1] @typeCode="DRIV" derived (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:410].
(2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:411].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
97 DSTU (Revision 2013)
The following XML example outlines how to use the EMR Conversion template:
<ClinicalDocument classCode=”DOCCLIN” moodCode=”EVN”>
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<!-- Conforms to the BC PITO Standard Header specification -->
<templateId root="2.16.840.1.113883.3.1818.10.7.1"/>
<!-- Conforms to the BC PITO EMR Conversion Document specification -->
<templateId root="2.16.840.1.113883.3.1818.10.1.1"/>
…
<component typeCode=”COMP” contextConductionInd=”true”>
<structuredBody classCode-“DOCBODY” moodCode=”EVN”>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<languageCode code="en-CA" displayName="English, Canada"
codeSystem="2.16.840.1.113883.1.11.11526" codeSystemName="Internet Society
Language"/>
<component typeCode=”COMP” contextConductionInd=”true”>
<section>
. . .
</section>
<section>
. . .
</section>
</component>
</structuredBody>
</component>
</ClinicalDocument>
Figure 29: EMR Conversion entry example
The set of StructuredBody/component elements SHALL conform to the following constraints:
1) SHALL include one Advance Directives section, such that component/section,
a) MAY contain zero or one [0..1] Advance Directives [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.2), or SHOULD contain exactly one [1..1] Advance
Directives [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.2.1)
[CONF:SEC- 1.1].
2) SHALL include one Alerts section, such that component/section,
a) MAY contain zero or one [0..1] Alerts [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.3), or SHOULD contain exactly one [1..1] Alerts [with
entries] (templateId: 2.16.840.1.113883.3.1818.10.2.3.1) [CONF:SEC- 2.1].
3) SHALL include one Allergies & Intolerances - Reaction List section, such that component/section,
a) MAY contain zero or one [0..1] Allergies & Intolerances (Reaction List) [without entries]
(templateId: 2.16.840.1.113883.3.1818.10.2.4), or SHOULD contain exactly one [1..1]
Allergies & Intolerances (Reaction List) [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.4.1) [CONF:SEC- 3.1].
4) SHOULD include one Appointments & Scheduling section, such that component/section,
a) SHALL contain exactly one [1..1] Appointments & Scheduling [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.5.1) [CONF:SEC- 4.1].
5) MAY include one Billing section, such that component/section,
a) SHALL contain exactly one [1..1] Billing [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.6.1) [CONF:SEC- 5.1].
6) SHOULD include one Care Plan / Reminders / Tasks section, such that component/section,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
98 DSTU (Revision 2013)
a) SHALL contain exactly one [1..1] Care Plan / Reminders / Tasks [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.7) [CONF:SEC- 6.1].
7) SHOULD include one Clinically Measured Observations section, such that component/section,
a) MAY contain zero or one [0..1] Clinical Measured Observations [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.8), or SHOULD contain exactly one [1..1] Clinical
Measured Observations [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.8.1) [CONF:SEC- 7.1].
8) SHALL NOT include a Current Medications section [CONF:SEC-8].
9) SHOULD include one Developmental Observations section, such that component/section,
a) MAY contain zero or one [0..1] Developmental Observations [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.10), or SHOULD contain exactly one [1..1] Developmental
Observations [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.10.1)
[CONF:SEC- 9.1].
10) SHOULD include one Devices section, such that component/section,
a) MAY contain zero or one [0..1] Devices [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.11), or SHOULD contain exactly one [1..1] Devices [with
entries] (templateId: 2.16.840.1.113883.3.1818.10.2.11.1) [CONF:SEC- 10.1].
11) SHALL include one Encounter History & Notes section, such that component/section,
a) MAY contain zero or one [0..1] Encounter History & Notes [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.12), or SHOULD contain exactly one [1..1] Encounter
History & Notes [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.12.1)
[CONF:SEC- 11.1].
12) SHALL include one Family History section, such that component/section,
a) MAY contain zero or one [0..1] Family History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.13), or SHOULD contain exactly one [1..1] Family History
[with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.13.1) [CONF:SEC- 12.1].
13) SHALL include one Immunizations List section, such that component/section,
a) MAY contain zero or one [0..1] Immunizations List [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.14), or SHOULD contain exactly one [1..1] Immunizations
List [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.14.1) [CONF:SEC-
13.1].
14) SHOULD include one Investigative Procedure History section, such that component/section,
a) MAY contain zero or one [0..1] Investigative Procedure History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.15), or SHOULD contain exactly one [1..1] Investigative
Procedure History [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.15.1)
[CONF:SEC- 14.1].
15) SHALL include one Laboratory Results & Reports section, such that component/section,
a) MAY contain zero or one [0..1] Laboratory Results & Reports [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.16), or SHOULD contain exactly one [1..1] Laboratory
Results & Reports [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.16.1)
[CONF:SEC- 15.1].
16) SHOULD include one Medical History section, such that component/section,
a) MAY contain zero or one [0..1] Medical History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.17), or SHOULD contain exactly one [1..1] Medical History
[with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.17.1) [CONF:SEC- 16.1].
17) SHOULD include one Medical Imaging Results & Reports section, such that component/section,
a) MAY contain zero or one [0..1] Medical Imaging Results & Reports [without entries]
(templateId: 2.16.840.1.113883.3.1818.10.2.18), or SHOULD contain exactly one
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
99 DSTU (Revision 2013)
[1..1] Medical Imaging Results & Reports [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.18.1) [CONF:SEC- 17.1].
18) SHALL include one Medications & Prescriptions - Medication List section, such that component/section,
a) MAY contain zero or one [0..1] Medications & Prescriptions - Medication List [without entries]
(templateId: 2.16.840.1.113883.3.1818.10.2.19), or SHOULD contain exactly one
[1..1] Medications & Prescriptions - Medication List [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.19.1) [CONF:SEC- 18.1].
19) SHALL include one Orders & Requests section, such that component/section,
a) MAY contain zero or one [0..1] Orders & Requests [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.20), or SHOULD contain exactly one [1..1] Orders &
Requests [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.20.1)
[CONF:SEC- 19.1].
20) SHALL include one Problems & Conditions - Problem List section, such that component/section,
a) MAY contain zero or one [0..1] Problems & Conditions - Problem List [without entries]
(templateId: 2.16.840.1.113883.3.1818.10.2.21), or SHOULD contain exactly one
[1..1] Problems & Conditions - Problem List [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.21.1) [CONF:SEC- 20.1].
21) SHOULD include one Reproductive Observations section, such that component/section,
a) MAY contain zero or one [0..1] Reproductive Observations [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.23), or SHOULD contain exactly one [1..1] Reproductive
Observations [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.23.1)
[CONF:SEC- 22.1].
22) SHALL include one Risk Factors section, such that component/section,
a) MAY contain zero or one [0..1] Risk Factors [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.24), or SHOULD contain exactly one [1..1] Risk Factors
[with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.24.1) [CONF:SEC- 23.1].
23) SHOULD include one Surgical Procedure History section, such that component/section,
a) MAY contain zero or one [0..1] Surgical Procedure History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.25), or SHOULD contain exactly one [1..1] Surgical
Procedure History [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.25.1)
[CONF:SEC- 24.1].
24) SHOULD include one Treatment History section, such that component/section,
a) MAY contain zero or one [0..1] Treatment History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.26), or SHOULD contain exactly one [1..1] Treatment
History [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.26.1)
[CONF:SEC- 25.1].
25) SHOULD include one Unclassified Documents section, such that component/section,
a) SHALL contain exactly one [1..1] Unclassified Documents [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.27.1) [CONF:SEC- 204.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
100 DSTU (Revision 2013)
4.2 GENERIC EPISODIC DOCUMENT
[ClinicalDocument: templateId 2.16.840.1.113883.3.1818.10.1.2(open)]
The Generic Episodic Document supports the communication of portions of a patient record from one
clinical system (such as an EMR) to another to support the provision of care. The Generic Episodic
Document may be used as a basis for any clinical document that is relevant to a specific episode of care.
This may include the following types of documents:
Care Record Summary or Continuity of Care Document;
Referral Request;
Consultation Notes;
Discharge Summary;
Diagnostic Imaging Reports;
History and Physical Reports;
Operative Note;
Progress Note;
Procedure Note; and
General Unstructured Documents
Table 23: Template Containment for a Generic Episodic Document
Template Name Template Type Template ID (OID)
Generic Episodic Document Document 2.16.840.1.113883.3.1818.10.1.2
Advance Directives [with entries] Section 2.16.840.1.113883.3.1818.10.2.2.1
Advanced Directives Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.1
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Advance Directives [without entries] Section 2.16.840.1.113883.3.1818.10.2.2
Alerts [with entries] Section 2.16.840.1.113883.3.1818.10.2.3.1
Alert Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.2
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
101 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Alerts [without entries] Section 2.16.840.1.113883.3.1818.10.2.3
Allergies & Intolerances (Reaction List) [with entries]
Section 2.16.840.1.113883.3.1818.10.2.4.1
Allergy & Intolerance Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.3
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Lifestage Observation Entry 2.16.840.1.113883.3.1818.10.4.12
Reaction Observation Entry 2.16.840.1.113883.3.1818.10.4.23
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Status Changes Audit Event Entry 2.16.840.1.113883.3.1818.10.4.31
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Allergies & Intolerances (Reaction List) [without entries]
Section 2.16.840.1.113883.3.1818.10.2.4
Care Plan / Reminders / Tasks [without entries]
Section 2.16.840.1.113883.3.1818.10.2.7
Clinical Measured Observations [with entries]
Section 2.16.840.1.113883.3.1818.10.2.8.1
Clinically Measured Observations Organizer
SectionEntry 2.16.840.1.113883.3.1818.10.3.7
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Clinical Measured Observations [without entries]
Section 2.16.840.1.113883.3.1818.10.2.8
Current Medications [with entries] Section 2.16.840.1.113883.3.1818.10.2.9.1
Medication Event SectionEntry 2.16.840.1.113883.3.1818.10.3.18
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Medication Prescription Event Entry 2.16.840.1.113883.3.1818.10.4.20
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Dispense Request (first fill) Entry 2.16.840.1.113883.3.1818.10.4.14
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
102 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Dispense Request (part fill) Entry 2.16.840.1.113883.3.1818.10.4.33
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dispense Request (refill) Entry 2.16.840.1.113883.3.1818.10.4.34
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dose Observation Entry 2.16.840.1.113883.3.1818.10.4.8
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Instruction Observation Entry 2.16.840.1.113883.3.1818.10.4.35
Medication Dispense Event Entry 2.16.840.1.113883.3.1818.10.4.7
Medication Administration Event
Entry 2.16.840.1.113883.3.1818.10.4.36
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Location Participation Entry 2.16.840.1.113883.3.1818.10.4.13
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Order Indicator Entry 2.16.840.1.113883.3.1818.10.4.37
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Reaction Observation Entry 2.16.840.1.113883.3.1818.10.4.23
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Unbound Observation Entry 2.16.840.1.113883.3.1818.10.4.32
Current Medications [without entries] Section 2.16.840.1.113883.3.1818.10.2.9
Developmental Observations [with entries] Section 2.16.840.1.113883.3.1818.10.2.10.1
Developmental Observations Organizer SectionEntry 2.16.840.1.113883.3.1818.10.4.6
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Developmental Observations [without entries]
Section 2.16.840.1.113883.3.1818.10.2.10
Devices [with entries] Section 2.16.840.1.113883.3.1818.10.2.11.1
Device Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.8
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Devices [without entries] Section 2.16.840.1.113883.3.1818.10.2.11
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
103 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Encounter History & Notes [with entries] Section 2.16.840.1.113883.3.1818.10.2.12.1
Encounter Event SectionEntry 2.16.840.1.113883.3.1818.10.3.9
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Provider Participation Entry 2.16.840.1.113883.3.1818.10.4.21
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Encounter History & Notes [without entries]
Section 2.16.840.1.113883.3.1818.10.2.12
Family History [with entries] Section 2.16.840.1.113883.3.1818.10.2.13.1
Family History Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.10
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Lifestage Observation Entry 2.16.840.1.113883.3.1818.10.4.12
Secondary Code (ICD-9) Entry 2.16.840.1.113883.3.1818.10.4.28
Family History [without entries] Section 2.16.840.1.113883.3.1818.10.2.13
Immunizations List [with entries] Section 2.16.840.1.113883.3.1818.10.2.14.1
Immunization Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.11
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Location Participation Entry 2.16.840.1.113883.3.1818.10.4.13
Reaction Observation Entry 2.16.840.1.113883.3.1818.10.4.23
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Secondary Code (Drug) Entry 2.16.840.1.113883.3.1818.10.4.27
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
104 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Immunizations List [without entries] Section 2.16.840.1.113883.3.1818.10.2.14
Investigative Procedure History [with entries]
Section 2.16.840.1.113883.3.1818.10.2.15.1
Care History Event SectionEntry 2.16.840.1.113883.3.1818.10.3.6
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Qualifier Observation Entry 2.16.840.1.113883.3.1818.10.4.22
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Secondary Code (Unbound) Entry 2.16.840.1.113883.3.1818.10.4.29
Investigative Procedure History [without entries]
Section 2.16.840.1.113883.3.1818.10.2.15
Laboratory Results & Reports [with entries]
Section 2.16.840.1.113883.3.1818.10.2.16.1
Laboratory Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.12
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Result Organizer Entry 2.16.840.1.113883.3.1818.10.4.26
Result Component Entry 2.16.840.1.113883.3.1818.10.4.25
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Laboratory Results & Reports [without entries]
Section 2.16.840.1.113883.3.1818.10.2.16
Medical History [with entries] Section 2.16.840.1.113883.3.1818.10.2.17.1
Problem List Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.15
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
105 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Lifestage Observation Entry 2.16.840.1.113883.3.1818.10.4.12
Secondary Code (ICD-9) Entry 2.16.840.1.113883.3.1818.10.4.28
Unbound Observation Entry 2.16.840.1.113883.3.1818.10.4.32
Medical History [without entries] Section 2.16.840.1.113883.3.1818.10.2.17
Medical Imaging Results & Reports [with entries]
Section 2.16.840.1.113883.3.1818.10.2.18.1
Medical Imaging Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.13
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Medical Imaging Results & Reports [without entries]
Section 2.16.840.1.113883.3.1818.10.2.18
Medications & Prescriptions - Medication List [with entries]
Section 2.16.840.1.113883.3.1818.10.2.19.1
Medication Event SectionEntry 2.16.840.1.113883.3.1818.10.3.18
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Medication Prescription Event Entry 2.16.840.1.113883.3.1818.10.4.20
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Dispense Request (first fill) Entry 2.16.840.1.113883.3.1818.10.4.14
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dispense Request (part fill) Entry 2.16.840.1.113883.3.1818.10.4.33
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dispense Request (refill) Entry 2.16.840.1.113883.3.1818.10.4.34
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dose Observation Entry 2.16.840.1.113883.3.1818.10.4.8
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Instruction Observation Entry 2.16.840.1.113883.3.1818.10.4.35
Medication Dispense Event Entry 2.16.840.1.113883.3.1818.10.4.7
Medication Administration Event
Entry 2.16.840.1.113883.3.1818.10.4.36
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
106 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Location Participation Entry 2.16.840.1.113883.3.1818.10.4.13
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Order Indicator Entry 2.16.840.1.113883.3.1818.10.4.37
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Reaction Observation Entry 2.16.840.1.113883.3.1818.10.4.23
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Unbound Observation Entry 2.16.840.1.113883.3.1818.10.4.32
Medications & Prescriptions - Medication List [without entries]
Section 2.16.840.1.113883.3.1818.10.2.19
Orders & Requests [with entries] Section 2.16.840.1.113883.3.1818.10.2.20.1
Order Event SectionEntry 2.16.840.1.113883.3.1818.10.3.14
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Result Organizer Entry 2.16.840.1.113883.3.1818.10.4.26
Result Component Entry 2.16.840.1.113883.3.1818.10.4.25
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
107 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Orders & Requests [without entries] Section 2.16.840.1.113883.3.1818.10.2.20
Problems & Conditions - Problem List [with entries]
Section 2.16.840.1.113883.3.1818.10.2.21.1
Problem List Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.15
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Lifestage Observation Entry 2.16.840.1.113883.3.1818.10.4.12
Secondary Code (ICD-9) Entry 2.16.840.1.113883.3.1818.10.4.28
Unbound Observation Entry 2.16.840.1.113883.3.1818.10.4.32
Problems & Conditions - Problem List [without entries]
Section 2.16.840.1.113883.3.1818.10.2.21
Purpose Section 2.16.840.1.113883.3.1818.10.2.22
Reproductive Observations [with entries] Section 2.16.840.1.113883.3.1818.10.2.23.1
Reproductive Observations Organizer SectionEntry 2.16.840.1.113883.3.1818.10.3.16
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Reproductive Observations [without entries]
Section 2.16.840.1.113883.3.1818.10.2.23
Risk Factors [with entries] Section 2.16.840.1.113883.3.1818.10.2.24.1
Risk Factors Organizer SectionEntry 2.16.840.1.113883.3.1818.10.3.17
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Risk Factors [without entries] Section 2.16.840.1.113883.3.1818.10.2.24
Surgical Procedure History [with entries] Section 2.16.840.1.113883.3.1818.10.2.25.1
Care History Event SectionEntry 2.16.840.1.113883.3.1818.10.3.6
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Qualifier Observation Entry 2.16.840.1.113883.3.1818.10.4.22
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
108 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Secondary Code (Unbound) Entry 2.16.840.1.113883.3.1818.10.4.29
Surgical Procedure History [without entries]
Section 2.16.840.1.113883.3.1818.10.2.25
Treatment History [with entries] Section 2.16.840.1.113883.3.1818.10.2.26.1
Care History Event SectionEntry 2.16.840.1.113883.3.1818.10.3.6
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Qualifier Observation Entry 2.16.840.1.113883.3.1818.10.4.22
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Secondary Code (Unbound) Entry 2.16.840.1.113883.3.1818.10.4.29
Treatment History [without entries] Section 2.16.840.1.113883.3.1818.10.2.26
Generic Episodic Document Header Constraints
A Generic Episodic Document SHALL conform to the BC PITO Standard Header Template subject to
additional constraints as follows. Conformant documents:
1) SHALL contain exactly two [2..2] templateId elements such that it,
a) SHALL contain exactly one [1..1] templateId/@root="2.16.840.1.113883.3.1818.10.1.2" to declare conformance to
the Generic Episodic Document clinical document specification.
b) SHALL contain exactly one [1..1] templateId/@root="2.16.840.1.113883.3.1818.10.7.1" to declare conformance to
the required header template.
2) SHALL contain at least one [1..*] informationRecipient [CONF:4429].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
109 DSTU (Revision 2013)
Generic Episodic Document Body Constraints
A Generic Episodic Document contains both narrative sections and sections requiring coded clinical
statements subject to the following constraints.
A Generic Episodic Document (ClinicalDocument) element:
1) SHALL contain exactly one [1..1] {CDAR2} component [CONF:295].
a) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:296].
b) SHALL contain exactly one [1..1] @contextConductionInd [CONF:297].
c) SHALL contain exactly one [1..1] structuredBody [CONF:298].
i) SHALL contain exactly one [1..1] @classCode="DOCBODY" document body (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:299].
ii) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:300].
iii) MAY contain zero or one [0..1] {CDAR2} confidentialityCode, which SHALL be selected
from ValueSet x_BasicConfidentialityKind 2.16.840.1.113883.2.20.3.139 STATIC [CONF:301].
iv) MAY contain zero or one [0..1] {CDAR2} languageCode, which SHALL be selected from
ValueSet HumanLanguage 2.16.840.1.113883.1.11.11526 DYNAMIC {CDAR2} [CONF:302].
v) SHALL contain at least one [1..*] component [CONF:303].
(1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:304].
(2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:305].
(3) SHALL contain exactly one [1..1] section [CONF:306].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
110 DSTU (Revision 2013)
The following XML example outlines how to use the Generic Episodic Document template:
<ClinicalDocument classCode=”DOCCLIN” moodCode=”EVN”>
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<!-- Conforms to the BC PITO EMR Standard Headerspecification -->
<templateId root="2.16.840.1.113883.3.1818.10.7.1"/>
<!-- Conforms to the BC PITO EMR Generic Episodic Document specification -->
<templateId root="2.16.840.1.113883.3.1818.10.1.2"/>
…
<component typeCode=”COMP” contextConductionInd=”true”>
<structuredBody classCode-“DOCBODY” moodCode=”EVN”>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<languageCode code="en-CA" displayName="English, Canada"
codeSystem="2.16.840.1.113883.1.11.11526" codeSystemName="Internet Society
Language"/>
<component typeCode=”COMP” contextConductionInd=”true”>
<section>
. . .
</section>
<section>
. . .
</section>
</component>
</structuredBody>
</component>
</ClinicalDocument>
Figure 30: Generic Episodic Document entry example
The set of StructuredBody/component elements SHALL conform to the following constraints:
1) MAY include one Advance Directives section, such that component/section,
a) MAY contain zero or one [0..1] Advance Directives [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.2), or SHOULD contain exactly one [1..1] Advance
Directives [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.2.1)
[CONF:SEC- 26.1].
2) MAY include one Alerts section, such that component/section,
a) MAY contain zero or one [0..1] Alerts [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.3), or SHOULD contain exactly one [1..1] Alerts [with
entries] (templateId: 2.16.840.1.113883.3.1818.10.2.3.1) [CONF:SEC- 27.1].
3) MAY include one Allergies & Intolerances - Reaction List section, such that component/section,
a) MAY contain zero or one [0..1] Allergies & Intolerances (Reaction List) [without entries]
(templateId: 2.16.840.1.113883.3.1818.10.2.4), or SHOULD contain exactly one [1..1]
Allergies & Intolerances (Reaction List) [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.4.1) [CONF:SEC- 28.1].
4) MAY include one Care Plan / Reminders / Tasks section, such that component/section,
a) SHALL contain exactly one [1..1] Care Plan / Reminders / Tasks [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.7) [CONF:SEC- 31.1].
5) MAY include one Clinically Measured Observations section, such that component/section,
a) MAY contain zero or one [0..1] Clinical Measured Observations [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.8), or SHOULD contain exactly one [1..1] Clinical
Measured Observations [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.8.1) [CONF:SEC- 32.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
111 DSTU (Revision 2013)
6) MAY include one Current Medications section, such that component/section,
a) MAY contain zero or one [0..1] Current Medications [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.9), or SHOULD contain exactly one [1..1] Current
Medications [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.9.1)
[CONF:SEC- 33.1].
7) MAY include one Developmental Observations section, such that component/section,
a) MAY contain zero or one [0..1] Developmental Observations [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.10), or SHOULD contain exactly one [1..1] Developmental
Observations [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.10.1)
[CONF:SEC- 34.1].
8) MAY include one Devices section, such that component/section,
a) MAY contain zero or one [0..1] Devices [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.11), or SHOULD contain exactly one [1..1] Devices [with
entries] (templateId: 2.16.840.1.113883.3.1818.10.2.11.1) [CONF:SEC- 35.1].
9) MAY include one Encounter History & Notes section, such that component/section,
a) MAY contain zero or one [0..1] Encounter History & Notes [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.12), or SHOULD contain exactly one [1..1] Encounter
History & Notes [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.12.1)
[CONF:SEC- 36.1].
10) MAY include one Family History section, such that component/section,
a) MAY contain zero or one [0..1] Family History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.13), or SHOULD contain exactly one [1..1] Family History
[with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.13.1) [CONF:SEC- 37.1].
11) MAY include one Immunizations List section, such that component/section,
a) MAY contain zero or one [0..1] Immunizations List [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.14), or SHOULD contain exactly one [1..1] Immunizations
List [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.14.1) [CONF:SEC-
38.1].
12) MAY include one Investigative Procedure History section, such that component/section,
a) MAY contain zero or one [0..1] Investigative Procedure History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.15), or SHOULD contain exactly one [1..1] Investigative
Procedure History [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.15.1)
[CONF:SEC- 39.1].
13) MAY include one Laboratory Results & Reports section, such that component/section,
a) MAY contain zero or one [0..1] Laboratory Results & Reports [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.16), or SHOULD contain exactly one [1..1] Laboratory
Results & Reports [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.16.1)
[CONF:SEC- 40.1].
14) MAY include one Medical History section, such that component/section,
a) MAY contain zero or one [0..1] Medical History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.17), or SHOULD contain exactly one [1..1] Medical History
[with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.17.1) [CONF:SEC- 41.1].
15) MAY include one Medical Imaging Results & Reports section, such that component/section,
a) MAY contain zero or one [0..1] Medical Imaging Results & Reports [without entries]
(templateId: 2.16.840.1.113883.3.1818.10.2.18), or SHOULD contain exactly one
[1..1] Medical Imaging Results & Reports [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.18.1) [CONF:SEC- 42.1].
16) MAY include one Medications & Prescriptions - Medication List section, such that component/section,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
112 DSTU (Revision 2013)
a) MAY contain zero or one [0..1] Medications & Prescriptions - Medication List [without entries]
(templateId: 2.16.840.1.113883.3.1818.10.2.19), or SHOULD contain exactly one
[1..1] Medications & Prescriptions - Medication List [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.19.1) [CONF:SEC- 43.1].
17) MAY include one Orders & Requests section, such that component/section,
a) MAY contain zero or one [0..1] Orders & Requests [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.20), or SHOULD contain exactly one [1..1] Orders &
Requests [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.20.1)
[CONF:SEC- 44.1].
18) MAY include one Problems & Conditions - Problem List section, such that component/section,
a) MAY contain zero or one [0..1] Problems & Conditions - Problem List [without entries]
(templateId: 2.16.840.1.113883.3.1818.10.2.21), or SHOULD contain exactly one
[1..1] Problems & Conditions - Problem List [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.21.1) [CONF:SEC- 45.1].
19) SHALL include one Purpose section, such that component/section,
a) SHALL contain exactly one [1..1] Purpose (templateId:
2.16.840.1.113883.3.1818.10.2.22) [CONF:SEC- 46.1].
20) MAY include one Reproductive Observations section, such that component/section,
a) MAY contain zero or one [0..1] Reproductive Observations [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.23), or SHOULD contain exactly one [1..1] Reproductive
Observations [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.23.1)
[CONF:SEC- 47.1].
21) MAY include one Risk Factors section, such that component/section,
a) MAY contain zero or one [0..1] Risk Factors [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.24), or SHOULD contain exactly one [1..1] Risk Factors
[with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.24.1) [CONF:SEC- 48.1].
22) MAY include one Surgical Procedure History section, such that component/section,
a) MAY contain zero or one [0..1] Surgical Procedure History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.25), or SHOULD contain exactly one [1..1] Surgical
Procedure History [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.25.1)
[CONF:SEC- 49.1].
23) MAY include one Treatment History section, such that component/section,
a) MAY contain zero or one [0..1] Treatment History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.26), or SHOULD contain exactly one [1..1] Treatment
History [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.26.1)
[CONF:SEC- 50.1].
4.3 GENERIC STRUCTURED REFERRAL
[ClinicalDocument: templateId 2.16.840.1.113883.3.1818.10.1.6(open)]
The Generic Structured Referral Document supports the communication of a basic, generic CDA-L2 or
CDA-L3 electronic referral. It is generic in the sense that it is not refined for a particular care path or
specialty.
Table 24: Template Containment for a Generic Structured Referral
Template Name Template Type Template ID (OID)
Generic Structured Referral Document 2.16.840.1.113883.3.1818.10.1.6
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
113 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Advance Directives [with entries] Section 2.16.840.1.113883.3.1818.10.2.2.1
Advanced Directives Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.1
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Advance Directives [without entries] Section 2.16.840.1.113883.3.1818.10.2.2
Alerts [with entries] Section 2.16.840.1.113883.3.1818.10.2.3.1
Alert Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.2
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Alerts [without entries] Section 2.16.840.1.113883.3.1818.10.2.3
Allergies & Intolerances (Reaction List) [with entries]
Section 2.16.840.1.113883.3.1818.10.2.4.1
Allergy & Intolerance Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.3
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Lifestage Observation Entry 2.16.840.1.113883.3.1818.10.4.12
Reaction Observation Entry 2.16.840.1.113883.3.1818.10.4.23
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Status Changes Audit Event Entry 2.16.840.1.113883.3.1818.10.4.31
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Allergies & Intolerances (Reaction List) [without entries]
Section 2.16.840.1.113883.3.1818.10.2.4
Care Plan / Reminders / Tasks [without entries]
Section 2.16.840.1.113883.3.1818.10.2.7
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
114 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Clinical Measured Observations [with entries]
Section 2.16.840.1.113883.3.1818.10.2.8.1
Clinically Measured Observations Organizer
SectionEntry 2.16.840.1.113883.3.1818.10.3.7
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Clinical Measured Observations [without entries]
Section 2.16.840.1.113883.3.1818.10.2.8
Current Medications [with entries] Section 2.16.840.1.113883.3.1818.10.2.9.1
Medication Event SectionEntry 2.16.840.1.113883.3.1818.10.3.18
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Medication Prescription Event Entry 2.16.840.1.113883.3.1818.10.4.20
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Dispense Request (first fill) Entry 2.16.840.1.113883.3.1818.10.4.14
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dispense Request (part fill) Entry 2.16.840.1.113883.3.1818.10.4.33
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dispense Request (refill) Entry 2.16.840.1.113883.3.1818.10.4.34
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dose Observation Entry 2.16.840.1.113883.3.1818.10.4.8
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Instruction Observation Entry 2.16.840.1.113883.3.1818.10.4.35
Medication Dispense Event Entry 2.16.840.1.113883.3.1818.10.4.7
Medication Administration Event
Entry 2.16.840.1.113883.3.1818.10.4.36
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Location Participation Entry 2.16.840.1.113883.3.1818.10.4.13
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Order Indicator Entry 2.16.840.1.113883.3.1818.10.4.37
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Reaction Observation Entry 2.16.840.1.113883.3.1818.10.4.23
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
115 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Unbound Observation Entry 2.16.840.1.113883.3.1818.10.4.32
Current Medications [without entries] Section 2.16.840.1.113883.3.1818.10.2.9
Developmental Observations [with entries] Section 2.16.840.1.113883.3.1818.10.2.10.1
Developmental Observations Organizer SectionEntry 2.16.840.1.113883.3.1818.10.4.6
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Developmental Observations [without entries]
Section 2.16.840.1.113883.3.1818.10.2.10
Devices [with entries] Section 2.16.840.1.113883.3.1818.10.2.11.1
Device Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.8
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Devices [without entries] Section 2.16.840.1.113883.3.1818.10.2.11
Encounter History & Notes [with entries] Section 2.16.840.1.113883.3.1818.10.2.12.1
Encounter Event SectionEntry 2.16.840.1.113883.3.1818.10.3.9
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Provider Participation Entry 2.16.840.1.113883.3.1818.10.4.21
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Encounter History & Notes [without entries]
Section 2.16.840.1.113883.3.1818.10.2.12
Family History [with entries] Section 2.16.840.1.113883.3.1818.10.2.13.1
Family History Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.10
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Lifestage Observation Entry 2.16.840.1.113883.3.1818.10.4.12
Secondary Code (ICD-9) Entry 2.16.840.1.113883.3.1818.10.4.28
Family History [without entries] Section 2.16.840.1.113883.3.1818.10.2.13
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
116 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Immunizations List [with entries] Section 2.16.840.1.113883.3.1818.10.2.14.1
Immunization Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.11
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Location Participation Entry 2.16.840.1.113883.3.1818.10.4.13
Reaction Observation Entry 2.16.840.1.113883.3.1818.10.4.23
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Secondary Code (Drug) Entry 2.16.840.1.113883.3.1818.10.4.27
Immunizations List [without entries] Section 2.16.840.1.113883.3.1818.10.2.14
Investigative Procedure History [with entries]
Section 2.16.840.1.113883.3.1818.10.2.15.1
Care History Event SectionEntry 2.16.840.1.113883.3.1818.10.3.6
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Qualifier Observation Entry 2.16.840.1.113883.3.1818.10.4.22
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Secondary Code (Unbound) Entry 2.16.840.1.113883.3.1818.10.4.29
Investigative Procedure History [without entries]
Section 2.16.840.1.113883.3.1818.10.2.15
Laboratory Results & Reports [with entries]
Section 2.16.840.1.113883.3.1818.10.2.16.1
Laboratory Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.12
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
117 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Result Organizer Entry 2.16.840.1.113883.3.1818.10.4.26
Result Component Entry 2.16.840.1.113883.3.1818.10.4.25
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Laboratory Results & Reports [without entries]
Section 2.16.840.1.113883.3.1818.10.2.16
Medical History [with entries] Section 2.16.840.1.113883.3.1818.10.2.17.1
Problem List Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.15
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Lifestage Observation Entry 2.16.840.1.113883.3.1818.10.4.12
Secondary Code (ICD-9) Entry 2.16.840.1.113883.3.1818.10.4.28
Unbound Observation Entry 2.16.840.1.113883.3.1818.10.4.32
Medical History [without entries] Section 2.16.840.1.113883.3.1818.10.2.17
Medical Imaging Results & Reports [with entries]
Section 2.16.840.1.113883.3.1818.10.2.18.1
Medical Imaging Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.13
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Medical Imaging Results & Reports [without entries]
Section 2.16.840.1.113883.3.1818.10.2.18
Medications & Prescriptions - Medication List [with entries]
Section 2.16.840.1.113883.3.1818.10.2.19.1
Medication Event SectionEntry 2.16.840.1.113883.3.1818.10.3.18
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
118 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Medication Prescription Event Entry 2.16.840.1.113883.3.1818.10.4.20
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Dispense Request (first fill) Entry 2.16.840.1.113883.3.1818.10.4.14
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dispense Request (part fill) Entry 2.16.840.1.113883.3.1818.10.4.33
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dispense Request (refill) Entry 2.16.840.1.113883.3.1818.10.4.34
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dose Observation Entry 2.16.840.1.113883.3.1818.10.4.8
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Instruction Observation Entry 2.16.840.1.113883.3.1818.10.4.35
Medication Dispense Event Entry 2.16.840.1.113883.3.1818.10.4.7
Medication Administration Event
Entry 2.16.840.1.113883.3.1818.10.4.36
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Location Participation Entry 2.16.840.1.113883.3.1818.10.4.13
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Order Indicator Entry 2.16.840.1.113883.3.1818.10.4.37
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Reaction Observation Entry 2.16.840.1.113883.3.1818.10.4.23
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Unbound Observation Entry 2.16.840.1.113883.3.1818.10.4.32
Medications & Prescriptions - Medication List [without entries]
Section 2.16.840.1.113883.3.1818.10.2.19
Orders & Requests [with entries] Section 2.16.840.1.113883.3.1818.10.2.20.1
Order Event SectionEntry 2.16.840.1.113883.3.1818.10.3.14
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
119 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Result Organizer Entry 2.16.840.1.113883.3.1818.10.4.26
Result Component Entry 2.16.840.1.113883.3.1818.10.4.25
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Orders & Requests [without entries] Section 2.16.840.1.113883.3.1818.10.2.20
Problems & Conditions - Problem List [with entries]
Section 2.16.840.1.113883.3.1818.10.2.21.1
Problem List Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.15
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Lifestage Observation Entry 2.16.840.1.113883.3.1818.10.4.12
Secondary Code (ICD-9) Entry 2.16.840.1.113883.3.1818.10.4.28
Unbound Observation Entry 2.16.840.1.113883.3.1818.10.4.32
Problems & Conditions - Problem List [without entries]
Section 2.16.840.1.113883.3.1818.10.2.21
Purpose Section 2.16.840.1.113883.3.1818.10.2.22
Reproductive Observations [with entries] Section 2.16.840.1.113883.3.1818.10.2.23.1
Reproductive Observations Organizer SectionEntry 2.16.840.1.113883.3.1818.10.3.16
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Reproductive Observations [without entries]
Section 2.16.840.1.113883.3.1818.10.2.23
Risk Factors [with entries] Section 2.16.840.1.113883.3.1818.10.2.24.1
Risk Factors Organizer SectionEntry 2.16.840.1.113883.3.1818.10.3.17
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
120 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Risk Factors [without entries] Section 2.16.840.1.113883.3.1818.10.2.24
Surgical Procedure History [with entries] Section 2.16.840.1.113883.3.1818.10.2.25.1
Care History Event SectionEntry 2.16.840.1.113883.3.1818.10.3.6
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Qualifier Observation Entry 2.16.840.1.113883.3.1818.10.4.22
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Secondary Code (Unbound) Entry 2.16.840.1.113883.3.1818.10.4.29
Surgical Procedure History [without entries]
Section 2.16.840.1.113883.3.1818.10.2.25
Treatment History [with entries] Section 2.16.840.1.113883.3.1818.10.2.26.1
Care History Event SectionEntry 2.16.840.1.113883.3.1818.10.3.6
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Qualifier Observation Entry 2.16.840.1.113883.3.1818.10.4.22
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Secondary Code (Unbound) Entry 2.16.840.1.113883.3.1818.10.4.29
Treatment History [without entries] Section 2.16.840.1.113883.3.1818.10.2.26
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
121 DSTU (Revision 2013)
Generic Structured Referral Header Constraints
A Generic Structured Referral SHALL conform to the BC PITO Standard Header Template subject to
additional constraints as follows. Conformant documents:
1) SHALL contain exactly two [2..2] templateId elements such that it,
a) SHALL contain exactly one [1..1] templateId/@root="2.16.840.1.113883.3.1818.10.1.6" to declare conformance to
the Generic Structured Referral clinical document specification.
b) SHALL contain exactly one [1..1] templateId/@root="2.16.840.1.113883.3.1818.10.7.1" to declare conformance to
the required header template.
2) SHALL contain exactly one [1..1] code="57133-1" Referral note (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:4385].
3) SHALL contain at least one [1..*] informationRecipient [CONF:4438].
Generic Structured Referral Body Constraints
A Generic Structured Referral contains both narrative sections and sections requiring coded clinical
statements subject to the following constraints.
A Generic Structured Referral (ClinicalDocument) element:
1) SHALL contain exactly one [1..1] {CDAR2} component [CONF:4372].
a) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:4373].
b) SHALL contain exactly one [1..1] @contextConductionInd [CONF:4374].
c) SHALL contain exactly one [1..1] structuredBody [CONF:4375].
i) SHALL contain exactly one [1..1] @classCode="DOCBODY" document body (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:4376].
ii) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:4377].
iii) MAY contain zero or one [0..1] {CDAR2} confidentialityCode, which SHALL be selected
from ValueSet x_BasicConfidentialityKind 2.16.840.1.113883.2.20.3.139 STATIC [CONF:4378].
iv) MAY contain zero or one [0..1] {CDAR2} languageCode, which SHALL be selected from
ValueSet HumanLanguage 2.16.840.1.113883.1.11.11526 DYNAMIC {CDAR2} [CONF:4379].
v) SHALL contain at least one [1..*] component [CONF:4380].
(1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:4381].
(2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:4382].
(3) SHALL contain exactly one [1..1] section [CONF:4383].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
122 DSTU (Revision 2013)
The following XML example outlines how to use the Generic Structured Referral template:
<ClinicalDocument classCode=”DOCCLIN” moodCode=”EVN”>
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<!-- Conforms to the BC PITO EMR Standard Headerspecification -->
<templateId root="2.16.840.1.113883.3.1818.10.7.1"/>
<!-- Conforms to the BC PITO EMR Generic Structured Referal specification -->
<templateId root="2.16.840.1.113883.3.1818.10.1.6"/>
…
<component typeCode=”COMP” contextConductionInd=”true”>
<structuredBody classCode-“DOCBODY” moodCode=”EVN”>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<languageCode code="en-CA" displayName="English, Canada"
codeSystem="2.16.840.1.113883.1.11.11526" codeSystemName="Internet Society
Language"/>
<component typeCode=”COMP” contextConductionInd=”true”>
<section>
. . .
</section>
<section>
. . .
</section>
</component>
</structuredBody>
</component>
</ClinicalDocument>
Figure 31: Generic Structured Referral entry example
The set of StructuredBody/component elements SHALL conform to the following constraints:
1) MAY include one Advance Directives section, such that component/section,
a) MAY contain zero or one [0..1] Advance Directives [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.2), or SHOULD contain exactly one [1..1] Advance
Directives [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.2.1)
[CONF:SEC- 179.1].
2) MAY include one Alerts section, such that component/section,
a) MAY contain zero or one [0..1] Alerts [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.3), or SHOULD contain exactly one [1..1] Alerts [with
entries] (templateId: 2.16.840.1.113883.3.1818.10.2.3.1) [CONF:SEC- 180.1].
3) MAY include one Allergies & Intolerances - Reaction List section, such that component/section,
a) MAY contain zero or one [0..1] Allergies & Intolerances (Reaction List) [without entries]
(templateId: 2.16.840.1.113883.3.1818.10.2.4), or SHOULD contain exactly one [1..1]
Allergies & Intolerances (Reaction List) [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.4.1) [CONF:SEC- 181.1].
4) MAY include one Care Plan / Reminders / Tasks section, such that component/section,
a) SHALL contain exactly one [1..1] Care Plan / Reminders / Tasks [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.7) [CONF:SEC- 184.1].
5) MAY include one Clinically Measured Observations section, such that component/section,
a) MAY contain zero or one [0..1] Clinical Measured Observations [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.8), or SHOULD contain exactly one [1..1] Clinical
Measured Observations [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.8.1) [CONF:SEC- 185.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
123 DSTU (Revision 2013)
6) MAY include one Current Medications section, such that component/section,
a) MAY contain zero or one [0..1] Current Medications [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.9), or SHOULD contain exactly one [1..1] Current
Medications [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.9.1)
[CONF:SEC- 186.1].
7) MAY include one Developmental Observations section, such that component/section,
a) MAY contain zero or one [0..1] Developmental Observations [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.10), or SHOULD contain exactly one [1..1] Developmental
Observations [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.10.1)
[CONF:SEC- 187.1].
8) MAY include one Devices section, such that component/section,
a) MAY contain zero or one [0..1] Devices [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.11), or SHOULD contain exactly one [1..1] Devices [with
entries] (templateId: 2.16.840.1.113883.3.1818.10.2.11.1) [CONF:SEC- 188.1].
9) MAY include one Encounter History & Notes section, such that component/section,
a) MAY contain zero or one [0..1] Encounter History & Notes [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.12), or SHOULD contain exactly one [1..1] Encounter
History & Notes [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.12.1)
[CONF:SEC- 189.1].
10) MAY include one Family History section, such that component/section,
a) MAY contain zero or one [0..1] Family History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.13), or SHOULD contain exactly one [1..1] Family History
[with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.13.1) [CONF:SEC-
190.1].
11) MAY include one Immunizations List section, such that component/section,
a) MAY contain zero or one [0..1] Immunizations List [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.14), or SHOULD contain exactly one [1..1] Immunizations
List [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.14.1) [CONF:SEC-
191.1].
12) MAY include one Investigative Procedure History section, such that component/section,
a) MAY contain zero or one [0..1] Investigative Procedure History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.15), or SHOULD contain exactly one [1..1] Investigative
Procedure History [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.15.1)
[CONF:SEC- 192.1].
13) MAY include one Laboratory Results & Reports section, such that component/section,
a) MAY contain zero or one [0..1] Laboratory Results & Reports [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.16), or SHOULD contain exactly one [1..1] Laboratory
Results & Reports [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.16.1)
[CONF:SEC- 193.1].
14) MAY include one Medical History section, such that component/section,
a) MAY contain zero or one [0..1] Medical History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.17), or SHOULD contain exactly one [1..1] Medical History
[with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.17.1) [CONF:SEC-
194.1].
15) MAY include one Medical Imaging Results & Reports section, such that component/section,
a) MAY contain zero or one [0..1] Medical Imaging Results & Reports [without entries]
(templateId: 2.16.840.1.113883.3.1818.10.2.18), or SHOULD contain exactly one
[1..1] Medical Imaging Results & Reports [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.18.1) [CONF:SEC- 195.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
124 DSTU (Revision 2013)
16) MAY include one Medications & Prescriptions - Medication List section, such that component/section,
a) MAY contain zero or one [0..1] Medications & Prescriptions - Medication List [without entries]
(templateId: 2.16.840.1.113883.3.1818.10.2.19), or SHOULD contain exactly one
[1..1] Medications & Prescriptions - Medication List [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.19.1) [CONF:SEC- 196.1].
17) MAY include one Orders & Requests section, such that component/section,
a) MAY contain zero or one [0..1] Orders & Requests [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.20), or SHOULD contain exactly one [1..1] Orders &
Requests [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.20.1)
[CONF:SEC- 197.1].
18) MAY include one Problems & Conditions - Problem List section, such that component/section,
a) MAY contain zero or one [0..1] Problems & Conditions - Problem List [without entries]
(templateId: 2.16.840.1.113883.3.1818.10.2.21), or SHOULD contain exactly one
[1..1] Problems & Conditions - Problem List [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.21.1) [CONF:SEC- 198.1].
19) SHALL include one Purpose section, such that component/section,
a) SHALL contain exactly one [1..1] Purpose (templateId:
2.16.840.1.113883.3.1818.10.2.22) [CONF:SEC- 199.1].
20) MAY include one Reproductive Observations section, such that component/section,
a) MAY contain zero or one [0..1] Reproductive Observations [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.23), or SHOULD contain exactly one [1..1] Reproductive
Observations [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.23.1)
[CONF:SEC- 200.1].
21) MAY include one Risk Factors section, such that component/section,
a) MAY contain zero or one [0..1] Risk Factors [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.24), or SHOULD contain exactly one [1..1] Risk Factors
[with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.24.1) [CONF:SEC-
201.1].
22) MAY include one Surgical Procedure History section, such that component/section,
a) MAY contain zero or one [0..1] Surgical Procedure History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.25), or SHOULD contain exactly one [1..1] Surgical
Procedure History [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.25.1)
[CONF:SEC- 202.1].
23) MAY include one Treatment History section, such that component/section,
a) MAY contain zero or one [0..1] Treatment History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.26), or SHOULD contain exactly one [1..1] Treatment
History [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.26.1)
[CONF:SEC- 203.1].
4.4 GENERIC UNSTRUCTURED REFERRAL
[ClinicalDocument: templateId 2.16.840.1.113883.3.1818.10.1.5(open)]
A Generic Unstructured Referral CDA Document may be used to communicate clinical information in
support of a referral workflow when the patient record is captured in an unstructured format or when it is
desirable to send information in an unstructured manner to accommodate the capabilities of the targeted
receiving system. This document was derived from the Unstructured Document in these specifications
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
125 DSTU (Revision 2013)
but is intended to provide a basis for refinement, particularly in terms of the header, to support eReferral
data exchanges and use cases.
Table 25: Template Containment for a Generic Unstructured Referral
Template Name Template Type Template ID (OID)
Generic Unstructured Referral Document 2.16.840.1.113883.3.1818.10.1.5
Generic Unstructured Referral Header Constraints
A Generic Unstructured Referral SHALL conform to the BC PITO Standard Header Template subject to
additional constraints as follows. Conformant documents:
1) SHALL contain exactly two [2..2] templateId elements such that it,
a) SHALL contain exactly one [1..1] templateId/@root="2.16.840.1.113883.3.1818.10.1.5" to declare conformance to
the Generic Unstructured Referral clinical document specification.
b) SHALL contain exactly one [1..1] templateId/@root="2.16.840.1.113883.3.1818.10.7.1" to declare conformance to
the required header template.
2) SHALL contain at least one [1..*] informationRecipient [CONF:4435].
Generic Unstructured Referral Body Constraints
A Generic Unstructured Referral must include a nonXMLBody component with a single text element. The
text element can reference an external file using a reference element, or include unstructured content
directly. A Generic Unstructured Referral (ClinicalDocument) element:
1) SHALL contain exactly one [1..1] {CDAR2} component [CONF:4363].
a) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:4364].
b) SHALL contain exactly one [1..1] @contextConductionInd [CONF:4365].
c) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} nonXMLBody [CONF:4366].
d) SHALL contain exactly one [1..1] @classCode="DOCBODY" document body (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:4367].
e) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:4368].
f) SHALL contain exactly one [1..1] text [CONF:4369].
g) MAY contain zero or one [0..1] {CDAR2} confidentialityCode, which SHALL be selected from
ValueSet x_BasicConfidentialityKind 2.16.840.1.113883.2.20.3.139 STATIC [CONF:4370].
h) MAY contain zero or one [0..1] {CDAR2} languageCode, which SHALL be selected from ValueSet
HumanLanguage 2.16.840.1.113883.1.11.11526 DYNAMIC {CDAR2} [CONF:4371].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
126 DSTU (Revision 2013)
The following XML example outlines how to use the Generic Unstructured Referral template:
<ClinicalDocument classCode=”DOCCLIN” moodCode=”EVN”>
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<!-- Conforms to the BC PITO Standard Header specification -->
<templateId root="2.16.840.1.113883.3.1818.10.7.1"/>
<!-- Conforms to the BC PITO Generic Unstructured Referral document specification
-->
<templateId root="2.16.840.1.113883.3.1818.10.1.5"/>
...
Full nonXMLBody example with embedded content:
<component typeCode=”COMP” contextConductionInd=”true”>
<nonXMLBody classCode-“DOCBODY” moodCode=”EVN”>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<languageCode code="en-CA" displayName="English, Canada"
codeSystem="2.16.840.1.113883.1.11.11526" codeSystemName="Internet Society
Language"/>
<text mediaType="text/rtf" representation="B64">e1xydGY...</text>
</nonXMLBody>
</component>
Additional nonXMLBody example with referenced content:
<component>
<nonXMLBody>
<text>
<reference value="UD_sample.pdf"/>
</text>
</nonXMLBody>
</component>
Additional nonXMLBody example with compressed content:
<component>
<nonXMLBody>
<text mediaType="text/rtf" representation="B64"
compression="DF">dhUhkasd437hbjfQS7…</text>
</nonXMLBody>
</component>
Figure 32: Generic Unstructured Referral entry example
4.5 PATIENT TRANSFER
[ClinicalDocument: templateId 2.16.840.1.113883.3.1818.10.1.3(open)]
The Patient Transfer Document supports the transfer of a significant portion of a single patient chart. The
dominant use case scenario arises when a patient moves or for other reasons comes under the care of a
new physician and the new physician seeks to initiate the chart for the patient by requesting information
from the previous physician. This document is designed to enable the complete or near complete transfer
of a chart so as to ensure the progressive establishment of a life-time patient record notwithstanding the
fact that the patient may come under the care of a number of physicians.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
127 DSTU (Revision 2013)
Special Conformance Requirements for Patient Transfer
Notwithstanding the establishment of section or element optionality, systems claiming conformance with
the PITO E2E-DTC specification SHALL include all optional elements if these elements can reasonable
and safely be included in a Patient Transfer document instance. Furthermore, recipients of e Patient
Transfer document who claim conformance with the PITO E2E-DTC specification and who have
analogous data elements or capabilities to store this data SHALL support the full and complete import of
such document instances.
Table 26: Template Containment for a Patient Transfer
Template Name Template Type Template ID (OID)
Patient Transfer Document 2.16.840.1.113883.3.1818.10.1.3
Advance Directives [with entries] Section 2.16.840.1.113883.3.1818.10.2.2.1
Advanced Directives Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.1
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Advance Directives [without entries] Section 2.16.840.1.113883.3.1818.10.2.2
Alerts [with entries] Section 2.16.840.1.113883.3.1818.10.2.3.1
Alert Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.2
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Alerts [without entries] Section 2.16.840.1.113883.3.1818.10.2.3
Allergies & Intolerances (Reaction List) [with entries]
Section 2.16.840.1.113883.3.1818.10.2.4.1
Allergy & Intolerance Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.3
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Lifestage Observation Entry 2.16.840.1.113883.3.1818.10.4.12
Reaction Observation Entry 2.16.840.1.113883.3.1818.10.4.23
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
128 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Status Changes Audit Event Entry 2.16.840.1.113883.3.1818.10.4.31
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Allergies & Intolerances (Reaction List) [without entries]
Section 2.16.840.1.113883.3.1818.10.2.4
Care Plan / Reminders / Tasks [without entries]
Section 2.16.840.1.113883.3.1818.10.2.7
Clinical Measured Observations [with entries]
Section 2.16.840.1.113883.3.1818.10.2.8.1
Clinically Measured Observations Organizer
SectionEntry 2.16.840.1.113883.3.1818.10.3.7
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Clinical Measured Observations [without entries]
Section 2.16.840.1.113883.3.1818.10.2.8
Developmental Observations [with entries] Section 2.16.840.1.113883.3.1818.10.2.10.1
Developmental Observations Organizer SectionEntry 2.16.840.1.113883.3.1818.10.4.6
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Developmental Observations [without entries]
Section 2.16.840.1.113883.3.1818.10.2.10
Devices [with entries] Section 2.16.840.1.113883.3.1818.10.2.11.1
Device Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.8
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Devices [without entries] Section 2.16.840.1.113883.3.1818.10.2.11
Encounter History & Notes [with entries] Section 2.16.840.1.113883.3.1818.10.2.12.1
Encounter Event SectionEntry 2.16.840.1.113883.3.1818.10.3.9
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Provider Participation Entry 2.16.840.1.113883.3.1818.10.4.21
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
129 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Encounter History & Notes [without entries]
Section 2.16.840.1.113883.3.1818.10.2.12
Family History [with entries] Section 2.16.840.1.113883.3.1818.10.2.13.1
Family History Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.10
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Lifestage Observation Entry 2.16.840.1.113883.3.1818.10.4.12
Secondary Code (ICD-9) Entry 2.16.840.1.113883.3.1818.10.4.28
Family History [without entries] Section 2.16.840.1.113883.3.1818.10.2.13
Immunizations List [with entries] Section 2.16.840.1.113883.3.1818.10.2.14.1
Immunization Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.11
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Location Participation Entry 2.16.840.1.113883.3.1818.10.4.13
Reaction Observation Entry 2.16.840.1.113883.3.1818.10.4.23
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Secondary Code (Drug) Entry 2.16.840.1.113883.3.1818.10.4.27
Immunizations List [without entries] Section 2.16.840.1.113883.3.1818.10.2.14
Investigative Procedure History [with entries]
Section 2.16.840.1.113883.3.1818.10.2.15.1
Care History Event SectionEntry 2.16.840.1.113883.3.1818.10.3.6
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Qualifier Observation Entry 2.16.840.1.113883.3.1818.10.4.22
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
130 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Secondary Code (Unbound) Entry 2.16.840.1.113883.3.1818.10.4.29
Investigative Procedure History [without entries]
Section 2.16.840.1.113883.3.1818.10.2.15
Laboratory Results & Reports [with entries]
Section 2.16.840.1.113883.3.1818.10.2.16.1
Laboratory Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.12
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Result Organizer Entry 2.16.840.1.113883.3.1818.10.4.26
Result Component Entry 2.16.840.1.113883.3.1818.10.4.25
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Laboratory Results & Reports [without entries]
Section 2.16.840.1.113883.3.1818.10.2.16
Medical History [with entries] Section 2.16.840.1.113883.3.1818.10.2.17.1
Problem List Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.15
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Lifestage Observation Entry 2.16.840.1.113883.3.1818.10.4.12
Secondary Code (ICD-9) Entry 2.16.840.1.113883.3.1818.10.4.28
Unbound Observation Entry 2.16.840.1.113883.3.1818.10.4.32
Medical History [without entries] Section 2.16.840.1.113883.3.1818.10.2.17
Medical Imaging Results & Reports [with entries]
Section 2.16.840.1.113883.3.1818.10.2.18.1
Medical Imaging Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.13
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
131 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Medical Imaging Results & Reports [without entries]
Section 2.16.840.1.113883.3.1818.10.2.18
Medications & Prescriptions - Medication List [with entries]
Section 2.16.840.1.113883.3.1818.10.2.19.1
Medication Event SectionEntry 2.16.840.1.113883.3.1818.10.3.18
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Medication Prescription Event Entry 2.16.840.1.113883.3.1818.10.4.20
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Dispense Request (first fill) Entry 2.16.840.1.113883.3.1818.10.4.14
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dispense Request (part fill) Entry 2.16.840.1.113883.3.1818.10.4.33
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dispense Request (refill) Entry 2.16.840.1.113883.3.1818.10.4.34
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Dose Observation Entry 2.16.840.1.113883.3.1818.10.4.8
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Instruction Observation Entry 2.16.840.1.113883.3.1818.10.4.35
Medication Dispense Event Entry 2.16.840.1.113883.3.1818.10.4.7
Medication Administration Event
Entry 2.16.840.1.113883.3.1818.10.4.36
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Location Participation Entry 2.16.840.1.113883.3.1818.10.4.13
Medication Fill Interval Entry 2.16.840.1.113883.3.1818.10.4.11
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Medication Identification Entry 2.16.840.1.113883.3.1818.10.4.16
Order Indicator Entry 2.16.840.1.113883.3.1818.10.4.37
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Reaction Observation Entry 2.16.840.1.113883.3.1818.10.4.23
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Severity Observation Entry 2.16.840.1.113883.3.1818.10.4.30
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
132 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Unbound Observation Entry 2.16.840.1.113883.3.1818.10.4.32
Medications & Prescriptions - Medication List [without entries]
Section 2.16.840.1.113883.3.1818.10.2.19
Orders & Requests [with entries] Section 2.16.840.1.113883.3.1818.10.2.20.1
Order Event SectionEntry 2.16.840.1.113883.3.1818.10.3.14
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Result Organizer Entry 2.16.840.1.113883.3.1818.10.4.26
Result Component Entry 2.16.840.1.113883.3.1818.10.4.25
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19
Orders & Requests [without entries] Section 2.16.840.1.113883.3.1818.10.2.20
Problems & Conditions - Problem List [with entries]
Section 2.16.840.1.113883.3.1818.10.2.21.1
Problem List Observation SectionEntry 2.16.840.1.113883.3.1818.10.3.15
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Lifestage Observation Entry 2.16.840.1.113883.3.1818.10.4.12
Secondary Code (ICD-9) Entry 2.16.840.1.113883.3.1818.10.4.28
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
133 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Unbound Observation Entry 2.16.840.1.113883.3.1818.10.4.32
Problems & Conditions - Problem List [without entries]
Section 2.16.840.1.113883.3.1818.10.2.21
Purpose Section 2.16.840.1.113883.3.1818.10.2.22
Reproductive Observations [with entries] Section 2.16.840.1.113883.3.1818.10.2.23.1
Reproductive Observations Organizer SectionEntry 2.16.840.1.113883.3.1818.10.3.16
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Reproductive Observations [without entries]
Section 2.16.840.1.113883.3.1818.10.2.23
Risk Factors [with entries] Section 2.16.840.1.113883.3.1818.10.2.24.1
Risk Factors Organizer SectionEntry 2.16.840.1.113883.3.1818.10.3.17
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Risk Factors [without entries] Section 2.16.840.1.113883.3.1818.10.2.24
Surgical Procedure History [with entries] Section 2.16.840.1.113883.3.1818.10.2.25.1
Care History Event SectionEntry 2.16.840.1.113883.3.1818.10.3.6
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Qualifier Observation Entry 2.16.840.1.113883.3.1818.10.4.22
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Secondary Code (Unbound) Entry 2.16.840.1.113883.3.1818.10.4.29
Surgical Procedure History [without entries]
Section 2.16.840.1.113883.3.1818.10.2.25
Treatment History [with entries] Section 2.16.840.1.113883.3.1818.10.2.26.1
Care History Event SectionEntry 2.16.840.1.113883.3.1818.10.3.6
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
134 DSTU (Revision 2013)
Template Name Template Type Template ID (OID)
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Qualifier Observation Entry 2.16.840.1.113883.3.1818.10.4.22
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Informant Participation Entry 2.16.840.1.113883.3.1818.10.4.10
Record ID Link Entry 2.16.840.1.113883.3.1818.10.4.38
Secondary Code (Unbound) Entry 2.16.840.1.113883.3.1818.10.4.29
Treatment History [without entries] Section 2.16.840.1.113883.3.1818.10.2.26
Unclassified Documents [with entries] Section 2.16.840.1.113883.3.1818.10.2.27.1
Unclassified Documents Organizer SectionEntry 2.16.840.1.113883.3.1818.10.3.19
Attachment Entry 2.16.840.1.113883.3.1818.10.4.1
Comment Observation Entry 2.16.840.1.113883.3.1818.10.4.3
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Date Observation Entry 2.16.840.1.113883.3.1818.10.4.4
Encapsulated Data Entry 2.16.840.1.113883.3.1818.10.4.9
Author Participation Entry 2.16.840.1.113883.3.1818.10.4.2
Patient Transfer Header Constraints
A Patient Transfer SHALL conform to the BC PITO Standard Header Template subject to additional
constraints as follows. Conformant documents:
1) SHALL contain exactly two [2..2] templateId elements such that it,
a) SHALL contain exactly one [1..1] templateId/@root="2.16.840.1.113883.3.1818.10.1.3" to declare conformance to
the Patient Transfer clinical document specification.
b) SHALL contain exactly one [1..1] templateId/@root="2.16.840.1.113883.3.1818.10.7.1" to declare conformance to
the required header template.
2) SHALL contain exactly one [1..1] code="28616-1" Physician transfer note (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:4384].
3) SHALL contain at least one [1..*] informationRecipient [CONF:4426].
Patient Transfer Body Constraints
A Patient Transfer contains both narrative sections and sections requiring coded clinical statements
subject to the following constraints.
A Patient Transfer (ClinicalDocument) element:
1) SHALL contain exactly one [1..1] {CDAR2} component [CONF:349].
a) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:350].
b) SHALL contain exactly one [1..1] @contextConductionInd [CONF:351].
c) SHALL contain exactly one [1..1] structuredBody [CONF:352].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
135 DSTU (Revision 2013)
i) SHALL contain exactly one [1..1] @classCode="DOCBODY" document body (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:353].
ii) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:354].
iii) MAY contain zero or one [0..1] {CDAR2} confidentialityCode, which SHALL be selected
from ValueSet x_BasicConfidentialityKind 2.16.840.1.113883.2.20.3.139 STATIC [CONF:355].
iv) MAY contain zero or one [0..1] {CDAR2} languageCode, which SHALL be selected from
ValueSet HumanLanguage 2.16.840.1.113883.1.11.11526 DYNAMIC {CDAR2} [CONF:356].
v) SHALL contain at least one [1..*] component [CONF:357].
(1) SHALL contain exactly one [1..1] @typeCode="DRIV" derived (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:358].
(2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:359].
The following XML example outlines how to use the Patient Transfer template:
<ClinicalDocument classCode=”DOCCLIN” moodCode=”EVN”>
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<!-- Conforms to the BC PITO Standard Header specification -->
<templateId root="2.16.840.1.113883.3.1818.10.7.1"/>
<!-- Conforms to the BC PITO EMR Patient Transfer Document specification -->
<templateId root="2.16.840.1.113883.3.1818.10.1.3"/>
…
<component typeCode=”COMP” contextConductionInd=”true”>
<structuredBody classCode-“DOCBODY” moodCode=”EVN”>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<languageCode code="en-CA" displayName="English, Canada"
codeSystem="2.16.840.1.113883.1.11.11526" codeSystemName="Internet Society
Language"/>
<component typeCode=”COMP” contextConductionInd=”true”>
<section>
. . .
</section>
<section>
. . .
</section>
</component>
</structuredBody>
</component>
</ClinicalDocument>
Figure 33: Patient Transfer entry example
The set of StructuredBody/component elements SHALL conform to the following constraints:
1) SHALL include one Advance Directives section, such that component/section,
a) MAY contain zero or one [0..1] Advance Directives [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.2), or SHOULD contain exactly one [1..1] Advance
Directives [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.2.1)
[CONF:SEC- 51.1].
2) SHOULD include one Alerts section, such that component/section,
a) MAY contain zero or one [0..1] Alerts [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.3), or SHOULD contain exactly one [1..1] Alerts [with
entries] (templateId: 2.16.840.1.113883.3.1818.10.2.3.1) [CONF:SEC- 52.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
136 DSTU (Revision 2013)
3) SHALL include one Allergies & Intolerances - Reaction List section, such that component/section,
a) MAY contain zero or one [0..1] Allergies & Intolerances (Reaction List) [without entries]
(templateId: 2.16.840.1.113883.3.1818.10.2.4), or SHOULD contain exactly one [1..1]
Allergies & Intolerances (Reaction List) [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.4.1) [CONF:SEC- 53.1].
4) MAY include one Care Plan / Reminders / Tasks section, such that component/section,
a) SHALL contain exactly one [1..1] Care Plan / Reminders / Tasks [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.7) [CONF:SEC- 56.1].
5) SHOULD include one Clinically Measured Observations section, such that component/section,
a) MAY contain zero or one [0..1] Clinical Measured Observations [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.8), or SHOULD contain exactly one [1..1] Clinical
Measured Observations [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.8.1) [CONF:SEC- 57.1].
6) MAY include one Developmental Observations section, such that component/section,
a) MAY contain zero or one [0..1] Developmental Observations [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.10), or SHOULD contain exactly one [1..1] Developmental
Observations [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.10.1)
[CONF:SEC- 59.1].
7) MAY include one Devices section, such that component/section,
a) MAY contain zero or one [0..1] Devices [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.11), or SHOULD contain exactly one [1..1] Devices [with
entries] (templateId: 2.16.840.1.113883.3.1818.10.2.11.1) [CONF:SEC- 60.1].
8) SHOULD include one Encounter History & Notes section, such that component/section,
a) MAY contain zero or one [0..1] Encounter History & Notes [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.12), or SHOULD contain exactly one [1..1] Encounter
History & Notes [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.12.1)
[CONF:SEC- 61.1].
9) SHOULD include one Family History section, such that component/section,
a) MAY contain zero or one [0..1] Family History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.13), or SHOULD contain exactly one [1..1] Family History
[with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.13.1) [CONF:SEC- 62.1].
10) SHOULD include one Immunizations List section, such that component/section,
a) MAY contain zero or one [0..1] Immunizations List [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.14), or SHOULD contain exactly one [1..1] Immunizations
List [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.14.1) [CONF:SEC-
63.1].
11) SHOULD include one Investigative Procedure History section, such that component/section,
a) MAY contain zero or one [0..1] Investigative Procedure History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.15), or SHOULD contain exactly one [1..1] Investigative
Procedure History [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.15.1)
[CONF:SEC- 64.1].
12) SHOULD include one Laboratory Results & Reports section, such that component/section,
a) MAY contain zero or one [0..1] Laboratory Results & Reports [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.16), or SHOULD contain exactly one [1..1] Laboratory
Results & Reports [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.16.1)
[CONF:SEC- 65.1].
13) SHOULD include one Medical History section, such that component/section,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
137 DSTU (Revision 2013)
a) MAY contain zero or one [0..1] Medical History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.17), or SHOULD contain exactly one [1..1] Medical History
[with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.17.1) [CONF:SEC- 66.1].
14) SHOULD include one Medical Imaging Results & Reports section, such that component/section,
a) MAY contain zero or one [0..1] Medical Imaging Results & Reports [without entries]
(templateId: 2.16.840.1.113883.3.1818.10.2.18), or SHOULD contain exactly one
[1..1] Medical Imaging Results & Reports [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.18.1) [CONF:SEC- 67.1].
15) SHALL include one Medications & Prescriptions - Medication List section, such that component/section,
a) MAY contain zero or one [0..1] Medications & Prescriptions - Medication List [without entries]
(templateId: 2.16.840.1.113883.3.1818.10.2.19), or SHOULD contain exactly one
[1..1] Medications & Prescriptions - Medication List [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.19.1) [CONF:SEC- 68.1].
16) SHOULD include one Orders & Requests section, such that component/section,
a) MAY contain zero or one [0..1] Orders & Requests [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.20), or SHOULD contain exactly one [1..1] Orders &
Requests [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.20.1)
[CONF:SEC- 69.1].
17) SHALL include one Problems & Conditions - Problem List section, such that component/section,
a) MAY contain zero or one [0..1] Problems & Conditions - Problem List [without entries]
(templateId: 2.16.840.1.113883.3.1818.10.2.21), or SHOULD contain exactly one
[1..1] Problems & Conditions - Problem List [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.21.1) [CONF:SEC- 70.1].
18) MAY include one Purpose section, such that component/section,
a) SHALL contain exactly one [1..1] Purpose (templateId:
2.16.840.1.113883.3.1818.10.2.22) [CONF:SEC- 71.1].
19) SHOULD include one Reproductive Observations section, such that component/section,
a) MAY contain zero or one [0..1] Reproductive Observations [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.23), or SHOULD contain exactly one [1..1] Reproductive
Observations [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.23.1)
[CONF:SEC- 72.1].
20) SHOULD include one Risk Factors section, such that component/section,
a) MAY contain zero or one [0..1] Risk Factors [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.24), or SHOULD contain exactly one [1..1] Risk Factors
[with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.24.1) [CONF:SEC- 73.1].
21) SHOULD include one Surgical Procedure History section, such that component/section,
a) MAY contain zero or one [0..1] Surgical Procedure History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.25), or SHOULD contain exactly one [1..1] Surgical
Procedure History [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.25.1)
[CONF:SEC- 74.1].
22) SHOULD include one Treatment History section, such that component/section,
a) MAY contain zero or one [0..1] Treatment History [without entries] (templateId:
2.16.840.1.113883.3.1818.10.2.26), or SHOULD contain exactly one [1..1] Treatment
History [with entries] (templateId: 2.16.840.1.113883.3.1818.10.2.26.1)
[CONF:SEC- 75.1].
23) SHOULD include one Unclassified Documents section, such that component/section,
a) SHALL contain exactly one [1..1] Unclassified Documents [with entries] (templateId:
2.16.840.1.113883.3.1818.10.2.27.1) [CONF:SEC- 205.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
138 DSTU (Revision 2013)
4.6 UNSTRUCTURED DOCUMENT
[ClinicalDocument: templateId 2.16.840.1.113883.3.1818.10.1.4(open)]
The generic Unstructured Document template may be used to communicate clinical information when the
patient record is captured in an unstructured format or when it is desirable to send information in an
unstructured manner to accommodate the capabilities of the targeted receiving system.
Table 27: Template Containment for an Unstructured Document
Template Name Template Type Template ID (OID)
Unstructured Document Document 2.16.840.1.113883.3.1818.10.1.4
Unstructured Document Header Constraints
An Unstructured Document SHALL conform to the BC PITO Standard Header Template subject to
additional constraints as follows. Conformant documents:
1) SHALL contain exactly two [2..2] templateId elements such that it,
a) SHALL contain exactly one [1..1] templateId/@root="2.16.840.1.113883.3.1818.10.1.4" to declare conformance to
the Unstructured Document clinical document specification.
b) SHALL contain exactly one [1..1] templateId/@root="2.16.840.1.113883.3.1818.10.7.1" to declare conformance to
the required header template.
2) SHALL contain at least one [1..*] informationRecipient [CONF:4432].
Unstructured Document Body Constraints
An Unstructured Document must include a nonXMLBody component with a single text element. The text
element can reference an external file using a reference element, or include unstructured content directly.
An Unstructured Document (ClinicalDocument) element:
1) SHALL contain exactly one [1..1] {CDAR2} component [CONF:286].
a) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:287].
b) SHALL contain exactly one [1..1] @contextConductionInd [CONF:288].
c) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} nonXMLBody [CONF:289].
i) SHALL contain exactly one [1..1] @classCode="DOCBODY" document body (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:290].
ii) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:291].
iii) SHALL contain exactly one [1..1] text [CONF:292] such that it,
(1) SHALL conform to the PITO Encapsulated Data (ED) Data Type data type constraint
template (2.16.840.1.113883.3.1818.10.5.7) [CONF:292.81].
iv) MAY contain zero or one [0..1] {CDAR2} confidentialityCode, which SHALL be selected
from ValueSet x_BasicConfidentialityKind 2.16.840.1.113883.2.20.3.139 STATIC [CONF:293].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
139 DSTU (Revision 2013)
v) MAY contain zero or one [0..1] {CDAR2} languageCode, which SHALL be selected from
ValueSet HumanLanguage 2.16.840.1.113883.1.11.11526 DYNAMIC {CDAR2} [CONF:294].
The following XML example outlines how to use the Unstructured Document template:
<ClinicalDocument classCode=”DOCCLIN” moodCode=”EVN”>
<typeId root="2.16.840.1.113883.1.3" extension="POCD_HD000040"/>
<!-- Conforms to the BC PITO Standard Header specification -->
<templateId root="2.16.840.1.113883.3.1818.10.7.1"/>
<!-- Conforms to the BC PITO Unstructured Document specification -->
<templateId root="2.16.840.1.113883.3.1818.10.1.4"/>
...
Full nonXMLBody example with embedded content:
<component typeCode=”COMP” contextConductionInd=”true”>
<nonXMLBody classCode-“DOCBODY” moodCode=”EVN”>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<languageCode code="en-CA" displayName="English, Canada"
codeSystem="2.16.840.1.113883.1.11.11526" codeSystemName="Internet Society
Language"/>
<text mediaType="text/rtf" representation="B64">e1xydGY...</text>
</nonXMLBody>
</component>
Additional nonXMLBody example with referenced content:
<component>
<nonXMLBody>
<text>
<reference value="UD_sample.pdf"/>
</text>
</nonXMLBody>
</component>
Additional nonXMLBody example with compressed content:
<component>
<nonXMLBody>
<text mediaType="text/rtf" representation="B64"
compression="DF">dhUhkasd437hbjfQS7…</text>
</nonXMLBody>
</component>
Figure 34: Unstructured Document entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
140 DSTU (Revision 2013)
5.0 SECTION TEMPLATES This chapter contains the Section Templates referenced by one or more of the Document Templates of
the PITO E2E-DTC Specification. These templates describe the purpose of each section and the section-
level constraints.
Section Templates are always included in a document.
Each Section Templates contains the following:
LOINC section code
Template metadata (e.g., templateId, etc.)
Section title
Requirements for a text element
Description and explanatory narrative
Section Entry Templates names and IDs for referenced templates (required and optional)
Section Templates may also contain the following:
Other Design Considerations
Section Template Types
Section Templates define and constrain the format of a CDA body section. There are two flavours of
Section template used within this guide:
Section with entries required (CDA-L3),
Section with entries disallowed (CDA-L2)
The Section Template will always start at the <Section> element. If entries are allowed (optional or
required) the applicable Section Template will have an <entry> component and a reference to the
Section-Entry template that is applicable to the section.
When one of these templates is used the content of the section is included in the narrative text (text)
element as human readable. Entries Supported Section-Entry Templates have an entry element that links
to the Entry Templates containing CDA-L3 Discrete data.
Refer to Section 2.4 for additional information on template types and requirements.
SECTION CODE
The code element within the section classifies the section for machine processing. This code is drawn
from the LOINC Document Sections vocabulary and is constrained to those codes identified in the
Implementation Guide. Whilst it is possible to include additional sections in the document using other
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
141 DSTU (Revision 2013)
LOINC Document Section codes; there is no requirement that a receiving system will be able to process
the additional section.
SECTION TITLE
The title element within the section provides the human readable heading for the section and is the
section heading that the provider would normally expect to see as part of their clinical practice. The title
should conform to the Section Title provided in the Implementation Guide; however, there is no
requirement that it be exactly the same as the titles provided in the Implementation Guide. For example,
the “Prescriptions & Medications Section” title may be modified to “Medication List”; as long as the
content and intent of the section remains unchanged.
NARRATIVE TEXT
The text element within the section stores the narrative to be rendered or displayed, as described in the
CDA R2 specification, and is referred to as the CDA narrative block.
The content model of the CDA narrative block schema is hand crafted to meet requirements of human
readability and rendering. The schema is registered as a MIME type (text/x-hl7-text+xml), which is
the fixed media type for the text element.
As noted in the CDA R2 specification, the document originator is responsible for ensuring that the
narrative block contains the complete, human readable, attested content of the section. Structured entries
support computer processing and computation and are not a replacement for the attestable, human-
readable content of the CDA narrative block. The special case of structured entries with an entry
relationship of "DRIV" (is derived from) indicates to the receiving application that the source of the
narrative block is the structured entries, and that the contents of the two are clinically equivalent.
As for all CDA documents—even when a report consisting entirely of structured entries is transformed
into CDA—the encoding application must ensure that the authenticated content (narrative plus
multimedia) is a faithful and complete rendering of the clinical content of the structured source data. As a
general guideline, a generated narrative block should include the same human readable content that
would be available to users viewing that content in the originating system. Although content formatting in
the narrative block need not be identical to that in the originating system, the narrative block should use
elements from the CDA narrative block schema to provide sufficient formatting to support human
readability when rendered according to the rules defined in Section Narrative Block (§ 4.3.5 ) of the CDA
R2 specification.
By definition, a receiving application cannot assume that all clinical content in a section (i.e., in the
narrative block and multimedia) is contained in the structured entries unless the entries in the section
have an entry relationship of "DRIV".
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
142 DSTU (Revision 2013)
Additional specification information for the CDA narrative block can be found in the CDA R2 specification
in sections 1.2.1, 1.2.3, 1.3, 1.3.1, 1.3.2, 4.3.4.2, and 6. Further clarification applicable for this guide
follows.
SECTION ENTRY REQUIREMENTS
The objective of any clinical document exchange in this specification is to ensure that the appropriate
level of information is communicated. This is especially critical for the EMR Conversion and Patient
Transfer Documents, where the primary goal of those is to provide complete, detailed and accurate
information for machine processable load of a patient’s clinical chart in the destination system.
Sending System Responsibilities
2) The system SHALL generate all entries as either DRIV or COMP within a section. In other words, the
system SHALL-NOT include both DRIV and COMP entries within a single section in a document.
Clinical Information, stored as separate records in the Sending System:
3) IF the information for a section is structured and stored as separate records in the sending system, THEN the system SHALL generate a Level 3 Section using the appropriate Level 3 template.
a) The system SHALL generate an <entry> item for each record AND
i) SHALL set the @typeCode=”DRIV” for all <entry> items AND
ii) SHALL generate the narrative text from the entry/record information (i.e. the set of entries).
b) IF a section entry template includes an organizer, THEN the system SHALL generate each component of an organizer for each record in the system.
Clinical information, stored as a single object (i.e. unstructured text) in the Sending System:
4) IF the information for a section is unstructured and stored as a single textual component (i.e. not separate records), THEN the system:
a) SHALL use the Level 2 template for the section unless only Level 3 is supported for that section.
b) IF the system constructs a Level 3 section (i.e. Level 2 is not supported) from unstructured
information; THEN the system SHALL set the @typeCode=”COMP”.
Receiving System Responsibilities
5) The system SHALL-NOT attempt to parse and use narrative information (i.e. <text>) to construct
separate records.
6) The system SHALL process Level 3 template entries with the @typeCode=”COMP” as follows:
a) The system SHALL store and consider the narrative information <text> element as the attested
clinical content.
b) The system SHALL-NOT import <entry> items as separate records unless the system is capable
of flagging these records as supporting or subordinate to the attested clinical content.
7) The system SHALL process Level 3 template entries with the @typeCode=”DRIV” as follows:
a) IF the system supports distinct records, THEN the system SHALL process and store each <entry>
item as a separate record AND
i) The system MAY log and disregard (ignore) the narrative text because it was derived from the
machine-processable <entry> items by the sending system.
b) IF the system does not support distinct records, THEN the system SHALL store the narrative
information (text) element. The narrative text was derived from the machine-processable
<entry> items by the sending system.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
143 DSTU (Revision 2013)
5.1 ADVANCE DIRECTIVES [42348-3]
The Advance Directives Section provides information regarding any advance directives for the patient.
Advance Directives may include living wills, healthcare proxies as well as CPR and resuscitation status.
This section may include scanned images of the relevant legal documents.
This section supports both free text advance directives as well as discrete data encoded using a
standards based nomenclature.
Advance Directives Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.2(open)]
Table 28: Advance Directives [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
An Advance Directives [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:526].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:527].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:528] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.2"
[CONF:528.12].
4) SHALL contain exactly one [1..1] code="42348-3" Advance directives (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:529].
5) SHALL contain exactly one [1..1] title="Advance Directives Section [without
entries]" [CONF:530] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:530.32].
6) SHALL contain exactly one [1..1] text [CONF:531].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.2.1(open)]
Table 29: Advance Directives [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Advanced Directives Observation
Generic Episodic Document
Generic Structured Referral
Patient Transfer
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
144 DSTU (Revision 2013)
An Advance Directives [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:532].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:533].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:534] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.2.1"
[CONF:534.12].
4) SHALL contain exactly one [1..1] code="42348-3" Advance directives (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:535].
5) SHALL contain exactly one [1..1] title="Advance Directives Section [with entries]"
[CONF:536] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:536.32].
6) SHALL contain exactly one [1..1] text [CONF:537].
7) SHALL contain at least one [1..*] entry [CONF:538] such that each,
a) SHALL contain exactly one [1..1] Advanced Directives Observation
(2.16.840.1.113883.3.1818.10.3.1) [CONF:538.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
145 DSTU (Revision 2013)
The following XML example outlines how to use the Advance Directives [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.2.1"/>
<code code="42348-3" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="Advance Directives"/>
<title>Advance Directives Section [with entries]</title>
<text>
<table border='1'>
<thead>
<tr><th>Documentation</th><th>Contact</th>
<th>Effective Date</th><th>Comments</th>
</tr>
</thead>
<tbody>
<tr><td>Resuscitation Status: DNR 4 (full
resucitation)</td><td>GP</td>
<td>Jan 11, 2013</td><td>Discussed with patient</td>
</tr>
<tr><td>blood Product Refusal, Jehovah's Witness</td><td>GP</td>
<td>Jan 11, 2013</td><td>Plasma, cells refused, Purified
fractions OK</td>
</tr>
</tbody>
</table>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.1"/> <!-- Advance
Directives Observation -->
…
</entry>
</section>
</component>
Figure 35: Advance Directives [with entries] entry example
5.2 ALERTS [ALERTS]
The Alerts Section provides information on any condition about which a care provider should be aware.
Examples of alerts could include exposure to contagious disease, the existence of an advance directive,
a social situation or a fear/phobia. Other types of alerts could include Organ Donor, or a Transplant
Recipient, Special needs, Patient Preferences or MRSA positive.
This section supports both free text alert descriptions as well as discrete data encoded using a standards
based nomenclature.
Alerts Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.3(open)]
Table 30: Alerts [without entries] Template Context
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
146 DSTU (Revision 2013)
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
An Alerts [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:539].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:540].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:541] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.3"
[CONF:541.12].
4) SHALL contain exactly one [1..1] code="ALERTS" Alerts (CodeSystem: SectionType-CA-Pending
2.16.840.1.113883.3.3068.10.6.2) [CONF:542].
5) SHALL contain exactly one [1..1] title="Alerts [without entries]" [CONF:543] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:543.32].
6) SHALL contain exactly one [1..1] text [CONF:544].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.3.1(open)]
Table 31: Alerts [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Alert Observation
Generic Episodic Document
Generic Structured Referral
Patient Transfer
An Alerts [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:545].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:546].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:547] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.3.1"
[CONF:547.12].
4) SHALL contain exactly one [1..1] code="ALERTS" Alerts (CodeSystem: SectionType-CA-Pending
2.16.840.1.113883.3.3068.10.6.2) [CONF:548].
5) SHALL contain exactly one [1..1] title="Alerts [with entries]" [CONF:549] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:549.32].
6) SHALL contain exactly one [1..1] text [CONF:550].
7) SHALL contain at least one [1..*] entry [CONF:551] such that each,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
147 DSTU (Revision 2013)
a) SHALL contain exactly one [1..1] Alert Observation (2.16.840.1.113883.3.1818.10.3.2)
[CONF:551.1].
The following XML example outlines how to use the Alerts [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.3.1"/>
<code code="ALERTS" codeSystem="2.16.840.1.113883.3.3068.10.6.2"
codeSystemName="SectionType-CA-Pending" displayName="Alerts"/>
<title>Alerts [with entries]</title>
<text>
Verbose;
MRSA - Multiple resistant staphylococcus aureus infection carrier
</text>
<confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"
codeSystemName="HL7 - Confidentiality" displayName="Normal"/>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.2"/> <!-- Alert Observation -->
…
</entry>
</section>
</component>
Figure 36: Alerts [with entries] entry example
5.3 ALLERGIES & INTOLERANCES - REACTION LIST [48765-2]
The Allergies & Intolerances Section provides information on different allergies or adverse reactions that
a patient may have or have had. This section is commonly referred to as the “Reaction List”.
This section supports both free text allergy/intolerance descriptions as well as discrete data encoded
using a standards based nomenclature.
Allergies Reviewed
It may be necessary to document when an allergy list has been reviewed. This is normal practice
whenever a patient has an encounter with the provider and the result of the review is normally noted as
part of the encounter notes. The Encounter Notes functionality, as described in the Encounter History &
Notes Section allows for the inclusion of coded or textual observations associated with the encounter. If
the provider wishes to document that no allergies were identified including creating a specific record in
the Reaction List this may be done as outlined in the Allergies & Intolerances Observation template.
Drug Excipient
An excipient is generally a pharmacologically inactive substance used as a carrier for the active
ingredients of a medication. There are many examples of Excipients or inactive ingredients that may
cause adverse reactions in the patient such as specific dyes, eggs and corn.
The classic example is the colour/food dye that is used in a drug. The clinician could capture the dye
allergy as a separate Reaction Record (i.e. a record that is not directly linked to the drug and the
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
148 DSTU (Revision 2013)
associated medication events) and consider this when prescribing; however, he or she may not have
current information on drug formulation since drug colour agents and fillers often change. When aware of
these excipient intolerances, the clinician would typically aim to make the patient aware of the risk and
instruct them to discuss the issue with their pharmacist when filling prescriptions.
The Drug Excipient information is sometimes not readily available in medication databases but is
published in the drug monographs. It is sometimes very time consuming to find an appropriate medication
when a patient has problems with one or more of these substances. Some EMR systems have the
capability to use a commercial drug database (e.g. First Data Bank (FDB)) to store a value indicating that
the allergen is/is not an inactive ingredient in medications. However, FDB Canada does not currently
include a way to look up inactive ingredients in medications so the best that can be done is to show a
warning in the EMR that the patient has allergies to one or more inactive ingredients and that the doctor
should check each medication’s list of ingredients against the patient’s allergy profile.
The specifications have been designed to allow for the full coding of the allergen as well as the Allergen
Group using the same drug coding mechanisms as is used for prescribing. This allows for the
communication of the drug and drug excipient information if it is recorded in the source system.
Notwithstanding this basic capability it is important to note that it was well beyond the scope of this project
and these interoperability specifications to address the broader challenge of excipient reactions on clinical
practice, on the requirements for EMR functionality, and on drug formulary coding. If and when further
analysis is undertaken on these requirements and an approach for addressing the clinical practice
requirements, product capability, and structured terminology are developed, then these can be
incorporated in interchange standards such as these.
Free Text Reaction List Entries
While the specification supports the option of exchanging free text Reaction List entries this is primarily to
accommodate legacy data within the EMR systems that may need to be exchanged as part of a patient
transfer or conversion. The option of capturing and communicating reactions as free text is not
encouraged as it will impact the receiving EMR’s ability to leverage this information as part of its clinical
decision support and prescribing functions.
Allergies & Intolerances - Reaction List Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.4(open)]
Table 32: Allergies & Intolerances (Reaction List) [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
149 DSTU (Revision 2013)
An Allergies & Intolerances (Reaction List) [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:643].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:644].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:645] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.4"
[CONF:645.12].
4) SHALL contain exactly one [1..1] code="48765-2" Allergies, adverse reactions, alerts
(CodeSystem: LOINC 2.16.840.1.113883.6.1) [CONF:646].
5) SHALL contain exactly one [1..1] title="Allergies & Intolerances (Reaction List)
[without entries]" [CONF:647] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:647.32].
6) SHALL contain exactly one [1..1] text [CONF:648].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.4.1(open)]
Table 33: Allergies & Intolerances (Reaction List) [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Allergy & Intolerance Observation
Generic Episodic Document
Generic Structured Referral
Patient Transfer
An Allergies & Intolerances (Reaction List) [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:649].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:650].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:651] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.4.1"
[CONF:651.12].
4) SHALL contain exactly one [1..1] code="48765-2" Allergies, adverse reactions, alerts
(CodeSystem: LOINC 2.16.840.1.113883.6.1) [CONF:652].
5) SHALL contain exactly one [1..1] title="Allergies & Intolerances (Reaction List)
[with entries]" [CONF:653] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:653.32].
6) SHALL contain exactly one [1..1] text [CONF:654].
7) SHALL contain one or more (or a nullFlavor value) [1..*] entry [CONF:655] such that each,
a) SHALL contain exactly one [1..1] Allergy & Intolerance Observation
(2.16.840.1.113883.3.1818.10.3.3) [CONF:655.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
150 DSTU (Revision 2013)
The following XML example outlines how to use the Allergies & Intolerances (Reaction List) [with entries]
template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.4.1"/>
<code code="48765-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Allergies andor adverse reactions Doc"/>
<title>Allergies and Intolerances (Reaction List) [with entries]</title>
<text>
1. Long case of documented Peanut allergy with anaphylaxis.
2. Reaction to Angiotensin antagonist (Cough).
3. Multiple Penicillin reactions (Nausea, diarrhea)
4. Indeterminate reaction to sulfa as a child
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.3"/> <!--Allergy and Intolerance
Observation-->
…
</entry>
</section>
</component>
Figure 37: Allergies & Intolerances (Reaction List) [with entries] entry example
5.4 APPOINTMENTS & SCHEDULING [56446-8]
The Appointments & Scheduling Section supports the communication appointment events. This section
may be used to communicate both future and past appointments.
Implementer Caution
The project which established these specifications did not confirm or expand requirements in this area but, in accordance with the project scope, drew the data elements directly from the Alberta TCoPD specification. It is anticipated that a future versions may substantially change the structure and function of sections pertaining to the exchange of appointment and scheduling information.
Appointments & Scheduling Template Definitions
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.5.1(open)]
Table 34: Appointments & Scheduling [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Appointment Observation
An Appointments & Scheduling [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:656].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
151 DSTU (Revision 2013)
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:657].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:658] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.5.1"
[CONF:658.12].
4) SHALL contain exactly one [1..1] code="56446-8" Appointment summary (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:659].
5) SHALL contain exactly one [1..1] title="Appointments & Scheduling [with entries]"
[CONF:660] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:660.32].
6) SHALL contain exactly one [1..1] text [CONF:661].
7) SHALL contain one or more (or a nullFlavor value) [1..*] entry [CONF:662] such that each,
a) SHALL contain exactly one [1..1] Appointment Observation
(2.16.840.1.113883.3.1818.10.3.4) [CONF:662.1].
The following XML example outlines how to use the Appointments & Scheduling [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.5"/>
<code code="56446-8" displayName="Appointment Summary"
codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" />
<title>Appointments and Scheduling [with entries]</title>
<text>
14-Feb-2014 12:30PM; 30 minute. Annual Follow-up; Diabetes control and med
renewal;
Practitioner's office in community.
Provider; Dr. W. Pewarchuck 23377
Referred by: Dr. A. de Wit 24975
Copy Provider: J. Doe
20-Feb-2014 12:30PM; 15 minute. Post-angioplasty review; Review and renew meds
and clinical status;
Practitioner's office in community.
Provider; GP on call.
</text>
<!-- Feb 14th Appointment -->
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.4"/> <!-- Appointment
Observation -->
…
</entry>
</section>
</component>
Figure 38: Appointments & Scheduling [with entries] entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
152 DSTU (Revision 2013)
5.5 BILLING [BILLING]
The Billing Section enables the communication of billing information associated with the patient record.
This section supports a single attached external file containing the billing history for the patient according
to the B.C. Medical Services Plan (MSP) format7.
Implementer Caution
Implementers should note that this approach for the communication of billing information is intended as a stop gap measure at this time. Future versions of this specification may provide for the ability to transfer billing information in a more granular fashion to more fully support the conversion use case.
Billing Template Definitions
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.6.1(open)]
Table 35: Billing [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Billing Attachment
A Billing [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:467].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:468].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:469] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.6.1"
[CONF:469.12].
4) SHALL contain exactly one [1..1] code="BILLING" Billing Information (CodeSystem: SectionType-
CA-Pending 2.16.840.1.113883.3.3068.10.6.2) [CONF:470].
5) SHALL contain exactly one [1..1] title="Billing [with entries]" [CONF:471] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:471.32].
6) SHALL contain exactly one [1..1] text [CONF:472].
7) SHALL contain at least one [1..*] entry [CONF:473] such that each,
a) SHALL contain exactly one [1..1] Billing Attachment (2.16.840.1.113883.3.1818.10.3.5)
[CONF:473.1].
7 Please see http://www.health.gov.bc.ca/msp/infoprac/teleplanspecs/index.html for further information.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
153 DSTU (Revision 2013)
The following XML example outlines how to use the Billing [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.6"/>
<code code="48768-6" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Payment sources Doc"/>
<title>Billing [with entries]</title>
<text>
<!-- 3 Attachments -->
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.5"/> <!-- Billing Attachments --
>
<observationMedia classCode="OBS" moodCode="EVN">
<id extension="127797" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<value xsi:type="ED" mediaType="application/pdf">
<reference value="http://www.anywhere.com/folder1/20120202-Patient1-
claim1.pdf"/>
</value>
</observationMedia>
</entry>
</section>
</component>
Figure 39: Billing [with entries] entry example
5.6 CARE PLAN / REMINDERS / TASKS [56851-9]
The Care Plan / Reminders / Tasks Section includes any specific planned or scheduled tests, procedures
or regimens of care to be performed by the physician or agreed upon by the patient. This section includes
reminders and tasks to be performed by the care provider team.
Examples of tasks/reminders include laboratory, imaging, consult, communication actions that need to be
performed. These form the basis of Chronic Disease Management and proactive care. This section could
also incorporate Targets/Goals of care that are both standard population based (PAP smears,
mammograms) and individualized (diabetic testing in diabetic patients).
Implementer Caution
Although the scope of this section is currently limited to support for a human readable narrative, future versions of this specification may provide more support for the exchange of more granular care plans.
Care Plan / Reminders / Tasks Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.7(open)]
Table 36: Care Plan / Reminders / Tasks [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
154 DSTU (Revision 2013)
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Care Plan / Reminders / Tasks [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:461].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:462].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:463] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.7"
[CONF:463.12].
4) SHALL contain exactly one [1..1] code="56851-9" Care process or lan (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:464].
5) SHALL contain exactly one [1..1] title="Care Plan / Reminders / Tasks [without
entries]" [CONF:465] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:465.32].
6) SHALL contain exactly one [1..1] text [CONF:466].
The following XML example outlines how to use the Care Plan / Reminders / Tasks [without entries]
template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.7"/>
<code code="56851-9" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Care process or plan"/>
<title>Care Plan / Reminders / Tasks [without entries]</title>
<text>
<list>
<item>Complete PFTs with lung volumes.</item>
<item>Chem-7 tomorrow.</item>
<item>Teach peak flow rate measurement.</item>
<item>Decrease prednisone to 20qOD alternating with 18qOD.</item>
<item>Hydrocortisone cream to finger BID.</item>
<item>RTC 1 week.</item>
</list>
</text>
</section>
</component>
Figure 40: Care Plan / Reminders / Tasks [without entries] entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
155 DSTU (Revision 2013)
5.7 CLINICALLY MEASURED OBSERVATIONS [CLINOBS]
The Clinically Measured Observations Section includes clinically measured or noted observations on the
patient and provides discrete data points on the patients’ physical attributes and measurements including
information on the patients’ height, weight, blood pressure, pulse and heart sounds.
This section supports both free text observations as well as discrete data encoded using a standards
based nomenclature such as a controlled medical vocabulary.
The section follows the standard Organizer-Grouped Observations pattern.
Disease Specific Requirements
The opportunity exists for data interchange specifications to incorporate specific templates pertaining to
best practice data sets pertaining to specific diseases. For example, the Ontario Data Portability
Specifications have identified a number of observations specific to Diabetes. Similarly, in BC there are a
number of chronic disease capture forms and guidelines defined by the BC Guidelines and Protocols
Advisory Committee, including the following:
Table 37: Chronic Disease Capture Forms
Chronic Disease Capture Form and Guideline Link
Diabetes http://www.bcguidelines.ca/pdf/diabetes_flow_sheet.pdf
CHF http://www.bcguidelines.ca/pdf/heart_failure_flowsheet.pdf
Hypertension http://www.bcguidelines.ca/pdf/hypertension_appendix_d.pdf
COPD http://www.bcguidelines.ca/pdf/copd_appendix_a.pdf
Cognitive Impairment http://www.bcguidelines.ca/pdf/cognitive_appendix_g.pdf
Depression http://www.bcguidelines.ca/pdf/depression_flow.pdf
Implementer Caution
While the inclusion of these types of disease specific observations is not within the scope of this project; the Observation pattern described above could / should be used to communicate these types of observations. A subsequent effort may be undertaken to extend the table of PITO E2E-DTC Specification Observation Codes to include the structures necessary to explicitly support the communication of data pertaining to various disease-focused guidelines in addition to providing the implementation guidance required for the associated capture forms. The current specifications are designed in such a way that they can be extended to the full range of clinical observations through code system expansion – i.e. with little or no modification to the structure of the specification.
Clinically Measured Observations Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.8(open)]
Table 38: Clinical Measured Observations [without entries] Template Context
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
156 DSTU (Revision 2013)
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Clinical Measured Observations [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:604].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:605].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:606] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.8"
[CONF:606.12].
4) SHALL contain exactly one [1..1] code="CLINOBS" Clinically Measured Observations (CodeSystem:
SectionType-CA-Pending 2.16.840.1.113883.3.3068.10.6.2) [CONF:607].
5) SHALL contain exactly one [1..1] title="Clinical Measured Observations [without
entries]" [CONF:608] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:608.32].
6) SHALL contain exactly one [1..1] text [CONF:609].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.8.1(open)]
Table 39: Clinical Measured Observations [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Clinically Measured Observations Organizer
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Clinical Measured Observations [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:610].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:611].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:612] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.8.1"
[CONF:612.12].
4) SHALL contain exactly one [1..1] code="CLINOBS" Clinically Measured Observations (CodeSystem:
SectionType-CA-Pending 2.16.840.1.113883.3.3068.10.6.2) [CONF:613].
5) SHALL contain exactly one [1..1] title="Clinical Measured Observations [with
entries]" [CONF:614] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:614.32].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
157 DSTU (Revision 2013)
6) SHALL contain exactly one [1..1] text [CONF:615].
7) SHALL contain one or more (or a nullFlavor value) [1..*] entry [CONF:616] such that each,
a) SHALL contain exactly one [1..1] Clinically Measured Observations Organizer
(2.16.840.1.113883.3.1818.10.3.7) [CONF:616.1].
The following XML example outlines how to use the Clinical Measured Observations [with entries]
template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.8.1"/>
<code code="CLINOBS" codeSystem="2.16.840.1.113883.3.1818.10.2.100.1"
codeSystemName="PITOObservationType" displayName="Clinically Measured Observations"/>
<title>Clinical Measured Observations [with entries]</title>
<text>
Observation Name Date/Time Value Interpretation Code Method Code
Height 14-Feb-2011, 12:00 PM 160 cm
Weight 14-Feb-2011, 12:00 PM 120 kg H
Weight 02-Jul-2000, 10:00 AM 100 kg H
Waist Circumference 14-Feb-2011, 12:00 PM 120 cm
Pulse Rate 14-Feb-2011, 12:00 PM 70 bpm
Pulse Rate 11-feb-2013, 09:00 AM 50 bpm
Blood Pressure (BP) 14-Feb-2011, 12:00 PM 120/80 left upper arm, Sitting
Diastolic Pressure 14-Feb-2011, 12:00 PM 99
Diastolic Pressure 14-Feb-2011, 12:05 PM 85
Diastolic Pressure 14-Feb-2011, 12:08 PM 84
Diastolic Pressure 14-Feb-2011, 12:12 PM 80
Diastolic Pressure 11-feb-2013, 09:00 AM 50
Systolic Pressure 14-Feb-2011, 12:00 PM 180
Systolic Pressure 14-Feb-2011, 12:05 PM 165
Systolic Pressure 14-Feb-2011, 12:08 PM 150
Systolic Pressure 14-Feb-2011, 12:12 PM 130
Systolic Pressure 11-feb-2013, 09:00 AM 85
Diabetic Foot Exam 14-Feb-2011, 12:00 PM (Checkbox ticked)
Foot Pin-Prick Assessment 14-Feb-2011, 12:00 PM (Checkbox ticked)
Diabetic Counselling 14-Feb-2011, 12:00 PM (Checkbox ticked)
Dilated Eye Exam 14-Feb-2011, 12:00 PM (Checkbox not ticked)
Ejection Fraction 24-Aug-2010, 09:00 AM 55
Peak Flow 14-Feb-2011, 12:30 PM 220
Liver size 14-Feb-2011, 12:00 PM 10
Pedal edema 14-Feb-2011, 12:00 PM 1+
MMSE 14-Feb-2011, 12:30 PM 30
MOCA 14-Feb-2011, 12:30 PM 30
CHADS2 14-Feb-2011, 12:00 PM 2
Hypoglycemic Episodes Reported 14-Feb-2011, 12:00 PM Yes List of Yes/No
Blood Glucose Self-Monitoring 14-Feb-2011, 12:00 PM No List of Yes/No/Unknown
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.7"/> <!-- Clinically Measured
Observations Organizer -->
…
</entry>
</section>
</component>
Figure 41: Clinical Measured Observations [with entries] entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
158 DSTU (Revision 2013)
5.8 CURRENT MEDICATIONS [19009-0]
The Current Medications Section is a summary view of the patient’s active medications and will include
only the current medications that the patient is on as at a set date. Only medications with a Record Status
set to Active should be included in this section and consequently, it is only relevant to the Episodic
Documents use case when historical medications are not of interest and not appropriate to be used in the
EMR Conversion or Patient Transfer use cases. This section may be referred to as the “Useful Medication
List” and includes the date that the list was generated as accurate. This section may be used to
communicate the current medications when it is not appropriate or desired to send the entire medication
list history.
The inclusion of active prescription, dispense and administration details may be included in this section if
required.
Refer to the Medications & Prescriptions Section for a detailed discussion of the inclusion of medications
in the document and on specific information on communicating all active and historical medications and
prescription details.
Current Medications Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.9(open)]
Table 40: Current Medications [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
A Current Medications [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:663].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:664].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:665] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.9"
[CONF:665.12].
4) SHALL contain exactly one [1..1] code="19009-0" Medication.current (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:666].
5) SHALL contain exactly one [1..1] title="Current Medications [without entries]"
[CONF:667] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:667.32].
6) SHALL contain exactly one [1..1] text [CONF:668].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
159 DSTU (Revision 2013)
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.9.1(open)]
Table 41: Current Medications [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Medication Event
Generic Episodic Document
Generic Structured Referral
A Current Medications [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:669].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:670].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:671] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.9.1"
[CONF:671.12].
4) SHALL contain exactly one [1..1] code="19009-0" Medication.current (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:672].
5) SHALL contain exactly one [1..1] title="Current Medications [with entries]"
[CONF:673] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:673.32].
6) SHALL contain exactly one [1..1] text [CONF:674].
7) SHALL contain one or more (or a nullFlavor value) [1..*] entry [CONF:675] such that each,
a) SHALL contain exactly one [1..1] Medication Event (2.16.840.1.113883.3.1818.10.3.18)
[CONF:675.1].
The following XML example outlines how to use the Current Medications [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.9.1"/>
<code code="19789-7" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Medications"/>
<title> Current Medications [with entries]</title>
<text>
<list>
<item>ASA; 81 mg tablet, one daily; for Hypertension, Atrial
fibrillation</item>
<item>Amoxicillin 500mg PO BID</item>
</list>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.18" /> <!-- Medication Event -->
…
</entry>
</section>
</component>
Figure 42: Current Medications [with entries] entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
160 DSTU (Revision 2013)
5.9 DEVELOPMENTAL OBSERVATIONS [11334-0]
The Developmental Observations Section provides information on metrics specific to paediatric
requirements and consists of a series of observations regarding the patient. Information in this section
would include birth weight and APGAR scores as well as percentile growth chart information.
This section supports both free text observations as well as discrete data encoded using a standards
based nomenclature or clinical scales where appropriate.
The section follows the standard Organizer-Grouped Observations pattern.
Developmental Observations Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.10(open)]
Table 42: Developmental Observations [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Developmental Observations [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:630].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:631].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:632] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.10"
[CONF:632.12].
4) SHALL contain exactly one [1..1] code="11334-0" History of Growth+Development (CodeSystem:
LOINC 2.16.840.1.113883.6.1) [CONF:633].
5) SHALL contain exactly one [1..1] title="Developmental Observations [without
entries]" [CONF:634] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:634.32].
6) SHALL contain exactly one [1..1] text [CONF:635].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.10.1(open)]
Table 43: Developmental Observations [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Developmental Observations Organizer
Generic Episodic Document
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
161 DSTU (Revision 2013)
Directly Used by Template(s) Directly Contains Template(s)
Generic Structured Referral
Patient Transfer
A Developmental Observations [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:636].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:637].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:638] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.10.1"
[CONF:638.12].
4) SHALL contain exactly one [1..1] code="11334-0" History of Growth+Development (CodeSystem:
LOINC 2.16.840.1.113883.6.1) [CONF:639].
5) SHALL contain exactly one [1..1] title="Developmental Observations [with entries]"
[CONF:640] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:640.32].
6) SHALL contain exactly one [1..1] text [CONF:641].
7) SHALL contain one or more (or a nullFlavor value) [1..*] entry [CONF:642] such that each,
a) SHALL contain exactly one [1..1] Developmental Observations Organizer
(2.16.840.1.113883.3.1818.10.4.6) [CONF:642.1].
The following XML example outlines how to use the Developmental Observations [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.10.1"/>
<code code="11334-0" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="History of Growth+Development"/>
<title>Developmental Observations [with entries]</title>
<text>
<list>
<item>March 20, 2012: 67% Weight Percentile</item>
<item>March 20, 2012: 87% Height Percentile</item>
</list>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.7"/> <!-- Developmental
Observations Organizer -->
...
</entry>
</section>
</component>
Figure 43: Developmental Observations [with entries] entry example
5.10 DEVICES [46264-8]
The Devices Section provides information on any surgically implanted device or physical attachment the
patient may have, for example pacemaker or limb prosthesis.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
162 DSTU (Revision 2013)
This section supports both free text device descriptions as well as discrete data encoded using a
standards based nomenclature.
Devices Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.11(open)]
Table 44: Devices [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Devices [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:474].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:475].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:476] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.11"
[CONF:476.12].
4) SHALL contain exactly one [1..1] code="46264-8" History of medical device use (CodeSystem:
LOINC 2.16.840.1.113883.6.1) [CONF:477].
5) SHALL contain exactly one [1..1] title="Devices [without entries]" [CONF:478] such that
it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:478.32].
6) SHALL contain exactly one [1..1] text [CONF:479].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.11.1(open)]
Table 45: Devices [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Device Observation
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Devices [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:480].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:481].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
163 DSTU (Revision 2013)
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:482] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.11.1"
[CONF:482.12].
4) SHALL contain exactly one [1..1] code="46264-8" History of medical device use (CodeSystem:
LOINC 2.16.840.1.113883.6.1) [CONF:483].
5) SHALL contain exactly one [1..1] title="Devices [with entries]" [CONF:484] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:484.32].
6) SHALL contain exactly one [1..1] text [CONF:485].
7) SHALL contain at least one [1..*] entry [CONF:486] such that each,
a) SHALL contain exactly one [1..1] Device Observation
(2.16.840.1.113883.3.1818.10.3.8) [CONF:486.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
164 DSTU (Revision 2013)
The following XML example outlines how to use the Devices [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.11.1"/>
<code code="46264-8" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="History of medical device uset"/>
<title>Devices [with entries]</title>
<text>
<table border="1" width="100%">
<thead>
<tr>
<th>Supply/Device</th>
<th>Date Supplied</th>
<th>Device Author</th>
<th>Device Informant</th>
</tr>
</thead>
<tbody>
<tr>
<td>Total hip replacement prosthesis</td>
<td>1998</td>
<td>Dr. W. Pewarchuk</td>
<td>Daughter Cloe</td>
</tr>
<tr>
<td>Cardiac pacemaker</td>
<td>02-Dec-2009</td>
<td>Dr. W. Pewarchuk</td>
<td>Daughter Cloe</td>
</tr>
<tr>
<td>Breast Prosthesis</td>
<td>05-Jul-1967</td>
<td>Dr. W. Pewarchuk</td>
<td>Patient</td>
</tr>
<tr>
<td>Wheelchair</td>
<td>1999</td>
</tr>
</tbody>
</table>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.8"/> <!-- Device Observation -->
…
</entry>
</section>
</component>
Figure 44: Devices [with entries] entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
165 DSTU (Revision 2013)
5.11 ENCOUNTER HISTORY & NOTES [46240-8]
The Encounter History and Notes section provides information on the encounters that the patient has had
with the healthcare system as well as any clinical notes that are associated with the encounters.
Encounter reports such as discharge summaries, operative reports and consult reports may be
documented in this section along with information regarding the reason for the encounter and any follow-
up required.
Local and External Encounters
The EMR systems differentiate in how they manage information for encounters depending on if the
encounter is a “locally documented” encounter or one that is from external sources.
Locally Documented Encounters are those where the EMR is used as the primary source of
documentation for the encounter. For example, the primary care provider uses his EMR to document
a visit in his office and captures encounter comments, perhaps SOAP notes etc.
Externally Sourced Encounters are those where the EMR has received documentation regarding an
encounter from an external source. For example, the patient is hospitalized and the EMR is sent a
discharge summary from the hospital. In this case, the EMR may generate an record to capture the
encounter date, location, reason, providers etc; however, in some applications, the EMR may only
attach the received document to the patient file and not document an encounter event as a distinct
record.
Externally Sourced Encounter History includes all encounter types such as referrals, hospitalizations,
acute care, ambulatory care, home care or telehealth encounters, as well as other electronically mediated
health encounters, eg. Patient portal, email, video/voice conferencing that are not documented directly in
the EMR.
Currently some EMRs may not have the capability to create the externally sourced encounters as
Encounter History records. Consequently, the PITO E2E-DTC Specification allows for these encounters
to be communicated as part of the patient’s care history as outlined in the Medical Treatment History
Section.
Sending System Responsibilities
Sending System SHALL include all locally documented encounters in the Encounter History Section.
Sending System MAY include externally sourced encounters in the Encounter History Section.
Sending System MAY include externally sourced encounters in the Medical Treatment History Section.
Receiving System Responsibilities
Receiving System SHALL accept (sender) locally documented encounters in the Encounter History
Section.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
166 DSTU (Revision 2013)
Receiving System MAY accept (sender) externally sourced encounters in the Encounter History
Section.
Receiving System MAY accept (sender) externally sourced encounters in the Medical Treatment
History Section.
Encounter History & Notes Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.12(open)]
Table 46: Encounter History & Notes [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
An Encounter History & Notes [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:689].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:690].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:691] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.12"
[CONF:691.12].
4) SHALL contain exactly one [1..1] code="46240-8" History of hospitalizations+History of outpatient
visits (CodeSystem: LOINC 2.16.840.1.113883.6.1) [CONF:692].
5) SHALL contain exactly one [1..1] title="Encounter History & Notes [without entries]"
[CONF:693] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:693.32].
6) SHALL contain exactly one [1..1] text [CONF:694].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.12.1(open)]
Table 47: Encounter History & Notes [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Encounter Event
Generic Episodic Document
Generic Structured Referral
Patient Transfer
An Encounter History & Notes [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:695].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
167 DSTU (Revision 2013)
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:696].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:697] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.12.1"
[CONF:697.12].
4) SHALL contain exactly one [1..1] code="46240-8" History of hospitalizations+History of outpatient
visits (CodeSystem: LOINC 2.16.840.1.113883.6.1) [CONF:698].
5) SHALL contain exactly one [1..1] title="Encounter History & Notes [with entries]"
[CONF:699] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:699.32].
6) SHALL contain exactly one [1..1] text [CONF:700].
7) SHALL contain one or more (or a nullFlavor value) [1..*] entry [CONF:701] such that each,
a) SHALL contain exactly one [1..1] Encounter Event (2.16.840.1.113883.3.1818.10.3.9)
[CONF:701.1].
The following XML example outlines how to use the Encounter History & Notes [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.22.1"/>
<code code="46240-8" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Hospitalizations+OP visits Hx Reported"/>
<title>Encounter History and Notes [with entries]</title>
<text>
<list>
<item>1. 14-Feb-2011, 12:00 PM - GME</item>
<item>2. 20-Dec-2012, 02:00 PM - Med review, Rx renewal, UTI with new Septra
Rx (refuted allergy)</item>
<item>3. 11-Feb-2013, 09:00 AM– Chest Pain, send to ER, admission, IM Consult,
Discharge summary,
Angiogram/angioplasty, CXR, external meds</item>
<item>4. 20-Feb-2013, 11:00 AM – Post-angioplasty FU, Med review (include
Clopidogrel with special instructions
(“DO NOT STOP”, 1 year)</item>
</list>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.9"/> <!-- Encounter Event -->
…
</entry>
</section>
</component>
Figure 45: Encounter History & Notes [with entries] entry example
5.12 FAMILY HISTORY [10157-6]
The Family History Section provides details on conditions that family members have or have had in the
past that may effect on the treatment of the patient.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
168 DSTU (Revision 2013)
This section supports both free-text as well as discrete data encoded using a standards based
nomenclature. Discrete data capture may include the condition description, family relationship type, age
of onset of the condition, age and cause of death of the family member.
Personal versus Blood Relationships
The purpose of the Family History Section is to communicate medical information of the members of the
patient’s family that may impact the patient’s care. Consequently, the intent of this section is limited to
the documentation of ‘blood’ or genetically related family members and their diagnosis history.
The medical history of a non-blood relation is not appropriately communicated in the Family History
section as it has no direct bearing on the patient’s health. However, it may still be relevant to the overall
care of the patient; for example, noting that the patient’s husband has Alzheimer’s or that a parent is an
alcoholic. This information is appropriately communicated in the Alerts or Risk Factors Sections of the
document.
It is also important to communicate the existence of non-blood relations of the patient without any clinical
observations about the family member. The existence of family members, or other personal contacts is
communicated in the Header “Personal Contact” Section. The Personal Contact section may be used to
document the existence of any family or personal relationships (e.g. step father; husband etc).
Problem List vs Family History
Some providers prefer to include all patient problems or potential problems in a single “Problem List” and
they may include the documentation of family member’s diagnosis in the patient’s own Problem List.
Coding systems have, unfortunately, supported this practice by accepting the addition of codes such as
“History of Diabetes in Family” as an example. In other cases providers may simply enter free text
problems into the Patient’s problem list.
The challenge with this practice is that the source system will be unable to identify if a problem in the
Problem List is a diagnosis of the patient’s or of a family member and will consequently be unable to send
it in the Family History Section of the document. Consequently, whilst the PITO E2E-DTC specification
can encourage that the sending system identifies a family member diagnosis and sends it in the Family
History Section; this may not always be possible.
This problem is beyond the scope of an interoperability specification and needs to be addressed through
EMR system functionality, specificity in the coding systems used, and changes to clinical practice. The
PITO E2E-DTC specification provides distinct sections for the patient’s Problem List versus the Family
History list and encourages both sending and receiving systems to support these as distinct sections in
exchange documents.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
169 DSTU (Revision 2013)
Clinical Genomics
There is an increasing emphasis and importance on the tracking of clinical genomics and many EMR
systems have enhanced functionality to support clinical genomic mapping such as graphical family trees.
This is especially important for specialists in areas such as Oncology. HL7 has developed a
sophisticated standard for the communication of clinical genomic information and additional information
regarding this initiative can be retrieved from the HL7 website at
http://www.hl7.org/Special/committees/clingenomics/index.cfm.
Whilst this is important work and may need to be communicated between EMR systems, the scope of the
existing PITO project does not extend to support for these structures and the capabilities of the source
systems in the Family History sections does not include this functionality. If this is a priority, it is
recommended that a separate initiative be launched to extend the specification to add a specific Clinical
Genomic Section to the specification.
Family History Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.13(open)]
Table 48: Family History [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Family History [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:552].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:553].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:554] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.13"
[CONF:554.12].
4) SHALL contain exactly one [1..1] code="10157-6" History of family member diseases (CodeSystem:
LOINC 2.16.840.1.113883.6.1) [CONF:555].
5) SHALL contain exactly one [1..1] title="Family History [without entries]" [CONF:556]
such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:556.32].
6) SHALL contain exactly one [1..1] text [CONF:557].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
170 DSTU (Revision 2013)
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.13.1(open)]
Table 49: Family History [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Family History Observation
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Family History [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:558].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:559].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:560] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.13.1"
[CONF:560.12].
4) SHALL contain exactly one [1..1] code="10157-6" History of family member diseases (CodeSystem:
LOINC 2.16.840.1.113883.6.1) [CONF:561].
5) SHALL contain exactly one [1..1] title="Family History [with entries]" [CONF:562] such
that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:562.32].
6) SHALL contain exactly one [1..1] text [CONF:563].
7) SHALL contain at least one [1..*] entry [CONF:564] such that each,
a) SHALL contain exactly one [1..1] Family History Observation
(2.16.840.1.113883.3.1818.10.3.10) [CONF:564.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
171 DSTU (Revision 2013)
The following XML example outlines how to use the Family History [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.13.1"/>
<code code="10157-6" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="History of Family Member Diseases"/>
<title>Family History [with entries]</title>
<text>
Diagnosis Name Family history of cancer of colon
Onset Date/Date Resolved
Diagnosis Code. Family history of cancer of colon, 312824007, SNOMED CT
Family Member relationship Natural Mother
Treatment Comment Infared radiation therapy attempted in December 2009 and
was not successful.
Notes / Comments Mom was diagnosed with metastatic cancer of colon and
died at age 55.
Diagnosis Billing Code.
Lifestage at onset Adult
Age at Onset Value 54
Age at Death Value 55
Cause of Death Value Cancer of colon,
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.10"/> <!-- Family History
Observation -->
…
</entry>
</section>
</component>
Figure 46: Family History [with entries] entry example
5.13 IMMUNIZATIONS LIST [11369-6]
The Immunizations List Section provides information on the immunization history of the patient.
The Immunization Section may be best described as an “Immunization List” for the patient in the medical
record; however, the source of entries within the immunization list varies and with the varying sources the
information available, appropriate or captured differs.
Immunization List Use Cases
Three basic use cases have been identified for the capture of immunization list entries and are listed in
the following table along with the expected impact on the available information within the EMR.
1. Provider Administered
The EMR Provider is the source of the immunization administration and the immunization is documented in the EMR directly at the time of administration. In this use-case the provider is expected to have information regarding the specific vaccination product administered including the DIN or GTIN code, the lot, dose, method/site and reason for the administration.
2. Patient Reported The patient reports being immunized but cannot provide any medical documentation from another provider indicating the details of the immunization. In this use-case the provider may capture very limited information regarding the
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
172 DSTU (Revision 2013)
immunization and may only have the antigen code (e.g. Tetanus) and an approximate date of administration.
3. Provider Reported
The EMR Provider receives information regarding an immunization from another provider or public health agency. This use case also includes the patient bringing official documentation of immunization history such as a report from Public Health. In this use-case, in addition to the antigen code, the provider may have some information regarding the specific vaccination product and will likely have an administration date, provider, location and some other supporting information.
Immunization Counselling and Consent
During a consultation it may be appropriate for the physician to provide immunization counselling to the
patient (or patient’s parent) and discuss immunization recommendations, guidelines and consents
required. The ability to capture discussion about immunization counselling and the consent or refusal for
the immunizations is important and may occur independently of an immunization administration event.
For example, capturing a patient’s overall refusal to receive immunizations of any kind may be captured in
encounter notes rather than in an immunization list entry. This differs from the documentation of a
patient refusing a specific immunization antigen or event. The decision to record such counselling and
consent as encounter notes or as immunization list entries is the choice of the provider within the
capabilities of his EMR system. The PITO E2E-DTC specification will accommodate both encounter
notes (coded or free text) as well as immunization refusals within the immunization list. Additionally, a
global refusal to immunization may be communicated in the Alert Section.
Allergy Desensitization
Immunizations against infections are generally thought of as quite separate from allergy shots. Allergy
shots are actually desensitization shots and it may not be clinically desirable for them to be included in an
area where true immunizations are recorded. The decision to record Allergy desensitization with infection
immunizations is a clinical decision and the choice of the provider within the capabilities of his EMR
system.
The PITO E2E-DTC specification recommends that Allergy desensitizations be included in the Medication
List section where they can be appropriately documented, coded and linked to the problem/condition.
However, these medications may be included in the Immunization List if that is the preference of the
provider. This recording is determined by clinical practice and neither impacts nor is impacted by this
specification.
Linkage to Panorama
The requirement to support linkage to Panorama is not within the scope of this specification.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
173 DSTU (Revision 2013)
Immunizations List Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.14(open)]
Table 50: Immunizations List [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
An Immunizations List [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:591].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:592].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:593] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.14"
[CONF:593.12].
4) SHALL contain exactly one [1..1] code="11369-6" History of immunization (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:594].
5) SHALL contain exactly one [1..1] title="Immunizations List [without entries]"
[CONF:595] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:595.32].
6) SHALL contain exactly one [1..1] text [CONF:596].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.14.1(open)]
Table 51: Immunizations List [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Immunization Observation
Generic Episodic Document
Generic Structured Referral
Patient Transfer
An Immunizations List [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:597].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:598].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:599] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.14.1"
[CONF:599.12].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
174 DSTU (Revision 2013)
4) SHALL contain exactly one [1..1] code="11369-6" History of immunization (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:600].
5) SHALL contain exactly one [1..1] title="Immunizations List [with entries]" [CONF:601]
such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:601.32].
6) SHALL contain exactly one [1..1] text [CONF:602].
7) SHALL contain one or more (or a nullFlavor value) [1..*] entry [CONF:603] such that each,
a) SHALL contain exactly one [1..1] Immunization Observation
(2.16.840.1.113883.3.1818.10.3.11) [CONF:603.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
175 DSTU (Revision 2013)
The following XML example outlines how to use the Immunizations List [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.14.1"/>
<code code="11369-6" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="History of Immunization"/>
<title>Immunizations List [with entries]</title>
<text>
<table border="1" width="100%">
<thead>
<tr>
<th>Vaccine</th>
<th>Date</th>
<th>Status</th>
</tr>
</thead>
<tbody>
<tr>
<td>Influenza virus vaccine, IM</td>
<td>Nov 1999</td>
<td>Completed</td>
</tr>
<tr>
<td>Influenza virus vaccine, IM</td>
<td>Dec 1998</td>
<td>Completed</td>
</tr>
<tr>
<td>Pneumococcal polysaccharide vaccine, IM</td>
<td>Dec 1998</td>
<td>Completed</td>
</tr>
<tr>
<td>Tetanus and diphtheria toxoids, IM</td>
<td>1997</td>
<td>Completed</td>
</tr>
</tbody>
</table>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.11"/> <!-- Immunization
Observation -->
…
</entry>
</section>
</component>
Figure 47: Immunizations List [with entries] entry example
5.14 INVESTIGATIVE PROCEDURE HISTORY [INVPROC]
The Investigative Procedure History Section communicates specific investigative events whose intent is
not to change the state of the patient, that have been recorded in the EMR system. This section is used to
communicate procedures that are undergone for investigative purposes but are not otherwise included in
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
176 DSTU (Revision 2013)
departmental specific sections – for example, Ultrasounds and Bone Scans may be included in the
Medical Imaging Results & Reports Section and blood tests may be included in the Laboratory Results &
Reports Section.
Examples of care that would be included in this section include:
ECG & Holter ECG;
Biopsy; and
Angiogram.
Investigative Procedure History Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.15(open)]
Table 52: Investigative Procedure History [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
An Investigative Procedure History [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:513].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:514].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:515] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.15"
[CONF:515.12].
4) SHALL contain exactly one [1..1] code="INVPROC" Investigative Procedure History (CodeSystem:
SectionType-CA-Pending 2.16.840.1.113883.3.3068.10.6.2) [CONF:516].
5) SHALL contain exactly one [1..1] title="Investigative Procedure History [without
entries]" [CONF:517] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:517.32].
6) SHALL contain exactly one [1..1] text [CONF:518].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.15.1(open)]
Table 53: Investigative Procedure History [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Care History Event
Generic Episodic Document
Generic Structured Referral
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
177 DSTU (Revision 2013)
Directly Used by Template(s) Directly Contains Template(s)
Patient Transfer
An Investigative Procedure History [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:519].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:520].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:521] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.15.1"
[CONF:521.12].
4) SHALL contain exactly one [1..1] code="INVPROC" Investigative Procedure History (CodeSystem:
SectionType-CA-Pending 2.16.840.1.113883.3.3068.10.6.2) [CONF:522].
5) SHALL contain exactly one [1..1] title="Investigative Procedure History [with
entries]" [CONF:523] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:523.32].
6) SHALL contain exactly one [1..1] text [CONF:524].
7) SHALL contain at least one [1..*] entry [CONF:525] such that each,
a) SHALL contain exactly one [1..1] Care History Event (2.16.840.1.113883.3.1818.10.3.6)
[CONF:525.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
178 DSTU (Revision 2013)
The following XML example outlines how to use the Investigative Procedure History [with entries]
template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.15.1"/>
<code code="INVPROC" displayName="Investigative Procedure Section"
codeSystem="2.16.840.1.113883.3.3068.10.6.2" codeSystemName="SectionType-CA-Pending"
/>
<title>Investigative Procedure History (with entries)</title>
<text>
<table border='1'>
<thead>
<tr><th>Procedure</th>
<th>Effective Date</th>
<th>Comments</th>
</tr>
</thead>
<tbody>
<tr><td>ECG</td>
<td>1994</td>
<td>Results on file</td>
</tr>
</tbody>
</table>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.6"/> <!-- Care History Event -->
…
</entry>
</section>
</component>
Figure 48: Investigative Procedure History [with entries] entry example
5.15 LABORATORY RESULTS & REPORTS [30954-2]
The Laboratory Results & Reports Section includes results and reports for laboratory tests or procedures
that were performed on the patient. A laboratory result may be documented as a report; where the report
may be communicated as a standalone clinical document rather than a document section. A stand-alone
laboratory report document may be attached to the patient record.
This section of the PITO E2E-DTC Specification is designed to communicate the laboratory results and
reports as a summary collection of all the laboratory results. The Laboratory Results & Reports section is
based on the HL7 IHE Health Story Consolidation Results section (formerly CCD Results), which is
specifically designed for result summaries.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
179 DSTU (Revision 2013)
Laboratory Results & Reports Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.16(open)]
Table 54: Laboratory Results & Reports [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Laboratory Results & Reports [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:715].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:716].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:717] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.16"
[CONF:717.12].
4) SHALL contain exactly one [1..1] code="30954-2" Relevant diagnostic tests and/or laboratory data
(CodeSystem: LOINC 2.16.840.1.113883.6.1) [CONF:718].
5) SHALL contain exactly one [1..1] title="Laboratory Results & Reports [without
entries]" [CONF:719] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:719.32].
6) SHALL contain exactly one [1..1] text [CONF:720].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.16.1(open)]
Table 55: Laboratory Results & Reports [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Laboratory Observation
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Laboratory Results & Reports [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:721].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:722].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:723] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.16.1"
[CONF:723.12].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
180 DSTU (Revision 2013)
4) SHALL contain exactly one [1..1] code="30954-2" Relevant diagnostic tests and/or laboratory data
(CodeSystem: LOINC 2.16.840.1.113883.6.1) [CONF:724].
5) SHALL contain exactly one [1..1] title="Laboratory Results & Reports [with entries]"
[CONF:725] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:725.32].
6) SHALL contain exactly one [1..1] text [CONF:726].
7) SHALL contain one or more (or a nullFlavor value) [1..*] entry [CONF:727] such that each,
a) SHALL contain exactly one [1..1] Laboratory Observation
(2.16.840.1.113883.3.1818.10.3.12) [CONF:727.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
181 DSTU (Revision 2013)
The following XML example outlines how to use the Laboratory Results & Reports [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.16.1"/>
<code code="30954-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Relevant diagnostic tests and/or laboratory data"/>
<title>Laboratory Results and Reports [with entries]</title>
<text>
<table border="1" width="100%">
<thead>
<tr>
<th> </th>
<th>March 23, 2000</th>
<th>April 06, 2000</th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="3">
<content styleCode="BoldItalics">Hematology</content>
</td>
</tr>
<tr>
<td>HGB (M 13-18 g/dl; F 12-16 g/dl)</td>
<td>13.2</td>
<td> </td>
</tr>
<tr>
<td>WBC (4.3-10.8 10+3/ul)</td>
<td>6.7</td>
<td> </td>
</tr>
<tr>
<td>PLT (135-145 meq/l)</td>
<td>123*</td>
<td> </td>
</tr>
<tr>
<td colspan="3">
<content styleCode="BoldItalics">Chemistry</content>
</td>
</tr>
<tr>
<td>NA (135-145meq/l)</td>
<td> </td>
<td>140</td>
</tr>
<tr>
<td>K (3.5-5.0 meq/l)</td>
<td> </td>
<td>4.0</td>
</tr>
<tr>
<td>CL (98-106 meq/l)</td>
<td> </td>
<td>102</td>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
182 DSTU (Revision 2013)
</tr>
<tr>
<td>HCO3 (18-23 meq/l)</td>
<td> </td>
<td>35*</td>
</tr>
</tbody>
</table>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.2.16.1"/> <!-- Laboratory
Observation -->
…
</entry>
</section>
</component>
Figure 49: Laboratory Results & Reports [with entries] entry example
5.16 MEDICAL HISTORY [11348-0]
The Medical History Section provides details on the past conditions or diagnosis that the patient may
have had which would have an effect on their care. Whilst this is very similar to the concept of “Problems
& Conditions”, there are some differences in clinical practice that should be recognized.
It is indeed possible to enter the past Medical History as a series of problems that are now inactive;
however, regardless of the EMR design, the time required to log the history as distinct inactive problems
can be prohibitive and it is common clinical practice to actually capture this information as a single textual
narrative. The requirement for coding this history is low as, by definition, these are not active problems.
Classic medical school teaching includes a section on Past Medical History and it exists as a distinct
section in current specialty consults.
Consequently, whist the Problems & Conditions structure and section could be used to communicate
Medical History; the PITO E2E-DTC Specification supports this distinct CDA section for Medical History
that may be communicated as human readable narrative text only using Medical History (without entries);
or may be coded with the Medical History (without entries) which uses the same Section-Entry Template
as provided for the Problems & Conditions Section. Clinical practice and EMR capabilities will dictate if
medical history is captured in the same section as Problems & Conditions or as a separate section.
Medical History Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.17(open)]
Table 56: Medical History [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
183 DSTU (Revision 2013)
Directly Used by Template(s) Directly Contains Template(s)
Generic Structured Referral
Patient Transfer
A Medical History [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:565].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:566].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:567] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.17"
[CONF:567.12].
4) SHALL contain exactly one [1..1] code="11348-0" History of past illness (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:568].
5) SHALL contain exactly one [1..1] title="Medical History [without entries]" [CONF:569]
such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:569.32].
6) SHALL contain exactly one [1..1] text [CONF:570].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.17.1(open)]
Table 57: Medical History [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Problem List Observation
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Medical History [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:571].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:572].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:573] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.17.1"
[CONF:573.12].
4) SHALL contain exactly one [1..1] code="11348-0" History of past illness (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:574].
5) SHALL contain exactly one [1..1] title="Medical History [with entries]" [CONF:575]
such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:575.32].
6) SHALL contain exactly one [1..1] text [CONF:576].
7) SHALL contain one or more (or a nullFlavor value) [1..*] entry [CONF:577] such that each,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
184 DSTU (Revision 2013)
a) SHALL contain exactly one [1..1] Problem List Observation
(2.16.840.1.113883.3.1818.10.3.15) [CONF:577.1].
The following XML example outlines how to use the Medical History [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.17.1"/>
<code code="11348-0" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="History of Past Illness"/>
<title>Medical History (with entries)</title>
<text>
<list>
<item>Diagnosis Code: Complete heart block, 27885002 (SNOMED CT)</item>
<item>Onset Date/Date Resolved: 01-DEC-2009/02-DEC-2009</item>
<item>Diagnosis Name: Syncope from Heart block</item>
<item>Problem Status: Inactive</item>
<item>Diagnosing Provider: Cardiologist, Excellent</item>
<item>Diagnosis Note: Syncope with pacemaker insertion for 3rd degree heart
block.</item>
<item>Lifestage at onset: Adult</item>
<item>Problem Outcome: Inactive</item>
</list>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.15"/> <!-- Problem List
Observation -->
…
</entry>
</section>
</component>
Figure 50: Medical History [with entries] entry example
5.17 MEDICAL IMAGING RESULTS & REPORTS [55115-0]
The Medical Imaging Results & Reports Section includes the results, images and reports for medical
imaging procedures that were performed on the patient including x-rays, CT Scans, MRI’s etc.
Medical Imaging Results & Reports Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.18(open)]
Table 58: Medical Imaging Results & Reports [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
185 DSTU (Revision 2013)
A Medical Imaging Results & Reports [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:702].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:703].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:704] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.18"
[CONF:704.12].
4) SHALL contain exactly one [1..1] code="55115-0" Requested imaging studies information
(CodeSystem: LOINC 2.16.840.1.113883.6.1) [CONF:705].
5) SHALL contain exactly one [1..1] title="Medical Imaging Results & Reports [without
entries]" [CONF:706] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:706.32].
6) SHALL contain exactly one [1..1] text [CONF:707].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.18.1(open)]
Table 59: Medical Imaging Results & Reports [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Medical Imaging Observation
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Medical Imaging Results & Reports [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:708].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:709].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:710] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.18.1"
[CONF:710.12].
4) SHALL contain exactly one [1..1] code="55115-0" Requested imaging studies information
(CodeSystem: LOINC 2.16.840.1.113883.6.1) [CONF:711].
5) SHALL contain exactly one [1..1] title="Medical Imaging Results & Reports [with
entries]" [CONF:712] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:712.32].
6) SHALL contain exactly one [1..1] text [CONF:713].
7) SHALL contain one or more (or a nullFlavor value) [1..*] entry [CONF:714] such that each,
a) SHALL contain exactly one [1..1] Medical Imaging Observation
(2.16.840.1.113883.3.1818.10.3.13) [CONF:714.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
186 DSTU (Revision 2013)
The following XML example outlines how to use the Medical Imaging Results & Reports [with entries]
template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.18.1"/>
<code code="55115-0" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Requested imaging studies information"/>
<title>Medical Imaging Results and Reports (with entries)</title>
<text>
<table border="1">
<tbody>
<tr>
<th>Procedure</th>
<th>Results</th>
<th>Date</th>
<th>Indication / Reason</th>
<th>Result Author</th>
</tr>
<tr>
<td>Chest x-ray</td>
<td>Nothing unusual could be observed. X-ray image is attached.
<!-- This will render the attachment image identified in the Encapsulated
Data Template below -->
<renderMultiMedia referencedObject="M11"></renderMultiMedia>
</td>
<td>Feb 11, 2013</td>
<td>Chest Pain</td>
<td>Dr. Raymond Xpert</td>
</tr>
</tbody>
</table>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.13"/> <!-- Medical Imaging
Observation -->
…
</entry>
</section>
</component>
Figure 51: Medical Imaging Results & Reports [with entries] entry example
5.18 MEDICATIONS & PRESCRIPTIONS - MEDICATION LIST [10160-0]
The Medications & Prescriptions section, also known as the Medication List, provides the detailed
medication history for the patient. This section will include both active and historical medications and
prescriptions along with any dispensing and administering information available.
The Current Medications Section may be used to send only the active medications for the patient in a
more summary view.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
187 DSTU (Revision 2013)
Key Design Principles
There are at least three overarching complexities in the Canadian EMR & EHR context that any
specification concerned with the exchange of medication data currently needs to consider and which
demand the establishment of a nuanced design that feasibly addresses, historical data and today’s
realities while positioning for the future. These complexities are respectively the result of our current
medication coding infrastructure (driven in large part from Health Canada’s regulatory regime and the
associated implementation practices); current efforts to establish “All Drugs All People” Drug Information
Systems (DIS) solutions and associated ePrescribing hubs; and the current status of EMR based
medication data model and user interface design constraints.
Given these fundamental design challenges, the PITO project team has attempted to illustrate pragmatic
choices that balance the need for a well-structured medication record with on-the-ground reality of today’s
typical EMR data structures. Specifically a tiered model of medications was devised that explicitly
separates the concept of a basic medication list from the detail pertaining to associated prescriptions,
from the dispense details pertaining to those prescriptions, and from the administration data that may or
may not be available in an EMR.
The following sections outline the three principle challenges and the project team’s specific approaches to
addressing each challenge.
Fluidity in the implementation scope and status of DIS solutions
Although it is ultimately assumed that jurisdictional DIS solutions (e.g. BC Pharmanet, AB PIN, etc.) will
contain more or less complete drug profiles, several factors drive for the need for a full medication profile
to be maintained in EMR solutions and exchanged as part of conversion processes or day-to-day
episodic data interchanges. These factors include the following:
Ambiguity over the completeness of EHR/DIS drug profiles in terms of “All drugs” and “All people”
comprehensiveness. For example:
Do or will they include relevant over the counter medications?
Do or will they include medications dispensed out of jurisdiction?
Do or will they include medications provided at the time of hospital discharge?
Are they or will they be fed by claims processes or other limited feeder mechanisms that exclude
individuals whether explicitly or inadvertently?
Ambiguity over the level of integration between EMRs and those DIS solutions. If profile information
is not rapidly accessible and interoperable with key features of the EMR then this may present a
barrier for use in day to day practice.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
188 DSTU (Revision 2013)
The approach taken by this specification to addressing this challenge is to include in the specification the
ability to communicate basic information regarding the dispense events and full information regarding
prescriptions. This will support the existing functionality of EMRs where a dispense event is documented
in the EMR; however, this will also allow for the exchange of this information when integration with a DIS
results in external dispense events being present in the EMR.
Variation in Data granularity
The variability in the level of granularity with which drug information is maintained in EMRs particularly in
relation to structured dosing. Although emerging DIS standards drive towards structured data –
particularly around dosing and administration instructions so as to be able to, for example, forecast the
length-of-therapy and whether to consider a prescription as part of the any contraindication checks – this
is not supported in a consistent manner at this time by EMR solutions.
The approach taken by this specification to addressing this challenge is to design the specification to be
able to transport unstructured or weakly structured medication or prescription data while positioning for
the exchange of deeply structured data that will become de rigueur as/when DIS solutions fully enable
ePrescribing and are broadly integrated with EMRs.
Medication Identification
A key challenge in medication management and prescribe functionality is the identification of medications
at prescribe time. In many cases prescriptions are specified at an intent level where the medication is
identified through a generic or chemical name and the intended dosage is identified. At dispense time, a
specific manufactured product and formulation is selected which correspond with the intensions of the
prescriber (subject to various formulary and policy considerations that may be in play). The reality is that
in many systems the prescription is identified by way of a DIN which narrowly describes a particular
product and form but may NOT ultimately correspond to the product or form that was dispensed. This
specification accepts this imperfect reality and allows multiple types of coding systems to be exchanged
from EMRs for the prescribed drug – including the DIN.
The following structure has been designed to support the flexibility required in medication identification
and recognize the industry usage of the DIN code as well as accommodate alternate coding mechanisms:
If the source system does contain a DIN code for the drug then the Drug Code element SHALL be
populated with the DIN code.
The receiving system SHALL support receipt of coded drugs using the DIN coding system.
If the source system does contain a code for the drug from any other recognized coding system then
the Drug Code element SHALL be repeated for each recognized code system populated.
The receiving system MAY support receipt of coded drugs using alternative recognized coding
systems.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
189 DSTU (Revision 2013)
Where there are intellectual property constraints on coding systems, the sending system SHALL
conform to these constraints.
Recognized Drug Coding Systems
The following Coding Systems are “Recognized” by the PITO E2E-DTC Specification.
Drug Identification Number (DIN)
DIN is a computer-generated eight digit number assigned by Health Canada to a drug product prior to being marketed in Canada. It uniquely identifies all drug products sold in a dosage form in Canada and is located on the label of prescription and over-the-counter drug products that have been evaluated and authorized for sale in Canada. A DIN uniquely identifies the following product characteristics: manufacturer; product name; active ingredient(s); strength(s) of active ingredient(s); pharmaceutical form; route of administration. http://www.hc-sc.gc.ca/dhp-mps/prodpharma/activit/fs-fi/dinfs_fd-eng.php
Natural Product Number (NPN)
The Licensed Natural Health Products Database contains information about natural health products that have been issued a product licence by Health Canada. Products with a license have been assessed by Health Canada and found to be safe, effective and of high quality under their recommended conditions of use. You can identify licensed natural health products by looking for the eight-digit Natural Product Number (NPN) or Homeopathic Medicine Number (DIN-HM) on the label. http://www.hc-sc.gc.ca/dhp-mps/prodnatur/about-apropos/index-eng.php
First Databank Commercial drug database & supporting tooling/reference materials (http://www.fdbhealth.com/)
Cerner Multum Commercial drug database & supporting tooling/reference materials (http://www.multum.com)
WHO ATC
The Anatomical Therapeutic Chemical (ATC) Classification System is used for the classification of drugs. It is controlled by the WHO Collaborating Centre for Drug Statistics Methodology (WHOCC). The classification system divides drugs into different groups according to the organ or system on which they act and/or their therapeutic and chemical characteristics. Each bottom-level ATC code stands for a pharmaceutically used substance in a single indication (or use). This means that one drug can have more than one code: acetylsalicylic acid (aspirin), for example, has A01AD05 as a drug for local oral treatment, B01AC06 as a platelet inhibitor, and N02BA01 as an analgesic and antipyretic. On the other hand, several different brands share the same code if they have the same active substance and indications. http://en.wikipedia.org/wiki/Anatomical_Therapeutic_Chemical_Classification_System
Use Cases
The following use-case structure has been developed to describe the scope and approach for the
Prescriptions & Medications section of the PITO E2E-DTC Specification.
The Prescriptions & Medications Section may be best described as a “Medications List” for the patient in
the medical record; however, the source of entries within the medication list varies and with the varying
sources the information available, appropriate or captured differs. Five basic use cases have been
identified for the capture of medication list entries and are listed in the following table along with the
expected impact on the available information within the EMR.
1. Provider Prescribed
The EMR Provider is the source of the prescription. The prescription is documented in the EMR directly and the prescription is communicated to a pharmacyor DIS to be dispensed (via paper by the patient or electronically). In this use-case the provider may capture detailed discrete data regarding the prescription, dispensing and administration expectations. However, the medication may be coded at a ‘prescription’ level using a coding system such as First Databank
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
190 DSTU (Revision 2013)
(FDB). A DIN code may not be assigned until the medication is dispensed by the pharmacy.
2. Provider Dispensed
The EMR Provider is the source of the prescription and the prescription is documented in the EMR directlyand the prescription is dispensed by the provider directly (for example a medication sample is given to the patient). In this use-case the provider may capture detailed discrete data regarding the prescription and a DIN code may be assigned or use an alternate coding system (e.g. FDB) to identify the medication. Administration expectations may also be captured.
3. Provider Administered
The EMR Provider is the source of the prescription and the prescription is documented in the EMR directly, the prescription is dispensed and administered by the provider directly (for example Botox injections). In this use-case the provider may capture detailed discrete data regarding the prescription and may be able to assign a DIN or use an alternate coding system (e.g. FDB) to identify the medication. The provider would also capture information regarding the administration of the medication in the similar fashion as an immunization administration record.
4. Patient Reported
The patient reports taking medications themselves and may be able to provide varying levels of details regarding the medication, dosage and administration. It is also possible that the medication is not in the physician’s formulary as it is from a different jurisdiction (i.e. non-Canadian). In this use-case the provider may capture very limited information regarding the medication and may not be able to code it with any coding system. Information may be limited the drug name without a dose, strength or specific administration dates or details.
5. Provider Reported
The EMR Provider receives information regarding a prescription or medication as directed by another provider. For example, receipt of a discharge summary from acute care may include details of discharge medications provided to the patient. In this use-case the provider may have some information regarding the medication as well as the dispensing and administration instructions; however, the information is provided 2nd hand and must be captured as such.
Other Design Considerations
Drug Interaction Checking
Drug interaction checking is a complex clinical decision support function that may be activated at the time
of prescribing a medication or during a medication list review. Drug interaction checking includes
checking for interactions against other drugs (prescribed and non-prescribed) as well as food and
environmental allergies or intolerances. It may also include checks against documented conditions or
problems that the patient may have, for example prescribing beta-blockers for a patient with asthma.
Due to the complexity of drug interaction checking, many EMR systems may trigger interaction alerts that
may be overridden by the provider. This is because an EMR will err on the side of triggering an
interaction alert, rather than assuming the alert does not apply. Consequently, providers are often
prompted with interactions that they must override. The EMR will document the alert override; however,
when the medication list is communicated to another EMR system the interaction override may be lost.
It would be desirable to communicate that an interaction has been presented to the provider and the
provider has ‘managed’ or overridden the interaction. The advantage of communicating this information
is for the convenience of the receiving provider where they will not be prompted again with alerts that
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
191 DSTU (Revision 2013)
have been managed by the sender and also to document why a potential interaction has been overridden
– for example, the benefits to the patient’s health outweigh the potential adverse event. However,
communicating this information in a structured fashion can be complex. For example it is necessary to
document exactly what combination of drugs has been managed – drug A+B might be ok, but adding
drug C may cause adverse events that are not ok. The source system may not be aware of Drug C, or
may not be aware of an allergy or condition that has been identified.
It is possible to build the necessary discrete data structures to communicate accurately the specific
interactions that have been managed; however, there is some inconsistency in the capabilities of the
EMR systems, clinical practice and standards available to do this. It is certainly beyond the scope of
communicating the medication and prescription history of the patient.
Consequently, in balancing the risk to patient care against the potential benefits of a structured drug
interaction checking the Project Team has determined that it is appropriate to err on the side of caution. It
is recommended that a future extension of the PITO E2E-DTC Specification be developed to
communicate interaction checking specifically; however, for this release of the specification, any
interaction checking information may be communicated in the free-text Medication Record Comment
element. This will ensure that the information may be communicated; but puts the onus on the provider to
articulate in the comment exactly what interactions have been managed.
PharmaNet Integration
BC is currently piloting the rollout of Pharmanet including full ePrescribing integration between
PharmaNet and EMR systems. Once interoperability between Pharmanet and EMR systems is available,
recent medication information may be accessed through PharmaNet directly. However, the inclusion of
the medication list and prescription history in the data extract confirms the extent of the authoring
provider's knowledge of that history. Additionally, PharmaNet information will be available for a
retrospective time period (14 months) and some patient’s conditions require reference to medications
taken farther back in the past, such as medications tried for mental health various chronic conditions, to
assess the time that they were used and their effectiveness.
Medications & Prescriptions - Medication List Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.19(open)]
Table 60: Medications & Prescriptions - Medication List [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
192 DSTU (Revision 2013)
A Medications & Prescriptions - Medication List [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:676].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:677].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:678] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.19"
[CONF:678.12].
4) SHALL contain exactly one [1..1] code="10160-0" History of medication use (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:679].
5) SHALL contain exactly one [1..1] title="Medications & Prescriptions - Medication
List [without entries]" [CONF:680] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:680.32].
6) SHALL contain exactly one [1..1] text [CONF:681].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.19.1(open)]
Table 61: Medications & Prescriptions - Medication List [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Medication Event
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Medications & Prescriptions - Medication List [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:682].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:683].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:684] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.19.1"
[CONF:684.12].
4) SHALL contain exactly one [1..1] code="10160-0" History of medication use (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:685].
5) SHALL contain exactly one [1..1] title="Medications & Prescriptions - Medication
List [with entries]" [CONF:686] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:686.32].
6) SHALL contain exactly one [1..1] text [CONF:687].
7) SHALL contain at least one [1..*] entry [CONF:688] such that each,
a) SHALL contain exactly one [1..1] Medication Event (2.16.840.1.113883.3.1818.10.3.18)
[CONF:688.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
193 DSTU (Revision 2013)
The following XML example outlines how to use the Medications & Prescriptions - Medication List [with
entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.19.1"/>
<code code="10160-6" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="History of Medication Use"/>
<title>Medications and Prescriptions - Medication List [with entries]</title>
<text>
<list>
<item> 1. Metformin 500 mg bid</item>
<item> 2. Losartan 100 mg bid</item>
<item> 3. Metoprolol Increased dose from 25 to 50 mg bid</item>
<item> 4. Clopidogrel 75 mg/d for 1 year, do not stop.v</item>
<item> 5. Atorvastatin 80 mg/d</item>
<item> 6. Nitrospray 0.4 mg SL PRN</item>
</list>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.18" /> <!-- Medication Event -->
…
</entry>
</section>
</component>
Figure 52: Medications & Prescriptions - Medication List [with entries] entry example
5.19 ORDERS & REQUESTS [REQS]
The Orders and Requests Section includes records of orders for any diagnostic services, treatments,
interventions, therapies that may have been made for the patient. This section may also be used to
communicate referral orders and requests to other providers. The Orders Section may be used to
communicate orders independently of results or reports received; however, they may link to
results/reports, or outcomes of the order may be documented and included attached to the order.
Orders that are still in progress (i.e. no results received yet) may be communicated using this section.
Orders & Requests Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.20(open)]
Table 62: Orders & Requests [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
194 DSTU (Revision 2013)
An Orders & Requests [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:728].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:729].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:730] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.20"
[CONF:730.12].
4) SHALL contain exactly one [1..1] code="REQS" Orders and Requests (CodeSystem: SectionType-
CA-Pending 2.16.840.1.113883.3.3068.10.6.2) [CONF:731].
5) SHALL contain exactly one [1..1] title="Orders & Requests [without entries]"
[CONF:732] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:732.32].
6) SHALL contain exactly one [1..1] text [CONF:733].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.20.1(open)]
Table 63: Orders & Requests [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Order Event
Generic Episodic Document
Generic Structured Referral
Patient Transfer
An Orders & Requests [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:734].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:735].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:736] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.20.1"
[CONF:736.12].
4) SHALL contain exactly one [1..1] code="REQS" Orders and Requests (CodeSystem: SectionType-
CA-Pending 2.16.840.1.113883.3.3068.10.6.2) [CONF:737].
5) SHALL contain exactly one [1..1] title="Orders & Requests [with entries]" [CONF:738]
such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:738.32].
6) SHALL contain exactly one [1..1] text [CONF:739].
7) SHALL contain one or more (or a nullFlavor value) [1..*] entry [CONF:740] such that each,
a) SHALL contain exactly one [1..1] Order Event (2.16.840.1.113883.3.1818.10.3.14)
[CONF:740.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
195 DSTU (Revision 2013)
The following XML example outlines how to use the Orders & Requests [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.20.1"/>
<code code="REQS" codeSystem="2.16.840.1.113883.3.3068.10.6.2"
codeSystemName="SectionType-CA-Pending" displayName="Problems list Reported"/>
<title>Orders and Requests (with entries)</title>
<text>
<list>
<item>
GI Consult; Feb 18, 2013;
Status: New
Priority: Routine
Reason: Screening colonoscopy. Family history of cancer of colon, 312824007,
SNOMED CT
Comments: You have seen this lady 5 years ago. She had clear colonoscopy
then. Due again.
Performer: Gastroenterology specialist
</item>
</list>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.14"/> <!-- Order Event -->
…
</entry>
</section>
</component>
Figure 53: Orders & Requests [with entries] entry example
5.20 PROBLEMS & CONDITIONS - PROBLEM LIST [11450-4]
The problem list may be viewed as the table of contents into the patient’s record. While some of the
information that would be exchanged in a CDA type document would be of transient interest items in the
Problem List would be of more enduring interest. Information in the problem list may be used for various
functions including providing a summary of issues, concerns or conditions that the patient has or had. The
other functions would be to provide the indication or reasons that various other activities were done.
When a medication is prescribed the prescription could be linked to one or more problems as could
investigations and referrals. For an individual encounter one or more Problems could be selected as
having been an issue during that encounter.
The BC College of Physicians and Surgeons stipulates that a patient`s medical record include a problem
list. This is difficult to maintain in a paper chart. Time and effort needs to go into maintaining a computer
based Problem List but the increased utility can be the benefit. The Problem List can be used as the basis
of a chronic disease registry and for identifying patients that could be billed for various GPSC chronic
disease management fees. The utility of the Problem List can be seen in routine encounters when
referrals are being made or investigations are ordered.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
196 DSTU (Revision 2013)
Additional Design Considerations
The following items have been identified as other design considerations in the process of managing
diagnosis. These are not be able to be completely resolved through the definition of an interchange
specification as they require EMR functionality and/or clinician practice changes to be addressed
completely. They are documented here to acknowledge them and to address how the specification may
support their resolution.
Relevant Investigations
There needs to be a way to capture relevant investigations and treatments for a given problem. This may
start out as a clinical diagnosis of "Cough" and lead to a chest x-ray showing a "Pulmonary nodule" and
bronchoscopy showing "Lung cancer" and treatments including surgery, radiation and chemotherapy. The
coding needs to capture the transition in primary diagnosis, while keeping the "parent-child" relationships
together. The capabilities of EMR systems, as well as clinician practice, are inconsistent; consequently,
the PITO E2E-DTC Specification does not provide specific guidance on how these requirements are
captured or communicated.
Problem Hierarchies
The Problems/Conditions recorded in the Problem List are often related to each other. For example, a
patient may have a Problem “Heart Disease”, and may have a related child problem of “postoperative
subendocardial myocardial infarction”. It was expected that the SNOMED hierarchies could accomplish
the relationship between these problems; however, with the inconsistent implementation of SNOMED,
this is not a feasible option.
A related and resultant EMR functionality requirement; is that there is a need to be able to change the
names of problems and to rearrange the parent child relationships. For example, at one point it may
appear that a patient has several problems but as things come to light it becomes understood that what
appeared to be individual problems are actually related to a different problem. A patient that has chronic
peptic ulcers and surgery for a perforated ulcer and tingling in the feet with a low B12 level and anemia is
found to have a problem with intrinsic factor deficiency.
Existing specifications do not have the capability of identifying an item on the Problem List and allowing
linkage to related problems. Whilst some consideration has been given to including a mechanism for
linking problems in the problem list using the Record ID element; this has been determined to be a
clumsy approach that does not address the full extent of the requirements. There is also some concern
over how this could be implemented by the EMR systems. Consequently this capability is not being
included in the specifications.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
197 DSTU (Revision 2013)
Problems & Conditions - Problem List Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.21(open)]
Table 64: Problems & Conditions - Problem List [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Problems & Conditions - Problem List [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:578].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:579].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:580] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.21"
[CONF:580.12].
4) SHALL contain exactly one [1..1] code="11450-4" Problem list (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:581].
5) SHALL contain exactly one [1..1] title="Problems & Conditions - Problem List
[without entries]" [CONF:582] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:582.32].
6) SHALL contain exactly one [1..1] text [CONF:583].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.21.1(open)]
Table 65: Problems & Conditions - Problem List [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Problem List Observation
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Problems & Conditions - Problem List [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:584].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:585].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:586] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.21.1"
[CONF:586.12].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
198 DSTU (Revision 2013)
4) SHALL contain exactly one [1..1] code="11450-4" Problem list (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:587].
5) SHALL contain exactly one [1..1] title="Problems & Conditions - Problem List [with
entries]" [CONF:588] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:588.32].
6) SHALL contain exactly one [1..1] text [CONF:589].
7) SHALL contain one or more (or a nullFlavor value) [1..*] entry [CONF:590] such that each,
a) SHALL contain exactly one [1..1] Problem List Observation
(2.16.840.1.113883.3.1818.10.3.15) [CONF:590.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
199 DSTU (Revision 2013)
The following XML example outlines how to use the Problems & Conditions - Problem List [with entries]
template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.21.1"/>
<code code="11450-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Problems list Reported"/>
<title>Problems and Conditions - Problem List (with entries)</title>
<text>
<list>
<item>
Diagnosis Code: Essential hypertension, 59621000 (SNOMED CT)
Onset Date/Date Resolved: 14-aug-2001
Diagnosis Name: Hypertension
Problem Status: Active
Diagnosing Provider (id): Wpewarchuk (023377)
Diagnosis Billing Code: 401 (ICD-9)
Diagnosis Date: 15-aug-2001
Diagnosis Note: BP generally a bit high despite meds.
Diagnosis Modifier: Moderate severity
Lifestage at onset: Adult
</item>
<item>
Diagnosis Code: Coronary arteriosclerosis, 53741008 (SNOMED CT)
Onset Date/Date Resolved: 13-Feb-2013
Diagnosis Name: CAD
Problem Status: Active
Diagnosing Provider (id).: Wpewarchuk (023377)
Diagnosis Billing Code: 414
Diagnosis Date: 13-Feb-2013
Diagnosis Note: Unstable angina, admitted and had drug-eluting RCA stent.
Lifestage at onset: Unknown
</item>
</list>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.15"/> <!-- Problem List
Observation -->
…
</entry>
</section>
</component>
Figure 54: Problems & Conditions - Problem List [with entries] entry example
5.21 PURPOSE [42349-1]
A Purpose section records the reason why the document is being generated.
Purpose Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.22(closed)]
Table 66: Purpose Template Context
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
200 DSTU (Revision 2013)
Directly Used by Template(s) Directly Contains Template(s)
Generic Episodic Document N/A
Generic Structured Referral
Patient Transfer
A Purpose (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:455].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:456].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:457] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.22"
[CONF:457.12].
4) SHALL contain exactly one [1..1] code="42349-1" Reason for referral (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:458].
5) SHALL contain exactly one [1..1] title="Purpose / Reason" [CONF:459] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:459.32].
6) SHALL contain exactly one [1..1] text [CONF:460].
The following XML example outlines how to use the Purpose template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.22"/> <!-- Purpose Section -->
<code code="42349-1" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Reason For Referral"/>
<title>Purpose [without entries]</title>
<text>
<paragraph>Patient spends 4 months yearly with husband in Mexico.
Copy of records for patient in case of health issues while away.
</paragraph>
</text>
</section>
</component>
Figure 55: Purpose entry example
5.22 REPRODUCTIVE OBSERVATIONS [56833-7]
The Reproductive History Observations Section provides information on metrics specific to maternity
patient requirements. This section includes reproductive history summary information such as the number
of term births, living children, and spontaneous abortions etc. It also includes specific pregnancy detail
record information for each pregnancy including growth curve measurements of the fundus, due date and
paternal information.
This section supports both free text observations as well as discrete data encoded using a standards
based nomenclature.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
201 DSTU (Revision 2013)
The section follows the standard Organizer-Grouped Observations pattern.
Reproductive Observations Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.23(open)]
Table 67: Reproductive Observations [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Reproductive Observations [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:617].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:618].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:619] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.23"
[CONF:619.12].
4) SHALL contain exactly one [1..1] code="56833-7" Pregnancy related history (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:620].
5) SHALL contain exactly one [1..1] title="Reproductive Observations [without entries]"
[CONF:621] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:621.32].
6) SHALL contain exactly one [1..1] text [CONF:622].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.23.1(open)]
Table 68: Reproductive Observations [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Reproductive Observations Organizer
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Reproductive Observations [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:623].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:624].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:625] such that each,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
202 DSTU (Revision 2013)
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.23.1"
[CONF:625.12].
4) SHALL contain exactly one [1..1] code="56833-7" Pregnancy related history (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:626].
5) SHALL contain exactly one [1..1] title="Reproductive Observations [with entries]"
[CONF:627] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:627.32].
6) SHALL contain exactly one [1..1] text [CONF:628].
7) SHALL contain one or more (or a nullFlavor value) [1..*] entry [CONF:629] such that each,
a) SHALL contain exactly one [1..1] Reproductive Observations Organizer
(2.16.840.1.113883.3.1818.10.3.16) [CONF:629.1].
The following XML example outlines how to use the Reproductive Observations [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.23.1"/> <!-- Reproductive
Observations Section -->
<code code="56833-7" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Pregnancy related history"/>
<title>Reproductive Observations [with entries]</title>
<text>
<list>
<item>Gravida 5</item>
<item>Term 3</item>
<item>Preterm 1</item>
<item>Spontaneous Abortions 1</item>
<item>Induced Terminations 0</item>
<item>Births Still Living 4 </item>
<item>last Menstrual Period Feb 10, 2000</item>
</list>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.16"/> <!-- Reproductive
Observations Organizer -->
…
</entry>
</section>
</component>
Figure 56: Reproductive Observations [with entries] entry example
5.23 RISK FACTORS [46467-7]
The Risk Factors Section provides information regarding factors that may have a medical impact on the
course of care of the patient such as smoking status, social behaviours, employment environment etc.
This section supports both free text risk factors as well as discrete data encoded using a standards based
nomenclature.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
203 DSTU (Revision 2013)
Risk Factors Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.24(open)]
Table 69: Risk Factors [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Risk Factors [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:741].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:742].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:743] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.24"
[CONF:743.12].
4) SHALL contain exactly one [1..1] code="46467-7" High Risk Factors (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:744].
5) SHALL contain exactly one [1..1] title="Risk Factors [without entries]" [CONF:745]
such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:745.32].
6) SHALL contain exactly one [1..1] text [CONF:746].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.24.1(open)]
Table 70: Risk Factors [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Risk Factors Organizer
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Risk Factors [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:747].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:748].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:749] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.24.1"
[CONF:749.12].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
204 DSTU (Revision 2013)
4) SHALL contain exactly one [1..1] code="46467-7" High Risk Factors (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:750].
5) SHALL contain exactly one [1..1] title="Risk Factors [with entries]" [CONF:751] such
that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:751.32].
6) SHALL contain exactly one [1..1] text [CONF:752].
7) SHALL contain one or more (or a nullFlavor value) [1..*] entry [CONF:753] such that each,
a) SHALL contain exactly one [1..1] Risk Factors Organizer
(2.16.840.1.113883.3.1818.10.3.17) [CONF:753.1].
The following XML example outlines how to use the Risk Factors [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.24.1"/>
<code code="46467-7" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="High risk factors OASIS"/>
<title>Risk Factors [with entries]</title>
<text>
<table border='1'>
<thead>
<tr><th>Social History</th><th>Comments</th><th>Date Range</th></tr>
</thead>
<tbody>
<tr><td>Smoking</td><td>1/2 pack per day</td><td>1996-present</td></tr>
<tr><td>Alcohol Use</td><td>1-2 drinks per week</td><td></td></tr>
</tbody>
</table>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.17"/> <!-- Risk Factor Organizer
-->
…
</entry>
</section>
</component>
Figure 57: Risk Factors [with entries] entry example
5.24 SURGICAL PROCEDURE HISTORY [10167-5]
The Surgical Procedure History Section communicates specific surgical or procedural events whose
intent is to change the state of the patient, that have been recorded in the EMR system. This section is a
combination of the scope of the Surgical History and the Procedures section.
Examples of care that would be included in this section include:
Cardiac Surgery; and
Colonoscopy.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
205 DSTU (Revision 2013)
Surgical Procedure History Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.25(open)]
Table 71: Surgical Procedure History [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Surgical Procedure History [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:500].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:501].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:502] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.25"
[CONF:502.12].
4) SHALL contain exactly one [1..1] code="10167-5" History of surgical procedures (CodeSystem:
LOINC 2.16.840.1.113883.6.1) [CONF:503].
5) SHALL contain exactly one [1..1] title="Surgical Procedure History [without
entries]" [CONF:504] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:504.32].
6) SHALL contain exactly one [1..1] text [CONF:505].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.25.1(open)]
Table 72: Surgical Procedure History [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Care History Event
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Surgical Procedure History [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:506].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:507].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:508] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.25.1"
[CONF:508.12].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
206 DSTU (Revision 2013)
4) SHALL contain exactly one [1..1] code="10167-5" History of surgical procedures (CodeSystem:
LOINC 2.16.840.1.113883.6.1) [CONF:509].
5) SHALL contain exactly one [1..1] title="Surgical Procedure History [with entries]"
[CONF:510] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:510.32].
6) SHALL contain exactly one [1..1] text [CONF:511].
7) SHALL contain at least one [1..*] entry [CONF:512] such that each,
a) SHALL contain exactly one [1..1] Care History Event (2.16.840.1.113883.3.1818.10.3.6)
[CONF:512.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
207 DSTU (Revision 2013)
The following XML example outlines how to use the Surgical Procedure History [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.25.1"/>
<code code="10167-5" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="History of surgical procedures "/>
<title>Care History [with entries]</title>
<text>
<list>
<item>Intervention Code/Name: Cardiac pacemaker procedure, 233174007 (SNOMED
CT)</item>
<item>Intervention Name: Pacemaker insertion</item>
<item>Intervention Status: Completed</item>
<item>Intervention DatetimeL 02-Dec-2009</item>
<item>Intervention Reason: Complete heart block, 27885002 (SNOMED CT)</item>
<item>Intervention Qualifier: Right infraclavicular</item>
<item>Intervention Comment: Syncope with pacemaker insertion for 3rd degree
heart block.</item>
<item>Follow-up Comments: Pacemaker rechecks every 3 months</item>
</list>
<list>
<item>Intervention Code/Name: Appendectomy, 80146002 (SNOMED CT)</item>
<item>Intervention Name: Appy</item>
<item>Intervention Status: Completed</item>
<item>Intervention Datetime: 1957</item>
<item>Intervention Reason: Acute appendicitis with appendix abscess,
266439004 (SNOMED CT)</item>
<item>Intervention Comment: 3 weeks in hospital</item>
</list>
<list>
<item>Intervention Code/Name: Bilateral breast implants, 52852000 (SNOMED
CT)</item>
<item>Intervention Name: Breast augmentation</item>
<item>Intervention Status: Completed</item>
<item>Intervention Datetime: 05-jul-1967</item>
<item>Intervention Reason: </item>
<item>Intervention Qualifier: Bilateral</item>
</list>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.6"/> <!-- Care History Event -->
…
</entry>
</section>
</component>
Figure 58: Surgical Procedure History [with entries] entry example
5.25 TREATMENT HISTORY [62387-6]
The Treatment History Section communicates information regarding the treatments, therapies or care that
the patient has undergone. This section is specifically designed to communicate treatments that have
occurred over time with multiple encounters or episodes of care and is a combination of the scope of the
Hospitalizations, Treatments and Referrals requirements.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
208 DSTU (Revision 2013)
Examples or care that would be included in this section include:
Hospitalization;
Referrals to specialist for treatments;
Physiotherapy treatment series;
Acupuncture treatment series; and
Chemotherapy.
Treatment History Template Definitions
Section template without Coded Entries (Level 2)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.26(open)]
Table 73: Treatment History [without entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion N/A
Generic Episodic Document
Generic Structured Referral
Patient Transfer
A Treatment History [without entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:487].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:488].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:489] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.26"
[CONF:489.12].
4) SHALL contain exactly one [1..1] code="62387-6" Interventions (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:490].
5) SHALL contain exactly one [1..1] title="Treatment History [without entries]"
[CONF:491] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:491.32].
6) SHALL contain exactly one [1..1] text [CONF:492].
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.26.1(open)]
Table 74: Treatment History [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Care History Event
Generic Episodic Document
Generic Structured Referral
Patient Transfer
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
209 DSTU (Revision 2013)
A Treatment History [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:493].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:494].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:495] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.26.1"
[CONF:495.12].
4) SHALL contain exactly one [1..1] code="62387-6" Interventions (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:496].
5) SHALL contain exactly one [1..1] title="Treatment History [with entries]" [CONF:497]
such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:497.32].
6) SHALL contain exactly one [1..1] text [CONF:498].
7) SHALL contain at least one [1..*] entry [CONF:499] such that each,
a) SHALL contain exactly one [1..1] Care History Event (2.16.840.1.113883.3.1818.10.3.6)
[CONF:499.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
210 DSTU (Revision 2013)
The following XML example outlines how to use the Treatment History [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.26.1"/>
<code code="62387-6" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Interventions "/>
<title>Treatment History [with entries]</title>
<text>
Admission to Community hospital for chest pain and transfer to tertiary care
facility for angiogram
Discharge Summary
<list>
<item>Date of Admission: February 11, 2013</item>
<item>Date of Discharge: February 13, 2013 </item>
<item>Reason: Subendocardial myocardial infarction/acute coronary
syndrome</item>
<item>PREADMISSION COMORBIDITY: Allergic rhinitis /sinusitis. </item>
</list>
<paragraph>
This 66-year-old-lady was admitted through the hospital emergency department
after having had spells of heaviness in the chest and
arm tingling.
This was initially not associated with any ECG change, but with a troponin rise
of 1 increasing to 2.
During the time of the hospitalization, she was treated with nitrates, low
molecular weight heparin, Clopidogrel, and
low dose beta blockade.
Despite this, she had repeated spells of chest discomfort and wound up being
placed on higher dose of beta blockade, transdermal nitrates.
She developed inferior wall asymmetric T-wave inversion and did have transient
ST segment depression with pain.
Her case was discussed with Dr. Eric Fretz, and based on this discussion we did
institute integrilin drip and Dr. Fretz made
arrangements for transfer to the Royal Jubilee Hospital CCU for expediting
angiography on the 13th of February.
THIS DOCUMENT HAS BEEN DICTATED BUT NOT READ:
Dr. VG Internist
D: 13-feb-2013 22:00 T: 23-feb-2013 10:19
Transferred to Royal Jubilee Hospital
</paragraph>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.6"/> <!-- Care History Event -->
…
</entry>
</section>
</component>
Figure 59: Treatment History [with entries] entry example
5.26 UNCLASSIFIED DOCUMENTS [46450-3]
The Unclassified Documents Section provides the ability to communicate clinical or administrative
documents that are part of the patient’s chart but that have not been identified as a particular type of
document. This section is designed to enable the communication of documents attached to the patient’s
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
211 DSTU (Revision 2013)
chart in the source system without any codification of their type (e.g. laboratory, advanced directive,
diagnostic report, and discharge summaries). This section should explicitly NOT be used as a catchall for
document attachments that would more appropriately be communicated in the relevant section of the
specification. Any meta-data about the document attachment should be communicated with the
document.
Unclassified Documents Template Definitions
Section template with Coded Entries Required (Level 3)
[Section: templateId 2.16.840.1.113883.3.1818.10.2.27.1(open)]
Table 75: Unclassified Documents [with entries] Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR Conversion Unclassified Documents Organizer
Patient Transfer
An Unclassified Documents [with entries] (Section) element:
1) SHALL contain exactly one [1..1] @classCode="DOCSECT" document section (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:4452].
2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:4453].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:4454] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.2.27.1"
[CONF:4454.12].
4) SHALL contain exactly one [1..1] code="46450-3" Text-Miscellaneous Section (CodeSystem:
LOINC 2.16.840.1.113883.6.1) [CONF:4455].
5) SHALL contain exactly one [1..1] title="Unclassified Documents [with entries]
[PITO]" [CONF:4456] such that it,
a) MAY contain content that differs from the suggested text as long as it SHALL NOT conflict with the meaning intended by the fixed content of the code element [CONF:4456.32].
6) SHALL contain exactly one [1..1] text [CONF:4457].
7) SHALL contain at least one [1..*] entry [CONF:4458] such that each,
a) SHALL contain exactly one [1..1] Unclassified Documents Organizer
(2.16.840.1.113883.3.1818.10.3.19) [CONF:4458.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
212 DSTU (Revision 2013)
The following XML example outlines how to use the Unclassified Documents [with entries] template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.26.1"/>
<code code="46450-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Text-Miscellaneous Section"/>
<title>Unclassified Documents [with entries] [PITO]</title>
<text>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.27.1"/> <!-- Unclassified
Documents Organizer -->
...
</entry>
</section>
</component>
Figure 60: Unclassified Documents [with entries] entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
213 DSTU (Revision 2013)
6.0 SECTION ENTRY TEMPLATES This chapter contains the Section-Entry Templates referenced by one or more of the Section Templates
of the PITO E2E-DTC Specification. These templates contain the structured entry constraints that are
required for the section. Note that the Section-Entry Templates are presented in alphabetical order;
templates are not grouped by possible containing templates.
Section-Entry Templates are always allowed in sections.
Each Section-Entry Templates description contains the following information:
Key template metadata (e.g., templateId, etc.);
Description and explanatory narrative;
Entry Templates names and IDs for referenced templates (required and optional)
Required CDA acts, participants and vocabularies; and
Optional CDA acts, participants and vocabularies.
6.1 ADVANCED DIRECTIVES OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.3.1(open)]
Table 76: Advanced Directives Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Advance Directives [with entries] Attachment
Comment Observation
Date Observation
The Advanced Directives Observation template is the entry point for advanced directives and includes all
the meta data regarding the advanced directive such as the start/end dates, verification information,
custodian information and either the actual text of the advanced directive or an attachment reference
including (or referencing) the applicable advanced directive document.
Table 77: Advanced Directives Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
754 @typeCode M:1..1
755 templateId O:0..* II
756 observation O:0..*
757 @classCode M:1..1
758 @moodCode M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
214 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
759 Record ID Record ID associated with the Advance Directive.
id M:1..1 II
760 Advance Directive Type Categorization of the Advance Directive.
code R:1..1 CD
761 Advance Directive Text If the Advance Directive has been captured as text within the Source system, this element SHALL contain the text of the Advance Directive.
text R:1..1 ED
762 Advance Directive Status The status of the Advance Directive (Active or Complete).
statusCode M:1..1 CS
763 Start Date/End Date The effective or start date associated with the Advance Directive.
effectiveTime R:1..1 IVL_TS
764 Verified Date/Time entryRelationship (Date
Observation)
R:0..1
765 Attachment If the Advanced Directive has been attached to the patient’s chart, this element SHALL contain the attachment. An attachment always SHALL be present if Advanced Directive Text is not present.
entryRelationship
(Attachment)
R:0..1
766 Comments Additional textual information regarding the Advance Directive as captured in the EMR. (E.g. “have discussed with patient and NOK or guardian”).
entryRelationship
(Comment Observation)
R:0..*
767 Custodian participant R:0..1
768 @typeCode M:1..1
769 @contextControlCode O:1..1
770 Custodian Role participantRole R:0..1
771 @classCode M:1..1
772 Custodian Telecom telecom R:0..1 TEL
773 Custodian Address addr R:0..1 AD
774 Custodian Person/Organization playingEntity R:0..1
775 @classCode M:1..1
776 @determinerCode M:1..1
777 Custodian's name name R:0..1 PN
An Advanced Directives Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:754].
2) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:755] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.1"
[CONF:755.12].
3) MAY contain zero or more [0..*] {CDAR2} observation [CONF:756].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
215 DSTU (Revision 2013)
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:757].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:758].
c) SHALL contain exactly one [1..1] id [CONF:759].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] code, which SHALL be selected from
ValueSet AdvanceDirectiveType 2.16.840.1.113883.3.3068.10.8.6 STATIC [CONF:760].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] text [CONF:761].
f) SHALL contain exactly one [1..1] statusCode, which SHALL be selected from ValueSet
x_ActStatusActiveComplete 2.16.840.1.113883.1.11.19890 STATIC [CONF:762] such that it,
i) SHALL be constrained to either Active or Completed status codes [CONF:762.34].
g) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:763] such
that it,
i) SHALL contain exactly one [1..1] low value to indicate the Start Date/Time and MAY contain
zero or one [0..1] high values to indicate the End Date/Time [CONF:763.50].
h) SHALL contain zero or one if available [0..1] entryRelationship [CONF:764] such that it,
i) SHALL contain exactly one [1..1] Date Observation
(2.16.840.1.113883.3.1818.10.4.4) [CONF:764.1].
i) SHALL contain zero or one if available [0..1] entryRelationship [CONF:765] such that it,
i) SHALL contain exactly one [1..1] Attachment (2.16.840.1.113883.3.1818.10.4.1)
[CONF:765.1].
j) SHALL contain zero or more if available [0..*] entryRelationship [CONF:766] such that each,
i) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:766.1].
k) SHALL contain zero or one if available [0..1] participant [CONF:767].
i) SHALL contain exactly one [1..1] @typeCode="CST" custodian (CodeSystem:
ParticipationType 2.16.840.1.113883.5.90) [CONF:768].
ii) MAY contain zero or one [1..1] {CDAR2} @contextControlCode="OP" overriding
propagating (CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:769].
iii) SHALL contain zero or one if available [0..1] participantRole [CONF:770].
(1) SHALL contain exactly one [1..1] @classCode="ASSIGNED" assigned (CodeSystem:
RoleClass 2.16.840.1.113883.5.110) [CONF:771].
(2) SHALL contain zero or one if available [0..1] telecom [CONF:772] such that it,
(a) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.2) [CONF:772.5].
(3) SHALL contain zero or one if available [0..1] addr [CONF:773] such that it,
(a) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.1) [CONF:773.5].
(4) SHALL contain zero or one if available [0..1] playingEntity [CONF:774].
(a) SHALL contain exactly one [1..1] @classCode="PSN" person (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:775].
(b) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:776].
(c) SHALL contain zero or one if available [0..1] name [CONF:777].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
216 DSTU (Revision 2013)
The following XML example outlines how to use the Advanced Directives Observation template:
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.1"/> <!-- Advance
Directives Observation -->
<observation classCode="OBS" moodCode="EVN">
<id extension="123669" root="2.16.840.1.113883.3.1818.10.2.10.33"/>
<code code="304251008" displayName="Resuscitation"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED-CT">
</code>
<text>
Advance Directive: Resuscitation Status: DNR 4 (full resucitation),
documentation stored with GP,
Discussed with patient and confirmed on January 11, 2013.
</text>
<statusCode code="active"/>
<effectiveTime value="20130111"/>
<!-- Custodian (note this does NOT use the Provider Participation template)-->
<participant typeCode="CST" contextControlCode="OP">
<participantRole classCode="ASSIGNED">
<addr>
<streetAddressLine>4444 Healthcare Drive</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel: (555) 555-1003" use="WP"/>
<playingEntity classCode="PSN" determinerCode="INSTANCE">
<name>
<prefix>Dr.</prefix>
<given>Harold</given>
<given>H.</given>
<family>Hippocrates</family>
<suffix>the 1st</suffix>
</name>
</playingEntity>
</participantRole>
</participant>
<!-- Comments -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment
Observation -->
<observation classCode="OBS" moodCode="EVN">
<id extension="123" root="1.2.3.4"/>
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Patient advised to review package of care</text>
<effectiveTime value="20120202"/>
<value xsi:type="CD" code="413324005" displayName="Patient advised to
review package of care" codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED-CT" />
<!-- Comment Author -->
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
217 DSTU (Revision 2013)
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<name>Healthcare Drive Clinical Centre</name>
</representedOrganization>
</assignedAuthor>
</author>
</observation>
</entryRelationship>
<!-- Verified Date -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.4"/> <!-- Date
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="DATEOBS" displayName="Date Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<effectiveTime value="20120201114523-0700"/>
</observation>
</entryRelationship>
<!-- Attachment or Reference -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.1"/> <!-- Attachment -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="ATTACH" displayName="Attachment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Keywords: DNR 4, full resucitation</text>
<effectiveTime value="20120202"/>
<e2e:confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<value xsi:type="ST">Resucitation Order</value>
<!-- Attachment Notes -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="ST">Attachment Note included here</value>
</observation>
</entryRelationship>
<!-- Reviewed Dates -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
218 DSTU (Revision 2013)
<templateId root="2.16.840.1.113883.3.1818.10.4.4"/> <!-- Date
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="DATEOBS" displayName="Date Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<effectiveTime value="20120201114523-0700"/>
</observation>
</entryRelationship>
<!-- Attachment or Reference -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.9"/> <!-- Encapsulated
Data -->
<observationMedia classCode="OBS" moodCode="EVN">
<id extension="127797" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<value xsi:type="ED" mediaType="application/pdf">
<reference value="http://www.anywhere.com/folder1/20120202-Patient1-
claim1.pdf"/>
</value>
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
</observationMedia>
</entryRelationship>
</observation>
</entryRelationship>
</observation>
</entry>
Figure 61: Advanced Directives Observation entry example
6.2 ALERT OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.3.2(open)]
Table 78: Alert Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Alerts [with entries] Attachment
Comment Observation
The Alert Observation template is the entry point for alerts and includes the elements needed to describe
an alert. This template also enables the inclusion of an attachment and comments relevant to the alert.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
219 DSTU (Revision 2013)
Table 79: Alert Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
778 @typeCode M:1..1
779 templateId O:0..* II
780 observation O:0..*
781 @classCode M:1..1
782 @moodCode M:1..1
783 Record ID Record ID associated with the alert.
id M:1..1 II
784 Alert Type Categorization of the alert.
code R:1..1 CD
785 Alert Text If the Alert has been captured as text within the Source system, this element SHALL contain the text of the Alert.
text R:1..1 ED
786 Alert Status The status of the Alert.
statusCode M:1..1 CS
787 Start Date/End Date The effective or start date associated with the alert.
effectiveTime R:1..1 IVL_TS
788 Confidentiality The confidentiality of the Alert coded using HL7 Confidentiality Code.
e2e:confidentialityCode R:1..1
789 Attachment If the Alert has been attached to the patient’s chart, this element SHALL contain the attachment. An attachment always SHALL be present if Alert Text is not present.
entryRelationship
(Attachment)
R:0..1
790 Comment Additional textual information regarding the alert as captured in the EMR. (E.g. “have discussed with patient and NOK or guardian”).
entryRelationship
(Comment Observation)
R:0..1
An Alert Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:778].
2) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:779] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.2"
[CONF:779.12].
3) MAY contain zero or more [0..*] {CDAR2} observation [CONF:780].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:781].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:782].
c) SHALL contain exactly one [1..1] id [CONF:783].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] code, which SHALL be selected from
ValueSet AlertType 2.16.840.1.113883.3.1818.10.8.1 STATIC [CONF:784].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
220 DSTU (Revision 2013)
e) SHALL contain exactly one (or a nullFlavor value) [1..1] text [CONF:785].
f) SHALL contain exactly one [1..1] statusCode, which SHALL be selected from ValueSet
x_ActStatusActiveComplete 2.16.840.1.113883.1.11.19890 STATIC [CONF:786] such that it,
i) SHALL be constrained to either Active or Completed status codes [CONF:786.34].
g) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:787] such
that it,
i) SHALL contain exactly one [1..1] low value to indicate the Start Date/Time and MAY contain
zero or one [0..1] high values to indicate the End Date/Time [CONF:787.50].
h) SHALL contain exactly one (or a nullFlavor value) [1..1] e2e:confidentialityCode, which
SHALL be selected from ValueSet x_BasicConfidentialityKind 2.16.840.1.113883.2.20.3.139 STATIC (CDA R2 Extension) [CONF:788].
i) SHALL contain zero or one if available [0..1] entryRelationship [CONF:789] such that it,
i) SHALL contain exactly one [1..1] Attachment (2.16.840.1.113883.3.1818.10.4.1)
[CONF:789.1].
j) SHALL contain zero or one if available [0..1] entryRelationship [CONF:790] such that it,
i) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:790.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
221 DSTU (Revision 2013)
The following XML example outlines how to use the Alert Observation template:
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.2"/>
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="INFECTIOUS" displayName="Infectious Disease Alert"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>MRSA - Multiple resistant staphylococcus aureus infection carrier</text>
<statusCode code="active"/>
<effectiveTime value="20100111"/>
<e2e:confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.1"/> <!-- Attachment -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="ATTACH" displayName="Attachment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Keywords: MRSA</text>
<effectiveTime value="20100111"/>
<value xsi:type="ST">MRSA Alert</value>
<!-- Attachment Notes not included in this sample-->
<!-- Reviewed Dates not included in this sample-->
<!-- Attachment or Reference -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.9"/> <!--Encapsulated Data -
->
<observationMedia classCode="OBS" moodCode="EVN">
<id extension="127797" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<value xsi:type="ED" mediaType="application/pdf">
<reference value="http://www.anywhere.com/folder1/20120202-Patient2-
Alert1.pdf"/>
</value>
<!--Attachment author not included in this sample -->
</observationMedia>
</entryRelationship>
</observation>
</entryRelationship>
</observation>
</entry>
Figure 62: Alert Observation entry example
6.3 ALLERGY & INTOLERANCE OBSERVATION
[Act: templateId 2.16.840.1.113883.3.1818.10.3.3(open)]
Table 80: Allergy & Intolerance Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Allergies & Intolerances (Reaction List) [with entries] Comment Observation
Lifestage Observation
Reaction Observation
Severity Observation
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
222 DSTU (Revision 2013)
Directly Used by Template(s) Directly Contains Template(s)
Status Changes Audit Event
The Allergies and Intolerances Observation template enables the communication of whether an allergy or
intolerance exists or is thought not to exist.
Allergy/Intollerance Observations are wrapped in a Allergy Problem Act, or "Concern" act, which includes
the status of the observation, the date and time it was documented as well as a persistent Record ID from
the originating system. This Act will contain information about the agent or allergen as well as the
associated reaction.
Allergen and Allergen Group Codes
While the agent believed to be the cause of the allergy or adverse reaction is often implicit in the code
used to represent the associated alert observation (e.g. "allergy to penicillin"), it SHOULD also be asserted
explicitly as an entity. Due the limitations of the underlying CDA information model, these agents are
represented as a manufacturedMaterial entity in the allergy observation – whether or not the agent
is in fact manufactured or naturally occurring. The agent responsible for an allergy or adverse reaction is
not always a manufactured material (for example, food allergies), nor is it necessarily consumed.
The following constraints reflect limitations in the base CDA R2 specification, and should be used to
represent any type of responsible agent.
If the Allergen is a Drug (as identified by the Reaction Type Code), the Allergen Code and Allergen
Group Code SHALL conform to the Drug Identification requirements as outlined in the Medication
Event template.
If the Allergen is not a Drug, then the allergen Code MAY be coded using any recognized coding
system.
If the source system does contain a code for the Allergen from a recognized coding system then the Allergen Code element SHALL be repeated for each recognized code system populated.
The receiving system MAY support receipt of coded Allergens using alternative recognized coding systems.
Allergy Clinical Status Code Comments
Allergies with a status of 'Erroneous' are considered to be inactive, with the added provision that they
should no longer be displayed in the patient's allergy list.
If the status is Refuted then this should be displayed since there may be other data sources that continue
to show the allergy status to be active. If the status field is blank then the reader that sees the status to
be active in another document they are forced to err on the side of caution.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
223 DSTU (Revision 2013)
Reaction List Status History
Independent of communicating the Reaction List, there is a requirement to be able to communicate the
status change history of the Reaction List Record. The ability to communicate the history of the changes
is necessary to show when a status change was made and may have been communicated to an external
system such as a pharmacy. Additionally this information is helpful when communicating to patients
about the reported history of allergies.
Allergies Not Reviewed versus No Allergies
It is important to differentiate between affirmatively stating that a patient has no known allergies versus
either not including allergies in the record (for example an episodic document where the allergies are not
considered relevant to the document); or asserting that allergies were not reviewed and are unknown.
Allergies not reviewed
If the allergies are not reviewed and the sending system does not have any allergy records then a note to
that effect should be included in the section Text as shown below. The Sending System may also send
this information in the encounter notes.
<section>
<code code="008" codeSystem="48765-2 " codeSystemName="LOINC" displayName="Allergies
& Intolerances List"/>
<title> Allergies & Intolerances List </title>
<text>
<paragraph>Allergies not reviewed</paragraph>
</text>
</section>
Figure 63: Example “Allergies not reviewed”
Allergies Reviewed, None Identified
If the allergies are reviewed and none are identified then a note to that effect should be included in the
section Text as shown below. The Sending System MAY also send this information in the encounter
notes.
<section>
<code code="008" codeSystem="48765-2 " codeSystemName="LOINC" displayName="Allergies
& Intolerances List"/>
<title> Allergies & Intolerances List </title>
<text>
<paragraph>Allergies reviewed and none identified</paragraph>
</text>
</section>
Figure 64: Example “Allergies Reviewed & None Identified”
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
224 DSTU (Revision 2013)
If the sending provider has created a record in the Reaction List the following may be sent to indicate a
lack of allergies identified including the date that the lack of allergies is documented.
<entry typeCode=“DRIV”>
<act moodCode="EVN" classCode="ACT">
<id extension="123" root="2.16.840.1.113883.3.1818.10.2.10.1"/>
<code nullFlavor="NA"/>
<!-- Allergen Code -->
<participant typeCode="CSM" contextControlCode="OP">
<participantRole classCode="MANU">
<playingEntityChoice classCode="MMAT" determinerCode="KIND">
<code nullFlavor="OTH" displayName="No known allergies"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"/>
</playingEntityChoice>
</participantRole>
</participant>
<!-- Reported Comment -->
<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<code code="48767-8" codeSystem="TBD" codeSystemName="LOINC"
displayName="Reported Comment"/>
<value xsi:type="ST">Jane Doe, Mother, reports that patient has no known
allergies.</value>
</observation>
</entryRelationship>
<!-- Clinical Status -->
<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<code code="ALLCLINSTS" codeSystem="2.16.840.1.113883.3.1818.10.2.8.1"
codeSystemName="PITO ObservationType" displayName="Allergy Clinical Status Code"/>
<value xsi:type="CD" code="C"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.2" codeSystemName="PITO
AllergyClinicalStatus" displayName="Confirmed"/>
</observation>
</entryRelationship>
<!-- Documented Date -->
<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<code code="DOCDATE" codeSystem="2.16.840.1.113883.3.1818.10.2.8.1"
codeSystemName="PITO ObservationType" displayName="DocumentedDate"/>
<effectiveTime value="20120201"/>
</observation>
</entryRelationship>
</observation>
</entry>
Figure 65: Example “Allergies Reviewed & None Identified – structured data”
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
225 DSTU (Revision 2013)
Allergies not included in document
If the sending provider decides to not include allergies in a document regardless of if they have been
captured in the source system; then the source system should not include an Allergy & Intolerance
Section in the document.
A receiving system processing a document that does not have an Allergies & Intolerances section SHALL
NOT assume that there are no allergies for the patient; only that the Author of the document did not
choose to include this information.
Table 81: Allergy & Intolerance Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
791 @typeCode M:1..1
792 templateId O:0..* II
793 Allergy Problem Act act O:0..*
794 @classCode M:1..1
795 @moodCode M:1..1
796 Record ID id R:1..1 II
798 Allergy/Intolerance Status The status of the Allergy/Intolerance.
statusCode R:1..1 CS
799 Documented Date The date when the allergy or adverse reaction was recorded on the patient chart.
effectiveTime R:1..1 IVL_TS
800 Allergy/Intolerance Observation Details entryRelationship R:1..1
801 @typeCode M:1..1
802 observation O:0..*
803 @classCode M:1..1
804 @moodCode M:1..1
805 Onset Date & Resolved Date The effective date/time of the allergy or intolerance.
effectiveTime R:1..1 IVL_TS
806 Adverse Event Type Code Identifies the Allergen category (Drug, Food & Environment) as well as the category of the reaction (Allergy or Intolerance).
code R:1..1 CD
807 Lifestage at Onset entryRelationship
(Lifestage Observation)
O:0..1
808 Allergen participant R:1..1
809 @typeCode M:1..1
810 @contextControlCode O:1..1
811 Allergen Detail participantRole O:0..*
812 @classCode M:1..1
813 playingEntity O:0..1
814 @classCode M:1..1
815 @determinerCode M:1..1
816 Coded Allergen code R:1..1 CE
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
226 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
817 Free Text Allergen name R:1..1 PN
818 Allergen Group Identification of the group of drugs to which the specific drug identified in the Allergen Code or Allergen Name field belongs (e.g. Penicillin for Drug Amoxicillin). • Required if Reaction Type Code is “DALG”, “DINT” or “DNAINT".
entryRelationship R:1..1
1715 @typeCode M:1..1
1716 observation M:1..1
1646 @classCode M:1..1
1647 @moodCode M:1..1
1648 code M:1..1 CD
1649 Allergen Group Value value M:1..1 CD
819 Reported Comment Information regarding the source and timing of the reported reaction. For example: name of person reporting the allergy, the relationship of the reporter to the patient (e.g. mother) and any other comments regarding reliability of the reporting.
entryRelationship
(Comment Observation)
O:0..1
820 Reaction Coded identification of the specific reaction(s) that is experienced by a patient when exposed to the Allergen (e.g. Hives, anaphylaxis) including the severity of the specific reaction.
entryRelationship
(Reaction Observation)
O:0..1
821 Allergy/Intolerance Severity This indicates the overall severity of a patient's reaction to the Allergen as identified in the Allergen Code & Name fields. • If Severity is unknown then NullFlavor “UNK” SHALL be sent <code nullFlavor=”UNK”/>.
entryRelationship
(Severity Observation)
R:1..1
822 Allergy Clinical Status This indicates the verification status for the allergy (e.g. confirmed, refuted).
entryRelationship R:1..1
823 @typeCode M:1..1
824 observation O:0..*
825 @classCode M:1..1
826 @moodCode M:1..1
827 Clinical Status Observation Code code R:1..1 CD
828 Free Text Clinical Status text R:1..1 ED
829 Coded Clinical Status value R:1..1 CD
830 Alert Device This field describes any type of allergy alert device the patient may be carrying or wearing (e.g. Bracelet, Necklace, Wallet card).
entryRelationship O:0..*
831 @typeCode M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
227 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
832 observation O:0..*
833 @classCode M:1..1
834 @moodCode M:1..1
835 Code Identifying Observation type code R:1..1 CD
836 Free Text Alert Device text O:0..1 ED
837 Coded Alert Device value R:1..1 CD
838 Status History Audit Record This field contains the records from the source system’s audit log regarding the status changes that the Reaction List Record has undergone.
entryRelationship
(Status Changes Audit
Event)
O:0..*
An Allergy & Intolerance Observation (Act) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:791].
2) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:792] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.3"
[CONF:792.12].
3) MAY contain zero or more [0..*] {CDAR2} act [CONF:793].
a) SHALL contain exactly one [1..1] @classCode="ACT" act (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:794].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:795].
c) SHALL contain exactly one (or a nullFlavor value) [1..1] id [CONF:796].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] statusCode, which SHALL be
selected from ValueSet x_ActStatusActiveComplete 2.16.840.1.113883.1.11.19890 STATIC [CONF:798] such that it,
i) SHALL be constrained to either Active or Completed status codes [CONF:798.34].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:799].
f) SHALL contain exactly one (or a nullFlavor value) [1..1] entryRelationship [CONF:800].
i) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:801].
ii) MAY contain zero or more [0..*] {CDAR2} observation [CONF:802].
(1) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:803].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:804].
(3) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:805]
such that it,
(a) SHALL contain exactly one [1..1] low value to indicate the Start Date/Time and MAY
contain zero or one [0..1] high values to indicate the End Date/Time [CONF:805.50].
(4) SHALL contain exactly one (or a nullFlavor value) [1..1] code, which SHOULD be
selected from ValueSet ReactionTypeCode 2.16.840.1.113883.3.3068.10.8.18 DYNAMIC [CONF:806].
(5) MAY contain zero or one [0..1] entryRelationship [CONF:807] such that it,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
228 DSTU (Revision 2013)
(a) SHALL contain exactly one [1..1] Lifestage Observation
(2.16.840.1.113883.3.1818.10.4.12) [CONF:807.1].
(6) SHALL contain exactly one (or a nullFlavor value) [1..1] participant [CONF:808].
(a) SHALL contain exactly one [1..1] @typeCode="CSM" consumable (CodeSystem:
ParticipationType 2.16.840.1.113883.5.90) [CONF:809].
(b) MAY contain zero or one [1..1] {CDAR2} @contextControlCode="OP" overriding
propagating (CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:810].
(c) MAY contain zero or more [0..*] {CDAR2} participantRole [CONF:811].
(i) SHALL contain exactly one [1..1] @classCode="MANU" manufactured product
(CodeSystem: RoleClass 2.16.840.1.113883.5.110) [CONF:812].
(ii) MAY contain zero or one [0..1] {CDAR2} playingEntity [CONF:813].
1. SHALL contain exactly one [1..1] @classCode="MMAT" manufactured
material (CodeSystem: EntityClass 2.16.840.1.113883.5.41) [CONF:814].
2. SHALL contain exactly one [1..1] @determinerCode="KIND" kind
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:815].
3. SHALL contain exactly one (or a nullFlavor value) [1..1] code, which
SHALL be selected from ValueSet AllergenEntityCode 2.16.840.1.113883.3.3068.10.8.9 STATIC [CONF:816].
4. SHALL contain exactly one (or a nullFlavor value) [1..1] name [CONF:817].
(7) SHALL contain exactly one (or a nullFlavor value) [1..1] entryRelationship
[CONF:818].
(a) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1715].
(b) SHALL contain exactly one [1..1] observation [CONF:1716].
(i) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1646].
(ii) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem:
ActMood 2.16.840.1.113883.5.1001) [CONF:1647].
(iii) SHALL contain exactly one [1..1] code="ALRGRP" allergen group observation
(CodeSystem: ActCode 2.16.840.1.113883.5.4) [CONF:1648].
(iv) SHALL contain exactly one [1..1] value, which SHALL be selected from ValueSet
ClinicalDrug 2.16.840.1.113883.2.20.3.29 DYNAMIC [CONF:1649].
(8) MAY contain zero or one [0..1] entryRelationship [CONF:819] such that it,
(a) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:819.1].
(9) MAY contain zero or one [0..1] entryRelationship [CONF:820] such that it,
(a) SHALL contain exactly one [1..1] Reaction Observation
(2.16.840.1.113883.3.1818.10.4.23) [CONF:820.1].
(10) SHALL contain exactly one (or a nullFlavor value) [1..1] entryRelationship
[CONF:821] such that it,
(a) SHALL contain exactly one [1..1] Severity Observation
(2.16.840.1.113883.3.1818.10.4.30) [CONF:821.1].
(11) SHALL contain exactly one (or a nullFlavor value) [1..1] entryRelationship
[CONF:822].
(a) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:823].
(b) MAY contain zero or more [0..*] {CDAR2} observation [CONF:824].
(i) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:825].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
229 DSTU (Revision 2013)
(ii) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem:
ActMood 2.16.840.1.113883.5.1001) [CONF:826].
(iii) SHALL contain exactly one (or a nullFlavor value) [1..1] code="CLINSTAT"
Clinical Status (CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:827].
(iv) SHALL contain exactly one (or a nullFlavor value) [1..1] text [CONF:828].
(v) SHALL contain exactly one (or a nullFlavor value) [1..1] value, which SHALL
be selected from ValueSet AllergyIntoleranceStatusCode 2.16.840.1.113883.2.20.3.211 DYNAMIC [CONF:829].
(12) MAY contain zero or more [0..*] entryRelationship [CONF:830].
(a) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:831].
(b) MAY contain zero or more [0..*] {CDAR2} observation [CONF:832].
(i) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:833].
(ii) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem:
ActMood 2.16.840.1.113883.5.1001) [CONF:834].
(iii) SHALL contain exactly one (or a nullFlavor value) [1..1] code="ALRTDEV"
Alert Device Observation (CodeSystem: ActCode 2.16.840.1.113883.5.4) [CONF:835].
(iv) MAY contain zero or one [0..1] {CDAR2} text [CONF:836].
(v) SHALL contain exactly one (or a nullFlavor value) [1..1] value, which SHALL
be selected from ValueSet AlertDeviceType 2.16.840.1.113883.3.3068.10.8.20 DYNAMIC [CONF:837].
(13) MAY contain zero or more [0..*] entryRelationship [CONF:838] such that each,
(a) SHALL contain exactly one [1..1] Status Changes Audit Event
(2.16.840.1.113883.3.1818.10.4.31) [CONF:838.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
230 DSTU (Revision 2013)
The following XML example outlines how to use the Allergy & Intolerance Observation template:
<!--Peanut allergy coding -->
<entry typeCode=DRIVP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.3"/> <!--Allergy and Intolerance
Observation-->
<act classCode="ACT" moodCode="EVN">
<id extension="123" root="2.16.840.1.113883.3.1818.10.2.10.1"/>
<code nullFlavor="NA"/>
<statusCode code="active"/>
<effectiveTime value="20110214"/>
<entryRelationship typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<code code="FALG" displayName="Food Allergy"
codeSystem="2.16.840.1.113883.5.4" codeSystemName="HL7 ActCode"/>
<effectiveTime> <low value="20111225"/> </effectiveTime>
<participant typeCode="CSM" contextControlCode="OP">
<participantRole classCode="MANU">
<playingEntity classCode="MMAT" determinerCode="INSTANCE">
<code code="256349002" displayName="Peanut containing products"
codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
<name>Peanut allergy</name>
</playingEntity>
</participantRole>
</participant>
<!-- Allergen Group Observation not relevant for this allergy-->
<!-- Lifestage at Onset -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.12"/> <!--Livestage
observation-->
<observation classCode="OBS" moodCode="EVN">
<code code="LIFEOBS" displayName="Lifestage Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="CD" code="133936004" displayName="Adult"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT"/>
</observation>
</entryRelationship>
<!-- Reported Comment Observation -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Hospital discharge report</text>
</observation>
</entryRelationship>
<!-- Reaction -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.23"/> <!-- Reaction
Observation -->
<observation classCode="OBS" moodCode="EVN">
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
231 DSTU (Revision 2013)
<code code="REACTOBS" displayName="Reaction Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Severe reaction to peanuts</text>
<effectiveTime> <low value="20111225"/> </effectiveTime>
<value xsi:type="CD" code="417516000" displayName="Anaphylaxis due to
substance" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
<!-- Reaction Severity -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.30"/> <!-- Severity
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="SEV" displayName="Severity"
codeSystem="2.16.840.1.113883.5.4" codeSystemName="HL7 ActCode" />
<value xsi:type="CD" code="A4" displayName="Severe"
codeSystem="2.16.840.1.113883.5.1063" codeSystemName="HL7 ObservationValue" />
</observation>
</entryRelationship>
<!-- Reaction Comment not included in this sample -->
<!-- Reaction Author not included in this sample -->
<!-- Reaction Informant not included in this sample -->
</observation>
</entryRelationship>
<!-- Allergy Severity -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.30"/> <!-- Severity
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="SEV" displayName="Severity" codeSystem="2.16.840.1.113883.5.4"
codeSystemName="HL7 ActCode" />
<value xsi:type="CD" code="A4" displayName="Severe"
codeSystem="2.16.840.1.113883.5.1063" codeSystemName="HL7 ObservationValue" />
</observation>
</entryRelationship>
<!-- Allergy Clinical Status -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<code code="CLINSTAT" displayName="Allergy Clinical Status"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<text>Confirmed</text>
<value xsi:type="CD" code="C" displayName="Confirmed"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.2" codeSystemName="PITO
AllergyClinicalStatus"/>
</observation>
</entryRelationship>
<!-- Alert Device Code -->
<entryRelationship typeCode="SUBJ">
<observation classCode="OBS" moodCode="EVN">
<code code="ALRTDEV" displayName="Allert Device"
codeSystem="2.16.840.1.113883.5.4" codeSystemName="HL7 ActCode" />
<text>Bracelet</text>
<value xsi:type="CD" code="111046003" displayName="Identification
bracelet, device (physical object) " codeSystem="2.16.840.1.113883.3.1818.10.2.8.3"
codeSystemName="SNOMED-CT"/>
</observation>
</entryRelationship>
<!-- Status Change Audit Event -->
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
232 DSTU (Revision 2013)
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.31"/> <!--Status Change
Audit Event -->
<observation classCode="OBS" moodCode="EVN">
<id extension="123" root="2.16.840.1.113883.3.1818.10.2.10.1"/>
<code code="STSAUDITOBS" displayName="Status Audit Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<text>Allergy report recived from Emergency department confirming
allergy</text>
<effectiveTime value="201101221054"/>
<!-- Status change Author -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Status Change Reason -->
<entryRelationship typeCode="RSON" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> <!-- Reason
Observation -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="REASON" displayName="Reason Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>confirmation received from Hospital</text>
<effectiveTime value="20120201"/>
<value xsi:type="CD" code="10144323" displayName="Patient findings
pneumonia" codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT"/>
<!-- Status Change reason Author -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Status Change Reason Informant -->
<informant typeCode="INF" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.10"/> <!-- Informant
Participation -->
<assignedEntity classCode="ASSIGNED">
<id nullFlavor="NA"/>
<assignedPerson>
<name>Royal X Hospital</name>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
233 DSTU (Revision 2013)
</assignedPerson>
</assignedEntity>
</informant>
</observation>
</entryRelationship>
</observation>
</entryRelationship>
</observation>
</entryRelationship>
</act>
</entry>
<!--Angiotensin antagonist allergy coding -->
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.3"/> <!--Allergy and Intolerance
Observation-->
<act classCode="ACT" moodCode="EVN">
<id extension="123" root="2.16.840.1.113883.3.1818.10.2.10.1"/>
<code nullFlavor="NA"/>
<statusCode code="active"/>
<effectiveTime value="20110214"/>
<entryRelationship typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<code code="DALG" displayName="Drug Allergy"
codeSystem="2.16.840.1.113883.5.4" codeSystemName="HL7 ActCode"/>
<effectiveTime> <low value="20111225"/> </effectiveTime>
<participant typeCode="CSM" contextControlCode="OP">
<participantRole classCode="MANU">
<playingEntity classCode="MMAT" determinerCode="INSTANCE">
<code code="108564000" displayName="Ramipril"
codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
<name>Ramipril</name>
</playingEntity>
</participantRole>
</participant>
<!-- Allergen Group Observation -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<code code="ALLGRP" displayName="Allergen Group Code"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<value xsi:type="CD" code="41549009" displayName="Angiotensin-converting
enzyme inhibitor agent" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED
CT"/>
</observation>
</entryRelationship>
<!-- Lifestage Observation not included in sample -->
<!-- Reported Comment Observation -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Patient</text>
</observation>
</entryRelationship>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
234 DSTU (Revision 2013)
<!-- Allergy Reaction -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.23"/> <!-- Reaction
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="REACTOBS" displayName="Reaction Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<text>Mild nausea</text>
<effectiveTime> <low value="20111225"/> </effectiveTime>
<value xsi:type="CD" code="422587007" displayName="Nausea"
codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
<!-- Reaction Severity -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.30"/> <!-- Severity
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="M" displayName="Severity" codeSystem="2.16.840.1.113883.5.4"
codeSystemName="HL7 ActCode" />
<value xsi:type="CD" code="A2" displayName="Mild Reaction"
codeSystem="2.16.840.1.113883.5.1063" codeSystemName="HL7 ObservationValue" />
</observation>
</entryRelationship>
<!-- Reaction Comment not included in this sample -->
<!-- Reaction Author not included in this sample -->
<!-- Reaction Informant not included in this sample -->
</observation>
</entryRelationship>
<!-- Allergy Severity -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.30"/> <!-- Severity
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="SEV" displayName="Severity" codeSystem="2.16.840.1.113883.5.4"
codeSystemName="HL7 ActCode" />
<value xsi:type="CD" code="A3" displayName="Moderate"
codeSystem="2.16.840.1.113883.5.1063" codeSystemName="HL7 ObservationValue" />
</observation>
</entryRelationship>
<!-- Comment Observation not included in this sample-->
<!-- Allergy Clinical Status -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<code code="CLINSTAT" displayName="Allergy Clinical Status"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<text>Confirmed</text>
<value xsi:type="CD" code="C" displayName="Confirmed"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.2" codeSystemName="PITO
AllergyClinicalStatus"/>
</observation>
</entryRelationship>
<!-- Alert Device Code not included in this sample -->
<!-- Status Change Audit Event not included in this sample -->
</observation>
</entryRelationship>
</act>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
235 DSTU (Revision 2013)
</entry>
Figure 66: Allergy & Intolerance Observation entry example
6.4 APPOINTMENT OBSERVATION
[Encounter: templateId 2.16.840.1.113883.3.1818.10.3.4(open)]
Table 82: Appointment Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Appointments & Scheduling [with entries] Author Participation
Comment Observation
Provider Participation
Reason Observation
The Appointment Observation template is used to exchange appointments that the patient may have.
The Appointment Observation template includes the status of the appointment (active or cancelled) as
well as relevant information about the appointment (reason, notes, location, and provider). Other relevant
providers involved in the appointment may also be communicated.
Table 83: Appointment Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
839 @typeCode M:1..1
840 @contextConductionInd M:1..1
841 templateId M:1..1 II
842 encounter R:1..1
843 @classCode M:1..1
844 @moodCode M:1..1
846 Appointment Status Active, Complete, Cancelled Status of the appointment.
statusCode R:0..1 CS
845 Appointment Date, Start Time and Length The start time of the appointment and the actual/planned duration.
effectiveTime M:1..1 IVL_TS
861 Appointment Creator Name & Time Name of the staff member that created the appointment including the time the appointment was created.
author (Author
Participation)
O:0..*
849 Encounter Point of Service Location Location of the encounter.
participant O:0..*
850 @typeCode M:1..1
851 @contextControlCode O:1..1
852 participantRole O:0..*
853 @classCode M:1..1
854 Location Identifier Identifier of the point of service location for
id O:0..* II
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
236 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
the encounter.
855 Location Address The Point of Service address for the encounter.
addr O:0..* AD
856 Encounter Provider ID and Name of provider responsible for the encounter.
participant (Provider
Participation)
R:0..1
857 Referral Practitioner Name and Identifier of the physician who referred this patient.
participant (Provider
Participation)
R:0..1
858 Additional Provider Name and ID of medical resident or student working at the office/clinic.
participant (Provider
Participation)
R:0..1
859 Delegated Provider Name and ID of the physician who is 'standing-in' for the patient's regular physician.
participant (Provider
Participation)
R:0..1
847 Appointment Reason Reason for the appointment, e.g. physical, follow-up visit, consultation, new patient, rebooked appointment, prescription renewal.
entryRelationship
(Reason Observation)
O:0..*
848 Appointment Notes Any pertinent information about this patient and/or appointment, e.g. reason for visit, test results requested, pre-appointment tasks, current treatment regime, prescribed medication.
entryRelationship
(Comment Observation)
O:0..*
860 Cancellation Note & Date If the appointment is cancelled, the reason for the cancellation including the date of the cancellation.
entryRelationship
(Comment Observation)
O:0..*
An Appointment Observation (Encounter) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:839].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:840].
3) SHALL contain exactly one [1..1] templateId [CONF:841] such that it,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.4"
[CONF:841.12].
4) SHALL contain exactly one (or a nullFlavor value) [1..1] encounter [CONF:842].
a) SHALL contain exactly one [1..1] @classCode="ENC" encounter (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:843].
b) SHALL contain exactly one [1..1] @moodCode="APT" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:844].
c) SHALL contain zero or one if available [0..1] statusCode, which SHALL be selected from
ValueSet ActStatus 2.16.840.1.113883.1.11.159331 STATIC [CONF:846].
d) SHALL contain exactly one [1..1] effectiveTime [CONF:845].
e) MAY contain zero or more [0..*] {CDAR2} author [CONF:861] such that each,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
237 DSTU (Revision 2013)
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:861.1].
f) MAY contain zero or more [0..*] {CDAR2} participant [CONF:849].
i) SHALL contain exactly one [1..1] @typeCode="LOC" location (CodeSystem:
ParticipationType 2.16.840.1.113883.5.90) [CONF:850].
ii) MAY contain zero or one [1..1] {CDAR2} @contextControlCode="OP" overriding
propagating (CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:851].
iii) MAY contain zero or more [0..*] {CDAR2} participantRole [CONF:852].
(1) SHALL contain exactly one [1..1] @classCode="SDLOC" service delivery location
(CodeSystem: RoleClass 2.16.840.1.113883.5.110) [CONF:853].
(2) MAY contain zero or more [0..*] {CDAR2} id [CONF:854].
iv) MAY contain zero or more [0..*] {CDAR2} addr [CONF:855] such that each,
(1) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data type
constraint template (2.16.840.1.113883.3.3068.10.5.1) [CONF:855.5].
g) SHALL contain zero or one if available [0..1] participant [CONF:856] such that it,
i) SHALL contain exactly one [1..1] Provider Participation
(2.16.840.1.113883.3.1818.10.4.21) [CONF:856.1].
h) SHALL contain zero or one if available [0..1] participant [CONF:857] such that it,
i) SHALL contain exactly one [1..1] Provider Participation
(2.16.840.1.113883.3.1818.10.4.21) [CONF:857.1].
i) SHALL contain zero or one if available [0..1] participant [CONF:858] such that it,
i) SHALL contain exactly one [1..1] Provider Participation
(2.16.840.1.113883.3.1818.10.4.21) [CONF:858.1].
j) SHALL contain zero or one if available [0..1] participant [CONF:859] such that it,
i) SHALL contain exactly one [1..1] Provider Participation
(2.16.840.1.113883.3.1818.10.4.21) [CONF:859.1].
k) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:847] such that each,
i) SHALL contain exactly one [1..1] Reason Observation
(2.16.840.1.113883.3.1818.10.4.24) [CONF:847.1].
l) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:848] such that each,
i) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:848.1].
m) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:860] such that each,
i) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:860.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
238 DSTU (Revision 2013)
The following XML example outlines how to use the Appointment Observation template:
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.4"/> <!-- Appointment
Observation -->
<encounter classCode="ENC" moodCode="PRP">
<code nullFlavor="NA"/>
<statusCode code="Active"/>
<effectiveTime>
<low value="201402141230"/>
<high value="201402141300"/>
</effectiveTime>
<!-- Appointment Location -->
<participant typeCode="LOC" contextControlCode="OP">
<participantRole classCode="SDLOC">
<addr>
<streetAddressLine>4444 Healthcare Drive</streetAddressLine>
<city>Vancouver</city>
<state>BC</state>
<postalCode>A1B 2C3</postalCode>
<country>CA</country>
</addr>
</participantRole>
</participant>
<!-- Primary Performer -->
<participant typeCode="PPRF">
<participantRole>
<id extension="23377" root="1.2.3.4"/>
<addr></addr>
<telecom value="tel:5555552003" use="WP"/>
<playingEntity classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</playingEntity>
</participantRole>
</participant>
<!-- Referred by Provider -->
<participant typeCode="REFB">
<participantRole>
<id extension="24975" root="1.2.3.4"/>
<addr></addr>
<telecom value="tel:5555552003" use="WP"/>
<playingEntity classCode="PSN" determinerCode="INSTANCE">
<name>Dr. A. de Wit</name>
</playingEntity>
</participantRole>
</participant>
<!-- Information Recipient Provider -->
<participant typeCode="IRCP">
<participantRole>
<addr></addr>
<telecom value="tel:5555552003" use="WP"/>
<playingEntity classCode="PSN" determinerCode="INSTANCE">
<name>J. Doe</name>
<desc>Social Services case manager authorized to receive healthcare
information to support patient's integrated care.</desc>
</playingEntity>
</participantRole>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
239 DSTU (Revision 2013)
</participant>
<!-- Encounter Reason -->
<entryRelationship typeCode="SUBJ">
<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> <!-- Reason Observation
-->
<observation classCode="OBS" moodCode="EVN">
<id extension="127797" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<code code="REASON" displayName="Reason Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text> Annual Follow-up; Diabetes control and med renewal;</text>
<effectiveTime value="20140110"/>
<value xsi:type="CD" code="170744004" displayName="Follow-up diabetic
assessment" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
<!-- Encounter Reason Record Link -->
<entryRelationship typeCode="SUBJ">
<templateId root="2.16.840.1.113883.3.1818.10.4.38"/> <!-- Record ID Link --
>
<observation classCode="OBS" moodCode="EVN">
<id extension="12779999" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<code code="RECLINK" displayName="Record Link Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
</observation>
</entryRelationship>
<!-- Reason Author not included in sample -->
<!-- Reason Informant not included in sample -->
</observation>
</entryRelationship>
<!-- Appointment Notes Comment Observation -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment Observation
-->
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Social Services case manager, J. Doe, to provide support in medication
administration at patient's home. Include in all Diabetes care planning.</text>
</observation>
</entryRelationship>
</encounter>
</entry>
Figure 67: Appointment Observation entry example
6.5 BILLING ATTACHMENT
[Observation: templateId 2.16.840.1.113883.3.1818.10.3.5(open)]
Table 84: Billing Attachment Template Context
Directly Used by Template(s) Directly Contains Template(s)
Billing [with entries] N/A
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
240 DSTU (Revision 2013)
The Billing Attachment template is used to attach a BC Medical Services Plan billing file to the patient
record.
Implementers should note that this approach for communication of billing information is intended as a
stop gap measure at this time. Future versions of this specification may provide for the ability to transfer
billing information in a more granular fashion to support the conversion use case.
Table 85: Billing Attachment Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
862 @typeCode M:1..1
863 @contextConductionInd M:1..1
864 templateId O:0..* II
865 observationMedia M:1..1
866 @classCode M:1..1
867 @moodCode M:1..1
868 Billing File Identifier The identifier of the MSP Billing Extract file.
id M:1..1 II
869 Billing File Content The attachment content itself or external reference to the content.
value M:1..1 ED
A Billing Attachment (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:862].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:863].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:864] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.5"
[CONF:864.12].
4) SHALL contain exactly one [1..1] observationMedia [CONF:865].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:866].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:867].
c) SHALL contain exactly one [1..1] id [CONF:868].
d) SHALL contain exactly one [1..1] value [CONF:869].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
241 DSTU (Revision 2013)
The following XML example outlines how to use the Billing Attachment template:
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.5"/> <!-- Billing Attachments --
>
<observationMedia classCode="OBS" moodCode="EVN">
<id extension="127797" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<value xsi:type="ED" mediaType="application/pdf">
<reference value="http://www.anywhere.com/folder1/20120202-Patient1-
claim1.pdf"/>
</value>
</observationMedia>
</entry>
Figure 68: Billing Attachment entry example
6.6 CARE HISTORY EVENT
[Procedure: templateId 2.16.840.1.113883.3.1818.10.3.6(open)]
Table 86: Care History Event Template Context
Directly Used by Template(s) Directly Contains Template(s)
Investigative Procedure History [with entries] Comment Observation
Surgical Procedure History [with entries] Outcome Observation
Treatment History [with entries] Qualifier Observation
Reason Observation
Secondary Code (Unbound)
The Care History template is used to exchange history of care or interventions that have been performed
on the patient. The term “Intervention” is used in the Care History section to indicate “Treatment”,
“Procedure”, “Investigation” or other type of act that is being communicated.
Table 87: Care History Event Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
870 @typeCode M:1..1
871 @contextConductionInd M:1..1
872 templateId O:0..* II
873 procedure O:0..*
874 @classCode M:1..1
875 @moodCode M:1..1
876 Record ID The internal identifier of the procedure record.
id M:1..1 II
877 Intervention Code/Name The code associated with the Intervention including the coding system used and the display name associated with the code by the coding system.
code R:1..* CD
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
242 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
878 Intervention Name The name or short description for the Intervention. If the Intervention Code is NullFlavor, this element SHALL contain a Name or Short Description of the Intervention as entered by the provider.
text R:1..* ED
879 Intervention Status The status of the Intervention.
statusCode R:1..1 CS
880 Intervention Datetime/End Datetime The start date/time (and end date/time, if available) that the Intervention occurred.
effectiveTime R:1..1 IVL_TS
881 Secondary Code If the source system does contain a code for the Intervention from any other recognized coding systems then the Intervention Code element SHALL be repeated for each recognized code system populated.
entryRelationship
(Secondary Code
(Unbound))
R:0..*
882 Intervention Reason The Reason or indication for performing the Intervention.
entryRelationship
(Reason Observation)
R:0..1
883 Intervention Qualifier Qualifiers relevant to the Intervention such as laterality, approach, method, meta data, references etc. Qualifiers are communicated using the Observation structure allowing for free text or coded qualifiers as well as signatures.
entryRelationship
(Qualifier Observation)
R:0..*
884 Intervention Comment Comments or supporting information relevant to the Intervention that is not already included in the other data elements. Comments are communicated using the Observation structure allowing for free text or coded comments as well as signatures.
entryRelationship
(Comment Observation)
R:0..*
885 Intervention Outcome / Results The results or observations from the Intervention. Results are communicated using the Observation structure allowing them to be links (to attachments or result records), free text or coded.
entryRelationship
(Outcome Observation)
O:0..*
886 Follow-up Encounter Procedure Follow-up includes any follow-up information following a procedure including any encounters (with date and location), comments, and instructions.
entryRelationship R:0..1
887 @typeCode M:1..1
888 encounter M:1..1
889 @classCode M:1..1
890 @moodCode M:1..1
891 Follow-up Date The date/time by which follow up diagnostic
effectiveTime R:1..1 IVL_TS
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
243 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
services are expected to have been provided.
892 Follow-up Encounter Comments entryRelationship R:0..1
893 @typeCode M:1..1
894 observation O:0..*
895 @classCode M:1..1
896 @moodCode M:1..1
897 Code identifying Observation type code M:1..1 CD
898 Follow-up Comments Comments or instructions for follow-up (e.g. reason for follow-up, follow-up in 6 months to check pacemaker).
text M:1..1 ED
A Care History Event (Procedure) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:870].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:871].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:872] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.6"
[CONF:872.12].
4) MAY contain zero or more [0..*] {CDAR2} procedure [CONF:873].
a) SHALL contain exactly one [1..1] @classCode="PROC" procedure (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:874].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:875].
c) SHALL contain exactly one [1..1] id [CONF:876].
d) SHALL contain one or more (or a nullFlavor value) [1..*] code, which SHOULD be selected from
ValueSet Procedure 2.16.840.1.113883.3.3068.10.8.11 DYNAMIC [CONF:877].
e) SHALL contain one or more (or a nullFlavor value) [1..*] text [CONF:878].
f) SHALL contain exactly one (or a nullFlavor value) [1..1] statusCode, which SHALL be
selected from ValueSet x_ActStatusActiveComplete 2.16.840.1.113883.1.11.19890 STATIC [CONF:879] such that it,
i) SHALL be constrained to either Active or Completed status codes [CONF:879.34].
g) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:880] such
that it,
i) MAY be a partial date conforming to the TS data type constraints [CONF:880.62].
h) SHALL contain zero or more if available [0..*] entryRelationship [CONF:881] such that each,
i) SHALL contain exactly one [1..1] Secondary Code (Unbound)
(2.16.840.1.113883.3.1818.10.4.29) [CONF:881.1].
i) SHALL contain zero or one if available [0..1] entryRelationship [CONF:882] such that it,
i) SHALL contain exactly one [1..1] Reason Observation
(2.16.840.1.113883.3.1818.10.4.24) [CONF:882.1].
j) SHALL contain zero or more if available [0..*] entryRelationship [CONF:883] such that each,
i) SHALL contain exactly one [1..1] Qualifier Observation
(2.16.840.1.113883.3.1818.10.4.22) [CONF:883.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
244 DSTU (Revision 2013)
k) SHALL contain zero or more if available [0..*] entryRelationship [CONF:884] such that each,
i) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:884.1].
l) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:885] such that each,
i) SHALL contain exactly one [1..1] Outcome Observation
(2.16.840.1.113883.3.1818.10.4.18) [CONF:885.1].
m) SHALL contain zero or one if available [0..1] entryRelationship [CONF:886].
i) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:887].
ii) SHALL contain exactly one [1..1] encounter [CONF:888].
(1) SHALL contain exactly one [1..1] @classCode="ENC" encounter (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:889].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:890].
(3) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:891].
(4) SHALL contain zero or one if available [0..1] entryRelationship [CONF:892].
(a) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:893].
(b) MAY contain zero or more [0..*] {CDAR2} observation [CONF:894].
(i) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:895].
(ii) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem:
ActMood 2.16.840.1.113883.5.1001) [CONF:896].
(iii) SHALL contain exactly one [1..1] code="NXTENCREAS" Next Encounter Reason
(CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:897].
(iv) SHALL contain exactly one [1..1] text [CONF:898].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
245 DSTU (Revision 2013)
The following XML example outlines how to use the Care History Event template:
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.6"/> <!-- Care History Event -->
<procedure classCode="PROC" moodCode="EVN">
<id extension="123669" root="2.16.840.1.113883.3.1818.10.2.10.31"/>
<code code="8652-0" displayName="Hospital Discharge History"
codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
<text>Hostpital Admission and Discharge </text>
<statusCode code="complete"/>
<effectiveTime>
<low value="20130213"/>
<high value="20130223"/>
</effectiveTime>
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.29"/> <!-- Secondary Code
(unbound) -->
<observation classCode="OBS" moodCode="EVN">
<code code="SECCODE" displayName="Secondary Code Unbound"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="CD" code="32485007" displayName="Hospital Admission"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT"/>
</observation>
</entryRelationship>
<!-- Reason Observation-->
<entryRelationship typeCode="RSON" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> <!-- Reason Observation-
->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="REASON" displayName="Reason Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Subendocardial myocardial infarction/acute coronary syndrome</text>
<effectiveTime value="20130213"/>
<value xsi:type="CD" code="22298006" displayName="Myocardial infarction"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT"/>
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20130213"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. VG Internist</name>
</assignedPerson>
</assignedAuthor>
</author>
<informant typeCode="INF" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.10"/> <!-- Informant
Participation -->
<assignedEntity classCode="ASSIGNED">
<id nullFlavor="NA"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Ms. D. Everywoman</name>
</assignedPerson>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
246 DSTU (Revision 2013)
</assignedEntity>
</informant>
</observation>
</entryRelationship>
<!-- Qualifier -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.22"/> <!-- Qualifier
Observation -->
<observation classCode="OBS" moodCode="EVN">
<id extension="123669" root="2.16.840.1.113883.3.1818.10.2.10.31"/>
<code code="QUALOBS" displayName="Qualifier Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>THIS DOCUMENT HAS BEEN DICTATED BUT NOT READ</text>
<effectiveTime value="20130223"/>
<value xsi:type="CD" code="TBD" codeSystem="TBD" codeSystemName="TBD"
displayName="Qualifier Observation code"/>
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20130223"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. VG Internist</name>
</assignedPerson>
</assignedAuthor>
</author>
</observation>
</entryRelationship>
<!-- Intervention Comment -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment Observation
-->
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="ST">Admission to Community hospital for chest pain and
transfer to tertiary care facility for angiogram</value>
</observation>
</entryRelationship>
<!-- Outcome -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.18"/> <!-- Outcome Observation
-->
<observation classCode="OBS" moodCode="EVN">
<id extension="123669" root="2.16.840.1.113883.3.1818.10.2.10.31"/>
<code code="OUTCOBS" displayName="Outcome Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>This 66-year-old-lady was admitted through the hospital emergency
department after having had spells of heaviness in the chest and arm tingling.
This was initially not associated with any ECG change, but with a troponin
rise of 1 increasing to 2.
During the time of the hospitalization, she was treated with nitrates, low
molecular weight heparin, Clopidogrel, and low dose beta blockade.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
247 DSTU (Revision 2013)
Despite this, she had repeated spells of chest discomfort and wound up being
placed on higher dose of beta blockade, transdermal nitrates.
She developed inferior wall asymmetric T-wave inversion and did have
transient ST segment depression with pain.
Her case was discussed with Dr. Eric Fretz, and based on this discussion we
did institute integrilin drip and Dr. Fretz made
arrangements for transfer to the Royal Jubilee Hospital CCU for expediting
angiography on the 13th of February. </text>
<effectiveTime value="20100127"/>
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20130223"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. VG Internist</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Outcome Attachment or Reference -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.1"/> <!-- Attachment -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="ATTACH" displayName="Attachment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<text>Keywords: Hospital Discharge</text>
<effectiveTime value="20130223"/>
<value xsi:type="ST">Hospital Discharge Summary</value>
<!-- Attachment Notes not included in this sample-->
<!-- Reviewed Dates not included in this sample-->
<!-- Attachment or Reference -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.9"/> <!-- Encapsulated
Data -->
<observationMedia classCode="OBS" moodCode="EVN">
<id extension="127797" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<value mediaType="application/pdf">
<reference value="http://www.anywhere.com/folder1/20120202-Patient1-
CCD.pdf"/>
</value>
<!-- Attachment author not included in this sample -->
</observationMedia>
</entryRelationship>
</observation>
</entryRelationship>
</observation>
</entryRelationship>
<!-- Follow-Up Encounter -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<encounter classCode="ENC" moodCode="APT">
<effectiveTime value="20130410"/>
<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
248 DSTU (Revision 2013)
<code code="NXTENCREAS" displayName="Next Encounter Reason"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<text>Follow-up Encounter comments or instructions (e.g. reason for follow-
up).</text>
</observation>
</entryRelationship>
</encounter>
</entryRelationship>
</procedure>
</entry>
Figure 69: Care History Event entry example
6.7 CLINICALLY MEASURED OBSERVATIONS ORGANIZER
[Organizer: templateId 2.16.840.1.113883.3.1818.10.3.7(open)]
Table 88: Clinically Measured Observations Organizer Template Context
Directly Used by Template(s) Directly Contains Template(s)
Clinical Measured Observations [with entries] Author Participation
Informant Participation
The Clinically Measured Observations Organizer template is used to group clinical observations that the
provider may have documented regarding the patient. This organizer template enables the grouping of
the observations based on a record identifier, a code indicating the type of observation (e.g. vital signs),
a status, an author and an informant. Individual observations are grouped within the Organizer
element.
Table 89: Clinically Measured Observations Organizer Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1130 @typeCode M:1..1
1131 @contextConductionInd M:1..1
1132 templateId R:1..1 II
1133 organizer O:0..*
1134 @classCode M:1..1
1135 @moodCode M:1..1
1136 Organizer Id Unique and persistent identifier for the group of observations.
id R:0..1 II
1137 Organizer Code Code identifying the group of observations being reported.
code R:1..1 CD
1138 Organizer Status The overall status of the group of observations. Active shall be sent to indicate non-Final status, while Complete is used to indicate either a Final or Corrected group of
statusCode R:1..1 CS
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
249 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
observations.
1139 Observation Author The author of the observation. If the author is unknown or unavailable this element MAY contain a NullFlavor.
author (Author
Participation)
R:0..1
1140 Observation Informant The informant of the observation.
informant (Informant
Participation)
O:0..*
1141 Component Observation component R:1..*
1142 @typeCode M:1..1
1143 @contextConductionInd M:1..1
1144 observation O:0..*
1145 @classCode M:1..1
1146 @moodCode M:1..1
1147 Individual Observation Identifier Unique and persistent identifier for the observation record.
id R:1..1 II
1148 Observation Code Code identifying the individual observation being communicated.
code R:1..1 CD
1149 Observation Name The title, name or short description of what the observation is when it is not coded. For example, “Additional clinical notations”. This is Required if the Observation Code is not populated or not drawn from the PITO recognized codes.
text R:0..1 ED
1150 Observation Date/Time Date (and optional time) that the observation made or recorded.
effectiveTime R:0..1 IVL_TS
1151 Observation Value The observation value. This element’s structure will depend on the type of observation as identified by the Observation Code or Observation Title.
value R:1..* ANY
1152 Interpretation Code When appropriate, the code indicating the interpretation of the results; also known as the Abnormal flag.
interpretationCode O:0..* CE
1153 Method Code When appropriate, the method by which the observation was made.
methodCode O:0..* CE
A Clinically Measured Observations Organizer (Organizer) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1130].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1131].
3) SHALL contain exactly one (or a nullFlavor value) [1..1] templateId [CONF:1132] such that it,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.7"
[CONF:1132.12].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
250 DSTU (Revision 2013)
4) MAY contain zero or more [0..*] {CDAR2} organizer [CONF:1133].
a) SHALL contain exactly one [1..1] @classCode="CLUSTER" cluster (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1134].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1135].
c) SHALL contain zero or one if available [0..1] id [CONF:1136].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] code [CONF:1137].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] statusCode, which SHALL be
selected from ValueSet x_ActStatusActiveComplete 2.16.840.1.113883.1.11.19890 STATIC [CONF:1138].
f) SHALL contain zero or one if available [0..1] author [CONF:1139] such that it,
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1139.1].
g) MAY contain zero or more [0..*] {CDAR2} informant [CONF:1140] such that each,
i) SHALL contain exactly one [1..1] Informant Participation
(2.16.840.1.113883.3.1818.10.4.10) [CONF:1140.1].
h) SHALL contain one or more (or a nullFlavor value) [1..*] component [CONF:1141].
i) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1142].
ii) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1143].
iii) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1144].
(1) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1145].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1146].
(3) SHALL contain exactly one (or a nullFlavor value) [1..1] id [CONF:1147].
(4) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} code, which SHALL be
selected from ValueSet Clinically Measured Observations Codes 2.16.840.1.113883.3.1818.10.8.5 STATIC [CONF:1148].
(5) SHALL contain zero or one if available [0..1] text [CONF:1149].
(6) SHALL contain zero or one if available [0..1] effectiveTime [CONF:1150] such that it,
(a) MAY be a partial date conforming to the TS data type constraints [CONF:1150.62].
(7) SHALL contain one or more (or a nullFlavor value) [1..*] value [CONF:1151].
(8) MAY contain zero or more [0..*] {CDAR2} interpretationCode, which SHALL be
selected from ValueSet ObservationInterpretation 2.16.840.1.113883.2.20.3.78 STATIC [CONF:1152].
(9) MAY contain zero or more [0..*] {CDAR2} methodCode, which SHOULD be selected from
ValueSet ObservationMethod 2.16.840.1.113883.1.11.14079 DYNAMIC [CONF:1153].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
251 DSTU (Revision 2013)
The following XML example outlines how to use the Clinically Measured Observations Organizer
template:
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.7"/> <!-- Clinically Measured
Observations Organizer -->
<organizer classCode="CLUSTER" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="MEAOBSORG" displayName="Measured Observations Organizer"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<statusCode code="active"/>
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author Participation
-->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<informant typeCode="INF" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.10"/> <!-- Informant
Participation -->
<assignedEntity classCode="ASSIGNED">
<id nullFlavor="NA"/>
<assignedPerson>
<name>Royal X Hospital</name>
</assignedPerson>
</assignedEntity>
</informant>
<component typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<id extension="12367" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="8480-6" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Systolic Blood Pressure"/>
<effectiveTime value="20120113"/>
<value xsi:type="PQ" value="124" unit="mm[Hg]"/>
<interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"
codeSystemName="ObservationInterpretation" displayName="Normal"/>
</observation>
</component>
<component typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<id extension="12368" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="8462-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Diastolic Blood Pressure"/>
<effectiveTime value="20120113"/>
<value xsi:type="PQ" value="64" unit="mm[Hg]"/>
<interpretationCode code="N" codeSystem="2.16.840.1.113883.5.83"
codeSystemName="ObservationInterpretation" displayName="Normal"/>
</observation>
</component>
<component typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
252 DSTU (Revision 2013)
<code code="8302-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Height"/>
<effectiveTime value="20120113"/>
<value xsi:type="PQ" value="190" unit="cm"/>
</observation>
</component>
<component typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<code code="3141-9" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Weight"/>
<effectiveTime value="20120113"/>
<value xsi:type="PQ" value="48" unit="kg"/>
</observation>
</component>
<component typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<code code="56115-9" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="Waist Circumference by NCFS"/>
<text>Waist circumference</text>
<effectiveTime value="20120113"/>
<value xsi:type="PQ" value="120" unit="cm"/>
<methodCode code="NCFS" codeSystem="2.16.840.1.113883.5.84"
displayName="National Council of Forensic Scientists standardized methods"/>
</observation>
</component>
<!-- Note: All measurments from the <text> above have not been included in the
example -->
</organizer>
</entry>
Figure 70: Clinically Measured Observations Organizer entry example
6.8 DEVELOPMENTAL OBSERVATIONS ORGANIZER
[Organizer: templateId 2.16.840.1.113883.3.1818.10.4.6(open)]
Table 90: Developmental Observations Organizer Template Context
Directly Used by Template(s) Directly Contains Template(s)
Developmental Observations [with entries] Author Participation
Informant Participation
The Developmental Observations Organizer template is used to group developmental observations that
the provider may have documented on the patient. This organizer template enables the grouping of the
observations based on a record identifier, a code indicating the type of observations (e.g. growth chart), a
status, an author and an informant. Individual observations are grouped within the Organizer
element.
Table 91: Developmental Observations Organizer Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1154 @typeCode M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
253 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1155 @contextConductionInd M:1..1
1156 templateId R:1..1 II
1157 organizer O:0..*
1158 @classCode M:1..1
1159 @moodCode M:1..1
1160 Organizer Id Unique and persistent identifier for the group of observations.
id R:0..1 II
1161 Organizer Code Code identifying the group of observations being reported.
code R:1..1 CD
1162 Organizer Status The overall status of the group of observations. Active shall be sent to indicate non-Final status, while Complete is used to indicate either a Final or Corrected group of observations.
statusCode R:1..1 CS
1163 Observation Author The author of the observation. If the author is unknown or unavailable this element MAY contain a NullFlavor.
author (Author
Participation)
R:0..1
1164 Observation Informant The informant of the observation.
informant (Informant
Participation)
O:0..*
1165 Component Observation component R:1..*
1166 @typeCode M:1..1
1167 @contextConductionInd M:1..1
1168 observation O:0..*
1169 @classCode M:1..1
1170 @moodCode M:1..1
1171 Individual Observation Identifier Unique and persistent identifier for the observation record.
id R:1..1 II
1172 Observation Code Code identifying the individual observation being communicated.
code R:1..1 CD
1173 Observation Name The title, name or short description of what the observation is when it is not coded. For example, “Additional clinical notations”. This is Required if the Observation Code is not populated or not drawn from the PITO recognized codes.
text R:0..1 ED
1174 Observation Date/Time Date (and optional time) that the observation made or recorded.
effectiveTime R:0..1 IVL_TS
1175 Observation Value The observation value. This element’s structure will depend on the type of observation as identified by the Observation Code or Observation Title.
value R:1..* ANY
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
254 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1176 Interpretation Code When appropriate, the code indicating the interpretation of the results; also known as the Abnormal flag.
interpretationCode O:0..* CE
1177 Method Code When appropriate, the method by which the observation was made.
methodCode O:0..* CE
A Developmental Observations Organizer (Organizer) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1154].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1155].
3) SHALL contain exactly one (or a nullFlavor value) [1..1] templateId [CONF:1156] such that it,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.6"
[CONF:1156.12].
4) MAY contain zero or more [0..*] {CDAR2} organizer [CONF:1157].
a) SHALL contain exactly one [1..1] @classCode="CLUSTER" cluster (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1158].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1159].
c) SHALL contain zero or one if available [0..1] id [CONF:1160].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] code [CONF:1161].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] statusCode, which SHALL be
selected from ValueSet x_ActStatusActiveComplete 2.16.840.1.113883.1.11.19890 STATIC [CONF:1162].
f) SHALL contain zero or one if available [0..1] author [CONF:1163] such that it,
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1163.1].
g) MAY contain zero or more [0..*] {CDAR2} informant [CONF:1164] such that each,
i) SHALL contain exactly one [1..1] Informant Participation
(2.16.840.1.113883.3.1818.10.4.10) [CONF:1164.1].
h) SHALL contain one or more (or a nullFlavor value) [1..*] component [CONF:1165].
i) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1166].
ii) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1167].
iii) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1168].
(1) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1169].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1170].
(3) SHALL contain exactly one (or a nullFlavor value) [1..1] id [CONF:1171].
(4) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} code, which SHALL be
selected from ValueSet Developmental Observations Codes 2.16.840.1.113883.3.1818.10.8.6 STATIC [CONF:1172].
(5) SHALL contain zero or one if available [0..1] text [CONF:1173].
(6) SHALL contain zero or one if available [0..1] effectiveTime [CONF:1174] such that it,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
255 DSTU (Revision 2013)
(a) MAY be a partial date conforming to the TS data type constraints [CONF:1174.62].
(7) SHALL contain one or more (or a nullFlavor value) [1..*] value [CONF:1175].
(8) MAY contain zero or more [0..*] {CDAR2} interpretationCode, which SHALL be
selected from ValueSet ObservationInterpretation 2.16.840.1.113883.2.20.3.78 STATIC [CONF:1176].
(9) MAY contain zero or more [0..*] {CDAR2} methodCode, which SHOULD be selected from
ValueSet ObservationMethod 2.16.840.1.113883.1.11.14079 DYNAMIC [CONF:1177].
The following XML example outlines how to use the Developmental Observations Organizer template:
*** NO EXAMPLE ASSIGNED ***
Figure 71: Developmental Observations Organizer entry example
6.9 DEVICE OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.3.8(open)]
Table 92: Device Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Devices [with entries] Author Participation
Informant Participation
The Device Observation template describes the devices in use by a patient. Devices may be coded using
the code element, or may be identified by a free text title using the text element. The author of the
device observation MAY be tracked along with an informant if relevant.
Table 93: Device Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
899 @typeCode M:1..1
900 @contextConductionInd M:1..1
901 templateId O:0..* II
902 observation M:1..1
903 @classCode M:1..1
904 @moodCode M:1..1
905 Record ID id M:1..1 II
906 Device Observation Code code R:1..1 CD
907 Device Title The title, name or short description of the device if it is not coded. For example, “Crutches”.
text R:1..1 ED
908 Device Effective Time The effective date/time that the patient has the device.
effectiveTime R:1..1 IVL_TS
909 Device Author The author of the device record.
author (Author
Participation)
R:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
256 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
910 Device Informant the person who provided the information that the pateint is using the device.
informant (Informant
Participation)
R:0..1
A Device Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:899].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:900].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:901] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.8"
[CONF:901.12].
4) SHALL contain exactly one [1..1] observation [CONF:902].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:903].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:904].
c) SHALL contain exactly one [1..1] id [CONF:905].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} code="DEVOBS" Device
(CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:906].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] text [CONF:907].
f) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:908] such
that it,
i) SHALL contain exactly one [1..1] low value to indicate the Start Date/Time and MAY contain
zero or one [0..1] high values to indicate the End Date/Time [CONF:908.50].
ii) MAY be a partial date conforming to the TS data type constraints [CONF:908.62].
g) SHALL contain exactly one (or a nullFlavor value) [1..1] author [CONF:909] such that it,
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:909.1].
h) SHALL contain zero or one if available [0..1] informant [CONF:910] such that it,
i) SHALL contain exactly one [1..1] Informant Participation
(2.16.840.1.113883.3.1818.10.4.10) [CONF:910.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
257 DSTU (Revision 2013)
The following XML example outlines how to use the Device Observation template:
<!-- Hip Replacement Entry -->
<entry typeCode=DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.8"/> <!-- Device Observation -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="DEVOBS" displayName="Device Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Total hip replacement prosthesis was implanted in 1998</text>
<statusCode code="completed"/>
<effectiveTime value="1998"/>
<value xsi:type="CD" code="304120007" displayName="Total hip replacement
prosthesis (physical object) " codeSystem="2.16.840.1.113883.3.1818.10.2.8.3"
codeSystemName="SNOMED-CT" />
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author Participation
-->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<informant typeCode="INF" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.10"/> <!-- Informant
Participation -->
<assignedEntity classCode="ASSIGNED">
<id nullFlavor="NA"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Cloe Everywoman</name>
</assignedPerson>
</assignedEntity>
</informant>
</observation>
</entry>
<!-- Cardiac Pacemaker Entry -->
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.8"/> <!-- Device Observation -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="DEVOBS" displayName="Device Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Cardiac Pacemaker</text>
<statusCode code="completed"/>
<effectiveTime value="20091202"/>
<value xsi:type="CD" code="14106009" displayName="Cardiac pacemaker, device "
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT" />
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author Participation
-->
<time value="20030529"/>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
258 DSTU (Revision 2013)
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<informant typeCode="INF" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.10"/> <!-- Informant
Participation -->
<assignedEntity classCode="ASSIGNED">
<id nullFlavor="NA"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Cloe Everywoman</name>
</assignedPerson>
</assignedEntity>
</informant>
</observation>
</entry>
<!-- Beast Prosthesis Entry -->
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.8"/> <!-- Device Observation -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="DEVOBS" displayName="Device Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Cardiac Pacemaker</text>
<statusCode code="completed"/>
<effectiveTime value="20091202"/>
<value xsi:type="CD" code="2282003" displayName="Breast prosthesis, device"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT" />
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<informant typeCode="INF" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.10"/> <!-- Informant
Participation -->
<assignedEntity classCode="ASSIGNED">
<id nullFlavor="NA"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Patient</name>
</assignedPerson>
</assignedEntity>
</informant>
</observation>
</entry>
Figure 72: Device Observation entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
259 DSTU (Revision 2013)
6.10 ENCOUNTER EVENT
[Encounter: templateId 2.16.840.1.113883.3.1818.10.3.9(open)]
Table 94: Encounter Event Template Context
Directly Used by Template(s) Directly Contains Template(s)
Encounter History & Notes [with entries] Attachment
Author Participation
Comment Observation
Date Observation
Informant Participation
Provider Participation
Reason Observation
Record ID Link
The Encounter Event template describes the interactions between the patient and clinicians. Interactions
include in-person encounters, telephone conversations, and email exchanges.
Encounter Note
There is a requirement for the encounter note or comment to support the following attributes:
More than one comment per encounter;
Different authors (student, MOA, responsible provider) for each encounter comments;
Comments may be structured into sections (e.g. SOAP) or free text; and
Comments may be coded (e.g. vital signs).
The Encounter Comment is designed as a related observation to the encounter. This allows the
comment to be coded or free text and includes the author(s) or informant) for the comment.
It is anticipated that each encounter may contain multiple comments; however, each comment will be
limited to a single author – the person responsible for the comment. Where there are multiple providers
(MOA, Student and Provider) who are contributing to the comment the sending system must either split
the comment into each author’s content sending a separate comment attributed to each author or it must
identify a primary or responsible author for the comment.
Whilst capturing the person making each statement is appropriate, it may create an unwieldy and difficult
to read document if all data are typed or printed out with authors, codes and dates. The Sending System
should use the CDA Level 2 Human Readable structure to ensure that the information in the Encounter
Comment is appropriately formatted to be interpretable. The receiving system should ensure that
Encounter Comment is captured and displayed appropriately.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
260 DSTU (Revision 2013)
HL7 2.x ADT External Encounters
Some EMR implementations have the ability to receive HL7 2.x Admit/Discharge/Transfer (ADT)
messages as notifications of external encounters. These messages may be processed by the EMR into
Encounter records and SHOULD be included in the Encounter History Section.
The following guidance is provided to facilitate consistent mapping from the HL7 2.x and PITO
Specification.
Table 95: PITO EMR-2-EMR Specification to HL7 v2.x ADT Mapping
CDA Element HL7 2.x Mapping
Encounter ID PV1:19 Visit Number
Encounter Start Date/Time PV1:44 Admit Date/Time
Encounter End Date/Time PV1:45 Discharge Date/Time
Encounter Provider PV1:7 Attending Doctor
Encounter Location PV1:3 Assigned Patient Location
Encounter Reason PV2:3 Admit Reason
Encounter Note NTE PV2:12 Visit Description All other fields captured from the ADT message that are relevant to the encounter.
Encounter Note Signature PV1:7 Attending Doctor
Related Record ID PV1-54 Service Event
Encounter Attachments The original ADT message may be sent as an attachment if still captured in the source system.
Next Encounter Date ARQ-11
Next Encounter Reason ARQ-7
Table 96: Encounter Event Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
911 @typeCode M:1..1
912 @contextConductionInd M:1..1
913 templateId R:1..1 II
914 encounter O:0..*
915 @classCode M:1..1
916 @moodCode M:1..1
917 Encounter ID Identification of the encounter (including assigning authority) Used to link encounters to other sections (e.g. problem list).
id M:1..1 II
4441 Code Code identifying the type of encounter (e.g.
code O:0..1 CD
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
261 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
ambulatory, emergency, home health)
918 Encounter Start and End Date/Time Start and End date/time of the encounter.
effectiveTime M:1..1 IVL_TS
919 Encounter Location Location of the encounter.
participant R:1..1
920 @typeCode M:1..1
921 @contextControlCode O:1..1
922 participantRole O:0..*
923 @classCode M:1..1
924 Location identifier id R:0..1 II
925 Encounter Provider ID and Name of provider responsible for the encounter.
participant (Provider
Participation)
R:1..*
4442 Non-Provider Participant Identification of non-provider participants in an encounter such as a translator, family member or advocate for the patient.
participant O:0..*
4443 @typeCode M:1..1
4444 @contextControlCode O:1..1
4445 participantRole O:0..*
4446 Non-Provider Participant Role @classCode M:1..1
4447 playingEntity O:0..1
4448 @classCode M:1..1
4449 @determinerCode M:1..1
4450 Non-Provider Participant Name name R:1..1 PN
4451 Non-Provider Participant Description Description of the participant (e.g. translator, family member)
desc R:1..1 ED
926 Encounter Reason The reasons or indications for the Encounter. This may be represented in the following formats: • Link to the Problem List. • A code (e.g. SNOMED code of suspected problem) • A free text string.
entryRelationship
(Reason Observation)
R:0..*
927 Next Encounter Date Date of next or follow-up encounter.
entryRelationship (Date
Observation)
O:0..*
928 Next Encounter Reason Reason for next or follow-up encounter. This may be represented in the following formats: • Link to the Problem List. • A code (e.g. SNOMED code of suspected problem) • A free text string.
entryRelationship O:0..*
1650 @typeCode M:1..1
1651 @contextConductionInd M:1..1
1653 Next Encounter Reason observation O:0..*
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
262 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1654 @classCode M:1..1
1655 @moodCode M:1..1
1656 Record ID id R:1..1 II
1657 Reason Code code R:1..1 CD
1658 Free Text Reason Text for the reason when the reason for the event is not coded.
text R:1..1 ED
1659 Reason Effective Time effectiveTime R:1..1 IVL_TS
1660 Coded Reason value A coded reason for the event. This code may be a clinical reason such as a diagnosis, a symptom or an indication, or it may be an administrative reason.
value R:1..1 CD
1661 Record Link Link to another record (such as a problem list record).
entryRelationship
(Record ID Link)
R:1..1
1662 Reason Author author (Author
Participation)
O:0..*
1663 Reason Informant informant (Informant
Participation)
O:0..*
929 Encounter Note Coded or free text notes captured in the EMR including any contextual information regarding the service from the Health Service Provider. Includes the Encounter Note Signature of the encounter note author.
entryRelationship
(Comment Observation)
R:0..*
930 Encounter Attachments Link to attachments which may be associated with this encounter.
entryRelationship
(Attachment)
O:0..*
931 Related Records Record ID of any related or associated records in the patient’s record for this encounter.
entryRelationship
(Record ID Link)
O:0..*
An Encounter Event (Encounter) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:911].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:912].
3) SHALL contain exactly one (or a nullFlavor value) [1..1] templateId [CONF:913] such that it,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.9"
[CONF:913.12].
4) MAY contain zero or more [0..*] {CDAR2} encounter [CONF:914].
a) SHALL contain exactly one [1..1] @classCode="ENC" encounter (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:915].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:916].
c) SHALL contain exactly one [1..1] id [CONF:917].
d) MAY contain zero or one [0..1] {CDAR2} code [CONF:4441].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
263 DSTU (Revision 2013)
e) SHALL contain exactly one [1..1] effectiveTime [CONF:918] such that it,
i) SHALL contain exactly one [1..1] low value to indicate the Start Date/Time and MAY contain
zero or one [0..1] high values to indicate the End Date/Time [CONF:918.63].
ii) MAY be a partial date conforming to the TS data type constraints [CONF:918.62].
f) SHALL contain exactly one (or a nullFlavor value) [1..1] participant [CONF:919].
i) SHALL contain exactly one [1..1] @typeCode="LOC" location (CodeSystem:
ParticipationType 2.16.840.1.113883.5.90) [CONF:920].
ii) MAY contain zero or one [1..1] {CDAR2} @contextControlCode="OP" overriding
propagating (CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:921].
iii) MAY contain zero or more [0..*] {CDAR2} participantRole [CONF:922].
(1) SHALL contain exactly one [1..1] @classCode="ROL" (CodeSystem: RoleClass
2.16.840.1.113883.5.110) [CONF:923].
(2) SHALL contain zero or one if available [0..1] id [CONF:924].
g) SHALL contain one or more (or a nullFlavor value) [1..*] participant [CONF:925] such that
each,
i) SHALL contain exactly one [1..1] Provider Participation
(2.16.840.1.113883.3.1818.10.4.21) [CONF:925.1].
h) MAY contain zero or more [0..*] {CDAR2} participant [CONF:4442].
i) SHALL contain exactly one [1..1] @typeCode [CONF:4443].
ii) MAY contain zero or one [1..1] {CDAR2} @contextControlCode="OP" overriding
propagating (CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:4444].
iii) MAY contain zero or more [0..*] {CDAR2} participantRole [CONF:4445].
(1) SHALL contain exactly one [1..1] @classCode, which SHALL be selected from ValueSet
RoleClass 2.16.840.1.113883.1.11.11555 STATIC [CONF:4446].
(2) MAY contain zero or one [0..1] {CDAR2} playingEntity [CONF:4447].
(a) SHALL contain exactly one [1..1] @classCode="PSN" person (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:4448].
(b) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:4449].
(c) SHALL contain exactly one (or a nullFlavor value) [1..1] name [CONF:4450].
(d) SHALL contain exactly one (or a nullFlavor value) [1..1] desc [CONF:4451].
i) SHALL contain zero or more if available [0..*] entryRelationship [CONF:926] such that each,
i) SHALL contain exactly one [1..1] Reason Observation
(2.16.840.1.113883.3.1818.10.4.24) [CONF:926.1].
j) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:927] such that each,
i) SHALL contain exactly one [1..1] Date Observation
(2.16.840.1.113883.3.1818.10.4.4) [CONF:927.1].
k) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:928].
i) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1650].
ii) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1651].
iii) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1653].
(1) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1654].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1655].
(3) SHALL contain exactly one (or a nullFlavor value) [1..1] id [CONF:1656].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
264 DSTU (Revision 2013)
(4) SHALL contain exactly one (or a nullFlavor value) [1..1] code="NXTENCREAS" Next
Encounter Reason (CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1657].
(5) SHALL contain exactly one (or a nullFlavor value) [1..1] text [CONF:1658].
(6) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime
[CONF:1659].
(7) SHALL contain exactly one (or a nullFlavor value) [1..1] value [CONF:1660].
(8) SHALL contain exactly one (or a nullFlavor value) [1..1] entryRelationship
[CONF:1661] such that it,
(a) SHALL contain exactly one [1..1] Record ID Link
(2.16.840.1.113883.3.1818.10.4.38) [CONF:1661.1].
(9) MAY contain zero or more [0..*] {CDAR2} author [CONF:1662] such that each,
(a) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1662.1].
(10) MAY contain zero or more [0..*] {CDAR2} informant [CONF:1663] such that each,
(a) SHALL contain exactly one [1..1] Informant Participation
(2.16.840.1.113883.3.1818.10.4.10) [CONF:1663.1].
l) SHALL contain zero or more if available [0..*] entryRelationship [CONF:929] such that each,
i) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:929.1].
m) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:930] such that each,
i) SHALL contain exactly one [1..1] Attachment (2.16.840.1.113883.3.1818.10.4.1)
[CONF:930.1].
n) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:931] such that each,
i) SHALL contain exactly one [1..1] Record ID Link
(2.16.840.1.113883.3.1818.10.4.38) [CONF:931.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
265 DSTU (Revision 2013)
The following XML example outlines how to use the Encounter Event template:
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.9"/> <!-- Encounter Event -->
<encounter classCode="ENC" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.12" use="BUS"/>
<effectiveTime value="20110214"/>
<!-- Encounter Location -->
<participant typeCode="LOC" contextControlCode="OP">
<participantRole classCode="SDLOC">
<id extension="155388" root="2.16.840.1.113883.3.1818.10.2.10.19" use="BUS"/>
</participantRole>
</participant>
<!-- Encounter Provider -->
<participant typeCode="PRF" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.21"/> <!-- Provider
Participation -->
<participantRole>
<id extension="155388" root="2.16.840.1.113883.3.1818.10.2.10.19" use="BUS"/>
<playingEntity classCode="PSN" determinerCode="INSTANCE">
<name>
<prefix>Mr.</prefix>
<given>Encounter</given>
<family>Provider</family>
</name>
<desc>On-call attending provider.</desc>
</playingEntity>
</participantRole>
</participant>
<!-- Encounter Reason -->
<entryRelationship typeCode="RSON" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> <!-- Reason Observation
-->
<observation classCode="OBS" moodCode="EVN">
<code code="REASON" displayName="Reason Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<text>General Medical Examination</text>
<value xsi:type="CD" code="37743000" displayName="History and physical
examination, monitoring" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED
CT"/>
</observation>
</entryRelationship>
<!-- Next Encounter Date -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.4"/> <!-- Date Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="DATEOBS" displayName="Date Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<effectiveTime>
<low value="201212201400"/>
<high value="201212201430"/>
</effectiveTime>
</observation>
</entryRelationship>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
266 DSTU (Revision 2013)
<!-- Next Encounter Reason -->
<entryRelationship typeCode="RSON" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<id extension="155388" root="2.16.840.1.113883.3.1818.10.2.10.19"/>
<code code="NXTENCREAS" displayName="Next Encounter Reason"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<text>General Medical Examination</text>
<value xsi:type="CD" code="37743000" displayName="History and physical
examination, monitoring" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED
CT"/>
<!-- Next Encounter Reason Author -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Next Encounter Reason Informant -->
<informant typeCode="INF" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.10"/> <!-- Informant
Participation -->
<assignedEntity classCode="ASSIGNED">
<id nullFlavor="NA"/>
<assignedPerson>
<name>Royal X Hospital</name>
</assignedPerson>
</assignedEntity>
</informant>
<!-- Next Encounter Reason Record Link -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.38"/> <!-- Record ID Link --
>
<act classCode="ACT" moodCode="EVN">
<id extension="BC20120201RXO-1458755BN"
root="2.16.840.1.113883.3.1818.10.10.3"/>
<code code="RECLINK" displayName="Attachment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
</act>
</entryRelationship>
</observation>
</entryRelationship>
<!-- Encounter Notes -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment Observation
-->
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="ST">This is the Encounter Note comment</value>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
267 DSTU (Revision 2013)
</observation>
</entryRelationship>
<!-- Attachment or Reference -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.1"/> <!-- Attachment -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="ATTACH" displayName="Attachment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<text>Keywords: GME</text>
<effectiveTime value="20120202"/>
<value xsi:type="ST">General Medical Examination Report</value>
<!-- Attachment Notes not included in this sample-->
<!-- Reviewed Dates not included in this sample-->
<!-- Attachment or Reference -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.9"/> <!-- Encapsulated Data
-->
<observationMedia classCode="OBS" moodCode="EVN">
<id extension="127797" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<value mediaType="application/pdf">
<reference value="http://www.anywhere.com/folder1/20120202-Patient1-
claim1.pdf"/>
</value>
<!--Attachment author not included in this sample -->
</observationMedia>
</entryRelationship>
</observation>
</entryRelationship>
<!-- Related Records -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.38"/> <!-- Record ID Link -->
<act classCode="ACT" moodCode="EVN">
<id extension="BC20120201RXO-1458755BN"
root="2.16.840.1.113883.3.1818.10.10.3"/>
<code code="RECLINK" displayName="Attachment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
</act>
</entryRelationship>
</encounter>
</entry>
Figure 73: Encounter Event entry example
6.11 FAMILY HISTORY OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.3.10(open)]
Table 97: Family History Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Family History [with entries] Comment Observation
Lifestage Observation
Secondary Code (ICD-9)
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
268 DSTU (Revision 2013)
The Family History templates describe a family member’s clinically relevant information as it pertains to
the patient’s health. This includes information regarding the relationship, cause of death and age at death
as well as any relevant diagnosis and treatments that the family member may have had.
The effectiveTime in the Family History Observation is the biologically or clinically relevant time of the
observation. The biologically or clinically relevant time is the time at which the observation holds (is
effective) for the family member (the subject of the observation).
Problem Type
An entry in the Problem List may be categorized by Problem Types (e.g. diagnosis, findings, functional
limitations etc.) The Problem Type is specified in the <code> element using a sub-set of SNOMED CT®
values. If the source EMR does not support problem observation types, then a nullFlavor of “NI” should
be sent in the <code> element. If the destination EMR does not support problem observation types, then
it should capture the problem type as a text.
Family History Diagnosis Coding
While it is recognized that the ICD9 is predominantly used to code diagnoses for billing purposes, this
code is generally accepted as a billing or administrative code rather than a coding that has clinical value.
Where coding for clinical purposes; SNOMED CT® is the coding system of choice identified by both the
Clinician Panel and the consensus of standards setting organizations, other specifications and the pan-
Canadian Standards Collaborative. Vendors participating in the initial design have also confirmed a
capability with their EMRs to support SNOMED CT® for clinical coding of diagnoses.
As a result these specification separate the coding of a diagnosis for billing/administrative purposes from
the coding for clinical purposes into two separate elements.
Diagnosis Code will be used exclusively for clinical codification of the diagnosis. The only supported
coding system for this element in the specification will be SNOMED CT®.
Diagnosis ICD-9 Classification Code will be used exclusively for administrative codification of the
diagnosis. The only supported coding system for this element in the specification will be ICD-9.
Diagnosis Text <text> SHALL be populated when neither the Diagnosis Code <value> nor the
Diagnosis ICD-9 Classification Code are provided and SHALL be used to identify the diagnosis as a
free-text diagnosis.
The Diagnosis Text MAY also be populated when the diagnosis is coded and the source system
captures a free text diagnosis name in addition to the <displayName> associated with the <code>
in the <codeSystem>.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
269 DSTU (Revision 2013)
The cardinality of all three fields is R:1..1 indicating that if the information is available in the source
system, then it SHALL be populated. For example:
If the diagnosis is coded in SNOMED (or a reliable mapping is deemed to exist), then Diagnosis Code
is required to be populated; otherwise a NullFlavor of “UNK” (Unknown) SHALL be sent.
<value xsi:type="CD" code="59621000" displayName="Essential hypertension"
codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT" />
or
<value xsi:type="CD" NullFlavor="UNK"/>
Figure 74: Example “SNOMED CT® Diagnosis”
If the diagnosis is coded in ICD-9 (or a reliable mapping is deemed to exist), then Diagnosis ICD-9
Classification Code is required to be populated; otherwise a NullFlavor of “UNK” (Unknown) SHALL
be sent.
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.28"/>
<observation classCode="OBS" moodCode="EVN">
<code code="BILLINGCODE" displayName="Billing Code"
codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending"/>
<value xsi:type="CD" code="401" codeSystem="2.16.840.1.113883.6.42"
codeSystemName="ICD9" displayName="Bacterial Infection"/>
</observation>
</entryRelationship>
Or
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.28"/>
<observation classCode="OBS" moodCode="EVN">
<code code="BILLINGCODE" displayName="Billing Code"
codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending"/>
<value xsi:type="CD" nullFlavor="UNK"/>
</observation>
</entryRelationship>
Figure 75: Example “ICD9 Diagnosis”
If the diagnosis is coded in a code system other than SNOMED or ICD-9, Diagnosis code SHALL be
populated with a NullFlavor of “OTH” (Other) and the code and code system SHALL be sent in the
<translation> element.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
270 DSTU (Revision 2013)
<value xsi:type="CD" nullFlavor="OTH">
<translation code="K86" displayName="Hypertension Uncomplicated"
codeSystem="2.16.840.1.113883.6.139.1" codeSystemName="icpc2E-ENG"/>
</value>
Figure 76: Example “Other Coding System Diagnosis”
Table 98: Family History Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
932 @typeCode M:1..1
933 @contextConductionInd M:1..1
934 templateId O:0..* II
935 observation O:0..*
936 @classCode M:1..1
937 @moodCode M:1..1
938 Record ID id M:1..1 II
939 Problem Type This element identifies the category of family history problem being reported. If a problem type is not known, a nullFlavor of “NI” should be sent.
code R:1..1 CD
940 Diagnosis Name The name or short description for the diagnosis.
text R:0..1 ED
941 Onset Date/Date Resolved Onset and resolved date/time.
effectiveTime R:1..1 IVL_TS
1664 Diagnosis Code The SNOMED code associated with the Diagnosis/Problem.
value M:1..1 ANY
942 Family Member relationship subject R:1..1
943 @typeCode M:1..1
944 relatedSubject O:0..1
945 @classCode M:1..1
946 Relationship code code R:1..1 CE
947 Treatment Comment A textual or coded description of any treatments and associated comments (e.g. outcomes) undertaken by the family member in relation to the problem/condition.
entryRelationship R:0..*
1665 @typeCode M:1..1
1666 @contextConductionInd M:1..1
1668 observation O:0..*
1669 @classCode M:1..1
1670 @moodCode M:1..1
1671 Record ID id R:0..1 II
1672 Treatment Comment Code code R:1..1 CD
1673 Free Text Comment text R:1..1 ED
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
271 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1674 Comment Effective Time effectiveTime R:0..1 IVL_TS
1675 Coded Treatment Comment value R:1..1 CD
948 Notes / Comments Any observations, notes or comments by the provider regarding the family member’s problem/condition.
entryRelationship
(Comment Observation)
O:0..*
949 Diagnosis ICD9 Code The billing code associated with the Diagnosis/Problem including the coding system used and the display name associated with the code by the coding system.
entryRelationship
(Secondary Code (ICD-9))
R:1..1
950 Lifestage at onset entryRelationship
(Lifestage Observation)
O:0..1
951 Age At Onset entryRelationship O:0..1
952 @typeCode M:1..1
953 observation O:0..*
954 @classCode M:1..1
955 @moodCode M:1..1
956 Age at Onset Observation Code code M:1..1 CD
957 Age at Onset Value value M:1..1 PQ
958 Age At Death entryRelationship O:0..1
959 @typeCode M:1..1
960 observation O:0..*
961 @classCode M:1..1
962 @moodCode M:1..1
963 Age at Death Observation Code code M:1..1 CD
964 Age at Death Value value M:1..1 PQ
965 Cause of Death entryRelationship O:0..1
966 @typeCode M:1..1
967 observation O:0..*
968 @classCode M:1..1
969 @moodCode M:1..1
970 Cause of Death Observation Code code M:1..1 CD
971 Cause of Death Value value M:1..1 st
A Family History Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:932].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:933].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:934] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.10"
[CONF:934.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:935].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
272 DSTU (Revision 2013)
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:936].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:937].
c) SHALL contain exactly one [1..1] id [CONF:938].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] code, which SHALL be selected from
ValueSet ProblemType 2.16.840.1.113883.3.88.12.3221.7.2 STATIC [CONF:939].
e) SHALL contain zero or one if available [0..1] text [CONF:940] such that it,
i) SHALL be populated when neither the Diagnosis Code code nor the Diagnosis ICD9
Classification Code are provided and SHALL be used to identify the diagnosis as a free-text diagnosis; MAY be included when the diagnosis is coded if the sending system captures a free text diagnosis name in addition to the displayName associated with the code
[CONF:940.43].
f) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:941] such
that it,
i) SHALL contain exactly one [1..1] low value to indicate the Start Date/Time and MAY contain
zero or one [0..1] high values to indicate the End Date/Time [CONF:941.63].
ii) MAY be a partial date conforming to the TS data type constraints [CONF:941.62].
g) SHALL contain exactly one [1..1] value, which, when coded, SHALL be selected from ValueSet
DiagnosisValuePrimary 2.16.840.1.113883.2.20.3.40 DYNAMIC [CONF:1664].
h) SHALL contain exactly one (or a nullFlavor value) [1..1] subject [CONF:942].
i) SHALL contain exactly one [1..1] @typeCode="SBJ" subject (CodeSystem: ParticipationType
2.16.840.1.113883.5.90) [CONF:943].
ii) MAY contain zero or one [0..1] {CDAR2} relatedSubject [CONF:944].
(1) SHALL contain exactly one [1..1] @classCode="PRS" personal relationship
(CodeSystem: RoleClass 2.16.840.1.113883.5.110) [CONF:945].
(2) SHALL contain exactly one (or a nullFlavor value) [1..1] code, which SHALL be
selected from ValueSet PersonalRelationshipRoleType 2.16.840.1.113883.2.20.3.90 STATIC [CONF:946].
i) SHALL contain zero or more if available [0..*] entryRelationship [CONF:947].
i) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1665].
ii) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1666].
iii) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1668].
(1) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1669].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1670].
(3) SHALL contain zero or one if available [0..1] id [CONF:1671].
(4) SHALL contain exactly one (or a nullFlavor value) [1..1] code="TRTNOTE" Treatment
Comment (CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1672].
(5) SHALL contain exactly one (or a nullFlavor value) [1..1] text [CONF:1673].
(6) SHALL contain zero or one if available [0..1] effectiveTime [CONF:1674].
(7) SHALL contain exactly one (or a nullFlavor value) [1..1] value [CONF:1675].
j) MAY contain zero or more [0..*] entryRelationship [CONF:948] such that each,
i) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:948.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
273 DSTU (Revision 2013)
k) SHALL contain exactly one (or a nullFlavor value) [1..1] entryRelationship [CONF:949]
such that it,
i) SHALL contain exactly one [1..1] Secondary Code (ICD-9)
(2.16.840.1.113883.3.1818.10.4.28) [CONF:949.1].
l) MAY contain zero or one [0..1] entryRelationship [CONF:950] such that it,
i) SHALL contain exactly one [1..1] Lifestage Observation
(2.16.840.1.113883.3.1818.10.4.12) [CONF:950.1].
m) MAY contain zero or one [0..1] entryRelationship [CONF:951].
i) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:952].
ii) MAY contain zero or more [0..*] {CDAR2} observation [CONF:953].
(1) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:954].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:955].
(3) SHALL contain exactly one [1..1] code="30972-4" Age at Onset (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:956].
(4) SHALL contain exactly one [1..1] value [CONF:957].
n) MAY contain zero or one [0..1] entryRelationship [CONF:958].
i) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:959].
ii) MAY contain zero or more [0..*] {CDAR2} observation [CONF:960].
(1) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:961].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:962].
(3) SHALL contain exactly one [1..1] code="39016-1" Age at Death (CodeSystem: LOINC
2.16.840.1.113883.6.1) [CONF:963].
(4) SHALL contain exactly one [1..1] value [CONF:964].
o) MAY contain zero or one [0..1] entryRelationship [CONF:965].
i) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:966].
ii) MAY contain zero or more [0..*] {CDAR2} observation [CONF:967].
(1) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:968].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:969].
(3) SHALL contain exactly one [1..1] code="21984-0" Cause of Death (CodeSystem:
LOINC 2.16.840.1.113883.6.1) [CONF:970].
(4) SHALL contain exactly one [1..1] value [CONF:971].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
274 DSTU (Revision 2013)
The following XML example outlines how to use the Family History Observation template:
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.10"/> <!-- Family History
Observation -->
<observation classCode="OBS" moodCode="EVN">
<id extension="123669" root="2.16.840.1.113883.3.1818.10.2.10.33"/>
<code code="DX" displayName="Diagnosis" codeSystem="2.16.840.1.113883.5.4"
codeSystemName="Act Code"/>
<text>Family history of cancer of colon</text>
<!-- In this example, the onset and resolved dates are unknown, only the age of
the family member -->
<effectiveTime nullFlavor="UNK"/>
<value xsi:type="CD" code="312824007" displayName="Family history of cancer of
colon" codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT" />
<!--Relationship to the patient-->
<subject typeCode="SBJ" contextControlCode="OP">
<relatedSubject classCode="PRS">
<code code="NMTH" displayName="Natural Mother"
codeSystem="2.16.840.1.113883.5.111" codeSystemName="PersonalRelationshipRoleType" />
</relatedSubject>
</subject>
<!-- Notes / Comments -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment Observation
-->
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Mom was diagnosed with metastatic cancer of colon and died at age
55.</text>
</observation>
</entryRelationship>
<!-- Diagnosis Billing Code -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.28"/> <!-- Secondary Code
(ICD9) -->
<observation classCode="OBS" moodCode="EVN">
<code code="BILLINGCODE" displayName="Billing Code"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="CD" code="BIN" codeSystem="2.16.840.1.113883.6.42"
codeSystemName="ICD9" displayName="Bacterial Infection"/>
</observation>
</entryRelationship>
<!-- Lifestage at onset -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.12"/> <!-- Lifestage
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="LIFEOBS" displayName="Lifestage Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="CD" code="133936004" displayName="Adult"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT"/>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
275 DSTU (Revision 2013)
</observation>
</entryRelationship>
<!--Pertinent observations regarding the condition-->
<!--Age at Onset-->
<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<code code="30972-4" displayName="Age at onset"
codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
<value xsi:type="INT" value="54"/>
</observation>
</entryRelationship>
<!--Age at Death-->
<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<code code="39016-1" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="Age at Death"/>
<value xsi:type="INT" value="55"/>
</observation>
</entryRelationship>
<!--Cause of Death-->
<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<code code="21984-0" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="Cause of Death"/>
<value xsi:type="CD" code="58258-5" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="Myocardial Infarction"/>
</observation>
</entryRelationship>
<!-- Treatment Comment -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<code code="TRTNOTE" displayName="Treatment Note"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Infared radiation therapy attempted in December 2009 and was not
successful.</text>
<effectiveTime value="20091202"/>
<value xsi:type="CD" code="169421008" displayName="Infrared radiation
therapy" codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT" />
</observation>
</entryRelationship>
</observation>
</entry>
Figure 77: Family History Observation entry example
6.12 IMMUNIZATION OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.3.11(open)]
Table 99: Immunization Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Immunizations List [with entries] Author Participation
Comment Observation
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
276 DSTU (Revision 2013)
Directly Used by Template(s) Directly Contains Template(s)
Date Observation
Location Participation
Reaction Observation
Reason Observation
Secondary Code (Drug)
The Immunization Observation template describes immunization substance administrations that have
actually occurred or are intended to occur. Immunization Activities in "INT" mood are reflections of
immunizations a clinician intends a patient to receive. Immunization Activities in "EVN" mood reflect
immunizations actually received.
An Immunization Activity is very similar to a Medication Activity with some key differentiators. The drug
code system is constrained to DIN codes. Administration timing is less complex. Patient refusal reasons
should be captured. All vaccines administered should be fully documented in the patient's permanent
medical record.
Vaccine Status
Some of the source specifications include a Vaccine Status and this was considered as part of the PITO
specification. However, the project team recommends this element (vaccination status) be dropped as it
is difficult to interpret in an ambulatory or EMR setting. The AHW IZ Project considered ‘vaccine
effectiveness’ which is a very close concept, but determined from a process perspective that this info
would rarely, if ever, be available.
Most EMR systems have the ability to provide a calculated Immunization status based on the information
in the immunization list and guidelines based on patient characteristics (e.g. age, comorbidities, Marrow
transplant, institutionalization, etc.) which combined may modify what constitutes "up to date" for a given
patient. Based on these parameters, EMR’s may be able to generate recall lists and flags for discussion;
however, this functionality is appropriately within the EMR systems and not part of a EMR to EMR transfer
specification’s scope.
Where establishing the immunity status is clinically relevant, for example in the case of checking a
pregnant mother’s immunity to Rubella, this may be communicated as a Clinical Observation.
Reported Immunization Flag
The information available and appropriate to be recorded will vary based on if the context are historical
immunizations as per the use cases outlined above. It is necessary to allow the communication of
minimal information but also support richer information if recording a vaccination event. It should be
noted that a checkbox “yes vaccine for tetanus” – asked of patient, may not be appropriate entry in the
immunization list and could be captured under clinical notes instead.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
277 DSTU (Revision 2013)
The Reported Immunization Flag allows the communication of the source of the immunization list entry. If
this flag is populated with “True”, then the requirements and expectations for discrete data regarding the
immunization are less and the receiving provider will be able to interpret the record based on an
appropriate understanding of its providence. If the Reported Immunization Flag is unpopulated, absent
or “False”, then there is an expectation that the code for the specific vaccination product administered as
well as full administration details will be present.
Series Count
The Series Count element (also known as the Antigen count, dose number or vaccination number)
allows for the communication of which administration in a vaccine series is being communicated. For
example, if there are three administrations required for an antigen and this is the second administration;
the Antigen Count will be “2 of 3”.
Lot Number
The Lot Number is important for the Patient Transfer and Conversion use case where the ongoing care
and clinical responsibility for the patient is transferred with the patient record. The Lot Number enables
the receiving system to track the patient if a product recall or findings of vaccine failures are identified as
these are sometimes not recognized until years after administration.
Recording Non-Immunizations
Non-immunizations should be recorded and should be part of the immunization record (and not be
separate). Each non-immunization or refusal is recorded as a "negated" immunization with a reason
selected from a list of ‘refusal reasons’. Allowing Non-immunizations to be recorded informs the system
that the doctor is aware of such a decision.
Table 100: Immunization Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
972 @typeCode M:1..1
973 @contextConductionInd M:1..1
974 templateId O:0..* II
975 substanceAdministration O:0..*
976 @classCode M:1..1
977 @moodCode M:1..1
980 Vaccine Negation True/False flag to indicate to code that vaccine was NOT given (e.g. refused).
@negationInd R:0..1
978 Record ID Unique identifier for the immunization event Used to link immunizations to other sections (e.g. problem list).
id M:1..1 II
979 Substance Type code O:0..1 CD
981 Immunization Date effectiveTime M:1..1 SXCM_T
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
278 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
Date/time that immunization event occurred or was refused.
S
982 Administrating Method /Route Code The route of administration of the vaccine into the patient (e.g. intradermal).
routeCode R:0..1 CE
983 Vaccine Site Code The anatomical site into which the vaccine is administered into the patient (e.g. Left Arm).
approachSiteCode R:0..1 CD
984 Dose The amount of the vaccine administered into the patient (e.g. 3 Drops).
doseQuantity R:0..1 IVL_PQ
985 Dose Type The Dosage Type Code is the unit in which the dosage of the vaccine is administered into the immunization service recipient (e.g. drops).
administrationUnitCode R:0..1 CE
986 Immunization Product consumable R:1..1
987 @typeCode M:1..1
988 manufacturedProduct R:1..1
989 @classCode M:1..1
990 manufacturedMaterial R:1..1
991 @classCode M:1..1
992 @determinerCode M:1..1
993 Vaccine Code Vaccine Identification code from a recognized coding system. The PITO Specification will identify a list of recognized coding systems.
code R:1..1 CE
994 Vaccine Name Vaccine Identification code from a recognized coding system. The PITO Specification will identify a list of recognized coding systems.
name R:1..1 EN
995 Lot Number The manufacturer’s lot number for the vaccine administered into the patient. It represents a code assigned to a package of several individual doses of a particular vaccine comprising a manufacturer’s unit of production.
lotNumberText R:0..1 ST
996 Alternate Immunization Product Coding entryRelationship
(Secondary Code (Drug))
R:0..*
997 Reported Immunization Indicator True/False flag to indicate if the Immunization Record is for an immunization event captured directly during administration of the immunization in the EMR or if it is a 'historical' or 'reported' immunization event.
entryRelationship O:0..*
998 @typeCode M:1..1
999 observation O:0..*
1000 @classCode M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
279 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1001 @moodCode M:1..1
1002 Reported Indicator Code code R:1..1 CD
1003 Reported Indicator Value value R:0..1 bl
1004 Antigen / Vaccine Type The Vaccine type identifies the Active Immunizing Agent or Antigen for the immunization.
entryRelationship M:1..1
1005 @typeCode M:1..1
1006
substanceAdministration
O:0..*
1007 @classCode M:1..1
1008 @moodCode M:1..1
1009 Substance Type code O:0..1 CD
1010 Series Count The count of the antigen that is being administered. The recommended format is a series number and maximum number. For example “1 of 3” indicating that the series number is 1 and the maximum number is 3. <value=”1 of 3”/>.
repeatNumber R:0..1 IVL_INT
1011 Antigen Product consumable R:1..1
1012 @typeCode M:1..1
1013 manufacturedProduct R:1..1
1014 @classCode M:1..1
1015
manufacturedMaterial
R:1..1
1016 @classCode M:1..1
1017 @determinerCode M:1..1
1018 Antigen Code Vaccine Identification code.
code R:1..1 CE
1019 Antigen Name Vaccine Identification code from a recognized coding system. The PITO Specification will identify a list of recognized coding systems.
name R:1..1 EN
1020 Immunization Administration Provider (id) ID and Name of primary provider who administered the immunization.
author (Author
Participation)
R:1..1
1021 Immunization Administration Location Location of the vaccination event (e.g. Primary provider’s office or public health office). • If unknown, NullFlavor may be sent (e.g. UNK [Unknown]).
participant (Location
Participation)
R:1..1
1022 Immunization or Refusal Reason Coded or textual reason for the immunization, or the immunization refusal (e.g. refusal, contraindicated). This is the reason why the vaccine is administered into
entryRelationship
(Reason Observation)
R:0..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
280 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
the patient. A Reason For Immunization is required for selected Vaccine Codes.
1023 Next Immunization Date Date of next or follow-up immunization event. • May be a partial date.
entryRelationship (Date
Observation)
R:0..1
1024 Immunization Adminstration Comment Comments specific to the Immunization event or a particular antigen to capture any contextual information regarding the immunization event from the immunization administrating provider.
entryRelationship
(Comment Observation)
R:0..1
1025 Reaction Patient medical reaction to the immunization administration.
entryRelationship
(Reaction Observation)
R:0..*
An Immunization Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:972].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:973].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:974] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.11"
[CONF:974.12].
4) MAY contain zero or more [0..*] {CDAR2} substanceAdministration [CONF:975].
a) SHALL contain exactly one [1..1] @classCode="SBADM" substance administration (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:976].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:977].
c) SHALL contain zero or one if available [0..1] @negationInd [CONF:980].
d) SHALL contain exactly one [1..1] id [CONF:978].
e) MAY contain zero or one [0..1] {CDAR2} code="IMMUNIZ" immunization (CodeSystem: ActCode
2.16.840.1.113883.5.4) [CONF:979].
f) SHALL contain exactly one [1..1] effectiveTime [CONF:981] such that it,
i) MAY be a partial date conforming to the TS data type constraints [CONF:981.62].
g) SHALL contain zero or one if available [0..1] routeCode, which SHALL be selected from ValueSet
RouteOfAdministration 2.16.840.1.113883.2.20.3.188 STATIC [CONF:982].
h) SHALL contain zero or one if available [0..1] approachSiteCode, which SHALL be selected from
ValueSet HumanSubstanceAdministrationSite 2.16.840.1.113883.2.20.3.52 DYNAMIC [CONF:983].
i) SHALL contain zero or one if available [0..1] doseQuantity [CONF:984].
j) SHALL contain zero or one if available [0..1] administrationUnitCode, which SHALL be
selected from ValueSet AdministerableDrugForm 2.16.840.1.113883.1.11.14570 STATIC [CONF:985].
k) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} consumable [CONF:986].
i) SHALL contain exactly one [1..1] @typeCode="CSM" consumable (CodeSystem:
ParticipationType 2.16.840.1.113883.5.90) [CONF:987].
ii) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} manufacturedProduct
[CONF:988].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
281 DSTU (Revision 2013)
(1) SHALL contain exactly one [1..1] @classCode="MANU" manufactured product
(CodeSystem: RoleClass 2.16.840.1.113883.5.110) [CONF:989].
(2) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2}
manufacturedMaterial [CONF:990].
(a) SHALL contain exactly one [1..1] @classCode="MMAT" manufactured material
(CodeSystem: EntityClass 2.16.840.1.113883.5.41) [CONF:991].
(b) SHALL contain exactly one [1..1] @determinerCode="KIND" kind (CodeSystem:
EntityDeterminer 2.16.840.1.113883.5.30) [CONF:992].
(c) SHALL contain exactly one (or a nullFlavor value) [1..1] code, which SHALL be
selected from ValueSet MaterialEntityClassType 2.16.840.1.113883.1.11.16041 STATIC {CDAR2} [CONF:993].
(d) SHALL contain exactly one (or a nullFlavor value) [1..1] name [CONF:994].
(e) SHALL contain zero or one if available [0..1] lotNumberText [CONF:995].
l) SHALL contain zero or more if available [0..*] entryRelationship [CONF:996] such that each,
i) SHALL contain exactly one [1..1] Secondary Code (Drug)
(2.16.840.1.113883.3.1818.10.4.27) [CONF:996.1].
m) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:997].
i) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:998].
ii) MAY contain zero or more [0..*] {CDAR2} observation [CONF:999].
(1) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1000].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1001].
(3) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} code="REPIND"
Reported Indicator (CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1002].
(4) SHALL contain zero or one if available [0..1] value [CONF:1003] such that it,
(a) SHALL contain "TRUE" if the immunization is reported [CONF:1003.46].
n) SHALL contain exactly one [1..1] entryRelationship [CONF:1004].
(a) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1005].
(b) MAY contain zero or more [0..*] {CDAR2} substanceAdministration [CONF:1006].
(i) SHALL contain exactly one [1..1] @classCode="SBADM" substance
administration (CodeSystem: ActClass 2.16.840.1.113883.5.6) [CONF:1007].
(ii) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem:
ActMood 2.16.840.1.113883.5.1001) [CONF:1008].
(iii) MAY contain zero or one [0..1] {CDAR2} code="IMMUNIZ" immunization
(CodeSystem: ActCode 2.16.840.1.113883.5.4) [CONF:1009].
(iv) SHALL contain zero or one if available [0..1] repeatNumber [CONF:1010].
(v) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} consumable
[CONF:1011].
1. SHALL contain exactly one [1..1] @typeCode="CSM" consumable
(CodeSystem: ParticipationType 2.16.840.1.113883.5.90) [CONF:1012].
2. SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2}
manufacturedProduct [CONF:1013].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
282 DSTU (Revision 2013)
a. SHALL contain exactly one [1..1] @classCode="MANU" manufactured
product (CodeSystem: RoleClass 2.16.840.1.113883.5.110) [CONF:1014].
b. SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2}
manufacturedMaterial [CONF:1015].
i. SHALL contain exactly one [1..1] @classCode="MMAT"
manufactured material (CodeSystem: EntityClass 2.16.840.1.113883.5.41) [CONF:1016].
ii. SHALL contain exactly one [1..1] @determinerCode="KIND" kind
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) [CONF:1017].
iii. SHALL contain exactly one (or a nullFlavor value) [1..1] code,
which SHALL be selected from ValueSet VaccineAdministeredNameCode 2.16.840.1.113883.2.20.3.264 DYNAMIC {CDAR2} [CONF:1018].
iv. SHALL contain exactly one (or a nullFlavor value) [1..1] name
[CONF:1019]. o) SHALL contain exactly one (or a nullFlavor value) [1..1] author [CONF:1020] such that it,
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1020.1].
p) SHALL contain exactly one (or a nullFlavor value) [1..1] participant [CONF:1021] such that
it,
i) SHALL contain exactly one [1..1] Location Participation
(2.16.840.1.113883.3.1818.10.4.13) [CONF:1021.1].
q) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1022] such that it,
i) SHALL contain exactly one [1..1] Reason Observation
(2.16.840.1.113883.3.1818.10.4.24) [CONF:1022.1].
r) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1023] such that it,
i) SHALL contain exactly one [1..1] Date Observation
(2.16.840.1.113883.3.1818.10.4.4) [CONF:1023.1].
s) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1024] such that it,
i) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:1024.1].
t) SHALL contain zero or more if available [0..*] entryRelationship [CONF:1025] such that each,
i) SHALL contain exactly one [1..1] Reaction Observation
(2.16.840.1.113883.3.1818.10.4.23) [CONF:1025.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
283 DSTU (Revision 2013)
The following XML example outlines how to use the Immunization Observation template:
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.11"/> <!-- Immunization
Observation -->
<substanceAdministration classCode="SBADM" moodCode="EVN" negationInd="false">
<id extension="BC20120211VAC-145999X" root="2.16.840.1.113883.3.1818.10.10.3"/>
<code code="IMMUNIZ" displayName="Immunization"
codeSystem="2.16.840.1.113883.5.4" codeSystemName="HL7 Act Code"/>
<!-- Immunizatin Date -->
<effectiveTime value="199911"/>
<routeCode code="PO" displayName="per os" codeSystem="2.16.840.1.113883.5.112"
codeSystemName="RouteOfAdministration"/>
<approachSiteCode code="LA" displayName="left arm"
codeSystem="2.16.840.1.113883.12.163" codeSystemName="Body Site"/>
<doseQuantity>
<center value="100" unit="mg"/>
</doseQuantity>
<!-- Dose Type-->
<administrationUnitCode code="DROP" displayName="Drops"
codeSystem="2.16.840.1.113883.5.85" codeSystemName="AdministerableDrugForm"/>
<!-- Immunization Product (i.e. DIN) -->
<consumable typeCode="CSM">
<manufacturedProduct classCode="MANU">
<manufacturedMaterial classCode="MMAT" determinerCode="KIND">
<code code="00466085" displayName="M-M-R*II"
codeSystem="2.16.840.1.113.883.5.1105" codeSystemName="hc-DIN" />
<name>Measles, Mups, Rubella</name>
<lotNumberText>BR549-201112</lotNumberText>
</manufacturedMaterial>
</manufacturedProduct>
</consumable>
<!-- Immunization Administration Provider -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author Participation
-->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Immunization Administration Location -->
<participant typeCode="LOC" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.13"/> <!-- Location
Participation -->
<participantRole classCode="SDLOC">
<playingEntity>
<name>Walk In Clinic</name>
</playingEntity>
</participantRole>
</participant>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
284 DSTU (Revision 2013)
<!-- Alternate Product Coding -->
<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.4.27"/> <!-- Secondary Code
Drug -->
<code code="SECDRUGCODE" displayName="Secondary Drug Code"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="CD" code="61153008" displayName="Measles + Mumps + Rubella
vaccine " codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT" />
</observation>
</entryRelationship>
<!-- Antigen Vaccine Type (PHAC Antigen code) -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<substanceAdministration classCode="SBADM" moodCode="EVN">
<code code="ANTIGEN" codeSystem="2.16.840.1.113883.5.4"
displayName="Anitgen"/>
<repeatNumber value="2"/>
<consumable typeCode="CSM">
<manufacturedProduct classCode="MANU">
<manufacturedMaterial classCode="MMAT" determinerCode="KIND">
<code code="61153008" displayName="Measles + Mumps + Rubella vaccine "
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT" />
<name>Measles, Mumps, Rubella</name>
</manufacturedMaterial>
</manufacturedProduct>
</consumable>
</substanceAdministration>
</entryRelationship>
<!--Reported Immunization Indicator -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<code code="REPIND" displayName="Reported Indicator"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<value xsi:type="BL" value="false"/>
</observation>
</entryRelationship>
<!-- Immunization or Refusal Reason 1022 -->
<entryRelationship typeCode="RSON" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> <!-- Reason Observation
-->
<observation classCode="OBS" moodCode="EVN">
<code code="REASON" displayName="Reason Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<text>Patient potentially exposed. </text>
<value xsi:type="CD" code="37743000" displayName="History and physical
examination, monitoring" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED
CT"/>
</observation>
</entryRelationship>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
285 DSTU (Revision 2013)
<!-- Next Immunization Date -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.4"/> <!-- Date Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="DATEOBS" displayName="Date Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<effectiveTime>
<low value="200311"/>
<high value="200411"/>
</effectiveTime>
</observation>
</entryRelationship>
<!-- Immunization Administration Comment -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment Observation
-->
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="ST">This is the administration comment. Patient
bites!</value>
</observation>
</entryRelationship>
<!-- Reaction -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.23"/> <!-- Reaction
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="REACTOBS" displayName="Reaction Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Sweating Fever</text>
<effectiveTime> <low value="199911"/> </effectiveTime>
<value xsi:type="CD" code="186694006" displayName="Sweating fever"
codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
<!-- Reaction Severity -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.30"/> <!-- Severity
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="SEV" displayName="Severity" codeSystem="2.16.840.1.113883.5.4"
codeSystemName="HL7 ActCode" />
<value xsi:type="CD" code="A2" displayName="Mild Reaction"
codeSystem="2.16.840.1.113883.5.1063" codeSystemName="HL7 ObservationValue" />
</observation>
</entryRelationship>
<!-- Reaction Comment not included in this sample -->
<!-- Reaction Author not included in this sample -->
<!-- Reaction Informant not included in this sample -->
</observation>
</entryRelationship>
</substanceAdministration>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
286 DSTU (Revision 2013)
</entry>
Figure 78: Immunization Observation entry example
6.13 LABORATORY OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.3.12(open)]
Table 101: Laboratory Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Laboratory Results & Reports [with entries] Author Participation
Comment Observation
Result Organizer
The Laboratory Observation template defines the format for the results of observations generated by
laboratories. The scope includes observations such as hematology, chemistry, serology, virology,
toxicology, microbiology, and pathology observations. The section often includes notable results such as
abnormal values or relevant trends, and could contain all results for the period of time being documented.
Laboratory results are typically generated by laboratories providing analytic services in areas such as
chemistry, hematology, serology, histology, cytology, anatomic pathology, microbiology, and/or virology.
These observations are based on analysis of specimens obtained from the patient and submitted to the
laboratory.
Order Information
For Lab workflow exchanges, there is clearly a difference between the lab request/order and the lab
result. However, EMR systems are frequently only interested in the result and may not track the order as
a distinct record. Where an order may be placed electronically and the subsequent result communicated
back electronically, some of the order information is echoed back to facilitate the matching of orders
against results. This information may include the ordering system’s identifier for the order and the code
or text describing the ordered procedure.
Collection Information
For Lab results, the effective time of the result is the physiological time of the specimen being tested. In
other words, the result is a measurement of a characteristic of a specimen at the time the specimen was
obtained/collected. Most electronic laboratory result systems will include the observation date/time (HL7
2.x OBR-7) in the result message and this information should be maintained as part of the clinically
relevant meta-data attached to the result record.
Scanned / Attached Laboratory Results & Reports
Many clinics receive laboratory reports in paper format either directly or through a fax system. These
reports are attached to the patient’s medical record as image attachments with minimal discrete data
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
287 DSTU (Revision 2013)
available. Refer to the Attachments template for details on the collection of meta-data for encapsulated
data reports.
Results Information
The format and structure of laboratory result information is very varied because there are many types of
laboratory tests available. Common types of result data that are supported include coded, text, quantity
measures, and encapsulated data or attachments.
If results are coded, they could be coded using any number of code systems including SNOMED and
specialized clinical scales. Whilst it is important for the sending system to include any information
regarding the coding system used for the laboratory result; it is not necessary for the receiving system to
support the specific coding system used. The receiving system will use the code value, display name
and supporting elements (reference ranges, abnormality flags etc) to appropriately file and render the
results.
For example, an Anatomic Pathology report where the result value may be sent as:
<value code=”414794006” codeSystem=”2.16.840.1.113883.6.1“ codeSystemName=”SNOMED”
displayName=”myeloproliferative disorder”/>
Figure 79: Example Anatomic Pathology Report Result value
Result Notes
As a consequence of the variability of data in healthcare and localization of lab result testing, some data
is commonly sent as part of the result notes. The Result Notes element is included to support the
communication of any unstructured information relevant to the interpretation of the result.
Test Procedure Coding
There are thousands of possible procedures that can be performed by laboratories. The coding systems
used to identify the procedure that is being ordered, and the procedure that was actually performed by the
laboratory is critical to being able to appropriately interpret the results received. Historically, many
laboratories used locally defined coding systems to identify procedures and variants or procedures (for
example based on method of testing). Internationally the LOINC (Logical Observation Identifiers Names
and Codes - http://loinc.org/) standard has been recognized to be used for this purpose. In Canada the
Standards Collaborative has created an Canadian implementation of the LOINC standard refered to as
pCLoCD (pan Canadian Laboratory Observation Code Database). The pCLOCD was created using the
LOINC records and attributes that specifically meet Canadian laboratory ordering and reporting
requirements. In conjunction with Regenstrief, the LOINC records have been translated to French. This
enables the pCLOCD to be published and maintained in both official languages. Currently, the pCLOCD
includes records that cover most laboratory domains and that pertain to laboratory testing on humans and
non-humans. It is being further developed to include Clinical terms that best suit the Electronic Health
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
288 DSTU (Revision 2013)
Record and Medication Management. (http://loinc.org/adopters/canada-health-infoway-inc-inforoute-
sante-du-canada-inc.html/)
The PITO Specification recommends the use of the pCLOCD codes to communicate the test procedure
code.
To support the consistent implementation of pCLOCD, the PITO Specification recommends the
evaluation fo the Saskatchewan Automated Mapping Assistant (SAMA). SAMA is designed to enable
mapping between regional/local LIS tests to the pCLOCD standard.
Table 102: Laboratory Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1026 @typeCode M:1..1
1027 templateId O:0..* II
1028 observation R:1..*
4352 @classCode M:1..1
4353 @moodCode M:1..1
1029 Order Record ID Unique and persistent identifier for the request or order.
id M:1..1 II
1030 Order Code Code identifying the laboratory test or procedure ordered.
code R:1..1 CD
1031 Order Name Name identifying the laboratory test or procedure ordered. If the Order Code is NullFlavor, this element SHALL contain a Name or Short Description of the ordered test or procedure as known by the source system.
text O:0..1 ED
1032 Ordering Provider Provider ordering the laboratory test or procedure. If the ID is unknown, a name alone may be sent.
author (Author
Participation)
O:0..*
1033 Relevant Clinical Information Additional clinical information about the patient or specimen.
entryRelationship
(Comment Observation)
O:0..*
1034 Result Organizer Grouper Code identifying whether the result observations comprise a Battery or a Cluster.
entryRelationship
(Result Organizer)
R:1..*
A Laboratory Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1026].
2) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1027] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.12"
[CONF:1027.12].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
289 DSTU (Revision 2013)
3) SHALL contain one or more (or a nullFlavor value) [1..*] observation [CONF:1028].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:4352].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:4353].
c) SHALL contain exactly one [1..1] id [CONF:1029].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} code [CONF:1030].
e) MAY contain zero or one [0..1] {CDAR2} text [CONF:1031].
f) MAY contain zero or more [0..*] {CDAR2} author [CONF:1032] such that each,
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1032.1].
g) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:1033] such that each,
i) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:1033.1].
h) SHALL contain one or more (or a nullFlavor value) [1..*] entryRelationship [CONF:1034]
such that each,
i) SHALL contain exactly one [1..1] Result Organizer
(2.16.840.1.113883.3.1818.10.4.26) [CONF:1034.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
290 DSTU (Revision 2013)
The following XML example outlines how to use the Laboratory Observation template:
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.2.16.1"/> <!-- Laboratory
Observation -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="18723-7" displayName="Hematology Studies"
codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
<text>Hematology Series</text>
<!-- Ordering Provider -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Provider
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Relevant Clinical Information -->
<entryRelationship typeCode="SUBJ">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment Observation
-->
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="ST">Relevant Clinical Information Comment is inserted
here</value>
</observation>
</entryRelationship>
<!-- Result Organizer -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.26"/> <!-- Result Organizer --
>
<organizer classCode="BATTERY" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.35"/>
<code code="57782-5" displayName="CBC w ordered manual differential"
codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
<statusCode code="final"/>
<component typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.25"/> <!-- Result Component
-->
<observation classCode="OBS" moodCode="EVN">
<id extension="123669" root="2.16.840.1.113883.3.1818.10.2.10.33"/>
<code code="6690-2" displayName="Leukocytes [#/volume] in Blood by
Automated count" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
<text>White Blood Count</text>
<statusCode code="final"/>
<effectiveTime value="20100127"/>
<value xsi:type="PQ" value="6.7" unit="10+3/ul"/>
<interpretationCode code="N" displayName="Normal"
codeSystem="2.16.840.1.113883.2.20.3.78" codeSystemName="ObservationInterpretation"/>
<!--Resulting Organization -->
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
291 DSTU (Revision 2013)
<performer typeCode="PRF">
<templateId root="2.16.840.1.113883.3.1818.10.4.19"/> <!--Performer
Participation-->
<time value="201111111111"/>
<assignedEntity>
<id extension="123" root="2.16.840.1.113883.3.40.2.11"
assigningAuthorityName="BCMOH"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>
<prefix>Mr.</prefix>
<family>Laboratory</family>
<given>Performer</given>
</name>
</assignedPerson>
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
<id extension="TBD" root="TBD"/>
<name>Performing Organization Name</name>
</representedOrganization>
</assignedEntity>
</performer>
<!--Specimen Collection Information -->
<entryRelationship typeCode="COMP">
<procedure classCode="PROC" moodCode="EVN">
<!-- specimen collection comments -->
<text>No problem with specimen collection</text>
<!-- specimen collection date -->
<effectiveTime value="20100126100311"/>
</procedure>
</entryRelationship>
<!-- Result Notes -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="ST">Result Note comment inserted heret</value>
</observation>
</entryRelationship>
<!-- Result Attachment or Reference -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.1"/> <!-- Attachment -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="ATTACH" displayName="Attachment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Keywords: Abnormal Laboratory Result Chicken-Pox Confirmed</text>
<effectiveTime value="20120202"/>
<value xsi:type="ST">Chicken Pox Alert</value>
<!-- Attachment Notes not included in this sample-->
<!-- Reviewed Dates not included in this sample-->
<!-- Attachment or Reference -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.9"/> <!-- Encapsulated
Data -->
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
292 DSTU (Revision 2013)
<observationMedia classCode="OBS" moodCode="EVN">
<id extension="127797" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<value mediaType="application/pdf">
<reference value="http://www.anywhere.com/folder1/20120202-Patient1-
claim1.pdf"/>
</value>
<!-- Attachment author not included in this sample -->
</observationMedia>
</entryRelationship>
</observation>
</entryRelationship>
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<code code="N" displayName="Normal"
codeSystem="2.16.840.1.113883.1.11.10206"
codeSystemName="ObservationInterpretationNormality"/>
<text>Normal Reference range is between 5 and 10</text>
<value xsi:type="IVL_REAL">
<low value="4.3"/>
<high value="10.8"/>
</value>
</observationRange>
<observationRange classCode="OBS" moodCode="EVN.CRT">
<code code="H" displayName="High"
codeSystem="2.16.840.1.113883.1.11.10206"
codeSystemName="ObservationInterpretationNormality"/>
<text>High Reference range is between 5 and 10</text>
<value xsi:type="IVL_REAL">
<low value="10.81"/>
<high value="15.4"/>
</value>
</observationRange>
<observationRange classCode="OBS" moodCode="EVN.CRT">
<code code="HH" displayName="Very High"
codeSystem="2.16.840.1.113883.1.11.10206"
codeSystemName="ObservationInterpretationNormality"/>
<text>Very High Reference range is between 5 and 10</text>
<value xsi:type="IVL_REAL">
<low value="15.41"/>
</value>
</observationRange>
</referenceRange>
</observation>
</component>
</organizer>
</entryRelationship>
</observation>
</entry>
Figure 80: Laboratory Observation entry example
6.14 MEDICAL IMAGING OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.3.13(open)]
Table 103: Medical Imaging Observation Template Context
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
293 DSTU (Revision 2013)
Directly Used by Template(s) Directly Contains Template(s)
Medical Imaging Results & Reports [with entries] Attachment
Author Participation
Reason Observation
The Medical Imaging Observation template defines the format for the results of observations generated
by imaging procedures. The scope includes observations such as plain x-ray, ultrasound, CT, MRI,
angiography, echocardiography and nuclear medicine observations. The section often includes notable
results such as abnormal values or relevant trends, and could contain all results for the period of time
being documented.
Imaging results are typically generated by a clinician reviewing the output of an imaging procedure, such
as where a cardiologist reports the left ventricular ejection fraction based on the review of a cardiac
echocardiogram.
The Image Procedure Code element is used to identify the specific procedure that was performed on the
patient. The PITO Specification does not recommend any specific Code System to be used for this
element.
If the source system does NOT contain a code for the procedure, then the Image Procedure Code
element SHALL be the NullFlavor ‘OTH’ and the Image Procedure Name element SHALL be
populated:
If the source system does contain a code for the procedure then the Image Procedure Code element
SHALL be populated with the code, codeSystem, codeSystemName and displayName.
The receiving system SHALL support receipt of coded imaging procedure results.
If the receiving system cannot process the codeSystem for the Image procedure Code, then the
receiving system SHALL capture the procedure as a free text entry and SHALL store the received code
information with the record.
Table 104: Medical Imaging Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1035 @typeCode M:1..1
1036 @contextConductionInd M:1..1
1037 templateId R:1..1 II
1038 observation O:0..*
1039 @classCode M:1..1
1040 @moodCode M:1..1
1041 Record ID Unique identifier for the procedure findings/interpretation/report.
id M:1..1 II
1042 Image Procedure Code code R:1..1 CD
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
294 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
Code identifying the imaging procedure being reported.
1043 Image Procedure Name Name identifying the imaging procedure being reported. If the Imaging Code is NullFlavor, this element SHALL contain a Name or Short Description of the procedure as known by the source system.
text R:0..1 ED
1044 Imaging Date The date that the medical imaging procedure was performed.
effectiveTime O:0..1 IVL_TS
1045 Indication or Reason for procedure Reason for the imaging diagnostic procedure(s). This may be represented in the following formats: • Link to the Problem List. • A code (e.g. SNOMED code of suspected problem) • A free text string.
entryRelationship
(Reason Observation)
O:0..*
1046 Imaging Attachments Any attached files. This includes any external document references and external imaging files.
entryRelationship
(Attachment)
O:0..*
1047 Image Detail Sections Documentation of the radiology procedure, findings, interpretation, and impression.
entryRelationship R:0..*
1048 @typeCode M:1..1
1049 observation O:0..*
1050 @classCode M:1..1
1051 @moodCode M:1..1
1052 Image Detail identifier id R:0..1 II
1053 Image Detail code Code identifying the Procedure / Finding / Interpretation detail section.
code R:1..1 CD
1054 Image Detail Coded Observations value R:0..1 ANY
1055 Image Detail Free Text Observation text R:0..1 ED
1056 Image Detail Observation Effective Time The effective date/time of the observation.
effectiveTime R:0..1 IVL_TS
1057 Image Detail Author author (Author
Participation)
R:0..1
A Medical Imaging Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1035].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1036].
3) SHALL contain exactly one (or a nullFlavor value) [1..1] templateId [CONF:1037] such that it,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.13"
[CONF:1037.12].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
295 DSTU (Revision 2013)
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1038].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1039].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1040].
c) SHALL contain exactly one [1..1] id [CONF:1041].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} code, which SHOULD be
selected from ValueSet ImagingProcedureObservationType 2.16.840.1.113883.3.3068.10.8.16 DYNAMIC [CONF:1042].
e) SHALL contain zero or one if available [0..1] text [CONF:1043].
f) MAY contain zero or one [0..1] {CDAR2} effectiveTime [CONF:1044].
g) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:1045] such that each,
i) SHALL contain exactly one [1..1] Reason Observation
(2.16.840.1.113883.3.1818.10.4.24) [CONF:1045.1].
h) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:1046] such that each,
i) SHALL contain exactly one [1..1] Attachment (2.16.840.1.113883.3.1818.10.4.1)
[CONF:1046.1].
i) SHALL contain zero or more if available [0..*] entryRelationship [CONF:1047].
i) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1048].
ii) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1049].
(1) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1050].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1051].
(3) SHALL contain zero or one if available [0..1] id [CONF:1052].
(4) SHALL contain exactly one (or a nullFlavor value) [1..1] code, which SHOULD be
selected from ValueSet ImagingDetailObservationType 2.16.840.1.113883.3.3068.10.8.15 DYNAMIC [CONF:1053].
(5) SHALL contain zero or one if available [0..1] value [CONF:1054].
(6) SHALL contain zero or one if available [0..1] text [CONF:1055].
(7) SHALL contain zero or one if available [0..1] effectiveTime [CONF:1056].
(8) SHALL contain zero or one if available [0..1] author [CONF:1057] such that it,
(a) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1057.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
296 DSTU (Revision 2013)
The following XML example outlines how to use the Medical Imaging Observation template:
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.13"/> <!-- Medical Imaging
Observation -->
<observation classCode="OBS" moodCode="EVN">
<id extension="123669" root="2.16.840.1.113883.3.1818.10.2.10.33"/>
<code code="10144323" displayName="Plain chest X-ray "
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT"/>
<text>Chest x-ray</text>
<effectiveTime value="20130211"/>
<!-- Indication or Reason for Procedure -->
<entryRelationship typeCode="RSON" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> <!-- Reason Observation-
->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="REASON" displayName="Reason Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Chest Pain</text>
<effectiveTime value="20130210"/>
<value xsi:type="CD" code="10144323"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT"
displayName="Patient findings pneumonia"/>
<!-- Reason Author not included in this sample -->
<!-- Reason Informant not included in this sample -->
</observation>
</entryRelationship>
<!-- Imaging Attachments -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.1"/> <!-- Attachment -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="ATTACH" displayName="Attachment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<text>Keywords: chest x-ray</text>
<effectiveTime value="20120202"/>
<value xsi:type="ST">Chest x-Ray image</value>
<!-- Attachment Notes not included in this sample-->
<!-- Reviewed Dates not included in this sample-->
<!-- Attachment or Reference -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.9"/> <!-- Encapsulated Data
with ID for renderMultiMedia above-->
<observationMedia classCode="OBS" moodCode="EVN" ID="M11">
<id extension="127797" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<value mediaType="application/png">
<reference value="http://www.anywhere.com/folder1/20120202-Patient1-
xray.png"/>
</value>
<!-- Attachment author not included in this sample -->
</observationMedia>
</entryRelationship>
</observation>
</entryRelationship>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
297 DSTU (Revision 2013)
<!-- Imagage Detail Sections -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="59776-5" displayName="Procedure Findings"
codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" />
<text>Nothing unusual could be observed.</text>
<effectiveTime value="20120211"/>
<value xsi:type="CD" code="272519000" displayName="Absense findings"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT" />
<!-- Image Detail Section Author -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38810" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. Raymond Xpert</name>
</assignedPerson>
</assignedAuthor>
</author>
</observation>
</entryRelationship>
</observation>
</entry>
Figure 81: Medical Imaging Observation entry example
6.15 MEDICATION EVENT
[Substance Administration: templateId 2.16.840.1.113883.3.1818.10.3.18(open)]
Table 105: Medication Event Template Context
Directly Used by Template(s) Directly Contains Template(s)
Current Medications [with entries] Comment Observation
Medications & Prescriptions - Medication List [with entries]
Date Observation
Medication Identification
Medication Prescription Event
Reaction Observation
Reason Observation
Unbound Observation
The Medication Event template defines the structure and format rules to enable the communication of
medications including current medications and medication history. The Medication Event template
includes references other templates to identify the drug and links to the medication detail and prescription
order as well as the dispensing and medication administration information.
This template references the Medication Prescription Event template that defines the structure for the
prescription including specific dosing and dispensing instructions.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
298 DSTU (Revision 2013)
The Medication List data element structure is complex as it needs to accommodate the five distinct use
cases identified in the Medications & Prescriptions - Medication List section. Consequently the section
has been divided into four primary Entry templates as follows:
Table 106: Medication Related Entry templates
Description
Medication Event These data elements identify the Medication List record and the Medication/Drug that is the subject of the list entry.
Prescription Event These data elements are related to the ordering or prescribing of the medication. This includes any instructions (for dispense or administration) that are made as part of the prescribing process.
Dispense Event These elements are those that describe the actual dispensing of the medication.
Administration Event These elements are those that describe the actual administration of the medication.
It is recognized that for a specific patient a medication is often prescribed repeatedly – for example in the
case of an on-going medication. The medication is represented as a single entry in Medication List;
however, there would be more than one prescription event record associated with that Medication List
entry. Similarly, a prescription may be dispensed multiple times; either because of refill instructions or due
to part-fill instructions. Finally, the dispense event may be associated with multiple administration events.
Obviously, if the patient is taking a tablet every day, each day could be considered an administration
event; however, this is not normally captured in the EMR and would not be reported. However, there are
situations where the administration is completed by a healthcare provider and the administration is
captured and should be reported. An example of this might include Synvisc treatments (injectable natural
product that is administered once a week for 3 weeks).
In addition to the above listed events, a medication record may be linked to a Allergy & Inolerance
Reaction Record, or a free text or coded reaction may be documented against the medication.
The medication record may also be linked to the Problem List to describe the indication(s) or reason(s) for
the Medication and the Reaction List to describe any reactions to the medication that the patient may
have experienced. Please refer to the Problems & Conditions and Allergies & Intolerances Discussion
Papers for more details on these sections.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
299 DSTU (Revision 2013)
The following diagram shows the relationship between the five sub-sections of the Medication List
Section:
Figure 82: Medication Model
Medication List Record
The Medication Event template includes the identification of the Medication List Record (i.e. the specific
record in the Medication List), and the specific drug or medication that is the subject of the record
including the strength of the Drug. This template is designed to be flexible to support the variability of
information available in the five identified use cases as well as the types of available coding systems.
The Medication Event template may be used to support medication list management and reconciliation. It
includes a Record Type to indicate if the medication is a long term (e.g. chronic, continuous or usual
medication) or short term; as well as a date of the last review of the medication. The sending system
may filter the medications sent based on the Record status (Active/Complete); the Type (Long term/short
term) depending on the requirements of the document (e.g. an episodic document).
The record may be also be communicated alone as a summary of the medications that the patient is or
has used without the detail or the prescription.
Record Status
The Record Status element distinguishes if the medication record is active or complete. The Record
Status is used to determine if the medication is current and should be included in the Current Medications
Section of a document and may be used to filter and sort medications within the EMR. This is also of
importance when using graphs to display various types of information when medication use is displayed.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
300 DSTU (Revision 2013)
If the Record Type is set to “Short Term”, then the Record Status may be automatically changed to
Completed when there are no longer active prescriptions. I.e. all prescriptions have an end date, or
duration that is complete.
If the Record Type is set to “Long Term”, then the Status should remain Active until manually changed to
Completed by the provider. Consequently, it is valid for a long term medication to be considered active,
and to appear on the current medications list, even if there are no active prescriptions.
Table 107: Medication Event Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1470 @typeCode M:1..1
1471 @contextConductionInd M:1..1
1472 templateId M:1..1 II
1473 Medication Record substanceAdministration O:0..*
1474 @classCode M:1..1
1475 @moodCode M:1..1
1476 Record ID A unique identifier for the medication record.
id M:1..1 II
1477 code M:1..1 CD
1478 Record Status The status of the Medication Record.
statusCode M:1..1 CS
1479 Record Type An indicator that identifies if this medication record is a “usual medication” (i.e. part of a usual medication list) or if it is short term (i.e. one-time / acute).
entryRelationship
(Unbound Observation)
R:1..1
1480 Last Review Date The date that the medication record was reviewed or reconciliation was conducted on this record. This supports the “best possible medication history”.
entryRelationship (Date
Observation)
R:0..1
1481 Reason / Indication The reasons or indications for the Medication Event.
entryRelationship
(Reason Observation)
R:0..*
1482 Reaction The reaction that that patient had to the medication.
entryRelationship
(Reaction Observation)
R:0..1
1483 Medication Record Comment Notes or comments that the EMR provider may capture related to the medication record. This may include notes regarding interactions with other drugs, allergies or conditions as well as notes during medication reconciliation.
entryRelationship
(Comment Observation)
R:0..1
1484 Drug Information The specific drug and drug strength that is the subject of the Medication List record.
consumable (Medication
Identification)
M:1..1
1485 Prescription Information The identification of the Prescription Event that may repeat for each prescription issued
entryRelationship
(Medication Prescription
R:0..*
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
301 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
for the Drug identified in the Medication List Record.
Event)
A Medication Event (Substance Administration) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1470].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1471].
3) SHALL contain exactly one [1..1] templateId [CONF:1472] such that it,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.18"
[CONF:1472.12].
4) MAY contain zero or more [0..*] {CDAR2} substanceAdministration [CONF:1473].
a) SHALL contain exactly one [1..1] @classCode="SBADM" substance administration (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1474].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1475].
c) SHALL contain exactly one [1..1] id [CONF:1476].
d) SHALL contain exactly one [1..1] code="DRUG" drug therapy (CodeSystem: ActCode
2.16.840.1.113883.5.4) [CONF:1477].
e) SHALL contain exactly one [1..1] statusCode, which SHALL be selected from ValueSet
x_ActStatusActiveComplete 2.16.840.1.113883.1.11.19890 STATIC [CONF:1478] such that it,
i) SHALL be constrained to either Active or Completed status codes [CONF:1478.34].
f) SHALL contain exactly one (or a nullFlavor value) [1..1] entryRelationship [CONF:1479]
such that it,
i) SHALL contain exactly one [1..1] Unbound Observation
(2.16.840.1.113883.3.1818.10.4.32) [CONF:1479.1].
g) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1480] such that it,
i) SHALL contain exactly one [1..1] Date Observation
(2.16.840.1.113883.3.1818.10.4.4) [CONF:1480.1].
h) SHALL contain zero or more if available [0..*] entryRelationship [CONF:1481] such that each,
i) SHALL contain exactly one [1..1] Reason Observation
(2.16.840.1.113883.3.1818.10.4.24) [CONF:1481.1].
i) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1482] such that it,
i) SHALL contain exactly one [1..1] Reaction Observation
(2.16.840.1.113883.3.1818.10.4.23) [CONF:1482.1].
j) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1483] such that it,
i) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:1483.1].
k) SHALL contain exactly one [1..1] consumable [CONF:1484] such that it,
i) SHALL contain exactly one [1..1] Medication Identification
(2.16.840.1.113883.3.1818.10.4.16) [CONF:1484.1].
l) SHALL contain zero or more if available [0..*] entryRelationship [CONF:1485] such that each,
i) SHALL contain exactly one [1..1] Medication Prescription Event
(2.16.840.1.113883.3.1818.10.4.20) [CONF:1485.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
302 DSTU (Revision 2013)
The following XML example outlines how to use the Medication Event template:
<!-- ASA simple example without prescription details -->
<templateId root="2.16.840.1.113883.3.1818.10.3.18" /> <!-- Medication Event -->
<entry typeCode="DRIV" contextConductionInd="true">
<substanceAdministration classCode="SBADM" moodCode="EVN">
<id extension="BC20120201RXA-1452388BN" root="2.16.840.1.113883.3.1818.10.10.3"/>
<code code="DRUG" displayName="Drug Therapy" codeSystem="2.16.840.1.113883.5.4"
codeSystemName="HL7 Act Code"/>
<statusCode code="active"/>
<!-- Medication -->
<consumable typeCode="CSM">
<templateId root="2.16.840.1.113883.3.1818.10.4.16"/> <!--Medication
Identification-->
<manufacturedProduct classCode="MANU">
<manufacturedLabeledDrug>
<code code="0101169013" displayName="ASA"
codeSystem="2.16.840.1.113883.5.1106" codeSystemName="hc-AIGN"/>
<name>Aspirin</name>
<e2e:desc>ASA; 81 mg tablet, one daily</e2e:desc>
<e2e:formCode code="TAB" displayName="tablet"
codeSystem="2.16.840.1.113883.19.5.3" codeSystemName="HL7 Orderable Drug Form"/>
<e2e:ingredient classCode="INGR">
<e2e:quantity value="81" unit="mg"/>
<e2e:ingredient classCode="MMAT" determinerCode="KIND">
<e2e:code code="TBD" displayName="Acetylsalicylic Acid"
codeSystem="2.16.840.1.113883.5.1106" codeSystemName="hc-AIGN"/>
<e2e:name>Acetylsalicylic Acid</e2e:name>
</e2e:ingredient>
</e2e:ingredient>
</manufacturedLabeledDrug>
</manufacturedProduct>
</consumable>
<!-- Record Type -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.32"/> <!--Unbounded Observation-
->
<observation classCode="OBS" moodCode="EVN">
<code code="UNBOUND" displayName="Unbound Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<text>Long Term</text>
</observation>
</entryRelationship>
<!-- Last Review Date -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.4"/> <!-- Date Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="DATEOBS" displayName="Date Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<effectiveTime value="20121220"/>
</observation>
</entryRelationship>
<!-- Reason -->
<entryRelationship typeCode="RSON" contextConductionInd="true">
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
303 DSTU (Revision 2013)
<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> <!-- Reason Observation -
->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="REASON" displayName="Reason Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Hypertension, Atrial fibrillation</text>
<effectiveTime value="20120201"/>
<value xsi:type="CD" code="426749004" displayName="Chronic atrial
fibrillation" codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-
CT" />
<!-- Author Participation -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/>
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
</observation>
</entryRelationship>
<!-- Reaction not included in this sample -->
<!-- Medication Record Comments -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment Observation --
>
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="ST">Patient is taking 2 asprins daily. </value>
</observation>
</entryRelationship>
</substanceAdministration>
</entry>
<!-- This is an example that tries to use all elements of the templates; but will not
make clinical sense -->
<!-- 6. Nitrospray 0.4 mg SL PRN -->
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.18" /> <!-- Medication Event -->
<substanceAdministration classCode="SBADM" moodCode="EVN">
<id extension="BC20120201RXA-1452388BN" root="2.16.840.1.113883.3.1818.10.10.3"/>
<code code="DRUG" displayName="Drug Therapy" codeSystem="2.16.840.1.113883.5.4"
codeSystemName="HL7 Act Code"/>
<statusCode code="active"/>
<!-- Medication -->
<consumable typeCode="CSM">
<templateId root="2.16.840.1.113883.3.1818.10.4.16"/> <!--Medication
Identification-->
<manufacturedProduct classCode="MANU">
<manufacturedLabeledDrug>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
304 DSTU (Revision 2013)
<code code="02243588" displayName="MYLAN-NITRO SUBLINGUAL SPRAY"
codeSystem="2.16.840.1.113883.5.1105" codeSystemName="hc-DIN"/>
<name>Nitrospray</name>
<e2e:desc>NITROGLYCERIN 0.4 mg/dose SPRAY, NON-AEROSOL (GRAM)</e2e:desc>
<e2e:formCode code="SPRAY" displayName="Spray"
codeSystem="2.16.840.1.113883.19.5.3" codeSystemName="HL7 Orderable Drug Form"/>
<e2e:ingredient classCode="INGR">
<e2e:quantity value="0.4" unit="mg"/>
<e2e:ingredient classCode="MMAT" determinerCode="KIND">
<e2e:code code="TBD" displayName="Nitro" codeSystem="tbd"
codeSystemName="ClinicalDrug"/>
<e2e:name> NITROGLYCERIN </e2e:name>
</e2e:ingredient>
</e2e:ingredient>
</manufacturedLabeledDrug>
</manufacturedProduct>
</consumable>
<!-- Record Type -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.32"/> <!--Unbounded Observation-
->
<observation classCode="OBS" moodCode="EVN">
<code code="UNBOUND" displayName="Unbound Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<text>Short Term</text>
</observation>
</entryRelationship>
<!-- Last Review Date -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.4"/> <!-- Date Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="DATEOBS" displayName="Date Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<effectiveTime value="20121220"/>
</observation>
</entryRelationship>
<!-- Reason -->
<entryRelationship typeCode="RSON" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> <!-- Reason Observation -
->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="REASON" displayName="Reason Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Coronary atherosclerosis</text>
<effectiveTime value="20120201"/>
<value xsi:type="CD" code="443502000" displayName="Coronary atherosclerosis"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT" />
<!-- Provider -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
305 DSTU (Revision 2013)
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
</observation>
</entryRelationship>
<!-- Reaction not included in this sample refer to other Reaction Observation
template examples-->
<!-- Medication Record Comments -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment Observation --
>
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="ST">Nurse to administer sub-lingualy as needed. </value>
</observation>
</entryRelationship>
<!-- Prescription Information -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.20" /> <!-- Medication
Prescription Event-->
<substanceAdministration classCode="SBADM" moodCode="RQO">
<id extension="BC20120201RXO-1458756BN"
root="2.16.840.1.113883.3.1818.10.10.3"/>
<code code="DRUG" codeSystem="2.16.840.1.113883.5.4" displayName="Drug
Therapy"/>
<!-- Start/Stop Date -->
<effectiveTime xsi:type="IVL_TS" operator="I">
<low value="20130211"/>
<high value="20130212"/>
</effectiveTime>
<consumable typeCode="CSM">
<templateId root="2.16.840.1.113883.3.1818.10.4.16"/> <!--Medication
Identification-->
<manufacturedProduct classCode="MANU">
<manufacturedLabeledDrug>
<code code="02243588" displayName="MYLAN-NITRO SUBLINGUAL
SPRAY" codeSystem="2.16.840.1.113883.5.1105" codeSystemName="hc-DIN"/>
<name>Nitrospray</name>
<e2e:desc>NITROGLYCERIN 0.4 mg/dose SPRAY, NON-AEROSOL
(GRAM)</e2e:desc>
<e2e:formCode code="SPRAY" displayName="Spray"
codeSystem="2.16.840.1.113883.19.5.3" codeSystemName="HL7 Orderable Drug Form"/>
<e2e:ingredient classCode="INGR">
<e2e:quantity value="0.4" unit="mg"/>
<e2e:ingredient classCode="MMAT"
determinerCode="KIND">
<e2e:code code="TBD" displayName="Nitro"
codeSystem="tbd" codeSystemName="ClinicalDrug"/>
<e2e:name> NITROGLYCERIN </e2e:name>
</e2e:ingredient>
</e2e:ingredient>
</manufacturedLabeledDrug>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
306 DSTU (Revision 2013)
</manufacturedProduct>
</consumable>
<!-- Prescribing Provider -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Dose Instructions -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.8"/> <!--Dose
Observation-->
<substanceAdministration classCode="SBADM" moodCode="RQO">
<!-- Duration -->
<text>Take 2 tablets for 10 days</text>
<!--Example 1: Using start and stop dates or start date and number
of time units-->
<effectiveTime xsi:type="IVL_TS" operator="I"><!-- 10 days -->
<width value="10" unit="D"/>
</effectiveTime>
<!-- Example 2: Duration from Jan 1 until Jan 10
<effectiveTime xsi:type="IVL_TS" operator="I">
<low value="20130101" inclusive="true"/>
<high value="20130110" inclusive="true"/>
</effectiveTime>
-->
<!-- Example 3: Specify medication administration frequency (e.g.
b.i.d)
<effectiveTime xsi:type="PIVL_TS" institutionSpecified="true">
<frequency>
<numerator value="2"/>
<denominator value="1" unit="d"/>
</frequency>
</effectiveTime>
-->
<!-- Example 4: Frequency every 2-4 hours
<effectiveTime xsi:type="PIVL_TS" institutionSpecified="true">
<period xsi:type="URG_PQ">
<low value="2" unit="h"/>
<high value="4" unit="h"/>
</period>
</effectiveTime>
-->
<routeCode code="PO" displayName="per os"
codeSystem="2.16.840.1.113883.5.112" codeSystemName="RouteOfAdministration"/>
<approachSiteCode code="M" displayName="Mouth"
codeSystem="2.16.840.1.113883.2.20.3.52"
codeSystemName="HumanSubstanceAdministrationSite"/>
<doseQuantity>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
307 DSTU (Revision 2013)
<center value="100" unit="mg"/>
</doseQuantity>
<!-- Form -->
<administrationUnitCode code="ORSPRAY" displayName="oral spray"
codeSystem="2.16.840.1.113883.1.11.14570" codeSystemName="AdministerableDrugForm"/>
<consumable typeCode="CSM">
<templateId root="2.16.840.1.113883.3.1818.10.4.16"/> <!--
Medication Identification-->
<manufacturedProduct classCode="MANU">
<manufacturedLabeledDrug>
<code code="02243588" displayName="MYLAN-NITRO
SUBLINGUAL SPRAY" codeSystem="2.16.840.1.113883.5.1105" codeSystemName="hc-DIN"/>
<name>Nitrospray</name>
<e2e:desc>NITROGLYCERIN 0.4 mg/dose SPRAY,
NON-AEROSOL (GRAM)</e2e:desc>
<e2e:formCode code="SPRAY" displayName="Spray"
codeSystem="2.16.840.1.113883.19.5.3" codeSystemName="HL7 Orderable Drug Form"/>
<e2e:ingredient classCode="INGR">
<e2e:quantity value="0.4" unit="mg"/>
<e2e:ingredient classCode="MMAT"
determinerCode="KIND">
<e2e:code code="TBD"
displayName="Nitro" codeSystem="tbd" codeSystemName="ClinicalDrug"/>
<e2e:name> NITROGLYCERIN
</e2e:name>
</e2e:ingredient>
</e2e:ingredient>
</manufacturedLabeledDrug>
</manufacturedProduct>
</consumable>
</substanceAdministration>
</entryRelationship>
<!-- Prior Prescription Record ID -->
<entryRelationship typeCode="SUBJ">
<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> <!-- Record ID
Link -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12779999"
root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<code code="RECLINK" displayName="Record Link Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
</observation>
</entryRelationship>
<!-- Stop Reason -->
<entryRelationship typeCode="RSON" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> <!-- Reason
Observation -->
<observation classCode="OBS" moodCode="EVN">
<id nullFlavor="NA"/>
<code code="REASON" displayName="Reason Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
308 DSTU (Revision 2013)
<text>Stop administration of spray if patient experiences problems
swollowing.</text>
<effectiveTime value="20120201"/>
<value xsi:type="CD" code="288936000" displayName="Able to swallow
(finding)" codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT"/>
</observation>
</entryRelationship>
<!-- PRN -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.37"/> <!-- Order
Indicator-->
<observation classCode="OBS" moodCode="EVN">
<code code="PRNIND" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="PRN Indicator"/>
<value xsi:type="BL" value="true"/>
</observation>
</entryRelationship>
<!-- Adapt Not Allowed Indicator -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.37"/> <!--Order
Indicator-->
<observation classCode="OBS" moodCode="EVN">
<code code="ADPIND" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Adapt Not Allowed
Indicator"/>
<value xsi:type="BL" value="false"/>
</observation>
</entryRelationship>
<!-- Substitute Not Allowed Indicator -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.37"/> <!--Order
Indicator-->
<observation classCode="OBS" moodCode="EVN">
<code code="SUBIND" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Substitute Not Allowed
Indicator"/>
<value xsi:type="BL" value="false"/>
</observation>
</entryRelationship>
<!-- Part Fill Dispense Instructions -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.14"/> <!--Dispense
Request (part fill)-->
<supply classCode="SPLY" moodCode="RQO">
<code code="FFP" codeSystem="2.16.840.1.113883.5.4"
displayName="Partial First Fill" codeSystemName="Hl7 Act Code"/>
<quantity value="10"/>
<expectedUseTime>
<width value="5" unit="d"/>
</expectedUseTime>
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.11"/> <!--
Medication Fill Interval -->
<observation classCode="OBS" moodCode="EVN">
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
309 DSTU (Revision 2013)
<code code="FILLINT"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" displayName="Fill Interval"/>
<text>5 per day</text>
<value xsi:type="PQ" value="5" unit="d"/>
</observation>
</entryRelationship>
</supply>
</entryRelationship>
<!-- First Dispense Instructions -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.14"/> <!-- Dispense
Request (first fill) -->
<supply classCode="SPLY" moodCode="RQO">
<code code="FF" codeSystem="2.16.840.1.113883.5.4"
displayName="Partial First Fill" codeSystemName="Hl7 Act Code"/>
<quantity value="10"/>
<expectedUseTime>
<width value="5" unit="d"/>
</expectedUseTime>
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.11"/> <!--
Medication Fill Interval -->
<observation classCode="OBS" moodCode="EVN">
<code code="FILLINT"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" displayName="Fill Interval"/>
<text>3 days</text>
<value xsi:type="PQ" value="3" unit="d"/>
</observation>
</entryRelationship>
</supply>
</entryRelationship>
<!-- Refill Dispense Instructions -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.34"/> <!--Dispense
Request (Refills)-->
<supply classCode="SPLY" moodCode="RQO">
<code code="RF" codeSystem="2.16.840.1.113883.5.4"
displayName="Refills" codeSystemName="Hl7 Act Code"/>
<repeatNumber value="1"/>
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.11"/> <!--
Medication Fill Interval -->
<observation classCode="OBS" moodCode="EVN">
<code code="FILLINT"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" displayName="Fill Interval"/>
<text>30 days</text>
<value xsi:type="PQ" value="30" unit="d"/>
</observation>
</entryRelationship>
</supply>
</entryRelationship>
<!-- Instructions to Pharmacist -->
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
310 DSTU (Revision 2013)
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.4.35"/> <!--
Instruction Observation-->
<code code="INSTRUCT" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Instructions"/>
<text>
Please review proper administration technique to the
patient and patient's daughter at time of dispense.
</text>
<participant typeCode="PRCP" contextControlCode="OP">
<participantRole classCode="PROV"/>
</participant>
</observation>
</entryRelationship>
<!-- Instructions to patient -->
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.4.35"/> <!--
Instruction Observation-->
<code code="INSTRUCT" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Instructions"/>
<text>
One spray every 5 minutes as needed for chest discomfort.
If pain continues for more than 15 minutes or recurs
frequently, get to emergency department ASAP.
</text>
<participant typeCode="PRCP" contextControlCode="OP">
<participantRole classCode="PAT"/>
</participant>
</observation>
</entryRelationship>
<!-- Dispense Record -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.7"/> <!--Dispense Event
-->
<supply classCode="SPLY" moodCode="EVN">
<id extension="BC20120201RXO-1458756BN"
root="2.16.840.1.113883.3.1818.10.10.3"/>
<!-- Dispense Date -->
<effectiveTime value="20130211"/>
<quantity value="1"/>
<!-- Dispensed Medication -->
<product typeCode="PRD">
<manufacturedProduct classCode="MANU">
<manufacturedLabeledDrug classCode="MMAT"
determinerCode="KIND">
<code code="02243588" displayName="MYLAN-NITRO
SUBLINGUAL SPRAY" codeSystem="2.16.840.1.113883.5.1105" codeSystemName="hcDIN"/>
</manufacturedLabeledDrug>
</manufacturedProduct>
</product>
<!--Dispensing Organization -->
<performer typeCode="PRF">
<templateId root="2.16.840.1.113883.3.1818.10.4.19"/> <!--
Performer Participation -->
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
311 DSTU (Revision 2013)
<time value="20130211"/>
<assignedEntity classCode="ASSIGNED">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<code code="180000000X" displayName="Pharmacy"
codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7 RoleCode" />
<assignedPerson classCode="PSN"
determinerCode="INSTANCE">
<name use="L">Mr. P. Scriber</name>
</assignedPerson>
<representedOrganization>
<name>Mainstreet Pharmacy</name>
</representedOrganization>
</assignedEntity>
</performer>
<!-- Fill Interval -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.11"/> <!--
Medication Fill Interval -->
<observation classCode="OBS" moodCode="EVN">
<code code="FILLINT"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" displayName="Fill Interval"/>
<text>30 days</text>
<value xsi:type="PQ" value="30" unit="d"/>
</observation>
</entryRelationship>
<!-- Administration Event -->
<entryRelationship typeCode="SAS" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.36"/> <!--
Medication Acministration Event -->
<substanceAdministration classCode="SBADM" moodCode="EVN">
<id extension="BC20120201RXO-1458756BN"
root="2.16.840.1.113883.3.1818.10.10.3"/>
<code code="DRUG" codeSystem="2.16.840.1.113883.5.4"
displayName="Drug Therapy"/>
<!-- Administered Date -->
<effectiveTime value="20130211"/>
<routeCode></routeCode>
<approachSiteCode></approachSiteCode>
<doseQuantity></doseQuantity>
<!-- Administred Product Information -->
<consumable typeCode="CSM">
<manufacturedProduct classCode="MANU">
<manufacturedMaterial classCode="MMAT"
determinerCode="KIND">
<lotNumberText>123</lotNumberText>
</manufacturedMaterial>
</manufacturedProduct>
</consumable>
<!-- Administration Provider -->
<author typeCode="AUT" contextControlCode="OP">
<templateId
root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author Participation -->
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
312 DSTU (Revision 2013)
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN"
determinerCode="INSTANCE">
<name>Mrs. Grace Nurse</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Administering Location -->
<participant typeCode="LOC" contextControlCode="OP">
<templateId
root="2.16.840.1.113883.3.1818.10.4.13"/> <!-- Location Participation -->
<participantRole classCode="SDLOC">
<playingEntity>
<name>Walk In Clinic</name>
</playingEntity>
</participantRole>
</participant>
<!-- Administration Comment -->
<entryRelationship typeCode="SUBJ"
contextConductionInd="true" inversionInd="true">
<templateId
root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT"
displayName="Comment Observation" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending"/>
<value xsi:type="ST">Hypotension due to
administration for ACS.</value>
</observation>
</entryRelationship>
</substanceAdministration>
</entryRelationship>
</supply>
</entryRelationship>
</substanceAdministration>
</entryRelationship>
</substanceAdministration>
</entry>”
Figure 83: Medication Event entry example
6.16 ORDER EVENT
[Observation: templateId 2.16.840.1.113883.3.1818.10.3.14(open)]
Table 108: Order Event Template Context
Directly Used by Template(s) Directly Contains Template(s)
Orders & Requests [with entries] Author Participation
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
313 DSTU (Revision 2013)
Directly Used by Template(s) Directly Contains Template(s)
Comment Observation
Outcome Observation
Performer Participation
Reason Observation
Result Organizer
The Order Event template defines the format for the orders placed by the users of the source system that
may or may not have results documented against them. Some orders are captured without an
expectation that a result or report will be received against it, in other cases an order may still be active
and the result not yet available.
Order Code
The coding system for Orders is not specified by the PITO specification. The possible coding that is
appropriate for the different types of orders is diverse and may be supported at different levels by the
receiver and sender. It is expected that if the order is coded when placed that code along with the coding
system, display name and original name will be communicated. If the source system does not have any
coding for the order, the Order Name data element will be used.
Order Date / Time
The Order Date/Time is a mandatory element and must be populated with a valid date with optional time
extension. Additionally, the Order Date may be a future date.
Order Type
Whilst it would be desirable for the Order Type to be coded, there is no identified coding system for this
element and input from stakeholders indicates that this is a free text field. Consequently, the PITO
specification will list this as a String text field; however, consistent coding is recommended as a future
enhancement.
Order Priority
The order priority order of importance regarding the expectation to be performed is as follows: Routine,
Expedite, Urgent, STAT. However, most EMR systems do not track order priority to this level of
granularity. Consequently the PITO specification only requires the support of Routine and Stat as coded
priorities; but allows for additional order priority codes to be supported as per the HL7 Order Priority code
set.
The Order Priority Note may be used to indicate further nuances of the priority, for example:
To indicate dependence between the completion of orders (order 1 before order #2);
To indicate timeframes for the order to be completed (within 3 weeks);
To indicate pre/post activity (must have renal function and contrast studies completed before MRI);;
and
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
314 DSTU (Revision 2013)
To indicate a critical deadline (order must be completed prior to surgery on January 1st).
Order Results / Outcome
The Order Results/Outcome Observation field allows for the documentation of the results or outcome of
the order, or attachment of a report to the order. If the sending system attaches results/reports to the
orders they may do so using this element. This element also allows the sending system to send result
records in a separate section of the document (e.g. Laboratory Results); and to link the result record to
the order record using the Record ID.
The receiving system is expected to be able to process the results of the order and to maintain the link
between the order and the associated results regardless of how they are stored within its architecture
Table 109: Order Event Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1058 @typeCode M:1..1
1059 @contextConductionInd M:1..1
1060 templateId R:1..1 II
1061 observation O:0..*
1062 @classCode M:1..1
1063 @moodCode M:1..1
1064 Record ID id M:1..1 II
1065 Order Code code R:1..1 CD
1066 Order Name / Type The title, name or short description of what the order is when it is not coded. For example, “Physiotherapy”. This may also be the type of the order (e.g. Medical Imaging).
text R:1..1 ED
1067 Order Date /Time The date (and time if available) that the order was placed or that the order is to be performed.
effectiveTime M:1..1 IVL_TS
1068 Order Status The status of the order (e.g. Complete).
statusCode R:0..1 CS
1069 Order Priority The order of the priority (e.g. STAT).
priorityCode R:0..1 CE
1070 Order Priority Notes A note or comment regarding the priority of the order.
entryRelationship R:0..1
1071 @typeCode M:1..1
1072 observation O:0..*
1073 @classCode M:1..1
1074 @moodCode M:1..1
1075 Order Priority Notes Code code M:1..1 CD
1076 Free Text order priority notes text R:1..1 ED
1077 Order Reason entryRelationship R:0..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
315 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
The Reason or indication for the Order. (Reason Observation)
1078 Order Comments Comments or supporting information relevant to the order.
entryRelationship
(Comment Observation)
R:0..1
1079 Ordering Provider The author of the order or ordering provider.
author (Author
Participation)
R:1..1
1080 Order Performer The identification of the person or organization that is expected to fulfill the order.
performer (Performer
Participation)
R:1..1
1081 Order Outcome The report, results or outcome of the order.
entryRelationship
(Outcome Observation)
R:0..1
1082 Order Result The report, results or outcome of the order.
entryRelationship
(Result Organizer)
R:0..1
An Order Event (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1058].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1059].
3) SHALL contain exactly one (or a nullFlavor value) [1..1] templateId [CONF:1060] such that it,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.14"
[CONF:1060.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1061].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1062].
b) SHALL contain exactly one [1..1] @moodCode="RQO" request (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1063].
c) SHALL contain exactly one [1..1] id [CONF:1064].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} code [CONF:1065].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] text [CONF:1066].
f) SHALL contain exactly one [1..1] effectiveTime [CONF:1067].
g) SHALL contain zero or one if available [0..1] statusCode, which SHALL be selected from
ValueSet ActStatus 2.16.840.1.113883.1.11.159331 STATIC {CDAR2} [CONF:1068].
h) SHALL contain zero or one if available [0..1] priorityCode [CONF:1069].
i) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1070].
i) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1071].
ii) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1072].
(1) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1073].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1074].
(3) SHALL contain exactly one [1..1] code="ORDPRYNT" Order Priority Note (CodeSystem:
ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1075].
(4) SHALL contain exactly one (or a nullFlavor value) [1..1] text [CONF:1076].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
316 DSTU (Revision 2013)
j) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1077] such that it,
i) SHALL contain exactly one [1..1] Reason Observation
(2.16.840.1.113883.3.1818.10.4.24) [CONF:1077.1].
k) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1078] such that it,
i) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:1078.1].
l) SHALL contain exactly one (or a nullFlavor value) [1..1] author [CONF:1079] such that it,
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1079.1].
m) SHALL contain exactly one (or a nullFlavor value) [1..1] performer [CONF:1080] such that it,
i) SHALL contain exactly one [1..1] Performer Participation
(2.16.840.1.113883.3.1818.10.4.19) [CONF:1080.1].
n) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1081] such that it,
i) SHALL contain exactly one [1..1] Outcome Observation
(2.16.840.1.113883.3.1818.10.4.18) [CONF:1081.1].
o) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1082] such that it,
i) SHALL contain exactly one [1..1] Result Organizer
(2.16.840.1.113883.3.1818.10.4.26) [CONF:1082.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
317 DSTU (Revision 2013)
The following XML example outlines how to use the Order Event template:
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.14"/> <!-- Order Event -->
<observation classCode="OBS" moodCode="EVN">
<id extension="123669" root="2.16.840.1.113883.3.1818.10.2.10.31"/>
<code code="50687007" displayName="Digestive tract consultation and report "
codeSystem="2.16.840.1.113883.6.69" codeSystemName="SNOMED-CT"/>
<text>GI Consult</text>
<statusCode code="new"/>
<effectiveTime value="20130218"/>
<priorityCode code="Routine"/>
<!-- Order Performer -->
<performer typeCode="PRF">
<templateId root="2.16.840.1.113883.3.1818.10.4.19"/> <!--Performer
Participation-->
<time value="201111111111"/>
<assignedEntity>
<id extension="123" root="2.16.840.1.113883.3.40.2.11"
assigningAuthorityName="BCMOH"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>
<prefix>Dr.</prefix>
<family>G.</family>
<given>Astro</given>
</name>
</assignedPerson>
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
<id extension="TBD" root="TBD"/>
<name>Performing Organization Name</name>
</representedOrganization>
</assignedEntity>
</performer>
<!-- Diagnosing Provider -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author Participation
-->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Order Priority Notes -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<code code="ORDPRYNT" displayName="Order Priority Note"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Routine screening should be scheduled before March 15th to allow for
results prior to next GP appointment. </text>
</observation>
</entryRelationship>
<!-- Order Reason -->
<entryRelationship typeCode="RSON" contextConductionInd="true">
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
318 DSTU (Revision 2013)
<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> <!-- Reason Observation
-->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="REASON" displayName="Reason Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Screening colonoscopy. Family history of cancer of colon, 312824007,
SNOMED CT</text>
<effectiveTime value="20120201"/>
<value xsi:type="CD" code="312824007" displayName="Family history of cancer
of colon" codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT" />
</observation>
</entryRelationship>
<!-- Order Comments -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment Observation
-->
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="ST">You have seen this lady 5 years ago. She had clear
colonoscopy then. Due again.</value>
</observation>
</entryRelationship>
<!-- Outcome Observation -->
<!-- Outcomes not available for this order as it is a future order; refer to
Investigative Procedures Sections for examples of outcomes -->
<!-- Result Organizer -->
<!-- Results not available for this order as it is a future order; refer to
Laboratory or Medical Imaging Sections for examples of Results -->
</observation>
</entry>
Figure 84: Order Event entry example
6.17 PROBLEM LIST OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.3.15(open)]
Table 110: Problem List Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Medical History [with entries] Author Participation
Problems & Conditions - Problem List [with entries] Comment Observation
Date Observation
Lifestage Observation
Secondary Code (ICD-9)
Unbound Observation
The Problem List Observation template defines the format for an unstructured list of problems that a
clinician has noted in the patient’s chart.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
319 DSTU (Revision 2013)
Problem Type
An entry in the Problem List may be categorized by Problem Types (e.g. diagnosis, findings, functional
limitations etc.) The Problem Type is specified in the <code> element using a sub-set of SNOMED CT®
values. If the source EMR does not support problem observation types, then a nullFlavor of “NI” should
be sent in the <code> element. If the destination EMR does not support problem observation types, then
it should capture the problem type as a text.
Diagnosis Coding
While it is recognized that the ICD9 is predominantly used to code diagnoses for billing purposes, this
code is generally accepted as a billing or administrative code rather than a coding that has clinical value.
Where coding for clinical purposes; SNOMED CT® is the coding system of choice identified by both the
Clinician Panel and the consensus of standards setting organizations, other specifications and the pan-
Canadian Standards Collaborative. Vendors participating in the initial design have also confirmed a
capability with their EMRs to support SNOMED CT® for clinical coding of diagnoses.
As a result these specification separate the coding of a diagnosis for billing/administrative purposes from
the coding for clinical purposes into two separate elements.
Diagnosis Code will be used exclusively for clinical codification of the diagnosis. The only supported
coding system for this element in the specification will be SNOMED CT®.
Diagnosis ICD-9 Classification Code will be used exclusively for administrative codification of the
diagnosis. The only supported coding system for this element in the specification will be ICD-9.
Diagnosis Text <text> SHALL be populated when neither the Diagnosis Code <value> nor the
Diagnosis ICD-9 Classification Code are provided and SHALL be used to identify the diagnosis as a
free-text diagnosis.
The Diagnosis Text MAY also be populated when the diagnosis is coded and the source system
captures a free text diagnosis name in addition to the <displayName> associated with the <code>
in the <codeSystem>.
The cardinality of all three fields is R:1..1 indicating that if the information is available in the source
system, then it SHALL be populated. For example:
If the diagnosis is coded in SNOMED (or a reliable mapping is deemed to exist), then Diagnosis Code
is required to be populated; otherwise a NullFlavor of “UNK” (Unknown) SHALL be sent.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
320 DSTU (Revision 2013)
<value xsi:type="CD" code="59621000" displayName="Essential hypertension"
codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT" />
or
<value xsi:type="CD" NullFlavor="UNK"/>
Figure 85: Example “SNOMED CT® Diagnosis”
If the diagnosis is coded in ICD-9 (or a reliable mapping is deemed to exist), then Diagnosis ICD-9
Classification Code is required to be populated; otherwise a NullFlavor of “UNK” (Unknown) SHALL
be sent.
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.28"/>
<observation classCode="OBS" moodCode="EVN">
<code code="BILLINGCODE" displayName="Billing Code"
codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending"/>
<value xsi:type="CD" code="401" codeSystem="2.16.840.1.113883.6.42"
codeSystemName="ICD9" displayName="Bacterial Infection"/>
</observation>
</entryRelationship>
Or
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.28"/>
<observation classCode="OBS" moodCode="EVN">
<code code="BILLINGCODE" displayName="Billing Code"
codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending"/>
<value xsi:type="CD" nullFlavor="UNK"/>
</observation>
</entryRelationship>
Figure 86: Example “ICD9 Diagnosis”
If the diagnosis is coded in a code system other than SNOMED or ICD-9, Diagnosis code SHALL be
populated with a NullFlavor of “OTH” (Other) and the code and code system SHALL be sent in the
<translation> element.
<value xsi:type="CD" nullFlavor="OTH">
<translation code="K86" displayName="Hypertension Uncomplicated"
codeSystem="2.16.840.1.113883.6.139.1" codeSystemName="icpc2E-ENG"/>
</value>
Figure 87: Example “Other Coding System Diagnosis”
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
321 DSTU (Revision 2013)
Diagnosis Modifier / Observation
The use of modifiers such as laterality, stages and severity are often seen in EMRs and the importance of
these modifiers is increasing. The Diagnosis Modifier / Observation element is used to capture and
communicate various subtleties regarding the diagnosis. This may include the laterality anatomy or
location of the diagnosis; stages of diagnosis; severity, etc. Examples of use of the Diagnosis Modifier
include:
In the case of breast cancer, coding regarding therapeutic implications, it is necessary to capture
issues such as TNM staging, Estrogen receptor status and Her-2/Neu status. "Cancer metastatic to
bone", "Estrogen receptor positive tumor" and "Her-2 Positive tumor" are modifiers that need to be
attached to breast cancer diagnosis. ER+ tumors need hormone blockers; Her-2+ tumors need
Herceptin.
Documenting the severity of the diagnosis will require different coding systems based on the
diagnosis. For example,
severity of heart failure would use the New York Heart Association code system;
Severity of frailty would use the Canadian Study of Health and Aging code system.
The Diagnosis Modifier Observation allows the discrete communication of this information so that it can
be presented in a fashion that makes sense to a clinician rather than having four related terms on
different lines of a very long problem list.
Diagnosing Provider
The Diagnosing provider is required to be populated if captured by the source system. If it is not
populated, the receiving system SHOULD NOT assume that the author of the diagnosis record is the
Diagnosing Provider.
Problem Status
The Problem Status SHALL be Active or Complete.
There was some consideration given to extending the Problem Status element to support concepts such
as confirmed, tentative, excluded, under consideration, refuted, and deleted. However, after further
analysis, the recommendation is to limit the values of the Problem Status to Active/Inactive and that these
other concepts may be captured as an encounter note or as a Diagnosis Modifier.
Outcome Code
There was some consideration given regarding extending the Outcome Code to include concepts such as
Worse, Deterioration and No Change. However, after further analysis, the recommendation is to not
include these in the Outcome Code element and recommend that these concepts be captured as an
encounter note as they may change over time.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
322 DSTU (Revision 2013)
The problem with worse or deterioration is it’s stating a point in time that isn’t necessarily always true at
another point in time when you’re dealing with a different problem. For example, depression recorded
under psychiatric. The person is worst at one visit, it’s recorded that way. The next time they’re coming in
they’re dealing with their hip fracture. 6 months later the depression is gone, but it’s still labeled as
worst/deterioration.
Table 111: Problem List Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1083 @typeCode M:1..1
1084 @contextConductionInd M:1..1
1085 templateId O:0..* II
1086 Problem List Observation observation O:0..*
1087 Record ID The internal identifier of the Problem/Condition record. This ID allows the linking of problems/conditions to each other as well as to other elements in the patient’s chart (e.g. prescriptions).
id O:0..* II
1088 Problem Type This element identifies the category of problem being reported. If a problem type is not known, a nullFlavor of “NI” should be sent.
code R:1..1 CD
1089 Onset Date/Date Resolved Onset and resolved date/time.
effectiveTime R:0..1 IVL_TS
1090 Diagnosis Code The SNOMED code associated with the Diagnosis/Problem.
value R:1..1 CD
4354 Diagnosis Text The free-text diagnosis when the Diagnosis Code nor the Diagnosis Billing Code is available; may also be populated when the diagnosis is coded if the source system captures a free text diagnosis name in addition to the <displayName> associated with the <code> in the <codeSystem>.
text R:0..1 ED
1091 Problem Status The status of the Problem.
statusCode R:0..1 CS
1092 Diagnosing Provider (id) Identity of the provider responsible for the diagnosis.
author (Author
Participation)
M:1..1
1093 Diagnosis ICD9 Classification Code The ICD-9 billing code associated with the Diagnosis/Problem.
entryRelationship
(Secondary Code (ICD-9))
R:1..1
1094 Diagnosis Date Date (and time if avilable) that the diagnosis of the problem was made.
entryRelationship (Date
Observation)
O:0..*
1095 Diagnosis Note Free text notes relevant to the diagnosis as well as the identification of the provider responsible for the note.
entryRelationship
(Comment Observation)
O:0..*
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
323 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1096 Symptoms Coded or free text list of symptoms as documented by the provider.
entryRelationship O:0..*
4355 @typeCode M:1..1
4356 observation O:0..*
4357 @classCode M:1..1
4358 @moodCode M:1..1
4359 Symptom Observation Code code M:1..1 CD
4360 Symptom Value value M:1..1 ANY
1097 Diagnosis Modifier Observations attached to the diagnosis that may modify the diagnosis. Examples include laterality, anatomical location, stages or severity.
entryRelationship
(Unbound Observation)
R:0..*
1098 Lifestage at onset The lifestage of the patient at the time of onset of the diagnosis.
entryRelationship
(Lifestage Observation)
O:0..1
1099 Problem Outcome The coded outcome of the effect that the diagnosed disease has on the patient.
entryRelationship O:0..1
1100 @typeCode M:1..1
1101 observation O:0..*
1102 @classCode M:1..1
1103 @moodCode M:1..1
1104 Outcome Observation Code code M:1..1 CD
1105 Coded Outcome value value M:1..1 CD
A Problem List Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1083].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1084].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1085] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.15"
[CONF:1085.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1086].
a) MAY contain zero or more [0..*] {CDAR2} id [CONF:1087].
b) SHALL contain exactly one (or a nullFlavor value) [1..1] code, which SHALL be selected from
ValueSet ProblemType 2.16.840.1.113883.3.88.12.3221.7.2 STATIC [CONF:1088].
c) SHALL contain zero or one if available [0..1] effectiveTime [CONF:1089] such that it,
i) SHALL contain exactly one [1..1] low value to indicate the Start Date/Time and MAY contain
zero or one [0..1] high values to indicate the End Date/Time [CONF:1089.50].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] value, which SHALL be selected from
ValueSet DiagnosisValuePrimary 2.16.840.1.113883.2.20.3.40 DYNAMIC [CONF:1090].
e) SHALL contain zero or one if available [0..1] text [CONF:4354] such that it,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
324 DSTU (Revision 2013)
i) SHALL be populated when neither the Diagnosis Code code nor the Diagnosis ICD9
Classification Code are provided and SHALL be used to identify the diagnosis as a free-text diagnosis; MAY be included when the diagnosis is coded if the sending system captures a free text diagnosis name in addition to the displayName associated with the code
[CONF:4354.43].
f) SHALL contain zero or one if available [0..1] statusCode, which SHALL be selected from
ValueSet x_ActStatusActiveComplete 2.16.840.1.113883.1.11.19890 STATIC [CONF:1091] such that it,
i) SHALL be constrained to either Active or Completed status codes [CONF:1091.34].
g) SHALL contain exactly one [1..1] author [CONF:1092] such that it,
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1092.1].
h) SHALL contain exactly one (or a nullFlavor value) [1..1] entryRelationship [CONF:1093]
such that it,
i) SHALL contain exactly one [1..1] Secondary Code (ICD-9)
(2.16.840.1.113883.3.1818.10.4.28) [CONF:1093.1].
i) MAY contain zero or more [0..*] entryRelationship [CONF:1094] such that each,
i) SHALL contain exactly one [1..1] Date Observation
(2.16.840.1.113883.3.1818.10.4.4) [CONF:1094.1].
j) MAY contain zero or more [0..*] entryRelationship [CONF:1095] such that each,
i) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:1095.1].
k) MAY contain zero or more [0..*] entryRelationship [CONF:1096].
i) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:4355].
ii) MAY contain zero or more [0..*] {CDAR2} observation [CONF:4356].
(1) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:4357].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:4358].
(3) SHALL contain exactly one [1..1] code="SYMPTOMOBS" (CodeSystem: ObservationType-
CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:4359].
(4) SHALL contain exactly one [1..1] value [CONF:4360].
l) SHALL contain zero or more if available [0..*] entryRelationship [CONF:1097] such that each,
i) SHALL contain exactly one [1..1] Unbound Observation
(2.16.840.1.113883.3.1818.10.4.32) [CONF:1097.1].
m) MAY contain zero or one [0..1] entryRelationship [CONF:1098] such that it,
i) SHALL contain exactly one [1..1] Lifestage Observation
(2.16.840.1.113883.3.1818.10.4.12) [CONF:1098.1].
n) MAY contain zero or one [0..1] entryRelationship [CONF:1099].
i) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1100].
ii) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1101].
(1) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1102].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1103].
(3) SHALL contain exactly one [1..1] code [CONF:1104].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
325 DSTU (Revision 2013)
(4) SHALL contain exactly one [1..1] value [CONF:1105].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
326 DSTU (Revision 2013)
The following XML example outlines how to use the Problem List Observation template:
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.15"/> <!-- Problem List
Observation -->
<observation classCode="OBS" moodCode="EVN">
<id extension="123669" root="2.16.840.1.113883.3.1818.10.2.10.31"/>
<code code="ASSERTION" displayName="Assertion"
codeSystem="2.16.840.1.113883.5.4" codeSystemName="HL7 ActCode"/>
<text>Patient has ongoing history of hypertension that has been medicated and
under observation.</text>
<statusCode code="active"/>
<effectiveTime xsi:type="IVL_TS">
<low value="20010814"/>
</effectiveTime>
<value xsi:type="CD" code="59621000" displayName="Essential hypertension"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT" />
<!-- Diagnosing Provider -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author Participation
-->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Diagnosis Billing Code -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.28"/> <!-- Secondary Code
(ICD9) -->
<observation classCode="OBS" moodCode="EVN">
<code code="BILLINGCODE" displayName="Billing Code"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="CD" code="401" codeSystem="2.16.840.1.113883.6.42"
codeSystemName="ICD9" displayName="Bacterial Infection"/>
</observation>
</entryRelationship>
<!-- Diagnosis Date -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.4"/> <!-- Date Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="DATEOBS" displayName="Date Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<effectiveTime value="20010815"/>
</observation>
</entryRelationship>
<!-- Diagnosis Note-->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment Observation
-->
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
327 DSTU (Revision 2013)
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="ST">BP generally a bit high despite meds.</value>
</observation>
</entryRelationship>
<!-- Symptoms -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<code code="SYMPTOMOBS" displayName="Symptom Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="ST">Systolic BP high</value>
</observation>
</entryRelationship>
<!-- Diagnosis Modifier -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.32"/> <!-- Unbound Observation
-->
<observation classCode="OBS" moodCode="EVN">
<code code="UNBOUND" displayName="Unbound Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="ST">Moderate severity</value>
</observation>
</entryRelationship>
<!-- Lifestage Observation -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.12"/> <!-- Lifestage
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="LIFEOBS" displayName="Lifestage Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="CD" code="133936004" displayName="Adult"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT"/>
</observation>
</entryRelationship>
<!--Outcome Code-->
<entryRelationship typeCode="CAUS">
<observation classCode="OBS" moodCode="EVN">
<code code="OUTCOME" displayName="Outcome Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="CD" code="03" displayName="Patient Convalescing"
codeSystem="2.16.840.1.113883.3.3068.10.6.1" codeSystemName="TCoPD Outcome Codes" />
</observation>
</entryRelationship>
</observation>
</entry>
Figure 88: Problem List Observation entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
328 DSTU (Revision 2013)
6.18 REPRODUCTIVE OBSERVATIONS ORGANIZER
[Organizer: templateId 2.16.840.1.113883.3.1818.10.3.16(open)]
Table 112: Reproductive Observations Organizer Template Context
Directly Used by Template(s) Directly Contains Template(s)
Reproductive Observations [with entries] Author Participation
Informant Participation
The Reproductive Observations Organizer template is used to group reproductive observations that the
provider may have documented on the patient. The organizer template enables the grouping of the
observations based on a record identifier, a code indicating the type of observations (e.g. pregnancy),
status, author and informant. Individual observations are grouped within the Organizer element.
Table 113: Reproductive Observations Organizer Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1178 @typeCode M:1..1
1179 @contextConductionInd M:1..1
1180 templateId R:1..1 II
1181 organizer O:0..*
1182 @classCode M:1..1
1183 @moodCode M:1..1
1184 Organizer Id Unique and persistent identifier for the group of observations.
id R:0..1 II
1185 Organizer Code Code identifying the group of observations being reported.
code R:1..1 CD
1186 Organizer Status The overall status of the group of observations. Active shall be sent to indicate non-Final status, while Complete is used to indicate either a Final or Corrected group of observations.
statusCode R:1..1 CS
1187 Observation Author The author of the observation. If the author is unknown or unavailable this element MAY contain a NullFlavor.
author (Author
Participation)
R:0..1
1188 Observation Informant The informant of the observation.
informant (Informant
Participation)
O:0..*
1189 Component Observation component R:1..*
1190 @typeCode M:1..1
1191 @contextConductionInd M:1..1
1192 observation O:0..*
1193 @classCode M:1..1
1194 @moodCode M:1..1
1195 Individual Observation Identifier id R:1..1 II
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
329 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
Unique and persistent identifier for the observation record.
1196 Observation Code Code identifying the individual observation being communicated.
code R:1..1 CD
1197 Observation Name The title, name or short description of what the observation is when it is not coded. For example, “Additional clinical notations”. This is Required if the Observation Code is not populated or not drawn from the PITO recognized codes.
text R:0..1 ED
1198 Observation Date/Time Date (and optional time) that the observation made or recorded.
effectiveTime R:0..1 IVL_TS
1199 Observation Value The observation value. This element’s structure will depend on the type of observation as identified by the Observation Code or Observation Title.
value R:1..* ANY
1200 Interpretation Code When appropriate, the code indicating the interpretation of the results; also known as the Abnormal flag.
interpretationCode O:0..* CE
1201 Method Code When appropriate, the method by which the observation was made.
methodCode O:0..* CE
A Reproductive Observations Organizer (Organizer) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1178].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1179].
3) SHALL contain exactly one (or a nullFlavor value) [1..1] templateId [CONF:1180] such that it,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.16"
[CONF:1180.12].
4) MAY contain zero or more [0..*] {CDAR2} organizer [CONF:1181].
a) SHALL contain exactly one [1..1] @classCode="CLUSTER" cluster (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1182].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1183].
c) SHALL contain zero or one if available [0..1] id [CONF:1184].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] code, which SHOULD be selected from
ValueSet Reproductive Observations Organizer Codes 2.16.840.1.113883.3.1818.10.8.10 STATIC [CONF:1185].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] statusCode, which SHALL be
selected from ValueSet x_ActStatusActiveComplete 2.16.840.1.113883.1.11.19890 STATIC [CONF:1186].
f) SHALL contain zero or one if available [0..1] author [CONF:1187] such that it,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
330 DSTU (Revision 2013)
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1187.1].
g) MAY contain zero or more [0..*] {CDAR2} informant [CONF:1188] such that each,
i) SHALL contain exactly one [1..1] Informant Participation
(2.16.840.1.113883.3.1818.10.4.10) [CONF:1188.1].
h) SHALL contain one or more (or a nullFlavor value) [1..*] component [CONF:1189].
i) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1190].
ii) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1191].
iii) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1192].
(1) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1193].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1194].
(3) SHALL contain exactly one (or a nullFlavor value) [1..1] id [CONF:1195].
(4) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} code, which SHALL be
selected from ValueSet Reproductive Observations Codes 2.16.840.1.113883.3.1818.10.8.7 STATIC [CONF:1196].
(5) SHALL contain zero or one if available [0..1] text [CONF:1197].
(6) SHALL contain zero or one if available [0..1] effectiveTime [CONF:1198] such that it,
(a) MAY be a partial date conforming to the TS data type constraints [CONF:1198.62].
(7) SHALL contain one or more (or a nullFlavor value) [1..*] value [CONF:1199].
(8) MAY contain zero or more [0..*] {CDAR2} interpretationCode, which SHALL be
selected from ValueSet ObservationInterpretation 2.16.840.1.113883.2.20.3.78 STATIC [CONF:1200].
(9) MAY contain zero or more [0..*] {CDAR2} methodCode, which SHOULD be selected from
ValueSet ObservationMethod 2.16.840.1.113883.1.11.14079 DYNAMIC [CONF:1201].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
331 DSTU (Revision 2013)
The following XML example outlines how to use the Reproductive Observations Organizer template:
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.16"/> <!-- Reproductive
Observations Organizer -->
<organizer classCode="CLUSTER" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="267013003" displayName="Past pregnancy outcome"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT"/>
<statusCode code="final"/>
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author Participation
-->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Observation Informant -->
<informant typeCode="INF" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.10"/> <!-- Informant
Participation -->
<assignedEntity classCode="ASSIGNED">
<id nullFlavor="NA"/>
<assignedPerson>
<name>Mrs. Everybody</name>
</assignedPerson>
</assignedEntity>
</informant>
<component typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<id nullFlavor="NA"/>
<code code="11996-6" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="Gravida"/>
<text>Gravida</text>
<value xsi:type="INT" value="5"/>
</observation>
</component>
<component typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<id nullFlavor="NA"/>
<code code="11639-2" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="Term"/>
<text>Term</text>
<value xsi:type="INT" value="3"/>
</observation>
</component>
<component typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<id nullFlavor="NA"/>
<code code="11637-6" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="Preterm"/>
<text>Preterm</text>
<value xsi:type="INT" value="1"/>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
332 DSTU (Revision 2013)
</observation>
</component>
<component typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<id nullFlavor="NA"/>
<code code="11614-5" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="Spontaneous Abortions"/>
<text>Spontaneous Abortions</text>
<value xsi:type="INT" value="1"/>
</observation>
</component>
<component typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<id nullFlavor="NA"/>
<code code="11613-7" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="Induced Termination"/>
<text>Induced Termination</text>
<value xsi:type="INT" value="0"/>
</observation>
</component>
<component typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<id nullFlavor="NA"/>
<code code="11638-4" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="Births still living"/>
<text>Births still living</text>
<value xsi:type="INT" value="4"/>
</observation>
</component>
<component typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<id nullFlavor="NA"/>
<code code="11955-2" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC" displayName="Last Menstrual Period"/>
<text>Last Menstrual Period</text>
<value xsi:type="TS" value="20000210"/>
</observation>
</component>
</organizer>
</entry>
Figure 89: Reproductive Observations Organizer entry example
6.19 RISK FACTORS ORGANIZER
[Organizer: templateId 2.16.840.1.113883.3.1818.10.3.17(open)]
Table 114: Risk Factors Organizer Template Context
Directly Used by Template(s) Directly Contains Template(s)
Risk Factors [with entries] Author Participation
Informant Participation
The Risk Factors Organizer template is used to group risk factor observations that the provider may have
documented on the patient. The organizer template enables the grouping of the observations based on a
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
333 DSTU (Revision 2013)
record identifier, a code indicating the type of observations (e.g. social risks), status, author and
informant. Individual observations are grouped within the Organizer element.
Table 115: Risk Factors Organizer Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1106 @typeCode M:1..1
1107 @contextConductionInd M:1..1
1108 templateId R:1..1 II
1109 organizer O:0..*
1110 @classCode M:1..1
1111 @moodCode M:1..1
1112 Organizer Id Unique and persistent identifier for the group of observations.
id R:0..1 II
1113 Organizer Code Code identifying the group of observations being reported.
code R:1..1 CD
1114 Organizer Status The overall status of the group of observations. Active shall be sent to indicate non-Final status, while Complete is used to indicate either a Final or Corrected group of observations.
statusCode R:1..1 CS
1115 Observation Author The author of the observation. If the author is unknown or unavailable this element MAY contain a NullFlavor.
author (Author
Participation)
R:0..1
1116 Observation Informant The informant of the observation.
informant (Informant
Participation)
O:0..*
1117 Component Observation component R:1..*
1118 @typeCode M:1..1
1119 @contextConductionInd M:1..1
1120 observation O:0..*
1121 @classCode M:1..1
1122 @moodCode M:1..1
1123 Individual Observation Identifier Unique and persistent identifier for the observation record.
id R:1..1 II
1124 Risk Factors Observation code Code identifying the individual observation being communicated.
code R:1..1 CD
1125 Observation Name The title, name or short description of what the observation is when it is not coded. For example, “Additional clinical notations”. This is Required if the Observation Code is not populated or not drawn from the PITO recognized codes.
text R:0..1 ED
1126 Observation Date/Time Date (and optional time) that the observation
effectiveTime R:0..1 IVL_TS
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
334 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
made or recorded.
1127 Risk Factors Observation value The observation value. This element’s structure will depend on the type of observation as identified by the Observation Code or Observation Title.
value R:1..* ANY
1128 Interpretation Code When appropriate, the code indicating the interpretation of the results; also known as the Abnormal flag.
interpretationCode O:0..* CE
1129 Method Code When appropriate, the method by which the observation was made.
methodCode O:0..* CE
A Risk Factors Organizer (Organizer) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1106].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1107].
3) SHALL contain exactly one (or a nullFlavor value) [1..1] templateId [CONF:1108] such that it,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.17"
[CONF:1108.12].
4) MAY contain zero or more [0..*] {CDAR2} organizer [CONF:1109].
a) SHALL contain exactly one [1..1] @classCode="CLUSTER" cluster (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1110].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1111].
c) SHALL contain zero or one if available [0..1] id [CONF:1112].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] code [CONF:1113].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] statusCode, which SHALL be
selected from ValueSet x_ActStatusActiveComplete 2.16.840.1.113883.1.11.19890 STATIC [CONF:1114].
f) SHALL contain zero or one if available [0..1] author [CONF:1115] such that it,
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1115.1].
g) MAY contain zero or more [0..*] {CDAR2} informant [CONF:1116] such that each,
i) SHALL contain exactly one [1..1] Informant Participation
(2.16.840.1.113883.3.1818.10.4.10) [CONF:1116.1].
h) SHALL contain one or more (or a nullFlavor value) [1..*] component [CONF:1117].
i) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1118].
ii) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1119].
iii) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1120].
(1) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1121].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1122].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
335 DSTU (Revision 2013)
(3) SHALL contain exactly one (or a nullFlavor value) [1..1] id [CONF:1123].
(4) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} code, which SHOULD
be selected from ValueSet RiskFactorObservationType 2.16.840.1.113883.3.1818.10.8.3 DYNAMIC [CONF:1124].
(5) SHALL contain zero or one if available [0..1] text [CONF:1125].
(6) SHALL contain zero or one if available [0..1] effectiveTime [CONF:1126] such that it,
(a) MAY be a partial date conforming to the TS data type constraints [CONF:1126.62].
(7) SHALL contain one or more (or a nullFlavor value) [1..*] value [CONF:1127].
(8) MAY contain zero or more [0..*] {CDAR2} interpretationCode, which SHALL be
selected from ValueSet ObservationInterpretation 2.16.840.1.113883.2.20.3.78 STATIC [CONF:1128].
(9) MAY contain zero or more [0..*] {CDAR2} methodCode, which SHOULD be selected from
ValueSet ObservationMethod 2.16.840.1.113883.1.11.14079 DYNAMIC [CONF:1129].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
336 DSTU (Revision 2013)
The following XML example outlines how to use the Risk Factors Organizer template:
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.17"/> <!-- Risk Factor Organizer
-->
<organizer classCode="CLUSTER" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="80943009" displayName="Risk factor (observable entity)"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT"/>
<statusCode code="final"/>
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author Participation
-->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Observation Informant -->
<informant typeCode="INF" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.10"/> <!-- Informant
Participation -->
<assignedEntity classCode="ASSIGNED">
<id nullFlavor="NA"/>
<assignedPerson>
<name>Mrs. Everybody</name>
</assignedPerson>
</assignedEntity>
</informant>
<component typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<id nullFlavor="NA"/>
<code code="77176002" displayName="Smoker (finding)"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT"/>
<text>Smoking 2 pack per day since 1996</text>
<value xsi:type="BL" value="true"/>
</observation>
</component>
<component typeCode="COMP" contextConductionInd="true">
<observation classCode="OBS" moodCode="EVN">
<id nullFlavor="NA"/>
<code code="228277002" displayName="Light Drinker"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT"/>
<text>1-2 drinks per week</text>
<value xsi:type="BL" value="true"/>
</observation>
</component>
</organizer>
</entry>
Figure 90: Risk Factors Organizer entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
337 DSTU (Revision 2013)
6.20 UNCLASSIFIED DOCUMENTS ORGANIZER
[Organizer: templateId 2.16.840.1.113883.3.1818.10.3.19(open)]
Table 116: Unclassified Documents Organizer Template Context
Directly Used by Template(s) Directly Contains Template(s)
Unclassified Documents [with entries] Attachment
The Unclassified Documents Organizer template is used to group unclassified documents that are
attached to the patient's heath record. The organizer template enables the grouping of the unclassified
documents based on a record identifier, a code indicating the type of document or a status.
Table 117: Unclassified Documents Organizer Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
4459 @typeCode M:1..1
4460 templateId O:0..* II
4461 organizer O:0..*
4462 @classCode R:1..1
4463 @moodCode R:1..1
4464 Organizer Id Unique and persistent identifier for the group of unclassified documents.
id O:0..* II
4465 Organizer Code Code identifying the type of the group of unclassified documents.
code O:0..1 CD
4466 Organizer Status The overall status of the group of unclassified documents. Active shall be sent to indicate non-Final status, while Complete is used to indicate either a Final or Corrected group of documents.
statusCode R:1..1 CS
4467 Organizer Effective Date The effective date/time of the group of unclassified documents
effectiveTime O:0..1 IVL_TS
4468 Unclassified Document attachment(s)
component (Attachment) M:1..*
An Unclassified Documents Organizer (Organizer) element:
1) SHALL contain exactly one [1..1] @typeCode="DRIV" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:4459].
2) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:4460] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.3.19"
[CONF:4460.12].
3) MAY contain zero or more [0..*] {CDAR2} organizer [CONF:4461].
a) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} @classCode="CLUSTER"
cluster (CodeSystem: ActClass 2.16.840.1.113883.5.6) [CONF:4462].
b) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} @moodCode="EVN" event
(CodeSystem: ActMood 2.16.840.1.113883.5.1001) [CONF:4463].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
338 DSTU (Revision 2013)
c) MAY contain zero or more [0..*] {CDAR2} id [CONF:4464].
d) MAY contain zero or one [0..1] {CDAR2} code [CONF:4465].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} statusCode, which SHALL be
selected from ValueSet ActStatus 2.16.840.1.113883.1.11.159331 STATIC [CONF:4466].
f) MAY contain zero or one [0..1] {CDAR2} effectiveTime [CONF:4467].
g) SHALL contain at least one [1..*] component [CONF:4468] such that each,
i) SHALL contain exactly one [1..1] Attachment (2.16.840.1.113883.3.1818.10.4.1)
[CONF:4468.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
339 DSTU (Revision 2013)
The following XML example outlines how to use the Unclassified Documents Organizer template:
<component typeCode="COMP" contextConductionInd="true">
<section classCode="DOCSECT" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.2.26.1"/>
<code code="46450-3" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
displayName="Text-Miscellaneous Section"/>
<title>Unclassified Documents [with entries] [PITO]</title>
<text>
</text>
<entry typeCode="DRIV" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.3.27.1"/> <!-- Unclassified
Documents Organizer -->
<organizer classCode="CLUSTER" moodCode="EVN">
<code nullFlavor="NI" displayName="2012 historical documents"/>
<statusCode code="Complete"/>
<effectiveTime>
<low value="20120101"/>
<high value="20121231"/>
</effectiveTime>
<component>
<!-- Attachment or Reference -->
<templateId root="2.16.840.1.113883.3.1818.10.4.1"/> <!-- Attachment -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="ATTACH" displayName="Attachment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<text>Keywords: GME</text>
<effectiveTime value="20120202"/>
<value xsi:type="ST">General Medical Examination Report</value>
<!-- Attachment Notes not included in this sample-->
<!-- Reviewed Dates not included in this sample-->
<!-- Attachment or Reference -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.9"/> <!-- Encapsulated Data
-->
<observationMedia classCode="OBS" moodCode="EVN">
<id extension="127797" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<value mediaType="application/pdf">
<reference value="http://www.anywhere.com/folder1/20120202-Patient1-
claim1.pdf"/>
</value>
<!--Attachment author not included in this sample -->
</observationMedia>
</entryRelationship>
</observation>
</component>
</organizer>
</entry>
</section>
</component>
Figure 91: Unclassified Documents Organizer entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
340 DSTU (Revision 2013)
7.0 ENTRY TEMPLATES This chapter contains the Entry Templates referenced by one or more of the Section-Entry Templates of
the PITO E2E-DTC Specification. These templates are reusable sections of the implementation guide
that are called from the Section-Entry Templates as required. They contain the structured entry
constraints for specific clinical statements or functions. Entry Templates may be called from Section-
Entry Templates, or from other Entry Templates.
Note that the Entry Templates are presented in alphabetical order; templates are not grouped by possible
containing templates.
Entry Templates are always allowed in sections.
Each Entry Templates description contains the following information:
Key template metadata (e.g., templateId, etc.);
Description and explanatory narrative;
Entry Templates names and IDs for referenced templates (required and optional);
Required CDA acts, participants and vocabularies; and
Optional CDA acts, participants and vocabularies.
7.1 ATTACHMENT
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.1(open)]
Table 118: Attachment Template Context
Directly Used by Template(s) Directly Contains Template(s)
Advanced Directives Observation Comment Observation
Alert Observation Date Observation
Encounter Event Encapsulated Data
Medical Imaging Observation
Outcome Observation
Result Component
Unclassified Documents Organizer
The Attachments template is used to reference any external file within the context of a part of the patient’s
record (e.g. lab results, x-ray images, etc.). There are many use cases where clinical content may not be
incorporated discretely into the EMR system, but linked to the relevant record through the attachment
mechanism.
When an external file is attached to the patient’s medical record there are certain meta data regarding
that file that must be captured and communicated with the file to ensure that the context of the external
file in relation to the medical record is maintained. This meta data may include the date the attachment is
received, its title and author. The addition of keywords may also be used to facilitate searching, filtering
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
341 DSTU (Revision 2013)
and sorting attachments within the EMR. Additionally, the EMR may provide the ability for the user to add
notes or observations regarding the attachment for future reference.
The Attachment itself may be embedded into the CDA document; or, more commonly referenced as an
external document located within the message wrapper, a recognized file system, or at a web location.
Refer to the Encapsulated Data template for details on the transmission of attached files.
Table 119: Attachment Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1202 @typeCode M:1..1
1203 @contextConductionInd M:1..1
1204 templateId O:0..* II
1205 observation M:1..1
1206 @classCode M:1..1
1207 @moodCode M:1..1
1208 Record ID id M:1..1 II
1209 Attachment Type Code The type of attachment. (e.g. Consult report, Advance Directive).
code M:1..1 CD
1210 Date Attachment Received Date that attachment was captured in the EMR system.
effectiveTime R:1..1 IVL_TS
1211 Attachment Title The title or short description of the attachment that may be used to identify the attachment to the provider.
value R:1..1 st
1212 Attachment Keywords Keywords associated with the attachment that may be used to filter or search for attachments.
text O:0..1 ED
1213 Attachment Notes Any notes or observations regarding the attachment that the provider may have entered in the EMR.
entryRelationship
(Comment Observation)
O:0..*
1214 Date Attachment Reviewed Date attachment was reviewed by a doctor.
entryRelationship (Date
Observation)
R:0..1
1215 Attachment Encapsulated Data entryRelationship
(Encapsulated Data)
O:0..*
An Attachment (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1202].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1203].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1204] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.1"
[CONF:1204.12].
4) SHALL contain exactly one [1..1] observation [CONF:1205].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
342 DSTU (Revision 2013)
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1206].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1207].
c) SHALL contain exactly one [1..1] id [CONF:1208].
d) SHALL contain exactly one [1..1] code, which SHALL be selected from ValueSet
AttachmentObservationType 2.16.840.1.113883.3.3068.10.8.14 DYNAMIC [CONF:1209].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:1210].
f) SHALL contain exactly one (or a nullFlavor value) [1..1] value [CONF:1211].
g) MAY contain zero or one [0..1] {CDAR2} text [CONF:1212].
h) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:1213] such that each,
i) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:1213.1].
i) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1214] such that it,
i) SHALL contain exactly one [1..1] Date Observation
(2.16.840.1.113883.3.1818.10.4.4) [CONF:1214.1].
j) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:1215] such that each,
i) SHALL contain exactly one [1..1] Encapsulated Data
(2.16.840.1.113883.3.1818.10.4.9) [CONF:1215.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
343 DSTU (Revision 2013)
The following XML example outlines how to use the Attachment template:
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.1"/> <!-- Attachment -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="ATTACH" displayName="Attachment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Keywords: DNR 4, full resucitation</text>
<effectiveTime value="20120202"/>
<e2e:confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>
<value xsi:type="ST">Resucitation Order</value>
<!-- Attachment Notes -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="ST">Attachment Note included here</value>
</observation>
</entryRelationship>
<!-- Reviewed Dates -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.4"/> <!-- Date
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="DATEOBS" displayName="Date Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<effectiveTime value="20120201114523-0700"/>
</observation>
</entryRelationship>
<!-- Attachment or Reference -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.9"/> <!-- Encapsulated
Data -->
<observationMedia classCode="OBS" moodCode="EVN">
<id extension="127797" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<value xsi:type="ED" mediaType="application/pdf">
<reference value="http://www.anywhere.com/folder1/20120202-Patient1-
claim1.pdf"/>
</value>
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/>
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
344 DSTU (Revision 2013)
</author>
</observationMedia>
</entryRelationship>
</observation>
</entryRelationship>
Figure 92: Attachment entry example
7.2 AUTHOR PARTICIPATION
[Author: templateId 2.16.840.1.113883.3.1818.10.4.2(closed)]
Table 120: Author Participation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Appointment Observation N/A
Clinically Measured Observations Organizer
Comment Observation
Developmental Observations Organizer
Device Observation
Encapsulated Data
Encounter Event
Immunization Observation
Laboratory Observation
Medical Imaging Observation
Medication Administration Event
Medication Prescription Event
Order Event
Outcome Observation
Problem List Observation
Qualifier Observation
Reaction Observation
Reason Observation
Reproductive Observations Organizer
Risk Factors Organizer
Status Changes Audit Event
The Author Participation template is a generic template that is referenced by various section or entry to
enable the consistent communication of an author participation.
The Author Participation template supports the author’s name and an optional identifier as well as an
effectiveTime element. This template MAY also be extended to support the author’s represented
organization if required.
Table 121: Author Participation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1226 @typeCode M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
345 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1227 @contextControlCode M:1..1
1228 templateId O:0..* II
1229 Authored Date/Time The date/time at which the authoring activity occurred.
time R:1..1 TS
1230 assignedAuthor M:1..1
1231 @classCode M:1..1
1232 Author Identifier id R:1..1 II
1233 assignedPerson M:1..1
1234 @classCode M:1..1
1235 @determinerCode M:1..1
1236 Author's Name The author's name.
name R:1..1 PN
1237 Author's Represented Organization The organization that is represented by the author may be included if required.
representedOrganization O:0..*
1238 @classCode M:1..1
1239 @determinerCode M:1..1
1240 Represented Organization's Identifier id O:0..* II
1241 Represented Organization's Name name O:0..* ON
An Author Participation (Author) element:
1) SHALL contain exactly one [1..1] @typeCode="AUT" author (CodeSystem: ParticipationType
2.16.840.1.113883.5.90) [CONF:1226].
2) SHALL contain exactly one [1..1] {CDAR2} @contextControlCode="OP" overriding propagating
(CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:1227].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1228] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.2"
[CONF:1228.12].
4) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} time [CONF:1229] such that it,
a) SHALL be precise to the day and SHOULD be precise to the minute; if precise to the minute, value
SHALL include a time zone offset [CONF:1229.18].
5) SHALL contain exactly one [1..1] assignedAuthor [CONF:1230].
a) SHALL contain exactly one [1..1] @classCode="ASSIGNED" assigned (CodeSystem: RoleClass
2.16.840.1.113883.5.110) [CONF:1231].
b) SHALL contain exactly one (or a nullFlavor value) [1..1] id [CONF:1232] such that it,
i) SHALL be the BC Ministry of Health Practitioner ID, for which the OID root is
2.16.840.1.113883.3.40.2.11 if the identified person is a Provider; MAY be a locally
assigned identifier if and only if the identified person is not a Provider [CONF:1232.25].
ii) MAY be a locally assigned identifier, if the author is a not a Provider [CONF:1232.13].
iii) MAY contain a NullFlavor if the id is not known and the name is included [CONF:1232.14].
c) SHALL contain exactly one [1..1] assignedPerson [CONF:1233].
i) SHALL contain exactly one [1..1] @classCode="PSN" person (CodeSystem: EntityClass
2.16.840.1.113883.5.41) [CONF:1234].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
346 DSTU (Revision 2013)
ii) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance (CodeSystem:
EntityDeterminer 2.16.840.1.113883.5.30) [CONF:1235].
iii) SHALL contain exactly one (or a nullFlavor value) [1..1] name [CONF:1236] such that it,
(1) SHALL, when present, conform to the Person Name (PN) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.3) [CONF:1236.5].
d) MAY contain zero or more [0..*] {CDAR2} representedOrganization [CONF:1237].
i) SHALL contain exactly one [1..1] @classCode="ORG" organization (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:1238].
ii) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance (CodeSystem:
EntityDeterminer 2.16.840.1.113883.5.30) [CONF:1239].
iii) MAY contain zero or more [0..*] {CDAR2} id [CONF:1240].
iv) MAY contain zero or more [0..*] {CDAR2} name [CONF:1241].
The following XML example outlines how to use the Author Participation template:
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<name>Healthcare Drive Clinical Centre</name>
</representedOrganization>
</assignedAuthor>
</author>
Figure 93: Author Participation entry example
7.3 COMMENT OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.3(open)]
Table 122: Comment Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Advanced Directives Observation Author Participation
Alert Observation
Allergy & Intolerance Observation
Appointment Observation
Attachment
Care History Event
Encounter Event
Family History Observation
Immunization Observation
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
347 DSTU (Revision 2013)
Directly Used by Template(s) Directly Contains Template(s)
Laboratory Observation
Medication Administration Event
Medication Event
Order Event
Problem List Observation
Reaction Observation
Result Component
The Comment Observation template is a generic comment template that may be referenced from different
sections or entry templates to support the consistent communication of a comment. Comments are free
text data that cannot otherwise be recorded using data elements already defined by this specification.
They SHALL NOT be used to record information that can be recorded elsewhere. For example, a free text
description of the severity of an allergic reaction SHALL NOT be recorded in a comment but SHALL be
communicated through the applicable data element.
The Comment Observation template supports a coded or free text comment, effective time and an author.
Table 123: Comment Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1318 @typeCode M:1..1
1319 @contextConductionInd M:1..1
1320 templateId O:0..* II
1321 observation O:0..*
1322 @classCode M:1..1
1323 @moodCode M:1..1
1324 Record ID id R:0..1 II
1325 Comment Observation Code code R:1..1 CD
1326 Free Text Comment text R:1..1 ED
1327 Comment Effective Time effectiveTime R:0..1 IVL_TS
1328 Coded Comment value value R:1..1 ED
1329 Observation Author author (Author
Participation)
O:0..*
A Comment Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem: ActRelationshipType
2.16.840.1.113883.5.1002) [CONF:1318].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1319].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1320] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.3"
[CONF:1320.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1321].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
348 DSTU (Revision 2013)
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1322].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1323].
c) SHALL contain zero or one if available [0..1] id [CONF:1324].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] code="COMMENT" Comment
Observation (CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1325].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] text [CONF:1326].
f) SHALL contain zero or one if available [0..1] effectiveTime [CONF:1327] such that it,
i) SHALL contain exactly one [1..1] low value to indicate the Start Date/Time and MAY contain
zero or one [0..1] high values to indicate the End Date/Time [CONF:1327.50].
g) SHALL contain exactly one (or a nullFlavor value) [1..1] value [CONF:1328].
h) MAY contain zero or more [0..*] {CDAR2} author [CONF:1329] such that each,
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1329.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
349 DSTU (Revision 2013)
The following XML example outlines how to use the Comment Observation template:
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment
Observation -->
<observation classCode="OBS" moodCode="EVN">
<id extension="123" root="1.2.3.4"/>
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending"/>
<text>Patient advised to review package of care</text>
<effectiveTime value="20120202"/>
<value xsi:type="CD" code="413324005" displayName="Patient advised to
review package of care"
codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT" />
<!-- Comment Author -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<name>Healthcare Drive Clinical Centre</name>
</representedOrganization>
</assignedAuthor>
</author>
</observation>
</entryRelationship>
Figure 94: Comment Observation entry example
7.4 DATE OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.4(open)]
Table 124: Date Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Advanced Directives Observation N/A
Attachment
Encounter Event
Immunization Observation
Medication Event
Problem List Observation
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
350 DSTU (Revision 2013)
The Date Observation template is a generic comment template that may be referenced from different
section or entry templates to support the consistent communication of a date for an observation.
The Date Observation template supports only an effective time.
Table 125: Date Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1330 Date Observation @typeCode M:1..1
1331 @contextConductionInd M:1..1
1332 templateId O:0..* II
1333 observation O:0..*
1334 @classCode M:1..1
1335 @moodCode M:1..1
1336 Date Observation Code code R:1..1 CD
1337 Effective Time effectiveTime O:0..1 IVL_TS
A Date Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem: ActRelationshipType
2.16.840.1.113883.5.1002) [CONF:1330].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1331].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1332] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.4"
[CONF:1332.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1333].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1334].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1335].
c) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} code="DATEOBS" Date
Observation (CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1336].
d) MAY contain zero or one [0..1] {CDAR2} effectiveTime [CONF:1337].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
351 DSTU (Revision 2013)
The following XML example outlines how to use the Date Observation template:
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.4"/> <!-- Date Observation
-->
<observation classCode="OBS" moodCode="EVN">
<code code="DATEOBS" displayName="Date Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<effectiveTime value="20120201114523-0700"/>
</observation>
</entryRelationship>
Figure 95: Date Observation entry example
7.5 DISPENSE REQUEST (FIRST FILL)
[Supply: templateId 2.16.840.1.113883.3.1818.10.4.14(open)]
Table 126: Dispense Request (first fill) Template Context
Directly Used by Template(s) Directly Contains Template(s)
Medication Prescription Event Medication Fill Interval
The Dispense Request (first fill) template is used to communicate the instructions for the initial filling of a
prescription event. This template includes the requested dispense quantity, duration, and the fill interval
(amount of time between dispense events).
Table 127: Dispense Request (first fill) Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1598 @typeCode M:1..1
1599 @contextConductionInd M:1..1
1600 templateId M:1..1 II
1601 supply M:1..1
1602 @classCode M:1..1
1603 @moodCode M:1..1
1604 Supply Dispense Type Type of dispense request or event. (e.g. first fill, refill, part fill).
code M:1..1 CD
1605 Fill Quantity The quantity of medication to be dispensed for the first administration of the prescription. Expressed as a number and the form. (e.g. 2 tablets) .
quantity R:0..1 PQ
1606 Fill Duration Number of days (or units of time) of medication to be dispensed for the first
expectedUseTime R:0..1 IVL_TS
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
352 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
dispense of the prescription (e.g. 30 days).
1607 Fill Interval The amount of time that must elapse between the first dispense event and any subsequent part-fill or refill dispense events (e.g. 30 days).
entryRelationship
(Medication Fill
Interval)
R:0..1
A Dispense Request (first fill) (Supply) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1598].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1599].
3) SHALL contain exactly one [1..1] templateId [CONF:1600] such that it,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.14"
[CONF:1600.12].
4) SHALL contain exactly one [1..1] supply [CONF:1601].
a) SHALL contain exactly one [1..1] @classCode="SPLY" supply (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1602].
b) SHALL contain exactly one [1..1] @moodCode="RQO" request (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1603].
c) SHALL contain exactly one [1..1] code="FF" First fill (CodeSystem: ActCode
2.16.840.1.113883.5.4) [CONF:1604].
d) SHALL contain zero or one if available [0..1] quantity [CONF:1605].
e) SHALL contain zero or one if available [0..1] expectedUseTime [CONF:1606].
f) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1607] such that it,
i) SHALL contain exactly one [1..1] Medication Fill Interval
(2.16.840.1.113883.3.1818.10.4.11) [CONF:1607.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
353 DSTU (Revision 2013)
The following XML example outlines how to use the Dispense Request (first fill) template:
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.14"/> <!-- Dispense
Request (first fill) -->
<supply classCode="SPLY" moodCode="RQO">
<code code="FF" codeSystem="2.16.840.1.113883.5.4" displayName="Partial
First Fill" codeSystemName="Hl7 Act Code"/>
<quantity value="10"/>
<expectedUseTime>
<width value="5" unit="d"/>
</expectedUseTime>
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.11"/> <!-- Medication
Fill Interval -->
<observation classCode="OBS" moodCode="EVN">
<code code="FILLINT" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Fill Interval"/>
<text>3 days</text>
<value xsi:type="PQ" value="3" unit="d"/>
</observation>
</entryRelationship>
</supply>
</entryRelationship>
Figure 96: Dispense Request (first fill) entry example
7.6 DISPENSE REQUEST (PART FILL)
[Supply: templateId 2.16.840.1.113883.3.1818.10.4.33(open)]
Table 128: Dispense Request (part fill) Template Context
Directly Used by Template(s) Directly Contains Template(s)
Medication Prescription Event Medication Fill Interval
The Dispense Request (part fill) template is used to communicate the instructions for the partial filling of a
prescription event required. Part-Fill is a method for prescribing a staggered fill where refills are not
allowed as in the case of opioids or other controlled substances. When these types of medications are
prescribed, the prescriber MUST specify the total quantity to be dispensed. Although refills are not
allowed, the prescriber may specify that the total amount be dispensed in smaller amounts at specified
intervals until the total amount has been dispensed.
This template includes the requested dispense quantity, duration, and the fill interval (amount of time
between dispense events).
Table 129: Dispense Request (part fill) Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1608 @typeCode M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
354 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1609 @contextConductionInd M:1..1
1610 templateId M:1..1 II
1611 supply M:1..1
1612 @classCode M:1..1
1613 @moodCode M:1..1
1614 Supply Dispense Type Type of dispense request or event (e.g. first fill, refill, part fill).
code M:1..1 CD
1615 Fill Quantity The quantity of medication to be dispensed during one dispensing event for part-fill prescriptions. Expressed as a number and the form (e.g. 2 tablets).
quantity R:0..1 PQ
1616 Fill Duration Number of days (or units of time) of medication to be dispensed for each part-fill dispense of the prescription (e.g. 30 days).
expectedUseTime R:0..1 IVL_TS
1617 Fill Interval The amount of time that must occur between dispense evens for part-fill prescriptions (e.g. 30 days).
entryRelationship
(Medication Fill
Interval)
R:0..1
A Dispense Request (part fill) (Supply) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1608].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1609].
3) SHALL contain exactly one [1..1] templateId [CONF:1610] such that it,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.33"
[CONF:1610.12].
4) SHALL contain exactly one [1..1] supply [CONF:1611].
a) SHALL contain exactly one [1..1] @classCode="SPLY" supply (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1612].
b) SHALL contain exactly one [1..1] @moodCode="RQO" request (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1613].
c) SHALL contain exactly one [1..1] code="FFP" First fill (partial) (CodeSystem: ActCode
2.16.840.1.113883.5.4) [CONF:1614].
d) SHALL contain zero or one if available [0..1] quantity [CONF:1615].
e) SHALL contain zero or one if available [0..1] expectedUseTime [CONF:1616].
f) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1617] such that it,
i) SHALL contain exactly one [1..1] Medication Fill Interval
(2.16.840.1.113883.3.1818.10.4.11) [CONF:1617.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
355 DSTU (Revision 2013)
The following XML example outlines how to use the Dispense Request (part fill) template:
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.33"/> <!--Dispense Request
(part fill)-->
<supply classCode="SPLY" moodCode="RQO">
<code code="FFP" codeSystem="2.16.840.1.113883.5.4" displayName="Partial
First Fill" codeSystemName="Hl7 Act Code"/>
<quantity value="10"/>
<expectedUseTime>
<width value="5" unit="d"/>
</expectedUseTime>
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.11"/> <!-- Medication
Fill Interval -->
<observation classCode="OBS" moodCode="EVN">
<code code="FILLINT" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Fill Interval"/>
<text>5 per day</text>
<value xsi:type="PQ" value="5" unit="d"/>
</observation>
</entryRelationship>
</supply>
</entryRelationship>
Figure 97: Dispense Request (part fill) entry example
7.7 DISPENSE REQUEST (REFILL)
[Supply: templateId 2.16.840.1.113883.3.1818.10.4.34(open)]
Table 130: Dispense Request (refill) Template Context
Directly Used by Template(s) Directly Contains Template(s)
Medication Prescription Event Medication Fill Interval
The Dispense Request (refill) template is used to communicate the refill instructions for a prescription
event. In addition to the number of refills that are being authorized, this template includes the requested
dispense quantity, duration, and the fill interval (amount of time between dispense events).
Table 131: Dispense Request (refill) Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1618 @typeCode M:1..1
1619 templateId O:0..* II
1620 @contextConductionInd M:1..1
1621 supply M:1..1
1622 @classCode M:1..1
1623 @moodCode M:1..1
1624 Supply Dispense Type code M:1..1 CD
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
356 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
Type of dispense request or event (e.g. first fill, refill, part fill).
1625 Refill Number Number of refills that are allowed by the prescription.
repeatNumber R:0..1 IVL_INT
1626 Refill Quantity The quantity of medication to be dispensed for the refills in the prescription (e.g. 30 tablets).
quantity R:0..1 PQ
1627 Refill Duration Number of days of medication to be dispensed for the refills of the prescription (e.g. 30 days) .
expectedUseTime R:0..1 IVL_TS
1628 Refill Interval The amount of time that must elapse between dispense events for refill prescriptions (e.g. 30 days) .
entryRelationship
(Medication Fill
Interval)
R:0..1
A Dispense Request (refill) (Supply) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1618].
2) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1619] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.34"
[CONF:1619.12].
3) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1620].
4) SHALL contain exactly one [1..1] supply [CONF:1621].
a) SHALL contain exactly one [1..1] @classCode="SPLY" supply (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1622].
b) SHALL contain exactly one [1..1] @moodCode="RQO" request (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1623].
c) SHALL contain exactly one [1..1] code="RF" Refill (CodeSystem: ActCode
2.16.840.1.113883.5.4) [CONF:1624].
d) SHALL contain zero or one if available [0..1] repeatNumber [CONF:1625].
e) SHALL contain zero or one if available [0..1] quantity [CONF:1626].
f) SHALL contain zero or one if available [0..1] expectedUseTime [CONF:1627].
g) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1628] such that it,
i) SHALL contain exactly one [1..1] Medication Fill Interval
(2.16.840.1.113883.3.1818.10.4.11) [CONF:1628.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
357 DSTU (Revision 2013)
The following XML example outlines how to use the Dispense Request (refill) template:
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.34"/> <!--Dispense
Request (Refills)-->
<supply classCode="SPLY" moodCode="RQO">
<code code="RF" codeSystem="2.16.840.1.113883.5.4" displayName="Refills"
codeSystemName="Hl7 Act Code"/>
<repeatNumber value="1"/>
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.11"/> <!-- Medication
Fill Interval -->
<observation classCode="OBS" moodCode="EVN">
<code code="FILLINT" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Fill Interval"/>
<text>30 days</text>
<value xsi:type="PQ" value="30" unit="d"/>
</observation>
</entryRelationship>
</supply>
</entryRelationship>
Figure 98: Dispense Request (refill) entry example
7.8 DOSE OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.8(open)]
Table 132: Dose Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Medication Prescription Event Medication Identification
The Dose Observation template is used to communicate specific dose related instructions including the
dose duration, frequency, route, site quantity and form.
Multiple Dose Management
It is not unusual for medications to be prescribed with multiple dose instructions such as variable
frequencies and quantities. Examples may include:
1 pill twice a day and two pills at bed time;
1 pill for 2 days then 3 pills for 10 days.
If there are more than one Dose Observation instruction within a prescription then this is indicated by the
entryRelationship/@typeCode element.
Table 133: Dose Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
358 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1572 Dose Relationship Type If there are more than one Dose Instruction within the prescription; this element indicates if the dose instructions are sequential (dose 1 then dose 2) or concurrent (dose 1 and dose 2).
@typeCode M:1..1
1573 @contextConductionInd M:1..1
1574 templateId M:1..1 II
1575 substanceAdministration O:0..*
1576 @classCode M:1..1
1577 @moodCode M:1..1
1578 Dose Instructions A textual description of the dose instructions.
text R:0..1 ED
4387 Duration A number in the prescription denoting how long a medication is to be administered based on a specific dosage specification. This is an alternative approach to specifying start and stop dates (e.g. 10 days).
effectiveTime R:1..1 SXCM_TS
1579 Frequency A code describing the interval between dosages and use of a particular medication, and the repeating frequency with which the dosage is to be administered or the use repeated (e.g. every 2 hours).
effectiveTime R:1..1 SXCM_TS
1580 Route A Coded value in the prescription denoting the primary method by which a medication is to be administered to the patient (e.g. sublingual).
routeCode R:0..1 CE
1581 Site Coded value for the anatomic site where medication is intended to be administered (e.g. left eye).
approachSiteCode R:0..1 CD
1582 Dose Dose amount of medication intended to be consumed during a single administration. The Dose Amount data type supports a single dose or a range of doses with a high/low value (e.g. 1-2 tsp, 10mg).
doseQuantity R:1..1 IVL_PQ
1583 Form Form of medication to be administered (e.g. tablet, drop).
administrationUnitCode R:0..1 CE
4361 Drug Information The specific drug and drug strength that is the subject of the Medication List record.
consumable (Medication
Identification)
M:1..1
A Dose Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode, which SHALL be selected from ValueSet
x_ComponentStartsBefore 2.16.840.1.113883.3.3068.10.8.12 STATIC [CONF:1572].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1573].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
359 DSTU (Revision 2013)
3) SHALL contain exactly one [1..1] templateId [CONF:1574] such that it,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.8"
[CONF:1574.12].
4) MAY contain zero or more [0..*] {CDAR2} substanceAdministration [CONF:1575].
a) SHALL contain exactly one [1..1] @classCode="SBADM" substance administration (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1576].
b) SHALL contain exactly one [1..1] @moodCode="RQO" request (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1577].
c) SHALL contain zero or one if available [0..1] text [CONF:1578].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:4387].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:1579].
f) SHALL contain zero or one if available [0..1] routeCode, which SHALL be selected from ValueSet
RouteOfAdministration 2.16.840.1.113883.2.20.3.188 STATIC [CONF:1580].
g) SHALL contain zero or one if available [0..1] approachSiteCode, which SHALL be selected from
ValueSet HumanSubstanceAdministrationSite 2.16.840.1.113883.2.20.3.52 DYNAMIC [CONF:1581].
h) SHALL contain exactly one (or a nullFlavor value) [1..1] doseQuantity [CONF:1582].
i) SHALL contain zero or one if available [0..1] administrationUnitCode, which SHALL be
selected from ValueSet AdministerableDrugForm 2.16.840.1.113883.1.11.14570 STATIC [CONF:1583].
j) SHALL contain exactly one [1..1] consumable [CONF:4361] such that it,
i) SHALL contain exactly one [1..1] Medication Identification
(2.16.840.1.113883.3.1818.10.4.16) [CONF:4361.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
360 DSTU (Revision 2013)
The following XML example outlines how to use the Dose Observation template:
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.8"/> <!--Dose Observation-
->
<substanceAdministration classCode="SBADM" moodCode="RQO">
<!-- Duration -->
<text>Take 2 tablets for 10 days</text>
<!--Example 1: Using start and stop dates or start date and number of
time units-->
<effectiveTime xsi:type="IVL_TS" operator="I"><!-- 10 days -->
<width value="10" unit="D"/>
</effectiveTime>
<!-- Example 2: Duration from Jan 1 until Jan 10
<effectiveTime xsi:type="IVL_TS" operator="I">
<low value="20130101" inclusive="true"/>
<high value="20130110" inclusive="true"/>
</effectiveTime>
-->
<!-- Example 3: Specify medication administration frequency (e.g. b.i.d)
<effectiveTime xsi:type="PIVL_TS" institutionSpecified="true">
<frequency>
<numerator value="2"/>
<denominator value="1" unit="d"/>
</frequency>
</effectiveTime>
-->
<!-- Example 4: Frequency every 2-4 hours
<effectiveTime xsi:type="PIVL_TS"
institutionSpecified="true">
<period xsi:type="URG_PQ">
<low value="2" unit="h"/>
<high value="4" unit="h"/>
</period>
</effectiveTime>
-->
<routeCode code="PO" displayName="per os"
codeSystem="2.16.840.1.113883.5.112" codeSystemName="RouteOfAdministration"/>
<approachSiteCode code="M" displayName="Mouth"
codeSystem="2.16.840.1.113883.2.20.3.52"
codeSystemName="HumanSubstanceAdministrationSite"/>
<doseQuantity>
<center value="100" unit="mg"/>
</doseQuantity>
<!-- Form -->
<administrationUnitCode code="ORSPRAY" displayName="oral spray"
codeSystem="2.16.840.1.113883.1.11.14570" codeSystemName="AdministerableDrugForm"/>
<consumable typeCode="CSM">
<templateId root="2.16.840.1.113883.3.1818.10.4.16"/> <!--Medication
Identification-->
<manufacturedProduct classCode="MANU">
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
361 DSTU (Revision 2013)
<manufacturedLabeledDrug>
<code code="02243588" displayName="MYLAN-NITRO SUBLINGUAL SPRAY"
codeSystem="2.16.840.1.113883.5.1105" codeSystemName="hc-DIN"/>
<name>Nitrospray</name>
<e2e:desc>NITROGLYCERIN 0.4 mg/dose SPRAY, NON-AEROSOL
(GRAM)</e2e:desc>
<e2e:formCode code="SPRAY" displayName="Spray"
codeSystem="2.16.840.1.113883.19.5.3" codeSystemName="HL7 Orderable Drug Form"/>
<e2e:ingredient classCode="INGR">
<e2e:quantity value="0.4" unit="mg"/>
<e2e:ingredient classCode="MMAT" determinerCode="KIND">
<e2e:code code="TBD" displayName="Nitro" codeSystem="tbd"
codeSystemName="ClinicalDrug"/>
<e2e:name> NITROGLYCERIN </e2e:name>
</e2e:ingredient>
</e2e:ingredient>
</manufacturedLabeledDrug>
</manufacturedProduct>
</consumable>
</substanceAdministration>
</entryRelationship>
Figure 99: Dose Observation entry example
7.9 ENCAPSULATED DATA
[ObservationMedia: templateId 2.16.840.1.113883.3.1818.10.4.9(open)]
Table 134: Encapsulated Data Template Context
Directly Used by Template(s) Directly Contains Template(s)
Attachment Author Participation
The Encapsulated Data template is used to transmit binary large object (blob) data. This may include
word processing documents, images, video, audio, waveforms, multimedia etc. Encapsulated data may
be referenced as an external file or directly incorporated into the CDA document. If it is referenced it may
be referenced either external or internally to a message package that may be used to carry the document.
In the former case the reference would be to a web URL or to a file in a contextually relevant file system
directory. In the latter case, the blob may be packaged along with the document in the transport
message.
In all cases, a reference to the encapsulated data is contained in the CDA document. All file types are
supported using a reference subject to specific restrictions identified at the document template level.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
362 DSTU (Revision 2013)
File Types
The following file types are supported by the PITO Specification as embedded or included in the Message
Wrapper. Any file type may be referenced.
Table 135: Encapsulated Data File Types
Format Type Format Code (MIME Type)
Word Processing/ Narrative Formats
Microsoft® Word application/msword
Adobe® Portable Document Format (PDF) application/pdf
Plain Text text/plain
Rich Text Format (RTF) Text text/rtf
Hypertext Markup Language (HTML) text/html
Graphic / Image Formats
Graphics Interchange Format (GIF) Image image/gif
Tagged Image File (TIF) Image image/tiff
Joint Photographic Experts Group (JPEG) Image image/jpeg
Portable Network Graphics (PNG) Image image/png
Guidance for Embedding versus Referencing Encapsulated Data
At this time these specifications are silent on whether attachments should be embedded or referenced.
Further work on practical file size limits, if any, or other design drivers that may emerge from early pilot
implementations may influence this position in future. At this time implementers are advised to use their
judgment and the applicable client / implementation requirements.
The following specific guidance and constraints for the various attachment communication mechanisms
apply:
Embedded
Embedded attachments SHALL be from a list of valid MIME types and mediaTypes.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
363 DSTU (Revision 2013)
If the content is compressed (the compression attribute is present), if the content is an image, or if the
content is an ‘application’ file (first part of the mediaType) (e.g. mediaType=“application/pdf”, “image/png”
respectively), then the content must be base 64-encoded. Otherwise, the content will be sent as directly
embedded text or XML. Uncompressed HTML must be XHTML compliant.
<!-- Example attachment embedded in document -->
<text mediaType=”text/html” language=”fr-CA”>
<html> . . . </html>
</text>
or
<text mediaType="text/rtf" representation="B64">
e1xydGY...
</text>
Figure 100: Example attachment embedded in document
Included in Message Wrapper
In the event the document is transported by way of a structured electronic message and the attachment is
also in the message, then an Xpath is used to reference the location of the attachment in the message
wrapper.
A PDF document contained in the message wrapper would be specified using xpath as follows:
<!-- Example attachment reference to message wrapper -->
<text mediaType=”application/pdf” language=”en-CA”>
<reference value=”Message.attachmentText(1)”/>
</text>
Figure 101: Example attachment included in message wrapper
Referenced
A referenced attachment may be located at a web location. The URL for the location of the actual file or
document must be defined according to the Internet standard for URLs (refer to
“http://tools.ietf.org/html/rfc1738’). For example:
<!-- Example attachment reference to a URL -->
<text mediaType=”image/jpg”>
<reference value=”ftp://anywhere.com/folder1/image1.jpg”/>
</text>
<!—or -->
<text mediaType=”image/jpg”>
<reference value=”http://www.anywhere.com/folder1/image1.jpg”/>
</text>
Figure 102: Example attachment referenced by URL
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
364 DSTU (Revision 2013)
A referenced attachment may be located at an absolute location within a file system. For example:
<!-- Example attachment reference to an absolute file location -->
<text mediaType=”image/jpg”>
<reference value=”file://localhost/c:/my documents/application
data/ehrdata/image1.jpg”/>
</text>
Figure 103: Example attachment referenced by absolute location
In the Conversion Use Case the referenced attachments may be placed in a directory relative to the CDA
document containing a patient’s information. The following example shows how an attachment may be
referenced when it is located in a relative location. For example:
<!-- Example attachment reference to a relative file location -->
<text mediaType=”image/jpg”>
<reference value=”file://ehrdata/image1.jpg”/>
</text>
Figure 104: Example attachment referenced by relative location
The example code in this section and in other sample file(s) typically use simple filenames with relative
paths because they are easy to read. However, simple filenames and relative paths can cause problems
when files are moved among systems.
The hazard to be avoided can be illustrated as follows: Suppose an Unstructured Document that
references a file "ekg.pdf" is transmitted to a receiver who places that Unstructured Document in a
directory that already contains an Unstructured Document for another patient, which also references a file
"ekg.pdf". Unless provisions are made to rename these files or place them in subdirectories, the sitation
may arise where one file overwrites the other and at least one document may point to an incorrect file. As
a result, the use of relative paths and simple filenames can pose a danger to patient safety.
The alternative of providing an absolute URL (Uniform Resource Locator) will fail if the URL is
inaccessible; even within a single organization, machine identifiers may be mapped differently at different
locations.
Therefore this guide recommends the use of unique names for referenced files. One approach to
generating a unique name is to construct it from the globally-unique document id (root and extension)
concatenated to a locally unique reference for the external file. The following figure illustrates this
technique used with a CDA document that has an id root 2.16.840.1.113883.19 and extension
999021.
<reference value="file:ref-2.16.840.1.113883.19-999021-ekg-1.pdf"/>
Figure 105: Unique file reference example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
365 DSTU (Revision 2013)
Considerations pertaining to Multiple Files and File Packaging
In the event there are several scanned files which constitute a single document, the following
consolidation mechanisms are proposed:
Use of a CDA document type that has a structuredBody;
Use a multi-page/graphic file type such as PDF; or
“Stitch” the separate images into a single image.
Table 136: Encapsulated Data Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1216 @typeCode M:1..1
1217 @contextConductionInd M:1..1
1218 templateId O:0..* II
1219 observationMedia O:0..*
1220 @classCode M:1..1
1221 @moodCode M:1..1
1222 Attachment Identifier The identifier of the external document, report, letter or other attachment relevant to the encounter and attached to the encounter.
id M:1..1 II
1223 Attachment Content or Reference The attachment content itself or external reference to the content.
value M:1..1 ED
1224 Attachment Author Principle author of the attachment. This may be used to filter or search for attachments.
author (Author
Participation)
O:0..*
An Encapsulated Data (ObservationMedia) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1216].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1217].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1218] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.9"
[CONF:1218.12].
4) MAY contain zero or more [0..*] {CDAR2} observationMedia [CONF:1219].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1220].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1221].
c) SHALL contain exactly one [1..1] id [CONF:1222].
d) SHALL contain exactly one [1..1] value [CONF:1223].
e) MAY contain zero or more [0..*] {CDAR2} author [CONF:1224] such that each,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
366 DSTU (Revision 2013)
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1224.1].
The following XML example outlines how to use the Encapsulated Data template:
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.9"/> <!-- Encapsulated
Data -->
<observationMedia classCode="OBS" moodCode="EVN">
<id extension="127797" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<value xsi:type="ED" mediaType="application/pdf">
<reference value="http://www.anywhere.com/folder1/20120202-Patient1-
claim1.pdf"/>
</value>
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/>
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
</observationMedia>
Figure 106: Encapsulated Data entry example
7.10 INFORMANT PARTICIPATION
[Informant: templateId 2.16.840.1.113883.3.1818.10.4.10(open)]
Table 137: Informant Participation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Clinically Measured Observations Organizer N/A
Developmental Observations Organizer
Device Observation
Encounter Event
Reaction Observation
Reason Observation
Reproductive Observations Organizer
Risk Factors Organizer
The Informant Participation template is a generic template that is referenced by various section or entry to
enable the consistent communication of an informant participation.
The Informant Participation template supports the informant’s name and an optional identifier.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
367 DSTU (Revision 2013)
Table 138: Informant Participation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1242 @typeCode M:1..1
1243 @contextControlCode M:1..1
1244 templateId O:0..* II
1245 assignedEntity M:1..1
1246 @classCode M:1..1
1247 Informant Identifier The informant's identifier if the informant is an identified person.
id R:1..1 II
1248 assignedPerson M:1..1
1249 @classCode M:1..1
1250 @determinerCode M:1..1
1251 Informant's Name name R:1..1 PN
An Informant Participation (Informant) element:
1) SHALL contain exactly one [1..1] @typeCode="INF" informant (CodeSystem: ParticipationType
2.16.840.1.113883.5.90) [CONF:1242].
2) SHALL contain exactly one [1..1] {CDAR2} @contextControlCode="OP" overriding propagating
(CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:1243].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1244] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.10"
[CONF:1244.12].
4) SHALL contain exactly one [1..1] assignedEntity [CONF:1245].
a) SHALL contain exactly one [1..1] @classCode="ASSIGNED" assigned (CodeSystem: RoleClass
2.16.840.1.113883.5.110) [CONF:1246].
b) SHALL contain exactly one (or a nullFlavor value) [1..1] id [CONF:1247] such that it,
i) MAY be a locally assigned identifier, if the author is a not a Provider [CONF:1247.13].
ii) SHALL be the BC Ministry of Health Practitioner ID, for which the OID root is
2.16.840.1.113883.3.40.2.11 if the identified person is a Provider; MAY be a locally
assigned identifier if and only if the identified person is not a Provider [CONF:1247.25].
iii) MAY contain a NullFlavor if the id is not known and the name is included [CONF:1247.14].
c) SHALL contain exactly one [1..1] assignedPerson [CONF:1248].
i) SHALL contain exactly one [1..1] @classCode="PSN" person (CodeSystem: EntityClass
2.16.840.1.113883.5.41) [CONF:1249].
ii) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance (CodeSystem:
EntityDeterminer 2.16.840.1.113883.5.30) [CONF:1250].
iii) SHALL contain exactly one (or a nullFlavor value) [1..1] name [CONF:1251] such that it,
(1) SHALL, when present, conform to the Person Name (PN) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.3) [CONF:1251.5].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
368 DSTU (Revision 2013)
The following XML example outlines how to use the Informant Participation template:
<informant typeCode="INF" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.10"/> <!-- Informant
Participation -->
<assignedEntity classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<code code="07Q00000X" displayName="Family Practice"
codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7 RoleCode" />
<addr use="WP">
<delimiter>2222 Home Street</delimiter>
<city>Kamloops</city>
<state>BC</state>
<postalCode>A1B2C3</postalCode>
<country>CA</country>
</addr>
<telecom value="tel:5555552003" use="H"/>
<telecom value="mailto://[email protected]" use="H"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name use="L">
<prefix>Mrs.</prefix>
<given>Eve</given>
<given>E.</given>
<family>Everywoman</family>
</name>
</assignedPerson>
</assignedEntity>
</informant>
Figure 107: Informant Participation entry example
7.11 INSTRUCTION OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.35(open)]
Table 139: Instruction Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Medication Prescription Event N/A
The Instruction Observation template is a generic template that is referenced by various section or entry
to enable the consistent communication of free text instructions pertaining to an identified target. The
Instruction can be used in several ways, such as to record patient instructions within a Medication Activity
or to record fill instructions within a supply order. The act/code defines the type of instruction.
The Instructions Observation template supports a coded or free text instruction, effective time and author.
The template supports the inclusion of an attachment (such as a report, image or external file) using the
Attachment template.
The target of the instruction is identified in the observation participant using the
participatnRole/code element.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
369 DSTU (Revision 2013)
Table 140: Instruction Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1584 @typeCode M:1..1
1585 @contextConductionInd M:1..1
1586 templateId O:0..* II
1587 observation O:0..*
1588 @classCode M:1..1
1589 @moodCode M:1..1
1590 Instruction Observation Code code R:1..1 CD
1591 Free Text Comment text R:1..1 ED
1592 Instruction Target participant R:1..1
1593 @typeCode M:1..1
1594 @contextControlCode O:1..1
1595 participantRole R:1..1
1596 @classCode M:1..1
1597 Target Participation Code Type of participation that is the target of the instructions. This could be the patient, another provider, the pharmacist etc.
code R:1..1 CE
An Instruction Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem: ActRelationshipType
2.16.840.1.113883.5.1002) [CONF:1584].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1585].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1586] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.35"
[CONF:1586.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1587].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1588].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1589].
c) SHALL contain exactly one (or a nullFlavor value) [1..1] code="INSTRUCT" Instruction Notes
(CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1590].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] text [CONF:1591].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] participant [CONF:1592].
i) SHALL contain exactly one [1..1] @typeCode="PRCP" primary information recipient
(CodeSystem: ParticipationType 2.16.840.1.113883.5.90) [CONF:1593].
ii) MAY contain zero or one [1..1] {CDAR2} @contextControlCode="OP" overriding
propagating (CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:1594].
iii) SHALL contain exactly one (or a nullFlavor value) [1..1] participantRole [CONF:1595].
iv) SHALL contain exactly one [1..1] @classCode="ROL" (CodeSystem: RoleClass
2.16.840.1.113883.5.110) [CONF:1596].
v) SHALL contain exactly one (or a nullFlavor value) [1..1] code, which SHALL be selected
from ValueSet InstructionTargetRole 2.16.840.1.113883.3.3068.10.8.30 STATIC [CONF:1597].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
370 DSTU (Revision 2013)
The following XML example outlines how to use the Instruction Observation template:
<!-- Instructions to Pharmacist -->
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.4.35"/> <!--Instruction
Observation-->
<code code="INSTRUCT" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Instructions"/>
<text>
Please review proper administration technique to the patient and
patient's daughter at time of dispense.
</text>
<participant typeCode="PRCP" contextControlCode="OP">
<participantRole classCode="PROV"/>
</participant>
</observation>
</entryRelationship>
<!-- Instructions to patient -->
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.4.35"/> <!--Instruction
Observation-->
<code code="INSTRUCT" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Instructions"/>
<text>
One spray every 5 minutes as needed for chest discomfort.
If pain continues for more than 15 minutes or recurs frequently, get to
emergency department ASAP.
</text>
<participant typeCode="PRCP" contextControlCode="OP">
<participantRole classCode="PAT"/>
</participant>
</observation>
</entryRelationship>
Figure 108: Instruction Observation entry example
7.12 LIFESTAGE OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.12(open)]
Table 141: Lifestage Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Allergy & Intolerance Observation N/A
Family History Observation
Problem List Observation
The Lifestage Observation template is referenced by various section or entry to enable the consistent
communication of Lifestage as a coded element.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
371 DSTU (Revision 2013)
The Lifestage Observation template supports only a coded value from the Lifestage code set.
Table 142: Lifestage Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1383 @typeCode M:1..1
1384 @contextConductionInd M:1..1
1385 templateId O:0..* II
1386 observation O:0..*
1387 @classCode M:1..1
1388 @moodCode M:1..1
1389 Lifestage Observation Code code M:1..1 CD
1390 Lifestage value value M:1..1 CD
A Lifestage Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem: ActRelationshipType
2.16.840.1.113883.5.1002) [CONF:1383].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1384].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1385] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.12"
[CONF:1385.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1386].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1387].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1388].
c) SHALL contain exactly one [1..1] code="LIFEOBS" Life Stage (CodeSystem: ObservationType-
CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1389].
d) SHALL contain exactly one [1..1] value, which SHALL be selected from ValueSet
LifeStageObservationValue 2.16.840.1.113883.3.3068.10.8.19 STATIC [CONF:1390].
The following XML example outlines how to use the Lifestage Observation template:
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.12"/> <!--Livestage
observation-->
<observation classCode="OBS" moodCode="EVN">
<code code="LIFEOBS" displayName="Lifestage Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="CD" code="133936004" displayName="Adult"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT"/>
</observation>
</entryRelationship>
Figure 109: Lifestage Observation entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
372 DSTU (Revision 2013)
7.13 LOCATION PARTICIPATION
[Participant: templateId 2.16.840.1.113883.3.1818.10.4.13(closed)]
Table 143: Location Participation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Immunization Observation N/A
Medication Administration Event
This template represents the location of a service event where an act, observation or procedure took (or
will take) place.
The intent of the Encounter Location is to communicate the service delivery location (or point of service
location) where the patient encounter occurred. There is a requirement for the Encounter Location to be
captured for internal and external encounters. There will be some instances where an External
Encounter location will not be easily identifiable when the encounter record has been manually
transferred (as a paper record) to the EMR and the paper record isn’t clear about the Encounter location;
in these cases a NullFlavor may be used (e.g. Unknown).
Table 144: Location Participation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1266 @typeCode M:1..1
1267 @contextControlCode O:1..1
1268 templateId O:0..* II
1269 participantRole O:0..*
1270 @classCode M:1..1
1271 Location identifier id R:0..1 II
1272 Location address addr R:0..1 AD
1273 Location Telecom (phone, email, url) telecom R:0..1 TEL
1274 playingEntity O:0..1
1275 @classCode M:1..1
1276 @determinerCode M:1..1
1277 Location Name name R:0..1 PN
A Location Participation (Participant) element:
1) SHALL contain exactly one [1..1] @typeCode="LOC" location (CodeSystem: ParticipationType
2.16.840.1.113883.5.90) [CONF:1266].
2) MAY contain zero or one [1..1] {CDAR2} @contextControlCode="OP" overriding propagating
(CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:1267].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1268] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.13"
[CONF:1268.12].
4) MAY contain zero or more [0..*] {CDAR2} participantRole [CONF:1269].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
373 DSTU (Revision 2013)
a) SHALL contain exactly one [1..1] @classCode="SDLOC" service delivery location (CodeSystem:
RoleClass 2.16.840.1.113883.5.110) [CONF:1270].
b) SHALL contain zero or one if available [0..1] id [CONF:1271].
c) SHALL contain zero or one if available [0..1] addr [CONF:1272] such that it,
i) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data type
constraint template (2.16.840.1.113883.3.3068.10.5.1) [CONF:1272.5].
d) SHALL contain zero or one if available [0..1] telecom [CONF:1273] such that it,
i) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data type
constraint template (2.16.840.1.113883.3.3068.10.5.2) [CONF:1273.5].
e) MAY contain zero or one [0..1] {CDAR2} playingEntity [CONF:1274].
i) SHALL contain exactly one [1..1] @classCode="PLC" place (CodeSystem: EntityClass
2.16.840.1.113883.5.41) [CONF:1275].
ii) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance (CodeSystem:
EntityDeterminer 2.16.840.1.113883.5.30) [CONF:1276].
iii) SHALL contain zero or one if available [0..1] name [CONF:1277].
The following XML example outlines how to use the Location Participation template:
<participant typeCode="LOC" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.13"/> <!-- Location
Participation -->
<participantRole classCode="SDLOC">
<playingEntity>
<name>Walk In Clinic</name>
</playingEntity>
</participantRole>
</participant>
Figure 110: Location Participation entry example
7.14 MEDICATION ADMINISTRATION EVENT
[Substance Administration: templateId 2.16.840.1.113883.3.1818.10.4.36(open)]
Table 145: Medication Administration Event Template Context
Directly Used by Template(s) Directly Contains Template(s)
Medication Dispense Event Author Participation
Comment Observation
Location Participation
The Medication Administration Event template describes substance administrations that have actually
occurred (e.g. pills ingested or injections given).
This template includes the identification of the Administering Event and would repeat for each dispense
issued for the Dispense identified in the Dispense Event Section. This template includes all the
information that may be communicated as part of a administering event.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
374 DSTU (Revision 2013)
This template is primarily relevant to use cases 3 (Provider Administered); however, it may also be
populated if the administering provider/organization has submitted the information to the EMR.
Medication timing is complex. This template requires that there be a
substanceAdministration/effectiveTime valued with a time interval, representing the start and
stop dates. Additional effectiveTime elements are optional, and can be used to represent frequency
and other aspects of more detailed dosing regimens.
Table 146: Medication Administration Event Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1528 Dose Relationship Type If there are more than one Dose Instruction within the prescription, then this element indicates if the dose instructions are sequential (dose 1 then dose 2) or concurrent (dose 1 and dose 2).
@typeCode M:1..1
1529 @contextConductionInd M:1..1
1530 templateId M:1..1 II
1531 substanceAdministration O:0..*
1532 @classCode M:1..1
1533 @moodCode M:1..1
1534 Record ID A unique identifier for the administration record.
id M:1..1 II
1535 code M:1..1 CD
1536 Administration DateAdministration Date Date/time that administration event occurred.
effectiveTime R:1..1 SXCM_TS
1537 Method /Route Code The route of administration of the drug into the patient (e.g. intradermal).
routeCode R:0..1 CE
1538 Site Code The anatomical site into which the medication is administered into the patient (e.g. Left Arm).
approachSiteCode R:0..1 CD
1539 Dose The amount of the drug administered into the patient (e.g. 3 Drops).
doseQuantity R:0..1 IVL_PQ
1540 Administration Location Administration Provider.
participant (Location
Participation)
R:1..1
1541 Administration Provider ID and Name of primary provider who administered the medication.
author (Author
Participation)
R:1..1
1542 Administration Comment Comments specific to the administration event or a particular drug to capture any contextual information regarding the administration event from the administrating provider.
entryRelationship
(Comment Observation)
R:0..1
1543 Administered Product Information consumable R:0..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
375 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1544 @typeCode M:1..1
1545 Manufactured Product manufacturedProduct R:1..1
1546 @classCode M:1..1
1547 manufacturedMaterial R:1..1
1548 Manufactured Material @classCode M:1..1
1549 @determinerCode M:1..1
1550 Lot Number The manufacturer’s lot number for the drug administered into the patient. It represents a code assigned to a package of several individual doses of a particular drug comprising a manufacturer’s unit of production.
lotNumberText R:1..1 ST
A Medication Administration Event (Substance Administration) element:
1) SHALL contain exactly one [1..1] @typeCode, which SHALL be selected from ValueSet
x_ComponentStartsBefore 2.16.840.1.113883.3.3068.10.8.12 STATIC [CONF:1528] such that it,
a) SHALL contain "SAS" if dose is sequential or "COMP" otherwise [CONF:1528.44].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1529].
3) SHALL contain exactly one [1..1] templateId [CONF:1530] such that it,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.36"
[CONF:1530.12].
4) MAY contain zero or more [0..*] {CDAR2} substanceAdministration [CONF:1531].
a) SHALL contain exactly one [1..1] @classCode="SBADM" substance administration (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1532].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1533].
c) SHALL contain exactly one [1..1] id [CONF:1534].
d) SHALL contain exactly one [1..1] code="DRUG" drug therapy (CodeSystem: ActCode
2.16.840.1.113883.5.4) [CONF:1535].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:1536].
f) SHALL contain zero or one if available [0..1] routeCode, which SHALL be selected from ValueSet
RouteOfAdministration 2.16.840.1.113883.2.20.3.188 STATIC [CONF:1537].
g) SHALL contain zero or one if available [0..1] approachSiteCode, which SHALL be selected from
ValueSet HumanSubstanceAdministrationSite 2.16.840.1.113883.2.20.3.52 DYNAMIC [CONF:1538].
h) SHALL contain zero or one if available [0..1] doseQuantity [CONF:1539].
i) SHALL contain exactly one (or a nullFlavor value) [1..1] participant [CONF:1540] such that
it,
i) SHALL contain exactly one [1..1] Location Participation
(2.16.840.1.113883.3.1818.10.4.13) [CONF:1540.1].
j) SHALL contain exactly one (or a nullFlavor value) [1..1] author [CONF:1541] such that it,
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1541.1].
k) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1542] such that it,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
376 DSTU (Revision 2013)
i) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:1542.1].
l) SHALL contain zero or one if available [0..1] consumable [CONF:1543].
i) SHALL contain exactly one [1..1] @typeCode="CSM" consumable (CodeSystem:
ParticipationType 2.16.840.1.113883.5.90) [CONF:1544].
ii) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} manufacturedProduct
[CONF:1545].
(1) SHALL contain exactly one [1..1] @classCode="MANU" manufactured product
(CodeSystem: RoleClass 2.16.840.1.113883.5.110) [CONF:1546].
(2) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2}
manufacturedMaterial [CONF:1547].
(a) SHALL contain exactly one [1..1] @classCode="MMAT" manufactured material
(CodeSystem: EntityClass 2.16.840.1.113883.5.41) [CONF:1548].
(b) SHALL contain exactly one [1..1] @determinerCode="KIND" kind (CodeSystem:
EntityDeterminer 2.16.840.1.113883.5.30) [CONF:1549].
(c) SHALL contain exactly one (or a nullFlavor value) [1..1] lotNumberText
[CONF:1550].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
377 DSTU (Revision 2013)
The following XML example outlines how to use the Medication Administration Event template:
<!-- Administration Event -->
<entryRelationship typeCode="SAS" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.36"/> <!-- Medication
Acministration Event -->
<substanceAdministration classCode="SBADM" moodCode="EVN">
<id extension="BC20120201RXO-1458756BN"
root="2.16.840.1.113883.3.1818.10.10.3"/>
<code code="DRUG" codeSystem="2.16.840.1.113883.5.4" displayName="Drug
Therapy"/>
<!-- Administered Date -->
<effectiveTime value="20130211"/>
<routeCode></routeCode>
<approachSiteCode></approachSiteCode>
<doseQuantity></doseQuantity>
<!-- Administred Product Information -->
<consumable typeCode="CSM">
<manufacturedProduct classCode="MANU">
<manufacturedMaterial classCode="MMAT" determinerCode="KIND">
<lotNumberText>123</lotNumberText>
</manufacturedMaterial>
</manufacturedProduct>
</consumable>
<!-- Administration Provider -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Mrs. Grace Nurse</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Administering Location -->
<participant typeCode="LOC" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.13"/> <!-- Location
Participation -->
<participantRole classCode="SDLOC">
<playingEntity>
<name>Walk In Clinic</name>
</playingEntity>
</participantRole>
</participant>
<!-- Administration Comment -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment
Observation -->
<observation classCode="OBS" moodCode="EVN">
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
378 DSTU (Revision 2013)
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="ST">Hypotension due to administration for
ACS.</value>
</observation>
</entryRelationship>
</substanceAdministration>
</entryRelationship>
Figure 111: Medication Administration Event entry example
7.15 MEDICATION DISPENSE EVENT
[Supply: templateId 2.16.840.1.113883.3.1818.10.4.7(open)]
Table 147: Medication Dispense Event Template Context
Directly Used by Template(s) Directly Contains Template(s)
Medication Prescription Event Medication Administration Event
Medication Fill Interval
Performer Participation
This Medication Dispense Event template defines the structure and format rules for each dispensing
event that occurs against a medication order or prescription. This template will repeat for each dispense
issued for the Prescription identified in the Prescription Event template. This template includes all the
information that may be communicated as part of a dispensing event including the specific DIN Code for
the product dispensed.
This Medication Dispense Event template includes the identification of the Dispense Event and would
repeat for each dispense issued for the Prescription identified in the Prescription Event Section. This
template includes all the information that may be communicated as part of a dispensing event including
the specific DIN Code for the product dispensed.
This template is primarily relevant to use cases 2 (Provider Dispensed) and 3 (Provider Administered);
however, it may also be populated if the dispensing organization has submitted the information to the
EMR.
Table 148: Medication Dispense Event Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1508 @typeCode M:1..1
1509 @contextConductionInd M:1..1
1510 templateId M:1..1 II
1511 Dispense Record supply M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
379 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1512 @classCode M:1..1
1513 @moodCode M:1..1
1514 Record ID A unique identifier for the dispense record.
id M:1..1 II
1515 Dispense Date Date/time that the dispense event occurred.
effectiveTime M:1..1 SXCM_TS
1516 Dispensed Quantity The quantity of medication that was dispensed (e.g. 2 tablets).
quantity M:1..1 PQ
1517 Dispensing Organization The organization and location where the dispense event occurred (e.g. Xyz Pharmacy, In-Clinic) .
performer (Performer
Participation)
R:0..1
1518 Dispense Medication The identification of the actual medication dispensed.
product R:0..1
1519 @typeCode M:1..1
1520 manufacturedProduct M:1..1
1521 @classCode M:1..1
1522
manufacturedLabeledDrug
M:1..1
1523 @classCode M:1..1
1524 @determinerCode M:1..1
1525 Dispensed Drug Code The code of the product actually dispensed.
code M:1..1 CE
1526 Fill Interval The amount of time that has elapsed between this and the previous dispense events for refill prescriptions (e.g. 30 days).
entryRelationship
(Medication Fill
Interval)
R:0..1
1527 Administration Event entryRelationship
(Medication
Administration Event)
R:0..*
A Medication Dispense Event (Supply) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1508].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1509].
3) SHALL contain exactly one [1..1] templateId [CONF:1510] such that it,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.7"
[CONF:1510.12].
4) SHALL contain exactly one [1..1] supply [CONF:1511].
a) SHALL contain exactly one [1..1] @classCode="SPLY" supply (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1512].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1513].
c) SHALL contain exactly one [1..1] id [CONF:1514] such that it,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
380 DSTU (Revision 2013)
i) SHALL be the identifier assigned to the dispense by the Pharmanet system for senders who are connected and for dispenses that have been sent to or originated from Pharmanet; sending systems that are not connected to Pharmanet SHALL send an internal record identifier. In either case the applicable Assigning Authority SHALL be sent [CONF:1514.42].
d) SHALL contain exactly one [1..1] effectiveTime [CONF:1515].
e) SHALL contain exactly one [1..1] quantity [CONF:1516].
f) SHALL contain zero or one if available [0..1] performer [CONF:1517] such that it,
i) SHALL contain exactly one [1..1] Performer Participation
(2.16.840.1.113883.3.1818.10.4.19) [CONF:1517.1].
g) SHALL contain zero or one if available [0..1] product [CONF:1518].
i) SHALL contain exactly one [1..1] @typeCode="PRD" product (CodeSystem:
ParticipationType 2.16.840.1.113883.5.90) [CONF:1519].
ii) SHALL contain exactly one [1..1] manufacturedProduct [CONF:1520].
(1) SHALL contain exactly one [1..1] @classCode="MANU" manufactured product
(CodeSystem: RoleClass 2.16.840.1.113883.5.110) [CONF:1521].
(2) SHALL contain exactly one [1..1] manufacturedLabeledDrug [CONF:1522].
(a) SHALL contain exactly one [1..1] @classCode="MMAT" manufactured material
(CodeSystem: EntityClass 2.16.840.1.113883.5.41) [CONF:1523].
(b) SHALL contain exactly one [1..1] @determinerCode="KIND" kind (CodeSystem:
EntityDeterminer 2.16.840.1.113883.5.30) [CONF:1524].
(c) SHALL contain exactly one [1..1] code, which SHALL be selected from ValueSet
ClinicalDrug 2.16.840.1.113883.2.20.3.29 DYNAMIC [CONF:1525].
h) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1526] such that it,
i) SHALL contain exactly one [1..1] Medication Fill Interval
(2.16.840.1.113883.3.1818.10.4.11) [CONF:1526.1].
i) SHALL contain zero or more if available [0..*] entryRelationship [CONF:1527] such that each,
i) SHALL contain exactly one [1..1] Medication Administration Event
(2.16.840.1.113883.3.1818.10.4.36) [CONF:1527.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
381 DSTU (Revision 2013)
The following XML example outlines how to use the Medication Dispense Event template:
<!-- Dispense Record -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.7"/> <!--Dispense Event --
>
<supply classCode="SPLY" moodCode="EVN">
<id extension="BC20120201RXO-1458756BN"
root="2.16.840.1.113883.3.1818.10.10.3"/>
<!-- Dispense Date -->
<effectiveTime value="20130211"/>
<quantity value="1"/>
<!-- Dispensed Medication -->
<product typeCode="PRD">
<manufacturedProduct classCode="MANU">
<manufacturedLabeledDrug classCode="MMAT" determinerCode="KIND">
<code code="02243588" displayName="MYLAN-NITRO SUBLINGUAL SPRAY"
codeSystem="2.16.840.1.113883.5.1105" codeSystemName="hcDIN"/>
</manufacturedLabeledDrug>
</manufacturedProduct>
</product>
<!--Dispensing Organization -->
<performer typeCode="PRF">
<templateId root="2.16.840.1.113883.3.1818.10.4.19"/> <!-- Performer
Participation -->
<time value="20130211"/>
<assignedEntity classCode="ASSIGNED">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<code code="180000000X" displayName="Pharmacy"
codeSystem="2.16.840.1.113883.5.111" codeSystemName="HL7 RoleCode" />
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name use="L">Mr. P. Scriber</name>
</assignedPerson>
<representedOrganization>
<name>Mainstreet Pharmacy</name>
</representedOrganization>
</assignedEntity>
</performer>
<!-- Fill Interval -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.11"/> <!-- Medication
Fill Interval -->
<observation classCode="OBS" moodCode="EVN">
<code code="FILLINT" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Fill Interval"/>
<text>30 days</text>
<value xsi:type="PQ" value="30" unit="d"/>
</observation>
</entryRelationship>
<!-- Administration Event -->
<entryRelationship typeCode="SAS" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.36"/> <!-- Medication
Acministration Event -->
...
</entryRelationship>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
382 DSTU (Revision 2013)
</supply>
</entryRelationship>
Figure 112: Medication Dispense Event entry example
7.16 MEDICATION FILL INTERVAL
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.11(open)]
Table 149: Medication Fill Interval Template Context
Directly Used by Template(s) Directly Contains Template(s)
Dispense Request (first fill) N/A
Dispense Request (part fill)
Dispense Request (refill)
Medication Dispense Event
The Medication Fill Interval template is a generic template that is referenced by dispense request
templates. It template supports the communication of the amount of time that must elapse between
dispense events for prescriptions. Whist it is expected that the fill interval will be provided in a structured
format in the observation/value element (e.g. 30 days); this template also supports free text fill interval
instructions.
Table 150: Medication Fill Interval Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1637 @typeCode M:1..1
1638 @contextConductionInd M:1..1
1639 templateId O:0..* II
1640 observation O:0..*
1641 @classCode M:1..1
1642 @moodCode M:1..1
1643 Fill Interval Observation Code code R:1..1 CD
1644 Free Text Fill Interval text R:1..1 ED
1645 Fill Interval Value value R:1..1 PQ
A Medication Fill Interval (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem: ActRelationshipType
2.16.840.1.113883.5.1002) [CONF:1637].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1638].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1639] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.11"
[CONF:1639.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1640].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
383 DSTU (Revision 2013)
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1641].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1642].
c) SHALL contain exactly one (or a nullFlavor value) [1..1] code="FILLINT" Fill Interval
(CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1643].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] text [CONF:1644].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] value [CONF:1645].
The following XML example outlines how to use the Medication Fill Interval template:
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.11"/> <!-- Medication
Fill Interval -->
<observation classCode="OBS" moodCode="EVN">
<code code="FILLINT" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Fill Interval"/>
<text>30 days</text>
<value xsi:type="PQ" value="30" unit="d"/>
</observation>
</entryRelationship>
Figure 113: Medication Fill Interval entry example
7.17 MEDICATION IDENTIFICATION
[Consumable: templateId 2.16.840.1.113883.3.1818.10.4.16(closed)]
Table 151: Medication Identification Template Context
Directly Used by Template(s) Directly Contains Template(s)
Dose Observation N/A
Medication Event
Medication Prescription Event
The Medication Identification List template defines the structure to identify the specific drug and drug
strength that is the subject of the Medication List record as defined in the Medication Observation
template.
CDA Extensions
This template includes the following CDA Extensions:
Drug Description: The Drug Description (LabeledDrug/e2e:desc)has been added to the
schema to support a free form textual description of the drug. This is usually only populated for
custom compounds, providing instructions on the composition and creation of the compound.
Drug Form: The Drug Form (LabeledDrug/e2e:formCode) has been added to the schema
communicate the administration form of the drug (e.g. tablet, capsule, powder, etc.).
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
384 DSTU (Revision 2013)
Drug Ingredient: Frequently the drug strength is assumed to be included in or implied by the drug
code itself. For example, there is a specific DIN code for TYLENOL 325 mg tablet (00723894).
However, the specification supports the communication of the drug strength attribute as a separate
element to accommodate historical or patient reported data that may not be coded or may not have
the strength pre-coordinated in the drug code or implied through the drug name.
Amalgamated drug Names
Some systems (e.g. FDB) include the drug strength and form in the name of the drug (e.g. Tylenol 300mg
tablet). The PITO Specification includes as three distinct fields - Drug Name, Strength and Form. The
sending system SHALL include the strength and form in the distinct fields for these values. The Name
element MAY be populated with just the name (e.g. “Tylenol)”, or MAY include the strength and form.
Generic Name
The Generic Name is used to communicate the generic ingredients that are included in the drug. This is
included as the <translation> component of the Drug Code element which may repeat.
In some cases there will be multiple generic named ingredients within the drug; for example, Tylenol 3
has acetaminophen 300mg and codeine 30mg and caffeine as generic ingredients. This element is a
string format and there are no requirements for the display of the ingredient name, strength and units of
measure; however, it is strongly recommended that the element repeat with each ingredient included in
its own repetition. Having this recorded as a single text string causes difficulties for calculating defined
daily dose when a medication formulation consists of a combination of different drugs.
This field may be absent if a DIN code is provided as the receiving system may use the DIN code to
identify the component generic ingredients.
Drug Description
The Drug Description is a free form textual description of the drug. This usually is only populated for
custom compounds, providing instructions on the composition and creation of the compound.
This field may also be used to provide more detailed and supplemental information regarding the Drug;
however, dispensing and administration instructions should not be included here as there are specific
instruction fields for that information.
Table 152: Medication Identification Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1551 @typeCode M:1..1
1552 templateId M:1..1 II
1553 Manufactured Product manufacturedProduct R:1..1
1554 @classCode M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
385 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1555 Manufactured Labeled Drug manufacturedLabeledDrug R:1..1
1556 @classCode M:1..1
1557 @determinerCode M:1..1
1558 Drug Code Drug Identification code.
code R:1..1 CE
1559 Drug Name The name or short description for the drug as entered by the provider. This will accommodate use case where drug is un-coded (free text). This may be a generic name, a specific drug name or a non-formulary name.
name R:1..1 EN
1560 Drug Description A free form textual description of the drug.
e2e:desc O:0..1
1561 Drug Form Drug form from the Health Canada Drug Products Database (DPD) when DIN is provided, else the coded form of the drug presentation as entered by the provider (e.g. tablet, capsule).
e2e:formCode O:0..1
4325 Drug Ingredient Identification of which ingredients are contained (or are not contained) in a drug, along with their respective quantities.
e2e:ingredient O:0..50
4326 e2e:@classCode M:1..1
4327 Drug Ingredient Quantity Drug strength from the drug database when DIN is provided, else the Physical Quantity (includes amount and units: of mass or volume appropriate to drug quantities) as entered by the provider (e.g. 20mg).
e2e:quantity R:0..1
4328 Ingredient Substance A drug, chemical or excipient that may be present in a manufactured drug or a custom compound.
e2e:ingredient R:1..1
4329 e2e:@classCode M:1..1
4330 e2e:@determinerCode M:1..1
4331 Ingredient Code The unique identifier for the drug or chemical.
e2e:code O:0..1
4332 Ingredient Name The name of the contained drug or chemical. Used for communication between and display to providers.
e2e:name O:0..1
A Medication Identification (Consumable) element:
1) SHALL contain exactly one [1..1] @typeCode="CSM" consumable (CodeSystem: ParticipationType
2.16.840.1.113883.5.90) [CONF:1551].
2) SHALL contain exactly one [1..1] templateId [CONF:1552] such that it,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
386 DSTU (Revision 2013)
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.16"
[CONF:1552.12].
3) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} manufacturedProduct
[CONF:1553].
a) SHALL contain exactly one [1..1] @classCode="MANU" manufactured product (CodeSystem:
RoleClass 2.16.840.1.113883.5.110) [CONF:1554].
b) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2}
manufacturedLabeledDrug [CONF:1555].
i) SHALL contain exactly one [1..1] @classCode="MMAT" manufactured material (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:1556].
ii) SHALL contain exactly one [1..1] @determinerCode="KIND" kind (CodeSystem:
EntityDeterminer 2.16.840.1.113883.5.30) [CONF:1557].
iii) SHALL contain exactly one (or a nullFlavor value) [1..1] code, which SHALL be selected
from ValueSet ClinicalDrug 2.16.840.1.113883.2.20.3.29 DYNAMIC [CONF:1558].
iv) SHALL contain exactly one (or a nullFlavor value) [1..1] name [CONF:1559].
v) MAY contain zero or one [0..1] e2e:desc (CDA R2 Extension) [CONF:1560].
vi) MAY contain zero or one [0..1] e2e:formCode (CDA R2 Extension) [CONF:1561].
vii) MAY contain zero to 50 [0..50] e2e:ingredient (CDA R2 Extension) [CONF:4325].
(1) SHALL contain exactly one [1..1] e2e:@classCode="INGR" ingredient (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) (CDA R2 Extension) [CONF:4326].
(2) SHALL contain zero or one if available [0..1] e2e:quantity (CDA R2 Extension)
[CONF:4327].
(3) SHALL contain exactly one (or a nullFlavor value) [1..1] e2e:ingredient (CDA R2
Extension) [CONF:4328].
(a) SHALL contain exactly one [1..1] e2e:@classCode="MMAT" manufactured material
(CodeSystem: EntityClass 2.16.840.1.113883.5.41) (CDA R2 Extension) [CONF:4329].
(b) SHALL contain exactly one [1..1] e2e:@determinerCode="KIND" kind
(CodeSystem: EntityDeterminer 2.16.840.1.113883.5.30) (CDA R2 Extension) [CONF:4330].
(c) MAY contain zero or one [0..1] e2e:code, which SHALL be selected from ValueSet
ClinicalDrug 2.16.840.1.113883.2.20.3.29 DYNAMIC (CDA R2 Extension) [CONF:4331].
(d) MAY contain zero or one [0..1] e2e:name (CDA R2 Extension) [CONF:4332].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
387 DSTU (Revision 2013)
The following XML example outlines how to use the Medication Identification template:
<consumable typeCode="CSM">
<templateId root="2.16.840.1.113883.3.1818.10.4.16"/> <!--Medication
Identification-->
<manufacturedProduct classCode="MANU">
<manufacturedLabeledDrug>
<code code="02243588" displayName="MYLAN-NITRO SUBLINGUAL SPRAY"
codeSystem="2.16.840.1.113883.5.1105" codeSystemName="hc-DIN"/>
<name>Nitrospray</name>
<e2e:desc>NITROGLYCERIN 0.4 mg/dose SPRAY, NON-AEROSOL (GRAM)</e2e:desc>
<e2e:formCode code="SPRAY" displayName="Spray"
codeSystem="2.16.840.1.113883.19.5.3" codeSystemName="HL7 Orderable Drug Form"/>
<e2e:ingredient classCode="INGR">
<e2e:quantity value="0.4" unit="mg"/>
<e2e:ingredient classCode="MMAT" determinerCode="KIND">
<e2e:code code="TBD" displayName="Nitro" codeSystem="tbd"
codeSystemName="ClinicalDrug"/>
<e2e:name> NITROGLYCERIN </e2e:name>
</e2e:ingredient>
</e2e:ingredient>
</manufacturedLabeledDrug>
</manufacturedProduct>
</consumable>
Figure 114: Medication Identification entry example
7.18 MEDICATION PRESCRIPTION EVENT
[Substance Administration: templateId 2.16.840.1.113883.3.1818.10.4.20(open)]
Table 153: Medication Prescription Event Template Context
Directly Used by Template(s) Directly Contains Template(s)
Medication Event Author Participation
Dispense Request (first fill)
Dispense Request (part fill)
Dispense Request (refill)
Dose Observation
Instruction Observation
Medication Dispense Event
Medication Identification
Order Indicator
Reason Observation
Record ID Link
The Medication Prescription Event template defines the structure and format rules for the details of a
medication record and will repeat for each prescription against a medication record. This template
includes, or references other templates that include, the information specific to the prescription or
medication order such as the dosing instructions, medication timing, instructions to the patient and
pharmacist as well as structured dispensing instructions.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
388 DSTU (Revision 2013)
This Medication Prescription Event template includes the identification of the Prescription Event and may
repeat for each prescription issued for the Drug identified in the Medication List Record. This template
includes the detailed level information about the medication as prescribed, or as reported as well as all
the information that may be communicated as part of a prescription, or known about the consumption of
the medication, including instructions regarding refills, part-fills and administration.
While the EMR should be able to generate prescriptions that are complete the data in the prescription
should provide the pharmacist with unambiguous instructions on the medication to be prescribed. If some
data elements are missing it should be possible to infer the missing data based on the information
provided.
Referring back to the use cases described in the Medications & Prescriptions - Medication List section
template, use-case 4 (Patient Reported) and use-case 5 (Provider Reported); the actual prescription may
not be captured in the EMR; however, the detailed information about the medication use (dosage,
frequency, form etc.) may still be communicated in this template.
Table 154: Medication Prescription Event Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1486 @typeCode M:1..1
1487 @contextConductionInd M:1..1
1488 templateId M:1..1 II
1489 Prescription Record substanceAdministration M:1..1
1490 @classCode M:1..1
1491 @moodCode M:1..1
1492 Record ID A unique ID of the Prescription record.
id M:1..1 II
1493 code M:1..1 CD
1494 Start/Stop Date The start/stop date of any medication administration as specified in the prescription.
effectiveTime R:1..1 SXCM_TS
4362 Drug Information The specific drug and drug strength that is the subject of the Medication List record.
consumable (Medication
Identification)
M:1..1
1495 Prescribing Provider Clinician responsible for prescription.
author (Author
Participation)
R:1..1
1496 Dose Instructions Sepcific dosing instructions component of the prescription. (e.g. 1 pill twice a day and two pills at bed time) (e.g. 1 pill for 2 days then 3 pills for 10.
entryRelationship (Dose
Observation)
R:0..*
1497 Prior Prescription Record ID If the current prescription is a subsequent prescription for the Medication Record, this element will contain the Record ID of
entryRelationship
(Record ID Link)
O:0..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
389 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
previous prescription on that Medication Record.
1498 Stop Reason The reason for stopping the prescription.
entryRelationship
(Reason Observation)
R:0..*
1499 Order Indicators Used to communicate various order indicators such as PRN (pro re nata or "as needed"), "Do Not Adapt", and "Do Not Substitute".
entryRelationship (Order
Indicator)
R:0..*
1502 First Dispense Instructions The initial dispense requirements as part of the prescription.
entryRelationship
(Dispense Request (first
fill))
R:0..1
1503 Part-Fill Dispense Instructions Part-Fill instructions as part of the prescription.
entryRelationship
(Dispense Request (part
fill))
R:0..1
1504 Refill Dispense Instructions Re-Fill instructions as part of the prescription.
entryRelationship
(Dispense Request
(refill))
R:0..1
1505 Instructions to Pharmacist Prescriber instructions to the pharmacist. Populated for custom compounds, providing instructions on the composition and creation of the compound. May also be used to request specific packaging (e.g. compliance packaging / blister packs).
entryRelationship
(Instruction Observation)
R:0..1
1506 Instructions to Patient Instructions the prescriber may attach to the prescription record to communicate with the patient (e.g. directions of use). These instructions are targeted to the subject taking the medication. (e.g. To be taken on an empty stomach).
entryRelationship
(Instruction Observation)
R:0..1
1507 Dispense Event entryRelationship
(Medication Dispense
Event)
R:0..1
A Medication Prescription Event (Substance Administration) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1486].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1487].
3) SHALL contain exactly one [1..1] templateId [CONF:1488] such that it,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.20"
[CONF:1488.12].
4) SHALL contain exactly one [1..1] substanceAdministration [CONF:1489].
a) SHALL contain exactly one [1..1] @classCode="SBADM" substance administration (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1490].
b) SHALL contain exactly one [1..1] @moodCode="RQO" request (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1491].
c) SHALL contain exactly one [1..1] id [CONF:1492] such that it,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
390 DSTU (Revision 2013)
i) SHALL be the identifier assigned to the prescription by the Pharmanet system for senders who are connected and for prescriptions that have been sent to or originated from Pharmanet; sending systems that are not connected to Pharmanet SHALL send an internal record identifier. In either case the applicable Assigning Authority SHALL be sent. [CONF:1492.41].
d) SHALL contain exactly one [1..1] code="DRUG" drug therapy (CodeSystem: ActCode
2.16.840.1.113883.5.4) [CONF:1493].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:1494] such
that it,
i) SHALL contain exactly one [1..1] low value to indicate the Start Date/Time and MAY contain
zero or one [0..1] high values to indicate the End Date/Time [CONF:1494.50].
f) SHALL contain exactly one [1..1] consumable [CONF:4362] such that it,
i) SHALL contain exactly one [1..1] Medication Identification
(2.16.840.1.113883.3.1818.10.4.16) [CONF:4362.1].
g) SHALL contain exactly one (or a nullFlavor value) [1..1] author [CONF:1495] such that it,
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1495.1].
h) SHALL contain zero or more if available [0..*] entryRelationship [CONF:1496] such that each,
i) SHALL contain exactly one [1..1] Dose Observation
(2.16.840.1.113883.3.1818.10.4.8) [CONF:1496.1].
i) MAY contain zero or one [0..1] entryRelationship [CONF:1497] such that it,
i) SHALL contain exactly one [1..1] Record ID Link
(2.16.840.1.113883.3.1818.10.4.38) [CONF:1497.1].
j) SHALL contain zero or more if available [0..*] entryRelationship [CONF:1498] such that each,
i) SHALL contain exactly one [1..1] Reason Observation
(2.16.840.1.113883.3.1818.10.4.24) [CONF:1498.1].
k) SHALL contain zero or more if available [0..*] entryRelationship [CONF:1499] such that each,
i) SHALL contain exactly one [1..1] Order Indicator
(2.16.840.1.113883.3.1818.10.4.37) [CONF:1499.1].
l) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1502] such that it,
i) SHALL contain exactly one [1..1] Dispense Request (first fill)
(2.16.840.1.113883.3.1818.10.4.14) [CONF:1502.1].
m) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1503] such that it,
i) SHALL contain exactly one [1..1] Dispense Request (part fill)
(2.16.840.1.113883.3.1818.10.4.33) [CONF:1503.1].
n) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1504] such that it,
i) SHALL contain exactly one [1..1] Dispense Request (refill)
(2.16.840.1.113883.3.1818.10.4.34) [CONF:1504.1].
o) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1505] such that it,
i) SHALL contain exactly one [1..1] Instruction Observation
(2.16.840.1.113883.3.1818.10.4.35) [CONF:1505.1].
p) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1506] such that it,
i) SHALL contain exactly one [1..1] Instruction Observation
(2.16.840.1.113883.3.1818.10.4.35) [CONF:1506.1].
q) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1507] such that it,
i) SHALL contain exactly one [1..1] Medication Dispense Event
(2.16.840.1.113883.3.1818.10.4.7) [CONF:1507.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
391 DSTU (Revision 2013)
The following XML example outlines how to use the Medication Prescription Event template:
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.20" /> <!-- Medication
Prescription Event-->
<substanceAdministration classCode="SBADM" moodCode="RQO">
<id extension="BC20120201RXO-1458756BN"
root="2.16.840.1.113883.3.1818.10.10.3"/>
<code code="DRUG" codeSystem="2.16.840.1.113883.5.4" displayName="Drug
Therapy"/>
<!-- Start/Stop Date -->
<effectiveTime xsi:type="IVL_TS" operator="I">
<low value="20130211"/>
<high value="20130212"/>
</effectiveTime>
<consumable typeCode="CSM">
<templateId root="2.16.840.1.113883.3.1818.10.4.16"/> <!--Medication
Identification-->
…
</consumable>
<!-- Prescribing Provider -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Dose Instructions -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.8"/> <!--Dose Observation-
-> …
</entryRelationship>
<!-- Prior Prescription Record ID -->
<entryRelationship typeCode="SUBJ">
<templateId root="2.16.840.1.113883.3.1818.10.4.38"/> <!-- Record ID Link
-->
<observation classCode="OBS" moodCode="EVN">
<id extension="12779999" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<code code="RECLINK" displayName="Record Link Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending"/>
</observation>
</entryRelationship>
<!-- Stop Reason -->
<entryRelationship typeCode="RSON" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> <!-- Reason
Observation -->
<observation classCode="OBS" moodCode="EVN">
<id nullFlavor="NA"/>
<code code="REASON" displayName="Reason Observation"
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
392 DSTU (Revision 2013)
codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending"/>
<text>Stop administration of spray if patient experiences problems
swollowing.</text>
<effectiveTime value="20120201"/>
<value xsi:type="CD" code="288936000" displayName="Able to swallow
(finding)"
codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-
CT"/>
</observation>
</entryRelationship>
<!-- PRN -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.37"/> <!-- Order
Indicator-->
<observation classCode="OBS" moodCode="EVN">
<code code="PRNIND" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="PRN Indicator"/>
<value xsi:type="BL" value="true"/>
</observation>
</entryRelationship>
<!-- Adapt Not Allowed Indicator -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.37"/> <!--Order Indicator-
->
<observation classCode="OBS" moodCode="EVN">
<code code="ADPIND" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Adapt Not
Allowed Indicator"/>
<value xsi:type="BL" value="false"/>
</observation>
</entryRelationship>
<!-- Substitute Not Allowed Indicator -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.37"/> <!--Order Indicator-
->
<observation classCode="OBS" moodCode="EVN">
<code code="SUBIND" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Substitute Not
Allowed Indicator"/>
<value xsi:type="BL" value="false"/>
</observation>
</entryRelationship>
<!-- Part Fill Dispense Instructions -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.33"/> <!--Dispense Request
(part fill)-->
<supply classCode="SPLY" moodCode="RQO">
<code code="FFP" codeSystem="2.16.840.1.113883.5.4" displayName="Partial
First Fill"
codeSystemName="Hl7 Act Code"/>
<quantity value="10"/>
<expectedUseTime>
<width value="5" unit="d"/>
</expectedUseTime>
<entryRelationship typeCode="COMP" contextConductionInd="true">
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
393 DSTU (Revision 2013)
<templateId root="2.16.840.1.113883.3.1818.10.4.11"/> <!-- Medication
Fill Interval -->
<observation classCode="OBS" moodCode="EVN">
<code code="FILLINT" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Fill Interval"/>
<text>5 per day</text>
<value xsi:type="PQ" value="5" unit="d"/>
</observation>
</entryRelationship>
</supply>
</entryRelationship>
<!-- First Dispense Instructions -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.14"/> <!-- Dispense
Request (first fill) -->
<supply classCode="SPLY" moodCode="RQO">
<code code="FF" codeSystem="2.16.840.1.113883.5.4" displayName="Partial
First Fill"
codeSystemName="Hl7 Act Code"/>
<quantity value="10"/>
<expectedUseTime>
<width value="5" unit="d"/>
</expectedUseTime>
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.11"/> <!-- Medication
Fill Interval -->
<observation classCode="OBS" moodCode="EVN">
<code code="FILLINT" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Fill Interval"/>
<text>3 days</text>
<value xsi:type="PQ" value="3" unit="d"/>
</observation>
</entryRelationship>
</supply>
</entryRelationship>
<!-- Refill Dispense Instructions -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.34"/> <!--Dispense
Request (Refills)-->
<supply classCode="SPLY" moodCode="RQO">
<code code="RF" codeSystem="2.16.840.1.113883.5.4" displayName="Refills"
codeSystemName="Hl7 Act Code"/>
<repeatNumber value="1"/>
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.11"/> <!-- Medication
Fill Interval -->
<observation classCode="OBS" moodCode="EVN">
<code code="FILLINT" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Fill Interval"/>
<text>30 days</text>
<value xsi:type="PQ" value="30" unit="d"/>
</observation>
</entryRelationship>
</supply>
</entryRelationship>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
394 DSTU (Revision 2013)
<!-- Instructions to Pharmacist -->
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.4.35"/> <!--Instruction
Observation-->
<code code="INSTRUCT" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Instructions"/>
<text>
Please review proper administration technique to the patient and
patient's daughter at time of dispense.
</text>
<participant typeCode="PRCP" contextControlCode="OP">
<participantRole classCode="PROV"/>
</participant>
</observation>
</entryRelationship>
<!-- Instructions to patient -->
<entryRelationship typeCode="SUBJ" inversionInd="true">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.4.35"/> <!--Instruction
Observation-->
<code code="INSTRUCT" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Instructions"/>
<text>
One spray every 5 minutes as needed for chest discomfort.
If pain continues for more than 15 minutes or recurs frequently, get to
emergency department ASAP.
</text>
<participant typeCode="PRCP" contextControlCode="OP">
<participantRole classCode="PAT"/>
</participant>
</observation>
</entryRelationship>
<!-- Dispense Record -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.7"/> <!--Dispense Event --
>
…
</entryRelationship>
</substanceAdministration>
</entryRelationship>
</substanceAdministration>
Figure 115: Medication Prescription Event entry example
7.19 ORDER INDICATOR
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.37(open)]
Table 155: Order Indicator Template Context
Directly Used by Template(s) Directly Contains Template(s)
Medication Prescription Event N/A
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
395 DSTU (Revision 2013)
The Order Indicator template is used to communicate specific order related instructions such as PRN (pro
re nata or as needed), Do not Adapt and Do not Substitute.
The Medication Observation template supports Yes/No response values for a specific set of order related
coded observations.
Table 156: Order Indicator Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1562 @typeCode M:1..1
1563 @contextConductionInd M:1..1
1564 @InversionInd O:0..1
1565 templateId O:0..* II
1566 observation O:0..*
1567 @classCode M:1..1
1568 @moodCode M:1..1
1569 Order Indicator Observation Code code R:1..1 CD
1571 Order Indicator Observation Value value O:0..* bl
An Order Indicator (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem: ParticipationType
2.16.840.1.113883.5.90) [CONF:1562].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1563].
3) MAY contain zero or one [0..1] {CDAR2} @InversionInd="true" [CONF:1564].
4) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1565] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.37"
[CONF:1565.12].
5) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1566].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1567].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1568].
c) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} code [CONF:1569].
d) MAY contain zero or more [0..*] {CDAR2} value [CONF:1571].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
396 DSTU (Revision 2013)
The following XML example outlines how to use the Order Indicator template:
<!-- PRN -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.37"/> <!-- Order
Indicator-->
<observation classCode="OBS" moodCode="EVN">
<code code="PRNIND" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="PRN Indicator"/>
<value xsi:type="BL" value="true"/>
</observation>
</entryRelationship>
<!-- Adapt Not Allowed Indicator -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.37"/> <!--Order Indicator-
->
<observation classCode="OBS" moodCode="EVN">
<code code="ADPIND" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Adapt Not Allowed
Indicator"/>
<value xsi:type="BL" value="false"/>
</observation>
</entryRelationship>
<!-- Substitute Not Allowed Indicator -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.37"/> <!--Order Indicator-
->
<observation classCode="OBS" moodCode="EVN">
<code code="SUBIND" codeSystem="2.16.840.1.113883.3.3068.10.6.3"
codeSystemName="ObservationType-CA-Pending" displayName="Substitute Not Allowed
Indicator"/>
<value xsi:type="BL" value="false"/>
</observation>
</entryRelationship>
Figure 116: Order Indicator entry example
7.20 OUTCOME OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.18(open)]
Table 157: Outcome Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Care History Event Attachment
Order Event Author Participation
The Outcome Observation template is a generic comment template that is referenced by various section
or entry templates to enable the consistent communication of an outcome observation. Outcomes are
free text or coded observations that are the result of an activity, procedure or event.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
397 DSTU (Revision 2013)
The Outcome Observation template supports a coded or free text outcome, effective time and author.
The template also supports the inclusion of an attachment (such as a report, image or external file) using
the Attachment template.
Table 158: Outcome Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1361 @typeCode M:1..1
1362 @contextConductionInd M:1..1
1363 templateId O:0..* II
1364 observation O:0..*
1365 @classCode M:1..1
1366 @moodCode M:1..1
1367 Result Record ID Record identifier for this outcome observation.
id R:0..* II
1368 Outcome Observation Code code R:1..1 CD
1369 Free Text Outcome value text R:0..1 ED
1370 Outcome Effective Time effectiveTime R:0..1 IVL_TS
1371 Coded Outcome value value R:0..1 CD
1372 Outcome Attachments Any attached files. This includes any external document references and external result report files.
entryRelationship
(Attachment)
O:0..*
1373 Outcome Author author (Author
Participation)
O:0..*
An Outcome Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem: ActRelationshipType
2.16.840.1.113883.5.1002) [CONF:1361].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1362].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1363] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.18"
[CONF:1363.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1364].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1365].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1366].
c) SHALL contain zero or more if available [0..*] id [CONF:1367].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] code="OUTCOBS" Outcome
Observation Code (CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1368].
e) SHALL contain zero or one if available [0..1] text [CONF:1369].
f) SHALL contain zero or one if available [0..1] effectiveTime [CONF:1370] such that it,
i) MAY be a partial date conforming to the TS data type constraints [CONF:1370.62].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
398 DSTU (Revision 2013)
g) SHALL contain zero or one if available [0..1] value [CONF:1371].
h) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:1372] such that each,
i) SHALL contain exactly one [1..1] Attachment (2.16.840.1.113883.3.1818.10.4.1)
[CONF:1372.1].
i) MAY contain zero or more [0..*] {CDAR2} author [CONF:1373] such that each,
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1373.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
399 DSTU (Revision 2013)
The following XML example outlines how to use the Outcome Observation template:
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.18"/> <!-- Outcome Observation
-->
<observation classCode="OBS" moodCode="EVN">
<id extension="123669" root="2.16.840.1.113883.3.1818.10.2.10.31"/>
<code code="OUTCOBS" displayName="Outcome Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>This 66-year-old-lady was admitted through the hospital emergency
department after having had spells of heaviness in the chest and arm tingling.
This was initially not associated with any ECG change, but with a troponin
rise of 1 increasing to 2.
During the time of the hospitalization, she was treated with nitrates, low
molecular weight heparin, Clopidogrel, and low dose beta blockade.
Despite this, she had repeated spells of chest discomfort and wound up being
placed on higher dose of beta blockade, transdermal nitrates.
She developed inferior wall asymmetric T-wave inversion and did have
transient ST segment depression with pain.
Her case was discussed with Dr. Eric Fretz, and based on this discussion we
did institute integrilin drip and Dr. Fretz made
arrangements for transfer to the Royal Jubilee Hospital CCU for expediting
angiography on the 13th of February. </text>
<effectiveTime value="20100127"/>
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20130223"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. VG Internist</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Outcome Attachment or Reference -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.1"/> <!-- Attachment -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="ATTACH" displayName="Attachment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<text>Keywords: Hospital Discharge</text>
<effectiveTime value="20130223"/>
<value xsi:type="ST">Hospital Discharge Summary</value>
<!-- Attachment Notes not included in this sample-->
<!-- Reviewed Dates not included in this sample-->
<!-- Attachment or Reference -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.9"/> <!-- Encapsulated
Data -->
<observationMedia classCode="OBS" moodCode="EVN">
<id extension="127797" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<value mediaType="application/pdf">
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
400 DSTU (Revision 2013)
<reference value="http://www.anywhere.com/folder1/20120202-Patient1-
CCD.pdf"/>
</value>
<!-- Attachment author not included in this sample -->
</observationMedia>
</entryRelationship>
</observation>
</entryRelationship>
</observation>
</entryRelationship>
Figure 117: Outcome Observation entry example
7.21 PERFORMER PARTICIPATION
[Performer: templateId 2.16.840.1.113883.3.1818.10.4.19(open)]
Table 159: Performer Participation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Medication Dispense Event N/A
Order Event
Result Component
The Performer Participation template is a generic template that is referenced by various section or entry
to enable the consistent communication a Performer participation.
The Performer Participation template supports the performer’s name and identifier as well as the
performer’s organization’s identifier and name. This template also supports an effectiveTime
element.
Table 160: Performer Participation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1252 @typeCode M:1..1
1253 templateId O:0..* II
1254 Performed Date/Time The date/time at which the performer performed the activity.
time O:0..* IVL_TS
1255 assignedEntity O:0..*
1256 Performer ID id R:0..1 II
1257 Assigned Person assignedPerson O:0..1
1258 @classCode M:1..1
1259 @determinerCode M:1..1
1260 Assigned Person's Name name R:0..1 PN
1261 Represented Organization representedOrganization O:0..1
1262 @classCode M:1..1
1263 @determinerCode M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
401 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1264 Represented Organization's Identifier id R:0..1 II
1265 Represented Organization's Name name R:0..1 ON
A Performer Participation (Performer) element:
1) SHALL contain exactly one [1..1] @typeCode="PRF" performer (CodeSystem: ParticipationType
2.16.840.1.113883.5.90) [CONF:1252].
2) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1253] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.19"
[CONF:1253.12].
3) MAY contain zero or more [0..*] {CDAR2} time [CONF:1254] such that each,
a) SHALL contain exactly one [1..1] low value to indicate the Start Date/Time and MAY contain zero
or one [0..1] high values to indicate the End Date/Time [CONF:1254.63].
b) MAY be a partial date conforming to the TS data type constraints [CONF:1254.62].
4) MAY contain zero or more [0..*] {CDAR2} assignedEntity [CONF:1255].
a) SHALL contain zero or one if available [0..1] id [CONF:1256] such that it,
i) MAY be a locally assigned identifier, if the author is a not a Provider [CONF:1256.13].
ii) SHALL be the BC Ministry of Health Practitioner ID, for which the OID root is
2.16.840.1.113883.3.40.2.11 if the identified person is a Provider; MAY be a locally
assigned identifier if and only if the identified person is not a Provider [CONF:1256.25].
iii) MAY contain a NullFlavor if the id is not known and the name is included [CONF:1256.14].
b) MAY contain zero or one [0..1] {CDAR2} assignedPerson [CONF:1257].
i) SHALL contain exactly one [1..1] @classCode="PSN" person (CodeSystem: EntityClass
2.16.840.1.113883.5.41) [CONF:1258].
ii) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance (CodeSystem:
EntityDeterminer 2.16.840.1.113883.5.30) [CONF:1259].
iii) SHALL contain zero or one if available [0..1] name [CONF:1260] such that it,
(1) SHALL, when present, conform to the Person Name (PN) pan-Canadian Data Type data
type constraint template (2.16.840.1.113883.3.3068.10.5.3) [CONF:1260.5].
c) MAY contain zero or one [0..1] {CDAR2} representedOrganization [CONF:1261].
i) SHALL contain exactly one [1..1] @classCode="ORG" organization (CodeSystem:
EntityClass 2.16.840.1.113883.5.41) [CONF:1262].
ii) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance (CodeSystem:
EntityDeterminer 2.16.840.1.113883.5.30) [CONF:1263].
iii) SHALL contain zero or one if available [0..1] id [CONF:1264].
iv) SHALL contain zero or one if available [0..1] name [CONF:1265].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
402 DSTU (Revision 2013)
The following XML example outlines how to use the Performer Participation template:
<performer typeCode="PRF">
<templateId root="2.16.840.1.113883.3.1818.10.4.19"/> <!--Performer
Participation-->
<time value="201111111111"/>
<assignedEntity>
<id extension="123" root="2.16.840.1.113883.3.40.2.11"
assigningAuthorityName="BCMOH"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>
<prefix>Mr.</prefix>
<family>Laboratory</family>
<given>Performer</given>
</name>
</assignedPerson>
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
<id extension="TBD" root="TBD"/>
<name>Performing Organization Name</name>
</representedOrganization>
</assignedEntity>
</performer>
Figure 118: Performer Participation entry example
7.22 PROVIDER PARTICIPATION
[Participant: templateId 2.16.840.1.113883.3.1818.10.4.21(open)]
Table 161: Provider Participation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Appointment Observation N/A
Encounter Event
The Provider Participation template is a generic template that is referenced by various section or entry to
enable the consistent communication of a Provider participation.
The Provider Participation template supports the provider’s name, address, telecommunications contact
information as well as an identifier. The template also supports a “Provider Description” that may be used
when a specific provider cannot be named which may be used to indicate a speciality or department.
Table 162: Provider Participation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1278 @typeCode M:1..1
1279 @contextControlCode O:1..1
1280 templateId O:0..* II
1281 participantRole O:0..*
1282 @classCode M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
403 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1283 Provider's Identifier ID and Name of provider responsible for the encounter.
id R:0..1 II
1284 Provider's Address Address for the provider.
addr R:0..1 AD
1285 Provider's Telecom Telephone, email or other telecommunications contact information for the provider.
telecom R:0..1 TEL
1286 playingEntity O:0..1
1287 @classCode M:1..1
1288 @determinerCode M:1..1
1289 Provider's Name name R:1..1 PN
1290 Provider's Description Description of the provider if no specific named provider is known. For example, the speciality or department.
desc R:1..1 ED
A Provider Participation (Participant) element:
1) SHALL contain exactly one [1..1] @typeCode, which SHALL be selected from ValueSet
ParticipationType 2.16.840.1.113883.1.11.10901 STATIC [CONF:1278].
2) MAY contain zero or one [1..1] {CDAR2} @contextControlCode="OP" overriding propagating
(CodeSystem: ContextControl 2.16.840.1.113883.5.1057) [CONF:1279].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1280] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.21"
[CONF:1280.12].
4) MAY contain zero or more [0..*] {CDAR2} participantRole [CONF:1281].
a) SHALL contain exactly one [1..1] @classCode="PROV" provider (CodeSystem: RoleClass
2.16.840.1.113883.5.110) [CONF:1282].
b) SHALL contain zero or one if available [0..1] id [CONF:1283] such that it,
i) MAY be a locally assigned identifier, if the author is a not a Provider [CONF:1283.13].
ii) SHALL be the BC Ministry of Health Practitioner ID, for which the OID root is
2.16.840.1.113883.3.40.2.11 if the identified person is a Provider; MAY be a locally
assigned identifier if and only if the identified person is not a Provider [CONF:1283.25].
iii) MAY contain a NullFlavor if the id is not known and the name is included [CONF:1283.14].
c) SHALL contain zero or one if available [0..1] addr [CONF:1284] such that it,
i) SHALL, when present, conform to the Address (AD) pan-Canadian Data Type data type
constraint template (2.16.840.1.113883.3.3068.10.5.1) [CONF:1284.5].
d) SHALL contain zero or one if available [0..1] telecom [CONF:1285] such that it,
i) SHALL, when present, conform to the Telecom (TEL) pan-Canadian Data Type data type
constraint template (2.16.840.1.113883.3.3068.10.5.2) [CONF:1285.5].
e) MAY contain zero or one [0..1] {CDAR2} playingEntity [CONF:1286].
i) SHALL contain exactly one [1..1] @classCode="PSN" person (CodeSystem: EntityClass
2.16.840.1.113883.5.41) [CONF:1287].
ii) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance (CodeSystem:
EntityDeterminer 2.16.840.1.113883.5.30) [CONF:1288].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
404 DSTU (Revision 2013)
iii) SHALL contain exactly one (or a nullFlavor value) [1..1] name [CONF:1289].
iv) SHALL contain exactly one (or a nullFlavor value) [1..1] desc [CONF:1290].
The following XML example outlines how to use the Provider Participation template:
<participant typeCode="PRF" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.21"/> <!-- Provider
Participation -->
<participantRole>
<id extension="155388" root="2.16.840.1.113883.3.1818.10.2.10.19" use="BUS"/>
<playingEntity classCode="PSN" determinerCode="INSTANCE">
<name>
<prefix>Mr.</prefix>
<given>Encounter</given>
<family>Provider</family>
</name>
<desc>On-call attending provider.</desc>
</playingEntity>
</participantRole>
</participant>
Figure 119: Provider Participation entry example
7.23 QUALIFIER OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.22(open)]
Table 163: Qualifier Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Care History Event Author Participation
The Qualifier Observation template is a generic template that is referenced by various section or entry to
enable the consistent communication of a qualifier observation. Qualifiers are free text or coded
observations that qualify another element of the patient’s record. For example, in the Problem List a
diagnosis may have Qualifier Observations attached to it that further qualify the diagnosis (e.g. laterality,
disease stage etc.).
The Qualifier Observation template supports coded or free text qualifiers, effective time, record identifiers
and an author.
Table 164: Qualifier Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1305 @typeCode M:1..1
1306 @contextConductionInd M:1..1
1307 templateId O:0..* II
1308 templateId O:0..* II
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
405 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1309 observation O:0..*
1310 @classCode M:1..1
1311 @moodCode M:1..1
1312 Record ID id R:1..1 II
1313 Qualifier Observation Code code R:1..1 CD
1314 Free Text Qualifier text R:1..1 ED
1315 Qualifier Effective Time effectiveTime R:1..1 IVL_TS
1316 Coded Qualifier value value R:1..1 CD
1317 Qualifier Author author (Author
Participation)
O:0..*
A Qualifier Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem: ActRelationshipType
2.16.840.1.113883.5.1002) [CONF:1305].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1306].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1307] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.22"
[CONF:1307.12].
4) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1308] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.22"
[CONF:1308.12].
5) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1309].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1310].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1311].
c) SHALL contain exactly one (or a nullFlavor value) [1..1] id [CONF:1312].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] code="QUALOBS" Qualifier
Observation (CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1313].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] text [CONF:1314].
f) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:1315] such
that it,
i) SHALL contain exactly one [1..1] low value to indicate the Start Date/Time and MAY contain
zero or one [0..1] high values to indicate the End Date/Time [CONF:1315.50].
g) SHALL contain exactly one (or a nullFlavor value) [1..1] value [CONF:1316].
h) MAY contain zero or more [0..*] {CDAR2} author [CONF:1317] such that each,
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1317.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
406 DSTU (Revision 2013)
The following XML example outlines how to use the Qualifier Observation template:
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.22"/> <!-- Qualifier
Observation -->
<observation classCode="OBS" moodCode="EVN">
<id extension="123669" root="2.16.840.1.113883.3.1818.10.2.10.31"/>
<code code="QUALOBS" displayName="Qualifier Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<effectiveTime value="20100127"/>
<value xsi:type="CD" code="TBD" codeSystem="TBD" codeSystemName="TBD"
displayName="Qualifier Observation code"/>
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
</observation>
</entryRelationship>
Figure 120: Qualifier Observation entry example
7.24 REACTION OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.23(open)]
Table 165: Reaction Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Allergy & Intolerance Observation Author Participation
Immunization Observation Comment Observation
Medication Event Informant Participation
Severity Observation
This template represents an undesired symptom, finding or event due to an administered or exposed
substance. A reaction can be defined with respect to its severity, and can have been treated by one or
more interventions.
Table 166: Reaction Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1338 @typeCode M:1..1
1339 @contextConductionInd M:1..1
1340 templateId O:0..* II
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
407 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1341 observation O:0..*
1342 @classCode M:1..1
1343 @moodCode M:1..1
1344 Record ID Identified link to a reaction on the reaction list.
id R:0..1 II
1345 Reaction Observation Code code R:1..1 CD
1346 Reaction Name The name or short description of the specific reaction(s) that is experienced by a patient when exposed (e.g. Hives, anaphylaxis).
text R:1..1 ED
1347 Reaction Effective Time Effective date/time of the reaction.
effectiveTime R:0..1 IVL_TS
1348 Coded Reaction value Coded identification of the specific reaction(s) that is or are experienced by a patient when exposed (e.g. hives, anaphylaxis).
value R:1..1 CD
1349 Reaction Severity Severity of the reaction observed.
entryRelationship
(Severity Observation)
R:0..1
1717 Reaction Comment Comments or Observations related to the reaction. Examples of the use of this element include: Free form text describing or supplementing the details of the patient’s reaction; Textual description of the time period of the first reaction when an exact date is not known (e.g. adolescence); or Coded Observations.
entryRelationship
(Comment Observation)
O:0..1
1350 Reaction Author The documented author of the reaction.
author (Author
Participation)
R:0..1
1351 Reaction Informant The informant of the reaction observation (e.g. patient, patient's mother, Dr. Skin).
informant (Informant
Participation)
R:0..1
A Reaction Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem: ActRelationshipType
2.16.840.1.113883.5.1002) [CONF:1338].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1339].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1340] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.23"
[CONF:1340.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1341].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1342].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1343].
c) SHALL contain zero or one if available [0..1] id [CONF:1344].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
408 DSTU (Revision 2013)
d) SHALL contain exactly one (or a nullFlavor value) [1..1] code="REACTOBS" Reaction Code
(CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1345].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] text [CONF:1346] such that it,
i) SHALL NOT contain a nullFlavor if value contains a NullFlavor [CONF:1346.48].
f) SHALL contain zero or one if available [0..1] effectiveTime [CONF:1347] such that it,
i) SHALL contain exactly one [1..1] low value to indicate the Start Date/Time and MAY contain
zero or one [0..1] high values to indicate the End Date/Time [CONF:1347.50].
g) SHALL contain exactly one (or a nullFlavor value) [1..1] value [CONF:1348] such that it,
i) SHALL NOT contain a nullFlavor if text contains a NullFlavor [CONF:1348.47].
h) SHALL contain zero or one if available [0..1] entryRelationship [CONF:1349] such that it,
i) SHALL contain exactly one [1..1] Severity Observation
(2.16.840.1.113883.3.1818.10.4.30) [CONF:1349.1].
i) MAY contain zero or one [0..1] entryRelationship [CONF:1717] such that it,
i) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:1717.1].
j) SHALL contain zero or one if available [0..1] author [CONF:1350] such that it,
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1350.1].
k) SHALL contain zero or one if available [0..1] informant [CONF:1351] such that it,
i) SHALL contain exactly one [1..1] Informant Participation
(2.16.840.1.113883.3.1818.10.4.10) [CONF:1351.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
409 DSTU (Revision 2013)
The following XML example outlines how to use the Reaction Observation template:
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.23"/> <!-- Reaction
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="REACTOBS" displayName="Reaction Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Severe reaction to peanuts</text>
<effectiveTime> <low value="20111225"/> </effectiveTime>
<value xsi:type="CD" code="417516000" displayName="Anaphylaxis due to
substance" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>
<!-- Reaction Severity -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.30"/> <!-- Severity
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="SEV" displayName="Severity"
codeSystem="2.16.840.1.113883.5.4" codeSystemName="HL7 ActCode" />
<value xsi:type="CD" code="A4" displayName="Severe"
codeSystem="2.16.840.1.113883.5.1063" codeSystemName="HL7 ObservationValue" />
</observation>
</entryRelationship>
<!-- Reaction Comment -->
... Comment Observation Template ...
<!-- Reaction Author -->
... Author Participation Template ...
<!-- Reaction Informant -->
... Informant Participation Template ...
</observation>
</entryRelationship>
Figure 121: Reaction Observation entry example
7.25 REASON OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.24(open)]
Table 167: Reason Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Appointment Observation Author Participation
Care History Event Informant Participation
Encounter Event Record ID Link
Immunization Observation
Medical Imaging Observation
Medication Event
Medication Prescription Event
Order Event
Status Changes Audit Event
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
410 DSTU (Revision 2013)
The Reason Observation template is a generic template that is referenced by various section or entry to
enable the consistent communication of a reason or indication observation is required. Reason
observations are free text or coded observations that document the rationale for an activity. The Reason
Observation template can be used with the id element to reference a problem recorded elsewhere in the
document or with a code and value to record the problem type and problem, or as a free text reason. For
example, the indication for a prescription of a painkiller might be a headache that is documented in the
Problems Section.
The Reason Observation template supports a coded or free text reasons, effective time, record identifiers
as well as an author and informant.
Encounter Reason
There is a requirement to support the encounter reason to be from the Patient or the Provider’s
perspective. It may also be coded or free text. It is important to distinguish between the sources of the
encounter reason (patient/provider) as well as to support both coded and textual views.
This is especially important because the patient’s reason, whilst important as this is their perceived
reason for the encounter; can very often be inaccurate. For example someone thinks that the chest pain
that they are having is a heart attack when it is actually acid reflux. This could “contaminate” the record
with data that is not accurately reflecting the true reason for the encounter. The patient’s reason for the
encounter might best be left in the Subjective portion of the Encounter Comment element.
Consequently, the recommendation is to allow for communicating the patient’s reason in a format that
clearly tags it as such. However, it is still possible for the provider to only include the reason in the
encounter comments if that is his/her clinical preference.
It should be noted that Emergency Room records are now required to have patient's stated "Reason"
recorded as text whilst physician preference is to have their own coding (e.g. "BP check and med
renewal" or "Follow-up after CT" ) which they may be able to see at a glance the purpose of the visit).
The sending system is responsible for ensuring that the Encounter Reason is clearly identified with the
source of the reason (patient or provider).
The Encounter Reason is designed as a related observation to the encounter. This allows the reason to
be coded or free text and includes the author or informant of the reason.
Table 168: Reason Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1291 @typeCode M:1..1
1292 @contextConductionInd M:1..1
1293 templateId O:0..* II
1294 observation O:0..*
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
411 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1295 @classCode M:1..1
1296 @moodCode M:1..1
1297 Record ID id R:1..1 II
1298 Reason Observation Code code R:1..1 CD
1299 Free Text Reason Text for the reason when the reason for the event is not coded.
text R:1..1 ED
1300 Reason Effective Time effectiveTime R:1..1 IVL_TS
1301 Coded Reason value A coded reason for the event. This code may be a clinical reason such as a diagnosis, a symptom or an indication, or it may be an administrative reason.
value R:1..1 CD
1302 Record Link Link to another record (such as a problem list record).
entryRelationship
(Record ID Link)
R:1..1
1303 Reason Author author (Author
Participation)
O:0..*
1304 Reason Informant informant (Informant
Participation)
O:0..*
A Reason Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem: ActRelationshipType
2.16.840.1.113883.5.1002) [CONF:1291].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1292].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1293] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.24"
[CONF:1293.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1294].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1295].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1296].
c) SHALL contain exactly one (or a nullFlavor value) [1..1] id [CONF:1297].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] code="REASON" Reason Code
(CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1298].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] text [CONF:1299].
f) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:1300] such
that it,
i) SHALL contain exactly one [1..1] low value to indicate the Start Date/Time and MAY contain
zero or one [0..1] high values to indicate the End Date/Time [CONF:1300.50].
g) SHALL contain exactly one (or a nullFlavor value) [1..1] value, which SHOULD be selected
from ValueSet ReasonObservationValue 2.16.840.1.113883.3.3068.10.8.22 DYNAMIC [CONF:1301].
h) SHALL contain exactly one (or a nullFlavor value) [1..1] entryRelationship [CONF:1302]
such that it,
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
412 DSTU (Revision 2013)
i) SHALL contain exactly one [1..1] Record ID Link
(2.16.840.1.113883.3.1818.10.4.38) [CONF:1302.1].
i) MAY contain zero or more [0..*] {CDAR2} author [CONF:1303] such that each,
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1303.1].
j) MAY contain zero or more [0..*] {CDAR2} informant [CONF:1304] such that each,
i) SHALL contain exactly one [1..1] Informant Participation
(2.16.840.1.113883.3.1818.10.4.10) [CONF:1304.1].
The following XML example outlines how to use the Reason Observation template:
<entryRelationship typeCode="RSON" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> <!-- Reason
Observation -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="REASON" displayName="Reason Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>confirmation recieved from Hospital</text>
<effectiveTime value="20120201"/>
<value xsi:type="CD" code="10144323" displayName="Patient findings
pneumonia" codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT"/>
<!-- Reason Author -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Reason Informant -->
<informant typeCode="INF" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.10"/> <!-- Informant
Participation -->
<assignedEntity classCode="ASSIGNED">
<id nullFlavor="NA"/>
<assignedPerson>
<name>Royal X Hospital</name>
</assignedPerson>
</assignedEntity>
</informant>
</observation>
</entryRelationship>
Figure 122: Reason Observation entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
413 DSTU (Revision 2013)
7.26 RECORD ID LINK
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.38(open)]
Table 169: Record ID Link Template Context
Directly Used by Template(s) Directly Contains Template(s)
Encounter Event N/A
Medication Prescription Event
Reason Observation
The Record ID Link template is a generic template that is referenced by various section or entry to enable
the consistent communication of a link to another record in the patient’s medical record, or within the
document is required. For example, a prescription may link to a previous prescription or a diagnosis may
link to a problem list record.
The Record ID Link template supports a single observation/value element with a Record ID including
the assigning authority of the identifier.
Table 170: Record ID Link Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1629 @typeCode M:1..1
1630 @contextConductionInd M:1..1
1631 templateId O:0..* II
1632 observation O:0..*
1633 @classCode M:1..1
1634 @moodCode M:1..1
1636 Record ID id M:1..1 II
1635 Record ID Link Observation Code code M:1..1 CD
A Record ID Link (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem: ActRelationshipType
2.16.840.1.113883.5.1002) [CONF:1629].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1630].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1631] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.38"
[CONF:1631.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1632].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1633].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1634].
c) SHALL contain exactly one [1..1] id [CONF:1636].
d) SHALL contain exactly one [1..1] code="RECLINK" Record ID Link (CodeSystem:
ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1635].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
414 DSTU (Revision 2013)
The following XML example outlines how to use the Record ID Link template:
<entryRelationship typeCode="SUBJ">
<templateId root="2.16.840.1.113883.3.1818.10.4.38"/> <!-- Record ID Link
-->
<observation classCode="OBS" moodCode="EVN">
<id extension="12779999" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<code code="RECLINK" displayName="Record Link Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
</observation>
</entryRelationship>
Figure 123: Record ID Link entry example
7.27 RESULT COMPONENT
[Component: templateId 2.16.840.1.113883.3.1818.10.4.25(open)]
Table 171: Result Component Template Context
Directly Used by Template(s) Directly Contains Template(s)
Result Organizer Attachment
Comment Observation
Performer Participation
The Result Component template represents details of a laboratory test or procedure performed on a
patient.
Specimen Collection Information
For Lab results, the effective time of the result is the physiological time of the specimen being tested. In
other words, the result is a measurement of a characteristic of a specimen at the time the specimen was
obtained/collected. Most electronic laboratory result systems will include the observation date/time (HL7
2.x OBR-7) in the result message and this information should be maintained as part of the clinically
relevant meta-data attached to the result record.
Table 172: Result Component Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1439 @typeCode M:1..1
1440 @contextConductionInd M:1..1
1441 templateId O:0..* II
1442 Result Component Observation observation R:1..1
1443 @classCode M:1..1
1444 @moodCode M:1..1
1445 Result Observation Record ID id R:1..1 II
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
415 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
Unique and persistent identifier for the Result record (i.e. Accession Number).
1446 Result Observation Code Code identifying the laboratory test or procedure being reported. This may differ from the Order Code.
code R:1..1 CD
1447 Result Name Name identifying the laboratory test or procedure being reported.
text R:0..1 ED
1448 Result Date/Time Date (and optional time) that the test result was recorded by the Laboratory system.
effectiveTime R:0..1 IVL_TS
1449 Result Status The status of the laboratory results. Active shall be sent to indicate non-Final status, while Complete is used to indicate either a Final or Corrected laboratory results.
statusCode R:1..1 CS
1450 Result Value The result value. This element may be in various complex formats or data types depending on the test or procedure being reported.
value R:0..* ANY
1451 Interpretation Code Code indicating the interpretation of the results; also known as the Abnormal flag.
interpretationCode R:0..* CE
1467 Resulting Organization The ID and Name of the performing laboratory organization.
performer (Performer
Participation)
R:0..1
1460 Specimen Collection Information entryRelationship R:1..1
1461 @typeCode M:1..1
1462 Collection Procedure procedure O:0..*
1463 @classCode M:1..1
1464 @moodCode M:1..1
1465 Specimen Collection Date Date and time of the specimen collection. This is observation date/time in HL7 v2 (OBR-7).
effectiveTime R:1..1 IVL_TS
1466 Specimen Collection Comments Any notes documented regarding the specimen collection procedure.
text R:0..* ED
1468 Result Notes Comments or notes attached to the results. This includes any interpretive comments. See Observations discussion document.
entryRelationship
(Comment Observation)
O:0..*
1469 Result Attachments Attachments pertinent to the laboratory result. Examples include an attachment containing a scanned image of the order, and attachment including a radiological image with the result.
entryRelationship
(Attachment)
O:0..*
1452 Reference Ranges The ranges within which the results are
referenceRange R:0..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
416 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
interpreted.
1453 @typeCode M:1..1
1454 Observation Range observationRange O:0..*
1455 @classCode M:1..1
1456 @moodCode M:1..1
1457 Reference Range Interpretation Type Code identifying the interpretation for a given observation range (e.g. normal, high, low, etc.).
code R:0..1 CD
1458 Reference Range Text Textual form (for display) of an observation range assumed to be applicable to the subject of this result.
text R:0..1 ED
1459 Reference Range Value Structured form (for processing) of an observation range assumed to be applicable to the subject of this result.
value R:0..1 ANY
A Result Component (Component) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1439].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1440].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1441] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.25"
[CONF:1441.12].
4) SHALL contain exactly one (or a nullFlavor value) [1..1] observation [CONF:1442].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1443].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1444].
c) SHALL contain exactly one (or a nullFlavor value) [1..1] id [CONF:1445].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} code [CONF:1446].
e) SHALL contain zero or one if available [0..1] text [CONF:1447].
f) SHALL contain zero or one if available [0..1] effectiveTime [CONF:1448].
g) SHALL contain exactly one (or a nullFlavor value) [1..1] statusCode, which SHALL be
selected from ValueSet x_ActStatusActiveComplete 2.16.840.1.113883.1.11.19890 STATIC [CONF:1449].
h) SHALL contain zero or more if available [0..*] value, which, when coded, SHOULD be selected
from ValueSet ObservationValue 2.16.840.1.113883.3.3068.10.8.21 DYNAMIC [CONF:1450].
i) SHALL contain zero or more if available [0..*] interpretationCode, which SHALL be selected
from ValueSet ObservationInterpretation 2.16.840.1.113883.2.20.3.78 STATIC [CONF:1451].
j) SHALL contain zero or one if available [0..1] performer [CONF:1467] such that it,
i) SHALL contain exactly one [1..1] Performer Participation
(2.16.840.1.113883.3.1818.10.4.19) [CONF:1467.1].
k) SHALL contain exactly one (or a nullFlavor value) [1..1] entryRelationship [CONF:1460].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
417 DSTU (Revision 2013)
i) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1461].
ii) MAY contain zero or more [0..*] {CDAR2} procedure [CONF:1462].
(1) SHALL contain exactly one [1..1] @classCode="PROC" procedure (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1463].
(2) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1464].
(3) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime
[CONF:1465].
(4) SHALL contain zero or more if available [0..*] text [CONF:1466].
l) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:1468] such that each,
i) SHALL contain exactly one [1..1] Comment Observation
(2.16.840.1.113883.3.1818.10.4.3) [CONF:1468.1].
m) MAY contain zero or more [0..*] {CDAR2} entryRelationship [CONF:1469] such that each,
i) SHALL contain exactly one [1..1] Attachment (2.16.840.1.113883.3.1818.10.4.1)
[CONF:1469.1].
n) SHALL contain zero or one if available [0..1] referenceRange [CONF:1452].
i) SHALL contain exactly one [1..1] @typeCode="REFV" reference (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1453].
ii) MAY contain zero or more [0..*] {CDAR2} observationRange [CONF:1454].
(1) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem:
ActClass 2.16.840.1.113883.5.6) [CONF:1455].
(2) SHALL contain exactly one [1..1] @moodCode="EVN.CRT" event criterion (CodeSystem:
ActMood 2.16.840.1.113883.5.1001) [CONF:1456].
(3) SHALL contain zero or one if available [0..1] code, which SHALL be selected from
ValueSet ObservationInterpretationNormality 2.16.840.1.113883.1.11.10206 STATIC [CONF:1457].
(4) SHALL contain zero or one if available [0..1] text [CONF:1458].
(5) SHALL contain zero or one if available [0..1] value [CONF:1459].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
418 DSTU (Revision 2013)
The following XML example outlines how to use the Result Component template:
<component typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.25"/> <!-- Result Component
-->
<observation classCode="OBS" moodCode="EVN">
<id extension="123669" root="2.16.840.1.113883.3.1818.10.2.10.33"/>
<code code="6690-2" displayName="Leukocytes [#/volume] in Blood by
Automated count" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
<text>White Blood Count</text>
<statusCode code="final"/>
<effectiveTime value="20100127"/>
<value xsi:type="PQ" value="6.7" unit="10+3/ul"/>
<interpretationCode code="N" displayName="Normal"
codeSystem="2.16.840.1.113883.2.20.3.78" codeSystemName="ObservationInterpretation"/>
<!--Resulting Organization -->
<performer typeCode="PRF">
<templateId root="2.16.840.1.113883.3.1818.10.4.19"/> <!--Performer
Participation-->
<time value="201111111111"/>
<assignedEntity>
<id extension="123" root="2.16.840.1.113883.3.40.2.11"
assigningAuthorityName="BCMOH"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>
<prefix>Mr.</prefix>
<family>Laboratory</family>
<given>Performer</given>
</name>
</assignedPerson>
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
<id extension="TBD" root="TBD"/>
<name>Performing Organization Name</name>
</representedOrganization>
</assignedEntity>
</performer>
<!--Specimen Collection Information -->
<entryRelationship typeCode="COMP">
<procedure classCode="PROC" moodCode="EVN">
<!-- specimen collection comments -->
<text>No problem with specimen collection</text>
<!-- specimen collection date -->
<effectiveTime value="20100126100311"/>
</procedure>
</entryRelationship>
<!-- Result Notes -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> <!-- Comment
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="COMMENT" displayName="Comment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="ST">Result Note comment inserted heret</value>
</observation>
</entryRelationship>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
419 DSTU (Revision 2013)
<!-- Result Attachment or Reference -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.1"/> <!-- Attachment -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="ATTACH" displayName="Attachment Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>Keywords: Abnormal Laboratory Result Chicken-Pox Confirmed</text>
<effectiveTime value="20120202"/>
<value xsi:type="ST">Chicken Pox Alert</value>
<!-- Attachment Notes not included in this sample-->
<!-- Reviewed Dates not included in this sample-->
<!-- Attachment or Reference -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.9"/> <!-- Encapsulated
Data -->
<observationMedia classCode="OBS" moodCode="EVN">
<id extension="127797" root="2.16.840.1.113883.3.1818.10.2.10.16"/>
<value mediaType="application/pdf">
<reference value="http://www.anywhere.com/folder1/20120202-Patient1-
claim1.pdf"/>
</value>
<!-- Attachment author not included in this sample -->
</observationMedia>
</entryRelationship>
</observation>
</entryRelationship>
<referenceRange typeCode="REFV">
<observationRange classCode="OBS" moodCode="EVN.CRT">
<code code="N" displayName="Normal"
codeSystem="2.16.840.1.113883.1.11.10206"
codeSystemName="ObservationInterpretationNormality"/>
<text>Normal Reference range is between 5 and 10</text>
<value xsi:type="IVL_REAL">
<low value="4.3"/>
<high value="10.8"/>
</value>
</observationRange>
<observationRange classCode="OBS" moodCode="EVN.CRT">
<code code="H" displayName="High"
codeSystem="2.16.840.1.113883.1.11.10206"
codeSystemName="ObservationInterpretationNormality"/>
<text>High Reference range is between 5 and 10</text>
<value xsi:type="IVL_REAL">
<low value="10.81"/>
<high value="15.4"/>
</value>
</observationRange>
<observationRange classCode="OBS" moodCode="EVN.CRT">
<code code="HH" displayName="Very High"
codeSystem="2.16.840.1.113883.1.11.10206"
codeSystemName="ObservationInterpretationNormality"/>
<text>Very High Reference range is between 5 and 10</text>
<value xsi:type="IVL_REAL">
<low value="15.41"/>
</value>
</observationRange>
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
420 DSTU (Revision 2013)
</referenceRange>
</observation>
</component>
Figure 124: Result Component entry example
7.28 RESULT ORGANIZER
[Organizer: templateId 2.16.840.1.113883.3.1818.10.4.26(open)]
Table 173: Result Organizer Template Context
Directly Used by Template(s) Directly Contains Template(s)
Laboratory Observation Result Component
Order Event
The Result Organizer template identifies set of result observations. It defines the format for information
applicable to all of the contained result observations. Result type codes categorize a result into one of
several commonly accepted values (e.g., “Hematology”, “Chemistry”, “Nuclear Medicine”). These values
are often implicit in the Organizer/code (e.g., an Organizer/code of “complete blood count” implies
a ResultTypeCode of “Hematology”). This template requires Organizer/code to include a
ResultTypeCode either directly or as a translation of a code from some other code system.
An appropriate nullFlavor can be used when a single result observation is contained in the organizer,
and organizer/code or organizer/id is unknown.
Table 174: Result Organizer Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1428 @typeCode M:1..1
1429 @contextConductionInd M:1..1
1430 templateId O:0..* II
1431 organizer R:1..1
1432 @classCode M:1..1
1433 @moodCode M:1..1
1434 templateId M:1..1 II
1435 Result Organizer Record ID Unique and persistent identifier for the battery or cluster.
id R:0..1 II
1436 Result Organizer Code Code identifying the battery or cluster being reported.
code R:1..1 CD
1437 Result Organizer Status The status of the battery or cluster. Active shall be sent to indicate non-Final status, while Complete is used to indicate either a Final or Corrected battery of cluster.
statusCode R:1..1 CS
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
421 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1438 Result Observation component (Result
Component)
R:1..*
A Result Organizer (Organizer) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1428].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1429].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1430] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.26"
[CONF:1430.12].
4) SHALL contain exactly one (or a nullFlavor value) [1..1] organizer [CONF:1431].
a) SHALL contain exactly one [1..1] @classCode [CONF:1432] such that it,
i) SHALL contain either "CLUSTER" or "BATTERY" [CONF:1432.144].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1433].
c) SHALL contain exactly one [1..1] templateId [CONF:1434] such that it,
i) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.26"
[CONF:1434.12].
d) SHALL contain zero or one if available [0..1] id [CONF:1435].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] code [CONF:1436].
f) SHALL contain exactly one (or a nullFlavor value) [1..1] statusCode, which SHALL be
selected from ValueSet x_ActStatusActiveComplete 2.16.840.1.113883.1.11.19890 STATIC [CONF:1437].
g) SHALL contain one or more (or a nullFlavor value) [1..*] component [CONF:1438] such that
each,
i) SHALL contain exactly one [1..1] Result Component
(2.16.840.1.113883.3.1818.10.4.25) [CONF:1438.1].
The following XML example outlines how to use the Result Organizer template:
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.26"/> <!-- Result Organizer --
>
<organizer classCode="BATTERY" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.35"/>
<code code="57782-5" displayName="CBC w ordered manual differential"
codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>
<statusCode code="final"/>
<component typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.25"/> <!-- Result Component
-->
...
</component>
</organizer>
</entryRelationship>
Figure 125: Result Organizer entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
422 DSTU (Revision 2013)
7.29 SECONDARY CODE (DRUG)
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.27(open)]
Table 175: Secondary Code (Drug) Template Context
Directly Used by Template(s) Directly Contains Template(s)
Immunization Observation N/A
The Secondary Code (Drug) template is a generic template that is referenced by various section or entry
to enable the consistent communication of a secondary code is required for a drug. Whilst the
specification has identified the DIN as the primary coding system to be used when identifying drugs, it
recognizes that there are several other available coding systems that may be used to identify a drug that
may be more clinically appropriate. Consequently the specification supports additional identifiers to be
attached to the record using the alternate coding systems.
Refer to the discussion pertaining to the Medication Event template for a more detailed discussion of
Drug coding options.
Table 176: Secondary Code (Drug) Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1412 @typeCode M:1..1
1413 @contextConductionInd M:1..1
1414 templateId O:0..* II
1415 observation O:0..*
1416 @classCode M:1..1
1417 @moodCode M:1..1
1418 Secondary Drug Observation Code code M:1..1 CD
1419 Drug Code value Code from the recognized Drug coding system.
value M:1..1 CD
A Secondary Code (Drug) (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1412].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1413].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1414] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.27"
[CONF:1414.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1415].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1416].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1417].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
423 DSTU (Revision 2013)
c) SHALL contain exactly one [1..1] code="SECDRUGCODE" Secondary Drug (CodeSystem:
ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1418].
d) SHALL contain exactly one [1..1] value, which SHALL be selected from ValueSet ClinicalDrug
2.16.840.1.113883.2.20.3.29 DYNAMIC [CONF:1419].
The following XML example outlines how to use the Secondary Code (Drug) template:
<!-- Alternate Product Coding -->
<entryRelationship typeCode="COMP">
<observation classCode="OBS" moodCode="EVN">
<templateId root="2.16.840.1.113883.3.1818.10.4.27"/> <!-- Secondary Code
Drug -->
<code code="SECDRUGCODE" displayName="Secondary Drug Code"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="CD" code="61153008" displayName="Measles + Mumps + Rubella
vaccine " codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT" />
</observation>
</entryRelationship>
Figure 126: Secondary Code (Drug) entry example
7.30 SECONDARY CODE (ICD-9)
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.28(open)]
Table 177: Secondary Code (ICD-9) Template Context
Directly Used by Template(s) Directly Contains Template(s)
Family History Observation N/A
Problem List Observation
The Secondary Code (ICD-9) template is a generic template that is referenced by various section or entry
to enable the consistent communication of an ICD-9 code. Whilst the specification has identified
SNOMED as the primary coding system for diagnosis, it recognizes that the ICD-9 code system may also
be used may be more clinically appropriate. Consequently the specification supports sending the ICD-9
code as an additional identifier to be attached to the record as required.
Refer to the discussion pertaining to the Medication Event template for a more detailed discussion of
Drug coding options.
Table 178: Secondary Code (ICD-9) Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1404 @typeCode M:1..1
1405 @contextConductionInd M:1..1
1406 templateId O:0..* II
1407 observation O:0..*
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
424 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1408 @classCode M:1..1
1409 @moodCode M:1..1
1410 ICD-9 Observation Code code M:1..1 CD
1411 ICD-9 Code value Code from the ICD-9 Coding system.
value M:1..1 CD
A Secondary Code (ICD-9) (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1404].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1405].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1406] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.28"
[CONF:1406.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1407].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1408].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1409].
c) SHALL contain exactly one [1..1] code="ICD9CODE" Billing Code Observation (e.g. ICD9)
(CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1410].
d) SHALL contain exactly one [1..1] value, which SHALL be selected from ValueSet
DiagnosisICD9CM 2.16.840.1.113883.1.11.15931 STATIC [CONF:1411].
The following XML example outlines how to use the Secondary Code (ICD-9) template:
<!-- Diagnosis Billing Code -->
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.28"/> <!-- Secondary Code
(ICD9) -->
<observation classCode="OBS" moodCode="EVN">
<code code="BILLINGCODE" displayName="Billing Code"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="CD" code="tbd" displayName="tbd"
codeSystem="2.16.840.1.113883.6.42" codeSystemName="ICD9"/>
</observation>
</entryRelationship>
Figure 127: Secondary Code (ICD-9) entry example
7.31 SECONDARY CODE (UNBOUND)
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.29(open)]
Table 179: Secondary Code (Unbound) Template Context
Directly Used by Template(s) Directly Contains Template(s)
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
425 DSTU (Revision 2013)
Directly Used by Template(s) Directly Contains Template(s)
Care History Event N/A
The Secondary Code (Unbound) template is a generic template that is referenced by various section or
entry to enable the consistent communication of a secondary code is required. The specification
recognizes that there are many coding options for procedures depending on the scope of practice and
jurisdictional requirements of the practitioners. Consequently, it is recommended that if the source
system has more than one code for a procedure from alternate coding systems it should include all
available codes in the expectation that the receiving system will recognize and support one of the code
systems. The specification supports attaching a secondary code to a procedure record for this purpose.
Refer to Section TBD for a more detailed discussion of secondary coding options.
Table 180: Secondary Code (Unbound) Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1420 @typeCode M:1..1
1421 @contextConductionInd M:1..1
1422 templateId O:0..* II
1423 observation O:0..*
1424 @classCode M:1..1
1425 @moodCode M:1..1
1426 Secondary Unbounded Observation Code code M:1..1 CD
1427 Secondary Code Value Code from Secondary Coding system.
value M:1..1 CD
A Secondary Code (Unbound) (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:
ActRelationshipType 2.16.840.1.113883.5.1002) [CONF:1420].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1421].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1422] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.29"
[CONF:1422.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1423].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1424].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1425].
c) SHALL contain exactly one [1..1] code="SECCODE" Secondary Code Unbound (CodeSystem:
ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1426].
d) SHALL contain exactly one [1..1] value [CONF:1427].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
426 DSTU (Revision 2013)
The following XML example outlines how to use the Secondary Code (Unbound) template:
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.29"/> <!-- Secondary Code
Unbound -->
<observation classCode="OBS" moodCode="EVN">
<code code="SECCODE" displayName="Secondary Code"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="CD" code="BIN" codeSystem="2.16.840.1.113883.6.42"
codeSystemName="ICD9" displayName="Bacterial Infection"/>
</observation>
</entryRelationship>
Figure 128: Secondary Code (Unbound) entry example
7.32 SEVERITY OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.30(closed)]
Table 181: Severity Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Allergy & Intolerance Observation N/A
Reaction Observation
The Severity Observation template is a generic template that is referenced by various section or entry to
enable the consistent communication of a severity observation is required. Severity represents the
gravity of the problem, such as allergy or reaction, in terms of its actual or potential impact on the patient.
The Severity Observation can be associated with an Allergy Observation, Reaction Observation or both.
When the Severity Observation is associated directly with an Allergy it characterizes the Allergy. When
the Severity Observation is associated with a Reaction Observation it characterizes a Reaction. A person
may manifest many symptoms in a reaction to a single substance, and each reaction to the substance
can be represented. However, each reaction observation can have only one severity observation
associated with it. For example, someone may have a rash reaction observation as well as an itching
reaction observation, but each can have only one level of severity.
The Severity Observation template supports coded or free text severities.
Table 182: Severity Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1352 @typeCode M:1..1
1353 @contextConductionInd M:1..1
1354 templateId O:0..* II
1355 observation O:0..*
1356 @classCode M:1..1
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
427 DSTU (Revision 2013)
CONF Business Name & Description Element Name E&C Element Data Type
1357 @moodCode M:1..1
1358 Severity Observation Code code R:1..1 CD
1359 Free Text Severity text R:0..1 ED
1360 Coded Severity value value R:0..1 CD
A Severity Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem: ActRelationshipType
2.16.840.1.113883.5.1002) [CONF:1352].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1353].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1354] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.30"
[CONF:1354.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1355].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1356].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1357].
c) SHALL contain exactly one (or a nullFlavor value) [1..1] code="SEV" severity (CodeSystem:
ActCode 2.16.840.1.113883.5.4) [CONF:1358].
d) SHALL contain zero or one if available [0..1] text [CONF:1359].
e) SHALL contain zero or one if available [0..1] value, which SHALL be selected from ValueSet
AllergyTestValue 2.16.840.1.113883.1.11.19696 STATIC [CONF:1360].
The following XML example outlines how to use the Severity Observation template:
<entryRelationship typeCode="COMP" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.30"/> <!-- Severity
Observation -->
<observation classCode="OBS" moodCode="EVN">
<code code="SEV" displayName="Severity" codeSystem="2.16.840.1.113883.5.4"
codeSystemName="HL7 ActCode" />
<value xsi:type="CD" code="A4" displayName="Severe"
codeSystem="2.16.840.1.113883.5.1063" codeSystemName="HL7 ObservationValue" />
</observation>
</entryRelationship>
Figure 129: Severity Observation entry example
7.33 STATUS CHANGES AUDIT EVENT
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.31(open)]
Table 183: Status Changes Audit Event Template Context
Directly Used by Template(s) Directly Contains Template(s)
Allergy & Intolerance Observation Author Participation
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
428 DSTU (Revision 2013)
Directly Used by Template(s) Directly Contains Template(s)
Reason Observation
The Status Change Audit template is a generic template that is referenced by various section or entry to
enable the consistent communication of status change audit information pertaining to a specific record.
This template enables the communication of a change is status of a record based on the audit record
captured in the source system. The information communicated in this entry is normally captured as an
audit trail in the source system and it is unlikely that a receiving system would want to include it as an
audit trail as it would mix with the receiving systems own audit trail. Consequently the ability of the
receiving system to capture this information must be considered when establishing the structure for
communicating it.
Table 184: Status Changes Audit Event Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1391 @typeCode M:1..1
1392 @contextConductionInd M:1..1
1393 @inversionInd O:0..1
1394 templateId O:0..* II
1395 observation O:0..*
1396 @classCode M:1..1
1397 @moodCode M:1..1
1398 Audit Record ID The audit record ID that may be used to track and locate the audit record being reported.
id R:1..1 II
1399 Status Change Audit Code The code indicating the type of status change made.
code R:1..1 CD
1400 Free Text Status Change comment Free text comment regarding the status change. This element may be used to include any additional relevant information regarding the status change.
text R:1..1 ED
1401 Status Change Effective Time The effective date/time of the observation. This indicates the time the Status was changed.
effectiveTime R:1..1 IVL_TS
1402 Reason This field is used to indicate the reason associated with the status change and any other descriptive text associated with the status change.
entryRelationship
(Reason Observation)
R:1..1
1403 Status Change Author Indicates the person who made the status change including their represented organization if known and relevant. Identifies a person by name, by identifier or both. If the author is unknown or unavailable this element MAY contain a NullFlavor.
author (Author
Participation)
O:0..*
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
429 DSTU (Revision 2013)
A Status Changes Audit Event (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem: ActRelationshipType
2.16.840.1.113883.5.1002) [CONF:1391].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1392].
3) MAY contain zero or one [0..1] {CDAR2} @inversionInd="true" [CONF:1393].
4) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1394] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.31"
[CONF:1394.12].
5) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1395].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1396].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1397].
c) SHALL contain exactly one (or a nullFlavor value) [1..1] id [CONF:1398].
d) SHALL contain exactly one (or a nullFlavor value) [1..1] code="STSAUDITOBS" Status Audit
Observation (CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1399].
e) SHALL contain exactly one (or a nullFlavor value) [1..1] text [CONF:1400].
f) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:1401].
g) SHALL contain exactly one (or a nullFlavor value) [1..1] entryRelationship [CONF:1402]
such that it,
i) SHALL contain exactly one [1..1] Reason Observation
(2.16.840.1.113883.3.1818.10.4.24) [CONF:1402.1].
h) MAY contain zero or more [0..*] {CDAR2} author [CONF:1403] such that each,
i) SHALL contain exactly one [1..1] Author Participation
(2.16.840.1.113883.3.1818.10.4.2) [CONF:1403.1].
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
430 DSTU (Revision 2013)
The following XML example outlines how to use the Status Changes Audit Event template:
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.31"/> <!--Status Change
Audit Event -->
<observation classCode="OBS" moodCode="EVN">
<id extension="123" root="2.16.840.1.113883.3.1818.10.2.10.1"/>
<code code="STSAUDITOBS" displayName="Status Audit Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending" />
<text>Allergy report recived from Emergency department confirming
allergy</text>
<effectiveTime value="201101221054"/>
<!-- Status change Author -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809" root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Status Change Reason -->
<entryRelationship typeCode="RSON" contextConductionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> <!-- Reason
Observation -->
<observation classCode="OBS" moodCode="EVN">
<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.15"/>
<code code="REASON" displayName="Reason Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<text>confirmation recieved from Hospital</text>
<effectiveTime value="20120201"/>
<value xsi:type="CD" code="10144323" displayName="Patient findings
pneumonia" codeSystem="2.16.840.1.113883.3.1818.10.2.8.3" codeSystemName="SNOMED-CT"/>
<!-- Status Change reason Author -->
<author typeCode="AUT" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> <!-- Author
Participation -->
<time value="20030529"/>
<assignedAuthor classCode="ASSIGNED">
<id use="BUS" extension="38809"
root="2.16.840.1.113883.3.163.5.0.10.2"/>
<assignedPerson classCode="PSN" determinerCode="INSTANCE">
<name>Dr. W. Pewarchuck</name>
</assignedPerson>
</assignedAuthor>
</author>
<!-- Status Change Reason Informant -->
<informant typeCode="INF" contextControlCode="OP">
<templateId root="2.16.840.1.113883.3.1818.10.4.10"/> <!-- Informant
Participation -->
<assignedEntity classCode="ASSIGNED">
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
431 DSTU (Revision 2013)
<id nullFlavor="NA"/>
<assignedPerson>
<name>Royal X Hospital</name>
</assignedPerson>
</assignedEntity>
</informant>
</observation>
</entryRelationship>
</observation>
</entryRelationship>
Figure 130: Status Changes Audit Event entry example
7.34 UNBOUND OBSERVATION
[Observation: templateId 2.16.840.1.113883.3.1818.10.4.32(open)]
Table 185: Unbound Observation Template Context
Directly Used by Template(s) Directly Contains Template(s)
Medication Event N/A
Problem List Observation
The Unbound Observation template is a generic comment template that is referenced by various section
or entry to enable the consistent communication of an observation that is not bound to any specific coding
system.
The Unbound Observation template supports a code from any identified coding system to identify the type
of observation. The observation value may be coded or free text comment.
Table 186: Unbound Observation Constraints Overview
CONF Business Name & Description Element Name E&C Element Data Type
1374 @typeCode M:1..1
1375 @contextConductionInd M:1..1
1376 templateId O:0..* II
1377 observation O:0..*
1378 @classCode M:1..1
1379 @moodCode M:1..1
1380 Unbounded Observation Code code R:1..1 CD
1381 Free Text Observation text O:0..1 ED
1382 Coded or Structured Observation The value of the unbounded observation when it is structured data (e.g. code (CD), quanity (PQ), identifier (II), or date/time (TS), etc.)
value O:0..* ANY
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
432 DSTU (Revision 2013)
An Unbound Observation (Observation) element:
1) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem: ActRelationshipType
2.16.840.1.113883.5.1002) [CONF:1374].
2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1375].
3) MAY contain zero or more [0..*] {CDAR2} templateId [CONF:1376] such that each,
a) SHALL contain exactly one [1..1] @root="2.16.840.1.113883.3.1818.10.4.32"
[CONF:1376.12].
4) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1377].
a) SHALL contain exactly one [1..1] @classCode="OBS" observation (CodeSystem: ActClass
2.16.840.1.113883.5.6) [CONF:1378].
b) SHALL contain exactly one [1..1] @moodCode="EVN" event (CodeSystem: ActMood
2.16.840.1.113883.5.1001) [CONF:1379].
c) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} code="UNBOUND" Unbound
Observation Code (CodeSystem: ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3) [CONF:1380].
d) MAY contain zero or one [0..1] {CDAR2} text [CONF:1381].
e) MAY contain zero or more [0..*] {CDAR2} value [CONF:1382].
The following XML example outlines how to use the Unbound Observation template:
<!-- Diagnosis Modifier -->
<entryRelationship typeCode="SUBJ" contextConductionInd="true"
inversionInd="true">
<templateId root="2.16.840.1.113883.3.1818.10.4.32"/> <!-- Unbound Observation
-->
<observation classCode="OBS" moodCode="EVN">
<code code="UNBOUND" displayName="Unbound Observation"
codeSystem="2.16.840.1.113883.3.3068.10.6.3" codeSystemName="ObservationType-CA-
Pending"/>
<value xsi:type="ST">Moderate severity</value>
</observation>
</entryRelationship>
Figure 131: Unbound Observation entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
433 DSTU (Revision 2013)
8.0 DATA TYPES
8.1 OVERVIEW
Data Type Assignment
Each data element in this specification has a data type associate with it. That data type is either the
default data type established by the CDA R2 standard or a data type assigned to the element through this
specification.
Consider, for example, the value attribute in CDA R2 which has been defined using the ANY data type
both by CDA as well as within the HL7 Reference Information Model (RIM) on which CDA is broadly
based. This data type allows any type of value to be communicated so that, for example, the response to
an observation type question can be a date, a scale value, a code, etc. In the context of this specification
there are instances where the value attribute is always intended to communicate a particular type of
information. In those cases, wherever feasible, a more specific data type has been designated(See 8.2.1
for further details).
Precedence
Data types in this specification SHALL be interpreted in accordance with the following precedence:
These specifications, particularly any data type templates established and referenced;
pan-Canadian Data Type standards.
In Scope Data Types
The following table provides a description of the HL7 data types used in this specification:
Table 187: Data Types
Data Type Name Description
AD Postal Address Mailing and home or office addresses. A sequence of address parts, such as street or post office Box, city, postal code, country. This datatype is of mixed content.
ANY Any Defines the basic properties of every data value. This is an abstract type, meaning that no value can be just a data value without belonging to any concrete type. Every concrete type is a specialization of this general abstract DataValue type.
bl Boolean The Boolean type stands for the values of two-valued logic. A Boolean value can be either true or false.
CD Concept Descriptor A concept descriptor represents any kind of concept usually by giving a code defined in a code system. A concept descriptor can contain the original text or phrase that served as the basis of the coding and one or more translations into different coding systems. A concept descriptor can also contain qualifiers to describe, e.g., the concept of a "left foot" as a postcoordinated term built from the primary code "FOOT" and the qualifier "LEFT". In exceptional cases, the concept descriptor need not contain a
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
434 DSTU (Revision 2013)
Data Type Name Description
code but only the original text describing that concept.
CE Coded with Equivalents
Coded data that consists of a coded value (CV) and, optionally, coded value(s) from other coding systems that identify the same concept. Used when alternative codes may exist.
CS Coded Simple Value Coded data in its simplest form, where only the code is not predetermined. The code system and code system version is fixed by the context in which the CS value occurs. CS is used for coded attributes that have a single HL7-defined value-set.
ED Encapsulated Date Data that is primarily intended for human interpretation or for further machine processing outside the scope of HL7. This includes unformatted or formatted written language, multimedia data, or structured information in as defined by a different standard.
EN Entity Name A name for a person, organization, place or thing. A sequence of name parts, such as first name or family name, prefix, suffix, etc.
II Instance Identifier An identifier that uniquely identifies a thing or object. Examples are object identifier for HL7 RIM objects, medical record number, order id, service catalog item id, Vehicle Identification Number (VIN), etc. Instance identifiers are defined based on ISO object identifiers. A globally unique identifier (GUID) will be used as the root for instance identifiers in this application.
IVL Interval A set of consecutive values of an ordered base data type. Any ordered type can be the basis of an interval; it does not matter whether the base type is discrete or continuous. If the base data type is only partially ordered, all elements of the interval must be elements of a totally ordered subset of the partially ordered data type.
ON Organization Name A name for an organization. A sequence of name parts.
PN Person Name A name for a person. A sequence of name parts, such as first name or family name, prefix, suffix, etc. A name part is a restriction of entity name part that only allows those entity name parts qualifiers applicable to person names. Since the structure of entity name is mostly determined by the requirements of person name, the restriction is very minor. This data type is of mixed content.
PQ Physical Quantity A dimensioned quantity expressing the result of measuring.
RTO Ratio A quantity constructed as the quotient of a numerator quantity divided by a denominator quantity. Common factors in the numerator and denominator are not automatically cancelled out. The data type supports titers (e.g., "1:128") and other quantities produced by laboratories that truly represent ratios.
SC Character String with Code
A character string that optionally may have a code attached. The text must always be present if a code is present. The code is often a local code.
ST Character String The character string data type stands for text data, primarily intended for machine processing (e.g., sorting, querying, indexing, etc.) Used for names, symbols, and formal expressions.
TEL Telecommunication Address
A telephone number (voice or fax), e-mail address, or other locator for a resource mediated by telecommunication equipment. The address is specified as a Universal Resource Locator (URL) qualified by time specification and use codes that help in deciding which address to use for a given time and purpose.
TS Timestamp A quantity specifying a point on the axis of natural time. A point in time is most often represented as a calendar expression. Note: An IVL TS (Interval Timestamp) has to be fully formed, whereas a regular TS can be
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
435 DSTU (Revision 2013)
Data Type Name Description
truncated.
Communication of Coded Data
Coded data is communicated using one of the code-style data types. These data types have been
designed to provide for the reliable exchange of coded data by ensuing that not only the code is
communicated but other critical data such as the assigning authority, the display text as well as, where
applicable, the text that was originally seen by the user.
Original Text and Display Name Components
Within the Code element there is a component <originalText> and <displayName>. The following
provides an explanation of the reason for, and use of, these components.
When using a controlled medical vocabulary there is often the situation where there is a code and a
description but within an EMR application it is possible to have a name or synonym displayed that is
different than the official description name from the coding system. For example, in ICD-9 there is
Osteoarthrosis and allied disorders of the lower leg which is more commonly called osteoarthritis of the
knee. Many EMRs have altered the displayed name and descriptions to more closely align with common
medical practice and terms. Another reason for altered descriptions is that some are very long like
“Osteoarthrosis involving, or with mention of more than one site, but not specified as generalized”.
The <originalText> component is used to communicate the EMR assigned name/title/description that
is displayed to the EMR user at the time of data capture.
The <displayName> component is used to communicate the Code System assigned display name for
the code selected.
Code System Information
Please see the applicable data type template(s).
8.2 IMPLEMENTATION CONSIDERATIONS
8.2.1 Use of the ANY Data Type in Question / Response Structures
The ANY data type is used explicitly in a variety of situations including for certain
<Observation/value> elements that are part of a Question / Response structure where
<Observation/code> is intended to convey a code for a piece of information, notionally the “question”,
and the <value> element is intended to convey the applicable, associated “response”. In this structure
the use of the ANY data type in the specification is actually intended to indicate that implementers should
apply the applicable data type in an actual message or document instance.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
436 DSTU (Revision 2013)
For example, the <code> could convey the concept of body weight, in which case the <value> element
would contain the actual weight, which would normally be conveyed through use of the PQ data type.
The following table outlines typical actual data type mappings:
Table 188: Example Data Types in Question / Response Structures
Question Type
Data Type
Example
Question (<code>) Response (<value>)
Coded CD or CE
SNOMET CT 386557006 Glasgow coma score finding
SNOMED CT 61102007 Glasgow coma scale, 11 (finding)
8
N.B. In situations where the specification does NOT establish a Code System or Value-Set it is particularly critical that a coded data type be used to include not only the code system but also a display name for use by the receiving system.
Date TS LOINC 57063-0 Delivery date
January 15, 1998
Object ED LOINC 53245-7 Driver license image attachment
An encoded attachment
Quantitative Value
PQ LOINC 3138-5 Body Height
172 cm
String ST LOINC 10221-0 Surgical operation note specimens taken
Gallbladder sent for routine pathology
Yes / No BL
LOINC 63584-7 Has there ever been a period in your life when you smoked cigarettes every day for at least 6Mo
True
8.3 DATA TYPE CONSTRAINT TEMPLATES
8.3.1 Address (AD) pan-Canadian Data Type
[AD: templateId 2.16.840.1.113883.3.3068.10.5.1(closed)]
This template establishes specific constraints for the AD data type as follows:
Table 189: Address (AD) pan-Canadian Data Type Constraints Overview
CONF Business Name & Description
Component Element
E&C Max Len.
ValueSet
DT-51 Address Type @use M:1..1 N/A x_BasicPostalAddressUse
DT-52 Address Street Lines String of text containing non-coded address information including the street address lines
delimiter R:1..4 80
DT-53 City or Township city R:0..1 80
DT-54 Province or State Province or State if free text
state R:0..1 80
8 Note that in this example, the question is also implied by the answer through the SNOMED CT relationships.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
437 DSTU (Revision 2013)
CONF Business Name & Description
Component Element
E&C Max Len.
ValueSet
DT-55 Province or State (Coded) Province or State if coded
coded province/state O:0..1 N/A ISO3166-1–CountryCodes
DT-56 Postal Code postal code R:0..1 80
DT-57 Country Country if free text
country R:0..1 80
DT-58 Country (Coded) Country if coded
coded country O:0..1 N/A ISO3166-2–State/Province
DT-59 Address Part The elements above, except for use, are indicate by using coded address parts
parts M:1..8 N/A x_BasicAddressPartType
The following XML example outlines how to use the Address (AD) pan-Canadian Data Type template:
<addr use="H">
<delimiter>2222 Home Street</delimiter>
<city>Opaskwayak</city>
<state>MB</state>
<postalCode>R0B2J0</postalCode>
<country>CA</country>
</addr>
Figure 132: Address (AD) pan-Canadian Data Type entry example
8.3.2 Coded With Equivalents (CE) pan-Canadian Data Type
[CE: templateId 2.16.840.1.113883.3.3068.10.5.5(closed)]
This template establishes specific constraints for the CE data type as follows:
Table 190: Coded With Equivalents (CE) pan-Canadian Data Type Constraints Overview
CONF Business Name & Description
Component Element
E&C Max Len.
ValueSet
DT-76 Code @code R:1..1 200
DT-77 Display Name Display name associated with value by the code system.
@displayName R:0..1 150
DT-78 Code System @codeSystem M:1..1 100
DT-79 Code System Name @codeSystemName O:0..1 20
DT-80 Code System Version @codeSystemNameVersion
O:0..1 20
DT-81 Original Text Text displayed to user at time of data entry.
@originalText O:0..1 150
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
438 DSTU (Revision 2013)
The following XML example outlines how to use the Coded With Equivalents (CE) pan-Canadian Data
Type template:
<code code="195967001" codeSystem="2.16.840.1.113883.19.6.96"
codeSystemName="SNOMED CT" displayName="Asthma">
<translation code="49390" codeSystem="2.16.840.1.113883.19.6.2"
codeSystemName="ICD9CM" displayName="ASTHMA W/O STATUS ASTHMATICUS"/>
</code>
Figure 133: Coded With Equivalents (CE) pan-Canadian Data Type entry example
8.3.3 Concept Descriptor (CD) pan-Canadian Data Type
[CD: templateId 2.16.840.1.113883.3.3068.10.5.6(closed)]
This template establishes specific constraints for the CD data type as follows:
Table 191: Concept Descriptor (CD) pan-Canadian Data Type Constraints Overview
CONF Business Name & Description
Component Element
E&C Max Len.
ValueSet
DT-82 Code @code R:1..1 200
DT-83 Display Name @displayName R:0..1 150
DT-84 Code System @codeSystem M:1..1 100
DT-85 Code System Name @codeSystemName O:0..1 20
DT-86 Code System Version @codeSystemNameVersion
O:0..1 20
DT-87 Original Text Text displayed to user at time of data entry.
@originalText O:0..1 150
DT-88 Qualifier Additional codes that increase the specificity of the the primary code.
@qualifier R:0..1 N/A
DT-89 Translation Set of other concept descriptors that translate this concept descriptor into other code systems.
@translation R:0..1 N/A
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
439 DSTU (Revision 2013)
The following XML example outlines how to use the Concept Descriptor (CD) pan-Canadian Data Type
template:
<code code="396275006" codeSystem="2.16.840.1.113883.19.6.96"
codeSystemName="SNOMED CT" displayName="Osteoarthritis">
<originalText>osteoarthritis of the right knee</originalText>
<translation code="12345" codeSystem="2.16.840.1.113883.19.6.2"
codeSystemName="ICD9CM" displayName="Osteoarthritis right knee"/>
<qualifier>
<name code="363698007" codeSystem="2.16.840.1.113883.19.6.96"
codeSystemName="SNOMED CT" displayName="finding site"/>
<value code="6757004" codeSystem="2.16.840.1.113883.19.6.96"
codeSystemName="SNOMED CT" displayName="right knee"/>
</qualifier>
</code>
Figure 134: Concept Descriptor (CD) pan-Canadian Data Type entry example
8.3.4 Encapsulated Data (ED) pan-Canadian Data Type
[ED: templateId 2.16.840.1.113883.3.3068.10.5.7(closed)]
This template establishes specific constraints for the ED data type as follows:
Table 192: Encapsulated Data (ED) pan-Canadian Data Type Constraints Overview
CONF Business Name & Description
Component Element
E&C Max Len.
ValueSet
DT-90 Media Type Encoding of the encapsulated data and the method to interpret or render the data.
@mediaType M:1..1 N/A MediaType
DT-91 Language For character based information the language property specifies the human language of the text.
@language R:1..1 N/A HumanLanguage
DT-92 Compression Indicates whether the raw byte data is compressed, and what compression algorithm was used.
@compression R:1..1 20
DT-93 Integrity Check Short binary value representing a cryptographically strong checksum that is calculated over the binary data.
@integrityCheck O:0..1 20
DT-94 Reference Telecommunication address (TEL), such as a URL for HTTP or FTP, which will resolve to precisely the same binary data that could as well have been provided as inline data.
@reference R:1..1 N/A x_PhoneOrEmailURLScheme
DT-95 Thumbnail Abbreviated rendition of the full data. A thumbnail requires significantly fewer resources than the full data, while still maintaining some distinctive similarity with the full data.
@thumbnail O:1..1 200
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
440 DSTU (Revision 2013)
CONF Business Name & Description
Component Element
E&C Max Len.
ValueSet
DT-96 value Encapsulated data itself.
@value M:1..1 200
The following XML example outlines how to use the Encapsulated Data (ED) pan-Canadian Data Type
template:
<text mediaType="image/png" representation="B64"
integrityCheck="aA5mb7c8TXtu392KMsaSa2MKkAwL5LKAo2d99azAs3MdUdw">
<reference value="http://example.org/xrays/128s8d9ej229se32s.png">
<useablePeriod xsi:type="IVL_TS">
<low value="200007200845"/>
<high value="200008200845"/>
</useablePeriod>
</reference>
<thumbnail mediaType="image/jpeg" representation="B64">
MNYD83jmMdomSJUEdmde9j44zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu83
6edjzMMIjdMDSsWdIJdksIJR3373jeu83MNYD83jmMdomSJUEdmde9j44zmMir
...
omSJUEdmde9j44zmMiromSJUEdmde9j44zmMirdMDSsWdIJdksIJR3373jeu83
4zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu83==
</thumbnail>
</text>
<text mediaType="application/pdf" representation="B64" compression="GZ">
omSJUEdmde9j44zmMiromSJUEdmde9j44zmMirdMDSsWdIJdksIJR3373jeu83
6edjzMMIjdMDSsWdIJdksIJR3373jeu83MNYD83jmMdomSJUEdmde9j44zmMir
...
MNYD83jmMdomSJUEdmde9j44zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu83
4zmMir6edjzMMIjdMDSsWdIJdksIJR3373jeu83==
</text>
Figure 135: Encapsulated Data (ED) pan-Canadian Data Type entry example
8.3.5 Identifier (II) pan-Canadian Data Type
[II: templateId 2.16.840.1.113883.3.3068.10.5.4(closed)]
This template establishes specific constraints for the II data type as follows:
Table 193: Identifier (II) pan-Canadian Data Type Constraints Overview
CONF Business Name & Description
Component Element
E&C Max Len.
ValueSet
DT-73 Assigning Authority Name A human readable name or mnemonic for the assigning authority.
@assigningAuthorityName
O:0..1 N/A
DT-72 Identifier Type @use M:1..1 N/A IdentifierUse
DT-74 Root A unique identifier that guarantees the global uniqueness of the instance identifier. The root alone may be the entire instance identifier.
@root M:1..1 200
DT-75 Extension A character string as a unique identifier
@extension M:1..1 20
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
441 DSTU (Revision 2013)
CONF Business Name & Description
Component Element
E&C Max Len.
ValueSet
within the scope of the identifier root.
The following XML example outlines how to use the Identifier (II) pan-Canadian Data Type template:
<id extension="MB20120201RXD-3345639" root="2.16.840.1.113883.3.1818.10.10.5"
assigningAuthorityName="ManitobaHealth"/>
Figure 136: Identifier (II) pan-Canadian Data Type entry example
8.3.6 Person Name (PN) pan-Canadian Data Type
[PN: templateId 2.16.840.1.113883.3.3068.10.5.3(closed)]
This template establishes specific constraints for the PN data type as follows:
Table 194: Person Name (PN) pan-Canadian Data Type Constraints Overview
CONF Business Name & Description
Component Element
E&C Max Len.
ValueSet
DT-64 Person Name Use @use M:1..1 N/A x_BasicPersonNameUse
DT-65 Person Name Title prefix O:0..1 50
DT-66 Person Given Name first M:1..* 50
DT-67 Person Last Name family M:1..1 50
DT-68 Person Name Prefix prefix O:0..1 50
DT-69 Person name Suffix suffix O:0..1 50
DT-70 Person Name part The elements above, except for use, are indicate by using coded name parts
parts M:2..7 N/A x_BasicPersonNamePartType
DT-71 Person Name Qualifier Modifier for the name part type. Used to indicate in initials, for example
qualifer O:0..1 N/A x_BasicPersonNamePartQualifier
The following XML example outlines how to use the Person Name (PN) pan-Canadian Data Type
template:
<name>
<prefix qualifier="AC">Dr. phil. </prefix>
<given>Regina</given>
<given>Johanna</given>
<given>Maria</given>
<prefix qualifier="NB">Gräfin </prefix>
<family qualifier="BR">Hochheim</family>-<family qualifier="SP">Weilenfels</family>
<suffix qualifier="PR">NCFSA</suffix>
</name>
Figure 137: Person Name (PN) pan-Canadian Data Type entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
442 DSTU (Revision 2013)
8.3.7 Physical Quantity (PQ) pan-Canadian Data Type
[PQ: templateId 2.16.840.1.113883.3.3068.10.5.9(closed)]
This template establishes specific constraints for the PQ data type as follows:
Table 195: Physical Quantity (PQ) pan-Canadian Data Type Constraints Overview
CONF Business Name & Description
Component Element
E&C Max Len.
ValueSet
DT-99 Value The numerical part of a quantity.
@value M:1..1 20
DT-100 Units The units for the value
@units R:0..1 N/A UCUM
The following XML example outlines how to use the Physical Quantity (PQ) pan-Canadian Data Type
template:
<value xsi:type=”PQ” value=”22.35” unit=”mmol/l”/>
Figure 138: Physical Quantity (PQ) pan-Canadian Data Type entry example
8.3.8 Telecom (TEL) pan-Canadian Data Type
[TEL: templateId 2.16.840.1.113883.3.3068.10.5.2(closed)]
This template establishes specific constraints for the TEL data type as follows:
Table 196: Telecom (TEL) pan-Canadian Data Type Constraints Overview
CONF Business Name & Description
Component Element
E&C Max Len.
ValueSet
DT-60 Telecommunication Address Intent @use M:1..1 N/A x_BasicTelecommunicationsAddressUse
DT-61 Telecommunication Address @value M:1..1 40
DT-62 Telecommunication Address Scheme @scheme M:1..1 N/A
DT-63 Useable Time period Periods of time during which the telecommunication address can be used
@useablePeriod O:0..1 20
The following XML example outlines how to use the Telecom (TEL) pan-Canadian Data Type template:
<telecom use="H" value="tel:555-555-5001">
<useablePeriod xsi:type="IVL_TS">
<low value="200007200845"/>
<high value="200008200945"/>
</useablePeriod>
</telecom>
<telecom use="WP" value="mailto://[email protected]"/>
Figure 139: Telecom (TEL) pan-Canadian Data Type entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
443 DSTU (Revision 2013)
8.3.9 TimeStamp Interval (IVL_TS) pan-Canadian Data Type
[IVL_INT: templateId 2.16.840.1.113883.3.3068.10.5.8(closed)]
This template establishes specific constraints for the IVL_INT data type as follows:
Table 197: TimeStamp Interval (IVL_TS) pan-Canadian Data Type Constraints Overview
CONF Business Name & Description
Component Element
E&C Max Len.
ValueSet
DT-97 Low Value Initial or starting date time in a range, inclusive of start date time
@low M:1..1 20
DT-98 High Value Ending or final date time in a range, inclusive of ending date time
@high R:0..1 20
The following XML example outlines how to use the TimeStamp Interval (IVL_TS) pan-Canadian Data
Type template:
<effectiveTime>
<low value="20111231"/>
<high value="20120930"/>
</effectiveTime>
Figure 140: TimeStamp Interval (IVL_TS) pan-Canadian Data Type entry example
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
444 DSTU (Revision 2013)
9.0 VOCABULARY
9.1 OVERVIEW
This specification aims to provide a sound binding between the document element framework and, for
coded elements, an associated Value-Set Reference. Each Value-Set reference is intended to provide
clarity as to the allowable Code System or Systems from which values may be drawn and, where
applicable and feasible, to define the set of acceptable code values from that system.
A constrained set of acceptable code values (sometimes known as a reference set) is defined either by
declaring the set of codes explicitly (i.e. by enumerating them within this specification) or by implicitly
describing the set through a SQL-like set-retrieval syntax.
For example, the set of Electrocardiogram observations within LOINC® could be expressed as follows:
Select all non-deprecated LOINC_NUM values from CodeSystem LOINC (2.16.840.1.113883.6.1) Version
2.38 / 2011-12-30 where the LOINC CLASS dimension value is “EKG.MEAS”.
In some cases no appropriate external Code System may exist or the applicable Code System or
Systems are deficient in their ability to express a particular concept. In that case additional code values
and descriptions may have been defined.
Implementers should also note that there are several value sets for which stakeholders have not yet
identified a set of specific values. In most cases, a broad code system has been defined to ensure that
implementations can exchange information. It is anticipated that these value systems may, in future,
contain more meaningful, constrained subsets on the overarching code system.
9.2 EXTERNAL REFERENCES
This implementation guide incorporates certain external vocabularies and/or terminologies and may
display specific value sets and/or reference sets from these external sources as a matter of convenience
for implementers. The table below summarizes these sources as well as the specific version or date
incorporated:
Table 198: Incorporated External Vocabulary or Terminology Sources
Vocabulary / Terminology Source (Publication URL)
Version and/or Date
HL7 RIM Repository http://wiki.hl7.org/index.php?title=%20RIM_Maintenance_and_Tooling_Documentation
Voc1148 (20120324)
Infoway Master Terminology Worksheet https://www.infoway-inforoute.com/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
R02.04.03 - 20100831
Infoway / CIHI Primary Health Care (PHC) Reference Sets V1.0 (August 2012 Release)
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
445 DSTU (Revision 2013)
Vocabulary / Terminology Source (Publication URL)
Version and/or Date
https://www.infoway-inforoute.com/index.php/programs-services/standards-collaborative/pan-canadian-standards/primary-health-care-phc-reference-sets
Implementers should note the following caveats regarding use of these external vocabulary sources in
this guide:
This guide may display specific value set content from the incorporated vocabulary sources. This
content (i.e. the specific codes and descriptions) incorporated SHALL always be considered
informative. In case of discrepancy between the content shown in this guide and the original,
authoritative source, the latter SHALL be deemed correct.
Although a reference URL may have been provided, this cannot be guaranteed since the applicable
custodian organization may change publication policies and/or locations.
Access to certain value set resources maintained by the Infoway Standards Collaborative requires
membership at a certain level. These membership rules and associated costs change from time to
time. Implementers should consult directly with the Standards Collaborative for further information.
At the time of publication of this guide, membership details, including costs and associated privileges,
are available at the following URL:
https://www.infoway-inforoute.com/index.php/programs-services/standards-collaborative/membership
9.3 VALUESET REFERENCES
The following table summarizes the ValueSet references use in this guide together with applicable
binding information:
Table 199: ValueSet References & Bindings
ValueSet OID ValueSet Name Binding
Realm Type
2.16.840.1.113883.1.11.19897 ActConsentType UV STATIC
2.16.840.1.113883.1.11.13955 ActEncounterCode UV STATIC
2.16.840.1.113883.3.3068.10.8.7 ActOrderCode CA-Pending DYNAMIC
2.16.840.1.113883.2.20.3.15 ActPriority CA STATIC
2.16.840.1.113883.1.11.159331 ActStatus UV STATIC
2.16.840.1.113883.1.11.14570 AdministerableDrugForm CA STATIC
2.16.840.1.113883.1.11.1 AdministrativeGender UV STATIC
2.16.840.1.113883.3.3068.10.8.6 AdvanceDirectiveType CA-Pending STATIC
2.16.840.1.113883.3.3068.10.8.20 AlertDeviceType CA-Pending DYNAMIC
2.16.840.1.113883.3.1818.10.8.1 AlertType CA-BC-PITO STATIC
2.16.840.1.113883.3.3068.10.8.9 AllergenEntityCode CA-Pending STATIC
2.16.840.1.113883.2.20.3.211 AllergyIntoleranceStatusCode CA DYNAMIC
2.16.840.1.113883.1.11.19696 AllergyTestValue UV STATIC
2.16.840.1.113883.3.3068.10.8.25 AssignedEntityRoleCode CA-Pending STATIC
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
446 DSTU (Revision 2013)
ValueSet OID ValueSet Name Binding
Realm Type
2.16.840.1.113883.3.3068.10.8.14 AttachmentObservationType CA-Pending DYNAMIC
2.16.840.1.113883.3.3068.10.8.8 CDAHeaderActClass CA-Pending STATIC
2.16.840.1.113883.2.20.3.29 ClinicalDrug CA DYNAMIC
2.16.840.1.113883.3.1818.10.8.5 Clinically Measured Observations Codes CA-BC-PITO STATIC
2.16.840.1.113883.3.1818.10.8.6 Developmental Observations Codes CA-BC-PITO STATIC
2.16.840.1.113883.1.11.15931 DiagnosisICD9CM UV STATIC
2.16.840.1.113883.2.20.3.40 DiagnosisValuePrimary CA DYNAMIC
2.16.840.1.113883.1.11.10870 DocumentType UV DYNAMIC
2.16.840.1.113883.2.20.3.43 EncounterDischargeDisposition CA STATIC
2.16.840.1.113883.2.20.3.48 HealthcareProviderRoleType CA DYNAMIC
2.16.840.1.113883.1.11.11526 HumanLanguage UV DYNAMIC
2.16.840.1.113883.2.20.3.52 HumanSubstanceAdministrationSite CA DYNAMIC
2.16.840.1.113883.2.20.3.53 IdentifierUse CA STATIC
2.16.840.1.113883.3.3068.10.8.15 ImagingDetailObservationType CA-Pending DYNAMIC
2.16.840.1.113883.3.3068.10.8.16 ImagingProcedureObservationType CA-Pending DYNAMIC
2.16.840.1.113883.3.3068.10.8.30 InstructionTargetRole CA-Pending STATIC
1.0.3166.1 ISO3166-1–CountryCodes UV DYNAMIC
1.0.3166.2 ISO3166-2–State/Province UV DYNAMIC
2.16.840.1.113883.3.3068.10.8.19 LifeStageObservationValue CA-Pending STATIC
2.16.840.1.113883.1.11.16041 MaterialEntityClassType UV STATIC
2.16.840.1.113883.1.11.14824 MediaType UV STATIC
2.16.840.1.113883.2.20.3.78 ObservationInterpretation CA STATIC
2.16.840.1.113883.1.11.10206 ObservationInterpretationNormality UV STATIC
2.16.840.1.113883.1.11.14079 ObservationMethod UV DYNAMIC
2.16.840.1.113883.3.3068.10.8.21 ObservationValue CA-Pending DYNAMIC
2.16.840.1.113883.2.20.3.87 ParticipationFunction CA STATIC
2.16.840.1.113883.2.20.3.88 ParticipationSignature CA STATIC
2.16.840.1.113883.1.11.10901 ParticipationType UV STATIC
2.16.840.1.113883.2.20.3.90 PersonalRelationshipRoleType CA STATIC
2.16.840.1.113883.3.88.12.3221.7.2 ProblemType UV STATIC
2.16.840.1.113883.3.3068.10.8.11 Procedure CA-Pending DYNAMIC
2.16.840.1.113883.2.20.3.265 ProviderRoleCode CA DYNAMIC
2.16.840.1.113883.3.3068.10.8.18 ReactionTypeCode CA-Pending DYNAMIC
2.16.840.1.113883.3.3068.10.8.22 ReasonObservationValue CA-Pending DYNAMIC
2.16.840.1.113883.3.1818.10.8.7 Reproductive Observations Codes CA-BC-PITO STATIC
2.16.840.1.113883.3.1818.10.8.10 Reproductive Observations Organizer Codes
CA-BC-PITO STATIC
2.16.840.1.113883.3.1818.10.8.3 RiskFactorObservationType CA-BC-PITO DYNAMIC
2.16.840.1.113883.1.11.11555 RoleClass UV STATIC
2.16.840.1.113883.1.11.19316 RoleClassMutualRelationship UV STATIC
2.16.840.1.113883.2.20.3.188 RouteOfAdministration CA STATIC
2.16.840.1.113883.2.20.3.182 ServiceDeliveryLocationRoleType CA STATIC
2.16.840.1.113883.6.8 UCUM UV DYNAMIC
2.16.840.1.113883.2.20.3.264 VaccineAdministeredNameCode CA DYNAMIC
2.16.840.1.113883.1.11.11610 x_ActRelationshipDocument UV STATIC
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
447 DSTU (Revision 2013)
ValueSet OID ValueSet Name Binding
Realm Type
2.16.840.1.113883.1.11.19890 x_ActStatusActiveComplete UV STATIC
2.16.840.1.113883.2.20.3.138 x_BasicAddressPartType CA STATIC
2.16.840.1.113883.2.20.3.139 x_BasicConfidentialityKind CA STATIC
2.16.840.1.113883.2.20.3.140 x_BasicPersonNamePartQualifier CA STATIC
2.16.840.1.113883.2.20.3.141 x_BasicPersonNamePartType CA STATIC
2.16.840.1.113883.2.20.3.142 x_BasicPersonNameUse CA STATIC
2.16.840.1.113883.2.20.3.143 x_BasicPostalAddressUse CA STATIC
2.16.840.1.113883.2.20.3.144 x_BasicTelecommunicationsAddressUse CA STATIC
2.16.840.1.113883.3.3068.10.8.12 x_ComponentStartsBefore CA-Pending STATIC
2.16.840.1.113883.1.11.19600 x_EncounterParticipant UV STATIC
2.16.840.1.113883.1.11.19741 x_PhoneOrEmailURLScheme UV STATIC
2.16.840.1.113883.1.11.19601 x_ServiceEventPerformer UV STATIC
ActConsentType
Table 200: ActConsentType Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.19897 STATIC
Code System(s) ActCode 2.16.840.1.113883.5.4
Description
Definition: The type of consent directive, e.g., to consent or dissent to collect, access, or use in specific ways within an EHRS or for health information exchange; or to disclose health information for purposes such as research.
Authority HL7 International
Reference URL http://www.hl7.org
ActEncounterCode
Table 201: ActEncounterCode Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.13955 STATIC
Code System(s) ActCode 2.16.840.1.113883.5.4
Description Domain provides codes that qualify the ActEncounterClass (ENC)
Authority HL7 International
Reference URL http://www.hl7.org
ActOrderCode
Table 202: ActOrderCode Definition
ValueSet OID & Binding
2.16.840.1.113883.3.3068.10.8.7 DYNAMIC
Code System(s) ActCode, LOINC
Description The types of orders to which a document may be in response.
Authority Infoway Standards Collaborative (once submitted and accepted)
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
448 DSTU (Revision 2013)
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Intentional Definition
Applicable codes from ActCode or LOINC.
ActPriority
Table 203: ActPriority Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.15 STATIC
Code System(s) ActPriority 2.16.840.1.113883.5.7
Description N/A
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
ActStatus
Table 204: ActStatus Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.159331 STATIC
Code System(s) ActStatus 2.16.840.1.113883.5.14
Description Contains the names (codes) for each of the states in the state-machine of the RIM Act class.
Authority HL7 International
Reference URL http://www.hl7.org
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
active ActStatus active
cancelled ActStatus cancelled
completed ActStatus completed
held ActStatus held
new ActStatus new
normal ActStatus normal
nullified ActStatus nullified
obsolete ActStatus obsolete
suspended ActStatus suspended
aborted ActStatus aborted
AdministerableDrugForm
Table 205: AdministerableDrugForm Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.14570 STATIC
Code System(s) OrderableDrugForm 2.16.840.1.113883.5.85
Description Indicates the form in which the drug product should be administered. This element only needs to be specified when (a) the form in which the drug is measured for
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
449 DSTU (Revision 2013)
dispensing differs from the form in which the drug is administered; and (b) the form in which the quantity of the administered drug being administered is not expressed as a discrete measured mass or volume.Usage:
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
AdministrativeGender
Table 206: AdministrativeGender Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.1 STATIC
Code System(s) AdministrativeGender 2.16.840.1.113883.5.1
Description The gender of a person used for adminstrative purposes (as opposed to clinical gender)
Authority HL7 International
Reference URL http://www.hl7.org
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
F AdministrativeGender Female
M AdministrativeGender Male
UN AdministrativeGender Undifferentiated
AdvanceDirectiveType
Table 207: AdvanceDirectiveType Definition
ValueSet OID & Binding
2.16.840.1.113883.3.3068.10.8.6 STATIC
Code System(s) SNOMED-CT 2.16.840.1.113883.6.96
Description The types of advance directives.
Authority Infoway Standards Collaborative (once submitted and accepted)
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
52765003 SNOMED-CT Intubation
61420007 SNOMED-CT Tube Feedings
71388002 SNOMED-CT Other Directive
78823007 SNOMED-CT Life Support
89666000 SNOMED-CT CPR
225204009 SNOMED-CT IV Fluid and Support
281789004 SNOMED-CT Antibiotics
304251008 SNOMED-CT Resuscitation
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
450 DSTU (Revision 2013)
AlertDeviceType
Table 208: AlertDeviceType Definition
ValueSet OID & Binding
2.16.840.1.113883.3.3068.10.8.20 DYNAMIC
Code System(s) SNOMED CT, Observation Type
Description The types of devices or mechnisms that are used to convey a medical alert.
Authority Infoway Standards Collaborative (once submitted and accepted)
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
38472000 SNOMED-CT Medical alert identification bracelet
MEDITATTOO ObservationType-CA-Pending Medical alert tattoo
MEDINECKLACE ObservationInterpretation Medical alert necklace
MEDICARD ObservationInterpretation Medical alert wallet card
AlertType
Table 209: AlertType Definition
ValueSet OID & Binding
2.16.840.1.113883.3.1818.10.8.1 STATIC
Code System(s) ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3
Description The types of alerts.
Authority BC Physician Information Technology Office (PITO)
Reference URL http://www.pito.bc.ca
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
ADVREAC ObservationType-CA-Pending Adverse Drug Reaction
HISTODNR ObservationType-CA-Pending Past History of Organ Donation
HLITERACY ObservationType-CA-Pending Health Literacy
INFECTIOUS ObservationType-CA-Pending Infectious Disease Alert
LITERACY ObservationType-CA-Pending Literacy
ORGANDNR ObservationType-CA-Pending Organ Donor
OTHERALRT ObservationType-CA-Pending Other Alert
PILOT ObservationType-CA-Pending Airplane Pilot
PREFER ObservationType-CA-Pending Patient preferences
PREVSVCS ObservationType-CA-Pending Alerts for Preventative Services
PROSPODNR ObservationType-CA-Pending Prospective Organ Donor
SPECNEED ObservationType-CA-Pending Special Needs
TRANSPLANT ObservationType-CA-Pending Transplant Recipient
AllergenEntityCode
Table 210: AllergenEntityCode Definition
ValueSet OID & 2.16.840.1.113883.3.3068.10.8.9 STATIC
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
451 DSTU (Revision 2013)
Binding
Code System(s) SNOMED CT, DIN
Description A list of possible allergens (i.e. materials) against which an allergic reaction or intolerance can be experienced.
Authority Infoway Standards Collaborative (once submitted and accepted)
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Intentional Definition
May be a ClinicalDrug (Value-set 2.16.840.1.113883.2.20.3.29) or NonDrugAllergenCode (Value-set 2.16.840.1.113883.2.20.3.269). Please refer to the pan-Canadian terminology and associated reference sets for further details.
AllergyIntoleranceStatusCode
Table 211: AllergyIntoleranceStatusCode Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.211 DYNAMIC
Code System(s) SNOMED-CT 2.16.840.1.113883.6.96
Description Represents whether an allergy/intolerance is “active” or resolved (indicating no longer active).
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/primary-health-care-phc-reference-sets
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
55561003 SNOMED-CT Active (qualifier value)
89925002 SNOMED-CT Cancelled (qualifier value)
410605003 SNOMED-CT Confirmed present (qualifier value)
785327971000087107 SNOMED-CT Invalidated (qualifier value)
475855351000087108 SNOMED-CT Proposed (qualifier value)
625759261000087105 SNOMED-CT Refuted (qualifier value)
383830771000087105 SNOMED-CT Resolved (qualifier value)
AllergyTestValue
Table 212: AllergyTestValue Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.19696 STATIC
Code System(s) ObservationValue 2.16.840.1.113883.5.1063
Description Indicates the result of a particular allergy test. E.g. Negative, Mild, Moderate, Severe
Authority HL7 International
Reference URL http://www.hl7.org
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
A3 ObservationValue moderate reaction
A4 ObservationValue severe reaction
A0 ObservationValue no reaction
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
452 DSTU (Revision 2013)
Code Code System Description / Print Name
A1 ObservationValue minimal reaction
A2 ObservationValue mild reaction
AssignedEntityRoleCode
Table 213: AssignedEntityRoleCode Definition
ValueSet OID & Binding
2.16.840.1.113883.3.3068.10.8.25 STATIC
Code System(s) RoleCode 2.16.840.1.113883.5.111
Description N/A
Authority Infoway Standards Collaborative (once submitted and accepted)
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
AttachmentObservationType
Table 214: AttachmentObservationType Definition
ValueSet OID & Binding
2.16.840.1.113883.3.3068.10.8.14 DYNAMIC
Code System(s) LOINC 2.16.840.1.113883.6.1
Description The types of documents or conceptual content that can be represented by attachments to allow tagging attachments in clinical document instances. Note that this is distinct from the concept of the MIME-type which designates the logical structure / format of an attachment.
Authority Infoway Standards Collaborative (once submitted and accepted)
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Intentional Definition
Applicable codes from LOINC
CDAHeaderActClass
Table 215: CDAHeaderActClass Definition
ValueSet OID & Binding
2.16.840.1.113883.3.3068.10.8.8 STATIC
Code System(s) ActClass 2.16.840.1.113883.5.6
Description The set of valid ActClass codes for use in CDA headers to designate the Act of an order being fulfilled or of a service event being documented.
Authority Infoway Standards Collaborative (once submitted and accepted)
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
ACT ActClass Act
CONS ActClass Consent
DOCBODY ActClass Document Body
DOCCLIN ActClass Clinical Document
DOCSECT ActClass Document Section
ENC ActClass Encounter
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
453 DSTU (Revision 2013)
ClinicalDrug
Table 216: ClinicalDrug Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.29 DYNAMIC
Code System(s) See Infoway Master Terminology Worksheet (MTW)
Description N/A
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Intentional Definition
See Infoway Master Terminology Worksheet (MTW)
Clinically Measured Observations Codes
Table 217: Clinically Measured Observations Codes Definition
ValueSet OID & Binding
2.16.840.1.113883.3.1818.10.8.5 STATIC
Code System(s) LOINC, SNOMED CT
Description The list of codes to identify specific clinically measured observations (e.g. Systolic blood pressure diastolic blood pressure, body weight, height, etc.)
Authority BC Physician Information Technology Office (PITO)
Reference URL http://www.pito.bc.ca
Intentional Definition
Applicable codes from SNOMED CT or LOINC.
Developmental Observations Codes
Table 218: Developmental Observations Codes Definition
ValueSet OID & Binding
2.16.840.1.113883.3.1818.10.8.6 STATIC
Code System(s) LOINC, SNOMED CT
Description The list of codes to identify specific developmental observations.
Authority BC Physician Information Technology Office (PITO)
Reference URL http://www.pito.bc.ca
Intentional Definition
Applicable codes from SNOMED CT or LOINC.
DiagnosisICD9CM
Table 219: DiagnosisICD9CM Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.15931 STATIC
Code System(s) icd9cm 2.16.840.1.113883.6.2
Description N/A
Authority HL7 International
Reference URL http://www.hl7.org
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
454 DSTU (Revision 2013)
DiagnosisValuePrimary
Table 220: DiagnosisValuePrimary Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.40 DYNAMIC
Code System(s) SNOMED-CT 2.16.840.1.113883.6.96
Description N/A
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Example codes shown below (Please consult authoritative source for full value set content).
Code Code System Description / Print Name
274945004 SNOMED-CT AA amyloidosis (disorder)
112143006 SNOMED-CT ABO group phenotype (finding)
341009 SNOMED-CT ABO incompatibility reaction (disorder)
3885002 SNOMED-CT ABO isoimmunization affecting pregnancy (disorder)
371627004 SNOMED-CT ACE inhibitor-aggravated angioedema (disorder)
237692001 SNOMED-CT ACTH deficiency (disorder)
237669001 SNOMED-CT ACTH hypersecretion (disorder)
237670000 SNOMED-CT ACTH hypersecretion not causing Cushing's syndrome (disorder)
237734007 SNOMED-CT ACTH-dependent Cushing's syndrome (disorder)
281882003 SNOMED-CT AD type amyloidosis (disorder)
... ... ...
DocumentType
Table 221: DocumentType Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.10870 DYNAMIC
Code System(s) LOINC 2.16.840.1.113883.6.1
Description
The kind of document. Possible values: discharge summary, progress note, Oncology note, etc.
Authority HL7 International
Reference URL http://www.hl7.org
EncounterDischargeDisposition
Table 222: EncounterDischargeDisposition Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.43 STATIC
Code System(s) SNOMED-CT 2.16.840.1.113883.6.96
Description N/A
Authority Infoway Standards Collaborative
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
455 DSTU (Revision 2013)
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Example codes shown below (Please consult authoritative source for full value set content).
Code Code System Description / Print Name
306689006 SNOMED-CT discharged home
30164005 SNOMED-CT left against medical advice
397709008 SNOMED-CT patient died
237364002 SNOMED-CT stillbirth
11545006 SNOMED-CT DOA
75004002 SNOMED-CT Died in Emergency Room
306691003 SNOMED-CT discharge to residential home
57976004 SNOMED-CT transfer within facility
306700000 SNOMED-CT discharge to long stay hospital
306691003 SNOMED-CT discharge to residential home
... ... ...
HealthcareProviderRoleType
Table 223: HealthcareProviderRoleType Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.48 DYNAMIC
Code System(s) SCPTYPE 2.16.840.1.113883.2.20.5.3
Description N/A
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
HumanLanguage
Table 224: HumanLanguage Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.11526 DYNAMIC
Code System(s) ietf3066 2.16.840.1.113883.6.121
Description Codes for the representation of the names of human languages.
Authority HL7 International
Reference URL http://www.hl7.org
Intentional Definition
All codes from iso3066
HumanSubstanceAdministrationSite
Table 225: HumanSubstanceAdministrationSite Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.52 DYNAMIC
Code System(s) bodySite 2.16.840.1.113883.12.163
Description N/A
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
456 DSTU (Revision 2013)
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Example codes shown below (Please consult authoritative source for full value set content).
Code Code System Description / Print Name
BE bodySite bilateral ears
BN bodySite bilateral nares
BU bodySite buttock
LA bodySite left arm
LAC bodySite left anterior chest
LACF bodySite left antecubital fossa
LD bodySite left deltoid
LE bodySite left ear
LEJ bodySite left external jugular
LF bodySite left foot
... ... ...
IdentifierUse
Table 226: IdentifierUse Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.53 STATIC
Code System(s) SCTEMP 2.16.840.1.113883.2.20.5.2
Description Codes to specify the scope in which the identifier applies to the object with which it is associated, and used in the datatype property II.use.
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Value set shown below may not be complete (Please consult the authoritative source).
Code Code System Description / Print Name
BUS SCTEMP Business identifier
VER SCTEMP Version identifier
ImagingDetailObservationType
Table 227: ImagingDetailObservationType Definition
ValueSet OID & Binding
2.16.840.1.113883.3.3068.10.8.15 DYNAMIC
Code System(s) LOINC 2.16.840.1.113883.6.1
Description N/A
Authority Infoway Standards Collaborative (once submitted and accepted)
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Intentional Definition
Applicable codes from LOINC
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
457 DSTU (Revision 2013)
ImagingProcedureObservationType
Table 228: ImagingProcedureObservationType Definition
ValueSet OID & Binding
2.16.840.1.113883.3.3068.10.8.16 DYNAMIC
Code System(s) SNOMED-CT 2.16.840.1.113883.6.96
Description N/A
Authority Infoway Standards Collaborative (once submitted and accepted)
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Intentional Definition
Applicable codes from SNOMED CT
InstructionTargetRole
Table 229: InstructionTargetRole Definition
ValueSet OID & Binding
2.16.840.1.113883.3.3068.10.8.30 STATIC
Code System(s) RoleClass, SCPTYPE
Description Target roles for instructions.
Authority GPi
Reference URL http://www.gpinformatics.com
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
PAT RoleClass Patient
PHARM SCPTYPE Pharmacist
ISO3166-1–CountryCodes
Table 230: ISO3166-1–CountryCodes Definition
ValueSet OID & Binding
1.0.3166.1 DYNAMIC
Code System(s) iso3166-1 1.0.3166.1
Description
ISO 3166 is the International Standard for country codes and codes for their subdivisions. The purpose of ISO 3166 is to establish internationally recognised codes for the representation of names of countries, territories or areas of geographical interest, and their subdivisions. However, ISO 3166 does not establish the names of countries, only the codes that represent them. The country names in ISO 3166 come from United Nations sources. New names and codes are added automatically when the United Nations publishes new names in either the Terminology Bulletin Country Names or in the Country and Region Codes for Statistical Use maintained by the United Nations Statistics Divisions. Names for subdivisions are taken from relevant official national information sources. (Source: http://www.iso.org/iso/country_codes)
Authority International Standards Organization (ISO)
Reference URL http://www.iso.org/iso/country_codes/country_codes
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
458 DSTU (Revision 2013)
ISO3166-2–State/Province
Table 231: ISO3166-2–State/Province Definition
ValueSet OID & Binding
1.0.3166.2 DYNAMIC
Code System(s) iso3166-2 1.0.3166.2
Description
ISO 3166-2:2007 establishes codes for the names of the principal subdivisions (e.g provinces or states) of all countries coded in ISO 3166-1. This code is based on the two-letter code element from ISO 3166-1 followed by a separator and up to three alphanumeric characters. The characters after the separator cannot be used on their own to denote a subdivision, they must be preceded by the alpha-2 country code. For example – ID-RI is the Riau province of Indonesia and NG-RI is the Rivers province in Nigeria. The codes denoting the subdivision are usually obtained from national sources and stem from coding systems already in place in the country. (Source: http://www.iso.org/iso/country_codes)
Authority International Standards Organization (ISO)
Reference URL http://www.iso.org/iso/country_codes/country_codes
LifeStageObservationValue
Table 232: LifeStageObservationValue Definition
ValueSet OID & Binding
2.16.840.1.113883.3.3068.10.8.19 STATIC
Code System(s) SNOMED-CT 2.16.840.1.113883.6.96
Description
The list of life stages for classification of various observations, typically pertaining to various types of medical or family history. The set of concepts was sourced from the OntarioMD EMR specification but is expressed here through SNOMED CT concept codes rather than via the custom Ontario codes.
Authority Infoway Standards Collaborative (once submitted and accepted)
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
133936004 SNOMED-CT Adult
133937008 SNOMED-CT Adolescent
410601007 SNOMED-CT Child
133931009 SNOMED-CT Infant
133933007 SNOMED-CT Newborn
MaterialEntityClassType
Table 233: MaterialEntityClassType Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.16041 STATIC
Code System(s) EntityCode 2.16.840.1.113883.5.1060
Description Types of Material for EntityClass "MAT"
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
459 DSTU (Revision 2013)
Authority HL7 International
Reference URL http://www.hl7.org
MediaType
Table 234: MediaType Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.14824 STATIC
Code System(s) mediaType 2.16.840.1.113883.5.79
Description Internet Assigned Numbers Authority (IANA) Mime Media Types
Authority HL7 International
Reference URL http://www.hl7.org
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
application mediaType ApplicationMediaType
application/dicom mediaType DICOM
application/msword mediaType MSWORD
application/pdf mediaType PDF
audio mediaType AudioMediaType
text mediaType TextMediaType
text/html mediaType HTML Text
text/plain mediaType Plain Text
text/rtf mediaType RTF Text
text/sgml mediaType SGML Text
text/x-hl7-ft mediaType HL7 Text
text/x-hl7-text+xml mediaType HL7 Structured Narrative
text/xml mediaType XML Text
video mediaType VideoMediaType
video/mpeg mediaType MPEG Video
video/x-avi mediaType X-AVI Video
audio/basic mediaType Basic Audio
audio/k32adpcm mediaType K32ADPCM Audio
audio/mpeg mediaType MPEG audio layer 3
image mediaType ImageMediaType
image/g3fax mediaType G3Fax Image
image/gif mediaType GIF Image
image/jpeg mediaType JPEG Image
image/png mediaType PNG Image
image/tiff mediaType TIFF Image
model mediaType ModelMediaType
model/vrml mediaType VRML Model
multipart mediaType MultipartMediaType
multipart/x-hl7-cda-level-one mediaType CDA Level 1 Multipart
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
460 DSTU (Revision 2013)
ObservationInterpretation
Table 235: ObservationInterpretation Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.78 STATIC
Code System(s) ObservationInterpretation 2.16.840.1.113883.5.83
Description N/A
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Example codes shown below (Please consult authoritative source for full value set content).
Code Code System Description / Print Name
B ObservationInterpretation better
D ObservationInterpretation decreased
U ObservationInterpretation increased
W ObservationInterpretation worse
< ObservationInterpretation low off scale
> ObservationInterpretation high off scale
A ObservationInterpretation Abnormal
AA ObservationInterpretation Abnormal alert
HH ObservationInterpretation High alert
LL ObservationInterpretation Low alert
... ... ...
ObservationInterpretationNormality
Table 236: ObservationInterpretationNormality Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.10206 STATIC
Code System(s) ObservationInterpretation 2.16.840.1.113883.5.83
Description
Normality, Abnormality, Alert. Concepts in this category are mutually exclusive, i.e., at most one is allowed.
Authority HL7 International
Reference URL http://www.hl7.org
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
N ObservationInterpretation Normal
HH ObservationInterpretation High alert
LL ObservationInterpretation Low alert
HH ObservationInterpretation High alert
LL ObservationInterpretation Low alert
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
461 DSTU (Revision 2013)
ObservationMethod
Table 237: ObservationMethod Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.14079 DYNAMIC
Code System(s) ObservationMethod 2.16.840.1.113883.5.84
Description
A code that provides additional detail about the means or technique used to ascertain the observation. Examples: Blood pressure measurement method: arterial puncture vs. sphygmomanometer (Riva-Rocci), sitting vs. supine position, etc. Constraints: In all observations the method is already partially specified by the Act.code. In this case, the methodCode NEED NOT be used at all. The methodCode MAY still be used to identify this method more clearly in addition to what is implied from the Act.code. However, an information consumer system or process SHOULD NOT depend on this methodCode information for method detail that is implied by the Act.code. If the methodCode is used to express method detail that is also implied by the Act.code, the methodCode MUST NOT be in conflict with the implied method of the Act.code.
Authority HL7 International
Reference URL http://www.hl7.org
Code Table Filter Example codes shown below (Please consult authoritative source for full value set content).
Code Code System Description / Print Name
0001 ObservationMethod Complement fixation
0002 ObservationMethod Computed axial tomography
0003 ObservationMethod HLAR agar test
0016 ObservationMethod Card agglutination
0017 ObservationMethod Hemagglutination
0018 ObservationMethod Hemagglutination inhibition
0019 ObservationMethod Latex agglutination
0020 ObservationMethod Plate agglutination
0021 ObservationMethod Rapid agglutination
0022 ObservationMethod RBC agglutination
... ... ...
ObservationValue
Table 238: ObservationValue Definition
ValueSet OID & Binding
2.16.840.1.113883.3.3068.10.8.21 DYNAMIC
Code System(s) ObservationValue 2.16.840.1.113883.5.1063
Description N/A
Authority Infoway Standards Collaborative (once submitted and accepted)
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
462 DSTU (Revision 2013)
ParticipationFunction
Table 239: ParticipationFunction Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.87 STATIC
Code System(s) ParticipationFunction 2.16.840.1.113883.5.88
Description N/A
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Value set shown below may not be complete (Please consult the authoritative source).
Code Code System Description / Print Name
ANRS ParticipationFunction anesthesia nurse
ANEST ParticipationFunction anesthesist
ATTPHYS ParticipationFunction attending physician
DISPHYS ParticipationFunction discharging physician
FASST ParticipationFunction first assistant surgeon
MDWF ParticipationFunction midwife
NASST ParticipationFunction nurse assistant
PCP ParticipationFunction primary care physician
PRISURG ParticipationFunction primary surgeon
RNDPHYS ParticipationFunction rounding physician
SNRS ParticipationFunction scrub nurse
SASST ParticipationFunction second assistant surgeon
TASST ParticipationFunction third assistant
ADMPHYS ParticipationFunction admitting physician
ParticipationSignature
Table 240: ParticipationSignature Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.88 STATIC
Code System(s) ParticipationSignature 2.16.840.1.113883.5.89
Description N/A
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Value set shown below may not be complete (Please consult the authoritative source).
Code Code System Description / Print Name
S ParticipationSignature signed
ParticipationType
Table 241: ParticipationType Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.10901 STATIC
Code System(s) ParticipationType 2.16.840.1.113883.5.90
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
463 DSTU (Revision 2013)
Description
A code specifying the meaning and purpose of every Participation instance. Each of its values implies specific constraints on the Roles undertaking the participation.
Authority HL7 International
Reference URL http://www.hl7.org
PersonalRelationshipRoleType
Table 242: PersonalRelationshipRoleType Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.90 STATIC
Code System(s) RoleCode 2.16.840.1.113883.5.111
Description N/A
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Value set shown below may not be complete (Please consult the authoritative source).
Code Code System Description / Print Name
FAMMEMB RoleCode Family Member
AUNT RoleCode aunt
MAUNT RoleCode MaternalAunt
PAUNT RoleCode PaternalAunt
CHILD RoleCode Child
SONC RoleCode Son
SONADOPT RoleCode adopted son
SONFOST RoleCode foster son
SON RoleCode natural son
STPSON RoleCode stepson
DAUC RoleCode Daughter
DAUADOPT RoleCode adopted daughter
DAUFOST RoleCode foster daughter
DAU RoleCode natural daughter
STPDAU RoleCode stepdaughter
CHLDADOPT RoleCode adopted child
DAUADOPT RoleCode adopted daughter
SONADOPT RoleCode adopted son
CHLDFOST RoleCode foster child
DAUFOST RoleCode foster daughter
SONFOST RoleCode foster son
CHLDINLAW RoleCode child in-law
DAUINLAW RoleCode daughter in-law
SONINLAW RoleCode son in-law
NCHILD RoleCode natural child
DAU RoleCode natural daughter
SON RoleCode natural son
STPCHLD RoleCode step child
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
464 DSTU (Revision 2013)
Code Code System Description / Print Name
STPDAU RoleCode stepdaughter
STPSON RoleCode stepson
COUSN RoleCode cousin
MCOUSN RoleCode MaternalCousin
PCOUSN RoleCode PaternalCousin
DOMPART RoleCode domestic partner
GGRPRN RoleCode great grandparent
GGRFTH RoleCode great grandfather
GGRMTH RoleCode great grandmother
MGGRFTH RoleCode MaternalGreatgrandfather
MGGRMTH RoleCode MaternalGreatgrandmother
MGGRPRN RoleCode MaternalGreatgrandparent
PGGRFTH RoleCode PaternalGreatgrandfather
PGGRMTH RoleCode PaternalGreatgrandmother
PGGRPRN RoleCode PaternalGreatgrandparent
GRNDCHILD RoleCode grandchild
GRNDDAU RoleCode granddaughter
GRNDSON RoleCode grandson
GRPRN RoleCode Grandparent
GRFTH RoleCode Grandfather
GRMTH RoleCode Grandmother
MGRFTH RoleCode MaternalGrandfather
MGRMTH RoleCode MaternalGrandmother
MGRPRN RoleCode MaternalGrandparent
PGRFTH RoleCode PaternalGrandfather
PGRMTH RoleCode PaternalGrandmother
PGRPRN RoleCode PaternalGrandparent
NIENEPH RoleCode niece/nephew
NEPHEW RoleCode nephew
NIECE RoleCode niece
PRN RoleCode Parent
FTH RoleCode Father
MTH RoleCode Mother
NPRN RoleCode natural parent
NFTH RoleCode natural father
NFTHF RoleCode natural father of fetus
NMTH RoleCode natural mother
PRNINLAW RoleCode parent in-law
FTHINLAW RoleCode father-in-law
MTHINLAW RoleCode mother-in-law
STPPRN RoleCode step parent
STPFTH RoleCode stepfather
STPMTH RoleCode stepmother
ROOM RoleCode Roomate
SIB RoleCode Sibling
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
465 DSTU (Revision 2013)
Code Code System Description / Print Name
BRO RoleCode Brother
HSIB RoleCode half-sibling
HBRO RoleCode half-brother
HSIS RoleCode half-sister
NSIB RoleCode natural sibling
NBRO RoleCode natural brother
NSIS RoleCode natural sister
SIBINLAW RoleCode sibling in-law
BROINLAW RoleCode brother-in-law
SISINLAW RoleCode sister-in-law
SIS RoleCode Sister
STPSIB RoleCode step sibling
STPBRO RoleCode stepbrother
STPSIS RoleCode stepsister
SIGOTHR RoleCode significant other
SPS RoleCode spouse
HUSB RoleCode husband
WIFE RoleCode wife
UNCLE RoleCode uncle
MUNCLE RoleCode MaternalUncle
PUNCLE RoleCode PaternalUncle
FRND RoleCode unrelated friend
NBOR RoleCode neighbor
ECON RoleCode emergency contact
NOK RoleCode next of kin
GUARD RoleCode guardian
SUBDM SCTEMP substitute decision maker
POWATT RoleCode Power of attorney
POWATYPR RoleCode Power of attorney-Personal
POWATYPT RoleCode Power of attorney-Property
ProblemType
Table 243: ProblemType Definition
ValueSet OID & Binding
2.16.840.1.113883.3.88.12.3221.7.2 STATIC
Code System(s) SNOMED-CT 2.16.840.1.113883.6.96
Description This value set indicates the level of medical judgment used to determine the existence of a problem.
Authority HL7 International
Reference URL http://www.hl7.org
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
404684003 SNOMED-CT Finding
409586006 SNOMED-CT Complaint
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
466 DSTU (Revision 2013)
Code Code System Description / Print Name
282291009 SNOMED-CT Diagnosis
64572001 SNOMED-CT Condition
248536006 SNOMED-CT Functional limitation
418799008 SNOMED-CT Symptom
55607006 SNOMED-CT Problem
Procedure
Table 244: Procedure Definition
ValueSet OID & Binding
2.16.840.1.113883.3.3068.10.8.11 DYNAMIC
Code System(s) SNOMED-CT 2.16.840.1.113883.6.96
Description The list of procedure codes applicable in Primary Care
Authority Infoway Standards Collaborative (once submitted and accepted)
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Intentional Definition
Applicable codes from SNOMED CT. Implementers may wish to consider the following Infoway/CIHI Primary Care Refsets: InterventionCode (2.16.840.1.113883.2.20.3.270); InterventionCodeSubsetAssessmentTool (2.16.840.1.113883.2.20.3.272); or InterventionCodeSubsetCare (2.16.840.1.113883.2.20.3.271).
ProviderRoleCode
Table 245: ProviderRoleCode Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.265 DYNAMIC
Code System(s) SNOMED-CT 2.16.840.1.113883.6.96
Description Represents the role of the Provider in relation to his/her participation in a specific health care event.
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/primary-health-care-phc-reference-sets
Code Table Filter Example codes shown below (Please consult authoritative source for full value set content).
Code Code System Description / Print Name
309294001 SNOMED-CT Accident and Emergency doctor (occupation)
224537001 SNOMED-CT Accident and Emergency nurse (occupation)
446701002 SNOMED-CT Addiction medicine specialist (occupation)
309339007 SNOMED-CT Adult intensive care specialist (occupation)
309328009 SNOMED-CT Ambulatory pediatrician (occupation)
309351009 SNOMED-CT Andrologist (occupation)
88189002 SNOMED-CT Anesthesiologist (occupation)
158970007 SNOMED-CT Anesthetist (occupation)
159038001 SNOMED-CT Artificial limb fitter (occupation)
445313000 SNOMED-CT Asthma nurse specialist (occupation)
... ... ...
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
467 DSTU (Revision 2013)
ReactionTypeCode
Table 246: ReactionTypeCode Definition
ValueSet OID & Binding
2.16.840.1.113883.3.3068.10.8.18 DYNAMIC
Code System(s) ActCode 2.16.840.1.113883.5.4
Description A set of values to classify a reaction (e.g. Allergy, Drug Allergy, Food Intolerance, etc.).
Authority Infoway Standards Collaborative (once submitted and accepted)
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
ALG ActCode Allergy (Unspecified)
DALG ActCode Drug Allergy
DINT ActCode Drug Intolerance
DNAINT ActCode Drug Non-Allergy Intolerance
EALG ActCode Environmental Allergy
EINT ActCode Environmental Intolerance
ENAINT ActCode Environmental Non-Allergy Intolerance
FALG ActCode Food Allergy
FINT ActCode Food Intolerance
FNAINT ActCode Food Non-Allergy Intolerance
NAINT ActCode Non-Allergy Intolerance (Unspecified)
OINT ActCode Intolerance (Unspecified)
ReasonObservationValue
Table 247: ReasonObservationValue Definition
ValueSet OID & Binding
2.16.840.1.113883.3.3068.10.8.22 DYNAMIC
Code System(s) SNOMED-CT 2.16.840.1.113883.6.96
Description The list of possible reasons for an event. These could be administrative causes (e.g. patient needs a form completed; patient needs a check-up; etc.) or specific clinical reasons, including symptoms, disorders, or other indications.
Authority Infoway Standards Collaborative (once submitted and accepted)
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Reproductive Observations Codes
Table 248: Reproductive Observations Codes Definition
ValueSet OID & Binding
2.16.840.1.113883.3.1818.10.8.7 STATIC
Code System(s) LOINC, SNOMED CT
Description The list of codes to identify specific reproductive observations.
Authority BC Physician Information Technology Office (PITO)
Reference URL http://www.pito.bc.ca
Intentional Applicable codes from SNOMED CT or LOINC.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
468 DSTU (Revision 2013)
Definition
Reproductive Observations Organizer Codes
Table 249: Reproductive Observations Organizer Codes Definition
ValueSet OID & Binding
2.16.840.1.113883.3.1818.10.8.10 STATIC
Code System(s) LOINC, SNOMED CT
Description The list of valid organizer types for reproductive observations.
Authority BC Physician Information Technology Office (PITO)
Reference URL http://www.pito.bc.ca
Intentional Definition
Applicable codes from SNOMED CT or LOINC.
RiskFactorObservationType
Table 250: RiskFactorObservationType Definition
ValueSet OID & Binding
2.16.840.1.113883.3.1818.10.8.3 DYNAMIC
Code System(s) ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3
Description N/A
Authority BC Physician Information Technology Office (PITO)
Reference URL http://www.pito.bc.ca
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
SMOKSTS ObservationType-CA-Pending Smoking Status
SMOKXDY ObservationType-CA-Pending Smoking Packs/Day
RoleClass
Table 251: RoleClass Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.11555 STATIC
Code System(s) RoleClass 2.16.840.1.113883.5.110
Description
This table includes codes for the Role class hierarchy. The values in this hierarchy, represent a Role which is an association or relationship between two entities - the entity that plays the role and the entity that scopes the role. Roles names are derived from the name of the playing entity in that role. The role hierarchy stems from three core concepts, or abstract domains: RoleClassOntological is an abstract domain that collects roles in which the playing entity is defined or specified by the scoping entity. RoleClassPartitive collects roles in which the playing entity is in some sense a "part" of the scoping entity. RoleClassAssociative collects all of the remaining forms of association between the playing
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
469 DSTU (Revision 2013)
entity and the scoping entity. This set of roles is further partitioned between: RoleClassPassive which are roles in which the playing entity is used, known, treated, handled, built, or destroyed, etc. under the auspices of the scoping entity. The playing entity is passive in these roles in that the role exists without an agreement from the playing entity. RoleClassMutualRelationship which are relationships based on mutual behavior of the two entities. The basis of these relationship may be formal agreements or they may be de facto behavior. Thus, this sub-domain is further divided into: RoleClassRelationshipFormal in which the relationship is formally defined, frequently by a contract or agreement. Personal relationship which inks two people in a personal relationship. The hierarchy discussed above is represented In the current vocabulary tables as a set of abstract domains, with the exception of the "Personal relationship" which is a leaf concept.
Authority HL7 International
Reference URL http://www.hl7.org
RoleClassMutualRelationship
Table 252: RoleClassMutualRelationship Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.19316 STATIC
Code System(s) RoleClass 2.16.840.1.113883.5.110
Description
A relationship that is based on mutual behavior of the two Entities as being related. The basis of such relationship may be agreements (e.g., spouses, contract parties) or they may be de facto behavior (e.g. friends) or may be an incidental involvement with each other (e.g. parties over a dispute, siblings, children).
Authority HL7 International
Reference URL http://www.hl7.org
Intentional Definition
See HL7 Reference Information Model (RIM)
RouteOfAdministration
Table 253: RouteOfAdministration Definition
ValueSet OID & 2.16.840.1.113883.2.20.3.188 STATIC
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
470 DSTU (Revision 2013)
Binding
Code System(s) RouteOfAdministration 2.16.840.1.113883.5.112
Description N/A
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Example codes shown below (Please consult authoritative source for full value set content).
Code Code System Description / Print Name
CHEW RouteOfAdministration chew, oral
EXTCORPDIF RouteOfAdministration diffusion, extracorporeal
HEMODIFF RouteOfAdministration diffusion, hemodialysis
TRNSDERMD RouteOfAdministration diffusion, transdermal
DISSOLVE RouteOfAdministration dissolve, oral
SL RouteOfAdministration dissolve, sublingual
DOUCHE RouteOfAdministration douche, vaginal
ELECTOSMOS RouteOfAdministration electro-osmosis
ENEMA RouteOfAdministration enema, rectal
RETENEMA RouteOfAdministration enema, rectal retention
... ... ...
ServiceDeliveryLocationRoleType
Table 254: ServiceDeliveryLocationRoleType Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.182 STATIC
Code System(s) RoleCode 2.16.840.1.113883.5.111
Description N/A
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Example codes shown below (Please consult authoritative source for full value set content).
Code Code System Description / Print Name
DX RoleCode Diagnostics or therapeutics unit
CVDX RoleCode Cardiovascular diagnostics or therapeutics unit
CATH RoleCode Cardiac catheterization lab
ECHO RoleCode Echocardiography lab
GIDX RoleCode Gastroenterology diagnostics or therapeutics lab
ENDOS RoleCode Endoscopy lab
RADDX RoleCode Radiology diagnostics or therapeutics unit
RADO RoleCode Radiation oncology unit
RNEU RoleCode Neuroradiology unit
HOSP RoleCode Hospital
... ... ...
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
471 DSTU (Revision 2013)
UCUM
Table 255: UCUM Definition
ValueSet OID & Binding
2.16.840.1.113883.6.8 DYNAMIC
Code System(s) UCUM 2.16.840.1.113883.6.8
Description
The Unified Code for Units of Measure (UCUM) is a code system intended to include all units of measures being contemporarily used in international science, engineering, and business. The purpose is to facilitate unambiguous electronic communication of quantities together with their units. The focus is on electronic communication, as opposed to communication between humans. A typical application of The Unified Code for Units of Measure are electronic data interchange (EDI) protocols, but there is nothing that prevents it from being used in other types of machine communication. (Source: http://unitsofmeasure.org/trac/) Note that since UCUM is, among other things, a grammar describing the set of strings that represent valid units, this value set is really a conceptual or intentional set.
Authority Regenstrief Institute
Reference URL http://unitsofmeasure.org/trac/
Intentional Definition
Appicable, valid unit strings expressed through the UCUM grammar.
VaccineAdministeredNameCode
Table 256: VaccineAdministeredNameCode Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.264 DYNAMIC
Code System(s) SNOMED-CT 2.16.840.1.113883.6.96
Description Represents the name of the vaccine that was administered to the Client.
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/primary-health-care-phc-reference-sets
Code Table Filter Example codes shown below (Please consult authoritative source for full value set content).
Code Code System Description / Print Name
940021261000087040 SNOMED-CT Acellular pertussis + diphtheria + haemophilus influenzae type b + tetanus vaccine (product)
783704961000087040 SNOMED-CT Acellular pertussis + diphtheria + inactivated poliomyelitis + recombinant hepatitis B virus + tetanus vaccine (product)
353614007 SNOMED-CT adsorbed diphtheria vaccine child injection suspension vial (product)
333521006 SNOMED-CT anthrax vaccine (product)
333532006 SNOMED-CT botulism antitoxin vaccine (product)
413830002 SNOMED-CT cholera oral vaccine suspension and effervescent granules (product)
35736007 SNOMED-CT cholera vaccine (product)
409580000 SNOMED-CT CVD 103-HgR live attenuated oral cholera vaccine (product)
421245007 SNOMED-CT diphtheria + pertussis + tetanus vaccine (product)
778319281000087105 SNOMED-CT diphtheria + tetanus + acellular pertussis +
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
472 DSTU (Revision 2013)
Code Code System Description / Print Name
inactivated poliomyelitis + haemophilus influenzae b vaccine (product)
... ... ...
x_ActRelationshipDocument
Table 257: x_ActRelationshipDocument Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.11610 STATIC
Code System(s) ActRelationshipType 2.16.840.1.113883.5.1002
Description
Used to enumerate the relationships between two clinical documents for document management.
Authority HL7 International
Reference URL http://www.hl7.org
x_ActStatusActiveComplete
Table 258: x_ActStatusActiveComplete Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.19890 STATIC
Code System(s) ActStatus 2.16.840.1.113883.5.14
Description N/A
Authority HL7 International
Reference URL http://www.hl7.org
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
active ActStatus active
completed ActStatus completed
x_BasicAddressPartType
Table 259: x_BasicAddressPartType Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.138 STATIC
Code System(s) AddressPartType 2.16.840.1.113883.5.16
Description Separates semantically relevant pieces of an address.
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Value set shown below may not be complete (Please consult the authoritative source).
Code Code System Description / Print Name
CNT AddressPartType country
CTY AddressPartType municipality
STA AddressPartType state or province
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
473 DSTU (Revision 2013)
Code Code System Description / Print Name
ZIP AddressPartType postal code
x_BasicConfidentialityKind
Table 260: x_BasicConfidentialityKind Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.139 STATIC
Code System(s) Confidentiality 2.16.840.1.113883.5.25
Description N/A
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Value set shown below may not be complete (Please consult the authoritative source).
Code Code System Description / Print Name
N Confidentiality normal
R Confidentiality restricted
V Confidentiality very restricted
T Confidentiality taboo
x_BasicPersonNamePartQualifier
Table 261: x_BasicPersonNamePartQualifier Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.140 STATIC
Code System(s) EntityNamePartQualifier 2.16.840.1.113883.5.43
Description Indicates any special characteristics of a name component.
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Value set shown below may not be complete (Please consult the authoritative source).
Code Code System Description / Print Name
IN EntityNamePartQualifier initial
x_BasicPersonNamePartType
Table 262: x_BasicPersonNamePartType Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.141 STATIC
Code System(s) EntityNamePartType 2.16.840.1.113883.5.44
Description Separates semantically relevant pieces of a name.
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Value set shown below may not be complete (Please consult the authoritative source).
Code Code System Description / Print Name
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
474 DSTU (Revision 2013)
Code Code System Description / Print Name
FAM EntityNamePartType family
GIV EntityNamePartType given
PFX EntityNamePartType prefix
SFX EntityNamePartType suffix
x_BasicPersonNameUse
Table 263: x_BasicPersonNameUse Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.142 STATIC
Code System(s) EntityNameUse 2.16.840.1.113883.5.45
Description Indicates how a name is intended to be used.
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Value set shown below may not be complete (Please consult the authoritative source).
Code Code System Description / Print Name
L EntityNameUse legal
P EntityNameUse pseudonym or alias
C EntityNameUse License or professional name
OR EntityNameUse Official registry
ASGN EntityNameUse assigned
x_BasicPostalAddressUse
Table 264: x_BasicPostalAddressUse Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.143 STATIC
Code System(s) AddressUse 2.16.840.1.113883.5.1119
Description Indicates how a postal address is intended to be used.
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Value set shown below may not be complete (Please consult the authoritative source).
Code Code System Description / Print Name
H AddressUse home address
PHYS AddressUse physical visit address
PST AddressUse postal address
TMP AddressUse temporary address
WP AddressUse workplace address
DIR AddressUse direct
CONF AddressUse confidential address
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
475 DSTU (Revision 2013)
x_BasicTelecommunicationsAddressUse
Table 265: x_BasicTelecommunicationsAddressUse Definition
ValueSet OID & Binding
2.16.840.1.113883.2.20.3.144 STATIC
Code System(s) AddressUse 2.16.840.1.113883.5.1119
Description Indicates how a phone number or e-mail address is intended to be used.
Authority Infoway Standards Collaborative
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Value set shown below may not be complete (Please consult the authoritative source).
Code Code System Description / Print Name
DIR AddressUse direct
EC AddressUse emergency contact
H AddressUse home address
MC AddressUse mobile contact
PG AddressUse pager
TMP AddressUse temporary
WP AddressUse workplace
CONF AddressUse confidential address
x_ComponentStartsBefore
Table 266: x_ComponentStartsBefore Definition
ValueSet OID & Binding
2.16.840.1.113883.3.3068.10.8.12 STATIC
Code System(s) ActRelationshipType 2.16.840.1.113883.5.1002
Description N/A
Authority Infoway Standards Collaborative (once submitted and accepted)
Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
COMP ActRelationshipType has component
SAS ActRelationshipType starts after start of
x_EncounterParticipant
Table 267: x_EncounterParticipant Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.19600 STATIC
Code System(s) ParticipationType 2.16.840.1.113883.5.90
Description Clones using this x_domain should have a name "encounterParticipant".
Authority HL7 International
Reference URL http://www.hl7.org
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
476 DSTU (Revision 2013)
Code Table Filter Value set shown below may not be complete (Please consult the authoritative source).
Code Code System Description / Print Name
ADM ParticipationType admitter
ATND ParticipationType attender
CON ParticipationType consultant
DIS ParticipationType discharger
REF ParticipationType referrer
x_PhoneOrEmailURLScheme
Table 268: x_PhoneOrEmailURLScheme Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.19741 STATIC
Code System(s) URLScheme 2.16.840.1.113883.5.143
Description Restricts scheme to e-mail or phone numbers at which a human can be reached
Authority HL7 International
Reference URL http://www.hl7.org
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
mailto URLScheme Mailto
tel URLScheme Telephone
x_ServiceEventPerformer
Table 269: x_ServiceEventPerformer Definition
ValueSet OID & Binding
2.16.840.1.113883.1.11.19601 STATIC
Code System(s) ParticipationType 2.16.840.1.113883.5.90
Description Clones using this x_domain should have a name "performer".
Authority HL7 International
Reference URL http://www.hl7.org
Code Table Filter Full value set shown below.
Code Code System Description / Print Name
PRF ParticipationType performer
SPRF ParticipationType secondary performer
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
477 DSTU (Revision 2013)
9.4 CODE SYSTEMS
The following table summarizes the Code Systems referenced by explicit fixed value assignments in this
specification:
Table 270: Code Systems
Code System Common Name OID Ref. URL
ActClass 2.16.840.1.113883.5.6 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
ActCode 2.16.840.1.113883.5.4 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
ActMood 2.16.840.1.113883.5.1001 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
ActPriority 2.16.840.1.113883.5.7 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
ActRelationshipType 2.16.840.1.113883.5.1002 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
ActStatus 2.16.840.1.113883.5.14 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
AddressPartType 2.16.840.1.113883.5.16 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
AddressUse 2.16.840.1.113883.5.1119 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
AdministrativeGender 2.16.840.1.113883.5.1 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
bodySite 2.16.840.1.113883.12.163 http://www.hl7.org/Memonly/downloads/Standards_Messaging_v26/HL7_Messaging_v26_WORD.zip
Confidentiality 2.16.840.1.113883.5.25 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
ContextControl 2.16.840.1.113883.5.1057 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
EntityClass 2.16.840.1.113883.5.41 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
EntityDeterminer 2.16.840.1.113883.5.30 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
EntityNamePartQualifier 2.16.840.1.113883.5.43 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
EntityNamePartType 2.16.840.1.113883.5.44 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
EntityNameUse 2.16.840.1.113883.5.45 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
hl7Realm 2.16.840.1.113883.5.1124 N/A
icd9cm 2.16.840.1.113883.6.2 N/A
ietf3066 2.16.840.1.113883.6.121 N/A
iso3166-1 1.0.3166.1 http://www.iso.org/iso/country_codes/iso_3166_code_lists.htm
iso3166-2 1.0.3166.2 http://www.iso.org/iso/country_codes/iso_3166_code_lists.htm
iso639-3 1.0.639.3 http://www.w3.org/WAI/ER/IG/ert/iso639.htm
LOINC 2.16.840.1.113883.6.1 http://loinc.org
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
478 DSTU (Revision 2013)
Code System Common Name OID Ref. URL
mediaType 2.16.840.1.113883.5.79 http://www.iana.org/assignments/media-types
ObservationInterpretation 2.16.840.1.113883.5.83 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
ObservationMethod 2.16.840.1.113883.5.84 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
ObservationType-CA-Pending 2.16.840.1.113883.3.3068.10.6.3 #http://www.gpinformatics.com
ObservationValue 2.16.840.1.113883.5.1063 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
OrderableDrugForm 2.16.840.1.113883.5.85 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
ParticipationFunction 2.16.840.1.113883.5.88 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
ParticipationSignature 2.16.840.1.113883.5.89 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
ParticipationType 2.16.840.1.113883.5.90 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
RoleClass 2.16.840.1.113883.5.110 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
RoleCode 2.16.840.1.113883.5.111 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
RouteOfAdministration 2.16.840.1.113883.5.112 http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm
SCPTYPE 2.16.840.1.113883.2.20.5.3 http://forums.infoway-inforoute.ca/PCS
SCTEMP 2.16.840.1.113883.2.20.5.2 http://forums.infoway-inforoute.ca/PCS
SectionType-CA-Pending 2.16.840.1.113883.3.3068.10.6.2 #http://www.gpinformatics.com
SNOMED-CT 2.16.840.1.113883.6.96 http://www.ihtsdo.org/snomed-ct/
UCUM 2.16.840.1.113883.6.8 http://www.regenstrief.org/medinformatics/ucum
URLScheme 2.16.840.1.113883.5.143 http://www.iana.org/protocols
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
479 DSTU (Revision 2013)
10.0 IDENTIFIERS
10.1 BACKGROUND
A key challenge in distributed information processing is the globally unique identification of records or
objects. HL7 version 3 (and hence CDA) addresses this through the use of Universal Object Identifiers
(OIDs). These OIDs are used in three areas:
As the root for all identifiers (using the II datatype);
As the means of identifying code systems when using one of the code datatypes; and
As the means of identifying value sets for use in constraint statements.
OIDs are a hierarchical identification scheme designed to ensure that identifiers are globally unique.
“Structurally, an OID consists of a node in a hierarchically-assigned namespace, formally defined using
the ITU-T's ASN.1 standard.”9 Each
OID consists of a series of integers
separated by decimal points. These
can be interpreted from left to right to
progressively identify an ‘assigning
authority’ and a hierarchy of objects.
If the rules defined by the
International Standards Organization
(ISO) are appropriately followed,
there is no chance that the same
OID will be issued to more than one
object. Conversely, if an OID is
known, then it the object to which the
OID corresponds is also known,
although this may require a lookup of
the OID in a repository.
Any person or organization can be
issued an OID by an OID registrar. Once issued, that OID is permanently and irrevocably assigned to
identify that person or organization. The person or organization can then issue additional OIDs below
their particular node by appending further levels. For example, as per the diagram in Figure 141, the
Internet has the OID “1.3.6.1”. It in turn is the assigning authority for the node “mgmt” which has the OID
“1.3.6.1.2”. Similarly HL7’s OID is 2.16.840.1.113883. Using HL7’s OID registry,
9 WikiPedia Object Identifier entry, accessed May 1, 2012.
Figure 141: ISO OID Hierarchy
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
480 DSTU (Revision 2013)
http://www.hl7.org/oid/index.cfm, the following OID has been established for the BC Physician Information
Technology Office: 2.16.840.1.113883.3.1818. This OID will be the assigning authority root for OIDs
established within these specifications.
10.2 USE OF OIDS
10.2.1 Vocabulary
10.2.1.1 Code Systems
OIDs for all code systems are assigned or registered when HL7 registers a particular code system. Once
registered, the assigned or registered OID is the only OID allowed to be used for that code system.
Implementers SHALL only use code systems, including local code systems, which have been registered
with HL7 and been assigned an OID or which have a PITO designated OID.
10.2.1.2 Value Sets
Value set OIDs are defined primarily to allow implementation guides such as this to provide definitive and
formal guidance as to the set of allowable values for a particular data element.
Positive identification of value sets and linkage of these sets to specific data elements is also intended to
position for automated validation and conformance testing. Since value set OIDs are NOT included in
message or document instances, the only way in which to use these identifiers is for validation tools and
algorithms to interrogate a message instance to identify the applicable specification; in the case of CDA
document instances, this is accomplished through the template identifiers contained within document
instances. Using this identifier it is possible to interrogate the applicable specification to ascertain the
appropriate value set. Based on this value set identifier, the specification and an appropriate terminology
services infrastructure, it is then possible to validate coding.
In many circumstances CDA projects identify requirements to establish value sets that are likely to have
broader applicability at a regional, provincial, national or even international level. When these value sets
are identified and it is not possible or expedient to establish an OID through an appropriate standards
body then a place holder will be assigned using the GPi CDA OID root for value sets, namely
2.16.840.1.113883.3.3068.10.8.*. Implementers should note that these value set identifiers may change
over time and that such changes must be managed carefully across an implementation infrastructure to
ensure consistent use across specifications, validation tools and terminology services. Appropriate
infrastructure change management procedures should be applied to mitigate any issues in this regard.
10.2.2 Instance Identifiers
In HL7 v3, all instance identifiers are required to be globally unique. Globally unique means that the
identifier points to only one thing no matter which system uses the identifier. Any system which
constructs identifiers which are not globally unique cannot claim HL7 v3 (nor HL7 CDA) conformance.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
481 DSTU (Revision 2013)
The II Datatype consists of two principle components: A mandatory OID root and an optional extension.
The combination of the root and the extension form the universally unique identifier. In other words, the
combination of the root and the extension must refer to only one thing worldwide.
The reason for the extension component of II is that many “real-world” identifiers do not reflect the
conventions of the OID (string of digits separated by periods) format. Real world identifiers such as
health numbers, provider ids, lab order ids and others tend to contain alphabetic characters, punctuation
or other structures that cannot be conveyed as an OID. In this case, the “root” element will contain an
OID which defines the “namespace” for the “real-world” identifier being conveyed in the extension. A
unique OID applies to each unique namespace. If the namespace changes (e.g. changing from an 8-digit
sequence to a 9-digit sequence), a new OID would apply. For example, the root might represent the
concept “Canadian Social Insurance Number beginning January, 1932”.
Note that the root refers to the “unique number-space” of the identifier, not to the assigning organization.
For example, although the Alberta College of Nursing may be responsible for licensing both Licensed
Practical Nurses (LPNs) and Registered Nurses (RNs), this would demand creation of two separate OIDs
(one for each type of nurse identifier) or one OID (for all nurses) depending on whether the license
numbers issued were drawn from two separate pools or one pool.
The “unique number-space” does not necessarily correspond to a single application. Multiple applications
might draw on a common database which tracks issued identifiers and thus use a single OID. On the
other hand, a single application might issue multiple identifiers. Some order entry systems will use the
same number-space for all orders, whether lab, pharmacy or imaging and would thus use the same OID
for all. Others would use a separate OID, and might even use different number-spaces and OIDs for
orders issued from each ward.
The hierarchy in which an OID is situated conveys no semantics about the meaning of an identifier.
Identifiers registered under the Canadian OID node can refer to items that exist in other countries and
vice versa. Registering an OID for an item does not imply control over that item, merely knowledge of the
item’s unique existence. If the organization responsible for issuing an identifier splits or merges or is
renamed, the OID remains the same so long as the number pool from which the extensions are issued
remains the same. For example, if the Alberta College of Nursing were to spin off a separate
organization for LPNs, the same OID would continue to be used for LPN identifiers unless the new
organization started issuing different identifiers.
Nothing prevents numerous OIDs from being issued for the same identifier. To minimize the mapping
issues resulting from two organizations using different OIDs for the same type of identifier, HL7 allows
organizations to ‘register’ OIDs of common identifiers with HL7. Common identifiers are those identifiers
where it is reasonable to expect an identifier to be captured by multiple systems without those systems
having an explicit business relationship with the issuer of the identifier. For example, many systems will
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
482 DSTU (Revision 2013)
need to capture the concept of a “BC Personal Health Number (PHN)” or an “Alberta Unique Lifetime
Identifier (ULI)” without necessarily having a direct relationship with either the Alberta Department of
Health or the BC Ministry of health. These types of identifiers have therefore been registered. HL7 will
only allow one OID to be registered for a given concept. The OID that is first registered for a particular
concept is the OID that SHALL be used when communicating that concept in HL7 version 3 message or
document instances. Systems which use other OIDs cannot claim conformance with either HL7 v3 nor
with this specification.
When the OID for an identifier is registered, the format for capturing the identifier is also specified. For
example, whether the extension should be in upper case or lower case, whether there should be any
punctuation or spacing, and whether there should be leading digits. The general rule is upper case with
only that punctuation and spacing needed to prevent duplication. (e.g. if 123-456 and 12-3456 constitute
different identifiers, then the dash needs to be sent as part of the identifier.)
While the mechanism described ensures that v3 applications will reference the same identifier object in a
consistent manner it is important to note that absolute identifier uniqueness will always depend on the
integrity of the assignment process for the underlying real world identifiers (i.e. the extension portion).
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
483 DSTU (Revision 2013)
10.3 ASSIGNED IDENTIFIERS
The following convention has been established for OIDs that are assigned explicitly as part of the
development of these specifications:
Table 271: OID Tree
OID Branch Usage Sample Leaf
{RootOID}.10.* This is the root for identifiers pertaining to these consolidated CDA specifications.
2.16.840.1.113883.3.1818.10 = PITO “E2E-DTC” Consolidated CDA Specifications
{RootOID}.10.1.* Document level template identifiers.
2.16.840.1.113883.3.1818.10.1.1 = EMR Conversion Document Template
{RootOID}.10.2.* Section level template identifiers. 2.16.840.1.113883.3.1818.10.2.9 = Current Medications [without entries]
{RootOID}.10.3.* Section Entry level template identifiers.
2.16.840.1.113883.3.1818.10.3.6 = Care History Event
{RootOID}.10.4.* Entry level template identifiers. 2.16.840.1.113883.3.1818.10.4.21 = Provider Participation
{RootOID}.10.6.* Code System identifiers.
{RootOID}.10.7.* Header template identifiers.
{RootOID}.10.8.* Value Set identifiers.
{RootOID}.10.9.* Instance identifiers.
Note that Value Sets that represent all codes in a given Code System may be identified using the
associated Code System OID in this implementation guide.
10.4 IMPLEMENTER ASSIGNED IDENTIFIERS
A number of identifiers referenced by the specification pertain to fields where the sending system reflects
the source of truth. For example, various record identifiers or local client/patient identifiers are assumed
to be generated within each sending system. In order to make these globally unique each implementer
will require an OID at implementation time and said OID will need to be used when communicating these
types of identifiers.
10.5 GOVERNANCE
Guidance for OID establishment will rest with the BC Physician Information Technology Office (PITO) until
such time as a provincial process is established.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
484 DSTU (Revision 2013)
10.6 INSTANCE IDENTIFIER OIDS
The following table summarizes a non-exhaustive subset of well-known identifier OIDs relevant to this
implementation guide. Since these OIDs are formally established through the HL7 OID registry, in case
of discrepancy between this list and the registry, the latter SHALL prevail.
Table 272: Common Identifier OIDs
OID Symbolic Name Description
2.16.840.1.113883.4.600 ca-abDLN Alberta, Canada (Ministry of Transportation of Alberta, Canada) Driver's Licence
2.16.840.1.113883.4.20 abcauli Alberta, Canada Unique Lifetime Identifier (ULI)
2.16.840.1.113883.4.50 ca-bcPHN British Columbia Personal Health Number
2.16.840.1.113883.4.597 ca-bcDLN British Columbia, Canada ICBC (Insurance Corporation of British Columbia, Canada) Driver's Licence
2.16.840.1.113883.4.377 cschn Correctional Service Canada Health Number
2.16.840.1.113883.4.378 inachn Indian & Northern Affairs Canada Health Number
2.16.840.1.113883.4.12 mhphin Manitoba Health Personal Health Identification Number - MHPHIN
2.16.840.1.113883.4.599 ca-mbDLN Manitoba, Canada Driver's Licence
2.16.840.1.113883.4.601 ca-nbDLN New Brunswick, Canada Driver's Licence
2.16.840.1.113883.4.51 ca-nbPHN New Brunswick, Canada Personal Health Number
2.16.840.1.113883.4.596 ca-nlDLN Newfoundland and Labrador, Canada Driver's Licence
2.16.840.1.113883.4.52 ca-nlPHN Newfoundland and Labrador, Canada Personal Health Number
2.16.840.1.113883.4.602 ca-ntDLN Northwest Territories, Canada (Ministry of Transportation Northwest Territories, Canada) Driver's Licence
2.16.840.1.113883.4.54 nwtCPHN Northwest Territories, Canada Personal Health Number
2.16.840.1.113883.4.606 ca-nsDLN Nova Scotia, Canada (Registry of Motor Vehicles Nova Scotia, Canada) Driver's Licence
2.16.840.1.113883.4.53 nsCPHN Nova Scotia, Canada Personal Health Number
2.16.840.1.113883.4.603 ca-nuDLN Nunavut, Canada Driver's Licence
2.16.840.1.113883.4.55 ca-nuPHN Nunavut, Canada Personal Health Number
2.16.840.1.113883.4.595 ca-onDLN Ontario, Canada MTO (Ministry of Transportation of Ontario, Canada) Driver's License
2.16.840.1.113883.4.604 ca-peDLN Prince Edward Island, Canada Driver's Licence
2.16.840.1.113883.4.13 peiphni Prince Edward Island, Canada Personal Health Number Identifier (PEIPHNI)
2.16.840.1.113883.4.11 mbcpn Provider Registry Common Party Number - Manitoba, Canada (MBCPN)
2.16.840.1.113883.4.594 ca-qcDLN Quebec, Canada (Société de l'assurance automobile du Quebec, Canada) Driver's Licence
2.16.840.1.113883.4.379 rcmphn Royal Canadian Mounted Police Health Number
2.16.840.1.113883.4.598 ca-skDLN Saskatchewan, Canada Driver's Licence
2.16.840.1.113883.4.376 vachn Veteran's Affairs Canada Health Number
2.16.840.1.113883.4.605 ca-ytDLN Yukon, Canada Driver's Licence
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
485 DSTU (Revision 2013)
Appendix A Known Issues & Instabilities
Implementer Caution
These specifications were devised as part of a project with a defined scope and a constrained delivery time frame. As such the specifications cannot address all stakeholder requirements that may arise in system-to-system data interchanges. Moreover, the final specification represents the sum total of a series of design and approach choices that reflect the consensus reached by those stakeholders involved in the specifications / standards development process. Given these constraints implementers may want to anticipate and design for potential future changes to these specifications. In order to assist in this process, the project team has identified a series of potential stability risks and included these in this appendix.
The following table outlines potential risks to the stability of these specifications:
Table 273: E2E Specification Stability Risks
Observation Stability Consequence / Potential Risk
The capability for the communication of Appointment and Schedule data in these specifications draw on ToPD/CoPD as per project scope. However, several stakeholders have indicated that the ensuing design may not be feasible for their solutions.
Risk of change to the Appointment and Scheduling section and any associated entries. This will likely not be resolved until after pilot testing of these specifications has been completed.
Vocabulary assignments (e.g. instantiating all value setswith the most appropriate set of codes) remain to be fully completed and validated through pilot testing.
Pilot implementers would, ideally, work with the maintenance team to complete various value set enumerations – as well as, of course, assisting in validating the remainder of this guide.
This release of the specification is intended for pilot testing. Specifically the following changes are anticipated after pilot testing is completed:
Corrections to the per-constraint conformance;
Corrections to and/or refinements of data element business names and business descriptions;
Potential refactoring of templates;
While the specification remains in this pilot state, there may be substantial changes.
Currently most, if not all, templates in this guide have
been marked as Open rather than Closed. This
setting remains to be reviewed for all templates and may not be finalized until after this specification has been implemented in a pilot project. Having said this, the overarching goal for this specification – particularly in the Conversion and Patient Transfer use cases – is to ensure that clinical data can be processed electronically by receivers in the most granular fashion, including, for example, the ability to load data into the receiving system’s record. Therefore the specification aims to err on the side of minimum ambiguity. This suggests that templates may tend to
shift to the Closed setting where feasible.
This will likely not be resolved until after pilot testing of these specifications has been completed.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
486 DSTU (Revision 2013)
Observation Stability Consequence / Potential Risk
The currently proposed Laboratory Results & Reports data section design (i.e. the Laboratory Observation Entry section templates and laboratory focused entry templates) connects results through an order structure which is well aligned with laboratory systems but not necessarily EMR systems. It is anticipated that pilot implementations will confirm the viability of this approach.
Change to this section should be anticipated after pilot implementations are completed.
It is anticipated that the conversion use case will require not only the production of the various document instances representing the individual patient charts (as well as any associated attachments – whether embedded or referenced) but also the production of a clear export and import summary as applicable. These summaries are anticipated to indicate, among other things, the number of charts exported or imported, the number of attachments exported, as well as any error information. The formats for these files remain to be defined.
Until such time as these files are defined, implementers SHALL output this information in text file format.
The first conformance statement in each document section does NOT include a unique conformance identifier. This is due to a technical issue.
This may be resolved in an upcoming release.
Support for communication of allergies and intolerances to drug excipients is limited due to limitations in the associated terminologies and drug information systems. This may be resolved in the future and may drive changes to the associated sections and templates.
Risk of future change.
Subject to further review on the risks, issues , benefits and stability of HL7’s greenCDA initiative, future versions of this specification may include and declare support for greenCDA schemas and the exchange of instances that conform to such schemas.
Risk of future change.
Additional, automated validation to augment basic W3C Schema validation through tools such as Schematron (www.schematron.com), RelaxNG (www.relaxng.org ), or similar mechanisms may be added in future.
N/A
For a listing of open specificatoion issues please consult the applicable, published issue logs.
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
487 DSTU (Revision 2013)
Appendix B Glossary & Abbreviations
B.1. Introduction
There are a number of excellent glossaries available online which are preferred to the use of a custom
glossary. These include the following:
Table 274: Internet Based Glossaries
Glossary URL
HL7 Glossary of Terms http://www.hl7.org/documentcenter/public_temp_2D807AAD-1C23-BA17-0C68015850694475/calendarofevents/FirstTime/Glossary%20of%20terms.pdf
Infoway Blueprint Glossary (Dated)
https://knowledge.infoway-inforoute.ca/ehr_blueprint/glossary/en/a.html
E-Health & Telehealth Glossary
http://telehealth.net/glossary
Joint Initiative for Global Standards Harmonization Health Informatics Document Registry and Glossary (Standards Knowledge Management Tool)
http://www.skmtglossary.org/Default.aspx?AspxAutoDetectCookieSupport=1 (Requires registration)
In addition, various jurisdictional eHealth agencies and catalyst organizations also maintain glossaries.
B.2. Specific Terms & Abbreviations
Notwithstanding the preference for external glossary entries, the following abbreviation table has been
included here for convenience:
Table 275: Terms & Abbreviations
Abbreviation Expansion
CDA Clinical Document Architecture
DICOM Digital Imaging and Communications in Medicine
DIR Diagnostic Imaging Report
EHR Electronic Health Record
EMR Electronic Medical Record
DSTU Draft Standard for Trial Use
HIMSS Healthcare Information and Management Systems Society
HIT healthcare information technology
HTML Hypertext Markup Language
EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard Part II - Consolidated CDA Implementation Guide
488 DSTU (Revision 2013)
Abbreviation Expansion
IG Implementation Guide
IHE Integrating the Healthcare Enterprise
IHTSDO International Health Terminology Standard Development Organisation
LOINC® Logical Observation Identifiers Names and Codes
MDHT Model-Driven Health Tools
MIME Multipurpose Internet Mail Extensions
OID Object Identifier
PDF Portable Document Format
PHR Personal Health Record
PITO (BC) Physician Information Technology Office
RIM Reference Information Model
RTF Rich Text Format
S&I Standards and Interoperability
SDO Standards Development Organization
SNOMED CT® Systemized Nomenclature for Medicine – Clinical Terms
SOP Service Object Pair
SR Structured Report
Tdb Template Database
TIFF tagged-image file format
UCUM Unified Code for Units of Measure
UD Unstructured Document
UDI Unique Device Identification
UML Unified Modeling Language
URL / URI Uniform Resource Locator / Uniform Resource Identifier
WADO Web Access to Persistent DICOM Objects
XPath XML Path Language