31 Guide

\
HL7 v3 pan-Canadian Messaging

Standards
Implementation Guide
Volume 2 - Clinical Records
July 12, 2007

V01R04.3
Document Information
Author: Canada Health Infoway
Creation Date: April 11, 2006
Last Updated: July 12, 2007
Language: English
Document Number: SC-CA-0006-EN
Document Status In Progress
Infoway Project Various
Distribution Infoway pan-Canadian Standards Groups (pCSGs);

Implementors; Other Stakeholders / Reviewers;
Contact Information Toronto Office:

150 King Street West, Suite 1308
Toronto, Ontario M5H 1J9
Tel.: (416) 979-4606
Toll free: 1-888-733-6462
Fax: (416) 593-5911
http://www.Infoway-inforoute.ca
Version Tracking
Version Author(s) Change Description Date

1.00 – 1.09 CeRx project team Initial baseline version + further edits prior to 2004-Oct-02 to
introduction of volumes 2005-Jun-25
2.00 CeRx project team Introduction of volumes and new formats 2006-Apr-15
2.01 CeRx project team Final updates for CeRx Stable for Use publication, 2006-Jun-30
resulting from public review of the CeRx
specification.
Additional updates include:
• Added new assumption regarding level of
HL7 information that is external to this
specification
• Added note to reader on application roles
used in storyboards
2.02 CeRx project team Updates corresponding to V01R04.2, including: 2006-Sep-11
• Added disclaimer for Immunization materials;
The Public Health Surveillance (PHS) project
is reviewing these materials and will be
including updated artifacts in their publication.
2.03 SC Maintenance Updates corresponding to V01R04.3, including: 2007-Jul-12
Team • No changes
Copyright © 2006 – Canada Health Infoway ii Implementation Guide Volume 2 - Clinical Records
Acknowledgments
N/A
Copyright Notice
This document is fully copyright protected by the owner. The owner has the exclusive right to make
copies of this document. No alterations, deletions or substitutions may be made in it without the prior
written consent of the owner. No part of it may be reproduced or transmitted in any form or by any
means, electronic or mechanical, including photocopy, email or any information storage and retrieval
system, without the prior written consent of the owner.
HL7® is registered trademark of Health Level Seven, Inc. (http://www.hl7.org)
LOINC® is a registered trademark of the Regenstrief Institute, Inc. (http://regenstrief.org)
SNOMED-CT® is a registered trademark of the College of American Pathologists (http://www.cap.org,
http://www.snomed.org).
Disclaimer
Canada Health Infoway Inc. (Infoway) in its role as strategic investor may require adherence to this or
similar specification documents as a criteria for funding or payment.
This document forms part of a standard which was developed through the EHR Standards Collaboration
Process (SCP). The SCP is a consensus-based standards development process that brings together
volunteers and/or seeks out the views of persons who have an interest in the topic covered by this
publication. While Infoway administers the process, establishes rules to promote fairness in the
development of consensus, and may engage consultants to facilitate the process and develop the
documentation, it does not independently test, evaluate, or verify the accuracy or completeness of any
information or the soundness of any judgments contained in its standards and guideline publications.
The information in this publication was considered technically sound by the consensus of persons
engaged in the development and approval of the document at the time it was developed. Consensus
does not necessarily mean that there is unanimous agreement among every person participating in the
development of this document.
Infoway disclaims liability for any personal injury, property, or other damages of any nature whatsoever,
whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the
publication, use of, application, or reliance on this document. Infoway disclaims and makes no guaranty
or warranty, expressed or implied, as to the accuracy or completeness of any information published
herein, and disclaims and makes no warranty that the information in this document will fulfill any of your
particular purposes or needs. Infoway does not undertake to guarantee the performance of any individual
manufacturer or seller’s products or services by virtue of this standard or guide.
In publishing and making this document available, Infoway is not undertaking to render professional or
other services for or on behalf of any person or entity, nor is Infoway undertaking to perform any duty
owed by any person or entity to someone else. Anyone using this document should rely on his or her
own independent judgment or, as appropriate, seek the advice of a competent professional in determining
the exercise of reasonable care in any given circumstances. Information and other standards on the topic
covered by this publication may be available from other sources, which the user may wish to consult for
additional views or information not covered by this publication.
Copyright © 2006 – Canada Health Infoway iii Implementation Guide Volume 2 - Clinical Records
PREFACE – QUICK DOCUMENT OVERVIEW
Purpose The purpose of this document is to provide implementation, compliance

and conformance guidelines for use in developing software that
conforms to the Message Specifications developed by Infoway through
the Standards Collaboration Process (SCP).
Audience The audience for this document includes the organizations implementing
the Message Specifications contained in the appropriate Implementation
Guide Volumes (e.g. Pharmacy, Lab, Client Registry). This includes
technical and business audiences who will use the guide to develop
implementations and validate that these implementations conform to the
Message Specifications and to the requirements of the stakeholder
organizations.
Instructions Instructions have been provided for each element in this document. Use
the Show/Hide button in Word to show the hidden text.
Structure In addition to the standard “Executive Summary” and “Appendix”

sections, this document includes the following specific sections:
Introduction General introduction to this document.
Standards The documentation approach followed in the

Development creation of Message Specifications and
Documentation implementation guidance.
Framework
Implementation Guide Documentation framework a series of
Documentation implementation guide volumes, that together,
Framework comprise the Implementation Guide for
Message Specifications.
Assumptions Overarching assumptions that are used to
shape the materials presented in this
document.
Business Model Business Model and storyboards (use cases)
that describe the business context for the
suite of transactions in this document
General Common considerations and guidelines that
Implementation pertain to messages contained in this
Considerations and document.
Guidelines
Transaction-Based Component based considerations and
Implementation guidelines for transactions contained in this
Considerations and document.
Guidelines
Copyright © 2006 – Canada Health Infoway iv Implementation Guide Volume 2 - Clinical Records
TABLE OF CONTENTS
I Executive Summary................................................................................................. 1
II Introduction.............................................................................................................. 2
2.1 Scope ..................................................................................................................................... 2
2.2 Purpose .................................................................................................................................. 2
2.3 Audience................................................................................................................................. 2
2.4 Document Assumptions........................................................................................................... 2
2.5 Related Documents................................................................................................................. 3
2.6 External Supporting Documents .............................................................................................. 3
III Standards Development Documentation Framework........................................... 6
3.1 Document Naming Conventions .............................................................................................. 6
IV Implementation Guide Documentation Framework .............................................. 7
4.1 Implementation Guide Volume 0 – Overview ........................................................................... 8
4.2 Implementation Guide Volumes 1-n – Domain Volumes........................................................... 8
4.3 Message Specification Artifacts ............................................................................................... 9
4.3.1 Message Models ......................................................................................................... 9
4.3.1.1 How to Read the Word Message Models ................................................... 10
4.3.2 XML Schemas........................................................................................................... 10
4.3.3 Message Worksheets ................................................................................................ 10
4.3.4 Vocabulary Status Worksheet.................................................................................... 10
4.3.4.1 How to Read the Vocabulary Status Worksheet ......................................... 10
4.3.5 Datatypes.................................................................................................................. 10
4.4 Cross-Volume Artifacts.......................................................................................................... 11
4.4.1 Glossary.................................................................................................................... 11
4.4.2 Scope & Tracking Framework.................................................................................... 11
4.4.2.1 How to Read the Scope & Tracking Framework ......................................... 11
4.5 Supporting Business Artifacts................................................................................................ 12
4.5.1 Business Model ......................................................................................................... 12
4.5.2 Issue Detail Reports + Discussion Documents........................................................... 12
V Assumptions .......................................................................................................... 13
VI Business Model...................................................................................................... 16
6.1 Storyboards........................................................................................................................... 16
6.1.1 Record Immunization................................................................................................. 16
6.1.2 Recording Patient Observations ................................................................................ 18
6.1.3 Recording Patient Medical Condition ......................................................................... 19
6.1.4 Recording Patient Allergic Reaction........................................................................... 20
6.1.5 Recording Professional Service................................................................................. 22
6.1.6 Recording Patient Adverse Reaction ......................................................................... 24
VII General Implementation Considerations and Guidelines................................... 26
7.1 Stakeholder Considerations................................................................................................... 26
7.1.1 Public........................................................................................................................ 26
7.1.2 Implementors of EHR/DIS Systems ........................................................................... 26
7.1.3 Implementors of Web-Based or Viewer Solutions....................................................... 29
7.1.4 Implementors of Electronic Medical Record (EMR) Systems...................................... 29
Copyright © 2006 – Canada Health Infoway v Implementation Guide Volume 2 - Clinical Records
7.1.5 Implementors of Pharmacy Management Systems (PMS).......................................... 30
7.1.6 Regulatory Bodies (Jurisdictional).............................................................................. 30
7.1.7 Regulatory Bodies (National)..................................................................................... 31
7.2 Business Based Considerations ............................................................................................ 32
7.2.1 Allergy Discussion ..................................................................................................... 32
7.3 Vocabulary Based Considerations ......................................................................................... 34
7.3.1 Conditions................................................................................................................. 34
VIII Transaction-Based Implementation Considerations and Guidelines............... 38
8.1 Immunizations....................................................................................................................... 38
8.1.1 C14.01 – Add Patient Immunization........................................................................... 38
8.1.1.1 Key Transaction Design Elements ............................................................. 38
8.1.1.2 Key Transaction Assumptions.................................................................... 38
8.1.1.3 Interaction(s).............................................................................................. 40
8.1.2 C14.05 Update Patient Immunization......................................................................... 42
8.1.2.3 Interaction(s).............................................................................................. 43
8.1.3 C14.02 Patient Immunization Query .......................................................................... 44
8.1.3.3 Interaction(s).............................................................................................. 44
8.1.4 C14.06 Retract Immunization Record ........................................................................ 45
8.1.4.3 Interaction(s).............................................................................................. 45
8.2 Patient Observations ............................................................................................................. 46
8.2.1 C21.04 Record Basic Patient Observation ................................................................. 46
8.2.1.3 Interaction(s).............................................................................................. 47
8.2.2 C21.05 Review Basic Patient Observations ............................................................... 49
8.2.2.3 Interaction(s).............................................................................................. 49
8.3 Medical Conditions................................................................................................................ 50
8.3.1 C12.01 Add Patient Medical Condition....................................................................... 50
8.3.1.3 Interaction(s).............................................................................................. 52
8.3.2 C12.02 Update Patient Medical Condition.................................................................. 53
8.3.2.3 Interaction(s).............................................................................................. 54
8.3.3 C12.03 Get Patient Medical Conditions...................................................................... 56
8.3.3.3 Interaction(s).............................................................................................. 56
8.3.4 C12.07 Get Patient Medical Conditions No History .................................................... 58
8.3.4.3 Interaction(s).............................................................................................. 58
8.4 Allergy/Intolerances............................................................................................................... 60
8.4.1 C11.01 Add Allergy, Intolerance ................................................................................ 60
Copyright © 2006 – Canada Health Infoway vi Implementation Guide Volume 2 - Clinical Records
8.4.1.3 Interaction(s).............................................................................................. 62
8.4.2 C11.02 Update Allergy, Intolerance ........................................................................... 63
8.4.2.3 Interaction(s).............................................................................................. 64
8.4.3 C11.03 Get Patient Allergies, Intolerances................................................................. 66
8.4.3.3 Interaction(s).............................................................................................. 66
8.4.4 C11.04 Get Allergy, Intolerance Change History ........................................................ 68
8.4.4.3 Interaction(s).............................................................................................. 68
8.5 Professional Services............................................................................................................ 70
8.5.1 C13.01 Record Professional Service ......................................................................... 70
8.5.1.3 Interaction(s).............................................................................................. 71
8.5.2 C13.02 Get Patient Professional Services.................................................................. 72
8.5.2.3 Interaction(s).............................................................................................. 72
8.6 Adverse Reactions ................................................................................................................ 73
8.6.1 C11.05 Add Patient Adverse Reaction....................................................................... 73
8.6.1.3 Interaction(s).............................................................................................. 75
8.6.2 C11.06 Update Patient Adverse Reaction.................................................................. 76
8.6.2.3 Interaction(s).............................................................................................. 77
8.6.3 C11.07 Get Patient Adverse Reactions...................................................................... 79
8.6.3.3 Interaction(s).............................................................................................. 79
Appendix A. How to Read the Scope & Tracking Framework............................... 80
Appendix B. How to Read the Word Message Models........................................... 83
Appendix C. How to Read the Vocabulary Status Worksheet............................... 86
Appendix D. HL7 Methodology Background .......................................................... 87
List of Figures
Figure 1 – Standards Development Documentation Framework (SDDF) .................................................. 6
Figure 2 – Implementation Guide Documentation Framework .................................................................. 7
Figure 3 – Interaction Diagram: Record Immunization............................................................................ 17
Figure 4 – Interaction Diagram: Recording Patient Observations............................................................ 18
Figure 5 – Interaction Diagram: Recording Patient Medical Condition..................................................... 19
Figure 6 – Interaction Diagram: Recording Patient Allergic Reaction ...................................................... 20
Figure 7 – Interaction Diagram: Recording Professional Service ............................................................ 23
Figure 8 – Interaction Diagram: Recording Patient Adverse Reaction..................................................... 25
Figure 9 – Uncategorized Intolerance (Allergy & Intolerance) ................................................................. 32
Copyright © 2006 – Canada Health Infoway vii Implementation Guide Volume 2 - Clinical Records
Figure 10 – Medical Condition vs. Prescribing Indication........................................................................ 36
Figure 11 – Artifact Relationship ............................................................................................................ 80
Figure 12 – HL7 v3 Messaging Artifacts................................................................................................. 88
Copyright © 2006 – Canada Health Infoway viii Implementation Guide Volume 2 - Clinical Records
I EXECUTIVE SUMMARY
The Canadian Electronic Drug Messaging standard is a Canada Health Infoway sponsored standards
development initiative. The Message Specification is focused on electronic messages that support e-
Prescribing and, more importantly, enable the establishment of complete, electronically accessible patient
drug profiles. Many adverse events are avoidable and the ability for prescribers and dispensers to refer
to complete drug profiles is expected to contribute to significant reductions in these events. Increased
compliance and appropriate use-behaviour by patients is another expected benefit. The design process
relied on collaborative engagement with the CeRx pan-Canadian Standards Group (CeRx-pCSG). This
group consisted of health care providers, vendors, jurisdictional representatives as well as a
representative from the Canadian Institute for Health Information.
This implementation guide is intended to provide information to all interested stakeholders and guidance
to the Message Specification implementors. In both cases, it is important to remember that this
messaging standard (as well as the whole electronic health information process) can be considered an
additional tool to be used in a “whole” set of tools available, including personal skill sets and other
diagnostic entities, to be used to provide better healthcare. Its usage is meant to enhance and
supplement but not replace an individual prescriber or dispenser’s professional judgement or healthy
sense of clinical suspicion, especially as it pertains to the safety of patient care delivery. Prudent clinical
practice currently, as well as likely in the future, is that prescribers will correlate information from available
sources with direct patient interaction and questioning. As such, we envision this messaging standard as
providing prescribers/clinicians/dispensers access to an electronic tool for obtaining information of a
patient’s drug status including pertinent historical data and present decision support tools.
Copyright © 2006 - Canada Health Infoway 1 Implementation Guide Volume 2 - Clinical Records
II INTRODUCTION
2.1 Scope
The scope of this document is restricted to common topics across all Infoway standards Message
Specifications such as glossary, data types, message wrappers and CMETs (Common Message Element
Types). Companion documents, in conjunction with this volume, make up the complete Message
Specification for any particular implementation.
In addition, jurisdictions that implement these Message Specifications may provide additional guidance to
implementors such as communication protocols, business rules, and policy guidelines. Implementors
should seek out this additional guidance as it will materially affect any implementation.
2.2 Purpose
The Implementation Guide defines and references the Message Specification and provides
implementation, compliance and conformance guidelines for use in developing software that conforms to
the Message Specifications developed by Infoway through the Standards Collaboration Process (SCP). It
will also provide additional information necessary to implement the developed Message Specifications
such as business rules not specified through the message constructs. However, implementors are
strongly encouraged to review any additional guidance provided by implementing jurisdictions.
2.3 Audience
The audience for this document are organizations implementing these Message Specifications including
jurisdictions seeking to establish Electronic Health Records (EHR) or jurisdictional applications (e.g. Drug
Information Systems (DIS) or Jurisdictional Laboratory Information Systems (JLIS)), as well as software
developers building or enhancing systems that will interoperate with such EHR solutions.
This audience includes technical and business readers who will use the guide to develop implementations
and validate that these implementations conform to the Message Specifications and to the requirements
of the associated stakeholder organizations.
For those readers who do not have an understanding of the HL7 Reference Information Model (RIM), the
HL7 methodology, the authors recommend that the reader refer to the HL7 Release documentation
1
(available to HL7 members at www.hl7.org) to augment this Implementation Guide. A brief background
on HL7 Methodology has been included in Appendix A – How to Read the Scope & Tracking Framework.
2.4 Document Assumptions

The following assumptions were made in the preparation of this document:
• Establishment of health care related solutions in Canada is an area of independent provincial
jurisdiction. As a result, the specific application of this Message Specification may vary between
jurisdictions. Efforts have been made in the development of the Message Specification to minimize
the need for such variation. However, while it is assumed that jurisdictional implementation guides
will augment this publication, where applicable, guidance is provided to help maintain consistency.
• The implementation of this Message Specification will/may impact workflows. As a result, regulatory
bodies in each jurisdiction may need to respond to the associated business challenges through
adjustment of the applicable professional practice guidelines. Their response may impact the
business implementation and could inform the technical deployment of the Message Specification.
1
This document contains information for which copyright is held by Health Level Seven, Inc. This includes the HL7 components of
the CeRx specification, once submitted and approved through the HL7 ballot process. Implementors of the standard (those
developing software or otherwise making use of the specification) are required to be members of either Health Level Seven Inc.,
HL7 Canada 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. i.e. Only those who require this document to develop, configure or test
interfaces for compliance with the CeRx specification require HL7 memberships.
• It should be noted that some materials necessary for the implementation of these specifications are
available directly from HL7 (www.hl7.org), as including them in these specifications is unnecessary.
Specific references to these materials are called out in the specifications, but include the HL7 XML
Implementable Technology Specification (ITS), abstract data types, transmission protocols, v3 guide
and refinement and localization protocols.
2.5 Related Documents

Note to Reader: Some documents are noted with a PN502 prefix and some documents are
noted with an SC-CA (Infoway Standards Collaborative – pan-Canadian) prefix. The PN502
reflects a document produced by the CeRx project (PN502 is the project identifier for CeRx),
whereas the SC-CA prefix is intended to reflect a document that will form part of a cross-
project or cross-domain documentation package, applicable to all pan-Canadian Message
Specifications.
At the time of this publication, some SC-CA documents are still noted as PN502 (e.g. data types), as they
have not undergone a formal review by other Message Specification projects. It is the intention that these
documents, where they span multiple domains and/or projects, will be renamed with the SC-CA prefix
once this review has occurred.
For additional information, see the Standards Development Documentation Framework document & the
section on the Implementation Guide Documentation Framework (in this document) for additional
guidance and information on document prefixes.
Document Name File Name Comments

Implementation Guide – SC-CA-0006-EN - General introduction to the Implementation Guide
Volume 0 – Overview Implementation Guide - Documentation Framework and overall guidance
Volume 0 – Overview – that span individual volumes of transactions.
yyyymmdd.pdf
Implementation Guide – SC-CA-0006-EN - Implementation guidance for Pharmacy related
Volume 1 – Pharmacy Implementation Guide - transactions (e.g. Create Rx Order, Stop
Volume 1 - Pharmacy – Prescription).
yyyymmdd.pdf
Implementation Guide – SC-CA-0006-EN - Implementation guidance for shared transactions
Volume 3 – Shared Implementation Guide - (e.g. Mask Record, Record/Revise/Remove Patient
Transactions Volume 3 – Shared Keyword).
Interactions –
yyyymmdd.pdf
Other Implementation Guide Volumes, as
developed, such as Laboratory, Client Registry,
Provider Registry, Immunization, Outbreak
Management.
2.6 External Supporting Documents

Document Name File Name Comments
Standards Development SC-CA-0001-EN - Documents the suite of artifacts that make up the
Documentation Standards Development Message Specifications as well as supporting
Framework (SDDF) Documentation documents such as Implementation Guides and
Framework – project deliverables such as Package Overviews.
yyyymmdd.pdf
Glossary SC-CA-0003-EN - Provides a list of common technical and business
Glossary – terms used throughout the Message Specifications.
yyyymmdd.pdf
Scope and Tracking PN502-PM99-EN - This spreadsheet is a pivotal document in that it
Framework Scope & Package ties together the scope of the Message
Tracking Framework - Specifications across Implementation Guide
yyyymmdd.xls Volumes from a transaction perspective, through to
interactions and finally to messages.
Vocabulary Status PN502-3004-EN - This file contains all of the valid code sets
Worksheet Vocabulary Status - referenced in these Message Specifications.
yyyymmdd.xls
Data Types PN502-3002-EN - Data This file contains all of the valid data types (e.g.
Types - yyyymmdd.pdf address) referenced in these Message
Specifications.
Volume 2 – Message PN502-2003-EN - CeRx This zip file contains all message models in Visio
Models – Visio View Models - Visio Models - format that comprise the Message Specifications
yyyymmdd.zip referenced in this document.
Note to Reader: This document includes artifacts

from all Implementation Guide Volumes.
Volume 2 – Message PN502-2003-EN - CeRx This zip file contains all message models in Word
Models – Word View Models - Word View - format that comprise the Message Specifications
yyyymmdd.zip referenced in this document.

Volume 2 – Message PN502-2003-EN - CeRx This zip file contains all message models in MIF
Models – MIF View Models - MIF - (Message Interchange Format) format that
yyyymmdd.zip comprise the Message Specifications referenced in
this document.

Volume 2 – XML PN502-2004-EN - XML This zip file contains all XML schemas for message
Schemas Schemas (with MIF types and interactions that comprise the Message
data) - yyyymmdd.zip Specifications referenced in this document.

Volume 2 – Message PN502-2005-EN - CeRx This zip file contains the message worksheets in
Worksheets – Excel Message Worksheets - Excel format that comprise the Message
View Excel View - Specifications referenced in this document.
yyyymmdd.zip
Volume 2 – Message PN502-2005-EN - CeRx This zip file contains the message worksheets in
Worksheets – Table Message Worksheets - Table View format that comprise the Message
View Table View - Specifications referenced in this document.
yyyymmdd.zip
III STANDARDS DEVELOPMENT DOCUMENTATION
FRAMEWORK
The Standards Development Documentation Framework (SDDF) is an outline of documents used in the
creation of a pan-Canadian HL7 v3 Standard. It includes definitions and descriptions for all business
documents (e.g. business model, issue, discussion documents and use cases) and technical documents
(e.g. HL7 message definitions) necessary to give suitable direction for implementors of these standards.
Note to Reader: The SDDF is depicted graphically below and is further described in SC-CA-
0001-EN - Standards Development Documentation Framework - FINAL - yyyymmdd.
Artifacts/Documents
Project Development Strategy
Development Methodology Package Artifacts/Documents (n Packages)

Infoway Style Guide Business Model Constrains & Defines
(SC-CA-1001)
Describes (ppppppp-0002) Package Overview
(For review / Cross references (ppppppp-2001)
development
Standards Development purposes) Tooling Plan
Document Framework
Elaborates
(SC-CA-1002)
Constrains
(SC-CA-0001)
Glossary
(SC-CA-0003) Business Message Artifacts
Issue Detail Reports + Storyboard(s)

Discussion Documents Standards Development Cross references (ppppppp-2002)
(ppppppp-0005) Tracking Logs
(action, issue, decision,
assumption)
(ppppppp-0004)
Normative Message Artifacts
Message Models (Visio, Word, MIF)

Scope &Tracking Cross Package Artifacts/Documents (SC-CA-2003)
Framework
(SC-CA-0008)
Datatypes XML Schemas (IN + MT)
(SC-CA-3002) (SC-CA-2004)
Publication Database Uses/Creates

Administrative Documents Message Worksheets (Excel, Table)
(SC-CA-3003)
(SC-CA-2005)
Agendas / Minutes /
Meeting Presentations
Legend (ppppppp-4001) Vocabulary Status Worksheet
(SC-CA-3004)
SC-CA = Infoway HL7 Process Artifacts
Standards Colloborative
ppppppp = Project Vocabulary Overview Harmonization Proposals
Uses (ppppppp-2006)
identifier such as HS50102 (SC-CA-3004)
HL7 Artifact New content

(SC-CA-0006)
New content
Non-Normative Ballot Strategy

Material (ppppppp-0007) Influences
As of 06 Apr 23
Figure 1 – Standards Development Documentation Framework (SDDF)
3.1 Document Naming Conventions

All documents identified in this framework are prefixed either by SC-CA or ppppppp. The former is used
to indicate that the document is a cross-project or cross-standard document to be shared across
standards development projects. The SC-CA represents the Infoway Standards Collaborative
organization, which operates at a pan-Canadian, hence the –CA, level.
The ppppppp documents are intended to be standards project specific in nature, such as storyboards,
business models and tracking logs. The concept of packaging is also project dependent and is used to
group materials for presentation to pan-Canadian Standards Groups (pCSG) for review and
consideration. After a project is completed, all project identifier references and packages are retired and
may be incorporated into the Implementation Guide documentation.
Note to Reader: Some documents noted as SC-CA have been initially developed by the
CeRx project and are known using the prefix PN502. Efforts have been made to change
these prefixes to SC-CA where appropriate. Some materials may still contain PN502 prefixes,
but these will be changed over time as project deliverables are reformed into the new
Implementation Guide Documentation Framework (see next section).
IV IMPLEMENTATION GUIDE DOCUMENTATION
FRAMEWORK
This Volume is part of an overall Implementation Guide Documentation Framework that documents
implementation guidance for a full suite of HL7 version 3 Message Specifications. This framework is
depicted in the following diagram.
Note to Reader: The Implementation Guide Document Framework noted below depicts the
official suite of documentation generated for the Message Specifications. It is anticipated that
implementors may augment this documentation with additional clarity, policies, legislative
requirements and business rules that are pertinent to that implementation.
Implementation Guide Documentation Framework
Infoway Style Guide

Describes
(For review / Cross-Volume Artifacts Message Specification Artifacts
Standards Development
development Implementation Guide
purposes) Message Models (Visio, Word, MIF)
Documentation Framework Reference Volume 0 Wrappers, CMETs (SC-CA-2003)
(SC-CA-0001) (SC-CA-0006) Payloads
Glossary
(SC-CA-0003)
XML Schemas (IN + MT)

(SC-CA-2004)
Scope & Tracking Payloads

Framework
(SC-CA-0008) Reference Message Worksheets (Excel, Table)
Implementation Guide Reference
(SC-CA-2005)
Volume 1-n - domain x
(SC-CA-0006)
Vocabulary Status Worksheet
Reference (SC-CA-3004)
Datatypes
(SC-CA-3002)
Supporting Business Artifacts

Legend (Referenced by Specific Volume)
SC-CA = Infoway Business Model

Standards Colloborative (e.g. Pharmacy-0002)
ppppppp = Project
identifier such as HS50102
Issue Detail Reports +

HL7 Artifact Discussion Documents
(e.g. Pharmacy-0005)
Non-Normative
Material
As of 06 April 15
Figure 2 – Implementation Guide Documentation Framework
Major functional components of the Implementation Guide Documentation Framework are described in
more detail in the following sections.
4.1 Implementation Guide Volume 0 – Overview
Volume 0
(SC-CA-0006)
This volume serves multiple purposes, including:

• Introduction to the Implementation Guide Documentation Framework;
• Explanation of key cross-volume documents such as the glossary, datatypes, scope & tracking
framework and vocabulary; and
• Description of key cross-standard considerations such as security & authentication, communication
protocols, conformance & compliance strategies, OID (object identifier) strategy and standards
maintenance.
From another perspective, this volume serves to house any artifact or discussion that spans domain
volumes, where examples of domain volumes include Pharmacy, Laboratory, Clinical Records, Client
Registry, etc.
4.2 Implementation Guide Volumes 1-n – Domain Volumes

Volume 1-n - domain x
(SC-CA-0006)
These volumes encompass materials specific to a particular domain such as Pharmacy, Laboratory,
Client Registry, etc. Of note, transactions are documented in one and only one Domain Volume.
Common components such as message wrappers and CMETs are documented in Volume 0 – Overview.
Implementors will likely need to include transactions from multiple Domain Volumes in order to meet
specific implementation requirements. For example, a Drug Information System may be complemented
by Client Registry and Claims Adjudication systems to form a particular implementation. Transactions
that would support this implementation would be drawn from multiple Domain Volumes (e.g. Pharmacy,
Client Registry, Claims & Reimbursement).
While some projects such as CeRx and RC5 have been used as vehicles to create Message
Specifications and implementation guidance for a large number of transactions, these transactions may
not all fit under one Domain Volume. For example, the CeRx project has developed materials for Volume
1 – Pharmacy, Volume 2 – Clinical Records and Volume 3 – Shared Interactions.
4.3 Message Specification Artifacts
Message Specification Artifacts
Message Models (Visio, Word, MIF)

(SC-CA-2003)
XML Schemas (IN + MT)

(SC-CA-2004)
Message Worksheets (Excel, Table)

(SC-CA-2005)
Vocabulary Status Worksheet

(SC-CA-3004)
Datatypes
(SC-CA-3002)
These artifacts comprise the Message Specifications and are governed by strict conformance rules, as
defined by HL7. Therefore, only artifacts under the guise of conformance are considered part of the
Message Specifications. Other artifacts, such as a glossary and implementation guide are considered
informative to the Message Specification and provide additional guidance towards implementation of
these Message Specifications.
A Message Specification can be viewed as a complete set of fully constrained artifacts such that
developers can build interfaces compliant to those artifacts without the requirement for additional artifacts.
Specifically, this will include: Message Types, CMETs, Datatypes, Trigger Events, Interactions, and
Application Roles. In addition, supporting vocabulary code sets will also be included in the Message
Specifications.
4.3.1 Message Models

Message Models in HL7 include the Domain Message Information Model(s) or DMIM(s), Common
Message Element Types or CMETs. These models are depicted in the following forms:
Visio Models
These represent the message model in a graphical form as per HL7 v3 modeling guidelines. These
models are referenced as part of the Scope & Tracking Framework (see above) and contain all the
conformance rules (e.g. mandatory, populated, required, CNE/CWE, repetitions, etc.).
MIF Models
MIF files are the formal “programmatic” representation of HL7 messages, wrappers and CMETs. They
are used to generate Schemas and Message Worksheets. They may be used by implementors to import
validation requirements for different models into their tools, for custom schema generation, etc.
Word Models
In addition to the Visio representation of the message models, a Word version is also provided that is
automatically generated from the Visio model. These Word versions, or Message Model Design
documents as they are sometimes referred to, represent the complex modeling constructs in a form that
is more presentable and acceptable to clinical and business readers. In these documents, each attribute
includes a definition, rationale for its use in the model and optionally notes to implementors and mapping
notes.
4.3.1.1 How to Read the Word Message Models

Please refer to Appendix B –How to Read the Word Message Models for a detailed description of how to
read the Word Message Models.
4.3.2 XML Schemas

The XML schemas provide the technical rules for individual message models (Message Type XML
schemas) as well as a consolidated schema for a specific interaction or flow of data between systems
(Interaction XML schema). The latter represents a “stitching” of individual Message Type XML schemas
to make up a specific interaction, including transmission wrappers, control act wrappers and message
payloads.
4.3.3 Message Worksheets

Message Worksheets represent serialized RMIMs that, aggregated into an interaction, are capable of
being sent across the wire from one system to another. All message constraints (e.g. mandatory,
vocabulary, etc.) that would apply to the message are applied to the message type. This artifact takes on
2 forms: an Excel view suitable for mapping exercises and a Table view, both produced automatically by
the HL7 tooling.
4.3.4 Vocabulary Status Worksheet

The Vocabulary Status Worksheet describes the codes that are to be used for each vocabulary domain
(e.g. gender). In some cases, only a subset of the complete code set is included in the Vocabulary Status
Worksheet for brevity purposes. In some situations, external, non-HL7 code sets such as SNOMED CT®
and LOINC® are indicated as appropriate code sets for a particular vocabulary domain.
4.3.4.1 How to Read the Vocabulary Status Worksheet

Please refer to Appendix B – How to Read the Word Message Models for a detailed description of key
aspects of the Vocabulary Status Worksheet.
4.3.5 Datatypes
Datatypes are used to convey how a particular data element in the RIM, DMIM or RMIM is expressed.
Datatypes can be as simple as ST for string, to complex like AD for address to extremely complex like
GTS to specify concepts such as “take 3 pills 6 times a day starting on Oct. 1, 2004. The datatypes in
HL7 are far too complex for use in many implementations and have been constrained for use in the CeRx
standards. This document acts as a central source of information for constrained datatypes.
4.4 Cross-Volume Artifacts
Cross-Volume Artifacts
Glossary
(SC-CA-0003)
Scope & Tracking

Framework
(SC-CA-0008)
These documents represent materials that are germane to all Implementation Guide Volumes. The
intention for these documents is to consolidate information in one location and reference it as required by
each of the Implementation Guide Volumes. Instructions for reviewing or reading these documents is
provided here, as appropriate, to assist readers in reviewing key cross-volume content.
4.4.1 Glossary
This document will contain definitions for all technical and business terms used across all Message
Specifications and implementation guide documentation.
4.4.2 Scope & Tracking Framework

This framework is a pivotal document in that it ties together the scope of the Message Specifications
across Implementation Guide Volumes from a transaction perspective, through to interactions and finally
to messages. It also includes summary tracking information for all key artifacts and a repository for the
HL7 Interaction (or Dynamic) Models.
4.4.2.1 How to Read the Scope & Tracking Framework

Please refer to Appendix A – How to Read the Scope & Tracking Framework for a detailed description of
key aspects of the Scope & Tracking Framework.
4.5 Supporting Business Artifacts
Supporting Business Artifacts
(Referenced by Specific Volume)
Business Model
Issue Detail Reports +

Discussion Documents
A specific Implementation Guide Volume may reference external documents such as a business model
and/or issue detail reports and/or discussion documents. These may not be present for all Volumes, but
if present, will provide additional guidance and context to implementors.
4.5.1 Business Model

The Business Model document contains information summarizing the overall context as well as outlining
those business situations for which more detailed information is available by way of story boards (e.g.
table listing the story boards and grouping them in some reasonable manner that will facilitate cross
referencing).
4.5.2 Issue Detail Reports + Discussion Documents

As a Message Specification is developed, issues and discussion documents are prepared and reviewed
by stakeholders. These documents provide additional guidance to implementors and may be suitable for
inclusion in the final Implementation Guide documentation. Efforts are made to include these materials
inline with other documentation, but on occasion, these documents are better suited as externally
referenced materials.
V ASSUMPTIONS
The following assumptions have been identified as applicable to this Implementation Guide Volume. In
many situations, these assumptions have been copied into the Transactions section of this document if
they are applicable to that specific transaction, in order to provide better guidance to implementors of the
particular transaction.
Readers should note that overarching, cross-Domain Volume assumptions are also noted in SC-CA-
0006-EN - Implementation Guide Volume 0 – Overview. These should be consulted in order to obtain a
full view of assumptions that apply to the implementation of these Message Specifications.
Contraindication Contraindication checking will potentially occur at multiple levels, including

Checking the EMR, EHR and the Pharmacy.
Local medication issue managements can be sent to the EHR at the time
the Rx is created or the Rx is dispensed to help mitigate the number of
medication issues that need to be managed by the prescriber or dispenser.
However, there may be situations where the local contraindication checking

managements should be ignored if there is net-new information on the EHR.
For example, the EMR manages a medication issue for a drug that is no
longer being taken by the patient. Unknown to the prescriber, another
prescriber created a new Rx for the drug such that the local management is
null/void. One option to alleviate this circumstance would be to undertake
the full download of the profile prior to local contraindication checking.
Perhaps a better option, given that the EHR has all of the current information
on medications, allergies etc. would be to undertake contraindication
checking only at the EHR . This has the added benefit that all healthcare
providers e.g. physicians and pharmacists are using the same
contraindication checking system and version. It may also serve to
decrease costs of drug knowledge-bases, which can add significant costs to
an EMR system. It is recognized that this is a significant shift from current
practice and make take some time to achieve, if at all.
Contraindication It is assumed that contraindication checking will consider masked records.

Checking When communicating "issues" to the prescriber, masked data must not be
included.
Contraindication For issues detected by the EHR/DIS: Issues that require management
Checking (including any managements) must be stored on the EHR/DIS. Issues that
do not require management may or may not be stored on the EHR/DIS, at
the discretion of the jurisdiction.
For issues detected by a local system (e.g. EMR or PMS): Issues that
require management (including any managements) and issues that do not
require management may or may not be stored on the EHR/DIS, at the
discretion of the jurisdiction.
Contraindication EHR/DIS functions in jurisdictions will have a contraindication checking

Checking capability;
Data Use Patient id, name, gender and date of birth will be provided on the
prescription and/or dispense and/or other creation messages. In addition,
patient contact address and patient contact phone and e-mails may be
included in the message. These attributes are germane to that prescription
only and must not be used to update a client registry i.e. while their client
registry address is still accurate, the address in relation to this prescription
may be different from the registry address.
There are some situations where the patient attributes can be different
between prescribing and dispensing. For example, prescribed using regular
registry address and dispensed using alternate address (e.g. vacation,
staying at parent's home).
There are situations where these attributes, while different than a client
registry, are only accurate for the purposes of the prescription. In other
words, using these attributes for purposes other than managing
prescriptions must not be implemented.
If these attributes need to be updated in a client registry, an application must

use a client registry update message to make the change (not an Rx
message).
Assume that client registry functionality will exist and the submission of
pharmacy messages will not necessarily create patient records (in an
EMPI/CR) application on the fly.
Diagnosis The prescription supports (at the level of "populated") sending the
indication(s) for the Rx in question. Medical conditions are not supported as
a component of the prescription but are available through queries, which
may be role based and /or by consent only. Only those with the authority to
diagnose as per their Standard of Practice may enter medical conditions in
the role of author. Others may be able to record the information through
delegation.
It is recognised that not all indications are appropriate for recording in the
patient's EHR e.g. preliminary indication.
Identifiers Identifiers are generally assigned by the EHR. This includes prescription
identifiers, allergy record identifiers and immunization record identifiers.
The impact of this assumption is that locally assigned identifiers from source
systems (e.g. EMR and Pharmacy systems) are merely additional identifiers;
the record’s primary identifier remains the identifier assigned by the EHR.
Source system identifiers, if provision has been made for these in a

message, are subject to all HL7 V3 identifier rules (i.e. need to be globally
unique by way of an OID or other sanctioned mechanism).
Some exceptions:
To support current pharmacy labeling practice and to minimize impact on
pharmacies, dispense event identifiers can be provided by the pharmacy
system and should be stored by the EHR/DIS. These local dispense
identifiers can be used, if provided on the initial dispense event, as query
parameters for that dispense when querying the EHR/DIS.
Queries Query responses will reflect current data in the EHR// (i.e. current data).
Historical or point-in-time data from the EHR/DIS will be supported through
specialized query history transactions.
Queries There will be no messaging support through the pharmacy messages to

transfer complete medication histories (or other components of the EHR)
from one EHR to another to support the moving of patients between
jurisdictions.
This is a generic problem that requires a more global approach.
VI BUSINESS MODEL
The purpose of the Business Model is to provide a business overview and describe the related processes
for the development of messaging standards pertaining to clinical and drug-related transactions.
A Business Model specific to this Implementation Guide Volume was not created. Storyboards describing
the clinical (business) context for transactions in this volume, however, have been produced and are
noted below.
Note to Reader: The proposed application roles in the storyboard diagrams in this section are
solely for illustrative purposes and are intended to reflect the fact that the broader EHR
contains multiple components including, for example, ePrescribing support. These
components are called out in some diagrams to make a specific point. It is important to note
that the constructs are purposefully abstract in order to remain silent on the specific EHR
architecture and to allow the needed implementation leeway.
6.1 Storyboards
6.1.1 Record Immunization
Storyboard ID: DOIZ_ST000210; Status: Transferred to HL7 Ballot
Purpose
To illustrate the interactions involved when a provider administers immunizations.
Introduction
This storyboard describes the situation where a physician records immunization events on a centeralized
system.
Story Event
Sarah Smith comes to the office of Dr. Pam Primary to have her four month old infant examined and to up
date her immunizations. Dr. Primary performs a focused history and examination on the infant and then
queries the EHR to determine what immunizations the infant has had and what is now required.
The EHR returns a response indicating that baby Smith has had her first dose of Pentacel and also her
first dose of Prevnar. At age four months, the infant now requires her second dose of both Pentacel and
Prevnar. Both of these vaccines are administered to the infant in the thigh, by the nurse.
The nurse then records the dose number and the lot numbers of both vaccines into the EHR/DIS and the
EMR
Interaction Diagram
Record Immunization
DOIZ_ST000210
Immunization
EHR System
Recorder / Seeker
Immunizations query
POIZ_IN020010
Immunizations query response

POIZ_IN020020
Record immunization request

POIZ_IN010020
Record immunization request accepted

POIZ_IN010030
Figure 3 – Interaction Diagram: Record Immunization
Flow of Events
1. Dr. Primary opens the EMR for Baby Smith
2. Dr Primary records the data from the focused history and examination of Baby Smith.
3. Dr. Primary queries the EHR/DIS to obtain the most recent immunization information for the infant
4. She determines that second doses in the primary series of Pentacel and Prevnar are needed
nd
5. Dr. Primary’s nurse administers the 2 doses of Pentacel and Prevnar to the infant and records the
information into the EMR in the clinic.
6. The EHR/DIS is updated by the EMR that the second doses in the series have been administered.
6.1.2 Recording Patient Observations
Storyboard ID: SB-55; Status: NOT Transferred to HL7 Ballot
Purpose
To demonstrate the recording of basic patient observations.
Introduction
To illustrate the recording of basic patient observations on the EHR/DIS.
Story Event
Adam Everyman presents to his Family Physician Dr. Primary for a routine examination. Following his
registration with the front desk, he meets with the Family Practice nurse who asks to weigh him and she
notes the weight at 68 kilograms and his height at 1.84 metres. She then calculates his BMI using her
EMR at 25. The nurse then draws a sample of blood to determine his blood sugar and his haemoglobin,
which are 5.4 mmol/L and 142 g/L respectively.
The nurse then records these patient observations on the EHR/DIS prior to his undergoing his physical
examination by the physician.
Interaction Diagram (Note: Interaction identifiers in the diagram below may not be correct)
Figure 4 – Interaction Diagram: Recording Patient Observations
Flow of Events
1. Patient registers for his examination
2. Family practice nurse makes basic patient measurements, weight, height, blood sugar and
haemoglobin
3. The patient observations are recorded into the EHR/DIS
6.1.3 Recording Patient Medical Condition
Purpose
The Storyboard illustrates how a physician would record a medical condition on the EHR/DIS.
Introduction
Recording of a Medical Condition on the EHR/DIS.
Story Event
Eve Everywoman presents to her primary care physician because she has been experiencing increased
thirst and loss of weight; she has a family history of diabetes and she fears that she may herself have the
affliction.
Dr. Peter Primary takes a focused history and performs a brief focused examination; he then orders a
series of laboratory investigations, which return and indicate that indeed, Mrs. Everywoman has diabetes,
as her fasting blood sugar is 14.5 mm/L. The dietician seconded to the clinic instructs her and she is then
told to return in one week following her diet treatment to determine if she will need medication to control
her blood sugar.
Dr Primary then submits a request to record a medical condition on the EHR/DIS; he has discussed this
with Mrs. Everywoman and she has no objection to this condition being recorded on the EHR/DIS and
available to other healthcare providers involved in her care.
Figure 5 – Interaction Diagram: Recording Patient Medical Condition
Flow of Events
1. Dr. Primary opens the record for Eve and notes that she has a new condition
2. Following the examination and with Eve’s consent, Dr. Primary enters a new medical condition –
Diabetes mellitus Type 2.
6.1.4 Recording Patient Allergic Reaction
Purpose
To demonstrate recording of an allergic reaction on the EHR/DIS.
Introduction
Recording of an Allergic Reaction on the EHR/DIS.
Story Event
Adam Everyman has developed a severe sore throat and a fever and due to the time of day, he goes to
an Urgent Care setting where he is examined by a physician and prescribed a ten-day supply of
amoxicillin for a Strep throat which has been confirmed by Quick Strep Test in the Urgent Care Centre.
Following the administration of the second capsule of amoxicillin, Adam develops a marked macular rash
over his entire body and has considerable itching as a result of this. Adam takes no more of the
amoxicillin and he visits his primary care physician the next day.
Dr. Pam Primary is his Primary Care Physician. She takes a focused history and performs a brief
physician examination to be sure there are no respiratory symptoms and advises Adam that he is
suffering an allergic reaction to amoxicillin. She submits a request on the EHR/DIS to stop the amoxicillin
and then submits a notice to the EHR/DIS to indicate that Adam suffers a Penicillin Class Allergy.
Dr. Primary then prescribes Sulphamethoxazole 800mg/Trimethoprim 160 mg to deal with the remainder
of the streptococcal sore throat.
Figure 6 – Interaction Diagram: Recording Patient Allergic Reaction
Flow of Events
1. Adam presents to Dr. Primary with an acute whole body rash following a prescription of amoxicillin
2. Dr. Primary opens the record for Adam
3. Dr. Primary confirms a diagnosis of acute penicillin allergy and discontinues the Amoxicillin
4. The doctor sends a notice to the EHR/DIS to stop the Amoxicillin
5. The doctor submits a notice to the EHR/DIS indicating that Adam has a Penicillin Allergy
6. The doctor then submits a notice to the EHR/DIS to create a prescription for Bactrim for five days
6.1.5 Recording Professional Service
Purpose
On occasion, a health care provider will provide a professional service that they want to document in a
patient’s record so that other health care providers serving the patient are aware of the service.
Introduction
This illustrates a scenario where a health care provider (pharmacist) undertakes a professional service
and decides that it is important that it be recorded in the patient’s health record.
Story Event
A new medication has been ordered for Eve Everywoman, an elderly woman who is taking several other
prescriptions for a number of chronic and acute indications. When Eve comes to the Good Neighbor
Pharmacy to pickup the new medication, Sue Script, the pharmacist on duty undertakes a dialogue with
Eve about the medication. The new medication has a somewhat complex dosage regimen. During the
dialogue, Eve seems apprehensive about taking the medication properly. She states that “I am taking so
many drugs; I know I must be getting them mixed up”. Sue expands the dialogue to discuss Eve’s
broader concern about her medication. As a result of the dialogue, Sue suggests that she and Eve meet
to further review Eve’s medication and help alleviate Eve’s concerns. Eve agrees and a time for the
consultation is established.
At the appointed time, Eve and Sue meet to review Eve’s medications. At Sue’s suggestion, Eve has
brought all of her medications with her. Sue begins by reviewing these and discovers a number of partly
used prescriptions that Eve is no longer taking. Sue offers to have these medications destroyed and Eve
agrees. Sue and Eve then discuss each on Eve’s medications, why Eve is taking them, how she should
take them and when she should take them. Sue makes notes on each of the prescriptions for Eve to take
away but Sue is still concerned that Eve is confused and may encounter problems. Sue and Eve discuss
a number of options and agree that they will try a period using compliance packaging. Eve agrees that
she will purchase the compliance packages, Sue will arrange that one will be filled weekly by the
pharmacy staff and Eve will pick up the filled package once a week. Sue also suggests and Eve readily
agrees that they will meet by telephone one a week for a period of time, to insure that Eve is managing
her medications appropriately.
After Eve leaves the pharmacy, Sue documents the encounter and the actions for her records. As Eve
sees a number of specialists for her chronic conditions, Sue decides that she will record the encounter in
Eve’s electronic record so that other health care providers can be made aware of the discussions and
actions.
Figure 7 – Interaction Diagram: Recording Professional Service
Flow of Events
1. In a dialogue about a new prescription, the pharmacist ascertains that the patient is confused about
her entire medication regimen.
2. An appropriate time for a consultation is set
3. The pharmacist and patient meet and review the medications
4. A course of actions is set
5. the pharmacist documents the consultation in the patient’s electronic medical record
6.1.6 Recording Patient Adverse Reaction
Purpose
To demonstrate how an adverse reaction is recorded on the EHR/DIS.
Introduction
This illustrates a scenario where a health care provider needs to record an adverse reaction to a
prescribed drug.
Story Event
Eve Everywoman has received a prescription for her elevated cholesterol from a cardiologist to whom she
has been referred; she suffers from atherosclerotic heart disease and diabetes and has recently been
found to have elevated cholesterol. The cardiologist has prescribed Lipitor 40 mg daily and has given her
a month’s supply of the drug. She has started the medication and now finds that she has very painful
cramps in her legs that have caused her to stop walking. She visits Dr. Pam Primary with this complaint.
Dr. Primary takes a focused history and performs a brief physical examination and determines that Eve
suffers from an adverse reaction to the Lipitor in the 40 mg per day dose. This is a common finding in her
practice and she deals with it by reducing the dose of the medication by half and asks Eve to return in two
weeks to determine if the change in medication has reduced the cramping.
Dr Primary then records on the EHR/DIS that Eve has had an adverse reaction to the Lipitor in the dose
of 40 mg per day. The EHR/DIS indicates by return message that the advice has been accepted.
Figure 8 – Interaction Diagram: Recording Patient Adverse Reaction
Flow of Events
1. Eve visits the Primary care physician with the complaint of cramps following the administration of
Lipitor 40 mg daily
2. Dr. Primary opens the clinical record for Eve Everywoman.
3. Dr. Primary takes a history and performs a physical examination to determine that the Lipitor is the
cause
4. Dr. Primary changes the dose
5. Dr. Primary sends a message to the EHR/DIS indicating that Eve has sustained an adverse reaction
to the Lipitor in the dose of 40 mg daily
VII GENERAL IMPLEMENTATION CONSIDERATIONS AND
GUIDELINES
During the development of the Message Specifications, implementation considerations and guidelines
were identified. The high level considerations have been included in this Implementation Guide in order
to assist implementors. Implementation considerations related to specific attributes within messages
have been clearly noted within the message documents and are not included in this section of the Guide.
The developers of the Message Specification do not assert that the set of implementation considerations
and guidelines are complete – particularly in areas of professional practice.
With respect to regulations, nothing in the description of messages or attributes should be considered a
regulatory statement. In fact, the regulatory regime in place at publication time does not recognize the
validity of an electronic prescription.
Every effort has been made to ensure that guidance related to specific message interactions addresses
those considerations not normally specified by the HL7 version 3 message development framework
(MDF).
7.1 Stakeholder Considerations

Healthcare delivery in Canada is a complex ‘business’ that both affects and is affected by a large number
of stakeholders groups. This is aptly demonstrated by the coming together of systems that deliver
medications and devices, and information on the same, to patients. The following sections delineate
some of the considerations and guidelines that arose from the deliberation in the development of these
and guidelines are complete.
7.1.1 Public
Several considerations and guidelines are overarching and should be understood by all jurisdictions
seeking to implement these Message Specifications, as well as by any associated stakeholders and
regulatory bodies. These include the following:
• None identified.
7.1.2 Implementors of EHR/DIS Systems

The following considerations and guidance apply to Implementors of such EHR systems:
• Implementors need to be aware of the concerns raised by members of the CeRx pan-Canadian
Standards Group (CeRx-pCSG) with respect to access to information; transparency; audit; traditional
roles and responsibilities of the various health care providers; and custodial responsibilities for the
information. The standards group undertook their review and made recommendation regarding this
Message Specification based on a series of significant assumptions which included the following:
Implementations of EHR/DIS solutions must include the establishment of strong governance models
which involve key regulatory agencies and which establish appropriate stewardship and transparency.
The governance framework should encompass not only the EHR/DIS but also those systems which store
related information such as client registries, consent management systems, etc.
Implementors need to ensure that patients have a full and unencumbered access to who has accessed
their record and when. Patients are the final check and balance in a transparent system, especially if
stewardship and governance of the Message Specification takes new directions.
Implementors may wish to consider guidelines with respect to the the persistence of data shared with
health care providers, as well as possible requirements of access audit of any shared information stored
in a health vare providers system.
• A range of decisions are required related to security, including but not limited to:
The types of activities permitted by various classes of users;
The information shown to various users of the system;
The extent to which patients may manage the accessibility of information in their profile;
• A range of decisions will need to be made regarding business rules implemented within the EHR/DIS.
These include but are not limited to the following:
The treatment of information that has been “nullified” or retracted at the EHR/DIS needs to be considered,
particularly as it relates to contraindication checking and visibility to queries. In general, it should be
noted that “nullified” or retracted does not mean that the associated record must be removed (in fact it
should generally be retained for audit purposes) but rather that it be flagged for or filtered from those
functions, applications and viewers who would not normally wish to consider such records.
There needs to be consideration of role-based access (security), perhaps to the level of access limited to
relationships between patients and individual, pre-identified providers. This may be covered through an
appropriate use of a consent model. This may have to take into consideration the effect of care having
been delivered by an organization – extending to all physicians working for that organization.
Certain message attributes may allow for defaulting values. Implementing jurisdictions may want to
provide direction to provider software management system developers with respect to the inclusion of
“automatic” defaults for certain attribute fields within their system.
The question of how new patients engaging the health system, such as those external to the jurisdiction,
will get an identifier from the EHR/DIS will need to be addressed. e.g. someone from Florida approaches
a physician or pharmacist. Will a physician or pharmacist be able to do this and/or be willing to do this.
From a prescriber’s perspective, would they alternately use a paper prescription in this circumstance.
Caution will need to be applied when using a patient name to verify a patient ID, given that individuals
may use multiple names. It may be necessary to use a number of possible cross checks, such as gender
or DOB and perhaps match two out of three.
Must consider and make rules with respect to the ‘masking’ of entries made in an EHR in error e.g. with
respect to the use, or not of a Retract Request message.
A generic retract capability is defined. This allows for the correction of errors such as a condition entered
against an incorrect patient, where the condition record effectively needs to be rolled back. In this
example, it would be anticipated that a corrected (new) condition record would be created with the correct
patient.
Systems will need to consider under what circumstances ‘retracts’ are permitted. For example,
• Who may retract an action? (e.g. the individual who posted the transaction, the system from
which the action originated, etc.)
• How long after an event is recorded may an action be retracted?
• Must retracts be performed in reverse order of the actions themselves?
• Implementors will likely need to provide mechanisms for end-users to find and invoke retract
transactions. Moreover, appropriate transaction numbers will need to be retained to support
the retract interaction.
• A range of decisions will need to be made regarding the operation of contraindication checking within
the EHR/DIS:
Carefully considering and documenting the extent to which contraindication checking consider active
prescriptions and non-prescribed medications (whether masked or not) in addition to dispensed drugs.
The CeRx project recommendation is that contraindication checking should include all active medications
whether prescribed or dispensed.
The threshold of alerts that will be forwarded during contraindication checking requires careful
consideration; too low a threshold (i.e. generate nuisance alerts) runs the risk of being ignored by the
prescriber (or may adversely impact uptake) while too high a level may result in harmful interactions being
missed. Jurisdictions should consider consulting the licensing bodies and/or prescriber stakeholders on
setting appropriate thresholds for each jurisdiction.
The extent to which local contraindication checking managements (i.e. management actions in response
to alerts issued by a local contraindication checking process in the EMR) are retained, used and
forwarded by the EHR will need to be determined.
Consideration should be given to including information in contraindication checking warning responses to
a Create Rx request highlighting missing information that could have improved contraindication checking
such as gender, date of birth or patient measurements. Care will need to be taken to minimize nuisance
alerts by raising these warnings only when appropriate; this may or may not be feasible depending on the
kind of drug database available.
The Message Specification provides flexibility in the entry of drugs, including the ability to enter a drug or
compound by name to accommodate situations where codes are not defined. contraindication checking
may have limitations in processing such non-coded drugs (either at prescribe or dispense time).
Consideration will need to be given to determining the active period for prescriptions as this will impact
not only contraindication checking but also queries. It is assumed that this is determined by a variety of
factors including: A specific Rx order expiry date; policies pertaining to stale-dating; the treatment type
attribute; policies pertaining to fills near the end or after expiry date and how these impact the active
period.
Consideration should be given to treating all alerts as having been managed, thus ensuring that all alerts
observed with a transaction (including warnings) will become part of the record and will be displayed as a
result of future queries. This may be a legal requirement, to know what issues were displayed to the
health care provider. A decision to not manage an issue may be as important as a decision to manage.
Dispenses for animals (pets, livestock) are clearly noted as such. While they are recorded against their
owner’s medication profile, they should not be included in or trigger any contraindication checking.
It has been noted that many ‘unclassified intolerances’ may be recorded as an intolerance rather than
allergy. Jurisdictions will need to consider this when implementing contraindication checking on allergies/
intolerances.
Careful consideration will need to be given to the length of time that “unknown” scripts are considered in
contraindication checking – for example, it may be reasonable to ignore inferred prescriptions since they
will have at least one dispense against them that can be considered during contraindication checking
processing.
• The Message Specification includes a rich series of functions related to privacy and consent
management. These functions assume a consent management infrastructure at the EHR/DIS
together with applicable data access policies. The establishment of this system and the associated
policies will need to consider variety of factors including the following:
Currently a trusted relationship exists between providers and their patients which may govern the access
to data in the non-automated world. This relationship should be considered in establishing data access
policies.
Jurisdictions may also need to consider the distinction between consent between two individuals
(patient/provider) as well as consent between an individuals and an organization (patient/health authority
or patient/hospital).
The practice of using shared User IDs exists on the real world situation based on practical realities. This
should be discouraged for individuals accessing the EHR record.
If the jurisdiction will support information masking by the patient, and if this is supported, a determination
will need to be made as to the mechanisms that will be used to allow access – keyword; consent;
emergency access. In addition, if masking is supported, the level of granularity that is supported needs to
be considered. With respect to masking drugs, can all drugs be masked; can certain classes of drugs be
masked e.g. AIDS drugs; can a single drug be masked. The business processes and mechanisms
around data access, including access by regulatory or law enforcement authorities, for investigative
purposes will need to be considered.
The masking security mechanism implemented at the EHR/DIS needs to consider the extent to which
masked access impacts the initial creator of the information.
The Message Specification enables “breaking the glass” type capabilities which are critical for providers;
jurisdictions will need to consider a number of factors including (a) the duration for which the “breaking
the glass” access is effective (each access or a for time period), (b) policies surrounding the use of this
function, (c) the extent of audit undertaken against uses.
The Message Specification enables “breaking the glass” type capabilities; jurisdictions will need to
consider a number of factors including (a) the duration for which the “breaking the glass” access is
effective (each access or a for time period), (b) policies surrounding the use of this function, (c) the extent
of audit undertaken against uses.
The extent to which clinicians may retain downloaded information and, if allowed, track individual
accesses to that information (i.e. who, when, why) once downloaded, must be carefully considered and,
while potentially covered by existing legislation, may require the establishment of appropriate policies and
agreements. (e.g. Can a Pharmacy Management System mirror the function of an Electronic Medical
Record system).
• Implementors must keep in mind that the Message Specification, including the associated application
roles, is not likely to be a full reflection of the functionality profile or requirements for the various
applications engaged in a full business solution. For example, an EMR or Pharmacy System can
reasonably be expected to interact with provider and/or client registry data through the applicable
interactions. Consequently, EHR/DIS implementors may need to define application conformance
profiles that aggregate application roles from one or more HL7 standards domains. In addition,
EHR/DIS implementors may or may not wish to specify additional functional and/or operational
requirements which are not related to the messaging interactions.
• There are a number of messages where the EHR/DIS acts to forward a message received from one
provider application to a second application. As applications may not always be on-line in real time,
the EHR/DIS needs to support:
A queue where messages can be stored awaiting retrieval by the receiving application;
The ability to send a ‘message waiting’ alert when messages are in the queue. The alert will be sent
when the receiving application exchanges messages with the EHR/DIS; and
The HL7 Polling Messages.
• Implementors of EHR/DIS systems will need to consider the extent to which EMR systems and/or
PMS systems can download and retain patient data within their files, as opposed to the ability to view
data only.
• When a query response has been constrained due to jurisdictional rules, the EHR/DIS should
consider adding a Warning on the query response in the effect that the query response has been
filtered by EHR/DIS
7.1.3 Implementors of Web-Based or Viewer Solutions

Web based solutions are expected to require a modest persistence framework to support certain
functions. For example, such solutions may need to track prior transaction IDs in order to offer
meaningful retract capabilities; similarly, persistence may be needed to support a shift from a clinical
predetermination to an actual prescription submission.
No review has been undertaken to ensure that query capabilities included in these Message Specification
provide sufficient information to allow all other functions within the Message Specification to be initiated
without separate storage.
7.1.4 Implementors of Electronic Medical Record (EMR) Systems

In general this Message Specification assumes that EMR solutions will normally retrieve information at
the outset of a transaction (e.g. retrieve allergies, retrieve medical conditions, retrieve demographics,
etc.).
The following considerations and guidance apply to Implementors of EMR Systems:
• There are a range of clinical validations that could be performed by the EHR/DIS as part of
contraindication checking process but are not likely to be implemented centrally. For example, these
could include warnings about other verifications such as ‘Check if patient is taking Aspirin?’. EMR
solutions should consider whether to establish such functionality.
• There are a number of messages the EMR receives from the EHR/DIS where the EHR/DIS acts to
forward a message received from another provider application to the EMR. As applications may not
always be on-line in real time, the EMR needs to support:
the ability to receive a ‘message waiting’ alert when messages are in the queue. The alert will be sent
when the EMR exchanges messages with the EHR/DIS.
the HL7 Polling Messages.
• Systems will need to consider under what circumstances ‘retracts’ are permitted. For example,
Who may retract an action? (e.g. the individual who posted the transaction, the system from which the
action originated, etc.)
How long after an event is recorded may an action be retracted?
Must retracts be performed in reverse order of the actions themselves?
transactions. Moreover, appropriate transaction numbers will need to be retained to support the
retract interaction.
7.1.5 Implementors of Pharmacy Management Systems (PMS)

The following considerations and guidance apply to Implementors of Pharmacy Management Systems:
• There are a number of messages the Pharmacy management System (PMS) receives from the
EHR/DIS where the EHR/DIS acts to forward a message received from another provider application
to the PMS. As applications may not always be on-line in real time, the PMS needs to support:
the ability to receive a ‘message waiting’ alert when messages are in the queue. The alert will be sent
when the EMR exchanges messages with the EHR/DIS;
the HL7 Polling Messages; and
For those jurisdictions that allow Dispense and deemed Pickup, Pharmacy software vendors should
2
provide for this capability with minimal workflow impact.
• Systems will need to consider under what circumstances ‘retracts’ are permitted. For example,
Who may retract an action? (e.g. the individual who posted the transaction, the system from which the
action originated, etc.)
How long after an event is recorded may an action be retracted?
Must retracts be performed in reverse order of the actions themselves?
transactions. Moreover, appropriate transaction numbers will need to be retained to support the
retract interaction.
7.1.6 Regulatory Bodies (Jurisdictional)

The implementation of a fully integrated solution for electronic prescribing and interchange of drug
prescribing and dispensing information is expected to significantly impact professional practice. As a
result, regulatory bodies will need to consider the associated workflows and may need to provide specific
guidance on areas including the following:
• Information will be exchanged about contraindication checking and associated overrides or
management actions to identified medication issues. The responsibility of downstream clinicians of
reacting to such prior responses to medication issues may need to be clarified. For example, if a
physician over-rides a contraindication, what is the responsibility of the pharmacist?
2
Jurisdictions with existing EHR/DIS solutions could consider the “Dispense Request” as a deemed pickup (completing the
dispense record and adjusting the available fills as appropriate).
7.1.7 Regulatory Bodies (National)
In order to provide a solid foundation for e-Prescribing, Health Canada should continue work on reviewing
the regulatory framework with a view towards establishing applicable electronic signature guidelines
and/or enabling the EHR/DIS in a jurisdiction to act as a trusted intermediary.
7.2 Business Based Considerations
The following sections describe business based implementation considerations. A number of these are
supported by external discussion papers, spreadsheets or presentations. Information here may be
repeated in other areas of the guide.
and guidelines are complete.
7.2.1 Allergy Discussion

Rationale
This discussion is intended to clarify and define three key facets of allergies for review by stakeholders.
Definitions
The Message Specifications uses the terms “Allergy” and “Intolerance” in describing the types of
substances which are contraindicated for a patient due to reactions they experience or could experience.
The distinction is as follows:
• Uncategorized Intolerance: A sensitivity to a substance or category of substances, such that
exposure to the substance is likely to result in an adverse reaction and where it has not been possible
to identify with any degree of certainty which type of adverse reaction it is.
• Allergy: A hypersensitivity caused by an exposure to an antigen which results in an adverse
immunologic reaction on subsequent exposures
• Intolerance: Any identified intolerance which is caused by a mechanism other than immunologic over-
response.
Both Allergy and Intolerances are types of an ‘Uncategorized Intolerance’ (where the category has been
determined).
Uncategorized Intolerance
Allergy Intolerance
Figure 9 – Uncategorized Intolerance (Allergy & Intolerance)

Allergies and intolerances are generally differentiated based on the type of reaction. Immunologic
reactions such as rash, hives, swelling and anaphylaxis generally signify the presence of an allergy.
Other reactions such as nausea, dry mouth, hair loss, etc. would qualify as intolerances.
Because allergens are immunologic in nature, they have a risk of producing an increased severity
reaction on subsequent exposures. Intolerances do not tend to have such a risk. Because of this
distinction, an alert regarding an allergy may be managed differently than one regarding an intolerance.
Different clinicians place different importance on the distinction between allergies and intolerances.
EMRs have traditionally been more likely to differentiate these concepts, while pharmacy applications
have tended to group them together. The Message Specification supports both views by allowing a
particular adverse reaction to an agent to be identified as an Uncategorized Intolerance, or to be
specifically categorized as an Allergy or an Intolerance. It is also possible for the categorization of an
adverse reaction to an agent to change over time. An initial recording of “Allergy to Penicillin” may later
be changed to “Intolerance to Penicillin” when the nature of the associated reaction becomes known.
Identifying Allergens
An important reason for recording a patient’s allergies and intolerances is to allow alerts to be raised
when drug products are prescribed or dispensed which might trigger an adverse reaction. Obviously an
alert should be triggered when an identical drug to the one initially recorded as an allergen is prescribed
or dispensed. However, different drugs often share molecular characteristics that cause them to be
treated similarly by the immune system. Drugs sharing a set of similarities are referred to as an “Allergen
Group”. An example of such a group might be “Sulfa drugs”. Because of this behavior, most knowledge-
bases tend to classify, check medications and cause alerts based on allergen group, rather than the drug
generic or therapeutic class. (Therapeutic class is based on drug use, rather than immuno-molecular
characteristics.)
Ideally, the Message Specifications would capture both the specific implicated drug product, as well as
the allergen group or groups believed to be implicated in a particular allergy. Unfortunately, there are no
non-proprietary code systems for allergen groups. Therefore, the Message Specifications will rely on
capturing the allergen as a generic drug, with the expectation that each knowledge-base will cross-check
all allergen groups associated with the specified generic.
In the case of multi-ingredient drugs such as Tylenol-3, clinicians are encouraged to record the allergy or
intolerance based on the generic drug believed to be implicated in the reaction. For example, if the
patient reacted to Tylenol-3, but not to regular Tylenol or coffee, the clinician should record the allergen
using the generic for Codeine.
Use of Allergy/Intolerance vs. ADR
The Message Specifications offers transactions which support the capturing of both “Allergies” and
“Intolerances” as well as Adverse Reactions in the patient record. One obvious question is “When should
a clinician record an Allergy or Intolerance, and when should they record an ADR?”
Allergies and Intolerances are intended for circumstances where the clinician has a fair degree of
confidence that the identified agent is the cause of the adverse reaction, or when specific testing has
been performed to confirm the presence of an allergy. ADRs are intended to record that an unusual
reaction has occurred in the patient, but the cause of the reaction is not definitively known. One or more
suspected or candidate drugs may be linked to the ADR to warn that they should be used with caution
and that careful monitoring should be performed if they are used.
By recording adverse reactions as they occur, it may be possible at a later point to identify a trend relating
to a combination of medications, to a time of year, or to some other factor that may aid the recording
clinician or others in identifying the cause of the reaction. Previously recorded adverse reactions can be
linked to allergy and intolerance records as supporting evidence for the presence of a particular allergy or
intolerance, reducing the requirement to re-enter data.
7.3 Vocabulary Based Considerations
This Messaging Specification uses coded data in a variety of messages to establish functional support for
complex business processes. Codes permit decision support capabilities and are critical for the
meaningful exchange of data amongst stakeholders.
Codes are typically not used in isolation but are intended to work in concert with other codes to support
important functions such as contraindication checking, status management, and general workflows
between prescribers and dispensers to enable the establishment of drug information systems and
electronic prescribing.
7.3.1 Conditions
The recording of prescription indications, allergic reactions and general medical conditions are intended
to support, among other things, contraindication checking and improved provider-to-provider
communication. In order to streamline physician workflow and to allow systems to leverage knowledge-
bases for such checking, appropriate coding will be critical.
Codes in this category have to provide:
• Improved patient safety
There are several commercial knowledge-bases available that can conduct drug-disease and drug-allergy
interaction checking.
Preventing side effects and harm to patients is a key design criterion for including this information in a
coded format.
• Improved communication between providers.
Prescribers may have clear reasons for prescribing a particular medication to a patient. However, these
reasons are not always clear to dispensers.
When dispensers and prescribers provide different rationales for a medication to patients, it can cause
patient confusion and mistrust in the healthcare system.
Concepts must be familiar to all providers.
• Allow Providers to search for, and select conditions by name at the appropriate level of specificity;
e.g., symptom, working diagnosis or diagnosis.
• Allow the EHR/DIS to determine the equivalence (through mapping) of conditions that may be used
by various systems and drug Knowledge-bases.
• Allow drug Knowledge-bases to relate to these identifiers and to use the knowledge of these
relationships for clinical decision support processes.
• Provide sufficient coverage for the topic; for example, condition codes should not force providers to
specify conditions to a higher degree of certainty than can be supported by available information.
• Be compatible with generally available commercial drug-disease interaction Knowledge-bases.
Rationale for Conditions
There are a number of reasons for including a description of physiologic states and disease conditions in
a prescribing standard. The inclusion of both is of significant importance to safe and effective
pharmaceutical prescribing. Firstly, there are a number of normal physiological states which require
recognition when prescribing such as pregnancy and lactation; in these circumstances the prescribing of
certain medications would be ill-advised as they might cause harm to a developing fetus or infant. These
are not disease states, but they are prescribing precautions which should be taken into consideration
when prescribing. Prescribing providers should be alerted to their existence.
Secondly, the state of the patient, either physiological or pathological, should be recorded in the EHR so
that proper contraindication checking can take place. Modern knowledge-bases can present prescribers
with warnings if they try to prescribe a medication which may be contra-indicated in certain disease or
physiological states. For example, advanced age is a physiologic state that can be associated with
pathologic conditions such as renal failure and thus the importance of knowing what is the state of the
patient who is receiving the prescription. Broad categories like pregnancy, lactation or advanced age all
have a bearing on effective and safe prescribing and should be indicated to guide the prescriber.
Thirdly, in disease states or conditions such as cancer, there are many associated conditions for which a
provider might prescribe. In the situation where a patient is suffering from underlying cancer of the
breast, providers often prescribe narcotics to manage the pain associated with the spread of the disease.
The pathologic condition here is breast cancer which is the disease but the indication for the narcotic is
the bone pain associated with the disease condition. This will help to distinguish between the disease
state or condition and the prescribing indication for which the drug is ostensibly ordered.
Finally, there are situations where there could be confusion and doubt in the mind of the patient if there is
not some indication provided for the medication. For example, when a provider uses amitriptyline for
neuropathic pain, a dispenser might inform the patient that the drug is used for depression where this is
clearly not the reason. By providing prescribing indications, the healthcare provider avoids this confusion
at the dispensing phase of therapy. In this case, providing the indication facilitates greater compliance
and peace of mind for the patient.
The choice of what circumstances it is appropriate to share medical condition in the EHR will in the end
be determined by jurisdictions, professional organizations and regulatory authorities. In those
circumstances where the information is capture, it is essential that it be captured in a consistent, coded
manner to enable appropriate decision support.
Medical Condition vs. Indication
The diagram below depicts the co-existence of medical conditions and indications and illustrates the fine
line between Indications and Medical Conditions. The following assertions can be made from the
diagram:
• There are several categories of medical condition, for which a disease state condition is one.
• Medical diagnosis is usually drawn from a single code scheme.
• Indication generally includes most medical diagnosis, but also includes symptoms (e.g. runny nose)
and other indirect reasons (e.g. contrast agent for diagnostic image).
• External drug knowledge-bases would usually provide decision support tools that may be employed
by jurisdictions to relate disease codes to indications, if they so choose.
Figure 10 – Medical Condition vs. Prescribing Indication
Indication
Indicates the reason for the therapy being prescribed. Reasons may be:
• a diagnosed medical condition e.g. diabetes or hypertension which could be documented and linked
to a created prescription by using a code such as SNOMED CT®;
• a symptom such as pain, fever or ‘runny nose’, which might be documented and linked to a
prescription by entering free text or by using a code from a code set such as SNOMED CT®, FDB or
perhaps a custom code set; or
• for prophylaxis or prevention, such as medications taken to avoid malaria. These too might be
documented and linked to a prescription by using free text or a code.
It is important to note that multiple prescribing indications may exist for any given prescription and that
when multiple indications occur, they may be placed in a hierarchy e.g. primary indication, secondary
indication, etc.
Medical Condition
Some definitions assert that a diagnosis is a cause-based statement about the medical state of a patient,
at a specific "point-in-time" and a Medical Condition describes a medical situation present in a patient
which extends over time. For the purposes of this Message Specification, they will be considered
equivalent. In addition, for the purposes of recording in an EHR/DIS, it is recommended that only a health
care provider allowed to diagnose by regulation in a jurisdiction can assert a diagnoses in a patient’s
record.
Medical Conditions may or may not require clinical interventions, and fall into the following three general
categories:
• Allergy/Intolerances.
• Non-Disease State Conditions, including pregnancy and lactation states.
• Disease/Illness state, including chronic and short term diseases/illnesses.
VIII TRANSACTION-BASED IMPLEMENTATION
CONSIDERATIONS AND GUIDELINES
This section provides specific guidelines for implementation of transactions/ interactions included in this
Message Specification. Guidelines includes applicable business considerations and message / scenario
usage rules. Please note that implementation guidance pertaining to specific elements in a message are
included in the detailed Message Specifications:
8.1 Immunizations
Note to Reader: This section describes a set of transactions to support Immunization
administrations and queries, specifically:
• C14.01 – Add Patient Immunization,

• C14.05 – Update Patient Immunization,
• C14.02 – Patient Immunization Query, and
• C14.06 – Retract Immunization Record.
These transactions were initially devised as part of the pan-Canadian Electronic Drug
(“CeRx”) standards project and, as of this publication, are now under review by the pan-
Canadian Public Health Surveillance (PHS) standards project.
Early or potential implementers are cautioned that these transactions are expected to change
as a result of the PHS review process in order to incorporate more specific public health
surveillance related requirements. Interested parties should consider participating through the
PHS project’s stakeholder engagement processes, particularly by monitoring of the
associated forum (http://forums.infoway-inforoute.ca/PHS).
The following transactions relate to the various processes used for immunization on the EHR/DIS.
8.1.1 C14.01 – Add Patient Immunization

The intention of this transaction is to record the immunization of a patient in their health record on the
EHR/DIS. It may also be used to record the fact that the patient refused the immunization.
8.1.1.1 Key Transaction Design Elements

None Identified
8.1.1.2 Key Transaction Assumptions


included.


message).

Some exceptions:
8.1.1.3 Interaction(s)
8.1.1.3.1 Record Immunization Request

Interaction ID POIZ_IN010020CA
Interaction Requests that a particular immunization be added to a patient's record.

Description
Considerations • Note that the Adverse Reaction class is a simple indicator that there has
been an adverse reaction to an immunization. There was no business
requirement stated to link this to an actual adverse reactions record.
Developer Guidance • None Identified
8.1.1.3.2 Record Immunization Request Accepted

Interaction Indicates that the requested immunization information has been successfully
Description added to the patient's record.
Considerations • None identified.
Developer Guidance • None identified.
8.1.1.3.3 Record Immunization Request Refused

Interaction Indicates that the request to add an immunization to the patient record has
been denied.
Description

8.1.2 C14.05 Update Patient Immunization
This transaction allows the update of an immunization record on the EHR/DIS. The updateable pieces of
information on the immunization is limited to three fields only namely: the textual comment, the vaccine
dose number, and the 'immunization course complete?’ indicator.

None Identified



included.


Some exceptions:
8.1.2.3.1 Update Immunization Request

Interaction Request that information about a previously recorded immunization be

Description changed.
8.1.2.3.2 Update Immunization Request Accepted

Interaction Indicates that information about a change to a previously recorded

Description immunization has been successfully recorded.

8.1.2.3.3 Update Immunization Request Refused

Interaction Indicates that the request to record a change to information about a

Description previously recorded immunization has been refused.
8.1.3 C14.02 Patient Immunization Query
This transaction is used to retrieve the list of immunizations a patient has received. Information retrieved
may include all immunizations that the patient has ever had or may be limited to specific vaccine and/or
dose number.

None Identified

Queries Query responses will reflect current data in the EHR/DIS (i.e. current data).

jurisdictions.
8.1.3.3.1 Immunizations Query

Interaction Requests retrieval of detailed information about a patient's immunizations,

Description potentially filtered by time-range of the immunization, time-range the
immunization was last updated, and/or type of immunization.
Considerations • None identified
Developer Guidance • None identified
8.1.3.3.2 Immunizations Query Response

Interaction Returns detailed information about a patient's immunizations.

Description
Developer Guidance • None identified
8.1.4 C14.06 Retract Immunization Record
This transaction marks a previously recorded immunization record as removed from view. The record is
retained at the EHR/DIS, but will no longer be included in query responses.

None identified

None identified
8.1.4.3.1 Retract Immunization Request

Interaction Asks that a previously recorded immunization should be "removed" from the
Description record; (Information may be retained for audit purposes).
8.1.4.3.2 Retract Immunization Request Accepted

Interaction Indicates that a previously recorded immunization has been "removed" from
Description the record as requested; (Information may have been retained for audit
purposes).
8.1.4.3.3 Retract Immunization Request Refused

Interaction Indicates that the requested previously recorded immunization will not be
Description "removed" from the record.
8.2 Patient Observations
8.2.1 C21.04 Record Basic Patient Observation
This transaction is used to record a non-Lab and non-DI types of observation about a patient such as
height, weight, blood pressure, etc.

None Identified



included.


message).

Some exceptions:
8.2.1.3.1 Record Patient Basic Observation Request

Interaction ID REPC_IN000051CA
Interaction Requests that a basic observation (height, weight, blood-pressure, etc.) be

Description recorded in a patient's record.
8.2.1.3.2 Record Patient Basic Observation Request Accepted

Interaction Indicates that the requested basic observation (height, weight, blood-
Description pressure, etc.) has been successfully recorded in a patient's record.

8.2.1.3.3 Record Patient Basic Observation Request Refused

Interaction Indicates that the request to record the specified observation in the patient's
Description record has been refused.
8.2.2 C21.05 Review Basic Patient Observations
• This transaction is used to retrieve various measurements and other types of observations that have
been recorded for a specific patient. The information retrieved covers those measurements and
observations that are usually undertaken in a provider’s office, such as weight, height, blood pressure
measurements, and excludes Lab and DI type observations.

None Identified


jurisdictions.
8.2.2.3.1 Patient Basic Observations Query

Interaction Requests retrieval of the basic observations (height, weight, blood-pressure,

Description etc.) which have been recorded for a particular patient, optionally filtered by
the type of observation and/or by the date-range for which the observation
was recorded.
8.2.2.3.2 Patient Basic Observations Query Response

Interaction Returns one or more basic observations (height, weight, blood-pressure,

Description etc.) associated with a patient.

8.3 Medical Conditions
8.3.1 C12.01 Add Patient Medical Condition
This transaction is used to record a medical condition (i.e. indication, diagnosis) against a patient's
record.
This transaction allows a provider wishes to enter a medical condition which may affect prescribing and
dispensing behavior. This information will aide both the providers and the dispensers of medication
important knowledge which will guide further prescribing and dispensing.

None Identified



included.

message).
delegation.

Some exceptions:
8.3.1.3.1 Record Medical Condition Request

Interaction Requests that a medical condition record be recorded against the specified
Description patient.
8.3.1.3.2 Record Medical Condition Request Accepted

Interaction Indicates that the requested medical condition record has been successfully
Description added to the patient's record.

8.3.1.3.3 Record Medical Condition Request Refused

Interaction Indicates that the request to add the specified medical condition to the
Description patient record has been refused.
8.3.2 C12.02 Update Patient Medical Condition
This transaction will update patient medical condition information.
Information on a record occasionally become out-of-date and in need of correction or updating and in
such instances this transaction would allow important new information to be entered into the record and
an example of this would be in the case where a patient’s creatinine level were to increase due to some
medical condition such as diabetes. This would be important information to guide future prescribing.

None Identified



included.

capability;
Checking
delegation.

Some exceptions:
8.3.2.3.1 Update Medical Condition Request

Interaction Requests that information such as severity, status, start date and end date
Description of a previously-recorded medical condition be updated.

8.3.2.3.2 Update Medical Condition Request Accepted

Interaction Indicates that the requested severity, status, start date, end date or other
Description information about a previously-recorded medical condition has been
successfully updated.
8.3.2.3.3 Update Medical Condition Request Refused

Interaction Indicates that the requested modification to the previously-recorded medical

Description condition has been refused.
8.3.3 C12.03 Get Patient Medical Conditions
This transaction allows the retrieval of the list of recorded patient medical conditions (indications,
diagnosis).
It is of great assistance to know why certain drugs have been prescribed for a patient over time and
where this information has been recorded, it can be obtained from the record to determine which
medications have been effective against a certain condition; this might be either a diagnosis or simple a
physiologic state for which further prescribing needs to be done with caution such as in pregnancy.

None Identified

delegation.

jurisdictions.
8.3.3.3.1 Patient Medical Condition With Hist. Query

Interaction Requests retrieval of the history of a particular medical condition record

Description identified by patient id and medical condition record id, including changes to
severity, status, start date, end date, etc
8.3.3.3.2 Patient Medical Condition With Hist. Query Resp.

Interaction Returns information about a single medical condition record, including all
Description revisions to severity, status, start date, end date and annotations
8.3.4 C12.07 Get Patient Medical Conditions No History
This transaction allows the retrieval of the list of recorded patient medical conditions (indications,
diagnosis) with no attached history.

None Identified

delegation.

jurisdictions.
8.3.4.3.1 Patient Medical Conditions Query

Interaction Requests retrieval of all medical condition records that have been recorded
Description for a particular patient, optionally filtered by time-range when the allergy or
intolerance record has last been changed, the type of condition and/or the
time-range when the medical condition was active.
8.3.4.3.2 Patient Medical Conditions Query Response

Interaction Returns the details of one or more medical condition records.

Description

8.4 Allergy/Intolerances
8.4.1 C11.01 Add Allergy, Intolerance
The intention of this transaction is to record an allergy or intolerance to a drug or non-drug substance and
add it to the patient's electronic health record.
The importance of this to healthcare is obvious; it will enhance safety and efficiency to the prescribing act
and allow physicians and other healthcare providers ensure that a complete profile of allergies and
intolerances is recorded against a patient’s record. It can be used when a patient first registers with a
provider and also every time a new allergy or adverse reaction occurs in the course of treatment with
either drugs or non drug substances like food additives or actual food substances (i.e. Nuts or dairy
products).

Confirmed vs. For the allergy/intolerance recording, a binary certainty (Confirmed vs.
Suspected Suspected) was selected for simplicity. Additions may need to be
considered as knowledge is gained through the implementation process.
Resolved vs. Refuted There are two different ways of negating an allergy record:
• "The allergy is 'resolved'". I.e. The patient was allergic, but due to time
and/or therapy, they no longer have the allergy. This is represented
using a statusCode of "complete" and a negationInd of false.
• "The allergy is 'refuted'". I.e. The patient is not and never was allergic to
this. For example, they complained of stomach upset when taking
penicillin and someone recorded it as an allergy. Stomach upset is not
an allergic reaction, and the absence of any other 'true' allergic reactions
indicates that the patient does not have the allergy. This is represented
using a statusCode of "complete" and negationInd of true.
Negated allergies must come back in query responses, as it's a positive
clinical assertion that providers need to know about.



included.


message).
Some exceptions:
8.4.1.3.1 Add Allergy/Intolerance Request

Interaction Requests that a new allergy or intolerance record be recorded against the
Description specified patient.
8.4.1.3.2 Add Allergy/Intolerance Request Accepted

Interaction Indicates that the requested allergy or intolerance record has been
Description successfully added to the patient's record.
8.4.1.3.3 Add Allergy/Intolerance Request Refused

Interaction Indicates that the request to add the specified allergy or intolerance to the
Description patient record has been denied.

8.4.2 C11.02 Update Allergy, Intolerance
This transaction is used to update the information associated with a particular allergy or intolerance in the
patient's record.
It would be used commonly with an established patient who experiences a new reaction or a changed
reaction to a drug or non drug substance. The transaction will allow the provider the opportunity to
distinguish between the two types of adverse reaction to a drug – the true allergy or the intolerance.



included.


Some exceptions:
8.4.2.3.1 Update Allergy/Intolerance Request

Interaction Requests that status, severity or other information about an existing allergy
Description or intolerance record be updated.
Developer Guidance • In the same way that ConditionEvent.value is already removed from an
update, but so should ConditionEvent.code if using SNOMED.
8.4.2.3.2 Update Allergy/Intolerance Request Accepted

Interaction Indicates that the status, severity and/or other information about the
requested allergy or intolerance record has been updated.
Description

8.4.2.3.3 Update Allergy/Intolerance Request Refused

Interaction Indicates that the requested modification to the defined allergy or intolerance
Description record has been denied.

8.4.3 C11.03 Get Patient Allergies, Intolerances
This transaction allows the retrieval of the list of all current allergies and intolerances recorded against a
specific patient.
It will be used by providers to determine prior to prescribing which medications may have produced an
adverse reaction in the past. Some drug classes exhibit cross-reactivity when used in a patient who has
had an adverse reaction to a drug of the same class in the past (i.e. Cephalosporin can cross react with
penicillin.)



jurisdictions.
8.4.3.3.1 Patient Allergy/Intolerance Query

Interaction Requests retrieval of all allergies or intolerances that have been recorded for
Description a particular patient, optionally filtered by time-range when the allergy or
intolerance record has last been changed.
8.4.3.3.2 Patient Allergy/Intolerance Query Response
Interaction Returns the details of one or more allergy and intolerance records.
Description
8.4.4 C11.04 Get Allergy, Intolerance Change History
This transaction allows the review of the set of changes that have occurred over the lifetime of an allergy
or intolerance for a particular patient.
The transaction will be used when a patient has experienced an adverse reaction to a substance or drug
and over time has had repeated exposure to the same substance during which time the reaction has
abated or even disappeared. The history will allow providers or researcher to determine the abetting or
worsening of an allergy or other adverse reaction over the period of time captured by the EHR.



jurisdictions.
8.4.4.3.1 Patient Allergy/Intolerance With Hist. Query

Interaction Requests retrieval of the history of a particular allergy or intolerance record

Description identified by patient id and allergy or intolerance record id, including changes
to severity, status, annotations, etc.
8.4.4.3.2 Patient Allergy/Intolerance With Hist. Query Resp.
Interaction Returns information about a single allergy or intolerance record, including all
Description revisions to severity, status and annotations
8.5 Professional Services
8.5.1 C13.01 Record Professional Service
Professional Services

Alignment with This model has been aligned with the NeCST Billable Clinical Service
NeCST CMET, which is used to support a clinical service in a claim.


message).

Some exceptions:
8.5.1.3.1 Record Pharmacy Prof. Service Request

Interaction Seeks to add a record of a professional service (training, counseling,

Description medication reviews, etc.) which has been delivered to a patient.
8.5.1.3.2 Record Pharmacy Prof. Service Request Accepted

Interaction Indicates that a record of a professional service (training, counseling,

Description medication reviews, etc.) which has been delivered to a patient has been
successfully added.
8.5.1.3.3 Record Pharmacy Prof. Service Request Refused

Interaction Indicates that the request to add a record of a professional service (training,
Description counselling, medication reviews, etc.) which has been delivered to a patient
has been refused.
8.5.2 C13.02 Get Patient Professional Services
The intention of this transaction is to retrieve a list of the services performed for a specific patient.
Parameters include patient id (plus name, date of birth, gender for verification), date range, and service
code.

Alignment with This model has been aligned with the NeCST Billable Clinical Service
NeCST CMET, which is used to support a clinical service in a claim.


jurisdictions.
8.5.2.3.1 Patient Pharmacy Prof. Services Query

Interaction Requests retrieval of all professional services (training, counseling,

Description medication reviews, etc.) provided to a patient, potentially filtered by the
provider who delivered the service, the type of service provided, the time-
range in which the service was provided, and/or the time-range in which
information about the service was last updated (via adding an annotation).

8.5.2.3.2 Patient Pharmacy Prof. Services Query Response

Interaction Returns detailed information about some or all professional services

Description (training, counselling, medication reviews, etc.) delivered to a patient.

8.6 Adverse Reactions
8.6.1 C11.05 Add Patient Adverse Reaction
This transaction allows the recording of a specific occurrence of an adverse reaction on a patient’s
record.
The most appropriate time to record a specific occurrence is at the time of the event and this transaction
will allow the provider to record the specifics of the reaction and often allows the distinction between a
true allergic reaction and an intolerance to the specific agent in question.
A review of patient adverse reactions records may highlight similarities between episodes. This may
assist a diagnostician in determining a diagnosis of an allergy or intolerance i.e. the ADR records may
serve as supporting documentation for the finding of allergy or intolerance.

None Identified



included.


message).

Some exceptions:
8.6.1.3.1 Record Adverse Reaction Request

Interaction Requests that information about an adverse reaction be recorded against a

Description patient's record.
8.6.1.3.2 Record Adverse Reaction Request Accepted

Interaction Indicates that the requested adverse reaction information has been
Description successfully recorded against the patient
8.6.1.3.3 Record Adverse Reaction Request Refused

Interaction Indicates that the request to record the specified reaction against the
Description patient's record has been refused.

8.6.2 C11.06 Update Patient Adverse Reaction
The intention of this transaction is to update an existing adverse reaction record for a patient.
It is common for patients to identify all reactions as allergies whereas most are simple intolerances to the
substance such as nausea or headache. The provider will be able to use this transaction to add further
information that would allow, for example, the distinction between allergies and other adverse reactions to
drugs or non drug substances. An example of this would be to append a comment indicating that a
previously identified allergy to Demerol for pain which was nausea was in fact, an intolerance and this
would not preclude using the drug at another time.

None Identified



included.

Some exceptions:
8.6.2.3.1 Update Adverse Reaction Request

Interaction Requests that information such as severity, outcome and suspected cause
Description of a previously-recorded adverse reaction be updated.
8.6.2.3.2 Update Adverse Reaction Request Accepted

Interaction Indicates that the requested severity, outcome, suspected cause or other
Description information about a previously-recorded adverse reaction has been
successfully updated.
8.6.2.3.3 Update Adverse Reaction Request Refused

Interaction Indicates that the requested modification to the previously-recorded adverse

Description reaction has been refused.
8.6.3 C11.07 Get Patient Adverse Reactions
The intention of this transaction is to retrieve a list of adverse reactions that have been recorded against a
patient’s record.
Since adverse reactions to drugs or non drug substances cause considerable morbidity and some
mortality, this transaction will allow the provider to retrieve a list of these such occurrences for a patient. It
will be used when a provider is trying to determine which adverse reaction is a true allergy and which
might be other reactions which might be mitigated by other drugs. (i.e. the adverse reaction to NSAID
medications can be mitigated by using a gastric protective medication such as a PPI).

None Identified


jurisdictions.
8.6.3.3.1 Patient Adverse Reactions Query

Interaction Requests retrieval of the details about all adverse reactions which have
Description been recorded against a patient's record, potentially filtered by reaction type,
time-range of the occurrence of the reaction and/or time-range in which the
adverse reaction information was last changed.
8.6.3.3.2 Patient Adverse Reactions Query Response

Interaction Returns information about the current status of one or more adverse
Description reactions for a patient.
Appendix A. HOW TO READ THE SCOPE & TRACKING
FRAMEWORK
A.1 Introduction & Purpose

The Scope & Tracking Framework, or STF, is a pivotal document in that it ties together the scope of the
Message Specifications across Implementation Guide Volumes from a transaction perspective, through to
interactions and finally to messages. It also includes summary tracking information for all key artifacts.
The STF also houses, where appropriate, materials from the Universal or international realm, allowing
users to cross reference Canadian realm artifacts against their Universal counterparts.
A.2 Organization of the Scope & Tracking Framework

The Scope & Tracking Framework (STF) is organized in a series of tabs in an Excel spreadsheet. As
such, each tab represents a single perspective on the complete Message Specifications.
The diagram below depicts in a graphical form the relationship between transactions, interactions and
message types. This diagram will help reinforce the relationship between the various artifacts (or tabs) in
the STF.
Artifact Relationship
TRANSACTIONS
Business Transactions
Characterized as either:
- Request
- Notification
- Query Request
TRIGGERS INTERACTIONS
Initiates an
Interaction
Trigger Event Request Notification Query Request
Response (Accept) Query Response
Response (Refuse)
By exception, some interactions have no

Mandatory Mandatory payload (e.g. for simple acknowledgements)
MESSAGE TYPES
Legend
Transmission Wrapper Models Control Act Wrapper Models Payload Models
Mandatory (Visio, Word, MIF) (Visio, Word, MIF) (Visio, Word, MIF)
(SC-CA-2003) (SC-CA-2003) (SC-CA-2003)
Optional
HL7 Artifact May contain...

CMET Models
(Visio, Word, MIF)
(SC-CA-2003)
Non-Normative
Material
As of 06 April 15
Figure 11 – Artifact Relationship
The STF uses filtering columns quite extensively. This is a standard Excel method and allows the reader
to focus on the subset of information that is relevant or of interest. For example, filtering by ‘1’ in the
Volume column allows the reader to see data only relevant for Volume1 (of the Implementation Guide).
The filters work similarly for the other columns; it is important to realize that the filters need to be set to
‘All’ in all other columns to display all of the information needed by the reader.
In addition to the usual Excel filtering, the STF also provides a global filter on the Overview Tab. This
global filter allows the reader to filter on All content, Canadian content or Universal content (the HL7
Universal realm). It is important to note that the STF may also house UV (universal) artifacts as the STF
is also used in some HL7 domains (e.g. Pharmacy) to generate the publication database, used to submit
materials to HL7 for balloting.
The Scope & Tracking Framework has been designed to provide specific views into the Dynamic Model
for the Message Specifications. The cornerstone for the STF is the Transaction, but any artifact can be
used to reference other components of the Message Specifications. That is, if the reader is aware of the
Message Type (e.g. PORX_MT010160CA), then the interactions that use this message type can be
ascertained by starting from the Message Summary Tab. See the breakdown of tabs below.
Also of note, the STF does not use artifact identifiers (e.g. PORX_MT060160CA) as linking identifiers, as
these identifiers are subject to change through the development and balloting of the artifact. Therefore, a
secondary key has been assigned for each artifact so that HL7 artifact identifiers may be changed as
required.
Lastly, all artifacts are known by up to 2 identifiers: a CA or Canadian identifier and a UV or Universal
identifier. These are typically the same identifier except for a UV or CA at the end of the identifier. The
use of 2 identifiers allows for specification of 2 perspectives: a CA and UV perspective. An artifact may
not have a UV identifier if it has not been accepted by HL7 International.
A.3 Scope & Tracking Framework Tabs

The major tabs in the worksheet are:
• Overview;
• Dashboard;
• Stability & Change;
• Artifact Changes;
• Transactions;
• Storyboards:
• Interactions;
• Transactions Interactions;
• Triggers;
• Storyboard Interactions;
• Message Summary;
• Application Roles & Role Interactions;
• Transaction Scope Traceability & Non Rx Transactions; and
• Change Log.
The Overview Tab provides an overview of all tabs in the Framework and also allows the reader to
switch between Canadian, Universal or All views.
The Dashboard Tab provides a high level status of the artifacts in the STF and consequently, in the
The Stability & Change Tab provides a listing of all items that are still in a state of flux. It highlights
which artifacts are affected by these potential changes, marks the stability remark as “Pending Change”
or “Change Risk” and ranks their change potential as high, medium or low. Over time, these remarks are
resolved and artifacts changed as appropriate. An example of a stability remark may be that Infoway is
reviewing the use of message wrappers and as a result of this review, some message wrappers used in
the Message Specifications may change. As this has not resulted in specific changes, it would be
marked as “Pending Change”. If there were changes, but they could not be put into the current release of
the Message Specifications, then this would be noted as “Pending Change”.
The changes made to artifacts, once a published version of the Message Specifications is released, is
noted in the Artifact Changes Tab.
The Transactions Tab is a complete list of transactions included in the Message Specifications (for the
CA or Canadian realm). For each transaction, the specific volume and chapter is listed, as well as a
transaction id (e.g. C06.03), a description and a quick status of the transaction. The Transaction id is
used as a reference point to other tabs in the STF.
The Storyboards Tab is used to list all of the storyboards referenced in the Implementation Guide as
informative material. In many situations, the storyboard is transferred to HL7 for balloting; this is noted in
the Status column.
The Interactions Tab is a primary vehicle for understanding each interaction included in the Message
Specifications. It lists the interaction id, description, initiating trigger event, payload message id (by
exception, a payload message type may not be present), control act wrapper message id (noted as
Trigger Event Wrapper) and transmission wrapper message id.
A cross reference tab, the Transactions Interactions Tab, it provides a method to tie the business
transactions (e.g. C03.02 – Create New Prescription Request) with the 3 interactions in this Request
message (Activate Prescription Request, Activate Prescription Request Accepted, Activate Prescription
Request Refused). Note: there are 3 transaction styles:
• Request: Request, with either a Request (Accept) or Request (Refuse) response;
• Notification, with no response; or
• Query Request, with a Query Response.
For more information on these 3 styles, please refer to section Error! Reference source not found. –
Error! Reference source not found.
The Triggers Tab provides a listing of the trigger events that cause interactions to fire.
The Storyboard Interactions Tab is a simple table listing of all interactions referenced in each
storyboard and is required for HL7 publishing only.
The Message Summary Tab lists all of the message type (models) used in the Message Specifications,
including transmission wrappers, control act/trigger event wrappers, payloads and CMETs, as typed in
the Type column.
Application roles are currently non-normative in HL7 and are also somewhat incomplete in this Message
Specifications. The Application Roles and Role Interactions Tabs lists the work developed to date, but
is likely to change as HL7 develops normative methods for these application roles.
The Transaction Scope Traceability Tab is used to trace initial business transaction scope, as defined
for the CeRx (ePrescribing) project. The Non-Rx Transactions Tab is a reflection of non-CeRx
transactions that were deemed out of scope of CeRx but are covered through other volumes of the
Message Specifications. These tabs are maintained for audit purposes only and will be removed in a
subsequent release of the STF.
Appendix B. HOW TO READ THE WORD MESSAGE
MODELS
The Word Message Models describe each individual message model, whether the model is a
transmission wrapper, control act/trigger event wrapper, payload or CMET (Common Message Element
Type). The Word versions of the message models are intended to address business or clinical interests
and therefore do not introduce too many technical terms. However, messaging is complex and
sometimes does require at least some reference to technical terms. The Word documents are therefore a
cross over document between business and technical aspects of the Message Specification.
Readers are encouraged to read Section Error! Reference source not found. – Error! Reference
source not found. in Volume 0 Overview for additional HL7 methodology background.
B.1 Model Details

Each Word design model starts with a Model Details section that describes all of the attributes (fields,
elements) in the model. The M, P, R or O following an attribute signifies conformance for the attribute as
Mandatory, Populated, Required or Optional.
The blue underline indicates that the attribute definition information is hyperlinked within the document
(e.g. Dispensing Allowed Period in the example below). For non-underlined text, this signifies that the
information for the attributes is in a CMET (Common Message Element Type). In the example below, the
hyperlink to prescribed for will link you to the reference to the CMET in the design document.
Prescription
Dispensing Allowed Period R
Prescription Number O
Previous Prescription Order Number R
Prescription Status M
Treatment Type P
Prescription Masking Indicator O
Not Eligible for Trial? M
Prescription Ship to Address R
Protocol Identifiers R 125
Non-authoritative? M
Prescription Type M
prescribed for Patient M
Patient ID M
Patient Name M
Patient Contact Address R
Patient Contact Phone and E-mails P 5
Patient Birth Date M
Patient Gender M
B.2 Attribute Conventions
The box below describes a typical attribute in a message. The attribute name Prescription Status is
followed by a reference to the underlying HL7 model (statusCode). As the box below is taken out of
context, it should be noted that the actual class in the HL7 model is noted, so that the statusCode
attribute can be determined in the model in case there are more than one statusCode in the HL7 model.
Prescription Status
(statusCode)
Datatype CS Simple Code (mnemonic only)
Conformance Mandatory Value must always be supplied (no nulls)
Repetitions 1 Does not repeat
Code CNE Must be coded using 'official' codeset (no un-coded text or
Strength local codes)
Code Domain ActStatus
Description This denotes the state of the prescription in the lifecycle of the prescription. Valid
statuses are: NEW, ACTIVE, SUSPENDED, ABORTED, COMPLETED,
OBSOLETE and NULLIFIED. Use 'NEW' when submitting a clinical pre-
determination. Use 'ACTIVE' when registering a new prescription or converting a
predetermination into a valid prescription.
Rationale Indicates what actions are allowed to be performed against a prescription. This is
a mandatory field because every prescription needs to be in some state.
The Datatype describes how the data is marked up. In the example, this attribute is noted as CS or
coded simple.
Note to Reader: All data types are described in detail in PN502-3002-EN - Data Types –
yyyymmdd.
Conformance for this attribute is set to Mandatory (value must be supplied). For an explanation of
conformance, please refer to Section Error! Reference source not found. – Error! Reference source
not found. in Section 0 Overview.
The number of Repetitions for this attribute (in the example below) is set to 1. There are some
situations, especially with identifiers, addresses or names, where more than 1 repetition of the same
attribute may be warranted.
The Code Strength is set to CNE, or coded with no extensions, which indicates that in order for a
message to be conformant, it must use one of the codes from the official code set. The other option is
CWE or codes with extensions, which allows new codes to be added by any implementor (without the
requirement to have the code added to the official code set). The CNE approach is generally used for
pan-Canadian standards development, as this increases interoperability. With CNE, new (even interim)
codes may be added to the official code set, obviating any concern that this would put any undue burden
on implementors requiring new codes.
The Code Domain element is set to ActStatus, which is the vocabulary domain for this attribute. That is,
it defines the domain that contains a valid set of codes.
Note to Reader: Vocabulary domains are listed in PN502-3004-EN - Vocabulary Status -

yyyymmdd.
The Description element provides descriptive data for the attribute, whereas Rationale describes why
the attribute is included in the model. On occasion, some additional components for the attribute may
appear, such as Implementation, which gives implementation notes for developers and Used By if there
were any mappings (e.g. to PECS, PIN, PharmaNet, etc.) for this attribute.
Appendix C. HOW TO READ THE VOCABULARY
STATUS WORKSHEET
The Vocabulary Status Worksheet has been designed to provide a logically complete explanation of the
code sets required by the Message Specification. It is arranged in such a way that a series of cross links
exist to take the reader to a particular domain to describe the code sets that have been recommended for
the domain.
The major tabs in the worksheet are:
• Overview;
• Domain Summary;
• Code System and OIDs; and
• Code Set tabs (multiple).
The Overview Tab describes all tabs in the Vocabulary Status Worksheet. The Worksheet uses filtering
columns quite extensively. This is a standard Excel method and allows the reader to focus on the subset
of information that is relevant or of interest. For example, filtering by ‘completed’ in the Status column
allows the reader to see which code set reviews have been completed (versus those that are not
completed). The filters work similarly for the other columns; it is important to realize that the filters need
to be set to ‘All’ in all other columns for the Domain Summary tab to display all of the information needed
by the reader.
The Domain Summary Tab lists all the vocabulary domains being contemplated for use in the Message
Specifications. The Domain Summary tab is the key tab for the reader to navigate to other tabs in the
worksheet. It provides links to detailed information about code sets for the various domains described in
the Domain Summary tab. The various business name codes (Domain names) are underlined and
clicking on them will send the reader to that tab where the detailed code information is highlighted.
The Code System and OIDs Tab lists all of the code systems contained in the Message Specifications,
along with their corresponding OID (object identifier). The OID, along with the code, are specified in the
message to provide unambiguous representation of a coded element. The OID distinguishes an “F” for
female from one code system vs. an “F” which may describe the coded concept of “first” in a second code
set.
The Code Set tabs are placed between the extreme left three main introductory tabs and those four at
the extreme right. These intervening tabs contain the actual codes, which may be a subset listing, which
are to be used for the vocabulary domain. In some situations, links to external code sets such as
SNOMED CT® are noted and a subset of codes listed.
The last four tabs of the worksheet are administrative in nature. Among these, the Change Log may be
useful to the reader as it indicates the changes that have been made over time. The small directions tabs
located to the far left of the lower tool bar will allow the reader to move to either the extreme right of the
sheet or the extreme left set of tabs.
Appendix D. HL7 METHODOLOGY BACKGROUND
D.1 Specification Component Introductions

Each artifact entered within the Message Specification has the following basic components:
6. Title Name: Human readable name for the artifact. The Title Name will appear as the artifact title and
in all references and hyperlink lists when the database is rendered.
7. Code: Unique code that is used to identify the artifact over time. Format is: UUDD_AAnnnnnnRRVV
where;
UU = Sub-Section code
DD = Domain code
AA = Artifact or Document code
nnnnnn = Six digit zero-filled number
RR = Realm code. (If not specified, universal assumed)
VV = Version code. (If not specified, version 1 assumed)
For example: PORX_AR000001CA01 is version 1 of the Operations
Section, Pharmacy Domain, Application Role Artifact number 00001 for
the Canadian realm. Because version numbers only apply to artifacts
which have completed the HL7 balloting process, they will be omitted
from CeRx artifact codes during the standards development and
approval process.
The code will appear after the title name when the Message
Specification is rendered.
8. Description: Most (not all artifacts) include a description that may be used to describe the artifact as
well as to insert links to other artifacts or images.
The following diagram shows the component artifacts of the HL7 V3 messaging methodology and their
interrelationships. Each artifact is described below.
HL7 v3 Artifacts
AR TE RIM
Reference Information
Application Role Trigger Event
Model
Instantiate
DMIM
ST Sender Receiver Domain Message
Storyboard Information Model
Restrict
Triggers
IN RMIM
References Refined Message
Interaction
Information Model
Example
Restrict
HMD
Hierarchical Message
Definition
SN
Storyboard Narrative Restrict
Content MT
Message Type
Figure 12 – HL7 v3 Messaging Artifacts
D.2 Specification Components

D.2.1 HL7 Storyboards
Storyboards, are similar to ‘Use Cases’ and are used to explain the business environment and
requirements for the messaging information flow. The storyboards show a direct linkage between the
business specifications and the technical messages designed to support them. The process of
storyboarding lays the foundation for describing HL7 messages and their content.
The HL7 Storyboards are comprised of the following sections:
• Purpose: The purpose is a short narrative that describes the generic set of actions that the storyboard
represents.
• Interaction Diagram: The Interaction Diagram shows the interactions between the application roles.
These interactions are depicted using a sequence diagram. In the diagram the boxes at the top and
the vertical lines associated with them represent application roles (the types of systems that send and
receive the messages). The arrows show the interactions (message instances) between the various
application roles. The names and associated artifact codes of those interactions are noted within the
arrowed lines.
• Narrative(s): A storyboard narrative is a description of a real-life event that provides the necessary
context for the development of a specific interaction described in the storyboard. There may be many
narratives for a particular storyboard each explaining a different environment/business that
demonstrates the purpose of the storyboard and that results in the interactions being communicated.
D.2.2 Application Roles

Application roles represent a set of communication responsibilities that might be implemented by an
application. Thus they describe system components or sub-components that send and/or receive
messages.
When an Application Role is defined, it identifies a list of interactions it is capable of sending (initiating)
and a set of interactions it is capable of receiving and appropriately processing. In some cases, an
Application Role may be capable of both sending and receiving an interaction.
The application roles appear in the Interaction Diagram found in the Storyboard section, the boxes at the
top of the diagram and the corresponding vertical lines represent application roles.
D.2.3 Trigger Events

Trigger events are an explicit set of conditions that initiate the transfer of information between system
components (application roles). It is a real-world event such as the entry of a provider into a registry or
the requesting of a report. The trigger event must able to be systematically recognizable by an automated
system. Trigger events are defined as one of three ‘types’:
• State-Transition Based: Trigger events resulting from a state transition as depicted in the State
Transition Model for a particular message interaction. The trigger for adding a provider, for example,
may be considered a State Transition Based trigger event
• Environment Based: Trigger events may be based on a user request or some other environmental
occurrence such as time of day. For example, the initiation of a query request.
• Interaction Based: Trigger events can be based on another interaction. For example, the event of
responding to a query (which is an interaction) is an Interaction Based trigger event.
D.2.4 Static Information Models
D-2.4.1 Models
The Reference Information Model (RIM) is a static model of health and health care information as
viewed within the scope of HL7 standards development activities. It is the combined consensus view of
information from the perspective of the HL7 working group and the HL7 international affiliates. The RIM is
the ultimate source from which all HL7 version 3.0 protocol specification standards draw their information-
related content.
The Domain Message Information Model (D-MIM) is a subset of the RIM that includes a fully expanded
set of class clones, attributes and relationships that are used to create messages for any particular
domain. For example, the set of classes that are used by the Personnel Management domain is quite
different from that used by the Patient Administration domain. The D-MIMs for these two domains, then,
will be quite different, although both will be derived from the RIM.
The Refined Message Information Models (R-MIMs) are used to express the information content for a
group of messages and is a subset of the D-MIM containing only those classes, attributes and
associations required to compose the desired set of messages. Classes, attributes and associations that
are not required are eliminated and/or constrained as necessary.
The Hierarchical Message Descriptor (HMD) is a grouping of specific Message Types. It is tabular
representation of the sequence of elements (i.e., classes, attributes and associations) contained in an R-
MIM and that define the messages.
A Message Type (MT) represents a unique set of constraints applied against the HMD and defines the
actual payload (fields, data types, constraints etc) that is communicated in an interaction.
D-2.4.2 Model Representations
The Message Information Model is represented as a diagram that shows the relationships between the
classes but it uses diagramming conventions and notations that were developed by HL7 to represent the
specific semantic constructs contained in the critical, "back-bone" classes of the RIM. Although D-MIMs
and R-MIMs could be represented in UML notation, as the RIM is, the HL7 notation provides more details
about the specific constraints and class clones being represented. The HL7 diagramming convention
abbreviates some relationship conventions, enabling diagrams to be smaller and more concise and to
convey more information visually. Understanding the diagramming conventions and notations is key to
understanding how to read D-MIMs and R-MIMs.
D-2.4.3 Interactions
Interactions are a unique association between a specific Message Type (information transfer), a particular
Trigger Event that initiates or "triggers" the transfer and the set of communication responsibilities
expected of an application which receives the message.
A single Interaction explicitly answers the questions:
1. When should the message be sent (Trigger Event)?
2. What are the responsibilities of the receiving application (Receiver Responsibilities)?
3. What message payload should be sent (Message Type)
4. What wrappers should be applied to the message (Transportation & Control Act wrappers)?
5. What options does a recipient have when it receives the interaction.
Each unique combination of Trigger Event, Message Type, Wrappers and Receiver Responsibilities is
represented as a separate interaction.

31 Guide

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

31 Guide

Загружено:

Авторское право:

Доступные форматы

\

HL7 v3 pan-Canadian Messaging

July 12, 2007

Author: Canada Health Infoway

Creation Date: April 11, 2006

Last Updated: July 12, 2007

Document Number: SC-CA-0006-EN

Document Status In Progress

Infoway Project Various

Distribution Infoway pan-Canadian Standards Groups (pCSGs);

Contact Information Toronto Office:

Version Author(s) Change Description Date

Purpose The purpose of this document is to provide implementation, compliance

Structure In addition to the standard “Executive Summary” and “Appendix”

Standards The documentation approach followed in the

2.4 Document Assumptions

2.5 Related Documents

Document Name File Name Comments

2.6 External Supporting Documents

Note to Reader: This document includes artifacts

Note to Reader: This document includes artifacts

Note to Reader: This document includes artifacts

Note to Reader: This document includes artifacts

Project Development Strategy

Development Methodology Package Artifacts/Documents (n Packages)

Issue Detail Reports + Storyboard(s)

Message Models (Visio, Word, MIF)

Publication Database Uses/Creates

HL7 Artifact New content

Non-Normative Ballot Strategy

Figure 1 – Standards Development Documentation Framework (SDDF)

3.1 Document Naming Conventions

Implementation Guide Documentation Framework

Infoway Style Guide

XML Schemas (IN + MT)

Scope & Tracking Payloads

Supporting Business Artifacts

SC-CA = Infoway Business Model

Issue Detail Reports +

Figure 2 – Implementation Guide Documentation Framework

This volume serves multiple purposes, including:

4.2 Implementation Guide Volumes 1-n – Domain Volumes

Message Models (Visio, Word, MIF)

XML Schemas (IN + MT)

Message Worksheets (Excel, Table)

Vocabulary Status Worksheet

4.3.1 Message Models

4.3.1.1 How to Read the Word Message Models

4.3.2 XML Schemas

4.3.3 Message Worksheets

4.3.4 Vocabulary Status Worksheet

4.3.4.1 How to Read the Vocabulary Status Worksheet

Scope & Tracking

4.4.2 Scope & Tracking Framework

4.4.2.1 How to Read the Scope & Tracking Framework

Issue Detail Reports +

4.5.1 Business Model

4.5.2 Issue Detail Reports + Discussion Documents

Contraindication Contraindication checking will potentially occur at multiple levels, including

However, there may be situations where the local contraindication checking

Contraindication It is assumed that contraindication checking will consider masked records.

Contraindication EHR/DIS functions in jurisdictions will have a contraindication checking

If these attributes need to be updated in a client registry, an application must