EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard · 2016-08-18 · EMR–to–EMR...

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.

http://www.hl7.org/

http://www.pito.bc.ca/


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

mailto:[email protected]








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.

http://www.healthstory.com/standards/sec/consolidate.htm


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


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


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


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


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


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


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


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


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


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


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


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


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

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7



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



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.

http://www.hl7.org/

https://www.infoway-inforoute.ca/standards



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.



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.



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

http://wiki.hl7.org/index.php?title=GreenCDA_Project#What_is_greenCDA.3F



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.

http://www.hl7.org/v3ballot/html/help/pfg/pfg.htm

http://www.healthstory.com/standards/sec/consolidate.htm



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.

http://www.hl7.org/implement/standards/product_brief.cfm?product_id=7



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

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



<templateId root="2.16.840.1.113883.10.20.22.1.1" assigningAuthorityName=”bcPITO”/>

...

</ClinicalDocument>

Figure 4: templateId element example XML



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.

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



...

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



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



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.



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.



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



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:


Conformance statements provide specific direction regarding the presence of XML elements and the number of repeats (cardinality)



Syntax for vocabulary binding to a single code:


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.

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'>

...



</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



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



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

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.







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



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



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.

http://standards.pito.bc.ca/E2E-DTC/cda

http://standards.pito.bc.ca/E2E-DTC/cda



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,



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



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


<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


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




the document.

23 Recipient's Address addr O:0..* AD

24 Recipient's Telecommunication Information

telecom O:0..* TEL

25 informationRecipient R:0..1


27 @determinerCode M:1..1

28 Recipient's Name name M:1..1 PN

29 Recipient's Organization receivedOrganization R:0..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


(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].



(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:




(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>


Figure 17: Information Recipient entry example

3.1.3 Author [author]

Table 8: Author [author] Constraints Overview


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




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


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



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



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



iv) SHALL contain exactly one [1..1] assignedAuthor [CONF:37].


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,



(4) SHALL contain zero or more if available [0..*] telecom [CONF:42] such that each,



(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:




(d) SHALL contain exactly one (or a nullFlavor value) [1..1] name [CONF:46] such that

it,



[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:




(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].

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>



<state>BC</state>



</addr>


<telecom value="fax: (555) 555-1133" use="WP"/>

<assignedPerson classCode="PSN" determinerCode="INSTANCE">

<name>


<given>Harold</given>

<given>H.</given>

<family>Hippocrates</family>

<suffix>the 1st</suffix>

</name>

</assignedPerson>

<representedOrganization classCode="ORG" determinerCode="INSTANCE">


<name>Healthcare Drive Clinical Centre</name>

</representedOrganization>

</assignedAuthor>

</author>



Figure 18: Author entry example

3.1.4 Custodian Organization [custodian]

Table 9: Custodian Organization [custodian] Constraints Overview


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




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


56

representedCustodianOrgan

ization

R: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].


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:


(b) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance


(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"/>


</representedCustodianOrganization>

</assignedCustodian>

</custodian>

Figure 19: Custodian Organization entry example



3.1.5 Patient [recordTarget]

Table 10: Patient [recordTarget] Constraints Overview


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


64 patientRole 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:




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



(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,






(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].



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>


<state>BC</state>



</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


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




78 Function Type The role that the contact plays in relationship with the patient for example Caregiver.

functionCode R:0..1 CE


80 associatedEntity 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


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,



(4) SHALL contain zero or one if available [0..1] telecom [CONF:84] such that it,



(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,



[CONF:86.5].



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>



<state>BC</state>



</addr>



<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


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




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


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


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


iii) SHALL contain exactly one [1..1] @contextControlCode="OP" overriding propagating


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,






(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,





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



<state>BC</state>



</addr>



<associatedPerson classCode="PSN" determinerCode="INSTANCE">

<name>



<given>P.</given>



</name>

</associatedPerson>

<scopingOrganization>


</scopingOrganization>

</associatedEntity>

</participant>

Figure 22: Healthcare Participant entry example

3.1.8 Legal Authenticator Participant [legalAuthenticator]

Table 13: Legal Authenticator Participant [legalAuthenticator] Constraints Overview


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




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


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


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



114 Person Name name M:1..1 PN

115 Represented Organization

representedOrganization

R:0..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:




iii) SHALL contain exactly one (or a nullFlavor value) [1..1] time [CONF:103].



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


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




[CONF:107.14].


HealthcareProviderRoleType 2.16.840.1.113883.2.20.3.48 DYNAMIC {CDAR2} [CONF:108].







(6) SHALL contain zero or one if available [0..1] assignedPerson [CONF:111].

(a) SHALL contain exactly one [1..1] @classCode="PSN" person (CodeSystem:




(c) SHALL contain exactly one [1..1] name [CONF:114] such that it,



[CONF:114.5].

(7) SHALL contain zero or one if available [0..1] representedOrganization [CONF:115].







(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


[CONF:121.5].



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



<state>BC</state>



</addr>



<assignedPerson>

<name>


<given>Good</given>

<family>Doctor</family>

</name>

</assignedPerson>

<representedOrganization>

<name>Good Health Clinic</name>


</assignedEntity>

</legalAuthenticator>

Figure 23: Legal Authenticator Participant entry example

3.1.9 Authenticator Participant [authenticator]

Table 14: Authenticator Participant [authenticator] Constraints Overview


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





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



128 Authenticator Identifier id M:1..1 II

129 code O:0..1 CE

130 Address Address of the authenticator.

addr O:0..* AD





135 Authenticator Person Name name M:1..1 PN



R:0..1



139 Organization Identifier id M:1..1 II




v) MAY contain zero or more [0..*] authenticator [CONF:122].

i) SHALL contain exactly one [1..1] @typeCode="AUTHEN" authenticator (CodeSystem:


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


RoleClass 2.16.840.1.113883.5.110) [CONF:127].







[CONF:128.14].



















[CONF:135.5].











[CONF:141.5].




[CONF:142.5].



The following XML example outlines how to use the Authenticator Participant object:

<authenticator>

<time value="200910201235"/>

<signatureCode nullFlavor="NI"/>

<assignedEntity>


<code code="TBD" codeSystem="2.16.840.1.113883.12.443" codeSystemName="HL7

Provider Role" displayName="Resident" />

<addr use="WP">



<state>BC</state>



</addr>



<assignedPerson>

<name>


<given>Allright</given>

<family>Resident</family>

</name>

</assignedPerson>




</assignedEntity>

</authenticator>

Figure 24: Authenticator Participant entry example

3.1.10 Data Enterer Participant [dataEnterer]

Table 15: Data Enterer Participant [dataEnterer] Constraints Overview


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



146 Data Enterer Time The date/time that the data was entered.

time R:0..1 TS






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








R:0..1







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



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


RoleClass 2.16.840.1.113883.5.110) [CONF:148].







[CONF:149.14].



















[CONF:156.5].











[CONF:162.5].




[CONF:163.5].



The following XML example outlines how to use the Data Enterer Participant object:

<dataEnterer typeCode="ENT" contextControlCode="OP">

<time value="200910201235" />

<assignedEntity>


<code code="TBD" codeSystem="2.16.840.1.113883.5.111" codeSystemName="RoleCode"

displayName="Transcriptionist" />

<addr use="WP">



<state>BC</state>



</addr>


<assignedPerson>

<name>


<given>Typ</given>

<family>Fast</family>

</name>

</assignedPerson>




</assignedEntity>

</dataEnterer>

Figure 25: Data Enterer Participant entry example

3.1.11 Informant Participant [informant]

Table 16: Informant Participant [informant] Constraints Overview


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








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








R:0..1







184 Informant Relationship relatedEntity R:0..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:




iii) SHALL contain zero or one if available [0..1] assignedEntity [CONF:167].


RoleClass 2.16.840.1.113883.5.110) [CONF:168].









[CONF:169.14].


AssignedEntityRoleCode 2.16.840.1.113883.3.3068.10.8.25 STATIC {CDAR2} [CONF:170].















[CONF:176.5].











[CONF:182.5].




[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].









(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,



[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"/>



<addr use="WP">



<state>BC</state>



</addr>


<assignedPerson>

<name>


<given>Gimme</given>

<family>Infoplease</family>

</name>

</assignedPerson>


<name>Tellall Health Clinic</name>


</assignedEntity>

</informant>

Figure 26: Informant Participant entry example

3.1.12 Parent Document [relatedDocument]

Table 17: Parent Document [relatedDocument] Constraints Overview


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




194 parentDocument 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].


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



3.1.13 Encompassing Encounter [componentOf]

Table 18: Encompassing Encounter [componentOf] Constraints Overview


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


204 encompassingEncounter R:0..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..*


213 assignedEntity 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




222 Provider Name Name of the provider.

name M:1..1 PN

1719 Responsible Party responsibleParty R:0..*







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




1730 Provider Name Name of the provider.

name M:1..1 PN



R:0..1



226 Organization Identifier Identifier of the organization represented by the provider participating in the encounter.

id M:1..1 II




230 Encounter Location location O:0..1


232 Healthcare Facility Healthcare facility where the encounter occurred.

healthCareFacility O:0..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



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



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


(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


[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:


2. SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance


3. SHALL contain exactly one [1..1] name [CONF:222] 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: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




[CONF:1723.13].





[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,



[CONF:1725.5].

(v) MAY contain zero or more [0..*] {CDAR2} telecom [CONF:1726] such that each,


(2.16.840.1.113883.3.3068.10.5.2) [CONF:1726.5].


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



(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




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,



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:


(b) MAY contain zero or one [0..1] healthCareFacility [CONF:232].

(i) SHALL contain exactly one [1..1] @classCode="SDLOC" service delivery location


(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:





4. MAY contain zero or one [0..1] addr [CONF:240] such that it,


(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


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


243 Order order O:0..*






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:


ii) MAY contain zero or more [0..*] order [CONF:243].


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


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


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


251 serviceEvent O:0..*



254 Service Event Identifier id O:0..* II

255 Code code O:0..1 CE




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


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


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




270 Provider’s Name name M:1..1 PN



R:0..1







bb) MAY contain zero or more [0..*] documentationOf [CONF:249].



i) SHALL contain exactly one [1..1] @typeCode="DOC" documentation (CodeSystem:


ii) MAY contain zero or more [0..*] serviceEvent [CONF:251].


CDAHeaderActClass 2.16.840.1.113883.3.3068.10.8.8 STATIC {CDAR2} [CONF:252].


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,



(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


(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




[CONF:263.13].





[CONF:263.14].

(iii) MAY contain zero or one [0..1] code, which SHOULD be selected from ValueSet


(iv) MAY contain zero or more [0..*] addr [CONF:265] such that each,



[CONF:265.5].

(v) MAY contain zero or more [0..*] telecom [CONF:266] such that each,


(2.16.840.1.113883.3.3068.10.5.2) [CONF:266.5].


1. SHALL contain exactly one [1..1] @classCode="PSN" person (CodeSystem:








(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




3. SHALL contain exactly one [1..1] id [CONF:274].


5. MAY contain zero or more [0..*] addr [CONF:276] such that each,


(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


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


280 consent R:0..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




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:


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.16.840.1.113883.5.1001) [CONF:282].


(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].

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



<realmCode code="CA" />


<id extension="12345" root="2.16.840.1.113883.3.933"/>


displayName="Referral"/>

<title>PITO EMR-2-EMR Complete Instance Example</title>





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



<state>BC</state>



</addr>



<patient>

<name>


<given>Eve</given>

<given>E.</given>


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




<time value="20030529"/>





<addr>



<state>BC</state>



</addr>




<name>



<given>H.</given>



</name>

</assignedPerson>





</assignedAuthor>

</author>





<dataEnterer typeCode="ENT" contextControlCode="OP">

<time value="200910201235" />

<assignedEntity>


<code code="TBD" codeSystem="2.16.840.1.113883.5.111" codeSystemName="RoleCode"

displayName="Transcriptionist" />

<addr use="WP">



<state>BC</state>

</addr>


<assignedPerson>

<name>


<given>Typ</given>

<family>Fast</family>

</name>

</assignedPerson>




</assignedEntity>

</dataEnterer>





<id root="B8E71AC2-0CD0-11E0-8746-CE50DFD72085"/>



<addr use="WP">



<state>BC</state>



</addr>


<assignedPerson>

<name>


<given>Gimme</given>

<family>Infoplease</family>

</name>

</assignedPerson>


<name>Tellall Health Clinic</name>


</assignedEntity>

</informant>



<custodian typeCode="CST">

<assignedCustodian classCode="ASSIGNED">

<representedCustodianOrganization classCode="ORG" determinerCode="INSTANCE">

<id extension="123" root="7EEF0BCC-F03E-4742-A736-8BAC57180C5F"/>


</representedCustodianOrganization>

</assignedCustodian>

</custodian>

<!--

********************************************************

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>



<state>BC</state>



</addr>


<informationRecipient classCode="PSN" determinerCode="INSTANCE">

<name>



<given>P.</given>



</name>


<receivedOrganization classCode="ORG" determinerCode="INSTANCE">


</receivedOrganization>

</intendedRecipient>




<legalAuthenticator>

<time value="200910201235" />

<signatureCode code="S" />

<assignedEntity>




<addr use="WP">



<state>BC</state>



</addr>



<assignedPerson>

<name>


<given>Good</given>

<family>Doctor</family>

</name>

</assignedPerson>

</assignedEntity>

</legalAuthenticator>



<authenticator>

<time value="200910201235"/>

<signatureCode nullFlavor="NI"/>

<assignedEntity>


<code code="TBD" codeSystem="2.16.840.1.113883.12.443" codeSystemName="HL7

Provider Role" displayName="Resident" />

<addr use="WP">



<state>BC</state>



</addr>



<assignedPerson>

<name>


<given>Allright</given>

<family>Resident</family>

</name>

</assignedPerson>




</assignedEntity>

</authenticator>



<participant typeCode="NOT" contextControlCode="OP">

<associatedEntity classCode="CON">

<code code="HUSB" codeSystem="F05716F7-BA77-4641-A8D8-6E3948CCD321"

codeSystemName="HL7: PersonalRelationshipRoleType" displayName="Husband"/>

<addr>



<state>BC</state>



</addr>



<associatedPerson>

<name>


<given>Neville</given>

<given>N.</given>

<family>Nuclear</family>

<suffix>III</suffix>

</name>

</associatedPerson>

</associatedEntity>

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



<state>BC</state>



</addr>



<associatedPerson classCode="PSN" determinerCode="INSTANCE">

<name>



<given>P.</given>



</name>

</associatedPerson>

<scopingOrganization>


</scopingOrganization>

</associatedEntity>

</participant>”

Figure 27: BC PITO Standard Header entry example



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


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

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/>


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





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





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



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




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


Status Changes Audit Event Entry 2.16.840.1.113883.3.1818.10.4.31


Reason Observation Entry 2.16.840.1.113883.3.1818.10.4.24



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




Provider Participation Entry 2.16.840.1.113883.3.1818.10.4.21





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



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







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


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


Dispense Request (refill) Entry 2.16.840.1.113883.3.1818.10.4.34


Dose Observation Entry 2.16.840.1.113883.3.1818.10.4.8


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




Location Participation Entry 2.16.840.1.113883.3.1818.10.4.13


Performer Participation Entry 2.16.840.1.113883.3.1818.10.4.19


Order Indicator Entry 2.16.840.1.113883.3.1818.10.4.37
















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






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



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


















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




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



















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



Outcome Observation Entry 2.16.840.1.113883.3.1818.10.4.18








Qualifier Observation Entry 2.16.840.1.113883.3.1818.10.4.22






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




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













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








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












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






















Entry 2.16.840.1.113883.3.1818.10.4.36

























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































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









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



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



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






















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



















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









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:


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


v) SHALL contain at least one [1..*] component [CONF:409].

(1) SHALL contain exactly one [1..1] @typeCode="DRIV" derived (CodeSystem:


(2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:411].

The following XML example outlines how to use the EMR Conversion template:





<templateId root="2.16.840.1.113883.3.1818.10.7.1"/>



<templateId root="2.16.840.1.113883.3.1818.10.1.1"/>

…

<component typeCode=”COMP” contextConductionInd=”true”>

<structuredBody classCode-“DOCBODY” moodCode=”EVN”>


<languageCode code="en-CA" displayName="English, Canada"

codeSystem="2.16.840.1.113883.1.11.11526" codeSystemName="Internet Society

Language"/>


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



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


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


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



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


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


[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


[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


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


[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].



4.2 GENERIC EPISODIC DOCUMENT


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


Generic Episodic Document Document 2.16.840.1.113883.3.1818.10.1.2




























Section 2.16.840.1.113883.3.1818.10.2.4.1



















Section 2.16.840.1.113883.3.1818.10.2.4


Section 2.16.840.1.113883.3.1818.10.2.7


Section 2.16.840.1.113883.3.1818.10.2.8.1


SectionEntry 2.16.840.1.113883.3.1818.10.3.7




Section 2.16.840.1.113883.3.1818.10.2.8























Entry 2.16.840.1.113883.3.1818.10.4.36































Section 2.16.840.1.113883.3.1818.10.2.10





























Section 2.16.840.1.113883.3.1818.10.2.12































Section 2.16.840.1.113883.3.1818.10.2.15.1




















Section 2.16.840.1.113883.3.1818.10.2.15


Section 2.16.840.1.113883.3.1818.10.2.16.1

















Section 2.16.840.1.113883.3.1818.10.2.16















Section 2.16.840.1.113883.3.1818.10.2.18.1














Section 2.16.840.1.113883.3.1818.10.2.18


Section 2.16.840.1.113883.3.1818.10.2.19.1



















Entry 2.16.840.1.113883.3.1818.10.4.36





























Section 2.16.840.1.113883.3.1818.10.2.19



































Section 2.16.840.1.113883.3.1818.10.2.21.1










Section 2.16.840.1.113883.3.1818.10.2.21

Purpose Section 2.16.840.1.113883.3.1818.10.2.22






Section 2.16.840.1.113883.3.1818.10.2.23





























Section 2.16.840.1.113883.3.1818.10.2.25





















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:



the Generic Episodic Document clinical document specification.



2) SHALL contain at least one [1..*] informationRecipient [CONF:4429].



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:







ActClass 2.16.840.1.113883.5.6) [CONF:299].


2.16.840.1.113883.5.1001) [CONF:300].






(1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:



(3) SHALL contain exactly one [1..1] section [CONF:306].

The following XML example outlines how to use the Generic Episodic Document template:





<templateId root="2.16.840.1.113883.3.1818.10.7.1"/>



<templateId root="2.16.840.1.113883.3.1818.10.1.2"/>

…






Language"/>


<section>

. . .

</section>

<section>

. . .

</section>

</component>

</structuredBody>

</component>

</ClinicalDocument>

Figure 30: Generic Episodic Document entry example


1) MAY include one Advance Directives section, such that component/section,




[CONF:SEC- 26.1].

2) MAY include one Alerts section, such that component/section,




3) MAY include one Allergies & Intolerances - Reaction List section, such that component/section,




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,


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,




2.16.840.1.113883.3.1818.10.2.8.1) [CONF:SEC- 32.1].



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,




[CONF:SEC- 34.1].

8) MAY include one Devices section, such that component/section,




9) MAY include one Encounter History & Notes section, such that component/section,




[CONF:SEC- 36.1].

10) MAY include one Family History section, such that component/section,




11) MAY include one Immunizations List section, such that component/section,




38.1].

12) MAY include one Investigative Procedure History section, such that component/section,




[CONF:SEC- 39.1].

13) MAY include one Laboratory Results & Reports section, such that component/section,




[CONF:SEC- 40.1].

14) MAY include one Medical History section, such that component/section,




15) MAY include one Medical Imaging Results & Reports section, such that component/section,




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,






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,




[CONF:SEC- 44.1].

18) MAY include one Problems & Conditions - Problem List section, such that component/section,




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,




[CONF:SEC- 47.1].

21) MAY include one Risk Factors section, such that component/section,




22) MAY include one Surgical Procedure History section, such that component/section,




[CONF:SEC- 49.1].

23) MAY include one Treatment History section, such that component/section,




[CONF:SEC- 50.1].

4.3 GENERIC STRUCTURED REFERRAL


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


Generic Structured Referral Document 2.16.840.1.113883.3.1818.10.1.6




























Section 2.16.840.1.113883.3.1818.10.2.4.1



















Section 2.16.840.1.113883.3.1818.10.2.4


Section 2.16.840.1.113883.3.1818.10.2.7





Section 2.16.840.1.113883.3.1818.10.2.8.1


SectionEntry 2.16.840.1.113883.3.1818.10.3.7




Section 2.16.840.1.113883.3.1818.10.2.8




















Entry 2.16.840.1.113883.3.1818.10.4.36


































Section 2.16.840.1.113883.3.1818.10.2.10


























Section 2.16.840.1.113883.3.1818.10.2.12































Section 2.16.840.1.113883.3.1818.10.2.15.1




















Section 2.16.840.1.113883.3.1818.10.2.15


Section 2.16.840.1.113883.3.1818.10.2.16.1




















Section 2.16.840.1.113883.3.1818.10.2.16












Section 2.16.840.1.113883.3.1818.10.2.18.1














Section 2.16.840.1.113883.3.1818.10.2.18


Section 2.16.840.1.113883.3.1818.10.2.19.1






















Entry 2.16.840.1.113883.3.1818.10.4.36


























Section 2.16.840.1.113883.3.1818.10.2.19



































Section 2.16.840.1.113883.3.1818.10.2.21.1










Section 2.16.840.1.113883.3.1818.10.2.21

Purpose Section 2.16.840.1.113883.3.1818.10.2.22






Section 2.16.840.1.113883.3.1818.10.2.23





























Section 2.16.840.1.113883.3.1818.10.2.25























Generic Structured Referral Header Constraints

A Generic Structured Referral SHALL conform to the BC PITO Standard Header Template subject to




the Generic Structured Referral clinical document specification.



2) SHALL contain exactly one [1..1] code="57133-1" Referral note (CodeSystem: LOINC

2.16.840.1.113883.6.1) [CONF:4385].


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:







ActClass 2.16.840.1.113883.5.6) [CONF:4376].


2.16.840.1.113883.5.1001) [CONF:4377].






(1) SHALL contain exactly one [1..1] @typeCode="COMP" component (CodeSystem:



(3) SHALL contain exactly one [1..1] section [CONF:4383].

The following XML example outlines how to use the Generic Structured Referral template:





<templateId root="2.16.840.1.113883.3.1818.10.7.1"/>



<templateId root="2.16.840.1.113883.3.1818.10.1.6"/>

…






Language"/>


<section>

. . .

</section>

<section>

. . .

</section>

</component>

</structuredBody>

</component>

</ClinicalDocument>

Figure 31: Generic Structured Referral entry example


1) MAY include one Advance Directives section, such that component/section,




[CONF:SEC- 179.1].

2) MAY include one Alerts section, such that component/section,




3) MAY include one Allergies & Intolerances - Reaction List section, such that component/section,




2.16.840.1.113883.3.1818.10.2.4.1) [CONF:SEC- 181.1].



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,




2.16.840.1.113883.3.1818.10.2.8.1) [CONF:SEC- 185.1].



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





[CONF:SEC- 187.1].





9) MAY include one Encounter History & Notes section, such that component/section,




[CONF:SEC- 189.1].

10) MAY include one Family History section, such that component/section,



[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,




191.1].

12) MAY include one Investigative Procedure History section, such that component/section,




[CONF:SEC- 192.1].

13) MAY include one Laboratory Results & Reports section, such that component/section,




[CONF:SEC- 193.1].

14) MAY include one Medical History section, such that component/section,




194.1].

15) MAY include one Medical Imaging Results & Reports section, such that component/section,




2.16.840.1.113883.3.1818.10.2.18.1) [CONF:SEC- 195.1].



16) MAY include one Medications & Prescriptions - Medication List section, such that component/section,




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,




[CONF:SEC- 197.1].

18) MAY include one Problems & Conditions - Problem List section, such that component/section,




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,


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,




[CONF:SEC- 200.1].

21) MAY include one Risk Factors section, such that component/section,




201.1].

22) MAY include one Surgical Procedure History section, such that component/section,




[CONF:SEC- 202.1].

23) MAY include one Treatment History section, such that component/section,




[CONF:SEC- 203.1].

4.4 GENERIC UNSTRUCTURED REFERRAL


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



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


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




the Generic Unstructured Referral clinical document specification.




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:





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

The following XML example outlines how to use the Generic Unstructured Referral template:




<templateId root="2.16.840.1.113883.3.1818.10.7.1"/>



<templateId root="2.16.840.1.113883.3.1818.10.1.5"/>

...

Full nonXMLBody example with embedded content:


<nonXMLBody classCode-“DOCBODY” moodCode=”EVN”>




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


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.



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


Patient Transfer Document 2.16.840.1.113883.3.1818.10.1.3

























Section 2.16.840.1.113883.3.1818.10.2.4.1






















Section 2.16.840.1.113883.3.1818.10.2.4


Section 2.16.840.1.113883.3.1818.10.2.7


Section 2.16.840.1.113883.3.1818.10.2.8.1


SectionEntry 2.16.840.1.113883.3.1818.10.3.7




Section 2.16.840.1.113883.3.1818.10.2.8






Section 2.16.840.1.113883.3.1818.10.2.10





























Section 2.16.840.1.113883.3.1818.10.2.12




























Section 2.16.840.1.113883.3.1818.10.2.15.1























Section 2.16.840.1.113883.3.1818.10.2.15


Section 2.16.840.1.113883.3.1818.10.2.16.1

















Section 2.16.840.1.113883.3.1818.10.2.16












Section 2.16.840.1.113883.3.1818.10.2.18.1

















Section 2.16.840.1.113883.3.1818.10.2.18


Section 2.16.840.1.113883.3.1818.10.2.19.1



















Entry 2.16.840.1.113883.3.1818.10.4.36





























Section 2.16.840.1.113883.3.1818.10.2.19
































Section 2.16.840.1.113883.3.1818.10.2.21.1













Section 2.16.840.1.113883.3.1818.10.2.21

Purpose Section 2.16.840.1.113883.3.1818.10.2.22






Section 2.16.840.1.113883.3.1818.10.2.23


























Section 2.16.840.1.113883.3.1818.10.2.25
























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







Patient Transfer Header Constraints

A Patient Transfer SHALL conform to the BC PITO Standard Header Template subject to additional

constraints as follows. Conformant documents:



the Patient Transfer clinical document specification.



2) SHALL contain exactly one [1..1] code="28616-1" Physician transfer note (CodeSystem: LOINC

2.16.840.1.113883.6.1) [CONF:4384].


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:






ActClass 2.16.840.1.113883.5.6) [CONF:353].


2.16.840.1.113883.5.1001) [CONF:354].






(1) SHALL contain exactly one [1..1] @typeCode="DRIV" derived (CodeSystem:



The following XML example outlines how to use the Patient Transfer template:




<templateId root="2.16.840.1.113883.3.1818.10.7.1"/>



<templateId root="2.16.840.1.113883.3.1818.10.1.3"/>

…






Language"/>


<section>

. . .

</section>

<section>

. . .

</section>

</component>

</structuredBody>

</component>

</ClinicalDocument>

Figure 33: Patient Transfer entry example


1) SHALL include one Advance Directives section, such that component/section,




[CONF:SEC- 51.1].

2) SHOULD include one Alerts section, such that component/section,



3) SHALL include one Allergies & Intolerances - Reaction List section, such that component/section,




2.16.840.1.113883.3.1818.10.2.4.1) [CONF:SEC- 53.1].



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,




2.16.840.1.113883.3.1818.10.2.8.1) [CONF:SEC- 57.1].





[CONF:SEC- 59.1].





8) SHOULD include one Encounter History & Notes section, such that component/section,




[CONF:SEC- 61.1].

9) SHOULD include one Family History section, such that component/section,




10) SHOULD include one Immunizations List section, such that component/section,




63.1].

11) SHOULD include one Investigative Procedure History section, such that component/section,




[CONF:SEC- 64.1].

12) SHOULD include one Laboratory Results & Reports section, such that component/section,




[CONF:SEC- 65.1].

13) SHOULD include one Medical History section, such that component/section,






14) SHOULD include one Medical Imaging Results & Reports section, such that component/section,




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,




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,




[CONF:SEC- 69.1].

17) SHALL include one Problems & Conditions - Problem List section, such that component/section,




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,


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,




[CONF:SEC- 72.1].

20) SHOULD include one Risk Factors section, such that component/section,




21) SHOULD include one Surgical Procedure History section, such that component/section,




[CONF:SEC- 74.1].

22) SHOULD include one Treatment History section, such that component/section,




[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].



4.6 UNSTRUCTURED DOCUMENT


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


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




the Unstructured Document clinical document specification.




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:





c) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} nonXMLBody [CONF:289].


ActClass 2.16.840.1.113883.5.6) [CONF:290].


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


v) MAY contain zero or one [0..1] {CDAR2} languageCode, which SHALL be selected from


The following XML example outlines how to use the Unstructured Document template:




<templateId root="2.16.840.1.113883.3.1818.10.7.1"/>



<templateId root="2.16.840.1.113883.3.1818.10.1.4"/>

...

Full nonXMLBody example with embedded content:


<nonXMLBody classCode-“DOCBODY” moodCode=”EVN”>




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



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



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



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.



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


EMR Conversion Advanced Directives Observation



Patient Transfer



An Advance Directives [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:532].


2.16.840.1.113883.5.1001) [CONF:533].


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,



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

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

…

</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



Table 30: Alerts [without entries] Template Context




EMR Conversion N/A



Patient Transfer

An Alerts [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:539].


2.16.840.1.113883.5.1001) [CONF:540].



[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,





Table 31: Alerts [with entries] Template Context


EMR Conversion Alert Observation



Patient Transfer

An Alerts [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:545].


2.16.840.1.113883.5.1001) [CONF:546].



[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) 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:



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


<templateId root="2.16.840.1.113883.3.1818.10.3.2"/> 

…

</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



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



Table 32: Allergies & Intolerances (Reaction List) [without entries] Template Context


EMR Conversion N/A



Patient Transfer



An Allergies & Intolerances (Reaction List) [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:643].


2.16.840.1.113883.5.1001) [CONF:644].



[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,





Table 33: Allergies & Intolerances (Reaction List) [with entries] Template Context


EMR Conversion Allergy & Intolerance Observation



Patient Transfer

An Allergies & Intolerances (Reaction List) [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:649].


2.16.840.1.113883.5.1001) [CONF:650].



[CONF:651.12].

4) SHALL contain exactly one [1..1] code="48765-2" Allergies, adverse reactions, alerts


5) SHALL contain exactly one [1..1] title="Allergies & Intolerances (Reaction List)

[with entries]" [CONF:653] such that it,



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

The following XML example outlines how to use the Allergies & Intolerances (Reaction List) [with entries]

template:



<templateId root="2.16.840.1.113883.3.1818.10.2.4.1"/>


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>


<templateId root="2.16.840.1.113883.3.1818.10.3.3"/> 

…

</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



Table 34: Appointments & Scheduling [with entries] Template Context


EMR Conversion Appointment Observation

An Appointments & Scheduling [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:656].

2.16.840.1.113883.5.1001) [CONF:657].



[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]"





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:



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




<templateId root="2.16.840.1.113883.3.1818.10.3.4"/> 

…

</entry>

</section>

</component>

Figure 38: Appointments & Scheduling [with entries] entry example



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



Table 35: Billing [with entries] Template Context


EMR Conversion Billing Attachment

A Billing [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:467].


2.16.840.1.113883.5.1001) [CONF:468].



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

http://www.health.gov.bc.ca/msp/infoprac/teleplanspecs/index.html

The following XML example outlines how to use the Billing [with entries] template:



<templateId root="2.16.840.1.113883.3.1818.10.2.6"/>


displayName="Payment sources Doc"/>

<title>Billing [with entries]</title>

<text>



</text>


<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



Table 36: Care Plan / Reminders / Tasks [without entries] Template Context




EMR Conversion N/A



Patient Transfer

A Care Plan / Reminders / Tasks [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:461].


2.16.840.1.113883.5.1001) [CONF:462].



[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




The following XML example outlines how to use the Care Plan / Reminders / Tasks [without entries]

template:



<templateId root="2.16.840.1.113883.3.1818.10.2.7"/>


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



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



Table 38: Clinical Measured Observations [without entries] Template Context

http://www.bcguidelines.ca/pdf/diabetes_flow_sheet.pdf

http://www.bcguidelines.ca/pdf/heart_failure_flowsheet.pdf

http://www.bcguidelines.ca/pdf/hypertension_appendix_d.pdf

http://www.bcguidelines.ca/pdf/copd_appendix_a.pdf

http://www.bcguidelines.ca/pdf/cognitive_appendix_g.pdf

http://www.bcguidelines.ca/pdf/depression_flow.pdf




EMR Conversion N/A



Patient Transfer

A Clinical Measured Observations [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:604].


2.16.840.1.113883.5.1001) [CONF:605].



[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






Table 39: Clinical Measured Observations [with entries] Template Context


EMR Conversion Clinically Measured Observations Organizer



Patient Transfer

A Clinical Measured Observations [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:610].


2.16.840.1.113883.5.1001) [CONF:611].



[CONF:612.12].

4) SHALL contain exactly one [1..1] code="CLINOBS" Clinically Measured Observations (CodeSystem:


5) SHALL contain exactly one [1..1] title="Clinical Measured Observations [with



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:



<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 11-feb-2013, 09:00 AM 50

Systolic Pressure 14-Feb-2011, 12:00 PM 180




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>


<templateId root="2.16.840.1.113883.3.1818.10.3.7"/> 

…

</entry>

</section>

</component>

Figure 41: Clinical Measured Observations [with entries] entry example



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



Table 40: Current Medications [without entries] Template Context


EMR Conversion N/A



A Current Medications [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:663].


2.16.840.1.113883.5.1001) [CONF:664].



[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]"




Table 41: Current Medications [with entries] Template Context


EMR Conversion Medication Event



A Current Medications [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:669].


2.16.840.1.113883.5.1001) [CONF:670].



[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]"





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:



<templateId root="2.16.840.1.113883.3.1818.10.2.9.1"/>


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>


<templateId root="2.16.840.1.113883.3.1818.10.3.18" /> 

…

</entry>

</section>

</component>

Figure 42: Current Medications [with entries] entry example



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.


based nomenclature or clinical scales where appropriate.


Developmental Observations Template Definitions



Table 42: Developmental Observations [without entries] Template Context


EMR Conversion N/A



Patient Transfer

A Developmental Observations [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:630].


2.16.840.1.113883.5.1001) [CONF:631].



[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






Table 43: Developmental Observations [with entries] Template Context


EMR Conversion Developmental Observations Organizer


Patient Transfer

A Developmental Observations [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:636].


2.16.840.1.113883.5.1001) [CONF:637].



[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]"





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:



<templateId root="2.16.840.1.113883.3.1818.10.2.10.1"/>


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>


<templateId root="2.16.840.1.113883.3.1818.10.3.7"/> <!-- Developmental


...

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



This section supports both free text device descriptions as well as discrete data encoded using a

standards based nomenclature.

Devices Template Definitions



Table 44: Devices [without entries] Template Context


EMR Conversion N/A



Patient Transfer

A Devices [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:474].


2.16.840.1.113883.5.1001) [CONF:475].



[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,





Table 45: Devices [with entries] Template Context


EMR Conversion Device Observation



Patient Transfer

A Devices [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:480].


2.16.840.1.113883.5.1001) [CONF:481].





[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) SHALL contain exactly one [1..1] Device Observation

(2.16.840.1.113883.3.1818.10.3.8) [CONF:486.1].

The following XML example outlines how to use the Devices [with entries] template:



<templateId root="2.16.840.1.113883.3.1818.10.2.11.1"/>


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>Daughter Cloe</td>

</tr>

<tr>

<td>Breast Prosthesis</td>

<td>05-Jul-1967</td>


<td>Patient</td>

</tr>

<tr>

<td>Wheelchair</td>

<td>1999</td>

</tr>

</tbody>

</table>

</text>


<templateId root="2.16.840.1.113883.3.1818.10.3.8"/> 

…

</entry>

</section>

</component>

Figure 44: Devices [with entries] entry example



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.



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



Table 46: Encounter History & Notes [without entries] Template Context


EMR Conversion N/A



Patient Transfer

An Encounter History & Notes [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:689].


2.16.840.1.113883.5.1001) [CONF:690].



[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]"






Table 47: Encounter History & Notes [with entries] Template Context


EMR Conversion Encounter Event



Patient Transfer

An Encounter History & Notes [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:695].

2.16.840.1.113883.5.1001) [CONF:696].



[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]"





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:



<templateId root="2.16.840.1.113883.3.1818.10.2.22.1"/>


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>


<templateId root="2.16.840.1.113883.3.1818.10.3.9"/> 

…

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



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.



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



Table 48: Family History [without entries] Template Context


EMR Conversion N/A



Patient Transfer

A Family History [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:552].


2.16.840.1.113883.5.1001) [CONF:553].



[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,



http://www.hl7.org/Special/committees/clingenomics/index.cfm





Table 49: Family History [with entries] Template Context


EMR Conversion Family History Observation



Patient Transfer

A Family History [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:558].


2.16.840.1.113883.5.1001) [CONF:559].



[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) SHALL contain exactly one [1..1] Family History Observation

(2.16.840.1.113883.3.1818.10.3.10) [CONF:564.1].

The following XML example outlines how to use the Family History [with entries] template:



<templateId root="2.16.840.1.113883.3.1818.10.2.13.1"/>


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>


<templateId root="2.16.840.1.113883.3.1818.10.3.10"/> 

…

</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



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.



Immunizations List Template Definitions



Table 50: Immunizations List [without entries] Template Context


EMR Conversion N/A



Patient Transfer

An Immunizations List [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:591].


2.16.840.1.113883.5.1001) [CONF:592].



[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]"






Table 51: Immunizations List [with entries] Template Context


EMR Conversion Immunization Observation



Patient Transfer

An Immunizations List [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:597].


2.16.840.1.113883.5.1001) [CONF:598].



[CONF:599.12].



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) SHALL contain exactly one [1..1] Immunization Observation

(2.16.840.1.113883.3.1818.10.3.11) [CONF:603.1].

The following XML example outlines how to use the Immunizations List [with entries] template:



<templateId root="2.16.840.1.113883.3.1818.10.2.14.1"/>


displayName="History of Immunization"/>

<title>Immunizations List [with entries]</title>

<text>


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


<templateId root="2.16.840.1.113883.3.1818.10.3.11"/> 

…

</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



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



Table 52: Investigative Procedure History [without entries] Template Context


EMR Conversion N/A



Patient Transfer

An Investigative Procedure History [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:513].


2.16.840.1.113883.5.1001) [CONF:514].



[CONF:515.12].

4) SHALL contain exactly one [1..1] code="INVPROC" Investigative Procedure History (CodeSystem:


5) SHALL contain exactly one [1..1] title="Investigative Procedure History [without






Table 53: Investigative Procedure History [with entries] Template Context


EMR Conversion Care History Event






Patient Transfer

An Investigative Procedure History [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:519].


2.16.840.1.113883.5.1001) [CONF:520].



[CONF:521.12].

4) SHALL contain exactly one [1..1] code="INVPROC" Investigative Procedure History (CodeSystem:


5) SHALL contain exactly one [1..1] title="Investigative Procedure History [with





a) SHALL contain exactly one [1..1] Care History Event (2.16.840.1.113883.3.1818.10.3.6)

[CONF:525.1].

The following XML example outlines how to use the Investigative Procedure History [with entries]

template:



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


<templateId root="2.16.840.1.113883.3.1818.10.3.6"/> 

…

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



Laboratory Results & Reports Template Definitions



Table 54: Laboratory Results & Reports [without entries] Template Context


EMR Conversion N/A



Patient Transfer

A Laboratory Results & Reports [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:715].


2.16.840.1.113883.5.1001) [CONF:716].



[CONF:717.12].

4) SHALL contain exactly one [1..1] code="30954-2" Relevant diagnostic tests and/or laboratory data


5) SHALL contain exactly one [1..1] title="Laboratory Results & Reports [without






Table 55: Laboratory Results & Reports [with entries] Template Context


EMR Conversion Laboratory Observation



Patient Transfer

A Laboratory Results & Reports [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:721].


2.16.840.1.113883.5.1001) [CONF:722].



[CONF:723.12].



4) SHALL contain exactly one [1..1] code="30954-2" Relevant diagnostic tests and/or laboratory data


5) SHALL contain exactly one [1..1] title="Laboratory Results & Reports [with entries]"





a) SHALL contain exactly one [1..1] Laboratory Observation

(2.16.840.1.113883.3.1818.10.3.12) [CONF:727.1].



The following XML example outlines how to use the Laboratory Results & Reports [with entries] template:



<templateId root="2.16.840.1.113883.3.1818.10.2.16.1"/>


displayName="Relevant diagnostic tests and/or laboratory data"/>

<title>Laboratory Results and Reports [with entries]</title>

<text>


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

</tr>

<tr>

<td>HCO3 (18-23 meq/l)</td>

<td> </td>

<td>35*</td>

</tr>

</tbody>

</table>

</text>


<templateId root="2.16.840.1.113883.3.1818.10.2.16.1"/> 

…

</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



Table 56: Medical History [without entries] Template Context


EMR Conversion N/A





Patient Transfer

A Medical History [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:565].


2.16.840.1.113883.5.1001) [CONF:566].



[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,





Table 57: Medical History [with entries] Template Context


EMR Conversion Problem List Observation



Patient Transfer

A Medical History [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:571].


2.16.840.1.113883.5.1001) [CONF:572].



[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) 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:



<templateId root="2.16.840.1.113883.3.1818.10.2.17.1"/>


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>


<templateId root="2.16.840.1.113883.3.1818.10.3.15"/> 

…

</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



Table 58: Medical Imaging Results & Reports [without entries] Template Context


EMR Conversion N/A



Patient Transfer



A Medical Imaging Results & Reports [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:702].


2.16.840.1.113883.5.1001) [CONF:703].



[CONF:704.12].

4) SHALL contain exactly one [1..1] code="55115-0" Requested imaging studies information


5) SHALL contain exactly one [1..1] title="Medical Imaging Results & Reports [without






Table 59: Medical Imaging Results & Reports [with entries] Template Context


EMR Conversion Medical Imaging Observation



Patient Transfer

A Medical Imaging Results & Reports [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:708].


2.16.840.1.113883.5.1001) [CONF:709].



[CONF:710.12].

4) SHALL contain exactly one [1..1] code="55115-0" Requested imaging studies information


5) SHALL contain exactly one [1..1] title="Medical Imaging Results & Reports [with





a) SHALL contain exactly one [1..1] Medical Imaging Observation

(2.16.840.1.113883.3.1818.10.3.13) [CONF:714.1].

The following XML example outlines how to use the Medical Imaging Results & Reports [with entries]

template:



<templateId root="2.16.840.1.113883.3.1818.10.2.18.1"/>


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.



<renderMultiMedia referencedObject="M11"></renderMultiMedia>

</td>

<td>Feb 11, 2013</td>

<td>Chest Pain</td>

<td>Dr. Raymond Xpert</td>

</tr>

</tbody>

</table>

</text>


<templateId root="2.16.840.1.113883.3.1818.10.3.13"/> 

…

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



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.



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.



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

http://www.hc-sc.gc.ca/dhp-mps/prodpharma/activit/fs-fi/dinfs_fd-eng.php

http://www.hc-sc.gc.ca/dhp-mps/prodnatur/about-apropos/index-eng.php

http://www.fdbhealth.com/

http://www.multum.com/

http://en.wikipedia.org/wiki/Anatomical_Therapeutic_Chemical_Classification_System



(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



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



Table 60: Medications & Prescriptions - Medication List [without entries] Template Context


EMR Conversion N/A



Patient Transfer



A Medications & Prescriptions - Medication List [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:676].


2.16.840.1.113883.5.1001) [CONF:677].



[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,





Table 61: Medications & Prescriptions - Medication List [with entries] Template Context


EMR Conversion Medication Event



Patient Transfer

A Medications & Prescriptions - Medication List [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:682].


2.16.840.1.113883.5.1001) [CONF:683].



[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) SHALL contain exactly one [1..1] Medication Event (2.16.840.1.113883.3.1818.10.3.18)

[CONF:688.1].



The following XML example outlines how to use the Medications & Prescriptions - Medication List [with

entries] template:



<templateId root="2.16.840.1.113883.3.1818.10.2.19.1"/>


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>

</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



Table 62: Orders & Requests [without entries] Template Context


EMR Conversion N/A



Patient Transfer



An Orders & Requests [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:728].


2.16.840.1.113883.5.1001) [CONF:729].



[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]"






Table 63: Orders & Requests [with entries] Template Context


EMR Conversion Order Event



Patient Transfer

An Orders & Requests [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:734].


2.16.840.1.113883.5.1001) [CONF:735].



[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) SHALL contain exactly one [1..1] Order Event (2.16.840.1.113883.3.1818.10.3.14)

[CONF:740.1].

The following XML example outlines how to use the Orders & Requests [with entries] template:



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


<templateId root="2.16.840.1.113883.3.1818.10.3.14"/> 

…

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



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.



Problems & Conditions - Problem List Template Definitions



Table 64: Problems & Conditions - Problem List [without entries] Template Context


EMR Conversion N/A



Patient Transfer

A Problems & Conditions - Problem List [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:578].


2.16.840.1.113883.5.1001) [CONF:579].



[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,





Table 65: Problems & Conditions - Problem List [with entries] Template Context


EMR Conversion Problem List Observation



Patient Transfer

A Problems & Conditions - Problem List [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:584].


2.16.840.1.113883.5.1001) [CONF:585].



[CONF:586.12].



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





a) SHALL contain exactly one [1..1] Problem List Observation

(2.16.840.1.113883.3.1818.10.3.15) [CONF:590.1].



The following XML example outlines how to use the Problems & Conditions - Problem List [with entries]

template:



<templateId root="2.16.840.1.113883.3.1818.10.2.21.1"/>


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>



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: templateId 2.16.840.1.113883.3.1818.10.2.22(closed)]

Table 66: Purpose Template Context

Generic Episodic Document N/A


Patient Transfer

A Purpose (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:455].


2.16.840.1.113883.5.1001) [CONF:456].



[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,



The following XML example outlines how to use the Purpose template:



<templateId root="2.16.840.1.113883.3.1818.10.2.22"/> 


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.


based nomenclature.




Reproductive Observations Template Definitions



Table 67: Reproductive Observations [without entries] Template Context


EMR Conversion N/A



Patient Transfer

A Reproductive Observations [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:617].


2.16.840.1.113883.5.1001) [CONF:618].



[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]"






Table 68: Reproductive Observations [with entries] Template Context


EMR Conversion Reproductive Observations Organizer



Patient Transfer

A Reproductive Observations [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:623].


2.16.840.1.113883.5.1001) [CONF:624].


[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]"





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:



<templateId root="2.16.840.1.113883.3.1818.10.2.23.1"/> 


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>


<templateId root="2.16.840.1.113883.3.1818.10.3.16"/> <!-- Reproductive


…

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



Risk Factors Template Definitions



Table 69: Risk Factors [without entries] Template Context


EMR Conversion N/A



Patient Transfer

A Risk Factors [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:741].


2.16.840.1.113883.5.1001) [CONF:742].



[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,





Table 70: Risk Factors [with entries] Template Context


EMR Conversion Risk Factors Organizer



Patient Transfer

A Risk Factors [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:747].


2.16.840.1.113883.5.1001) [CONF:748].



[CONF:749.12].

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



<templateId root="2.16.840.1.113883.3.1818.10.2.24.1"/>


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>


<templateId root="2.16.840.1.113883.3.1818.10.3.17"/> 

…

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



Surgical Procedure History Template Definitions



Table 71: Surgical Procedure History [without entries] Template Context


EMR Conversion N/A



Patient Transfer

A Surgical Procedure History [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:500].


2.16.840.1.113883.5.1001) [CONF:501].



[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






Table 72: Surgical Procedure History [with entries] Template Context





Patient Transfer

A Surgical Procedure History [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:506].


2.16.840.1.113883.5.1001) [CONF:507].



[CONF:508.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:509].

5) SHALL contain exactly one [1..1] title="Surgical Procedure History [with entries]"






[CONF:512.1].



The following XML example outlines how to use the Surgical Procedure History [with entries] template:



<templateId root="2.16.840.1.113883.3.1818.10.2.25.1"/>


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 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 Datetime: 05-jul-1967</item>

<item>Intervention Reason: </item>

<item>Intervention Qualifier: Bilateral</item>

</list>

</text>



…

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



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



Table 73: Treatment History [without entries] Template Context


EMR Conversion N/A



Patient Transfer

A Treatment History [without entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:487].


2.16.840.1.113883.5.1001) [CONF:488].



[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]"






Table 74: Treatment History [with entries] Template Context





Patient Transfer



A Treatment History [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:493].


2.16.840.1.113883.5.1001) [CONF:494].



[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,





[CONF:499.1].



The following XML example outlines how to use the Treatment History [with entries] template:



<templateId root="2.16.840.1.113883.3.1818.10.2.26.1"/>


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>

</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



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



Table 75: Unclassified Documents [with entries] Template Context


EMR Conversion Unclassified Documents Organizer

Patient Transfer

An Unclassified Documents [with entries] (Section) element:


ActClass 2.16.840.1.113883.5.6) [CONF:4452].


2.16.840.1.113883.5.1001) [CONF:4453].



[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) SHALL contain exactly one [1..1] Unclassified Documents Organizer

(2.16.840.1.113883.3.1818.10.3.19) [CONF:4458.1].

The following XML example outlines how to use the Unclassified Documents [with entries] template:



<templateId root="2.16.840.1.113883.3.1818.10.2.26.1"/>


displayName="Text-Miscellaneous Section"/>

<title>Unclassified Documents [with entries] [PITO]</title>

<text>

</text>


<templateId root="2.16.840.1.113883.3.1818.10.3.27.1"/> 

...

</entry>

</section>

</component>

Figure 60: Unclassified Documents [with entries] entry example



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


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


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



755 templateId O:0..* II

756 observation O:0..*






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.


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


769 @contextControlCode O:1..1

770 Custodian Role participantRole R:0..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



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:




[CONF:755.12].

3) MAY contain zero or more [0..*] {CDAR2} observation [CONF:756].



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:


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


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,






(4) SHALL contain zero or one if available [0..1] playingEntity [CONF:774].





(c) SHALL contain zero or one if available [0..1] name [CONF:777].

The following XML example outlines how to use the Advanced Directives Observation template:


<templateId root="2.16.840.1.113883.3.1818.10.3.1"/> 



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




<participant typeCode="CST" contextControlCode="OP">

<participantRole classCode="ASSIGNED">

<addr>



<state>BC</state>



</addr>


<playingEntity classCode="PSN" determinerCode="INSTANCE">

<name>



<given>H.</given>



</name>

</playingEntity>

</participantRole>

</participant>



<entryRelationship typeCode="SUBJ" contextConductionInd="true"

inversionInd="true">

<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> 


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


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

<templateId root="2.16.840.1.113883.3.1818.10.4.2"/> 

<time value="20030529"/>


<id use="BUS" extension="38809"

root="2.16.840.1.113883.3.163.5.0.10.2"/>


<name>Dr. W. Pewarchuck</name>

</assignedPerson>



root="2.16.840.1.113883.3.163.5.0.10.2"/>



</assignedAuthor>

</author>

</observation>

</entryRelationship>





<templateId root="2.16.840.1.113883.3.1818.10.4.4"/> 


<code code="DATEOBS" displayName="Date Observation"


Pending"/>

<effectiveTime value="20120201114523-0700"/>

</observation>




<entryRelationship typeCode="COMP" contextConductionInd="true">

<templateId root="2.16.840.1.113883.3.1818.10.4.1"/> 



<code code="ATTACH" displayName="Attachment Observation"


Pending"/>

<text>Keywords: DNR 4, full resucitation</text>


<e2e:confidentialityCode code="N" codeSystem="2.16.840.1.113883.5.25"/>

<value xsi:type="ST">Resucitation Order</value>






Observation -->




Pending"/>

<value xsi:type="ST">Attachment Note included here</value>

</observation>

Observation -->




Pending"/>


</observation>




<templateId root="2.16.840.1.113883.3.1818.10.4.9"/> 





claim1.pdf"/>

</value>



Participation -->

<time value="20030529"/>



root="2.16.840.1.113883.3.163.5.0.10.2"/>



</assignedPerson>

</assignedAuthor>

</author>

</observationMedia>


</observation>


</observation>

</entry>

Figure 61: Advanced Directives Observation entry example

6.2 ALERT OBSERVATION


Table 78: Alert Observation Template Context


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.



Table 79: Alert Observation Constraints Overview







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.


787 Start Date/End Date The effective or start date associated with the alert.


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


R:0..1

An Alert Observation (Observation) element:





[CONF:779.12].



2.16.840.1.113883.5.6) [CONF:781].


2.16.840.1.113883.5.1001) [CONF:782].



ValueSet AlertType 2.16.840.1.113883.3.1818.10.8.1 STATIC [CONF:784].




f) SHALL contain exactly one [1..1] statusCode, which SHALL be selected from ValueSet




that it,



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



[CONF:789.1].

j) SHALL contain zero or one if available [0..1] entryRelationship [CONF:790] such that it,


(2.16.840.1.113883.3.1818.10.4.3) [CONF:790.1].

The following XML example outlines how to use the Alert Observation template:


<templateId root="2.16.840.1.113883.3.1818.10.3.2"/>



<code code="INFECTIOUS" displayName="Infectious Disease Alert"


Pending"/>

<text>MRSA - Multiple resistant staphylococcus aureus infection carrier</text>










Pending"/>

<text>Keywords: MRSA</text>


<value xsi:type="ST">MRSA Alert</value>







<templateId root="2.16.840.1.113883.3.1818.10.4.9"/> 

</observationMedia>


</observation>


</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


Allergies & Intolerances (Reaction List) [with entries] Comment Observation

Lifestage Observation

Reaction Observation

Severity Observation




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.



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”

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


<code nullFlavor="NA"/>



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



<entryRelationship typeCode="COMP">


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






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






<code code="DOCDATE" codeSystem="2.16.840.1.113883.3.1818.10.2.8.1"

codeSystemName="PITO ObservationType" displayName="DocumentedDate"/>


</observation>


</observation>

</entry>

Figure 65: Example “Allergies Reviewed & None Identified – structured data”



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




793 Allergy Problem Act act O:0..*



796 Record ID id R:1..1 II

798 Allergy/Intolerance Status The status of the Allergy/Intolerance.


799 Documented Date The date when the allergy or adverse reaction was recorded on the patient chart.


800 Allergy/Intolerance Observation Details entryRelationship R:1..1





805 Onset Date & Resolved Date The effective date/time of the allergy or intolerance.


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



811 Allergen Detail participantRole O:0..*


813 playingEntity O:0..1



816 Coded Allergen code R:1..1 CE




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


1716 observation 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


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






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








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:





[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].


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,


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



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



(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,



(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:


(b) MAY contain zero or one [1..1] {CDAR2} @contextControlCode="OP" overriding


(c) MAY contain zero or more [0..*] {CDAR2} participantRole [CONF:811].

(i) SHALL contain exactly one [1..1] @classCode="MANU" manufactured product


(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


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:


(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].


(a) SHALL contain exactly one [1..1] Comment Observation

(2.16.840.1.113883.3.1818.10.4.3) [CONF:819.1].


(a) SHALL contain exactly one [1..1] Reaction Observation

(2.16.840.1.113883.3.1818.10.4.23) [CONF:820.1].



(a) SHALL contain exactly one [1..1] Severity Observation

(2.16.840.1.113883.3.1818.10.4.30) [CONF:821.1].


[CONF:822].

(a) SHALL contain exactly one [1..1] @typeCode="SUBJ" subject (CodeSystem:


(b) MAY contain zero or more [0..*] {CDAR2} observation [CONF:824].


ActClass 2.16.840.1.113883.5.6) [CONF:825].




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:




ActClass 2.16.840.1.113883.5.6) [CONF:833].


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

The following XML example outlines how to use the Allergy & Intolerance Observation template:



<entry typeCode=DRIVP" contextConductionInd="true">


Observation-->








<code code="FALG" displayName="Food Allergy"

codeSystem="2.16.840.1.113883.5.4" codeSystemName="HL7 ActCode"/>

<effectiveTime> <low value="20111225"/> </effectiveTime>



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






<templateId root="2.16.840.1.113883.3.1818.10.4.12"/> 


<code code="LIFEOBS" displayName="Lifestage Observation"


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>







Observation -->




Pending"/>

<text>Hospital discharge report</text>

</observation>





<templateId root="2.16.840.1.113883.3.1818.10.4.23"/>

<code code="REACTOBS" displayName="Reaction Observation"


Pending"/>

<text>Severe reaction to peanuts</text>


<value xsi:type="CD" code="417516000" displayName="Anaphylaxis due to

substance" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>




<templateId root="2.16.840.1.113883.3.1818.10.4.30"/> 


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








</observation>






Observation -->


<code code="SEV" displayName="Severity" codeSystem="2.16.840.1.113883.5.4"

codeSystemName="HL7 ActCode" />



</observation>




<entryRelationship typeCode="SUBJ" contextConductionInd="true">


<code code="CLINSTAT" displayName="Allergy Clinical Status"


Pending" />

<text>Confirmed</text>

<value xsi:type="CD" code="C" displayName="Confirmed"


AllergyClinicalStatus"/>

</observation>




<entryRelationship typeCode="SUBJ">


<code code="ALRTDEV" displayName="Allert Device"


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

<templateId root="2.16.840.1.113883.3.1818.10.4.31"/> 



<code code="STSAUDITOBS" displayName="Status Audit Observation"


Pending" />

<text>Allergy report recived from Emergency department confirming

allergy</text>






Participation -->

<time value="20030529"/>





</assignedPerson>

</assignedAuthor>

</author>



<entryRelationship typeCode="RSON" contextConductionInd="true">

<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> 



<code code="REASON" displayName="Reason Observation"


Pending"/>

<text>confirmation received from Hospital</text>


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





Participation -->

<time value="20030529"/>



root="2.16.840.1.113883.3.163.5.0.10.2"/>



</assignedPerson>

</assignedAuthor>

</author>




<templateId root="2.16.840.1.113883.3.1818.10.4.10"/> 


<id nullFlavor="NA"/>

<assignedPerson>

<name>Royal X Hospital</name>

</assignedPerson>

</assignedEntity>

</informant>

</observation>


</observation>


</observation>


</act>

</entry>





Observation-->








<code code="DALG" displayName="Drug Allergy"





<playingEntity classCode="MMAT" determinerCode="INSTANCE">

<code code="108564000" displayName="Ramipril"


<name>Ramipril</name>

</playingEntity>

</participantRole>

</participant>





<code code="ALLGRP" displayName="Allergen Group Code"


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>









Observation -->




Pending"/>

<text>Patient</text>

</observation>

Observation -->




Pending" />

<text>Mild nausea</text>


<value xsi:type="CD" code="422587007" displayName="Nausea"





Observation -->


<code code="M" displayName="Severity" codeSystem="2.16.840.1.113883.5.4"


<value xsi:type="CD" code="A2" displayName="Mild Reaction"


</observation>





</observation>






Observation -->




<value xsi:type="CD" code="A3" displayName="Moderate"


</observation>








<code code="CLINSTAT" displayName="Allergy Clinical Status"


Pending" />

<text>Confirmed</text>

<value xsi:type="CD" code="C" displayName="Confirmed"


AllergyClinicalStatus"/>

</observation>






</observation>


</act>



</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


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



840 @contextConductionInd M:1..1


842 encounter R:1..1



846 Appointment Status Active, Complete, Cancelled Status of the appointment.


845 Appointment Date, Start Time and Length The start time of the appointment and the actual/planned duration.


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



852 participantRole O:0..*


854 Location Identifier Identifier of the point of service location for

id O:0..* II




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.


Participation)

R:0..1

858 Additional Provider Name and ID of medical resident or student working at the office/clinic.


Participation)

R:0..1

859 Delegated Provider Name and ID of the physician who is 'standing-in' for the patient's regular physician.


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


O:0..*

860 Cancellation Note & Date If the appointment is cancelled, the reason for the cancellation including the date of the cancellation.

entryRelationship


O:0..*

An Appointment Observation (Encounter) element:



2) SHALL contain exactly one [1..1] @contextConductionInd [CONF:840].

3) SHALL contain exactly one [1..1] templateId [CONF:841] such that it,


[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,



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:




iii) MAY contain zero or more [0..*] {CDAR2} participantRole [CONF:852].

(1) SHALL contain exactly one [1..1] @classCode="SDLOC" service delivery location


(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,


(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,


(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,


(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,


(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,


(2.16.840.1.113883.3.1818.10.4.3) [CONF:860.1].

The following XML example outlines how to use the Appointment Observation template:


<templateId root="2.16.840.1.113883.3.1818.10.3.4"/> 

<encounter classCode="ENC" moodCode="PRP">


<statusCode code="Active"/>

<effectiveTime>

<low value="201402141230"/>

<high value="201402141300"/>

</effectiveTime>



<participant typeCode="LOC" contextControlCode="OP">

<participantRole classCode="SDLOC">

<addr>



<state>BC</state>



</addr>

</participantRole>

</participant>



<participant typeCode="PPRF">

<participantRole>


<addr></addr>

<telecom value="tel:5555552003" use="WP"/>



</playingEntity>

</participantRole>

</participant>



<participant typeCode="REFB">

<participantRole>


<addr></addr>



<name>Dr. A. de Wit</name>

</playingEntity>

</participantRole>

</participant>



<participant typeCode="IRCP">

<participantRole>

<addr></addr>



<name>J. Doe</name>

<desc>Social Services case manager authorized to receive healthcare

information to support patient's integrated care.</desc>

</playingEntity>

</participantRole>

</participant>




<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> 





Pending"/>

<text> Annual Follow-up; Diabetes control and med renewal;</text>


<value xsi:type="CD" code="170744004" displayName="Follow-up diabetic

assessment" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>




<templateId root="2.16.840.1.113883.3.1818.10.4.38"/> 



</observation>






<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> 




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>


</encounter>

</entry>

Figure 67: Appointment Observation entry example

6.5 BILLING ATTACHMENT


Table 84: Billing Attachment Template Context


Billing [with entries] N/A



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





865 observationMedia 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:






[CONF:864.12].

4) SHALL contain exactly one [1..1] observationMedia [CONF:865].


2.16.840.1.113883.5.6) [CONF:866].


2.16.840.1.113883.5.1001) [CONF:867].


d) SHALL contain exactly one [1..1] value [CONF:869].

The following XML example outlines how to use the Billing Attachment template:


<templateId root="2.16.840.1.113883.3.1818.10.3.5"/> <!-- Billing Attachments --

>





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


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





873 procedure O:0..*



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




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.


880 Intervention Datetime/End Datetime The start date/time (and end date/time, if available) that the Intervention occurred.


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


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


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.



888 encounter M:1..1



891 Follow-up Date The date/time by which follow up diagnostic





services are expected to have been provided.

892 Follow-up Encounter Comments entryRelationship R:0..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:






[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].


2.16.840.1.113883.5.1001) [CONF:875].


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,



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



(2.16.840.1.113883.3.1818.10.4.24) [CONF:882.1].


i) SHALL contain exactly one [1..1] Qualifier Observation

(2.16.840.1.113883.3.1818.10.4.22) [CONF:883.1].



k) SHALL contain zero or more if available [0..*] entryRelationship [CONF:884] such that each,


(2.16.840.1.113883.3.1818.10.4.3) [CONF:884.1].


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



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





ActClass 2.16.840.1.113883.5.6) [CONF:895].


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

The following XML example outlines how to use the Care History Event template:



<procedure classCode="PROC" moodCode="EVN">


<code code="8652-0" displayName="Hospital Discharge History"


<text>Hostpital Admission and Discharge </text>

<statusCode code="complete"/>

<effectiveTime>

<low value="20130213"/>

<high value="20130223"/>

</effectiveTime>


<templateId root="2.16.840.1.113883.3.1818.10.4.29"/> 


<code code="SECCODE" displayName="Secondary Code Unbound"


Pending"/>

<value xsi:type="CD" code="32485007" displayName="Hospital Admission"


</observation>





<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> 

<time value="20130213"/>




<name>Dr. VG Internist</name>

</assignedPerson>

</assignedAuthor>

</author>



Participation -->




<name>Ms. D. Everywoman</name>

</assignedPerson>

</assignedEntity>

</informant>

</observation>





<templateId root="2.16.840.1.113883.3.1818.10.4.22"/> 



<code code="QUALOBS" displayName="Qualifier Observation"


Pending"/>

<text>THIS DOCUMENT HAS BEEN DICTATED BUT NOT READ</text>


<value xsi:type="CD" code="TBD" codeSystem="TBD" codeSystemName="TBD"

displayName="Qualifier Observation code"/>



Participation -->

<time value="20130223"/>





</assignedPerson>

</assignedAuthor>

</author>

</observation>







-->




Pending"/>

<value xsi:type="ST">Admission to Community hospital for chest pain and

transfer to tertiary care facility for angiogram</value>

</observation>





<templateId root="2.16.840.1.113883.3.1818.10.4.18"/> 



<code code="OUTCOBS" displayName="Outcome Observation"


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.


molecular weight heparin, Clopidogrel, and low dose beta blockade.

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


angiography on the 13th of February. </text>




Participation -->

<time value="20130223"/>





</assignedPerson>

</assignedAuthor>

</author>









Pending" />

<text>Keywords: Hospital Discharge</text>


<value xsi:type="ST">Hospital Discharge Summary</value>






Data -->



<value mediaType="application/pdf">


CCD.pdf"/>

</value>



</observationMedia>


</observation>


</observation>





<encounter classCode="ENC" moodCode="APT">



<code code="NXTENCREAS" displayName="Next Encounter Reason"


Pending" />

<text>Follow-up Encounter comments or instructions (e.g. reason for follow-

up).</text>

</observation>


</encounter>


</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


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




1132 templateId R:1..1 II

1133 organizer O:0..*



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





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






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.


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:




3) SHALL contain exactly one (or a nullFlavor value) [1..1] templateId [CONF:1132] such that it,


[CONF:1132.12].



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


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,


(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].



ii) SHALL contain exactly one [1..1] @contextConductionInd [CONF:1143].

iii) MAY contain zero or more [0..*] {CDAR2} observation [CONF:1144].


ActClass 2.16.840.1.113883.5.6) [CONF:1145].


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



(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].

The following XML example outlines how to use the Clinically Measured Observations Organizer

template:


<templateId root="2.16.840.1.113883.3.1818.10.3.7"/> 

<time value="20030529"/>





</assignedPerson>

</assignedAuthor>

</author>



Participation -->



<assignedPerson>


</assignedPerson>

</assignedEntity>

</informant>





displayName="Systolic Blood Pressure"/>


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





displayName="Diastolic Blood Pressure"/>


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

displayName="Height"/>


<value xsi:type="PQ" value="190" unit="cm"/>

</observation>

</component>




displayName="Weight"/>


<value xsi:type="PQ" value="48" unit="kg"/>

</observation>

</component>




codeSystemName="LOINC" displayName="Waist Circumference by NCFS"/>

<text>Waist circumference</text>


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



</organizer>

</entry>

Figure 70: Clinically Measured Observations Organizer entry example

6.8 DEVELOPMENTAL OBSERVATIONS ORGANIZER


Table 90: Developmental Observations Organizer Template Context


Developmental Observations [with entries] Author 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










id R:0..1 II


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.



author (Author

Participation)

R:0..1



Participation)

O:0..*








id R:1..1 II


code R:1..1 CD


text R:0..1 ED




value R:1..* ANY








A Developmental Observations Organizer (Organizer) element:






[CONF:1156.12].



2.16.840.1.113883.5.6) [CONF:1158].


2.16.840.1.113883.5.1001) [CONF:1159].







(2.16.840.1.113883.3.1818.10.4.2) [CONF:1163.1].



(2.16.840.1.113883.3.1818.10.4.10) [CONF:1164.1].







ActClass 2.16.840.1.113883.5.6) [CONF:1169].


2.16.840.1.113883.5.1001) [CONF:1170].



selected from ValueSet Developmental Observations Codes 2.16.840.1.113883.3.1818.10.8.6 STATIC [CONF:1172].











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


Table 92: Device Observation Template Context


Devices [with entries] Author 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








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.


909 Device Author The author of the device record.

author (Author

Participation)

R:1..1




910 Device Informant the person who provided the information that the pateint is using the device.


Participation)

R:0..1

A Device Observation (Observation) element:






[CONF:901.12].

4) SHALL contain exactly one [1..1] observation [CONF:902].


2.16.840.1.113883.5.6) [CONF:903].


2.16.840.1.113883.5.1001) [CONF:904].


d) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} code="DEVOBS" Device



f) SHALL contain exactly one (or a nullFlavor value) [1..1] effectiveTime [CONF:908] such

that it,



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,


(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,


(2.16.840.1.113883.3.1818.10.4.10) [CONF:910.1].

The following XML example outlines how to use the Device Observation template:



<entry typeCode=DRIV" contextConductionInd="true">




<code code="DEVOBS" displayName="Device Observation"


Pending"/>

<text>Total hip replacement prosthesis was implanted in 1998</text>

<statusCode code="completed"/>


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



-->

<time value="20030529"/>





</assignedPerson>

</assignedAuthor>

</author>



Participation -->




<name>Cloe Everywoman</name>

</assignedPerson>

</assignedEntity>

</informant>

</observation>

</entry>









Pending"/>

<text>Cardiac Pacemaker</text>



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



-->

<time value="20030529"/>

</assignedPerson>

</assignedAuthor>

</author>



Participation -->




<name>Cloe Everywoman</name>

</assignedPerson>

</assignedEntity>

</informant>

</observation>

</entry>









Pending"/>

<text>Cardiac Pacemaker</text>



<value xsi:type="CD" code="2282003" displayName="Breast prosthesis, device"




Participation -->

<time value="20030529"/>





</assignedPerson>

</assignedAuthor>

</author>



Participation -->




<name>Patient</name>

</assignedPerson>

</assignedEntity>

</informant>

</observation>

</entry>

Figure 72: Device Observation entry example



6.10 ENCOUNTER EVENT

[Encounter: templateId 2.16.840.1.113883.3.1818.10.3.9(open)]

Table 94: Encounter Event Template Context


Encounter History & Notes [with entries] Attachment

Author Participation

Comment Observation

Date Observation


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.



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





914 encounter O:0..*



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




ambulatory, emergency, home health)

918 Encounter Start and End Date/Time Start and End date/time of the encounter.


919 Encounter Location Location of the encounter.

participant R:1..1





924 Location identifier id R:0..1 II

925 Encounter Provider ID and Name of provider responsible for the encounter.


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




4446 Non-Provider Participant Role @classCode 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


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.




1653 Next Encounter Reason observation O:0..*







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


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:






[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].


2.16.840.1.113883.5.1001) [CONF:916].


d) MAY contain zero or one [0..1] {CDAR2} code [CONF:4441].



e) SHALL contain exactly one [1..1] effectiveTime [CONF:918] such that it,




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:





(1) SHALL contain exactly one [1..1] @classCode="ROL" (CodeSystem: RoleClass

2.16.840.1.113883.5.110) [CONF:923].


g) SHALL contain one or more (or a nullFlavor value) [1..*] participant [CONF:925] such that

each,


(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].





RoleClass 2.16.840.1.113883.1.11.11555 STATIC [CONF:4446].

(2) MAY contain zero or one [0..1] {CDAR2} playingEntity [CONF:4447].





(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,


(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,


(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:





ActClass 2.16.840.1.113883.5.6) [CONF:1654].


2.16.840.1.113883.5.1001) [CONF:1655].




(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].



(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,


(2.16.840.1.113883.3.1818.10.4.3) [CONF:929.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].

The following XML example outlines how to use the Encounter Event template:


<templateId root="2.16.840.1.113883.3.1818.10.3.9"/> 

<encounter classCode="ENC" moodCode="EVN">

<id extension="12366" root="2.16.840.1.113883.3.1818.10.2.10.12" use="BUS"/>







</participantRole>

</participant>



<participant typeCode="PRF" contextControlCode="OP">

<templateId root="2.16.840.1.113883.3.1818.10.4.21"/> 

<participantRole>



<name>


<given>Encounter</given>

<family>Provider</family>

</name>

<desc>On-call attending provider.</desc>

</playingEntity>

</participantRole>

</participant>





-->




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>






<templateId root="2.16.840.1.113883.3.1818.10.4.4"/> 




Pending"/>

<effectiveTime>

<low value="201212201400"/>

<high value="201212201430"/>

</effectiveTime>

</observation>

<code code="NXTENCREAS" displayName="Next Encounter Reason"


Pending" />

<text>General Medical Examination</text>



CT"/>





Participation -->

<time value="20030529"/>





</assignedPerson>

</assignedAuthor>

</author>





Participation -->



<assignedPerson>


</assignedPerson>

</assignedEntity>

</informant>




<templateId root="2.16.840.1.113883.3.1818.10.4.38"/> 




-->




Pending"/>

<value xsi:type="ST">This is the Encounter Note comment</value>

</observation>









Pending" />

<text>Keywords: GME</text>


<value xsi:type="ST">General Medical Examination Report</value>





<templateId root="2.16.840.1.113883.3.1818.10.4.9"/> 





claim1.pdf"/>

</value>


</observationMedia>


</observation>





<templateId root="2.16.840.1.113883.3.1818.10.4.38"/> 



root="2.16.840.1.113883.3.1818.10.10.3"/>

<code code="RECLINK" displayName="Attachment Observation"


Pending" />

</act>


</encounter>

</entry>

Figure 73: Encounter Event entry example

6.11 FAMILY HISTORY OBSERVATION


Table 97: Family History Observation Template Context


Family History [with entries] Comment Observation


Secondary Code (ICD-9)



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



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.


<templateId root="2.16.840.1.113883.3.1818.10.4.28"/>


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


Or


<templateId root="2.16.840.1.113883.3.1818.10.4.28"/>



codeSystem="2.16.840.1.113883.3.3068.10.6.3"


<value xsi:type="CD" nullFlavor="UNK"/>

</observation>


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.



<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









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.


1664 Diagnosis Code The SNOMED code associated with the Diagnosis/Problem.

value M:1..1 ANY

942 Family Member relationship subject R:1..1


944 relatedSubject O:0..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..*







1672 Treatment Comment Code code R:1..1 CD

1673 Free Text Comment text R:1..1 ED




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


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


O:0..1

951 Age At Onset entryRelationship O:0..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





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





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:






[CONF:934.12].





2.16.840.1.113883.5.6) [CONF:936].


2.16.840.1.113883.5.1001) [CONF:937].



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


that it,




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


(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:





ActClass 2.16.840.1.113883.5.6) [CONF:1669].


2.16.840.1.113883.5.1001) [CONF:1670].


(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].


(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,


(2.16.840.1.113883.3.1818.10.4.3) [CONF:948.1].



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





ActClass 2.16.840.1.113883.5.6) [CONF:954].


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





ActClass 2.16.840.1.113883.5.6) [CONF:961].


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


o) MAY contain zero or one [0..1] entryRelationship [CONF:965].





ActClass 2.16.840.1.113883.5.6) [CONF:968].


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


The following XML example outlines how to use the Family History Observation template:


<templateId root="2.16.840.1.113883.3.1818.10.3.10"/> 



<code code="DX" displayName="Diagnosis" codeSystem="2.16.840.1.113883.5.4"

codeSystemName="Act Code"/>

<text>Family history of cancer of colon</text>



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



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






-->




Pending"/>

<text>Mom was diagnosed with metastatic cancer of colon and died at age

55.</text>

</observation>






(ICD9) -->




Pending"/>

<value xsi:type="CD" code="BIN" codeSystem="2.16.840.1.113883.6.42"


</observation>





<templateId root="2.16.840.1.113883.3.1818.10.4.12"/> 




Pending"/>

</observation>








<code code="30972-4" displayName="Age at onset"


<value xsi:type="INT" value="54"/>

</observation>







codeSystemName="LOINC" displayName="Age at Death"/>


</observation>







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>







<code code="TRTNOTE" displayName="Treatment Note"


Pending"/>

<text>Infared radiation therapy attempted in December 2009 and was not

successful.</text>


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


</observation>

</entry>

Figure 77: Family History Observation entry example

6.12 IMMUNIZATION OBSERVATION


Table 99: Immunization Observation Template Context


Immunizations List [with entries] Author Participation

Comment Observation




Date Observation

Location Participation


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.



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





975 substanceAdministration O:0..*



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




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


988 manufacturedProduct R:1..1


990 manufacturedMaterial R: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.









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


1006

substanceAdministration

O:0..*



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


1013 manufacturedProduct R:1..1


1015

manufacturedMaterial

R: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


R:0..1




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.


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


R:0..1

1025 Reaction Patient medical reaction to the immunization administration.

entryRelationship


R:0..*

An Immunization Observation (Observation) element:






[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].


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,


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:


ii) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} manufacturedProduct

[CONF:988].



(1) SHALL contain exactly one [1..1] @classCode="MANU" manufactured product


(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


(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].


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





ActClass 2.16.840.1.113883.5.6) [CONF:1000].


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



(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].


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


2. SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2}

manufacturedProduct [CONF:1013].



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}


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


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,


(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,


(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,


(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,


(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].

The following XML example outlines how to use the Immunization Observation template:


<templateId root="2.16.840.1.113883.3.1818.10.3.11"/> 

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




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



<administrationUnitCode code="DROP" displayName="Drops"

codeSystem="2.16.840.1.113883.5.85" codeSystemName="AdministerableDrugForm"/>



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





-->

<time value="20030529"/>





</assignedPerson>

</assignedAuthor>

</author>




<templateId root="2.16.840.1.113883.3.1818.10.4.13"/> 


<playingEntity>

<name>Walk In Clinic</name>

</playingEntity>

</participantRole>

</participant>

Drug -->

<code code="SECDRUGCODE" displayName="Secondary Drug Code"


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>





<substanceAdministration classCode="SBADM" moodCode="EVN">

<code code="ANTIGEN" codeSystem="2.16.840.1.113883.5.4"

displayName="Anitgen"/>

<repeatNumber value="2"/>




<code code="61153008" displayName="Measles + Mumps + Rubella vaccine "


<name>Measles, Mumps, Rubella</name>



</consumable>

</substanceAdministration>






<code code="REPIND" displayName="Reported Indicator"


Pending" />

<value xsi:type="BL" value="false"/>

</observation>






-->




Pending" />

<text>Patient potentially exposed. </text>



CT"/>

</observation>

Pending"/>

<effectiveTime>

<low value="200311"/>

<high value="200411"/>

</effectiveTime>

</observation>







-->




Pending"/>

<value xsi:type="ST">This is the administration comment. Patient

bites!</value>

</observation>






Observation -->




Pending"/>

<text>Sweating Fever</text>


<value xsi:type="CD" code="186694006" displayName="Sweating fever"





Observation -->




<value xsi:type="CD" code="A2" displayName="Mild Reaction"


</observation>





</observation>



</entry>

Figure 78: Immunization Observation entry example

6.13 LABORATORY OBSERVATION


Table 101: Laboratory Observation Template Context


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



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

http://loinc.org/



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




1028 observation R: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


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:





[CONF:1027.12].

http://loinc.org/adopters/canada-health-infoway-inc-inforoute-sante-du-canada-inc.html/

http://loinc.org/adopters/canada-health-infoway-inc-inforoute-sante-du-canada-inc.html/



3) SHALL contain one or more (or a nullFlavor value) [1..*] observation [CONF:1028].


2.16.840.1.113883.5.6) [CONF:4352].


2.16.840.1.113883.5.1001) [CONF:4353].


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,


(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,


(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].

The following XML example outlines how to use the Laboratory Observation template:


<templateId root="2.16.840.1.113883.3.1818.10.2.16.1"/> 



<code code="18723-7" displayName="Hematology Studies"


<text>Hematology Series</text>





Participation -->

<time value="20030529"/>





</assignedPerson>

</assignedAuthor>

</author>





-->




Pending"/>

<value xsi:type="ST">Relevant Clinical Information Comment is inserted

here</value>

</observation>





<templateId root="2.16.840.1.113883.3.1818.10.4.26"/> 



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



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

<performer typeCode="PRF">

<templateId root="2.16.840.1.113883.3.1818.10.4.19"/> 

<time value="201111111111"/>

<assignedEntity>

<id extension="123" root="2.16.840.1.113883.3.40.2.11"

assigningAuthorityName="BCMOH"/>


<name>


<family>Laboratory</family>

<given>Performer</given>

</name>

</assignedPerson>


<id extension="TBD" root="TBD"/>

<name>Performing Organization Name</name>


</assignedEntity>

</performer>







<text>No problem with specimen collection</text>




</procedure>







Observation -->




Pending"/>

<value xsi:type="ST">Result Note comment inserted heret</value>

</observation>










Pending"/>

<text>Keywords: Abnormal Laboratory Result Chicken-Pox Confirmed</text>


<value xsi:type="ST">Chicken Pox Alert</value>






Data -->







claim1.pdf"/>

</value>


</observationMedia>


</observation>


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


<code code="H" displayName="High"

codeSystem="2.16.840.1.113883.1.11.10206"


<text>High Reference range is between 5 and 10</text>


<low value="10.81"/>


</value>

</observationRange>


<code code="HH" displayName="Very High"

codeSystem="2.16.840.1.113883.1.11.10206"


<text>Very High Reference range is between 5 and 10</text>



</value>

</observationRange>

</referenceRange>

</observation>

</component>

</organizer>


</observation>

</entry>

Figure 80: Laboratory Observation entry example

6.14 MEDICAL IMAGING OBSERVATION


Table 103: Medical Imaging Observation Template Context




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








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




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.


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


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





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.


1057 Image Detail Author author (Author

Participation)

R:0..1

A Medical Imaging Observation (Observation) element:






[CONF:1037.12].





2.16.840.1.113883.5.6) [CONF:1039].


2.16.840.1.113883.5.1001) [CONF:1040].


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,


(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,


[CONF:1046.1].

i) SHALL contain zero or more if available [0..*] entryRelationship [CONF:1047].





ActClass 2.16.840.1.113883.5.6) [CONF:1050].


2.16.840.1.113883.5.1001) [CONF:1051].


(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].


(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].

The following XML example outlines how to use the Medical Imaging Observation template:


<templateId root="2.16.840.1.113883.3.1818.10.3.13"/> 



<code code="10144323" displayName="Plain chest X-ray "


<text>Chest x-ray</text>





<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> 



</observation>










Pending" />

<text>Keywords: chest x-ray</text>


<value xsi:type="ST">Chest x-Ray image</value>






with ID for renderMultiMedia above-->

<observationMedia classCode="OBS" moodCode="EVN" ID="M11">


<value mediaType="application/png">


xray.png"/>

</value>


</observationMedia>


</observation>

<code code="59776-5" displayName="Procedure Findings"

codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" />

<text>Nothing unusual could be observed.</text>


<value xsi:type="CD" code="272519000" displayName="Absense findings"






Participation -->

<time value="20030529"/>




<name>Dr. Raymond Xpert</name>

</assignedPerson>

</assignedAuthor>

</author>

</observation>


</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


Current Medications [with entries] Comment Observation


Date Observation


Medication Prescription Event


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.



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.



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.



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





1473 Medication Record substanceAdministration O:0..*



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.


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


Observation)

R:0..1

1481 Reason / Indication The reasons or indications for the Medication Event.

entryRelationship


R:0..*

1482 Reaction The reaction that that patient had to the medication.

entryRelationship


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


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




for the Drug identified in the Medication List Record.

Event)

A Medication Event (Substance Administration) element:






[CONF:1472.12].



ActClass 2.16.840.1.113883.5.6) [CONF:1474].


2.16.840.1.113883.5.1001) [CONF:1475].


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



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,


(2.16.840.1.113883.3.1818.10.4.4) [CONF:1480.1].



(2.16.840.1.113883.3.1818.10.4.24) [CONF:1481.1].


i) SHALL contain exactly one [1..1] Reaction Observation

(2.16.840.1.113883.3.1818.10.4.23) [CONF:1482.1].



(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].


i) SHALL contain exactly one [1..1] Medication Prescription Event

(2.16.840.1.113883.3.1818.10.4.20) [CONF:1485.1].

The following XML example outlines how to use the Medication Event template:






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





<templateId root="2.16.840.1.113883.3.1818.10.4.16"/> 


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


</consumable>




<templateId root="2.16.840.1.113883.3.1818.10.4.32"/> 







Pending"/>


</observation>

<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> 


<templateId root="2.16.840.1.113883.3.1818.10.4.2"/>

<time value="20030529"/>





</assignedPerson>

</assignedAuthor>

</author>

</observation>








<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> 






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






Identification-->

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



<e2e:quantity value="0.4" unit="mg"/>


<e2e:code code="TBD" displayName="Nitro" codeSystem="tbd"

codeSystemName="ClinicalDrug"/>

<e2e:name> NITROGLYCERIN </e2e:name>

</e2e:ingredient>

</e2e:ingredient>



</consumable>




<templateId root="2.16.840.1.113883.3.1818.10.4.32"/> 







Pending"/>


</observation>





<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> 



Participation -->

<time value="20030529"/>

</assignedPerson>

</assignedAuthor>

</author>

</observation>








<templateId root="2.16.840.1.113883.3.1818.10.4.3"/> 


<templateId root="2.16.840.1.113883.3.1818.10.4.20" /> 

<substanceAdministration classCode="SBADM" moodCode="RQO">


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



<effectiveTime xsi:type="IVL_TS" operator="I">

<low value="20130211"/>

<high value="20130212"/>

</effectiveTime>



Identification-->



<code code="02243588" displayName="MYLAN-NITRO SUBLINGUAL

SPRAY" codeSystem="2.16.840.1.113883.5.1105" codeSystemName="hc-DIN"/>


<e2e:desc>NITROGLYCERIN 0.4 mg/dose SPRAY, NON-AEROSOL

(GRAM)</e2e:desc>





<e2e:ingredient classCode="MMAT"

determinerCode="KIND">

<e2e:code code="TBD" displayName="Nitro"

codeSystem="tbd" codeSystemName="ClinicalDrug"/>


</e2e:ingredient>

</e2e:ingredient>

</consumable>





Participation -->

<time value="20030529"/>



root="2.16.840.1.113883.3.163.5.0.10.2"/>



</assignedPerson>

</assignedAuthor>

</author>




<templateId root="2.16.840.1.113883.3.1818.10.4.8"/> 




<text>Take 2 tablets for 10 days</text>



<effectiveTime xsi:type="IVL_TS" operator="I">

<width value="10" unit="D"/>

</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>

</doseQuantity>



<administrationUnitCode code="ORSPRAY" displayName="oral spray"

codeSystem="2.16.840.1.113883.1.11.14570" codeSystemName="AdministerableDrugForm"/>


<templateId root="2.16.840.1.113883.3.1818.10.4.16"/> 



<code code="02243588" displayName="MYLAN-NITRO

SUBLINGUAL SPRAY" codeSystem="2.16.840.1.113883.5.1105" codeSystemName="hc-DIN"/>


<e2e:desc>NITROGLYCERIN 0.4 mg/dose SPRAY,

NON-AEROSOL (GRAM)</e2e:desc>





<e2e:ingredient classCode="MMAT"


<e2e:code code="TBD"

displayName="Nitro" codeSystem="tbd" codeSystemName="ClinicalDrug"/>

<e2e:name> NITROGLYCERIN

</e2e:name>

</e2e:ingredient>

</e2e:ingredient>



</consumable>






<templateId root="2.16.840.1.113883.3.1818.10.4.24"/> 


<id extension="12779999"

root="2.16.840.1.113883.3.1818.10.2.10.16"/>



Pending"/>

</observation>






Observation -->





Pending"/>

<text>Stop administration of spray if patient experiences problems

swollowing.</text>


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





<templateId root="2.16.840.1.113883.3.1818.10.4.37"/> 


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





<templateId root="2.16.840.1.113883.3.1818.10.4.37"/> 


<code code="ADPIND" codeSystem="2.16.840.1.113883.3.3068.10.6.3"

codeSystemName="ObservationType-CA-Pending" displayName="Adapt Not Allowed

Indicator"/>


</observation>





<templateId root="2.16.840.1.113883.3.1818.10.4.37"/> 


<code code="SUBIND" codeSystem="2.16.840.1.113883.3.3068.10.6.3"

codeSystemName="ObservationType-CA-Pending" displayName="Substitute Not Allowed

Indicator"/>


</observation>





<templateId root="2.16.840.1.113883.3.1818.10.4.14"/> 

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


<templateId root="2.16.840.1.113883.3.1818.10.4.11"/>

<code code="FILLINT"


Pending" displayName="Fill Interval"/>

<text>5 per day</text>

<value xsi:type="PQ" value="5" unit="d"/>

</observation>


</supply>





<templateId root="2.16.840.1.113883.3.1818.10.4.14"/> 


<code code="FF" codeSystem="2.16.840.1.113883.5.4"

displayName="Partial First Fill" codeSystemName="Hl7 Act Code"/>


<expectedUseTime>


</expectedUseTime>


<templateId root="2.16.840.1.113883.3.1818.10.4.11"/> 



Request (Refills)-->


<code code="RF" codeSystem="2.16.840.1.113883.5.4"

displayName="Refills" codeSystemName="Hl7 Act Code"/>



<templateId root="2.16.840.1.113883.3.1818.10.4.11"/>

<entryRelationship typeCode="SUBJ" inversionInd="true">


<templateId root="2.16.840.1.113883.3.1818.10.4.35"/> 

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






<templateId root="2.16.840.1.113883.3.1818.10.4.35"/> 



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


<participantRole classCode="PAT"/>

</participant>

</observation>





<templateId root="2.16.840.1.113883.3.1818.10.4.7"/> 

<supply classCode="SPLY" moodCode="EVN">


root="2.16.840.1.113883.3.1818.10.10.3"/>







<product typeCode="PRD">


<manufacturedLabeledDrug classCode="MMAT"


<code code="02243588" displayName="MYLAN-NITRO

SUBLINGUAL SPRAY" codeSystem="2.16.840.1.113883.5.1105" codeSystemName="hcDIN"/>



</product>




<templateId root="2.16.840.1.113883.3.1818.10.4.19"/>

<time value="20130211"/>



root="2.16.840.1.113883.3.163.5.0.10.2"/>

<code code="180000000X" displayName="Pharmacy"


<assignedPerson classCode="PSN"

determinerCode="INSTANCE">

<name use="L">Mr. P. Scriber</name>

</assignedPerson>


<name>Mainstreet Pharmacy</name>


</assignedEntity>

</performer>




<templateId root="2.16.840.1.113883.3.1818.10.4.11"/> 

<entryRelationship typeCode="SAS" contextConductionInd="true">

<templateId root="2.16.840.1.113883.3.1818.10.4.36"/> 



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




<routeCode></routeCode>

<approachSiteCode></approachSiteCode>

<doseQuantity></doseQuantity>





<manufacturedMaterial classCode="MMAT"


<lotNumberText>123</lotNumberText>



</consumable>




<templateId

root="2.16.840.1.113883.3.1818.10.4.2"/>

<time value="20030529"/>



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>




<templateId

root="2.16.840.1.113883.3.1818.10.4.13"/> 


<playingEntity>


</playingEntity>

</participantRole>

</participant>



<entryRelationship typeCode="SUBJ"

contextConductionInd="true" inversionInd="true">

<templateId

root="2.16.840.1.113883.3.1818.10.4.3"/> 


<code code="COMMENT"

displayName="Comment Observation" codeSystem="2.16.840.1.113883.3.3068.10.6.3"


<value xsi:type="ST">Hypotension due to

administration for ACS.</value>

</observation>




</supply>





</entry>”

Figure 83: Medication Event entry example

6.16 ORDER EVENT


Table 108: Order Event Template Context


Orders & Requests [with entries] Author Participation




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



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









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.


1068 Order Status The status of the order (e.g. Complete).


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.






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




The Reason or indication for the Order. (Reason Observation)

1078 Order Comments Comments or supporting information relevant to the order.

entryRelationship


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:






[CONF:1060.12].



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




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





ActClass 2.16.840.1.113883.5.6) [CONF:1073].


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






(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,


(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,


(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].

The following XML example outlines how to use the Order Event template:


<templateId root="2.16.840.1.113883.3.1818.10.3.14"/> 



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


<priorityCode code="Routine"/>





Participation-->

<time value="201111111111"/>

<assignedEntity>




<name>


<family>G.</family>

<given>Astro</given>

</name>

</assignedPerson>





</assignedEntity>

</performer>





-->

<time value="20030529"/>





</assignedPerson>

</assignedAuthor>

</author>





<code code="ORDPRYNT" displayName="Order Priority Note"


Pending"/>

<text>Routine screening should be scheduled before March 15th to allow for

results prior to next GP appointment. </text>

</observation>

-->





Pending"/>

<text>Screening colonoscopy. Family history of cancer of colon, 312824007,

SNOMED CT</text>


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







-->




Pending"/>

<value xsi:type="ST">You have seen this lady 5 years ago. She had clear

colonoscopy then. Due again.</value>

</observation>










</observation>

</entry>

Figure 84: Order Event entry example

6.17 PROBLEM LIST OBSERVATION


Table 110: Problem List Observation Template Context


Medical History [with entries] Author Participation

Problems & Conditions - Problem List [with entries] Comment Observation

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



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.





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.


<templateId root="2.16.840.1.113883.3.1818.10.4.28"/>



codeSystem="2.16.840.1.113883.3.3068.10.6.3"




</observation>


Or


<templateId root="2.16.840.1.113883.3.1818.10.4.28"/>



codeSystem="2.16.840.1.113883.3.3068.10.6.3"


<value xsi:type="CD" nullFlavor="UNK"/>

</observation>


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”



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.



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





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.


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.


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.


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


O:0..*




1096 Symptoms Coded or free text list of symptoms as documented by the provider.






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


O:0..1

1099 Problem Outcome The coded outcome of the effect that the diagnosed disease has on the patient.

entryRelationship O:0..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:






[CONF:1085.12].


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,



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,



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,


g) SHALL contain exactly one [1..1] author [CONF:1092] such that it,


(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,


(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,


(2.16.840.1.113883.3.1818.10.4.3) [CONF:1095.1].

k) MAY contain zero or more [0..*] entryRelationship [CONF:1096].





ActClass 2.16.840.1.113883.5.6) [CONF:4357].


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



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





ActClass 2.16.840.1.113883.5.6) [CONF:1102].


2.16.840.1.113883.5.1001) [CONF:1103].

(3) SHALL contain exactly one [1..1] code [CONF:1104].

The following XML example outlines how to use the Problem List Observation template:



Observation -->



<code code="ASSERTION" displayName="Assertion"


<text>Patient has ongoing history of hypertension that has been medicated and

under observation.</text>


<effectiveTime xsi:type="IVL_TS">

<low value="20010814"/>

</effectiveTime>







-->

<time value="20030529"/>





</assignedPerson>

</assignedAuthor>

</author>




(ICD9) -->




Pending"/>



</observation>










Pending"/>


</observation>







-->

Pending"/>

<value xsi:type="ST">BP generally a bit high despite meds.</value>

</observation>







<code code="SYMPTOMOBS" displayName="Symptom Observation"


Pending"/>

<value xsi:type="ST">Systolic BP high</value>

</observation>






<templateId root="2.16.840.1.113883.3.1818.10.4.32"/> 




Pending"/>

<value xsi:type="ST">Moderate severity</value>

</observation>





<templateId root="2.16.840.1.113883.3.1818.10.4.12"/> 




Pending"/>



</observation>




<entryRelationship typeCode="CAUS">


<code code="OUTCOME" displayName="Outcome Observation"


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>


</observation>

</entry>

Figure 88: Problem List Observation entry example



6.18 REPRODUCTIVE OBSERVATIONS ORGANIZER


Table 112: Reproductive Observations Organizer Template Context


Reproductive Observations [with entries] Author 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









id R:0..1 II


code R:1..1 CD




author (Author

Participation)

R:0..1



Participation)

O:0..*







1195 Individual Observation Identifier id R:1..1 II




Unique and persistent identifier for the observation record.


code R:1..1 CD


text R:0..1 ED




value R:1..* ANY





A Reproductive Observations Organizer (Organizer) element:






[CONF:1180.12].



2.16.840.1.113883.5.6) [CONF:1182].


2.16.840.1.113883.5.1001) [CONF:1183].


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







(2.16.840.1.113883.3.1818.10.4.2) [CONF:1187.1].



(2.16.840.1.113883.3.1818.10.4.10) [CONF:1188.1].







ActClass 2.16.840.1.113883.5.6) [CONF:1193].


2.16.840.1.113883.5.1001) [CONF:1194].



selected from ValueSet Reproductive Observations Codes 2.16.840.1.113883.3.1818.10.8.7 STATIC [CONF:1196].









The following XML example outlines how to use the Reproductive Observations Organizer template:


<templateId root="2.16.840.1.113883.3.1818.10.3.16"/> 

<time value="20030529"/>





</assignedPerson>

</assignedAuthor>

</author>





Participation -->



<assignedPerson>

<name>Mrs. Everybody</name>

</assignedPerson>

</assignedEntity>

</informant>





codeSystemName="LOINC" displayName="Gravida"/>

<text>Gravida</text>


</observation>

</component>





codeSystemName="LOINC" displayName="Term"/>

<text>Term</text>


</observation>

</component>





codeSystemName="LOINC" displayName="Preterm"/>

<text>Preterm</text>



</observation>

</component>





codeSystemName="LOINC" displayName="Spontaneous Abortions"/>

<text>Spontaneous Abortions</text>


</observation>

</component>





codeSystemName="LOINC" displayName="Induced Termination"/>

<text>Induced Termination</text>


</observation>

</component>





codeSystemName="LOINC" displayName="Births still living"/>

<text>Births still living</text>


</observation>

</component>





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


Table 114: Risk Factors Organizer Template Context


Risk Factors [with entries] Author 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



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









id R:0..1 II


code R:1..1 CD




author (Author

Participation)

R:0..1



Participation)

O:0..*








id R:1..1 II

1124 Risk Factors Observation code Code identifying the individual observation being communicated.

code R:1..1 CD


text R:0..1 ED

1126 Observation Date/Time Date (and optional time) that the observation





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





A Risk Factors Organizer (Organizer) element:






[CONF:1108.12].



2.16.840.1.113883.5.6) [CONF:1110].


2.16.840.1.113883.5.1001) [CONF:1111].







(2.16.840.1.113883.3.1818.10.4.2) [CONF:1115.1].



(2.16.840.1.113883.3.1818.10.4.10) [CONF:1116.1].







ActClass 2.16.840.1.113883.5.6) [CONF:1121].


2.16.840.1.113883.5.1001) [CONF:1122].




(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].









The following XML example outlines how to use the Risk Factors Organizer template:


<templateId root="2.16.840.1.113883.3.1818.10.3.17"/> 



<code code="80943009" displayName="Risk factor (observable entity)"





-->

<time value="20030529"/>





</assignedPerson>

</assignedAuthor>

</author>





Participation -->



<assignedPerson>

<name>Mrs. Everybody</name>

</assignedPerson>

</assignedEntity>

</informant>




<code code="77176002" displayName="Smoker (finding)"


<text>Smoking 2 pack per day since 1996</text>


</observation>

</component>




<code code="228277002" displayName="Light Drinker"


<text>1-2 drinks per week</text>


</observation>

</component>

</organizer>

</entry>

Figure 90: Risk Factors Organizer entry example



6.20 UNCLASSIFIED DOCUMENTS ORGANIZER


Table 116: Unclassified Documents Organizer Template Context


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





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.


4467 Organizer Effective Date The effective date/time of the group of unclassified documents


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:




[CONF:4460.12].


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



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,


[CONF:4468.1].

The following XML example outlines how to use the Unclassified Documents Organizer template:



<templateId root="2.16.840.1.113883.3.1818.10.2.26.1"/>


displayName="Text-Miscellaneous Section"/>

<title>Unclassified Documents [with entries] [PITO]</title>

<text>

</text>


<templateId root="2.16.840.1.113883.3.1818.10.3.27.1"/> 


<code nullFlavor="NI" displayName="2012 historical documents"/>

<statusCode code="Complete"/>

<effectiveTime>

<low value="20120101"/>

<high value="20121231"/>

</effectiveTime>

<component>







Pending" />

<text>Keywords: GME</text>


<value xsi:type="ST">General Medical Examination Report</value>






-->





claim1.pdf"/>

</value>


</observationMedia>


</observation>

</component>

</organizer>

</entry>

</section>

</component>

Figure 91: Unclassified Documents Organizer entry example



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


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


Table 118: Attachment Template Context


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



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









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.


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


O:0..*

1214 Date Attachment Reviewed Date attachment was reviewed by a doctor.


Observation)

R:0..1

1215 Attachment Encapsulated Data entryRelationship

(Encapsulated Data)

O:0..*

An Attachment (Observation) element:






[CONF:1204.12].

4) SHALL contain exactly one [1..1] observation [CONF:1205].




2.16.840.1.113883.5.6) [CONF:1206].


2.16.840.1.113883.5.1001) [CONF:1207].


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


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



(2.16.840.1.113883.3.1818.10.4.3) [CONF:1213.1].



(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].

The following XML example outlines how to use the Attachment template:







Pending"/>

<text>Keywords: DNR 4, full resucitation</text>



<value xsi:type="ST">Resucitation Order</value>






Observation -->




Pending"/>

<value xsi:type="ST">Attachment Note included here</value>

</observation>







Observation -->




Pending"/>


</observation>





Data -->





claim1.pdf"/>

</value>


<templateId root="2.16.840.1.113883.3.1818.10.4.2"/>

<time value="20030529"/>



root="2.16.840.1.113883.3.163.5.0.10.2"/>



</assignedPerson>

</assignedAuthor>



</author>

</observationMedia>


</observation>


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


Appointment Observation N/A


Comment Observation

Developmental Observations Organizer

Device Observation

Encapsulated Data

Encounter Event

Immunization Observation

Laboratory Observation




Order Event

Outcome Observation

Problem List Observation

Qualifier Observation


Reason Observation

Reproductive Observations Organizer

Risk Factors Organizer


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








1229 Authored Date/Time The date/time at which the authoring activity occurred.

time R:1..1 TS

1230 assignedAuthor M:1..1


1232 Author Identifier id R:1..1 II




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



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




[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].



ii) SHALL contain exactly one [1..1] @determinerCode="INSTANCE" instance (CodeSystem:


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


d) MAY contain zero or more [0..*] {CDAR2} representedOrganization [CONF:1237].

i) SHALL contain exactly one [1..1] @classCode="ORG" organization (CodeSystem:




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:



Participation -->

<time value="20030529"/>



root="2.16.840.1.113883.3.163.5.0.10.2"/>



</assignedPerson>



root="2.16.840.1.113883.3.163.5.0.10.2"/>



</assignedAuthor>

</author>

Figure 93: Author Participation entry example

7.3 COMMENT OBSERVATION


Table 122: Comment Observation Template Context


Advanced Directives Observation Author Participation

Alert Observation

Allergy & Intolerance Observation

Appointment Observation

Attachment

Care History Event

Encounter Event

Family History Observation





Laboratory Observation


Medication Event

Order Event



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









1325 Comment Observation Code code R:1..1 CD


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




[CONF:1320.12].





2.16.840.1.113883.5.6) [CONF:1322].


2.16.840.1.113883.5.1001) [CONF:1323].


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


f) SHALL contain zero or one if available [0..1] effectiveTime [CONF:1327] such that it,



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,


(2.16.840.1.113883.3.1818.10.4.2) [CONF:1329.1].

The following XML example outlines how to use the Comment Observation template:




Observation -->




codeSystem="2.16.840.1.113883.3.3068.10.6.3"


<text>Patient advised to review package of care</text>


<value xsi:type="CD" code="413324005" displayName="Patient advised to

review package of care"






Participation -->

<time value="20030529"/>



root="2.16.840.1.113883.3.163.5.0.10.2"/>



</assignedPerson>



root="2.16.840.1.113883.3.163.5.0.10.2"/>



</assignedAuthor>

</author>

</observation>


Figure 94: Comment Observation entry example

7.4 DATE OBSERVATION


Table 124: Date Observation Template Context


Advanced Directives Observation N/A

Attachment

Encounter Event


Medication Event



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


1330 Date Observation @typeCode 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:


2.16.840.1.113883.5.1002) [CONF:1330].




[CONF:1332.12].



2.16.840.1.113883.5.6) [CONF:1334].


2.16.840.1.113883.5.1001) [CONF:1335].

c) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} code="DATEOBS" Date


d) MAY contain zero or one [0..1] {CDAR2} effectiveTime [CONF:1337].

The following XML example outlines how to use the Date Observation template:



<templateId root="2.16.840.1.113883.3.1818.10.4.4"/> 




Pending"/>


</observation>


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


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





1601 supply 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




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:






[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].


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

The following XML example outlines how to use the Dispense Request (first fill) template:





<code code="FF" codeSystem="2.16.840.1.113883.5.4" displayName="Partial

First Fill" codeSystemName="Hl7 Act Code"/>


<expectedUseTime>


</expectedUseTime>


<templateId root="2.16.840.1.113883.3.1818.10.4.11"/> 


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


</observation>


</supply>


Figure 96: Dispense Request (first fill) entry example

7.6 DISPENSE REQUEST (PART FILL)


Table 128: Dispense Request (part fill) Template Context



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






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


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:






[CONF:1610.12].



2.16.840.1.113883.5.6) [CONF:1612].


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,


(2.16.840.1.113883.3.1818.10.4.11) [CONF:1617.1].

The following XML example outlines how to use the Dispense Request (part fill) template:


<templateId root="2.16.840.1.113883.3.1818.10.4.33"/> 


<code code="FFP" codeSystem="2.16.840.1.113883.5.4" displayName="Partial

First Fill" codeSystemName="Hl7 Act Code"/>


<expectedUseTime>


</expectedUseTime>



Fill Interval -->






</observation>


</supply>


Figure 97: Dispense Request (part fill) entry example

7.7 DISPENSE REQUEST (REFILL)


Table 130: Dispense Request (refill) Template Context



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





1621 supply M:1..1



1624 Supply Dispense Type code M:1..1 CD




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


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:





[CONF:1619.12].




2.16.840.1.113883.5.6) [CONF:1622].


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,


(2.16.840.1.113883.3.1818.10.4.11) [CONF:1628.1].



The following XML example outlines how to use the Dispense Request (refill) template:





<code code="RF" codeSystem="2.16.840.1.113883.5.4" displayName="Refills"

codeSystemName="Hl7 Act Code"/>




Fill Interval -->






</observation>


</supply>


Figure 98: Dispense Request (refill) entry example

7.8 DOSE OBSERVATION


Table 132: Dose Observation Template Context


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





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






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


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


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


1583 Form Form of medication to be administered (e.g. tablet, drop).

administrationUnitCode R:0..1 CE



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






[CONF:1574.12].



ActClass 2.16.840.1.113883.5.6) [CONF:1576].


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


f) SHALL contain zero or one if available [0..1] routeCode, which SHALL be selected from ValueSet


g) SHALL contain zero or one if available [0..1] approachSiteCode, which SHALL be selected from


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,


(2.16.840.1.113883.3.1818.10.4.16) [CONF:4361.1].

The following XML example outlines how to use the Dose Observation template:


<templateId root="2.16.840.1.113883.3.1818.10.4.8"/> 

<text>Take 2 tablets for 10 days</text>



<effectiveTime xsi:type="IVL_TS" operator="I">

<width value="10" unit="D"/>

</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>


</doseQuantity>



<administrationUnitCode code="ORSPRAY" displayName="oral spray"

codeSystem="2.16.840.1.113883.1.11.14570" codeSystemName="AdministerableDrugForm"/>



Identification-->







<e2e:desc>NITROGLYCERIN 0.4 mg/dose SPRAY, NON-AEROSOL

(GRAM)</e2e:desc>









</e2e:ingredient>

</e2e:ingredient>



</consumable>



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


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.



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.

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.



<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:



<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:



<text mediaType=”image/jpg”>

<reference value=”ftp://anywhere.com/folder1/image1.jpg”/>

</text>

<!—or -->


<reference value=”http://www.anywhere.com/folder1/image1.jpg”/>

</text>

Figure 102: Example attachment referenced by URL

http://tools.ietf.org/html/rfc1738

ftp://anywhere.com/folder1/image1.jpg

http://www.anywhere.com/folder1/image1.jpg

A referenced attachment may be located at an absolute location within a file system. For example:




<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:




<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



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





1219 observationMedia O:0..*



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:






[CONF:1218.12].

4) MAY contain zero or more [0..*] {CDAR2} observationMedia [CONF:1219].


2.16.840.1.113883.5.6) [CONF:1220].


2.16.840.1.113883.5.1001) [CONF:1221].



e) MAY contain zero or more [0..*] {CDAR2} author [CONF:1224] such that each,




(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:



Data -->





claim1.pdf"/>

</value>


<templateId root="2.16.840.1.113883.3.1818.10.4.2"/>

<time value="20030529"/>



root="2.16.840.1.113883.3.163.5.0.10.2"/>



</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


Clinically Measured Observations Organizer N/A

Developmental Observations Organizer

Device Observation

Encounter Event


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.



Table 138: Informant Participation Constraints Overview







1247 Informant Identifier The informant's identifier if the informant is an identified person.

id R:1..1 II




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




[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




c) SHALL contain exactly one [1..1] assignedPerson [CONF:1248].


2.16.840.1.113883.5.41) [CONF:1249].



iii) SHALL contain exactly one (or a nullFlavor value) [1..1] name [CONF:1251] such that it,





The following XML example outlines how to use the Informant Participation template:



Participation -->





<addr use="WP">

<delimiter>2222 Home Street</delimiter>

<city>Kamloops</city>

<state>BC</state>

<postalCode>A1B2C3</postalCode>


</addr>

<telecom value="tel:5555552003" use="H"/>

<telecom value="mailto://[email protected]" use="H"/>


<name use="L">


<given>Eve</given>

<given>E.</given>


</name>

</assignedPerson>

</assignedEntity>

</informant>

Figure 107: Informant Participation entry example

7.11 INSTRUCTION OBSERVATION


Table 139: Instruction Observation Template Context


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.



Table 140: Instruction Observation Constraints Overview








1590 Instruction Observation Code code R:1..1 CD


1592 Instruction Target participant R:1..1



1595 participantRole R: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:


2.16.840.1.113883.5.1002) [CONF:1584].




[CONF:1586.12].



2.16.840.1.113883.5.6) [CONF:1588].


2.16.840.1.113883.5.1001) [CONF:1589].

c) SHALL contain exactly one (or a nullFlavor value) [1..1] code="INSTRUCT" Instruction Notes


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




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

The following XML example outlines how to use the Instruction Observation template:




<templateId root="2.16.840.1.113883.3.1818.10.4.35"/> 



<text>

Please review proper administration technique to the patient and

patient's daughter at time of dispense.

</text>



</participant>

</observation>






Observation-->



<text>


If pain continues for more than 15 minutes or recurs frequently, get to

emergency department ASAP.

</text>



</participant>

</observation>


Figure 108: Instruction Observation entry example

7.12 LIFESTAGE OBSERVATION


Table 141: Lifestage Observation Template Context


Allergy & Intolerance Observation N/A

Family History Observation


The Lifestage Observation template is referenced by various section or entry to enable the consistent

communication of Lifestage as a coded element.

The Lifestage Observation template supports only a coded value from the Lifestage code set.

Table 142: Lifestage Observation Constraints Overview








1389 Lifestage Observation Code code M:1..1 CD

1390 Lifestage value value M:1..1 CD

A Lifestage Observation (Observation) element:


2.16.840.1.113883.5.1002) [CONF:1383].




[CONF:1385.12].



2.16.840.1.113883.5.6) [CONF:1387].


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:


<templateId root="2.16.840.1.113883.3.1818.10.4.12"/> 




Pending"/>



</observation>


Figure 109: Lifestage Observation entry example



7.13 LOCATION PARTICIPATION

[Participant: templateId 2.16.840.1.113883.3.1818.10.4.13(closed)]

Table 143: Location Participation Template Context


Immunization Observation N/A


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







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




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




[CONF:1268.12].

4) MAY contain zero or more [0..*] {CDAR2} participantRole [CONF:1269].



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


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


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



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:



Participation -->


<playingEntity>


</playingEntity>

</participantRole>

</participant>

Figure 110: Location Participation entry example

7.14 MEDICATION ADMINISTRATION EVENT


Table 145: Medication Administration Event Template Context


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.



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


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






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.


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


1539 Dose The amount of the drug administered into the patient (e.g. 3 Drops).


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


R:0..1

1543 Administered Product Information consumable R:0..1





1545 Manufactured Product manufacturedProduct R:1..1


1547 manufacturedMaterial R:1..1

1548 Manufactured Material @classCode 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:


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




[CONF:1530.12].



ActClass 2.16.840.1.113883.5.6) [CONF:1532].


2.16.840.1.113883.5.1001) [CONF:1533].



2.16.840.1.113883.5.4) [CONF:1535].


f) SHALL contain zero or one if available [0..1] routeCode, which SHALL be selected from ValueSet


g) SHALL contain zero or one if available [0..1] approachSiteCode, which SHALL be selected from


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,


(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,




(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:


ii) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2} manufacturedProduct

[CONF:1545].



(2) SHALL contain exactly one (or a nullFlavor value) [1..1] {CDAR2}






(c) SHALL contain exactly one (or a nullFlavor value) [1..1] lotNumberText

[CONF:1550].

The following XML example outlines how to use the Medication Administration Event template:




Acministration Event -->



root="2.16.840.1.113883.3.1818.10.10.3"/>


Therapy"/>




<routeCode></routeCode>

<approachSiteCode></approachSiteCode>

<doseQuantity></doseQuantity>






<lotNumberText>123</lotNumberText>



</consumable>





Participation -->

<time value="20030529"/>



root="2.16.840.1.113883.3.163.5.0.10.2"/>


<name>Mrs. Grace Nurse</name>

</assignedPerson>

</assignedAuthor>

</author>





Participation -->


<playingEntity>


</playingEntity>

</participantRole>

</participant>






Observation -->





Pending"/>

<value xsi:type="ST">Hypotension due to administration for

ACS.</value>

</observation>




Figure 111: Medication Administration Event entry example

7.15 MEDICATION DISPENSE EVENT


Table 147: Medication Dispense Event Template Context


Medication Prescription Event Medication Administration Event

Medication Fill Interval


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





1511 Dispense Record supply 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) .


Participation)

R:0..1

1518 Dispense Medication The identification of the actual medication dispensed.

product R:0..1


1520 manufacturedProduct M:1..1


1522

manufacturedLabeledDrug

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:






[CONF:1510.12].



2.16.840.1.113883.5.6) [CONF:1512].


2.16.840.1.113883.5.1001) [CONF:1513].

c) SHALL contain exactly one [1..1] id [CONF:1514] such that it,



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,


(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:


ii) SHALL contain exactly one [1..1] manufacturedProduct [CONF:1520].



(2) SHALL contain exactly one [1..1] manufacturedLabeledDrug [CONF:1522].





(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].



(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].

The following XML example outlines how to use the Medication Dispense Event template:



<templateId root="2.16.840.1.113883.3.1818.10.4.7"/> 





<product typeCode="PRD">


<manufacturedLabeledDrug classCode="MMAT" determinerCode="KIND">


codeSystem="2.16.840.1.113883.5.1105" codeSystemName="hcDIN"/>



</product>




<templateId root="2.16.840.1.113883.3.1818.10.4.19"/> 

<time value="20130211"/>



root="2.16.840.1.113883.3.163.5.0.10.2"/>

<code code="180000000X" displayName="Pharmacy"



<name use="L">Mr. P. Scriber</name>

</assignedPerson>


<name>Mainstreet Pharmacy</name>


</assignedEntity>

</performer>





Fill Interval -->






</observation>





Acministration Event -->

...



</supply>


Figure 112: Medication Dispense Event entry example

7.16 MEDICATION FILL INTERVAL


Table 149: Medication Fill Interval Template Context


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








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:


2.16.840.1.113883.5.1002) [CONF:1637].




[CONF:1639.12].





2.16.840.1.113883.5.6) [CONF:1641].


2.16.840.1.113883.5.1001) [CONF:1642].

c) SHALL contain exactly one (or a nullFlavor value) [1..1] code="FILLINT" Fill Interval


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:



Fill Interval -->






</observation>


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


Dose Observation N/A

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



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




1553 Manufactured Product manufacturedProduct R:1..1


http://webprod5.hc-sc.gc.ca/dpd-bdpp/info.do?code=8597&lang=eng




1555 Manufactured Labeled Drug manufacturedLabeledDrug R: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].





[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:


ii) SHALL contain exactly one [1..1] @determinerCode="KIND" kind (CodeSystem:


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



The following XML example outlines how to use the Medication Identification template:



Identification-->






<e2e:desc>NITROGLYCERIN 0.4 mg/dose SPRAY, NON-AEROSOL (GRAM)</e2e:desc>









</e2e:ingredient>

</e2e:ingredient>



</consumable>

Figure 114: Medication Identification entry example

7.18 MEDICATION PRESCRIPTION EVENT


Table 153: Medication Prescription Event Template Context


Medication Event Author Participation

Dispense Request (first fill)

Dispense Request (part fill)

Dispense Request (refill)

Dose Observation

Instruction Observation

Medication Dispense Event


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.



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





1489 Prescription Record substanceAdministration 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.




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




previous prescription on that Medication Record.

1498 Stop Reason The reason for stopping the prescription.

entryRelationship


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:






[CONF:1488.12].

4) SHALL contain exactly one [1..1] substanceAdministration [CONF:1489].


ActClass 2.16.840.1.113883.5.6) [CONF:1490].


2.16.840.1.113883.5.1001) [CONF:1491].

c) SHALL contain exactly one [1..1] id [CONF:1492] such that it,



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


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,



f) SHALL contain exactly one [1..1] consumable [CONF:4362] such that it,


(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,


(2.16.840.1.113883.3.1818.10.4.2) [CONF:1495.1].


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,


(2.16.840.1.113883.3.1818.10.4.38) [CONF:1497.1].



(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].

The following XML example outlines how to use the Medication Prescription Event template:


<templateId root="2.16.840.1.113883.3.1818.10.4.20" /> 



root="2.16.840.1.113883.3.1818.10.10.3"/>


Therapy"/>




<low value="20130211"/>

<high value="20130212"/>

</effectiveTime>



Identification-->

…

</consumable>





Participation -->

<time value="20030529"/>





</assignedPerson>

</assignedAuthor>

</author>




<templateId root="2.16.840.1.113883.3.1818.10.4.8"/> 


<templateId root="2.16.840.1.113883.3.1818.10.4.38"/> 




codeSystem="2.16.840.1.113883.3.3068.10.6.3"


</observation>






Observation -->

codeSystem="2.16.840.1.113883.3.3068.10.6.3"


<text>Stop administration of spray if patient experiences problems

swollowing.</text>


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






Indicator-->





</observation>




<templateId root="2.16.840.1.113883.3.1818.10.4.37"/> 


<templateId root="2.16.840.1.113883.3.1818.10.4.33"/> 


<code code="FFP" codeSystem="2.16.840.1.113883.5.4" displayName="Partial

First Fill"



<expectedUseTime>


</expectedUseTime>

Fill Interval -->






</observation>


</supply>








<code code="FF" codeSystem="2.16.840.1.113883.5.4" displayName="Partial

First Fill"



<expectedUseTime>


</expectedUseTime>



Fill Interval -->




<text>3 days</text>


</observation>


</supply>








<code code="RF" codeSystem="2.16.840.1.113883.5.4" displayName="Refills"





Fill Interval -->






</observation>


</supply>

Observation-->



<text>

Please review proper administration technique to the patient and

patient's daughter at time of dispense.

</text>



</participant>

</observation>






Observation-->



<text>


If pain continues for more than 15 minutes or recurs frequently, get to

emergency department ASAP.

</text>



</participant>

</observation>




<templateId root="2.16.840.1.113883.3.1818.10.4.7"/> <!--Dispense Event --

>

…





Figure 115: Medication Prescription Event entry example

7.19 ORDER INDICATOR


Table 155: Order Indicator Template Context


Medication Prescription Event N/A



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




1564 @InversionInd O:0..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].


3) MAY contain zero or one [0..1] {CDAR2} @InversionInd="true" [CONF:1564].



[CONF:1565.12].



2.16.840.1.113883.5.6) [CONF:1567].


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

The following XML example outlines how to use the Order Indicator template:





Indicator-->





</observation>





->



codeSystemName="ObservationType-CA-Pending" displayName="Adapt Not Allowed

Indicator"/>


</observation>





->



codeSystemName="ObservationType-CA-Pending" displayName="Substitute Not Allowed

Indicator"/>


</observation>


Figure 116: Order Indicator entry example

7.20 OUTCOME OBSERVATION


Table 157: Outcome Observation Template Context


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.



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








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:


2.16.840.1.113883.5.1002) [CONF:1361].




[CONF:1363.12].



2.16.840.1.113883.5.6) [CONF:1365].


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






g) SHALL contain zero or one if available [0..1] value [CONF:1371].



[CONF:1372.1].

i) MAY contain zero or more [0..*] {CDAR2} author [CONF:1373] such that each,


(2.16.840.1.113883.3.1818.10.4.2) [CONF:1373.1].

The following XML example outlines how to use the Outcome Observation template:


<templateId root="2.16.840.1.113883.3.1818.10.4.18"/> 



<code code="OUTCOBS" displayName="Outcome Observation"


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.


molecular weight heparin, Clopidogrel, and low dose beta blockade.



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


angiography on the 13th of February. </text>




Participation -->

<time value="20130223"/>





</assignedPerson>

</assignedAuthor>

</author>









Pending" />

<text>Keywords: Hospital Discharge</text>


<value xsi:type="ST">Hospital Discharge Summary</value>






Data -->




CCD.pdf"/>

</value>


</observationMedia>


</observation>


</observation>


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


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




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



1260 Assigned Person's Name name R:0..1 PN

1261 Represented Organization representedOrganization O:0..1






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



[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,






b) MAY contain zero or one [0..1] {CDAR2} assignedPerson [CONF:1257].


2.16.840.1.113883.5.41) [CONF:1258].



iii) SHALL contain zero or one if available [0..1] name [CONF:1260] such that it,



c) MAY contain zero or one [0..1] {CDAR2} representedOrganization [CONF:1261].

i) SHALL contain exactly one [1..1] @classCode="ORG" organization (CodeSystem:




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



The following XML example outlines how to use the Performer Participation template:



Participation-->

<time value="201111111111"/>

<assignedEntity>




<name>




</name>

</assignedPerson>





</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


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










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




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:


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




[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,






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


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


e) MAY contain zero or one [0..1] {CDAR2} playingEntity [CONF:1286].


2.16.840.1.113883.5.41) [CONF:1287].





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


Participation -->

<participantRole>



<name>


<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


Table 163: Qualifier Observation Template Context


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













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:


2.16.840.1.113883.5.1002) [CONF:1305].




[CONF:1307.12].



[CONF:1308.12].



2.16.840.1.113883.5.6) [CONF:1310].


2.16.840.1.113883.5.1001) [CONF:1311].


d) SHALL contain exactly one (or a nullFlavor value) [1..1] code="QUALOBS" Qualifier




that it,



g) SHALL contain exactly one (or a nullFlavor value) [1..1] value [CONF:1316].



(2.16.840.1.113883.3.1818.10.4.2) [CONF:1317.1].

The following XML example outlines how to use the Qualifier Observation template:


<templateId root="2.16.840.1.113883.3.1818.10.4.22"/> 



<code code="QUALOBS" displayName="Qualifier Observation"


Pending"/>


<value xsi:type="CD" code="TBD" codeSystem="TBD" codeSystemName="TBD"

displayName="Qualifier Observation code"/>



Participation -->

<time value="20030529"/>





</assignedPerson>

</assignedAuthor>

</author>

</observation>


Figure 120: Qualifier Observation entry example

7.24 REACTION OBSERVATION


Table 165: Reaction Observation Template Context


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







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.


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


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


Participation)

R:0..1

A Reaction Observation (Observation) element:


2.16.840.1.113883.5.1002) [CONF:1338].




[CONF:1340.12].



2.16.840.1.113883.5.6) [CONF:1342].


2.16.840.1.113883.5.1001) [CONF:1343].




d) SHALL contain exactly one (or a nullFlavor value) [1..1] code="REACTOBS" Reaction Code


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




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


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,


(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,


(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,


(2.16.840.1.113883.3.1818.10.4.10) [CONF:1351.1].

The following XML example outlines how to use the Reaction Observation template:



Observation -->




Pending"/>

<text>Severe reaction to peanuts</text>


<value xsi:type="CD" code="417516000" displayName="Anaphylaxis due to

substance" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>




Observation -->


<code code="SEV" displayName="Severity"




</observation>




... Comment Observation Template ...



... Author Participation Template ...



... Informant Participation Template ...

</observation>


Figure 121: Reaction Observation entry example

7.25 REASON OBSERVATION


Table 167: Reason Observation Template Context


Appointment Observation Author Participation

Care History Event Informant Participation

Encounter Event Record ID Link



Medication Event


Order Event



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












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:


2.16.840.1.113883.5.1002) [CONF:1291].




[CONF:1293.12].



2.16.840.1.113883.5.6) [CONF:1295].


2.16.840.1.113883.5.1001) [CONF:1296].


d) SHALL contain exactly one (or a nullFlavor value) [1..1] code="REASON" Reason Code




that it,



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,

(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,


(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,


(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:



Observation -->





Pending"/>

<text>confirmation recieved from Hospital</text>








Participation -->

<time value="20030529"/>



root="2.16.840.1.113883.3.163.5.0.10.2"/>



</assignedPerson>

</assignedAuthor>

</author>





Participation -->



<assignedPerson>


</assignedPerson>

</assignedEntity>

</informant>

</observation>


Figure 122: Reason Observation entry example



7.26 RECORD ID LINK


Table 169: Record ID Link Template Context


Encounter Event N/A


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









1635 Record ID Link Observation Code code M:1..1 CD

A Record ID Link (Observation) element:


2.16.840.1.113883.5.1002) [CONF:1629].




[CONF:1631.12].



2.16.840.1.113883.5.6) [CONF:1633].


2.16.840.1.113883.5.1001) [CONF:1634].


d) SHALL contain exactly one [1..1] code="RECLINK" Record ID Link (CodeSystem:


The following XML example outlines how to use the Record ID Link template:


<templateId root="2.16.840.1.113883.3.1818.10.4.38"/> 





Pending"/>

</observation>


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


Result Organizer Attachment

Comment Observation


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





1442 Result Component Observation observation R:1..1



1445 Result Observation Record ID id R:1..1 II




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.


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.


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.


Participation)

R:0..1

1460 Specimen Collection Information entryRelationship R:1..1


1462 Collection Procedure procedure O:0..*



1465 Specimen Collection Date Date and time of the specimen collection. This is observation date/time in HL7 v2 (OBR-7).


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


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




interpreted.


1454 Observation Range observationRange O:0..*



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:






[CONF:1441.12].

4) SHALL contain exactly one (or a nullFlavor value) [1..1] observation [CONF:1442].


2.16.840.1.113883.5.6) [CONF:1443].


2.16.840.1.113883.5.1001) [CONF:1444].




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


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,


(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].





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



(2.16.840.1.113883.3.1818.10.4.3) [CONF:1468.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:


ii) MAY contain zero or more [0..*] {CDAR2} observationRange [CONF:1454].


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


(5) SHALL contain zero or one if available [0..1] value [CONF:1459].

The following XML example outlines how to use the Result Component template:



-->



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



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





Participation-->

<time value="201111111111"/>

<assignedEntity>




<name>




</name>

</assignedPerson>





</assignedEntity>

</performer>







<text>No problem with specimen collection</text>




</procedure>







Observation -->




Pending"/>

<value xsi:type="ST">Result Note comment inserted heret</value>

</observation>

Pending"/>

<text>Keywords: Abnormal Laboratory Result Chicken-Pox Confirmed</text>


<value xsi:type="ST">Chicken Pox Alert</value>






Data -->





claim1.pdf"/>

</value>


</observationMedia>


</observation>


<referenceRange typeCode="REFV">


<code code="N" displayName="Normal"

codeSystem="2.16.840.1.113883.1.11.10206"


<text>Normal Reference range is between 5 and 10</text>


<low value="4.3"/>


</value>

</observationRange>


<code code="H" displayName="High"

codeSystem="2.16.840.1.113883.1.11.10206"


<text>High Reference range is between 5 and 10</text>




</value>

</observationRange>


<code code="HH" displayName="Very High"

codeSystem="2.16.840.1.113883.1.11.10206"


<text>Very High Reference range is between 5 and 10</text>



</value>

</observationRange>



</referenceRange>

</observation>

</component>

Figure 124: Result Component entry example

7.28 RESULT ORGANIZER


Table 173: Result Organizer Template Context


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





1431 organizer R:1..1




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.


1438 Result Observation component (Result

Component)

R:1..*

A Result Organizer (Organizer) element:






[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].


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


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:


<templateId root="2.16.840.1.113883.3.1818.10.4.26"/> 

...

</component>

</organizer>


Figure 125: Result Organizer entry example



7.29 SECONDARY CODE (DRUG)


Table 175: Secondary Code (Drug) Template Context


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








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:






[CONF:1414.12].



2.16.840.1.113883.5.6) [CONF:1416].


2.16.840.1.113883.5.1001) [CONF:1417].

c) SHALL contain exactly one [1..1] code="SECDRUGCODE" Secondary Drug (CodeSystem:


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:






Drug -->

<code code="SECDRUGCODE" displayName="Secondary Drug Code"


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>


Figure 126: Secondary Code (Drug) entry example

7.30 SECONDARY CODE (ICD-9)


Table 177: Secondary Code (ICD-9) Template Context


Family History Observation N/A


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






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:






[CONF:1406.12].



2.16.840.1.113883.5.6) [CONF:1408].


2.16.840.1.113883.5.1001) [CONF:1409].

c) SHALL contain exactly one [1..1] code="ICD9CODE" Billing Code Observation (e.g. ICD9)


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:




(ICD9) -->




Pending"/>

<value xsi:type="CD" code="tbd" displayName="tbd"

codeSystem="2.16.840.1.113883.6.42" codeSystemName="ICD9"/>

</observation>


Figure 127: Secondary Code (ICD-9) entry example

7.31 SECONDARY CODE (UNBOUND)


Table 179: Secondary Code (Unbound) Template Context





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








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:






[CONF:1422.12].



2.16.840.1.113883.5.6) [CONF:1424].


2.16.840.1.113883.5.1001) [CONF:1425].

c) SHALL contain exactly one [1..1] code="SECCODE" Secondary Code Unbound (CodeSystem:





The following XML example outlines how to use the Secondary Code (Unbound) template:



Unbound -->


<code code="SECCODE" displayName="Secondary Code"


Pending"/>

<value xsi:type="CD" code="BIN" codeSystem="2.16.840.1.113883.6.42"


</observation>


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


Allergy & Intolerance Observation N/A


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











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:


2.16.840.1.113883.5.1002) [CONF:1352].




[CONF:1354.12].



2.16.840.1.113883.5.6) [CONF:1356].


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:



Observation -->






</observation>


Figure 129: Severity Observation entry example

7.33 STATUS CHANGES AUDIT EVENT


Table 183: Status Changes Audit Event Template Context


Allergy & Intolerance Observation Author Participation




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




1393 @inversionInd O:0..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.


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


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



A Status Changes Audit Event (Observation) element:


2.16.840.1.113883.5.1002) [CONF:1391].


3) MAY contain zero or one [0..1] {CDAR2} @inversionInd="true" [CONF:1393].



[CONF:1394.12].



2.16.840.1.113883.5.6) [CONF:1396].


2.16.840.1.113883.5.1001) [CONF:1397].


d) SHALL contain exactly one (or a nullFlavor value) [1..1] code="STSAUDITOBS" Status Audit



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,


(2.16.840.1.113883.3.1818.10.4.24) [CONF:1402.1].



(2.16.840.1.113883.3.1818.10.4.2) [CONF:1403.1].

The following XML example outlines how to use the Status Changes Audit Event template:



<templateId root="2.16.840.1.113883.3.1818.10.4.31"/> 



<code code="STSAUDITOBS" displayName="Status Audit Observation"


Pending" />

<text>Allergy report recived from Emergency department confirming

allergy</text>






Participation -->

<time value="20030529"/>





</assignedPerson>

</assignedAuthor>

</author>





Observation -->





Pending"/>

<text>confirmation recieved from Hospital</text>








Participation -->

<time value="20030529"/>



root="2.16.840.1.113883.3.163.5.0.10.2"/>



</assignedPerson>

</assignedAuthor>

</author>





Participation -->




<assignedPerson>


</assignedPerson>

</assignedEntity>

</informant>

</observation>


</observation>


Figure 130: Status Changes Audit Event entry example

7.34 UNBOUND OBSERVATION


Table 185: Unbound Observation Template Context


Medication Event N/A


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








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

An Unbound Observation (Observation) element:


2.16.840.1.113883.5.1002) [CONF:1374].




[CONF:1376.12].



2.16.840.1.113883.5.6) [CONF:1378].


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:





<templateId root="2.16.840.1.113883.3.1818.10.4.32"/> 




Pending"/>

<value xsi:type="ST">Moderate severity</value>

</observation>


Figure 131: Unbound Observation entry example



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




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




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.



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.




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>


</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


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



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


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



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


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




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


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




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


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



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


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


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



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


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



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)

http://wiki.hl7.org/index.php?title=%20RIM_Maintenance_and_Tooling_Documentation

https://www.infoway-inforoute.com/index.php/programs-services/standards-collaborative/pan-canadian-standards/pan-canadian-master-terminology-worksheet-and-messaging-artifacts





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



https://www.infoway-inforoute.com/index.php/programs-services/standards-collaborative/membership




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




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


2.16.840.1.113883.1.11.13955 STATIC


Description Domain provides codes that qualify the ActEncounterClass (ENC)



ActOrderCode

Table 202: ActOrderCode Definition


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)



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


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


ActStatus

Table 204: ActStatus Definition


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.



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


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



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:



AdministrativeGender

Table 206: AdministrativeGender Definition


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)





F AdministrativeGender Female

M AdministrativeGender Male

UN AdministrativeGender Undifferentiated

AdvanceDirectiveType

Table 207: AdvanceDirectiveType Definition


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.





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



AlertDeviceType

Table 208: AlertDeviceType Definition


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.





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


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



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



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.




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


2.16.840.1.113883.2.20.3.211 DYNAMIC


Description Represents whether an allergy/intolerance is “active” or resolved (indicating no longer active).


Reference URL https://www.infoway-inforoute.ca/index.php/programs-services/standards-collaborative/pan-canadian-standards/primary-health-care-phc-reference-sets



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


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





A3 ObservationValue moderate reaction

A4 ObservationValue severe reaction

A0 ObservationValue no reaction




A1 ObservationValue minimal reaction

A2 ObservationValue mild reaction

AssignedEntityRoleCode

Table 213: AssignedEntityRoleCode Definition


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



AttachmentObservationType

Table 214: AttachmentObservationType Definition


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.




Applicable codes from LOINC

CDAHeaderActClass

Table 215: CDAHeaderActClass Definition


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.





ACT ActClass Act

CONS ActClass Consent

DOCBODY ActClass Document Body

DOCCLIN ActClass Clinical Document

DOCSECT ActClass Document Section

ENC ActClass Encounter



ClinicalDrug

Table 216: ClinicalDrug Definition


2.16.840.1.113883.2.20.3.29 DYNAMIC

Code System(s) See Infoway Master Terminology Worksheet (MTW)

Description N/A




See Infoway Master Terminology Worksheet (MTW)

Clinically Measured Observations Codes

Table 217: Clinically Measured Observations Codes Definition


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




Applicable codes from SNOMED CT or LOINC.

Developmental Observations Codes

Table 218: Developmental Observations Codes Definition


2.16.840.1.113883.3.1818.10.8.6 STATIC


Description The list of codes to identify specific developmental observations.





DiagnosisICD9CM

Table 219: DiagnosisICD9CM Definition


2.16.840.1.113883.1.11.15931 STATIC

Code System(s) icd9cm 2.16.840.1.113883.6.2

Description N/A





DiagnosisValuePrimary

Table 220: DiagnosisValuePrimary Definition


2.16.840.1.113883.2.20.3.40 DYNAMIC


Description N/A



Code Table Filter Example codes shown below (Please consult authoritative source for full value set content).


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


2.16.840.1.113883.1.11.10870 DYNAMIC


Description

The kind of document. Possible values: discharge summary, progress note, Oncology note, etc.



EncounterDischargeDisposition

Table 222: EncounterDischargeDisposition Definition


2.16.840.1.113883.2.20.3.43 STATIC


Description N/A







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


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



HumanLanguage

Table 224: HumanLanguage Definition


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.




All codes from iso3066

HumanSubstanceAdministrationSite

Table 225: HumanSubstanceAdministrationSite Definition


2.16.840.1.113883.2.20.3.52 DYNAMIC

Code System(s) bodySite 2.16.840.1.113883.12.163

Description N/A







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


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.



Code Table Filter Value set shown below may not be complete (Please consult the authoritative source).


BUS SCTEMP Business identifier

VER SCTEMP Version identifier

ImagingDetailObservationType

Table 227: ImagingDetailObservationType Definition


2.16.840.1.113883.3.3068.10.8.15 DYNAMIC


Description N/A




Applicable codes from LOINC



ImagingProcedureObservationType

Table 228: ImagingProcedureObservationType Definition


2.16.840.1.113883.3.3068.10.8.16 DYNAMIC


Description N/A




Applicable codes from SNOMED CT

InstructionTargetRole

Table 229: InstructionTargetRole Definition


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



PAT RoleClass Patient

PHARM SCPTYPE Pharmacist

ISO3166-1–CountryCodes

Table 230: ISO3166-1–CountryCodes Definition


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



ISO3166-2–State/Province

Table 231: ISO3166-2–State/Province Definition


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


2.16.840.1.113883.3.3068.10.8.19 STATIC


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.





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


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"





MediaType

Table 234: MediaType Definition


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





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



ObservationInterpretation

Table 235: ObservationInterpretation Definition


2.16.840.1.113883.2.20.3.78 STATIC

Code System(s) ObservationInterpretation 2.16.840.1.113883.5.83

Description N/A





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


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.





N ObservationInterpretation Normal







ObservationMethod

Table 237: ObservationMethod Definition


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.





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


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





ParticipationFunction

Table 239: ParticipationFunction Definition


2.16.840.1.113883.2.20.3.87 STATIC

Code System(s) ParticipationFunction 2.16.840.1.113883.5.88

Description N/A





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


2.16.840.1.113883.2.20.3.88 STATIC

Code System(s) ParticipationSignature 2.16.840.1.113883.5.89

Description N/A





S ParticipationSignature signed

ParticipationType

Table 241: ParticipationType Definition


2.16.840.1.113883.1.11.10901 STATIC

Code System(s) ParticipationType 2.16.840.1.113883.5.90



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.



PersonalRelationshipRoleType

Table 242: PersonalRelationshipRoleType Definition


2.16.840.1.113883.2.20.3.90 STATIC


Description N/A





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




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




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


2.16.840.1.113883.3.88.12.3221.7.2 STATIC


Description This value set indicates the level of medical judgment used to determine the existence of a problem.





404684003 SNOMED-CT Finding

409586006 SNOMED-CT Complaint




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


2.16.840.1.113883.3.3068.10.8.11 DYNAMIC


Description The list of procedure codes applicable in Primary Care




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


2.16.840.1.113883.2.20.3.265 DYNAMIC


Description Represents the role of the Provider in relation to his/her participation in a specific health care event.





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)

... ... ...



ReactionTypeCode

Table 246: ReactionTypeCode Definition


2.16.840.1.113883.3.3068.10.8.18 DYNAMIC


Description A set of values to classify a reaction (e.g. Allergy, Drug Allergy, Food Intolerance, etc.).





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


2.16.840.1.113883.3.3068.10.8.22 DYNAMIC


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.



Reproductive Observations Codes

Table 248: Reproductive Observations Codes Definition


2.16.840.1.113883.3.1818.10.8.7 STATIC


Description The list of codes to identify specific reproductive observations.



Intentional Applicable codes from SNOMED CT or LOINC.



Definition

Reproductive Observations Organizer Codes

Table 249: Reproductive Observations Organizer Codes Definition


2.16.840.1.113883.3.1818.10.8.10 STATIC


Description The list of valid organizer types for reproductive observations.





RiskFactorObservationType

Table 250: RiskFactorObservationType Definition


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





SMOKSTS ObservationType-CA-Pending Smoking Status

SMOKXDY ObservationType-CA-Pending Smoking Packs/Day

RoleClass

Table 251: RoleClass Definition


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



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.



RoleClassMutualRelationship

Table 252: RoleClassMutualRelationship Definition


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




See HL7 Reference Information Model (RIM)

RouteOfAdministration

Table 253: RouteOfAdministration Definition

ValueSet OID & 2.16.840.1.113883.2.20.3.188 STATIC



Binding

Code System(s) RouteOfAdministration 2.16.840.1.113883.5.112

Description N/A





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


2.16.840.1.113883.2.20.3.182 STATIC


Description N/A





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

... ... ...



UCUM

Table 255: UCUM Definition


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/


Appicable, valid unit strings expressed through the UCUM grammar.

VaccineAdministeredNameCode

Table 256: VaccineAdministeredNameCode Definition


2.16.840.1.113883.2.20.3.264 DYNAMIC


Description Represents the name of the vaccine that was administered to the Client.





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 +




inactivated poliomyelitis + haemophilus influenzae b vaccine (product)

... ... ...

x_ActRelationshipDocument

Table 257: x_ActRelationshipDocument Definition


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.



x_ActStatusActiveComplete

Table 258: x_ActStatusActiveComplete Definition


2.16.840.1.113883.1.11.19890 STATIC

Code System(s) ActStatus 2.16.840.1.113883.5.14

Description N/A





active ActStatus active

completed ActStatus completed

x_BasicAddressPartType

Table 259: x_BasicAddressPartType Definition


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.





CNT AddressPartType country

CTY AddressPartType municipality

STA AddressPartType state or province




ZIP AddressPartType postal code

x_BasicConfidentialityKind

Table 260: x_BasicConfidentialityKind Definition


2.16.840.1.113883.2.20.3.139 STATIC

Code System(s) Confidentiality 2.16.840.1.113883.5.25

Description N/A





N Confidentiality normal

R Confidentiality restricted

V Confidentiality very restricted

T Confidentiality taboo

x_BasicPersonNamePartQualifier

Table 261: x_BasicPersonNamePartQualifier Definition


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.





IN EntityNamePartQualifier initial

x_BasicPersonNamePartType

Table 262: x_BasicPersonNamePartType Definition


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.








FAM EntityNamePartType family

GIV EntityNamePartType given

PFX EntityNamePartType prefix

SFX EntityNamePartType suffix

x_BasicPersonNameUse

Table 263: x_BasicPersonNameUse Definition


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.





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


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.





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



x_BasicTelecommunicationsAddressUse

Table 265: x_BasicTelecommunicationsAddressUse Definition


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.





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


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





COMP ActRelationshipType has component

SAS ActRelationshipType starts after start of

x_EncounterParticipant

Table 267: x_EncounterParticipant Definition


2.16.840.1.113883.1.11.19600 STATIC


Description Clones using this x_domain should have a name "encounterParticipant".







ADM ParticipationType admitter

ATND ParticipationType attender

CON ParticipationType consultant

DIS ParticipationType discharger

REF ParticipationType referrer

x_PhoneOrEmailURLScheme

Table 268: x_PhoneOrEmailURLScheme Definition


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





mailto URLScheme Mailto

tel URLScheme Telephone

x_ServiceEventPerformer

Table 269: x_ServiceEventPerformer Definition


2.16.840.1.113883.1.11.19601 STATIC


Description Clones using this x_domain should have a name "performer".





PRF ParticipationType performer

SPRF ParticipationType secondary performer



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

http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm


















http://www.hl7.org/Memonly/downloads/Standards_Messaging_v26/HL7_Messaging_v26_WORD.zip

















http://www.iso.org/iso/country_codes/iso_3166_code_lists.htm




http://www.w3.org/WAI/ER/IG/ert/iso639.htm

http://loinc.org/



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

http://www.iana.org/assignments/media-types

http://www.iana.org/assignments/media-types





















http://forums.infoway-inforoute.ca/PCS

http://forums.infoway-inforoute.ca/PCS

http://www.ihtsdo.org/snomed-ct/

http://www.regenstrief.org/medinformatics/ucum

http://www.regenstrief.org/medinformatics/ucum

http://www.iana.org/protocols



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



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.

http://www.hl7.org/oid/index.cfm



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



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



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.



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



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.



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.

http://www.schematron.com/

http://www.relaxng.org/



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

http://www.hl7.org/documentcenter/public_temp_2D807AAD-1C23-BA17-0C68015850694475/calendarofevents/FirstTime/Glossary%20of%20terms.pdf

http://www.hl7.org/documentcenter/public_temp_2D807AAD-1C23-BA17-0C68015850694475/calendarofevents/FirstTime/Glossary%20of%20terms.pdf

https://knowledge.infoway-inforoute.ca/ehr_blueprint/glossary/en/a.html

http://telehealth.net/glossary

http://www.skmtglossary.org/Default.aspx?AspxAutoDetectCookieSupport=1



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

EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard · 2016-08-18 · EMR–to–EMR...

Documents

Transcript of EMR–to–EMR Data Transfer & Conversion (E2E–DTC) Standard · 2016-08-18 · EMR–to–EMR...