Western Health Information Collaborative (WHIC) CDM HL7 Message Specifications Implementation Guide

User Manual:

Open the PDF directly: View PDF .
Page Count: 104

Download
Open PDF In Browser	View PDF

Western Health Information Collaborative (WHIC)

Western Canada Chronic Disease
Management Infostructure Initiative
Phase 2: Data Standards and HL7 Messaging

CDM HL7 Message Specifications – Implementation Guide

FINAL - 02/28/2006 9:52 AM

Prepared by
Western Health Information Collaborative
February 28, 2006 – Version 1.9

CDM HL7 Message Specifications – Implementation Guide

Page - i

Terms of Use
Copyright/Permission to Reproduce
The Government of Alberta owns copyright in this document. In this context, the Government of Alberta is
defined as the “Lead” jurisdiction relative to the Western Health Information Collaborative (WHIC) Chronic
Disease Management (CDM) project and holds ownership of common project materials, including this
document, in trust for the benefit of the Government of British Columbia, the Government of Saskatchewan and
the Government of Manitoba (parties participating in the WHIC CDM project and contributing to the project
deliverables – hereinafter the “WHIC provinces”).

Non-commercial or Educational Reproduction
Information in this document is intended to be readily available for personal and public non-commercial
(educational) use and may be reproduced, in part or in whole and by any means, without charge or further
permission from the Government of Alberta for these purposes.
We ask only that:
•
•
•

Users exercise due diligence in ensuring the accuracy of the materials reproduced;
The Western Health Information Collaborative be identified as the source of the information; and,
Any reproduction is not represented as an official version of the materials reproduced, nor as having
been made in affiliation with or with the endorsement of the Government of Alberta (on behalf of
WHIC).

Reproduction rights refer only to text. Logos, symbols, photographs and any other graphical material may not
be used or reproduced without permission unless explicitly stated in the source document.

Commercial Reproduction
Reproduction of this document, in whole or in part, for commercial purposes is prohibited except with written
permission from the Government of Alberta (on behalf of the WHIC provinces). Through the permission
granting process, the Government of Alberta helps to ensure that individuals or organizations wishing to
reproduce these materials for commercial purposes have access to the most accurate, up-to-date versions. To
obtain permission to reproduce materials on this site for commercial purposes, please contact:
Alberta Health and Wellness
Information Management Branch
21st Floor, 10025 Jasper Avenue, Telus Plaza North
Edmonton, Alberta
Canada
T5J 1S6 or
hisca@gov.ab.ca
© 2005 Government of Alberta

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - ii

Feedback Please!
We are interested in any feedback you may have on these materials. In addition, if you are contemplating doing
any further work in the area of chronic disease management data standards and/or electronic messaging, we
would be interested in hearing about your plans. Queries about our project work are also welcomed. Please
direct your feedback to the WHIC – CDM Project Director:
Michael.Hurka@gov.ab.ca

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - iii

Change Record:
Date

Author

Version

Change Reference

2005-Mar-20

CDM Team

1.0

Draft outline

2005-May-18

CDM Team

1.1

Initial content

2005-Jun-06

CDM Team

1.2

2005-Jun-07

CDM Team

1.3

2005-Jun-13

CDM Team

1.4

2005-Jun-15

CDM Team

1.5

2005-June-30

CDM Team

1.6

Updates (part 1 of 2) resulting from CDM
Data Working Group meeting May 25/26.
Minor formatting changes and updates from
PMO review
Distributed to Vendors
Finalized models and changes arising from
final quality assurance.
Distributed to CDM Data Working Group.
Complete remaining sections and redistribute to the DWG.
Incorporated feedback from DWG review.
Published as FINAL version

2005-Dec-23

CDM Team

1.7

•

Removed Disclaimer statement
inserted Terms of Use statement

•

Updated the document tables in section
1.7.1 Companion Documents and 1.7.2
Included Attachments

•

Inserted updated RMIM and DMIM
models

•

Minor editing corrections

•

Inserted updated Storyboards

and

2006-Feb-13

CDM Team

1.8

•

Inserted updated Storyboards
o Minor wording changes
o Relabelled interactions on
diagrams

2006-Feb-28

CDM Team

1.9

•

Minor corrections made to the following
sections (to align with the HL7
International Patient Care Domain):
o 4.2.3 Trigger Events – renamed
o 4.2.5 Message Types –
renamed
o 4.2.6 Interactions – renamed

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Date

Author

Page - iv

Version

Change Reference

o
o
o

4.3.2 Storyboards – renamed
interactions in diagram
4.7 Message Specifications –
renamed
4.7.2 CDM Record Query
Request – renamed message

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - v

PREFACE – QUICK DOCUMENT OVERVIEW
Purpose

The purpose of this document is to define and reference the Chronic
Disease Management (CDM) HL7 Message Specifications and provide
implementation, compliance and conformance guidelines for use in
developing software that conforms to the specifications developed by
this project. It will also provide additional information identified during
the standards development process and deemed necessary for
implementation. Mapping information may be included for selected preexisting specifications.

Audience

The audience for this document includes the organizations implementing
the CDM HL7 Message Specifications. This includes technical and
business audiences who will use the guide to develop implementations
and validate that these implementations conform to the specifications
and to the requirements of the stakeholder organizations.

Structure

In addition to the standard “Executive Summary” and “Appendix”
sections, this document includes the following specific sections:
Introduction

Describes
the
purpose
for
the
Implementation Guide, provides an overview
of licensing requirements, and identifies
related Western Canada CDM Infostructure
Initiative documents.

Implementation
Considerations &
Guidelines

Identifies key considerations, guidelines and
strategies for implementers of the CDM suite
of HL7 messages.

HL7 Conformance

Provides guidance on how implementations
can conform to the CDM HL7 Message
Specifications.

Specification and
Models

Describes or references all of the pertinent
message artifacts such as message models,
message schemas, and message samples.

Standard Maintenance

Describes how the CDM HL7 Message
Specifications – Implementation Guide will
be maintained.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - vi

TABLE OF CONTENTS
1. Introduction ............................................................................................................................... 1
1.1.
1.2.
1.3.
1.4.
1.5.

Scope ............................................................................................................................ 1
Purpose ............................................................................................................................ 1
Audience.......................................................................................................................... 1
Prerequisites .................................................................................................................... 1
Licensing Requirements .................................................................................................. 2
1.5.1. LOINC and RELMA licenses............................................................................. 2
1.5.2. ICD-10–CA (CIHI) ............................................................................................ 2
1.5.3. ICD 10 – World Health Organization (WHO) ................................................... 3
1.5.4. HL7
............................................................................................................... 4
1.6. Assumptions .................................................................................................................... 5
1.7. Related Documents.......................................................................................................... 5
1.7.1. Companion Documents ...................................................................................... 6
1.7.2. Included Attachments ......................................................................................... 7
1.8. Organization of this Document........................................................................................ 9
2. Implementation Considerations & Guidelines ........................................................................ 10
2.1.
2.2.
2.3.
2.4.
2.5.
2.6.
2.7.
2.8.
2.9.
2.10.
2.11.

Message Scope .............................................................................................................. 10
General Considerations.................................................................................................. 10
Vocabulary (Code) Considerations................................................................................ 12
Medication Considerations ............................................................................................ 13
Laboratory Considerations ............................................................................................ 13
Diagnostic Image Considerations .................................................................................. 13
General Observation Considerations ............................................................................. 14
Linking Considerations.................................................................................................. 14
Message Wrappers and Payloads .................................................................................. 14
Message Flow ................................................................................................................ 15
OID (Object Identifier) Strategy and Guidance............................................................. 17
2.11.1. Common Identifiers.......................................................................................... 17
2.11.2. Application-specific Identifiers ........................................................................ 17
2.11.3. Code Sets .......................................................................................................... 18
2.11.4. HL7 Message Artifacts..................................................................................... 18
2.11.5. HL7 and OIDs .................................................................................................. 18

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - vii

2.12. CDM OID (Object Identifier) Usage............................................................................. 22
2.13. Communication Protocols ............................................................................................. 22
2.14. Relationship to Other HL7 V3 pan-Canadian Standards............................................... 22
2.14.1. Client Registry (PA Domain) ........................................................................... 22
2.14.2. Provider Registry (PM Domain)....................................................................... 23
2.14.3. Pharmacy / CeRx (RX Domain)....................................................................... 23
3. HL7 Conformance................................................................................................................... 24
3.1. Background.................................................................................................................... 24
3.2. Attribute / Association Conformance Values ................................................................ 25
3.2.1. Mandatory......................................................................................................... 25
3.2.2. Populated .......................................................................................................... 25
3.2.3. Required ........................................................................................................... 26
3.2.4. Optional ............................................................................................................ 26
4. Specification and Models ........................................................................................................ 27
4.1. CDM Data Standards and CDM HL7 Message Standards Mapping............................. 27
4.2. Dynamic Model ............................................................................................................. 27
4.2.1. CDM Dynamic Model Characteristics ............................................................. 27
4.2.2. Notification Model – Considerations ............................................................... 28
4.2.3. Trigger Events .................................................................................................. 29
4.2.4. Application Roles ............................................................................................. 30
4.2.5. Message Types ................................................................................................. 30
4.2.6. Interactions ....................................................................................................... 31
4.3. Interaction Models......................................................................................................... 32
4.3.1. Communicate a person’s CDM data (DOPC_ST000019)................................ 32
4.3.2. Retrieve a person’s CDM data (DOPC_ST000020)......................................... 34
4.3.3. Ongoing CDM data exchange (DOPC_ST000022) ......................................... 36
4.4. Message Wrappers......................................................................................................... 37
4.4.1. MCCI_MT000100CA – Request Transport Wrapper ...................................... 38
4.4.2. MCCI_MT000300CA – Application Ack Transport Wrapper......................... 38
4.4.3. MCAI_MT700210CA - Trigger Event Wrapper for Acts................................ 39
4.4.4. QUQI_MT020000CA - Trigger Event Wrapper for Queries ........................... 40
4.4.5. QUQI_MT120000CA - Trigger Event Wrapper for Query Responses............ 41
4.5. Common Message Element Types ................................................................................ 41
4.6. CDM Domain Message Information Model (DMIM)................................................... 43
4.6.1. CDM Domain Model Walkthrough.................................................................. 43

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - viii

4.7. Message Specification Details....................................................................................... 47
4.7.1. REPC_RM000001CA - CDM Record ............................................................. 48
4.7.2. REPC_RM000002CA - CDM Record Query Request..................................... 49
4.8. Message Schemas .......................................................................................................... 50
4.9. Message Samples........................................................................................................... 53
4.10. Data Types..................................................................................................................... 54
5. Standard Maintenance ............................................................................................................. 55
5.1. Change Management Overview .................................................................................... 55
5.2. Change Management Process ........................................................................................ 55
5.3. Extensibility................................................................................................................... 56

List of Figures
Figure 1 – HL7 Message Structure ................................................................................................ 15
Figure 2 – HL7 OID Registry ........................................................................................................ 19
Figure 3 – Communicate a person’s CDM data – Interaction Diagram ........................................ 33
Figure 4 – Retrieve a person’s CDM data – Interaction Diagram ................................................. 35
Figure 5 – Ongoing CDM data exchange – Interaction Diagram .................................................. 36
Figure 6 – MCCI_MT000100CA – Request Transport Wrapper .................................................. 38
Figure 7 – MCCI_MT000300CA – Application Ack Transport Wrapper..................................... 38
Figure 8 – MCAI_MT700210CA - Trigger Event Wrapper for Acts............................................ 39
Figure 9 – QUQI_MT020000CA - Trigger Event Wrapper for Queries ....................................... 40
Figure 10 – QUQI_MT120000CA - Trigger Event Wrapper for Query Responses...................... 41
Figure 11 – CDM Domain Message Information Model (DMIM)................................................ 43
Figure 12 – CDM Record Message Model (RMIM) ..................................................................... 48
Figure 13 – CDM Record Query Request Message Model (RMIM)............................................. 49

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - ix

Figure 14 – CDM Record Notification Schema............................................................................. 52
Figure 15 – XML Schema and HL7 RMIM .................................................................................. 53
Figure 16 – XML Message Sample and HL7 RMIM .................................................................... 54

Appendices
APPENDIX A.

GLOSSARY

APPENDIX B.

HL7 METHODOLOGY BACKGROUND

APPENDIX C.

EXTENSIBILITY

APPENDIX D.

CDM DATA TYPES

APPENDIX E.

CDM OBJECT IDENTIFIERS

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 1

INTRODUCTION

1.1. Scope
The Implementation Guide scope includes information required by implementers of the CDM
HL7 Message Specifications to understand the specification and how it should be implemented.
The scope of this document is limited to the deliverable scope as defined by the Western Canada
CDM Infostructure Initiative through the applicable project definition documentation.

1.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 specifications developed by this project. It will also provide the additional
information necessary to implement the developed specifications including business rules not
specified through the message constructs.

1.3. Audience
The audiences for this document are organizations implementing the CDM HL7 Message
Specifications. This audience includes technical and business readers who will use the guide to
develop implementations and validate that these implementations conform to the specifications
and to the requirements of the associated stakeholder organizations.

1.4. Prerequisites
A working knowledge of HL7 version 3 messaging, including the HL7 Reference Information
Model (RIM) and HL7 Message Development Framework (MDF) is required. HL7 has provided
the Version 3 Guide at http://www.hl7.org/v3ballot/html/welcome/environment/index.htm (click
Introduction, select Version 3 Guide). A brief background on HL7 Methodology has also been
included in Appendix B – HL7 Methodology Background.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 2

1.5. Licensing Requirements
In general, the standards for vocabulary and terminology, along with the HL7 version 3 artifacts
will be widely available and free for use by implementers working in Canada who are members
of HL7 Canada or have formal agreements with the Canadian Institute for Health Information
(CIHI). However, it is the responsibility of the implementer to ensure that their particular
implementation satisfies the terms of the relevant licenses.
This section outlines the relevant licenses, and highlights key areas that must be understood by all
users of the WHIC CDM standard. It also gives source addresses for further review in relation to
any specific queries that may occur at the time of implementation.
1.5.1. LOINC and RELMA licenses
Full license statement and details relating to both RELMA and LOINC can be found at
http://www.regenstrief.org/loinc/license. We have highlighted some key points of the license
agreement here, but implementers need to be familiar with this document and assure themselves
that a particular implementation is not contravening the license.
The principal concern of the license is to prevent dilution of the existing LOINC codes, but
otherwise to allow its free use by projects without incurring cost.
•

•

The purpose of the LOINC codes and LOINC tables is to provide definitive standards for
identifying clinical information in electronic reports. The license is to prevent the dilution of
this purpose, thus users shall not use the RELMA program, RELMA Users' Manual, RELMA
database, LOINC Users' Guide, LOINC database, LOINC table or related files, and / or the
LOINC codes for the purpose of developing or promulgating a different standard for
identifying laboratory test results, diagnostic study reports, clinical measurements and
observations or orders for these entities in electronic reports and messages.
Users shall not change the meaning of any of the LOINC codes. Users shall not change the
name of, any contents of, or any fields in the LOINC table. Users may add new fields to the
LOINC table to attach additional information to existing LOINC records.
Requests for new LOINC codes can be submitted to Regenstrief. The process for
submissions is described http://www.regenstrief.org/loinc/submit/.

1.5.2. ICD-10–CA (CIHI)
CIHI maintains and supports a number of Health Information Technology standards, specifically
ICD-10–CA and CCI codes.
See http://secure.cihi.ca/cihiweb/dispPage.jsp?cw_page=codingclass_e for discussion.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 3

Currently CIHI supports and maintains the following classifications:
•

•
•

ICD-10-CA - Enhanced Canadian version of the 10th revision of the International Statistical
Classification of Diseases and Related Health Problems. ICD-10-CA replaces the earlier
ICD-9/ICD9-CM classification.
CCI - Canadian Classification of Health Interventions, developed to accompany ICD-10-CA.
CCI replaces the earlier CCP classification.
ICF - International Classification of Functioning, Disability and Health (formerly known as
ICIDH).

Currently, inpatient data is being reported to CIHI across Canada with the possible exception of
Quebec. ICD-10-CA and CCI are used in the data that is reported. Thus, each jurisdiction is
already using the coding systems and has established bi-lateral agreements with CIHI. All
regions and hospitals therefore should have copies and also each Provincial Ministry of Health.
Outside of the Governmental bodies, the cost to purchase the CIHI coding systems is the
following:
•
•

Per five concurrent users, plus PST in Ontario and British Columbia the cost is $300 for
members and $475 for non-members.
Per single user, plus PST in Ontario and British Columbia the cost is $150 for members and
$225 for non-members.

It is the responsibility of implementers to ensure that they have a valid license for the use of CIHI
maintained standards.
1.5.3. ICD 10 – World Health Organization (WHO)
ICD 10 International (WHO supported) version is available for access at no cost from the WHO
web site – http://www.who.int/classifications/icd/en/.
However, any sort of commercial use requires prior authorization from WHO, and is subject to
copyright notice – see http://www.who.int/about/copyright/en/. The key section of the copyright
notice is reproduced below.
•

The information in the various pages of the WHO web site is issued by the World Health
Organization for general distribution. The information presented is protected under the Berne
Convention for the Protection of Literature and Artistic works, under other international
conventions and under national laws on copyright and neighbouring rights. Extracts of the
information in the web site may be reviewed, reproduced or translated for research or private
study but not for sale or for use in conjunction with commercial purposes. Any use of information
in the web site should be accompanied by an acknowledgment of WHO as the source, citing the

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 4

uniform resource locator (URL) of the article. Reproduction or translation of substantial portions
of the web site, or any use other than for educational or other non-commercial purposes, requires
explicit, prior authorization in writing. Applications and enquiries should be addressed to the
programme responsible for the page used.
1.5.4. HL7
In general, all HL7 standards are freely available to organizations that are members of HL7. The
entirety of HL7 policies and procedures are contained in the policy and procedures manual –
available at the following address:
http://www.hl7.org/Library/General/HL7_pnpManual_041209.pdf.
Implementers should read and familiarize themselves with the material relating to protection of
Intellectual Property, however, the most important section is on page 41, and states as follows:
•

POL 18.01.01 Copyright Protection
The HL7 Standards are an evolving and expanding body of work prepared by the members of
HL7. They are protected as works of copyrightable authorship under applicable US and
international copyright principles. Consistent with these principles, HL7 asserts and holds
domestic and international copyrights to the Standards. Recognizing that the Standards are
the work product of the membership of HL7, and that HL7 is the collective representative of
all of the member’s interests, these copyrights are asserted and held by Health Level Seven,
Inc. in its capacity as the representative of its total membership. All members of HL7 have
and will continue to possess the usage rights to the Standards as authorized by the HL7
member agreements and International Affiliate agreements.

•

POL 18.01.04 Public Access to HL7 Copyrighted Vocabulary Tables
The content of HL7 Version 2 and Version 3 Vocabulary Tables will be made available free
for use electronically. HL7 reserves the copyright on all vocabulary content, but allows its
use and distribution subject to the provisions of the licensing agreement shown in Addendum
C. The codes and text may be used without further license in all applications, databases, and
derivative works except those that seek to circumvent, compete with or replace the HL7
Vocabulary table values.
HL7 shall provide the capability to download the HL7 Vocabulary Tables via the HL7 Web
site.

In Canada, via its web site, CIHI offers HL7 Canada members unrestricted access to HL7
standards and many other related tools.
See: http://secure.cihi.ca/cihiweb/dispPage.jsp?cw_page=infostand_hl7can_software_e

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 5

Membership costs range from $200.00 / year (individual) to $2500.00 / year (corporate member
with > $50 million / year in health care revenues).

1.6. 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 specification may vary between
jurisdictions. Efforts have been made in the development of the 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.

1.7. Related Documents
The related documents noted below are broken down into the following categories:
•

Companion Documents
Companion documents are required with this guide to fully describe the CDM HL7 Message
Specifications. Materials from companion documents are not included in this document
except by reference.

•

Included Attachments
Some documents are intrinsically part of this guide, but could not be included in line with the
document due to different formats or due to the size of these documents. They have been
included as appendices, with references to specific file names.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 6

1.7.1. Companion Documents
Short Name

Document Name

Comments

CDM Data Standards

Reference materials for all clinical data
elements, including vocabulary, used in
the CDM HL7 Message Specifications.
REFERENCE: The Chronic Disease
Model for background on the generic
chronic disease model.
REFERENCE: CDM Data Standards for
a description of the record level, clinical,
and detail data elements.
REFERENCE: Appendix A to E for
coding systems, record level data
elements, clinical data elements, detail
data elements and code tables.

•

CDM Data Standards Introduction

•

CDM Data Standards Appendix A Coding
Systems

•

CDM Data Standards Appendix B Record
Level Data

•

CDM Data Standards Appendix C Clinical Data

•

CDM Data Standards Appendix D Detailed Data

•

CDM Data Standards Appendix E Code Tables

Location: http://whic.org/public/profiles/cdm.html
Version 3 Guide

HL7 V3 Guide

Provides background on HL7 V3, the
Reference Information Model (RIM) and
the HL7 V3 Message Development
Framework (MDF), as well as insights
into artifact numbering.

Location: http://www.hl7.org/v3ballot/html/welcome/environment/index.htm (click Introduction)
Jurisdictional
Supplemental
Implementation Guides

Location:

Official name of these
documents to be provided by
individual jurisdictions.

Provides supplemental information for
implementing the CDM standards in a
particular jurisdiction. A jurisdiction is
allowed to tighten the CDM standard
and these guides will expose those
constraints to implementers.

Note to Reader: URL to be posted by each jurisdiction, as available.

CDM Data Standard – HL7
Mapping

This spreadsheet provides a mapping of
the data elements (CDM Data
Standards) to the HL7 structural
attributes (message models and design
documents).

Location: http://whic.org/public/profiles/cdm.html

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 7

1.7.2. Included Attachments
Short Name

Document Name

Comments

Request Transport Wrapper
Message Design Document

Describes the detailed attribute
descriptions, rationale, conformance
(e.g.,
mandatory,
populated,
required), repetitions, vocabulary
code references for the specified
message model.

Location: http://whic.org/public/profiles/cdm.html
Application Ack Transport
Wrapper Message Design
Document

Application Ack Transport
Wrapper Message Design
Document

Describes the detailed attribute
descriptions, rationale, conformance
(e.g.,
mandatory,
populated,
required), repetitions, vocabulary
code references for the specified
message model.

Location: http://whic.org/public/profiles/cdm.html
Trigger Event Wrapper for
Acts Message Design
Document

Trigger Event Wrapper for Acts
Message Design Document

Describes the detailed attribute
descriptions, rationale, conformance
(e.g.,
mandatory,
populated,
required), repetitions, vocabulary
code references for the specified
message model.

Location: http://whic.org/public/profiles/cdm.html
Trigger Event Wrapper for
Queries Message Design
Document

Trigger Event Wrapper for
Queries Message Design
Document

Describes the detailed attribute
descriptions, rationale, conformance
(e.g.,
mandatory,
populated,
required), repetitions, vocabulary
code references for the specified
message model.

Location: http://whic.org/public/profiles/cdm.html
Trigger Event Wrapper for
Query Responses Message
Design Document

Trigger Event Wrapper for
Query Responses Message
Design Document

Describes the detailed attribute
descriptions, rationale, conformance
(e.g.,
mandatory,
populated,
required), repetitions, vocabulary
code references for the specified
message model.

Location: http://whic.org/public/profiles/cdm.html

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 8

Short Name

Document Name

Comments

CDM Record Message
Design Document

CDM Record Message Design
Document

Describes the detailed attribute
descriptions, rationale, conformance
(e.g.,
mandatory,
populated,
required), repetitions, vocabulary
code references for the specified
message model.

Location: http://whic.org/public/profiles/cdm.html
CDM Record Query Request
Message Design Document

CDM Record Query Message
Design Document

Describes the detailed attribute
descriptions, rationale, conformance
(e.g.,
mandatory,
populated,
required), repetitions, vocabulary
code references for the specified
message model.

Location: http://whic.org/public/profiles/cdm.html
CDM Record XML Message
Schemas

CDM Record XML Message
Schemas

XML schema(s) for the requisite
message model(s).

Location: http://whic.org/public/profiles/cdm.html
Sample CDM Record Query
Request Message

Sample CDM Record Query
Message

XML message sample(s) for the
requisite message model(s).

Location: http://whic.org/public/profiles/cdm.html
Sample
CDM
Record
Notification Message

Sample
CDM
Notification Message

Record

XML message sample(s) for the
requisite message model(s).

Location: http://whic.org/public/profiles/cdm.html
Sample Accept
Acknowledgement Message

Sample Accept
Acknowledgement Message

XML message sample(s) for the
requisite message model(s).

Location: http://whic.org/public/profiles/cdm.html
Sample Reject
Acknowledgement Message

Sample Reject
Acknowledgement Message

XML message sample(s) for the
requisite message model(s).

Location: http://whic.org/public/profiles/cdm.html
CDM Data Standard – CDM
HL7 Message Standard
Mapping

CDM Data Standard – HL7
Mapping

A mapping between the CDM Data
Standard data elements and the
CDM HL7 Message Standard
attributes.

Location: http://whic.org/public/profiles/cdm.html

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 9

1.8. Organization of this Document
This document is organized as follows:
•

•
•
•
•
•

Section I Introduction: Describes the purpose for the Implementation Guide, provides an
overview of licensing requirements, and identifies related Western Canada CDM
Infostructure Initiative documents.
Section II Implementation Considerations & Guidelines: Identifies key considerations,
guidelines and strategies for implementers of the CDM suite of HL7 messages.
Section III Conformance: Provides guidance on how implementations can conform to the
CDM HL7 Message Specifications.
Section IV Specifications and Models: Describes or references all of the pertinent message
artifacts such as message models, message schemas, and message samples.
Section V Standard Maintenance: Describes how the CDM HL7 Message Specifications –
Implementation Guide will be maintained.
Appendices: Multiple appendices contain the additional content for this guide.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 10

IMPLEMENTATION CONSIDERATIONS & GUIDELINES
During the development of the specifications, implementation considerations and guidelines were
identified. The high level considerations have been included in this Implementation Guide in
order to assist implementers. Implementation considerations related to specific attributes within
messages have been clearly noted within the message design documents and are not included in
this section of the Implementation Guide (e.g., Procedure date has an implementation note around
reporting dates). The developers of the specification do not assert that the set of implementation
considerations and guidelines are complete – particularly in areas of professional practice.
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).

2.1. Message Scope
The following interactions, noted later in this guide, are noted below to help illustrate the scope of
the CDM HL7 Message Specifications:
•
•
•

CDM Record Query Request
CDM Record Query Response
CDM Record Notification.

The message contents for the last 2 interactions (CDM Record Query Response and CDM Record
Notification) use the same message model and are commonly referred to in the following sections
as the CDM Record.

2.2. General Considerations
Several considerations and guidelines are overarching and should be understood by all
jurisdictions seeking to implement these specifications, as well as by any associated stakeholders
and regulatory bodies. These include the following:
•
•
•

CDM messages will be XML (eXtensible Markup Language) only, based on the HL7 V3
standard.
Local implementations can only strengthen HL7 conformance (e.g., making an item marked
as populated to mandatory), not weaken.
Identifiers, used to document specific clinical data elements such as procedures, observations,
lab results, etc., must not change for any subsequent CDM Record Query Response or CDM

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

•

Page - 11

Record Notification. In other words, if a CDM Record included a procedure with a procedure
identifier of 123, the next time the CDM Record for the same person was messaged, the same
procedure identifier (123) must be used.
Care Plans and goals, as a component of the CDM Data Standards and included in the CDM
HL7 Message Specifications, is a minimal approach and is anticipated to be expanded over
time.
Each clinical data element in a person's CDM Record may be authored / created by distinct
providers. This information can be used to provide update capabilities to these providers to
only those portions of the CDM Record that they authored / created.
Systems that collect information from multiple providers for a person's condition (e.g., a
repository) should keep each update to the CDM Record by source provider for audit
purposes.
The CDM HL7 Message Specifications can only be used to send the data identified in the
CDM Data Standards. Additional data (e.g., additional drug attributes) would be obtained
from non-CDM sources and use non-CDM messages (e.g., Pharmaceutical Information
Network (PIN), or PharmaNet, etc.) for obtaining additional information for a person's drug
history.
Systems recording CDM data must note when a piece of information (e.g., lab result, blood
pressure reading) was recorded in order to respond to the queries by system date (event
history). For example, the CDM Record Query Request message can be used to obtain all
changes since the last time the query request was submitted, as a method of obtaining netnew changes. Recording when a piece of information in a person’s CDM Record has been
recorded will allow applications to respond to these types of queries.
Receivers of CDM Record Query Request messages may or may not look at person
corroborating information to confirm person identity. This may include, but is not limited to
such person information as person name, date of birth, gender or some combination thereof.
This guide does not provide specific guidance on how this will be implemented.
The CDM query may return multiple CDM Records for one person. Jurisdictions which plan
on supporting the return of multiple CDM Records should declare this in their jurisdictional
implementation guides. If multiple CDM Records are returned for one person in one HL7 V3
message, there can be at most one Message Transport Wrapper and for each CDM Record,
there will be one Control Act Event Wrapper + one Payload (e.g., CDM Record).
Distinct query parameters, used in the CDM Record Query Request interaction, are to be
considered joined by an “and”, whereas repetitions of the same type of query parameter are to
be considered joined by an “or”.
−

AND example: Specifying parameters such as Person ID and Date Range will return
only CDM Record information for the specified Person ID AND that fall within the
specified Date Range.

−

OR example: Specifying a Person ID and multiple condition types (e.g., Diabetes,
Hypertension, Chronic Kidney Disease) as query parameters will only return CDM
Record information for the specified Person ID AND any of the condition types
specified.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

•

•
•

•

Page - 12

Due to potential privacy considerations and policies within a specific jurisdiction, it may not
be appropriate to message all available information (e.g., HIV / AID medications) to a
recipient. The CDM HL7 Message Specifications will not define these policies. However,
implementers should be aware of what information should be restricted (i.e., masked) before
sending sensitive information to a recipient.
Implementers are expected, as a minimum, to understand all codes and information sent in
the CDM Record.
Only include a clinical data element in the CDM Record if a Y / N determination can be
made. That is, Yes, the clinical data element is present (and may be detailed in the CDM
Record) or No, it can be asserted that the clinical data element is absent or not applicable for
the person's condition.
If a clinical row (e.g., height) is included in the CDM Record, always specify Y or N, even if
the presence of data could be used to imply a Y indication. Being explicit with the Y / N
indicator is preferred over implying that the data exists or not.

2.3. Vocabulary (Code) Considerations
Note to Reader: Additional guidance can be obtained from the CDM Data Standards
document and various appendices.

The following considerations and guidance apply to use of vocabularies (codes):
•

•

•
•

•

Senders of CDM messages must map local codes from their applications to CDM codes, as
specified in the CDM Data Standards before sending a CDM message to a recipient.
Recipients of CDM messages may or may not map CDM codes to local codes, depending on
application requirements, but they must be able to understand all CDM codes.
Use of ICD-10-CA in the CDM Data Standards and CDM HL7 Message Specifications does
not require a source system to use ICD-10-CA in its application, as long as the application
can map its own coding scheme to the CDM Data Standards coding scheme. CIHI provides a
cross-walk from ICD-9-CM to ICD-10-CA. For further information on this mapping, refer to
the CIHI website: http://secure.cihi.ca/cihiweb/dispPage.jsp?cw_page=codingclass_e.
The ISO 2 digit or 3 digit country codes can be used interchangeably.
Observations will use LOINC codes. If an existing LOINC code cannot be determined, a
new code will be proposed (prefixed by an "x") and submitted to Regenstrief to be added to
the LOINC code set.
Some observations may have an “x” (temporary) code and an official LOINC code, once the
code has been accepted by LOINC. At some point, the use of the “x” code should be
deprecated (i.e., no longer used). Procedures for deprecating codes have not been
determined. Therefore, both codes would need to be supported by implementers.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

•

•
•

Page - 13

For any particular clinical data element (e.g., Diabetes), it will only be included in the CDM
Record if any of the "value" codes are applicable. For example, Diabetes may be included if
one of the diagnostic codes (value) for diagnosis, as specified in the standard is applicable
(e.g., E11.900).
A shorthand can be used to specify all value codes that satisfy a pattern (e.g., E11.9* would
be all codes starting with E11.9 whereas E11.* would be all codes starting with E11).
Exceptions, if there are few, may also be noted in the CDM Data Standards.
Allow either the ICD-10-CA or DSM IV codes for depression. This supports clinical settings
(e.g., Mental Health) that are only conversant in one code set.
A mapping or cross walk has been provided to aid clinical settings that receive depression
codes from the code set that they are not conversant in. Reference the CDM Data Standards
document for more information.

2.4. Medication Considerations
The following considerations and guidance apply to use or inclusion of medications:
•

•

If a person is on a specific medication and it has been discontinued, then a subsequent CDM
Record should have an assertion that the person is not on the medication (Y / N Indicator =
“N” + reason).
Medications can be included at two levels: Medications (Class) and Medications (Specify). It
is assumed that the CDM Record will only include either the Class (ATC code) or the
Individual (DIN); with preference for the Individual (DIN) as it provides greater detail.
Access to medication and prescription repositories, if available, may be used for detailed
medication / prescription information, if it is not included in the CDM Record. The CDM
Record is not intended to duplicate detailed medication records that may be recorded in
jurisdictional pharmacy systems (e.g., PIN, Pharmanet, etc.).

2.5. Laboratory Considerations
The following considerations and guidance apply to use or inclusion of laboratory information:
•

Only final lab results may be included in CDM messages, as there is no capability to specify
the status of the result.

2.6. Diagnostic Image Considerations
The following considerations and guidance apply to use or inclusion of diagnostic images:
•

Support for diagnostic images in CDM messages is not provided. The CDM messages do
support the inclusion of diagnostic text reports.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 14

2.7. General Observation Considerations
The following considerations and guidance apply to use or inclusion of general observations:
•

The CDM Data Standards include recommended units of measure for relevant measurements
(e.g., height, weight). However, the CDM HL7 Message Specifications does not require
implementers to convert to these units of measure when including the measurements in the
CDM Record. For example, if the recommended measurement for height is centimetres, and
a specific application captures height in inches, no conversion is required as the HL7 message
will allow you to exchange either metric or British Imperial by stating the value and the unit
of measure.

2.8. Linking Considerations
The following considerations and guidance apply to use or linking:
•
•

•

Only care plans and providers may be linked to a person’s condition.
Linking must be used to tie a care plan to either: [1] one and only one condition; [2] more
than one condition but not all; or [3] all conditions, for a specific person’s CDM Record. In
other words, lack of linking records for a care plan should not be construed that the care plan
applies to one, more than one and not all or all conditions.
Linking of providers is provided as a mechanism to reduce the volume of data in a CDM
message. Providing provider id, name and contact information once against the CDM Record
and then referencing that provider against all the detail record (Supporting Results) only
requires the provider id to be referenced (rather than repeating the name and contact
information).

2.9. Message Wrappers and Payloads
Transactions consist of one or more messages to support both outbound and inbound
communications (i.e., send / receive pairs). Every HL7 V3 message (send or receive) contains
two major components:
•

•

Transport Wrapper: One can think of transport wrappers as being the equivalent of
envelopes which describe where the message originated and where it is being sent, primarily
in technical terms. For example, the transport wrapper indicates which system originated the
message.
Message Content: The message content includes two components:
−

Trigger Event Wrapper: One can think of trigger event wrappers as file folders which
provide business information about the content. This wrapper contains information about
the business event that precipitated the sending of this message, who sent it and other
associated business information such as the facility from which it was sent.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

−

Page - 15

Payload: This element contains the core data attributes for the message such as an
observation or lab result.

It is the combination of each of these components that make up a valid HL7 message. The
diagram below helps to illustrate the wrapper and payload concept:

Message Content – composed of two components, which together form the “message” content:
Control Act Wrapper – Specifies business information suitable for security and audit, and will generally include
who created the message, who entered the message and when/where the message was created.
Payload – Contains the core business content of the message.

Security and audit information typically in Control
Act Wrapper.

Core content, typically in message payload

Authentication mechanism, likely handled through external,
implementation dependent logon mechanisms but potentially
in Control Act Wrapper.

Transport Wrapper – Specifies general information transmitted with the message; typically
intended to support transporting the message from one system to another.
Detailed specifications are contained in:
MCCI_RM000100CA - Request Transport Wrapper;
MCCI_RM000200CA - Accept Ack Transport Wrapper; or
MCCI RM000300CA - Application Ack Transport Wrapper

Figure 1 – HL7 Message Structure

2.10. Message Flow
There are three styles of interaction exchanges, of which the current CDM HL7 Message
Specifications provides support for only options 2 and 3 below:
1. A REQUEST transaction consists of the following types of interactions:
−

REQUEST: This message (e.g., Add Person to CDM Team) is sent by a sending system
(e.g., CDM System A) to a receiving system (e.g., CDM System B);

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

−

Page - 16

RESPONSE, one of:

RESPONSE (ACCEPT): If the intent of the request message was successful (e.g.,
Team member added), this message is returned to the requesting system;

RESPONSE (REFUSE): If the intent of the request message was not successful but
well formed (e.g., Team member is unknown to the receiving system), this message
is returned to the requesting system; or

RESPONSE (REJECT): If the request message is malformed (that is to say it did not
follow the formatting specifications of the standard), a standard HL7 message is
returned 1 . Note that the details of this message are not specified in this document.
Please consult the transmission infrastructure section of the HL7 version 3
specifications under Infrastructure Management (IM) Domain for further details.

2. A NOTIFICATION transaction consists of the following types of interactions:
−

NOTIFICATION: This message (e.g., CDM Record Notification) is sent by a sending
system (e.g., CDM System A) to a receiving system (e.g., CDM System B) as a simple
notification, with no response message returned (other than a message receipt
acknowledgement);

−

RESPONSE (REJECT): If the notification message is malformed (that is to say it did not
follow the formatting specifications of the standard), a standard HL7 message is
returned 2 . Note that the details of this message are not specified in this document.
Please consult the transmission infrastructure section of the HL7 version 3 specifications
under Infrastructure Management (IM) Domain for further details.

3. A QUERY REQUEST transaction consists of the following types of interactions:

1
2
3

−

QUERY REQUEST: This message (e.g., CDM Record Query Request) is sent by a
sending system (e.g., CDM System A) to a receiving system (e.g., CDM System B);

−

RESPONSE, one of:

QUERY RESPONSE (ACCEPT): If the intent of the query request message was
successful, this message will contain the query results, which could include no
records found;

QUERY RESPONSE (REFUSE): If the intent of the query request message was not
successful, this message will indicate reasons why the query was refused (e.g., too
many records, requestor not allowed to run this query, etc.); or

RESPONSE (REJECT): If the query request message is malformed (that is to say it
did not follow the formatting specifications of the standard), a standard HL7 message
is returned 3 . Note that the details of this message are not specified in this document.

Reference HL7 ballot: http://www.hl7.org/v3ballot/html/domains/MT/IMCOMT_ActStatus.htm#COMT_DO000000-ActStatus-ic
Reference HL7 ballot: http://www.hl7.org/v3ballot/html/domains/MT/IMCOMT_ActStatus.htm#COMT_DO000000-ActStatus-ic
Reference HL7 ballot: http://www.hl7.org/v3ballot/html/domains/MT/IMCOMT_ActStatus.htm#COMT_DO000000-ActStatus-ic

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 17

Please consult the transmission infrastructure section of the HL7 version 3
specifications under Infrastructure Management (IM) Domain for further details.

2.11. OID (Object Identifier) Strategy and Guidance
In HL7 V3, Object Identifiers, or OIDs, are used for identifiers (e.g., personal health numbers),
code sets (e.g., gender) and HL7 message artifacts (e.g., interaction ids). OIDs are used to make
identifiers, codes and HL7 message artifacts globally unique and unambiguous. The [OID] +
[identifier, code, or HL7 message artifact id] together make the particular item globally unique.
All identifiers must be communicated using the II (Instance Identifier) datatype. This datatype
makes use of a mandatory OID (Object Identifier) root, and an optional alpha-numeric extension.
The OID provides the namespace for the identifier, corresponding with who issued the identifier
and what type of identifier it is.
CDM will require the following types of identifiers:
•
•

Common identifiers – are identifiers which will be used across all applications, such as
provincial health numbers and provider identifiers
Application-specific identifiers – are identifiers created for records produced by clinical
applications, such as lab observation identifiers and care-plan identifiers

In addition to identifiers, OIDs are used to identify coding systems for code sets (e.g., ICD-10CA, CCI, gender codes) and HL7 message artifacts (e.g., interaction ids, message ids, etc.).
The following sections describe these 3 categories of OID usage in detail, followed by a
walkthrough of the HL7 OID Registry and a listing of OIDs used in CDM messages.
2.11.1. Common Identifiers
Common identifiers must be registered with HL7. All applications will use the same OID for the
same concept. For example, there will be one (and only one) OID used for BC provincial health
number. This will be used for all V3 specifications across all V3 standards.
Some examples of common identifiers include:
•

Person identifier; provider identifier.

2.11.2. Application-specific Identifiers
These identifiers will need to be issued by the application which creates the item. This means
that every application will have to register for its own OID. Within its own OID structure, the

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 18

application will need to create a sub-id for each type of identifier it produces. For example, if a
physician office application is given an OID 2.15.23687.443.27, then it might use the OID
2.15.23687.443.27.1 for locally recorded observations, OID 2.15.23687.443.27.2 for locally
recorded procedures, OID 2.15.23687.443.27.3 for locally created care plan identifiers.
Some examples of application-specific identifiers include:
•

Procedure identifier; Medication / Vaccine prescription or dispense identifier; Observation
identifier; Diagnostic image identifier; Referral identifier; Care plan identifier.

2.11.3. Code Sets
Code sets, or lists of codes, such as gender, diagnosis, drug form, etc., use OIDs (object
identifiers) to identify the coding system from which the codes are drawn from.
Each coded attribute in CDM messages has a defined code set (e.g., ICD-10-CA, DIN, HL7
AdministrativeGenderCode), as noted in the CDM Data Standards. For each of these code sets,
an OID has been defined to clearly identify the code set. Similar to identifiers, a code is made
globally unique by way of a 2-part key – the OID root + the unique code (e.g., M for male as a
gender code).
2.11.4. HL7 Message Artifacts
Similar to identifiers, HL7 message artifacts are identifiers themselves and are made globally
unique by prefixing them with an OID root. HL7 message artifacts are used for interaction ids,
trigger event ids and application role ids.
2.11.5. HL7 and OIDs
HL7 maintains an HL7 OID Registry to record the “official” OID root for each unique namespace
(e.g., BC Provincial Health Number (PHN)). The following information is provided as a
background on how HL7 manages OIDs through the HL7 OID Registry.
The OID Registry was established by members of the Vocabulary Technical Committee over the
past two years to achieve the following goals:
•

•

Allow HL7 member organizations to be assigned an OID under the HL7 root, with the intent
to use that OID as a new root for subsequent registration of HL7 profiles and templates
created by that member,
Allow organizations to register Code Systems, owned and maintained by other organizations,
for use in HL7 messages and applications,

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

•

Page - 19

Allow members to register externally maintained identification systems for potential use as
instance identifiers in HL7 messages and applications.

The home page of the OID registry (OID Registry) is broken into two frames. The right-hand
frame is used for new submissions and the left-hand frame is used for creating reports or to
submit queries for online responses.

Figure 2 – HL7 OID Registry
2.11.5.1. REGISTERING AN OID
The right-hand frame provides fields to identify the submitter, the responsible body, and a contact
point. This is metadata for the new registration; the name and description of the object to be
registered is entered on a subsequent page. At this point the submitter is given a choice, either to
request a new OID under some existing HL7 root, or to register an existing OID not assigned by
HL7. After that choice is made, the submitter continues to a second page to enter a symbolic
name for the new identifier and a short description of the object / entity it represents. There is also
a drop-down box that allows the submitter to declare a type for the object represented by the OID.
Currently the type box allows for the following type declarations:
•

HL7 Member use (e.g., to assign new OIDs under this new root)

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

•
•
•
•

Page - 20

HL7 Conformance Profile
HL7 Registered Template
Externally Maintained Identifier System
External Coding System

The first three type options appear when the submitter requests that the registry assign an OID
under the HL7 root and the second two options appear when the submitter indicates that they
wish to register an externally assigned OID. At the present time there is no option to register a
conformance profile or template under the HL7 Member’s own OID, and there is no explicit
option to describe (beyond a symbolic name) an external coding or identifier system.
2.11.5.2. CREATING AN OID REPORT
The left-hand frame of the OID Registry home page provides several options for creating reports
based on registry content. It also has two specialized query buttons to find OIDs based on a
textual input parameter.
For report creation there are two drop-down boxes; the first provides three report options and the
second provides a choice of two formats in which to receive a download of the report. At present
the report format options are an Excel spreadsheet with each item as a row and with each attribute
as a column, or as a 2-level XML document, with items separated by XML tags and with
attributes for each item separated by commas. At present, the report type options are:
•
•
•

Member OIDs
Coding Systems
All Registered OIDs

The Member OIDs option returns approximately 50 OIDs and supporting metadata. All but three
of the OIDs are consecutively numbered under the HL7 root 2.16.840.1.113883.3, which is itself
in the registry as “Object identifiers assigned to HL7 members, users, and vendors”. The other 3
HL7 Members in this list all have their own non-HL7 OIDs.
This report option returns the following attributes for each OID in the list:
•
•
•
•

Composite OID
Symbolic Name
Object Description
Responsible Body
−

Responsible Body Type

−

Responsible Body OID

−

Responsible Body Address

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

−

Responsible Body Phone

−

Responsible Body Email

Page - 21

−

•

Responsible Body URL
Contact Person
−

Contact Address

−

Contact Phone

−

Contact Email

−

•

Contact Information
Submitter

The Coding Systems report option returns a list of approximately 875 coding systems that have
been registered for use within HL7 committees. Some of these are identified by OIDs created
along some branch of the HL7 base root OID and some are clearly identified by external OIDs.
This report option returns three attribute values for each registered code system: the OID, the
code system symbolic name, and a short description. It does not return any of the other associated
metadata such as submitter, contact, or responsible body.
The All Registered OIDs option returns a list of approximately 1020 items. Each item has the
following four attributes returned for each item in the list:
•
•
•
•

Composite OID
OID Suffix
Symbolic Name
Object Description

At the present time these OIDs are not classified by Type unless they appear in one of the other
two reports.
2.11.5.3. SPECIALIZED OID QUERIES
The bottom half of the left-hand frame also provides buttons for invoking specialized queries.
Each has a textual input parameter that can be typed in by the user. Each returns a list of OIDs.
The first query template allows one to type in a complete OID; if the OID exists in the registry, a
frame will appear with the OID displayed. A Submit button also appears and if clicked presents
the complete collection of metadata submitted for that OID.
The second query template allows one to type in a word or phrase; if that word or phrase appears
in the description of a registered OID, then a drop-down list appears with a list of all such OIDs,

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 22

the name of the OID, and the submitter. One can choose any item in the list to display the
complete collection of metadata submitted for that OID.

2.12. CDM OID (Object Identifier) Usage
Note to Reader: Once identified and registered, the CDM Object Identifiers
will be included formally in this guide for quick reference (Appendix E)

2.13. Communication Protocols
The CDM HL7 Message Specifications do not provide any guidance on how HL7 messages will
be transported between computer applications. It is up to each application wishing to exchange
CDM HL7 messages to determine which techniques will be used to send secure and authenticated
CDM HL7 messages in a reliable manner.

2.14. Relationship to Other HL7 V3 pan-Canadian Standards
2.14.1. Client Registry (PA Domain)
Client registry interactions will likely be required. Implementers should consider the following
guidance:
•

•

The extent to which providers will or will not validate client identifiers prior to sending CDM
messages will be policy dependent. Note that no provisions exist within CDM to
communicate the occurrence of prior transactions with a registry. The core assumption is that
the sender sends “best information” (which may be further defined by policy and regulation)
and that the recipient will take applicable validation actions.
Efforts have been made to align CDM HL7 message components with the in-progress
Infoway Client Registry message specification in areas such as person demographic data
elements, vocabularies and data types (e.g., name, address, telecom). It is assumed that CDM
requirements are a subset of the Client Registry requirements as the need for person
identification and verification is less demanding for CDM systems.
No specific person search and lookup interactions have been defined, nor are included, in the
CDM HL7 Message Specifications - Implementation Guide.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 23

2.14.2. Provider Registry (PM Domain)
Provider registry interactions will likely be required. Implementers should consider the following
guidance:
•
•

Efforts have been made to align CDM HL7 message components with the in-progress
Infoway Provider Registry message specification in areas such as provider role types.
No specific provider search and lookup interactions have been defined, nor are included, in
the CDM HL7 Message Specifications - Implementation Guide.

2.14.3. Pharmacy / CeRx (RX Domain)
Pharmacy interactions will likely be required.
guidance:
•

•

Implementers should consider the following

Efforts have been made to align CDM HL7 message components with the in-progress
Infoway CeRx (ePrescribing) specification in areas such as medication data elements,
vocabularies and data types. It is assumed that CDM requirements are a subset of the CeRx
requirements as the need for ePrescribing support is less demanding for CDM systems. The
purpose of CDM is to provide an idea of what medications a person is receiving in order to
manage a condition. CDM does not support the level of sophistication found in the CeRx
specification (e.g., stopping / resuming medications).
No specific prescribing interactions have been defined, nor are included, in the CDM HL7
Message Specifications - Implementation Guide.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 24

HL7 CONFORMANCE

3.1. Background
There are 3 axis of conformance in HL7 messages:
Attribute / Association Conformance
Attribute / association conformance allows for the specification of how individual attributes and
associations in a message are valued. Using this method, applications are informed on what
constitutes a valid HL7 message and can convey this to receiving applications. Examples are
Mandatory, Populated, Required and Optional, described in the following sections.
Coding Strength
Coding strength suggests that new codes (e.g., new gender codes not included in the current
specification) are either site-negotiated between 2 trading partners (i.e., CWE) or must be added
through a formal code maintenance body (i.e., CNE) for codes managed by external bodies (e.g.,
CIHI for CCI, HL7 for gender).
Repetitions
Repetitions of an attribute or association indicate how many times that attribute or association can
be included in a message. These repetitions are governed by the HL7 Reference Information
Model. Repetitions are noted as [x..y], where x is the lower limit of repetitions, expressed as 0 or
1, and y is the upper limit of repetitions and must be greater than 1, with * indicating infinite.
Examples are:
•
•
•
•
•

[0..1] (may be 0 or 1),
[1..1] (must be 1),
[1..2] (at least 1, up to 2),
[0..*] (may be 0, 1, 2, … up to infinite), and
[1..*] (may be 1, 2, 3, … up to infinite).

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 25

3.2. Attribute / Association Conformance Values
In HL7 V3 messages, each attribute and association has one of the following four conformance
attributes 4 :
3.2.1. Mandatory
This conformance attribute is set for structural and message-critical message elements. For all
attributes and associations marked as mandatory, a “real” value or association must be present,
otherwise the message is non-conformant to the specification. In other words, null is not allowed.
3.2.2. Populated
Must send a value or include an association or explicitly indicate why the attribute or association
is not available or not applicable. In most situations, it is expected for the attribute or association
to be present.
3.2.2.1. NULL FLAVOUR
If a value is not present or available, a null flavour must be specified in the message to convey
why the information is not present. The list of Null Flavours for CDM is noted below:

Null Flavour

Definition

Notes

No Information

No information whatsoever can be inferred from this
exceptional value. This is the most general exceptional
value. It is also the default exceptional value.

MSK

Masked

There is information on this item available but it has not
been provided by the sender due to security, privacy or
other reasons. There may be an alternate mechanism for
gaining access to this information.

Not Applicable

No proper value is applicable in this context (e.g., last
menstrual period for a male).

Note: In HL7 v3, the term Populated is intended to be a cross of Required with minimum cardinality of 1. The term “Populated” is
given to this condition, even though it is not formally noted in HL7 documentation.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 26

Null Flavour

Definition

Notes

OTH

Other

The actual value is not an element in the value domain of
a variable. (e.g., concept not provided by required code
system).

UNK

Unknown

A proper value is applicable, but not known.

ASKU

Asked But Unknown

Information was sought but not found (e.g., individual was
asked but didn't know).

NAV

Temporarily
Unavailable

Information is not available at this time but it is expected
that it will be available later.

NASK

Not Asked

This information has not been sought (e.g., individual was
not asked).

3.2.3. Required
Must be capable of sending a value or association or receiving the value or association.
Expectation is that users will be able to send the data if they have it and it is applicable. Used for
items that should be supported, but where a value will not always be available or known.
3.2.4. Optional
Some applications will be capable of sending / receiving the attribute or association, others will
not. An application cannot fail if the data is present, nor can it fail if the data is not present.
Applications must declare whether they will support the attribute or association or not.
Note: the more optional elements are in the standard, the lower the chance of interoperable
solutions as each application must declare conformance to the standard and can do this in
multiple manners. In most cross-jurisdictional standards, optional has been avoided.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 27

SPECIFICATION AND MODELS
This section of the CDM HL7 Message Specifications – Implementation Guide includes as
reference or in line, all of the HL7 message details necessary for implementation.

4.1. CDM Data Standards and CDM HL7 Message Standards Mapping
A mapping of data elements and structural attributes from the CDM Data Standards to the CDM
HL7 Message Standards has been provided as an external spreadsheet to aid those implementers
who wish to cross reference elements from these standards. While reviewing the CDM HL7
Message Standards, it may be useful to reference the CDM Data Standards for applicable
definitions and other pertinent notes against the source data element. In other situations,
implementers may be familiar with the CDM Data Standards from a clinical perspective and need
to know where each element is housed in the CDM HL7 messages.
Note to Reader: The detailed mapping has been included in an external
document.
Please reference the CDM Data Standard - HL7 Mapping
spreadsheet for additional details.

4.2. Dynamic Model
The Dynamic Model includes all of the interactions necessary to support CDM Record exchange.
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:
•
•
•
•
•

When should the message be sent (Trigger Event)?
What are the responsibilities of the receiving application (Receiver Responsibilities)?
What message payload should be sent (Message Type)?
What wrappers should be applied to the message (Transportation & Control Act wrappers)?
What options does a recipient have when it receives the interaction?

4.2.1. CDM Dynamic Model Characteristics
The suite of CDM HL7 messages supports a Notification model of system interaction. When a
business event occurs (e.g., person with a chronic condition is treated), their entire CDM Record

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 28

is sent to a receiving system which must then determine what to do with the data (e.g., append it
to the person’s CDM Record, update entries or ignore data elements that are not of concern to the
receiving system). The Notification model in HL7 also implies that the receiving system cannot,
other than a message acknowledgement, return additional information to the sending system.
HL7 also supports the concept of a Request model of system interaction, even though this is not
currently supported by the CDM messages. The Request model implies that sending applications
request actions to be performed by receiving systems, which have the ability to accept or refuse
the request. The receiving system may also return information to the sender (e.g., why it was
refused, an identifier that it created to track the request, etc.). This model was not chosen for
CDM messages due to increased complexity in providing complex interactions between sending
and receiving systems.
Other aspects of the dynamic model include polling, batch and deferred processing. These
concepts are inherent in HL7 V3 messages and are not specifically called out in the CDM HL7
Message Specifications – Implementation Guide. Readers are encouraged to reference the HL7
V3
ballot
materials
at
the
following
URL
for
more
information:
http://www.hl7.org/v3ballot/html/welcome/environment/index.htm
(under
Specification
Infrastructure, then Messaging.
4.2.2. Notification Model – Considerations
This section can be used as reference to developers of CDM Repository applications who rely on
CDM Record Notification messages to maintain a person’s CDM Record. It was modified from
the BC Ministry of Health Services, Chronic Disease Management Toolkit, Connecting EMR
systems – XML Import document, version 1.8, November 15, 2004; readers who require
additional information should reference this document.
For each CDM Record the following steps should be undertaken.
Step 1: Validation
•
•

•
•

If the person in the CDM Record matches a person record in the repository on all fields,
proceed to Step 2.
If the person in the CDM Record matches person record in the repository on all fields, and
there is a removal reason, mark the person as removed with the reason specified. Proceed to
Step 2 to confirm any further updates.
If the person in the CDM Record has the same person identifier (e.g., PHN, ULI) as the
repository, but differs on other fields, update the person record and proceed to Step 2.
If the person in the CDM Record does not exist in the repository, add the person and proceed
to Step 2.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 29

Step 2: For each Condition
•

•

If the condition in the CDM Record matches the condition information in the repository on all
fields (i.e., no changes to condition data), proceed to the next condition (Step 2) or to clinical
data elements (Step 3).
If the condition in the CDM Record matches the condition information in the repository on all
fields and there is a removal reason, mark the condition as removed with the reason specified,
and proceed to the next condition (Step 2) or to clinical data elements (Step 3).
If the condition in the CDM Record matches the condition information in the repository but
differs on other fields, update the condition and proceed to the next condition (Step 2) or to
clinical data elements (Step 3).
If the condition in the CDM Record does not exist in the repository, add the condition and
proceed to the next condition (Step 2) or to clinical data elements (Step 3).

Step 3: For each Clinical Data Element
•
•

•

If the clinical data element in the CDM Record matches the clinical data element information
in the repository on all fields, proceed to the next clinical data element (Step 3).
If the clinical data element in the CDM Record matches the clinical data element information
in the repository, but differs on values, update the clinical data element in the repository and
proceed to the next clinical data element (Step 3).
If the clinical data element in the CDM Record does not exist in the repository, add the
clinical data element in the repository and proceed to the next clinical data element (Step 3).

4.2.3. Trigger Events
The following trigger events are included in the CDM HL7 Message Specifications:
•

REPC_TE004014 - Report Care Provision
This trigger event occurs whenever there is “any” change to a person’s chronic CDM Record.
This could include:

Adding or removing conditions.

Changing information about a condition.

Changing or adding 'supporting information' such as lab results, medication
information, etc.

Adding or revising care plans associated with a person’s chronic conditions.

Updating contact information and person information associated with their CDM
Record.

Often, the trigger event will be qualified such that it only fires after a set of changes have
been completed. For example, rather than firing after each new lab result comes in, the

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 30

•

trigger event would fire at the end of the day when a new set of lab results and medication
information have come in.
QUPC_TE043100 - Get Record Profile Query

•

A user or system wishes to retrieve a person’s CDM Record.
QUPC_TE043200 - Get Record Profile Response
A system has received a query requesting a person’s CDM Record.

4.2.4. Application Roles
The following application roles are included in the CDM HL7 Message Specifications:
•

REPC_AR000001CA - CDM Record Information Provider

•

This is a system which is capable of notifying other systems about a person’s CDM Record.
It might include clinical systems (physician office systems, community health systems,
community pharmacy systems, etc.). It might also include CDM repositories which 'push'
CDM information to interested recipients.
REPC_AR000002CA - CDM Record Information Recipient

•

This is a system which accepts notifications about a person’s CDM Record. This could
include both clinical systems (physician office systems, community health systems,
community pharmacy systems, etc.) which receive notifications from each other and / or from
a central repository. Alternatively, it may include a central CDM repository which receives
information from clinical systems.
REPC_AR000003CA - CDM Record Information Questioner

•

This is a system which retrieves (possibly filtered) information about a person’s CDM Record
from another system.
REPC_AR000004CA - CDM Record Information Repository
This is a system which contains a person’s CDM Record and provides the ability to query
that data. Note: This type of system will need to gather its information either through direct
entry, by querying data from another system, or by receiving information as a CDM Record
Information Provider.

4.2.5. Message Types
The following message types are included in the CDM HL7 Message Specifications:
•
•

REPC_RM000001CA - CDM Record
REPC_RM000002CA - CDM Record Query Request

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 31

4.2.6. Interactions
The following interactions are included in the CDM HL7 Message Specifications:
•

REPC_IN000001CA - CDM Record Notification
This interaction involves sending a complete snapshot of a person’s CDM record as a result
of an update to some portion of that record (or perhaps the creation of a new record).
•

Trigger Event Get Care Record Profile Query QUPC_TE043100

•

Transmission Wrapper Request Transport Wrapper MCCI_MT000100CA

•

Control Act Wrapper Trigger Event Wrapper for Queries QUQI_MT020000CA

•

Message Type CDM Record Query Request REPC_MT000002

Sending and Receiving Roles:

•

Sender CDM Record Information Questioner REPC_AR000003CA

•

Receiver CDM Record Information Repository REPC_AR000004CA

REPC_IN000002CA - CDM Record Query Request
This interaction is used to request a person’s CDM record, possibly filtered by condition,
time range, etc.
•

Trigger Event Get Care Record Profile Query QUPC_TE043100

•

Transmission Wrapper Request Transport Wrapper MCCI_MT000100CA

•

Control Act Wrapper Trigger Event Wrapper for Queries QUQI_MT020000CA

•

Message Type CDM Record Query Request REPC_MT000002

Sending and Receiving Roles:

•

Sender CDM Record Information Questioner REPC_AR000003CA

•

Receiver CDM Record Information Repository REPC_AR000004CA

REPC_IN000003CA - CDM Record Query Response
This interaction returns a person’s CDM record, possibly filtered by condition, time range,
etc. in response to a request.
•

Trigger Event Get Care Record Profile Response QUPC_TE043200

•

Transmission Wrapper Accept Level Acknowledgement MCCI_MT000200UV01

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 32

•

Control Act Wrapper Trigger Event Wrapper for Query Responses
QUQI_MT120000CA

•

Query Response Type CDM Record REPC_MT000001

•

Query Definition CDM Record Query Request REPC_MT000002

Sending and Receiving Roles:
•

Sender CDM Record Information Repository REPC_AR000004CA

•

Receiver CDM Record Information Questioner REPC_AR000003CA

4.3. Interaction Models
HL7 interactions are described through storyboards and interaction models. The following
storyboards and interaction models are included in the CDM HL7 Message Specifications. Note
that out of scope interactions are not illustrated in the CDM interaction models.
4.3.1. Communicate a person’s CDM data (DOPC_ST000019)
Purpose:
The purpose of this storyboard is to demonstrate the communication of a person’s CDM data.
•

In the first scenario, we describe the exchange of CDM data for an individual recently
diagnosed with a specific chronic disease (e.g., Diabetes).

•

The second scenario describes providing updates to the CDM data.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 33

Diagram:

Figure 3 – Communicate a person’s CDM data – Interaction Diagram

SCENARIO #1: Create new CDM record
Precondition:
Mrs. Everywoman exhibits new symptoms: an excessive thirst, lethargy, and difficulty
concentrating. She makes an appointment with her General Physician to review her symptoms.
No CDM record currently exists in the CDM System for Mrs. Everywoman.
Activities:
Mrs. Everywoman sees Dr. Patricia Primary, General Physician. After an initial interview and
review of symptoms, Dr. Primary orders laboratory and radiology tests.
After completing the tests, Mrs. Everywoman returns for another appointment with Dr. Primary.
Dr. Primary assesses all findings and test results, and diagnoses Mrs. Everywoman with Type 2
diabetes.
Dr. Primary records the findings of the investigations and diagnosis in the CDM System, enrols
Mrs. Everywoman in the Diabetes Management program, and recommends a referral to Dr.
Specialize, a Diabetologist.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 34

Post condition:
Lab results and assessments by Dr. Primary have been added to the individual’s CDM record. A
notification of Mrs. Everywoman’s CDM record is communicated with other members of the
CDM Team.
SCENARIO #2: Update the CDM record
Precondition:
Mrs. Everywoman meets with her General Physician, Dr. Patricia Primary for a follow up visit.
A CDM record currently exists in the CDM System for Mrs. Everywoman.
Activities:
Mrs. Everywoman sees Dr. Patricia Primary, General Physician. After a review of the current
symptoms, Dr. Primary orders follow up laboratory and radiology tests.
Dr. Primary records the findings of the recent tests in the CDM System.
Post condition:
Recent results have been added to the individual’s CDM record. Notification of the updated CDM
record is sent to the other members of the CDM Team.
4.3.2. Retrieve a person’s CDM data (DOPC_ST000020)
Purpose:
Illustrate the events that occur when a person with a chronic condition presents for care to a new
member of the Chronic Disease Management (CDM) Team. The new provider needs to be able to
access and update the person's condition-specific CDM information.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 35

Diagram:

Figure 4 – Retrieve a person’s CDM data – Interaction Diagram
Precondition:
Mrs. Everywoman meets with Dr. Specialize, her new Diabetologist.
Activities:
Mrs. Everywoman meets with Dr. Specialize, who needs information from the existing CDM
record such as:
•

CDM history.

•

Relevant medical history.

•

Relevant laboratory test results.

•

CDM specific goals and targets in Mrs. Everywoman's diabetes care plan.

During Mrs. Everywoman's visit, Dr. Specialize retrieves the history of all prior CDM
encounters. He checks Mrs. Everywoman's blood pressure, cholesterol levels and discusses her
psychosocial history.
Based on the review of the relevant data, Dr. Specialize orders additional laboratory tests.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 36

The results of the tests are entered into the CDM System, and the updated CDM record is
communicated to all members of the CDM Team.
Post condition:
Review of current and historical medical records by Dr. Specialize, who orders additional tests.
The results are entered into the CDM System, and communicated to all members of the CDM
Team.
4.3.3. Ongoing CDM data exchange (DOPC_ST000022)
Purpose:
This storyboard demonstrates the ongoing exchange of CDM data. In this scenario, we create and
validate an individualized care plan for a person, and communicate the updated contents of the
person’s Chronic Disease Management (CDM) record to all providers who need to know the
current plan for caring for this individual.
Diagram:

Figure 5 – Ongoing CDM data exchange – Interaction Diagram

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 37

Precondition:
Mrs. Everywoman has been recently enrolled in the Diabetes Management Program and is
continuing her enrolment in the Chronic Kidney Disease (CKD) Program. Data about Mrs.
Everywoman and her latest chronic disease (diabetes) is now available in the CDM System.
Activities:
The members of the CDM Team, with full involvement of Mrs. Everywoman and her husband,
review the available plans / templates / guidelines that apply to Mrs. Everywoman's diabetes and
CKD status.
The team agrees on a plan that focuses on regular home monitoring of her condition, proper
medication administration, and self management of hyperglycemic and hypoglycemic episodes.
The proposed Care Plan and Action Plan are entered into the CDM System and all members of
the CDM Team are notified.
Dr. Kidney, her Nephrologist, is asked to review her new diabetes care plan and to confirm its
appropriateness with her CKD program. Upon review, Dr. Kidney recommends that Mrs.
Everywoman have an exercise stress test and also see an Exercise Therapist in order to start a
carefully monitored exercise program.
All members of the CDM Team, including Dr. Kidney and Dr. Primary are notified of the updates
to the CDM data.
Post condition:
A CDM Care Plan is created and is validated with Mrs. Everywoman and the CDM Team. Mrs.
Everywoman's Nephrologist, Dr. Kidney and all other providers in her CDM Team are notified of
the updated CDM data.

4.4. Message Wrappers
There are 2 types of message wrappers in HL7 V3 messages (Transport Wrappers and Trigger
Event Wrappers). These are described in an earlier section of this document. This section
describes the 5 wrappers used in CDM messages.
The following diagrams are obtained from the HL7 V3 standard and are included in this guide for
reference only. Additional detail should be obtained from the HL7 V3 Guide (see References
section in this guide).

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 38

4.4.1. MCCI_MT000100CA – Request Transport Wrapper

Figure 6 – MCCI_MT000100CA – Request Transport Wrapper
Note to Reader: Details on each attribute of this model has been provided in an
external Message Design document. Please reference Request Transport
Wrapper Message Design Document for additional details.
Message wrapper models contain references to vocabulary code sets (e.g.,
HL7StandardVersionCode and AcknowledgementCondition) that are contained in
the HL7 V3 specification.
Valid codes can be obtained at:
http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm#voccontents
and
referencing
the
vocabulary
code
domain
(e.g.,
AcknowledgementCondition).
4.4.2. MCCI_MT000300CA – Application Ack Transport Wrapper

Figure 7 – MCCI_MT000300CA – Application Ack Transport Wrapper

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 39

Note to Reader: Details on each attribute of this model has been provided in an
external Message Design document. Please reference Application Ack Transport
Wrapper Message Design Document for additional details.
Message wrapper models contain references to vocabulary code sets (e.g.,
HL7StandardVersionCode and AcknowledgementCondition) that are contained in
the HL7 V3 specification.
Valid codes can be obtained at:
http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm#voccontents
and
referencing
the
vocabulary
code
domain
(e.g.,
AcknowledgementCondition).
4.4.3. MCAI_MT700210CA - Trigger Event Wrapper for Acts

Figure 8 – MCAI_MT700210CA - Trigger Event Wrapper for Acts
Note to Reader: Details on each attribute of this model has been provided in an
external Message Design document. Please reference Trigger Event Wrapper
for Acts Message Design Document for additional details.
Message wrapper models contain references to vocabulary code sets (e.g.,
HL7StandardVersionCode and AcknowledgementCondition) that are contained in
the HL7 V3 specification.
Valid codes can be obtained at:
http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm#voccontents
and
referencing
the
vocabulary
code
domain
(e.g.,
AcknowledgementCondition).

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 40

4.4.4. QUQI_MT020000CA - Trigger Event Wrapper for Queries

Figure 9 – QUQI_MT020000CA - Trigger Event Wrapper for Queries

Note to Reader: Details on each attribute of this model has been provided in an
external Message Design document. Please reference Trigger Event Wrapper
for Queries Message Design Document for additional details.
Message wrapper models contain references to vocabulary code sets (e.g.,
HL7StandardVersionCode and AcknowledgementCondition) that are contained in
the HL7 V3 specification.
Valid codes can be obtained at:
http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm#voccontents
and
referencing
the
vocabulary
code
domain
(e.g.,
AcknowledgementCondition).

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 41

4.4.5. QUQI_MT120000CA - Trigger Event Wrapper for Query Responses

Figure 10 – QUQI_MT120000CA - Trigger Event Wrapper for Query Responses
Note to Reader: Details on each attribute of this model has been provided in an
external Message Design document. Please reference Trigger Event Wrapper
for Query Responses Message Design Document for additional details.
Message wrapper models contain references to vocabulary code sets (e.g.,
HL7StandardVersionCode and AcknowledgementCondition) that are contained in
the HL7 V3 specification.
Valid codes can be obtained at:
http://www.hl7.org/v3ballot/html/infrastructure/vocabulary/vocabulary.htm#voccontents
and
referencing
the
vocabulary
code
domain
(e.g.,
AcknowledgementCondition).

4.5. Common Message Element Types
Common Message Element Types, or CMETs, are HL7 models that are used (or reused) across
multiple HL7 message domains. Examples include person, provider, medication, etc. CDM does
not include any specific CMETs in CDM HL7 message payloads. CMETs, however, are
included in HL7 message wrappers.
The following CMETs are used by the CDM model.
•

Request Transport Wrapper Message Design Document

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 42

−

•

None.
Application Ack Transport Wrapper Message Design Document
−

•

None.
Trigger Event Wrapper for Acts (MCAI_MT700211CA)
−

COCT_MT260001CA (ALRT) A_IssueEvent[managed]

−

COCT_MT090103CA (ASSIGNED) R_AssignedPerson[identified-contactable]

−

COCT_MT240003CA (SDLOC) R_ServiceDeliveryLocation[contactable]

−

COCT_MT470000CA (CONS) A_ConsentEvent[basic]

COCT_MT050002CA (PAT) R_Patient[identified-confirmable]

COCT_MT090103CA (ASSIGNED) R_AssignedPerson[identified-contactable]

COCT_MT040205CA (CNTCT) R_ResponsibleParty[contact]

COCT_MT240003CA (SDLOC) R_ServiceDeliveryLocation[contactable]
Trigger Event Wrapper for Queries (QUQI_MT020000CA)
−

COCT_DM260001CA (ALRT) A_IssueEvent[universal]

−

COCT_MT090103CA (ASSIGNED) R_AssignedPerson[identified-contactable]

−

COCT_MT240003CA (SDLOC) R_ServiceDeliveryLocation[contactable]

−

COCT_MT470000CA (CONS) A_ConsentEvent[basic]

COCT_MT050002CA (PAT) R_Patient[identified-confirmable]

COCT_MT090103CA (ASSIGNED) R_AssignedPerson[identified-contactable]

COCT_MT040205CA (CNTCT) R_ResponsibleParty[contact]

COCT_MT240003CA (SDLOC) R_ServiceDeliveryLocation[contactable]
Trigger Event Wrapper for Query Responses (QUQI_MT120000CA)
−

•

COCT_DM260001CA (ALRT) A_IssueEvent[universal]
CDM Record (REPC_MT000001CA)
−

•

None.
CDM Record Query Request (QUPC_MT000001CA)
−

None.
Note to Reader: Details on each attribute of the CMETs are included in the
Message Design Document for the model that includes the CMET (e.g., Trigger
Event Wrapper for Queries Message Design Document includes details on the
CMETs in that model).

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 43

4.6. CDM Domain Message Information Model (DMIM)
Note to Reader: Readers are expected to understand how to read HL7 Visio
models. Some guidance has been included as an Appendix to this guide.
The diagram below illustrates the CDM Domain Message Information Model (DMIM), which is
the basis for all CDM message models used to generate CDM HL7 messages. Following the
diagram is a short walkthrough of the model.

Figure 11 – CDM Domain Message Information Model (DMIM)
4.6.1. CDM Domain Model Walkthrough
The Chronic Disease Management record (CDM Record) class is the entry point and the root
class from which messages are derived. It is used to tie together all information about a person
with one or more chronic conditions. It allows for viewing information about a person in a

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 44

systematic way and is closely aligned to the way service providers view information in a paper
based system.
The DMIM indicates several associations between the CDM Record and other elements,
including Person and Chronic Conditions.
Person
The CDM Record applies to a Person (Patient) who is central to the condition and its
management. All chronic-condition records are person-centric. The Person class includes the
following attributes: Person identifiers (Id), Person addresses (addr), Date of birth (birthTime),
and Language types (languageCode).
For each person, a Primary Care Provider can be noted.
Contacts
The CDM Record can have additional information Contacts (PersonalRelationship) representing
persons other than the index person who can be contacted to verify or obtain missing information
pertinent to the CDM Record. Contacts include health care service providers, neighbors, family
and friends, etc.
Chronic Conditions
At least one, and in some cases a multitude, of Chronic Condition(s) (ConditionEvent) are listed
as part of the CDM Record. Each chronic condition identifies the Kind of chronic condition
(value) such as diabetes, hypertension, and / or chronic kidney disease.
Recall Indicator
The Recall Indicator (MonitoringProgramEvent) allows for a person to be flagged for recall
regarding a particular condition. The indicator would allow for individuals under institutional
care or are otherwise unable to participate in routine follow-up to be excluded.
Results
A CDM Record also contains related Results as part of a choice structure, called
SupportingElements (pertinentInformation.pertinentAct.id).
One of the choices within
SupportingElements is Observations (ObservationEvent), which could include lab tests (such as
triglycerides, 24 hour urinary protein), or physical exam results (such as systolic blood pressure,
waist circumference) or medical conditions (such as depression, dyslipidemia) and allergy alerts.
The CDM Record can also contain information on Procedures (ProcedureEvent), which could

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 45

include education as well as major (invasive) vascular interventions, amputations, transplants and
dialysis. The other choice structures include clinical information about Medications / Vaccines
(SubstanceAdministrationEvent), Diagnostic Images (DiagnosticImageEvent), and Referrals
(PatientCareProvisionRequest).
Generally service providers are interested in the results and related information. By way of
illustration, consider the example of diastolic blood pressure;
•
•
•
•
•

Observation date (effectiveTime) is the date the diastolic blood pressure observation was
performed.
The Observation value (value) might be “110 mmHg”.
Observation interpretation (intepretationCode) of “high”.
Observation method code (methodCode) of “right arm sitting”.
More information could be provided in the details section Observation details (text). For
example, “this result is likely to be affected by the person not having taken their medication
today”.

The supporting results were created by a Provider (AssignedEntity), which is associated with the
request or Provider’s order (ActRequest). The Medication / Vaccine dispense date
(fulfillment.supplyEvent.effectiveTime) can also be tracked for a medication / vaccine.
Supporting Observation results might also have a Normal range value
(referenceRange.referenceObservationEventCriterion.value) to communicate expected values
(which may vary from lab to lab and from equipment to equipment).
Provider
There is a need to clearly identify all providers (persons or organizations) who participate in the
delivery of care to the individual, and to identify their role and capabilities when performing care.
The CDM Record has an associated set of providers who are involved in some manner with the
CDM Record and its component pieces of information.
A provider includes a clinically qualified individual, such as a physician, nurse, or social worker,
who assists in the identification, prevention, or treatment of an illness or disability. It can also
include an individual, such as a parent, foster parent, or head of a household, who also assists in
the provision of care for a person with chronic illness. Also the Provider as a role organization
(AssignedEntity3) is used in circumstances when the specific people involved in providing care
are unknown. For example, rather than identifying a particular pharmacist, the provider might be
identified as simply the pharmacy.
The provider type (HealthCareProvider) is a licensed role and identifies that the provider is of a
formal type. The absence of this code indicates an informal provider (e.g., family caregiver).

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 46

There is a need to further categorize physicians and some other providers according to their
clinical area of expertise. In order to further understand the qualification of a provider the
provider specialty (QualifiedEntity) describes the expertise (e.g., Diabetes Specialist Nurse).
The clinical location (Organization3) provides context for where the information is gathered (e.g.,
physically located clinic, hospital, etc.)
Linking
In order to tie a specific condition to a care plan, a linking capability has been provided in the
Chronic Disease Management Model.
•

Care plan cross references (mitigatedBy.mitigatingPatientCareProvisionIntent2.id)

To reference a specific condition, each instance of a care plan must be identified with a unique
identifier. This is then included in the reference from the condition.
Care Plans
Care plans (PatientCareProvisionIntent) refer to planned activities used to manage the chronic
condition(s) affecting the person. Care plans identify the Care plan type / code (e.g., dietary plan,
and physical activity plan). Care plans also have a unique identifier Care plan identifier (id) and
Care plan attachments (text). The care plan attachment (PDF, HTML, plain text, or CDA
document) provides an opportunity for service providers to exchange unstructured but detailed
textual information about a person.
Goals
Many activities and results may also be expressed in the form of Goals
(ObservationEventCriterion2) and also a desired Goal value (value) to be achieved. The goal
value can be compared against a target and the Goal value target date (effectiveTime). For
example a person may wish to achieve a cholesterol value of < 5 mmol / l within a 3 month
period.
Planned Activities
Care plans also have PlannedActivities (PlannedActivities). Planned activities are another choice
structure with various classes that are intended to be performed as part of the management of the
person’s chronic condition. An example is a Planned procedure (ProcedureIntent). A Planned
procedure type (code) is a procedure to be taken in order to change the physical state or
knowledge of the person with the chronic condition. These may include self management skills
development, dialysis, major cardiovascular intervention such as coronary artery bypass graft etc.
The other choices in planned activities are: Planned clinical observations (ObservationIntent)

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 47

that is clinical observations, tests and related measurements, which are to be performed as part of
the care plan. Planned diagnostic image (DiagnosticImageIntent) describes a particular type of
diagnostic imaging (e.g., cardiac ECHO that is planned). Note: only diagnostic text reports, not
images, are supported. Finally Planned medications / vaccines (SubstanceAdministrationIntent)
include
Medication
/
Vaccine
generic
name
(consumable.manufacturedProduct.manufacturedManufacturedMaterialKind.name)
and
Medication / Vaccine dose (doseQuantity).
Reassessment
Continuous monitoring of the individual’s condition and related clinical outcomes, along with the
performance of various planned activities in a structured way are important requirements in the
management of any chronic disease.
The date for any planned reviews (SubjectOfreviewIntent effectiveTime) of most elements in the
CDM data set can be captured and communicated using the Reassessment date. For example, an
A1C test is planned for repeat testing in 3 months. Another example is a medication review date
of the person's use of medications for all or any individual medication.

4.7. Message Specification Details
This section of the guide provides guidance to the message models (RMIMs – Refined Message
Information Models) used in CDM messages. There are 2 message models included in the CDM
HL7 Message Specifications:
•
•

REPC_RM000001CA - CDM Record
REPC_RM000002CA - CDM Record Query Request

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 48

4.7.1. REPC_RM000001CA - CDM Record
The CDM Record message model 5 describes the information necessary to specify the CDM
Record content, as described in the CDM Data Standards document.

Figure 12 – CDM Record Message Model (RMIM)
Note to Reader: Details on each attribute of this model has been provided in an
external Message Design document. Please reference CDM Record Message
Design Document for additional details.

For CDM, the RMIM is the same as the DMIM.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 49

4.7.2. REPC_RM000002CA - CDM Record Query Request
The purpose of a query message is to specify parameters (e.g., person name, chronic condition)
that are used to filter data on the receiving application.

Figure 13 – CDM Record Query Request Message Model (RMIM)
Note to Reader: Details on each attribute of this model has been provided in an
external Message Design document. Please reference CDM Record Query
Message Design Document for additional details.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 50

4.8. Message Schemas
Note to Reader: Message schemas have been provided in an external
document. Please reference CDM Record XML Message Schemas for additional
details.

Note to Reader: Some browsers have the capability to display .XSD files.
However, Internet Explorer has some difficulty opening the CDM .XSD files if they
are simply double-clicked from the file system. To open .XSD files in Internet
Explorer (IE), open IE and drag the .XSD into the browser window to open.

Note to Reader: Notes for viewing CDM Message Schemas:
•

These files are geared for technically inclined people, preferably with some
XML experience.

•

How a schema is read depends on the tool used. One possible XML tool is
XML Spy found at http://www.altova.com/products_ide.html. In order to
experience the XML development environment they offer a free 30 day free
download.

•

Make sure the CDM Record XML Message Schemas zip file is extracted in
such a way to maintain the original directory structure.

•

The root or foundation schema is the REPC_IN000001CA.xsd, which is found
in the Schemas directory. All other schemas are imported when creating an
instance.

•

In order to view the sample message, click CDM Notification Sample
Message.xml. This file is a document so it will be opened in Internet Explorer
if an XML tool is not available. The sample schema illustrates the data with
their respective tags.

All CDM schemas have a single root, which represents the ‘interaction’ being exchanged. Within
the interaction schema are two wrapper schemas. The outer Transmission Wrapper contains the
information required for communications protocols and routing. The inner Trigger Event
Wrapper describes the type of event which caused the message to be sent, including who caused
the event, when and why. This wrapper then contains the ‘payload’ which is the primary message
content.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 51

The interaction schema, wrappers and payloads all reference a core set of schemas which define
the allowed data types and some of the structural vocabulary values. The wrappers and payloads
may also reference sub-models called CMETs. These CMETs may in turn reference other
CMETs. All references are handled via schema include statements.
The diagram on the following page shows the schema structure of the CDM Record Notification
interaction.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 52

REPC_IN000001CA.xsd

Root Interaction
Core Schemas
NarrativeBlock.xsd

CMET
Wrapper

Voc.xsd

Payload

Datatypes.xsd

Datatypes-base.xsd
MCCI_MT000100CA.xsd

MCAI_MT700211CA.xsd

COCT_MT090103CA.xsd

COCT_MT240003CA.xsd

COCT_MT470000CA.xsd

COCT_MT050002CA.xsd

COCT_MT090103CA.xsd

COCT_MT040205.xsd

COCT_MT240003.xsd

COCT_MT260001CA.xsd

POME_MT000003CA.xsd

COCT_MT240003CA.xsd

COCT_MT090103CA.xsd
REPC_MT000001CA.xsd

Figure 14 – CDM Record Notification Schema

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 53

The diagram following provides a visual mapping of the XML schema with the corresponding
HL7 RMIM (Refined Message Information Model).

Figure 15 – XML Schema and HL7 RMIM

4.9. Message Samples
Note to Reader: Message samples have been developed for each of the CDM
interactions and are provided in the following external documents. For additional
details, please reference:
Sample CDM Record Query Request Message
Sample CDM Record Notification Message
Sample CDM Record Query Response Message
Sample Accept Acknowledgement Message
Sample Reject Acknowledgement Message
The diagram following provides a visual mapping of an XML message sample with the
corresponding HL7 RMIM (Refined Message Information Model).

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 54

Figure 16 – XML Message Sample and HL7 RMIM

4.10. Data Types
The data types (e.g., AD – address) referenced in the Implementation Guide have been included
as Appendix D – CDM Data Types.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 55

STANDARD MAINTENANCE
Note to Reader: The process for maintaining the CDM HL7 Message Standard is
currently under review. General guidance only is provided at this point in time.

5.1. Change Management Overview
Changes to the CDM HL7 Message Standards should be aligned with the objectives of the
standard, beneficial to the widest possible audience, and introduced with appropriate consultation
and agreement.
The CDM change request process, once developed, should ensure that:
•
•
•
•
•

Any stakeholder / participant may request a change;
Each change request provides sufficient and appropriate information;
Implementations remain consistent across all jurisdictions;
Each change request is reviewed and given due consideration as to benefits and impact; and
All stakeholders / participants have the opportunity to review and comment on proposed
change requests.

5.2. Change Management Process
Changes to the CDM HL7 Data Standards may be one of:
Some Change Request (CR) examples which affect HL7 artifacts include:
•
•
•
•
•
•
•
•

Changing field conformance (e.g., Required to Mandatory, Required to Not Permitted)
Updating field repetitions
Changing data type for a specific field
Adding a field (attribute) to an existing message (e.g., adding a column in the Master Data
Element spreadsheet in the CDM Data Standards)
New message, application role, trigger events and / or interactions
Updating HL7 vocabulary tables
Updating to CMETs (Common Message Element Types)
Updating message wrappers and other HL7 artifacts (e.g., acknowledgements)

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Page - 56

Some Change Request (CR) examples which do not affect HL7 artifacts include:
•
•
•
•
•

Updating business names and / or business definitions
Updating field lengths
General updates to CDM Data Standards or the CDM HL7 Implementation Guide
Adding new clinical data elements in the Master Data Element spreadsheet in the CDM Data
Standards
Updates to code tables (including where require, submissions to LOINC, ICD-10-CA, etc.)

To submit a change request related to this standard:
•
•

Review existing proposed change requests with the CDM Project Management Office (PMO)
to ensure your change request will not be a duplicate; then, if necessary
Complete a CDM Change Request Form and forward it to the CDM PMO

The CDM Change Request Form (to be developed) will include at a minimum, the following
pieces of information:
•
•
•
•
•
•

Identifier for the change request
Requesting organization
Contact person
Date requested and date required
Change requested
Approval status

The approval process is under development, but may include representatives from the CDM Data
Working Group (DWG), CDM Working Group (WG), CDM Clinical Advisory Group (CAG)
and the CDM Steering Committee (SC).

5.3. Extensibility
In some situations, the CDM standard may need to be extended to meet local needs. Please refer
to Appendix C – Extensibility for a description of extensibility of the CDM standard.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix A-1

Appendix A. Glossary
The following definitions apply to terms used in the CDM HL7 Message Specifications – Implementation
Guide:
Term

Definition

Application

A software program or set of related programs that provide some useful health
care capability or functionality.

Application role

A characteristic of an application that defines a portion of its HL7 interfaces. It is
defined in terms of the interactions (messages) that the role sends or receives in
response to trigger events.

Artifact

Any document, tool or tangible outcome resulting from the discovery, analysis
and design activities leading to the creation of CDM HL7 Message
Specifications.

Attributes

Attributes are abstractions of the data captured about classes. Attributes
capture separate aspects of the class and take their values independent of one
another. Attributes assume data values that are passed in HL7 messages.
Example: ‘Observation method code’ is an attribute of the ‘Observation’ class. In
HL7 message the ‘ObservationEvent.methodcode’ attribute indicates the means
or technique used to perform the test or observation.

Client Registry

A Client Registry is the application where an individual / person's information
(e.g., Name, Date Of Birth, SIN, Health Access #) is securely stored and
maintained.

CMET

See Common Message Element Type.

Common Message
Element Type

A message type in a Hierarchical Message Description (HMD) that may be
included by reference in other HMD's.

Conformance

A valid document that complies with all of the HL7 rules and constraints.

DMIM

See Domain Message Information Model.

Domain
Message
Information Model

A form of Refined Message Information Model (RMIM) constructed to represent
the totality of concepts embodied in the individual RMIMs needed to support the
communication requirements of a particular HL7 domain.

EHR

See Electronic Health Record.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Term

Appendix A-2

Definition

Electronic
Record

Health

An Electronic Health Record (EHR) is a health record of an individual that is
accessible online from many separate, interoperable automated systems within
an electronic network.
An electronic representation of an individual's health record, either in a single
data repository or in separate linked repositories.

HL7

Health Level 7. An ANSI-accredited Standards Developing Organization (SDO)
operating in the health care arena. "Level Seven" refers to the highest level of
the International Standards Organization's (ISO) communications model for
Open Systems Interconnection (OSI) – the application level. The application
level addresses the definition of the data to be exchanged, the timing of the
interchange, and the communication of certain errors to the application. The
seventh level supports such functions as security checks, participant
identification, availability checks, exchange mechanism negotiations and, most
importantly, data exchange structuring.

HL7 Ballot

The formal process by which HL7 material is presented to its members for
review, consideration and feedback, including the ability to post positive and
negative comments.
See also HL7.

HL7
Version

Standard

Indicates the version of the messaging standard being referenced.

HL7 V3 Model

Refers to Version 3.X of the HL7 standard.

HMD

A specification of the exact fields of a message and their grouping, sequence,
optionality, and cardinality. This specification contains message types for one or
more interactions, or that represent one or more common message element
types. This is the primary normative structure for HL7 messages.

Interaction

A single, one-way information flow that supports a communication requirement
expressed in a scenario.

Interaction Diagram

A graphical representation of communications between application roles. An
interaction diagram may also be referred to as a ladder diagram, sequence
diagram, or storyboard diagram.

International
Standards
Organization

International Organization for Standardization. Note that ISO is not an acronym;
instead, the name derives from the Greek word "isos" which means equal.
Founded in 1946, ISO is an international organization composed of national
standards bodies from over 75 countries. For example, ANSI (American National
Standards Institute) is a member of ISO. ISO has defined a number of important
computer standards, the most significant of which is perhaps OSI (Open
Systems Interconnection), a standardized architecture for designing networks.

ISO

See International Standards Organization.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix A-3

Term

Definition

Message

A message is the atomic unit of data transferred between systems. It is
comprised of a group of segments in a defined sequence. Each message has a
message type that defines its purpose. For example, the Admission Discharge
Transfer (ADT) Message type is used to transmit portions of an individual’s
demographic data from one system to another. A three character code contained
within each message identifies its type.

Message
Development
Framework

Message Development Framework. The collection of models, methods, and
tools that comprise the methodology for specifying HL7 Version 3 messages.
This framework is used by the developer of HL7 standards. The HL7 V3 Guide is
a summary of the content of the methodology.

Message instance

A message as formatted for a specific transmission. Two messages may be
described by the same message type and identified with the same interaction
and yet vary in the instance because of differences in values, presence or
absence of the data being sent and different cardinalities of collections.
Otherwise identical messages may be different instances if they are sent at
different times or by a different sender.

Message type

A set of rules for constructing a message given a specific set of instance data.
As such, it also serves as a guide for parsing a message to recover the instance
data.
Each message has a message type that defines its purpose. For example, the
Admission Discharge Transfer (ADT) Message Type is used to transmit portions
of an individual’s ADT data from one system to another. A 3-character code
contained within each message identifies its type.

Patient

Person, in the role of patient for a particular situation. For example, this person is
a patient at the hospital, but this person is not a patient at this time. See also
Person.
One who is suffering from any disease or behavioural disorder and is under
treatment for it.

Reference
Information Model

The HL7 information model from which all other information models (e.g.,
RMIMs) and messages are derived.

Refined
Message
Information Model

An information structure that represents the requirements for a set of messages.
A constrained subset of the Reference Information Model (RIM) which may
contain additional classes that are cloned from RIM classes. Contains those
classes, attributes, associations, and data types that are needed to support one
or more Hierarchical Message Descriptions (HMD). A single message can be
shown as a particular pathway through the classes within an RMIM.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix A-4

Term

Definition

Registry

Directory-like system that focuses solely on managing data pertaining to one
conceptual entity. The primary purpose of a registry is to respond to searches
using one or more pre-defined parameters in order to find and retrieve a unique
occurrence of an entity. Examples of registries include: Client Registry, Provider
Registry, Location Registry, and Consent Registry.

Repository

1: A collection of information. 2: An implementation of a collection of information
along with data access and control mechanisms, such as search, indexing,
storage, retrieval and security.

RIM

See Reference Information Model.

RMIM

See Refined Message Information Model.

Role

1) A function or position. 2) A Reference Information Model class that defines the
competency of an Entity class. Each role is played by one Entity (the Entity that
is in the role) and is usually scoped by another. 3) In UML, each end of an
association is designated as a role to reflect the function that class plays in the
association.

Storyboard

A narrative of relevant events defined using interaction diagrams or use cases.
The storyboard provides one set of interactions that the modeling committee
expects will typically occur in the domain.
A short story used to define the business requirements and to illustrate specific
interactions related to a computer message.

System

1) An end user application. 2) In HL7, a group of messages that work together.

Transport Wrapper

A wrapper that contains information needed by a sending application or
message handling service to route the message payload to the designated
receiver. All HL7 V3 messages must have an appropriately configured transport
wrapper.

Trigger event

An event which, when recorded or recognized by an application, indicates the
need for an information flow to one or more other applications, resulting in one or
more interactions.

Trigger Event
Wrapper

A wrapper that contains domain specific administrative information related to the
"controlled event" which is being communicated as a messaging interaction. The
trigger event wrapper is used only in messages that convey status, or in
commands for logical operations being coordinated between applications (e.g.,
the coordination of query specification / query response interactions).

Vocabulary

The sum or the stock of words used by a language, a group, or an individual.

Vocabulary domain

The set of all concepts that can be taken as valid values in an instance of a
coded attribute or field; a constraint applicable to code values.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix A-5

Term

Definition

Wrapper

The control or envelope information in which the message content or payload
resides. See also, transport wrapper and trigger event wrapper.

XML

Extensible Mark-up Language.
XML is a mark-up language for structuring arbitrary data based on element tags
and attributes.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix B-1

Appendix B. HL7 Methodology Background
B.1

Specification Component Introductions
Each artifact entered within the HL7 specification has the following basic components:
1. Title Name: Human readable name for the artifact.
2. Code 6 : Unique code that is used to identify the artifact over time.
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)

Format is:

For example: REPC_RM000001CA01 is version 01 of the Health and
Clinical Management Section, Patient Care Domain, Refined Message
Information Model (RMIM) 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 CDM artifact codes
during the standards development and approval process.
The code will appear after the title name when the specification is
rendered.
3. 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.

Descriptions of each of the code components can be determined in the HL7 v3 Guide at the following URL:
http://www.hl7.org/v3ballot/html/help/v3guide/v3guide.htm#v3msg

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix B-2

HL7 v3 Artifacts
AR

Application Role

Trigger Event

RIM
Reference Information
Model
Instantiate

DMIM

Sender

Receiver

Domain Message
Information Model

Storyboard

Triggers

References

Restrict

RMIM

IN
Interaction

Example

Refined Message
Information Model
Restrict

HMD
Hierarchical Message
Definition

SN
Storyboard Narrative

Restrict

Content

B.2

MT
Message Type

Specification Components

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

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

•

B.2.2

Appendix B-3

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.

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.

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

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

B.2.4

Appendix B-4

Static Information Models

B-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 (DMIM) 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 DMIMs for
these two domains, then, will be quite different, although both will be derived from the RIM.
The Refined Message Information Models (RMIMs) are used to express the information
content for a group of messages and is a subset of the DMIM 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 a
tabular representation of the sequence of elements (i.e., classes, attributes and associations)
contained in an RMIM 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.
B-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 DMIMs and RMIMs 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
DMIMs and RMIMs.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

B-2.4.3

Appendix B-5

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

When should the message be sent (Trigger Event)?

−

What are the responsibilities of the receiving application (Receiver Responsibilities)?

−

What message payload should be sent (Message Type)?

−

What wrappers should be applied to the message (Transportation & Control Act
wrappers)?

−

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.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix C-1

Appendix C. Extensibility
This section provides a quick overview of the extensibility options available when using HL7
version 3, and provides some guidance to the CDM project on how it should approach differing
needs of jurisdictions.

C.1

HL7 V3 Approach
The HL7 Version 3 development process is predicated on the concept of “constraint”. All HL7
version 3 artifacts are based on a single model – the HL7 version 3 Reference Information Model
(RIM). From this model, committees create constrained Domain Message Information Models
(DMIMs) that limit the expressive power of the RIM to only cover the information topics of
interest in their domain. The committees then go through a series of additional processes to
create further constrained models representing particular focal classes (e.g., CDM Record),
particular state transitions (e.g., Create CDM Record) on a given focal class, and finally to
represent the messaging requirements of a single state transition on a focal class in a particular
operating environment (e.g., Create CDM Record in a Canadian primary care setting).
To be considered an HL7 version 3 specification, whether balloted or not, a message must draw
all of its content from a single version of the HL7 RIM. If the message contains any additional
associations or attributes, it cannot use the term “HL7 version 3”.
The mechanism of HL7 operation is therefore to try to be as comprehensive in gathering and
representing potential requirements in their model as possible, and then to constrain out the
requirements which are not needed by or used within a particular type of message. This is a
significant difference from practices found elsewhere of defining a “minimum subset” around
which others create extensions.
The basis of the restriction approach is that it ensures compatibility in the exchange of
information. If all data that can possibly be exchanged is defined in the high-level models of the
standard, then there is no possibility that two implementers might come up with divergent
extensions for performing the same task.
This approach challenges HL7 in that it requires them to have a thorough understanding of the
area of interest when creating their data models to ensure that those models contain all of the
constructs which could reasonably be required in a wide variety of operating environments. The
positive side of this approach is that it minimizes changes in future versions of the standard, and
ensures that the domain is thoroughly understood and modeled accurately the first time. The
negative side suggests that the HL7 approach requires implementers to include new requirements
at the highest level possible in the suite of models (e.g., RIM, DIM, etc.).

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

C.2

Appendix C-2

HL7 V3 Extensibility rules
In recognizing the difficulties involved in creating standards with international applicability, HL7
has published and balloted a document called “Refinement, Constraint & Localization” 7 . This
document outlines the rules about what constitutes a constraint and what constitutes an extension.
It also identifies two mechanisms for the use of “extensions” within HL7 Version 3:
•
•

C.2.1

Affiliate-specific artifacts; and
Localized extensions.

Affiliate-Specific Artifacts
In some cases, frequently due to legislative or cultural differences, international affiliates (e.g.,
HL7 Canada) may have local requirements which are specific to their affiliate or jurisdiction.
Rather than complicating the standard by accommodating such needs, HL7 may recommend to
affiliates that they develop a “realm-specific” version of the artifact. The realm-specific version
may include restrictions on the international version. However, affiliates are given special
dispensation to also add extensions, provided that such extensions are:
•
•

Derived from the RIM; and
Previously proposed to HL7 and rejected as specific to the realm.

Note that only HL7 affiliates can create and ballot such artifacts. If any other agency does so,
they may not be called HL7 standards.

C.2.2

Localized Extensions
HL7 recognizes that from time-to-time, HL7 members and others will need to develop messages
that are not a proper constraint of an existing HL7 version 3 specification. HL7 provides a
mechanism for adding additional data into a CDM HL7 Message Specifications beyond that
allowed by the defined specification. This mechanism is called “Local Extension”.
Any system which relies on the use of local extensions is automatically considered non-compliant
with HL7. The objective of HL7 in defining “local extensions” is merely to ensure maximum
compatibility between applications by ensuring that local extensions do not interfere with the
interoperability of HL7 messages.
To ensure maximum interoperability between applications, including those using local
extensions, HL7 requires that any attributes or associations which are “local extensions” be sent

This document is part of the formal HL7 v3 Standard at:
http://www.hl7.org/v3ballot/html/infrastructure/conformance/conformance.htm

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix C-3

in a distinct XML namespace from the HL7 namespace. HL7 further requires that applications
strip out the contents of all namespaces which they do not recognize before performing message
validation or processing. The result is that conformant HL7 applications can simply strip out all
local extensions before processing the message.
Local extensions must follow two rules:
•
•

C.3

They must be derived from the RIM; and
They must not affect the interpretation of any data already sent within the standard. 8

Other Extensibility Mechanisms
In addition to the explicit mechanisms for introducing extensions, HL7 provides a number of
other mechanisms for localization.

C.3.1

Templates and Profiles
In some cases, the HL7 messaging standard is quite broad and will support a significant range of
content. Implementers generally need to constrain the standard to reflect their needs within a
particular environment. To document how they intend to use the standard or how the standard
should be used in their particular environment, the implementers create a “template” or
“implementation profile”.
Templates are a set of constraints that apply to all or part of a model and may be applied to
multiple standards. Profiles apply to the complete set of models that make up a single interaction.
In either case, compliant templates and profiles will only constrain, not extend. They are not
balloted and may be written by anyone.
While templates must be constraints on the standard, new versions of a given template can easily
loosen constraints imposed by a previous template, so long as it is still a proper constraint on the
standard. In this way, the new version of the template will appear to extend the old version.

C.3.2

Embedded Data
Parts of some HL7 V3 messaging standards may include the ED (encapsulated data) datatype.
This datatype allows “encapsulated data” to be sent as part of the message. Examples include
text, images, sound-files, movies and documents. ED-typed attributes can also contain XML

For example, allowing an address to be sent where it had not previously been permitted would not change the meaning of the
standard. Adding a negationInd attribute, which allows the declaration of an act to be identified, as “this act did not occur”
could definitely change the meaning of other attributes within an instance, and would therefore be prohibited.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix C-4

data, including CDA documents. The contents of these attributes are generally unrestricted or
only loosely restricted by the messaging standard.
An implementer can effectively extend a messaging specification to contain additional data by
embedding that data within the content of an ED attribute.
The major drawback of such an approach is that a second level of parsing is required to access the
information. It will not be checked or validated when processing the message.

C.3.3

Stubs
In some cases, committees wish to create a generic construct which will contain content that the
committee does not wish to define. For example, the financial committee might wish to define a
claims message, but not define all the types of acts for which claims might be made. The finance
committee knows where the act for which the claim is being made should fit in their model, and
may even determine a minimum subset of information that must be present. However, they want
other committees to define the actual types of acts that can be billed for. For example, one
committee might define Lab content, while another committee would define DI content.
To support this, HL7 allows the concept of “Stubs”. Stubs allow a committee to say “Something
that generally looks like X should go here”, but leave the definition of all the possible variants of
X up to other standards developers.

C.4

CDM’s Position
The CDM HL7 Message Specifications were developed as a generic, flexible framework which
was capable of conveying the data for a variety of different chronic diseases. The specification
allows the capture of various observation results, diagnostic image information, medications,
procedures, referrals, as well as plans and goals. The specific types of results, medications and
other information that should be captured vary from chronic disease to chronic disease and are
specified by means of a template-based spreadsheet.
The CDM message also makes use of an ED datatype to capture “Care Plan” information (the
Care Plan Attachment) enabling the use of HTML, PDF and text documents, as well as HL7 CDA
(Clinical Document Architecture) structured documents.
As yet, the CDM HL7 Message Specifications have not been submitted to any HL7 committee or
affiliate for ballot. Therefore it has no standing as an HL7 standard. It can, however, be called an
HL7 version 3 artifact because it is strictly derived from the RIM. In all likelihood the
specification will likely be submitted to the Patient Care Committee for balloting as a Draft
Standard for Trial Use.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix C-5

In general, the CDM HL7 Message Specifications have attempted to be fairly encompassing of all
possible requirements of the WHIC jurisdictions related to chronic disease management. In some
cases, data elements have been marked as “optional” from a conformance point of view to allow
their use in some jurisdictions but not others. The expectation is that jurisdictions will develop
their own constraint profiles identifying which optional components must be supported within
their jurisdiction. In some cases, jurisdictions may choose to place additional constraints, though
variation in the constraints between jurisdictions will reduce inter-jurisdictional interoperability,
and will increase costs for cross-jurisdiction implementers.

C.5

Extension Recommendations
Due to the generic construction of the CDM HL7 Message Specifications, the likelihood of
significant or frequent extensions being required by any of the jurisdictions is minor. The bulk of
the extensions will come by adding additional clinical data elements (e.g., allowing the capture of
additional types of observations, lab-tests, drugs, etc.). This type of change will not affect the
underlying CDM HL7 Message Specifications or the balloting process.
The most uncertain area in the CDM HL7 Message Specifications relates to the topic of care
plans. The bulk of the detail regarding a care plan is sent using the “Care Plan Attachment”
attribute as an external document. As such, it is easy for jurisdictions to evolve and expand the
content transmitted for care plans independent of the messaging specification.
Should it become necessary for a jurisdiction to actually extend the messaging standard by adding
new attributes or associations, they will need to acquire or possess some HL7 version 3 modeling
advice to ensure that any changes they make continue to be proper subsets of the RIM. The
jurisdiction will then need to select the appropriate course of action from the list below:
•
•
•

Jointly resubmit the extended specification to HL7 (international) Patient Care Technical
Committee for inclusion in a future version of the standard;
Submit the revised specification to HL7 Canada for balloting as a realm-specific extension; or
Place the added attributes and associations into a unique XML namespace.

The first two options are simpler for implementers because there is no need to worry about
namespaces. They also have no limitations on the sorts of changes which can be made. Finally,
they have the benefit of ensuring that the CDM HL7 Message Specifications remains an “HL7
Standard”. However, both of these options may require significant lead-times. 9

Submitting to HL7 (international) can take up to 2 years, depending on where the HL7 committee is in their balloting cycle.
Realm specific timelines may be between 6 months and 1 year, again depending on timing with HL7 Canada ballot cycles.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix C-6

To avoid being faced with any of these prospects, jurisdictions should be encouraged to
thoroughly review the CDM HL7 Messaging Specifications and ensure that it meets their
perceived requirements for the next 3-5 years.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix D-1

Appendix D. CDM Data Types
In HL7 version 3, the attributes of all classes are defined using a set of datatypes specific to the
HL7 V3 standard. These datatypes are defined and balloted as part of the HL7 standard. The
documentation on the available datatypes, their properties and their relationships can be found at:
http://www.hl7.org/v3ballot/html/infrastructure/datatypes/datatypes.htm. The documentation of
how the datatypes are expressed using XML syntax can be found at:
http://www.hl7.org/v3ballot/html/infrastructure/itsxml/datatypes-its-xml.htm.
The WHIC Chronic Disease Management specification makes use of a subset of the available
HL7 datatypes. In many cases, the specification also constrains the datatypes by limiting what
properties can be used, restricting the vocabulary, specifying maximum lengths, etc.
This document provides a listing of the datatypes used by CDM, and also indicates the constraints
which have been applied. However, readers are encouraged to reference the underlying HL7
specifications for a more complete explanation of the datatypes and their properties.

D.1
D.1.1

General notes
Null Flavor
All HL7 datatypes intrinsically support a “nullFlavor” property. If the attribute is not marked as
“mandatory” in the CDM specification, a nullFlavor may be specified instead of populating any
of the other properties. “nullFlavor” will only appear if the remaining properties are left
unspecified. The null flavors supported for this specification are:
Code

Display-name

No information (default)

MSK

Masked

Not Applicable

OTH

Other

UNK

Unknown

ASKU

Asked but unknown

NAV

Temporarily unavailable

NASK

Not asked

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

D.1.2

Appendix D-2

SETs
When a field can repeat, the datatype is shown as a SET where x is the datatype of the items
within the set. “SET” adds no additional properties. It merely indicates that multiple repetitions
are allowed, and that the repetitions must be unique (i.e., no duplicates are allowed).

D.1.3

LISTs
Lists are similar to sets. There are two distinctions:
•
•

D.1.4

Lists allow duplicates, while sets do not.
In lists, the order of the items matters and must be retained. In Sets, order is irrelevant. The
meaning of the order of a list is conveyed in the definition of the attribute.

Validation
Many of the restrictions on HL7 V3 datatypes are enforced by HL7 schemas. However, there are
some constraints which are not enforced. Many of the CDM constraints will also not be enforced.
Applications claiming conformance with the WHIC CDM specification will be expected to
comply with the constraints listed here.

D.2

Codes and identifiers

D.2.1

II – Instance Identifier
This datatype is used for all identifiers, including lab result identifiers, plan identifiers,
prescription identifiers and dispense record identifiers. It uses an OID with an alpha-numeric
extension to convey globally unique identifiers.

EXAMPLE

root
This component is constrained to be an ISO OID (a registered hierarchical identifier consisting of
a sequence of integers separated by periods) or a UUID (a 32-character hex identifier). This
component forms the namespace for the issued identifiers. For example, there would be a single
ISO OID which represents Alberta-issued Prescription order numbers. A different ISO OID
would represent B.C.-issued provincial health identifiers. This component is mandatory (cannot
be null) and has an upper limit of 100 characters.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix D-3

extension
This component contains the specific identifier. For example, the PHN, the prescription number,
etc. The component is mandatory and has a maximum length of 20 characters.

D.2.2

CS – Coded Simple
This datatype is used for a number of internal HL7 attributes which help to define the message
structure. These are generally constrained to a fixed value within the specification and are not
displayed to users. The “displayName” property is prohibited for use in the CDM specification.

EXAMPLE

< . . . classCode= “OBS” . . . />

code
This is the value of the code being conveyed. No code system is specified because the only
permitted code-system is HL7-defined. Local codes are prohibited. The length limit of this
mandatory component is 20 characters.

D.2.3

CV – Coded Value
This datatype is used to convey most CDM coded values, such as type of observation, type of
procedure, person gender, etc. The behavior of this datatype differs slightly depending on
whether the attribute using the CV datatype was marked as CNE (coded with no extensibility) or
CWE (coded with extensibility).
The properties “codeSystemName”, “codeSystemVersion” and “displayName” merely provide
redundant information and are prohibited for use in the CDM specification.

EXAMPLE

code=“F”

codeSystem=“2.16.840.1.113883.5.1”

code
This is the value of the code being conveyed. For example, for gender it might be “F”. For a
LOINC code, it might be “10157-6”.
The component is mandatory for “CNE” attributes and required for “CWE” attributes. It has a
maximum length of 20 characters. However, implementers are free to restrict the length stored
based on the maximum length limit of the code-system in use. For example, when storing
LOINC codes, only 7 characters are required.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix D-4

codeSystem
This is the OID assigned to the code system when it was registered with HL7. The OIDs of the
code-systems used for the CDM specification will be included as part of the implementation
guide.
This component is mandatory if “code” is specified, and is not permitted otherwise.
maximum length of this component is 100 characters.

The

originalText
For CNE attributes, originalText is only specified if the “code” property is present. It indicates
the text which was seen by the user in selecting the code. For example, if the code were “F”, the
originalText might be “Female” (the display name for the code).
For CWE attributes, originalText has the same characteristic if “code” is present. However,
originalText may also be included if “code” is not present (i.e., no appropriate code was
available). In this case, “originalText” represents what was actually typed by the user in place of
selecting an appropriate code.
The component is Required (must be supported but may be null) and has a maximum length of
150 characters

D.3

Text

D.3.1

ST – String
This is a standard string. For the purposes of this specification, the character-set will be fixed as
128-bit ASCII. The “language” property will not be specified and will default to “en” (English).
The allowed length for this datatype varies and is specified for each attribute in which it is used.
If ST is used in place of an “ANY” datatype and no length is specified, the maximum length will
be 255 characters.

EXAMPLE

D.3.2

Royal Alexandra Hospital

ED.DOC – Encapsulated Data (Document)
This allows for the encapsulation of a document within the CDM HL7 instance. In CDM, this
datatype is used to attach care-plan documents to the message.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix D-5

The properties “charset”, “integrityCheck”, “reference” and “thumbnail” are not supported for
this restriction on the ED datatype.
EXAMPLE

. . .

compression
This coded component is not mandatory. If specified, this indicates the mechanism used to
compress the attached document. Only one compression mechanism is supported – GZ (gzip).
language
This coded component is not mandatory. If specified, it indicates the language in which the
document is written. This will generally be “en” (English).
mediaType
This mandatory coded component indicates the type of attachment. For the ED.DOC restriction
on the ED datatype, there are only four permitted values: “text / plain” (for plain-text documents),
“text / html” (for HTML documents), “text / xml” (for embedded HL7 CDA documents) and
application / pdf (for PDF documents).
Code

Display-name

text / plain

Plain text

text / html

HTML

text / xml

XML (for CDA documents)

application / pdf

PDF

This component represents the content of the document. If the content is compressed (the
compression attribute is populated), or if the content is a PDF document
(mediaType=“application/pdf”, then the content will be MIME-encoded. Otherwise, the content
will be sent as directly embedded text or XML. (NOTE: This means that uncompressed HTML
must be XHTML compliant.) Content (compressed or uncompressed) is restricted to a maximum
of 1 megabyte.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

D.3.3

Appendix D-6

ED.DOCORREF – Encapsulated Data (Document or Reference)
This is identical to ED.DOC, except that the “reference” property is supported. Either the
“reference” or “” must be specified, but not both. It is used when reporting clinical
issues with a particular submission. The likelihood of its use for CDM is low, but it is included
for alignment with other national specifications such as NeCST, Registries and CeRx.

reference
This component is a URI specifying the location where a monograph describing the detected
issue can be retrieved. Recommended formats include HTTP, HTTPS and FTP. Maximum
length of this component is 150 characters.

D.3.4

ED.SIGNATURE – Encapsulated Data (Electronic Signature)
This allows for conveying an electronic signature of the ‘semantic content’ of the message,
including the trigger event wrapper and the query definition and / or payload. The specific
formats to be used for signing the content, as well as the serialization and normalization
algorithms are not defined here. They must be negotiated between trading partners.
The properties “charset”, “compression”, “language”, “integrityCheck”, “reference” and
“thumbnail” are not supported for this restriction on the ED datatype. Lengths of the supported
properties are dependent on the trading-partner negotiated signature mechanism.

EXAMPLE

. . .

mediaType
This mandatory coded component indicates the type of attachment. This should be set to the
appropriate mime type for the type of signature being conveyed.

This component contains the actual signature of the message in whatever encoding has been
selected by the partners.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

D.4

Appendix D-7

Timing

D.4.1

TS.DATE – Timestamp (Date, partial allowed)
This constraint on the timestamp datatype only permits the “date” portion of the timestamp to be
specified. It also allows for partial dates to be transmitted. The grammar for the datatype is:
YYYY[MM[DD]] (4-8 characters).
Dates (or portions) specified must be valid dates (i.e., month must be 01 to 12, February 29 is
only permitted for leap-years, etc.).

EXAMPLE

D.4.2

TS.DATETIME – Timestamp (Date and time, partial allowed)
This constraint on the timestamp datatype permits both “date” and “date and time” portion of the
timestamp to be specified. It also allows for both the date and time portions to be transmitted as
partial values. The grammar for the datatype is: YYYY[MM[DD[hh[mm[ss]]]]] (4-14
characters).
Dates and times (or portions) specified must be valid dates (i.e., month must be 01 to 12,
February 29 is only permitted for leap-years, hour must be between 0 and 23, etc.).
“10pm on Aug. 15, 2005” would be specified as:

EXAMPLE

D.4.3

TS.FULLDATE – Timestamp (fully-specified date only)
This constraint on the timestamp datatype only permits the “date” portion of the timestamp to be
specified. It does not allow for partial dates to be transmitted. The grammar for the datatype is:
YYYYMMDD (8 characters).
Dates specified must be valid dates. (e.g., month must be 01 to 12; February 29 is only permitted
for leap-years, etc.)

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix D-8

“August 3, 2005” would be specified as:
EXAMPLE

D.4.4

TS.FULLDATETIME – Timestamp (fully-specified date & time)
This constraint on the timestamp datatype requires a complete date and time to be present down
to the second. It does not allow partial date or times to be transmitted. The grammar for the
datatype is: YYYYMMDDhhmmss (14 characters).
Dates and times specified must be valid dates. (e.g., month must be 01 to 12, February 29 is only
permitted for leap-years, hour must be 00 to 23, etc.)
“11:59:02 pm, August 3, 2005” would be specified as:

EXAMPLE

D.4.5

IVL
This datatype is used when both a start and end date may exist, and either or both may be
captured. Any two of the four properties “low”, “high”, “center” and “width” may be specified.
“Began March 01, 2000, ended July 31, 2000” would be specified as:

EXAMPLE

“Began April 1, 2004 and continued for 4 months” would be specified as:

EXAMPLE

low
This indicates the start date for the time-period.
(YYYYMMDD).

It must be specified as a full date

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix D-9

high
This indicates the end date for the time-period.
(YYYYMMDD).

It must be specified as a full date

This indicates the middle date of the time-period.
(YYYYMMDD).

It must be specified as a full date

center

width
This indicates the total duration of the time-period. It is sent as a physical quantity (PQ) where
the units are restricted to time. The allowed unit codes are:

D.4.6

Code

Display-name

Days

Weeks

Months

Years

IVL.LOW
This datatype is used when both a start and end date may exist, but only the start date should be
captured. The interval datatype is used, but only the “low” (start) property is populated. The
other properties (“high”, “width”, “center”, “low-closed” and “high-closed”) are not permitted.
The value of the high property can be sent as a fully-specified or partial date. The grammar is
YYYY[MM[DD]].
“Began July, 2005” would be specified as:

EXAMPLE

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

D.4.7

Appendix D-10

IVL.LOW – Start Date
This datatype is used when both a start and end date may exist, but only the start date should be
captured. The interval datatype is used, but only the “low” (start) property is populated. The
other properties (“high”, “width”, “center”, “low-closed” and “high-closed”) are not permitted.
The value of the high property must be sent as a fully-specified date (i.e., partial dates are not
allowed).
“Began July 6, 2005” would be specified as:

EXAMPLE

D.4.8

IVL.HIGH – End Date
This datatype is used when both a start and end date may exist, but only the end date should be
captured. The interval datatype is used, but only the “high” (end) property is populated. The
other properties (“low”, “width”, “center”, “low-closed” and “high-closed”) are not permitted.
The value of the high property is sent as a fully-specified date (i.e., partial dates are not allowed).
“Ended August 3, 2005” would be specified as:

EXAMPLE

D.4.9

IVL.WIDTH
This datatype is used when all that is of interest is the duration of a time-period, not when it
started or ended. The interval datatype is used, but only the “width” (duration) property is
populated. The other properties (“low”, “high”, “center”, “low-closed” and “high-closed”) are
not permitted.
“3 weeks” would be specified as:

EXAMPLE

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix D-11

The value of the width property is PQ with units restricted as follows:
Code

Display-name

Days

Weeks

Months

Years

D.4.10 URG – Uncertain Date in Range
This datatype is used when a date with a level of uncertainty needs to be conveyed. It can specify
an upper boundary and a lower boundary (e.g., Between March 2000 and July 2000; Between
1990 and 1995) between which the date is believed to fall.
“Between March 01, 2000 and July 31, 2000” would be specified as:
EXAMPLE

“April 1, 2004 +/- 2 months” would be specified as:

EXAMPLE

low
This indicates the lower boundary-date for the uncertain date. It must be specified as a full date
(YYYYMMDD).
high
This indicates the upper boundary-date for the uncertain date. It must be specified as a full date
(YYYYMMDD).

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix D-12

center
This indicates the middle of the range for the uncertain date. It must be specified as a full date
(YYYYMMDD).
width
This indicates the total size of the uncertainty. It is sent as a physical quantity (PQ) where the
units are restricted to time. The allowed unit codes are:
Code

Display-name

Days

Weeks

Months

Years

D.4.11 IVL> – Range of Uncertain Dates
This datatype is used when representing a period of dates where the beginning and end of the
period are uncertain. This is a complex structure where both the upper and lower bounds are
conveyed as uncertain intervals.
Either or both the start and end can specify an upper boundary and a lower boundary (e.g.,
Between March 2000 and July 2000; between 1990 and 1995).
“Started in the 1970s, ended in October, 2003” would be specified as:

EXAMPLE

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix D-13

low
This indicates the lower boundary-date for the date-range. The allowed content can be seen in the
description of URG.
high
This indicates the upper boundary-date for the date-range. The allowed content can be seen in the
description of URG.

D.4.12 PIVL – Periodic Interval
This datatype is used to capture the frequency with which an action occurred or should occur.
The “phase”, “period”, “alignment” and “institutionSpecified” properties are not permitted.
“3 times / day” would be specified as:

EXAMPLE

frequency
This mandatory property indicates how often the event occurred. The numerator property
identifies the number of repetitions which occurred or which are to occur. The denominator
indicates the period of time for the repetitions. The units for the denominator are:
Code

Display-name

Milliseconds

Seconds

min

Minutes

Hours

Days

Weeks

Months

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Code

Display-name

Years

Appendix D-14

D.4.13 GTS.BOUNDEDPIVL – General Timing Specification (Bounded periodic
interval)
This datatype is used to convey two pieces of information: the overall time-period when
something occurred (or is to occur), as well as how often it should / did occur within that timeperiod. This is accomplished by sending two repetitions of the attribute. The first repetition has a
type of IVL and specifies an operator of “I” (Include). The second repetition
has a type of PIVL.
“3 times / day beginning August 3rd for 3 weeks” would be specified as:

EXAMPLE

D.5

Measurement

D.5.1

INT.POS – Integer (Positive)
Used to communicate positive integers (e.g., greater than zero). Maximum length is 10 digits

EXAMPLE

D.5.2

INT.NONNEG – Integer (Non-negative)
Used to communicate non-negative integers (e.g. greater than or equal to zero). Maximum length
is 10 digits.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

EXAMPLE

D.5.3

Appendix D-15

PQ – Physical Quantity
Used to communicate measurements.

EXAMPLE

value
This mandatory property indicates the numeric amount of the measurement. The format of the
amount is 99999999.99 with no leading or trailing zeros.
unit
Indicates how the amount was measured. This coded property must be specified unless the units
of measurement are “eaches”. For example, “packages”, “packs”, “capsules”, “tablets”, etc. are
not sent in the units field. These concepts should be explicit in the code identifying the type of
item being measured. For example, if the drug name is “100mg Acetaminophen tablets”, the
quantity would be “1” (or “2” or whatever) with no units specified. The unit would be inferred
from the drug name as “tablets”.
The codes may be any combination of the atomic units specified in the HL7 “table of units and
measure – case sensitive”. The following list shows the subset of those codes which are expected
to be used for CDM. The appropriate units for a given observation can be found in the CDM
implementation guide.
Code

Display-name

Percent (0.0 to 100.0)

Kilograms

[lb_av]

Pound (imperial)

Meters

Centimeters

[ft_br]

Foot (imperial)

[in_br]

Inch (imperial)

g/l

Grams per litre

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

D.5.4

Appendix D-16

Code

Display-name

pg/ml

Picograms per millilitre

mmol/l

Millimoles per Litre

umol/l

Micro-moles per Litre

mmHg

Millimeters of mercury (pressure)

1/d

Per day

1/min

Per minute

g/d

Grams per day

mg/d

Milligrams per day

ug/min

Micrograms per minute

ml/s

Millilitres per second

u/l

Enzyme Units (micromoles / minute) per Litre

PQ.MASSVOL – physical quantity (Mass or Volume)
This is a restriction on physical quantity where units are restricted to the following:
Code

Display-name

Percent (0.0 to 100.0)

Nano-litres

Milli-litres

Deca-litres

Litres

[drp]

Drops

[foz_us]

Fluid ounces (U.S.)

[tbs_us]

Tablespoon (U.S.)

[tsp_us]

Teaspoon (U.S.)

Nanograms

Milligrams

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

D.5.5

Code

Display-name

Decagrams

Grams

Kilograms

[lb_av]

Pounds (U.S.)

[oz_av]

Ounces (U.S.)

Appendix D-17

IVL
This is used to express an allowed range of quantities. The properties lowClosed, highClosed,
center and width are not supported.
“500 milligrams to 2.34 grams” would be specified as:

EXAMPLE

D.5.6

URG
This is used when the physical quantity isn’t certain or is allowed to vary. The properties
lowClosed, highClosed, center and width are not supported.
“Somewhere between 4 and 10 mg” would be specified as:

EXAMPLE

D.6
D.6.1

Demographic
PN.BASIC
Used to communicate person names for communication purposes.
sophisticated enough for registry-type purposes.

This datatype is not

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix D-18

The name parts are limited to given, family, prefix and suffix. The “use” attribute (which applies
to the entire name) and “qualifier” attribute (which applies to each name part) are restricted to the
following values:
Name use:
Code

Display-name

Legal

Pseudonym

Name qualifier:
Code

Display-name

Initial

The maximum number of name parts is limited to 7. Each name part is limited to a maximum of
30 characters. The validTime attribute is not permitted.
Legal name “Mr. John W. Smith” would be specified as:
EXAMPLE

Mr.
John
qualifier=“IN”>W. Smith

Mr. John W. Smith

Systems are expected to be able to support names entered or transmitted in either format, though
discrete name parts should be captured whenever feasible.

D.6.2

AD.BASIC
Used to communicate addresses for contact purposes. This datatype is not sophisticated enough
for address-registry-type purposes.
The address parts are restricted to city, state (province), zip code (postal code) and country. All
other address lines will be specified as free-text with each line demarked by a delimiter address
part. A maximum of four delimited address lines may be specified in addition to the other
address parts.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix D-19

For country and state address parts, coded values may also be specified, restricted to ISO 3166-1
2-character alpha codes and ISO 3166-2 code suffixes respectively. (For example, Canada would
be “CA” and British Columbia would be “BC”. These are the same codes used by Canada Post.)
The complete listing of codes may be found here: http://en.wikipedia.org/wiki/ISO_3166-1.
A maximum of three address use codes may be specified from the following list:
Code

Display-name

PHYS

Visit address

PST

Postal address

TMP

Temporary address

Home

Work place

The length of each address part or content between address parts is restricted to 80 characters,
including each address line demarked by a delimiter. The usablePeriod attribute is not permitted.
Workplace postal address for “Some Company, at apartment A5, 123 Some Street
NW. in Edmonton, Alberta, Canada with the postal code A1B 2C3” would be
specified as:
EXAMPLE

D.6.3

Some CompanyApt A5, 123 Some Street
N.W.Edmonton,
Alberta
A1B
2C3Canada

TEL.PHONEMAIL
This restriction on the TEL datatype only permits telephone and fax numbers as well as e-mail
addresses to be communicated. The telecommunication use code may repeat up to three times
and is restricted to the following list:
Code

Display-name

Home

Work place

Emergency contact

Pager (not for use with e-mail)

Mobile Contact

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Code

Display-name

TMP

Temporary

Appendix D-20

The telecommunication schemes permitted are:
Code

Display-name

tel

Telephone

fax

Work Fax

mailto

E-mail

For telephone and fax numbers, the format is described by http://www.ietf.org/rfc/rfc2806.txt.
The maximum length is 25 characters for phone and fax numbers and 50 characters for e-mail
addresses. The usablePeriod property is not permitted.
A workplace email would specified as:
EXAMPLE

D.6.4

TEL.URI
This restriction allows any legal URI, including http, https, ftp, email, etc. “Custom” network
addresses can also be expressed in URI format. (Rules for constructing URIs can be found at
[http://www.ietf.org/rfc/rfc2396.txt). The only property permitted is URL. “useCode” and
“usablePeriod” are not permitted.

EXAMPLE

D.7

Other datatypes

D.7.1

BL
Used to communicate a value that may be true or false. Like all other datatypes, nullFlavor is
also supported.

EXAMPLE

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

D.7.2

Appendix D-21

ANY
Where this datatype is referenced it means that any of the above datatypes may be used. The
appropriate datatype will be specified in the data elements spreadsheet based on the type of
observation being made. The “any” datatype is never sent, rather a more specific datatype is sent,
with the datatype identified using xsi:type.

iax

FINAL
Printed on 02/28/2006 9:52 AM

CDM HL7 Message Specifications – Implementation Guide

Appendix E-1

Appendix E. CDM Object Identifiers
Note to Reader: Once identified and registered, the CDM Object Identifiers
will be included formally in this guide for quick reference.

iax

FINAL
Printed on 02/28/2006 9:52 AM

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.4
Linearized                      : Yes
Tagged PDF                      : Yes
XMP Toolkit                     : 3.1-701
Producer                        : Acrobat Distiller 7.0 (Windows)
Tag Email Subject               : Imp Guide
Property Flag                   : on
Tag Author Email Display Name   : Carolyn Scheidt
Tag Author Email                : carolyn@aardtech.net
Tag Ad Hoc Review Cycle ID      : -2053854974
Source Modified                 : D:20060228165151
Category                        : Deliverable
Creator Tool                    : Acrobat PDFMaker 7.0 for Word
Modify Date                     : 2006:02:28 09:57:53-07:00
Create Date                     : 2006:02:28 09:52:59-07:00
Metadata Date                   : 2006:02:28 09:57:53-07:00
Document ID                     : uuid:fd552f0e-00c9-4701-bd13-3da9cff353fd
Instance ID                     : uuid:ef2e4934-20d5-4f5a-b9ac-71e4115d7f0b
Version ID                      : 5
Format                          : application/pdf
Title                           : Western Health Information Collaborative (WHIC)
Creator                         : WHIC PMO
Subject                         : 
Headline                        : 
Page Count                      : 104
Page Layout                     : OneColumn
Author                          : WHIC PMO

EXIF Metadata provided by EXIF.tools

Western Health Information Collaborative (WHIC) CDM HL7 Message Specifications Implementation Guide

Navigation menu

Versions of this User Manual:

Views

Navigation