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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta FINAL Printed on 02/28/2006 9:52 AM CDM HL7 Message Specifications – Implementation Guide 1. 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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. • Copyright World Health Organization (WHO), 2005. All Rights Reserved. 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 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 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 © 2005 Government of Alberta 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 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta FINAL Printed on 02/28/2006 9:52 AM CDM HL7 Message Specifications – Implementation Guide 2. 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta FINAL Printed on 02/28/2006 9:52 AM CDM HL7 Message Specifications – Implementation Guide 3. 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 © 2005 Government of Alberta 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: 4 Null Flavour Definition Notes NI 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. NA 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta FINAL Printed on 02/28/2006 9:52 AM CDM HL7 Message Specifications – Implementation Guide 4. 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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. 5 For CDM, the RMIM is the same as the DMIM. iax © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta FINAL Printed on 02/28/2006 9:52 AM CDM HL7 Message Specifications – Implementation Guide 5. 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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. 6 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 © 2005 Government of Alberta FINAL Printed on 02/28/2006 9:52 AM CDM HL7 Message Specifications – Implementation Guide Appendix B-2 HL7 v3 Artifacts AR TE Application Role Trigger Event RIM Reference Information Model Instantiate DMIM ST 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 7 This document is part of the formal HL7 v3 Standard at: http://www.hl7.org/v3ballot/html/infrastructure/conformance/conformance.htm iax © 2005 Government of Alberta 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 8 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 NI No information (default) MSK Masked NA Not Applicable OTH Other UNK Unknown ASKU Asked but unknown NAV Temporarily unavailable NASK Not asked iax © 2005 Government of Alberta 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 SETwhere 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 PDFThis 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 d Days wk Weeks mo Months a 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 d Days wk Weeks mo Months a 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 © 2005 Government of Alberta 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 d Days wk Weeks mo Months a 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 © 2005 Government of Alberta 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 ms Milliseconds s Seconds min Minutes h Hours d Days wk Weeks mo Months iax © 2005 Government of Alberta FINAL Printed on 02/28/2006 9:52 AM CDM HL7 Message Specifications – Implementation Guide Code Display-name a 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 © 2005 Government of Alberta 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) kg Kilograms [lb_av] Pound (imperial) m Meters cm Centimeters [ft_br] Foot (imperial) [in_br] Inch (imperial) g/l Grams per litre iax © 2005 Government of Alberta 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) nl Nano-litres ml Milli-litres dl Deca-litres l Litres [drp] Drops [foz_us] Fluid ounces (U.S.) [tbs_us] Tablespoon (U.S.) [tsp_us] Teaspoon (U.S.) ng Nanograms mg Milligrams iax © 2005 Government of Alberta FINAL Printed on 02/28/2006 9:52 AM CDM HL7 Message Specifications – Implementation Guide D.5.5 Code Display-name dg Decagrams g Grams kg 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 © 2005 Government of Alberta 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 L Legal P Pseudonym Name qualifier: Code Display-name IN 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 © 2005 Government of Alberta 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 H Home WP 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 Company 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 H Home WP Work place EC Emergency contact PG Pager (not for use with e-mail) MC Mobile Contact iax © 2005 Government of Alberta 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: EXAMPLEApt A5, 123 Some Street N.W. Edmonton ,Alberta A1B 2C3 Canada 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 © 2005 Government of Alberta 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 PMOEXIF Metadata provided by EXIF.tools