Health Data Courier™
Release 1.2
Interoperability Specification
Release 1.2
Message Profiles and DTDs for
Admit/Discharge/Transfer and Orders/Results
NOTICE
The information contained in this document is copyrighted by Killdara Corporation and is subject to change without notice.
The material in this document is based on information published by Killdara Corporation. Publication of this document does not represent a commitment to implement any portion of this specification in the products of the submitters.
WHILE THE INFORMATION IN THIS PUBLICATION IS BELIEVED TO BE ACCURATE, KILLDARA CORPORATION MAKES NO WARRANTY OF ANY KIND WITH REGARD TO THIS MATERIAL INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Killdara Corporation shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance or use of this material.
This document contains proprietary information, which is protected by copyright. All Rights Reserved. No part of this work covered by copyright hereon may be reproduced or used in any form or by any means—graphic, electronic, or mechanical, including photocopying, recording, taping, or information storage and retrieval systems—without permission of the copyright owner.
RESTRICTED RIGHTS LEGEND. Use, duplication, or disclosure by government is subject to restrictions as set forth in subdivision (c) (1) (ii) of the Right in Technical Data and Computer Software Clause at DFARS 252.227.7013.
Copyright 2000 by Killdara Corporation
For more information, contact:
Product Support
Killdara Corporation
77 Mill Street, P.O. Box 1795
Almonte, Ontario, Canada, K0A 1A0
Telephone: 1-613-256-8685
Fax: 1-613-256-8710
Internet:
Contents
Health Data Courier™ Release 1.2 Change Document
1.0 Introduction
About Killdara
About this manual
Why Message Profiles
Object Oriented Approach
XML and HL7
HL7 Compatibility
HL7 Acknowledgement Modes
Translation of message symbol definition description to XML DTD form
2.0 Admit Discharge Transfer (ADT) Messages Overview
Introduction – ADT semantics
Actors
ADT Use Case Overview
2.1 Admit a Patient/Visit Notification (Message Type ADT^A01)
Use Case
Description
Dynamic Definition
Static Definition
2.2 Transfer a Patient (Message Type ADT^A02)
Use Case
Description
Dynamic Definition
Static Definition
2.3 Discharge a Patient / End Visit (Message Type ADT^A03)
Use Case
Description
Dynamic Definition
Static Definition
2.4 Register a Patient (Message Type ADT^A04 / ACK^A04)
Use Case
Description
Dynamic Definition
Static Definition
2.5 Pre-admit a Patient (Message Type ADT^A05)
Use Case
Description
Dynamic Definition
Static Definition
2.6 Update Patient Information (Message Type ADT^A08)
Use Case
Description
Dynamic Definition
Static Definition
2.7 Cancel Admit (Message Type ADT^A11)
Use Case
Description
Dynamic Definition
Static Definition
3.0 Diagnostic Study Order Overview
Introduction
Actors
What is an order?
Who creates the order?
Use Case – Overview
3.1 New Diagnostic Study Order (Message type ORM^O01)
Use Case
Description
Dynamic Definition
Static Definition
3.2 Diagnostic Study Order Accepted (Message Type ORR^O02)
Use Case
Description:
Dynamic Definition
Static Definition
3.3 Unable to Accept Diagnostic Study Order (Message Type ORR^O02)
Use Case
Description
Dynamic Definition
Static Definition
3.4 Diagnostic Study Order Cancelled by Filler (Message Type ORR^O02)
Use Case
Description:
Dynamic Definition
Static Definition
3.5 Cancel Diagnostic Study Order (Message Type ORM^O01)
Use Case
Description:
Dynamic Definition
Static Definition
3.6 Diagnostic Study Order Cancelled As Requested (Message Type ORR^O02)
Use Case
Description:
Dynamic Definition
Static Definition
3.7 Unable to Cancel Diagnostic Study Order (Message Type ORR^O02)
Use Case
Description
Dynamic Definition
Static Definition
3.8 Unsolicited Transmission of Observation Results (Message Type ORU^RO1)
Use Case
Description
Dynamic Definition
Static Definition
4.0 Appendices
4.1 Appendix A
Admit Patient Content Model Diagram
ADTA01_AdmitPatient DTD
4.2 Appendix B
Transfer Patient Content Model Diagram
ADTA02_TransferPatient DTD
4.3 Appendix C
Discharge Patient Content Model Diagram
ADTA03_DischargePatient DTD
4.4 Appendix D
Register Patient Content Model Diagram
ADTA04_RegisterPatient DTD
4.5 Appendix E
Pre-Admit Patient Content Model Diagram
ADTA05_PreadmitPatient DTD
4.6 Appendix F
Update Patient Info Content Model Diagram
ADTA08_UpdatePatientInfo DTD
4.7 Appendix G
Cancel Admit Content Model Diagram
ADTA11_CancelAdmit DTD
4.8 Appendix H
Admit/Discharge/Transfer Common Segments Definitions
4.9 Appendix I
ADT_Common_Segments DTD
4.10 Appendix J
ADT Field Definitions
4.11 Appendix K
ADT_Fields DTD
4.12 Appendix L
New Diagnostic Study Order Content Model Diagram
ORMO01_NewDiagnosticStudyOrder DTD
4.13 Appendix M
Response Diagnostic Study Order Content Model Diagram
ORRO02_DiagnosticStudyOrderAccepted DTD
ORRO02_DiagnosticStudyOrderCancelled (by Filler) DTD
ORRO02_DiagnosticStudyOrderCancelledAsRequested DTD
ORRO02_UnableToCancelDiagnosticStudyOrder DTD
Unable to Accept Diagnostic Study Order Content Model Diagram
ORRO02_UnableToAcceptDiagnosticStudyOrder DTD
4.14 Appendix N
Cancel Diagnostic Study Order Content Model Diagram
ORMO01_CancelDiagnosticStudyOrder DTD
4.15 Appendix O
Unsolicited Transmission of Observation Results Content Model Diagram
ORUR01_UnsolicitedTransmissionOfObservationResults DTD
4.16 Appendix P
Order/Result Common Segments Definitions
4.17 Appendix Q
OrderResult_CommonSegments DTD
4.18 Appendix R
Order/Result Field Definitions
4.19 Appendix S
OrderResult_Fields DTD
4.20 Appendix T
HL7 V2.3.1 Data Types Table
4.21 Appendix U
HL7 V2.3.1 Value Sets Tables
4.22 Appendix V
DataTypes DTD
Preface...... Error! Bookmark not defined.
Health Data Courier™ Release 1.2 Change Document...... 7
1.0 Introduction...... 8
Why Message Profiles?...... 9
HL7 Acknowledgement Modes...... 12
Object Oriented Approach...... 9
Translation of message symbol definition description to XML DTD form...... 13
XML Architecture...... 10
2.0 Admit Discharge Transfer Messages Overview...... 15
Introduction...... 15
Actors...... 15
ADT Use Case Overview...... 16
2.1 Admit a Patient/Visit Notification (Message Type ADT^A01)...... 17
Use Case...... 17
Description...... 17
Dynamic Definition...... 18
Static Definition...... 19
2.2 Transfer a Patient (Message Type ADT^A02)...... 20
Use Case...... 20
Description...... 20
Dynamic Definition...... 21
Static Definition...... 22
2.3 Discharge a Patient / End Visit (Message Type ADT^A03)...... 24
Use Case...... 24
Description...... 24
Dynamic Definition...... 25
Static Definition...... 26
2.4 Register a Patient (Message Type ADT^A04 / ACK^A04)...... 27
Use Case...... 27
Description...... 27
Dynamic Definition...... 28
Static Definition...... 29
2.5 Pre-admit a Patient (Message Type ADT^A05)...... 30
Use Case...... 30
Description...... 30
Dynamic Definition...... 31
Static Definition...... 32
2.6 Update Patient Information (Message Type ADT^A08)...... 33
Use Case...... 33
Description...... 33
Dynamic Definition...... 34
Static Definition...... 35
2.7 Cancel Admit (Message Type ADT^A11)...... 36
Use Case...... 36
Description...... 36
Dynamic Definition...... 37
Static Definition...... 38
3.0 Diagnostic Study Order Overview...... 39
Introduction...... 39
Actors...... 39
What is an order?...... 39
Who creates the order?...... 39
Use Case – Overview...... 41
3.1 New Diagnostic Study Order (Message type ORM^O01)...... 43
Use Case...... 43
Description...... 44
Dynamic Definition...... 45
Static Definition...... 45
3.2 Diagnostic Study Order Accepted (Message Type ORR^O02)...... 49
Use Case...... 49
Description:...... 49
Dynamic Definition...... 50
Static Definition...... 51
3.3 Unable to Accept Diagnostic Study Order (Message Type ORR^O02)...... 53
Use Case...... 53
Description...... 54
Dynamic Definition...... 55
Static Definition...... 55
3.4 Diagnostic Study Order Cancelled by Filler (Message Type ORR^O02)...... 58
Use Case...... 58
Description:...... 58
Dynamic Definition...... 59
Static Definition...... 60
3.5 Cancel Diagnostic Study Order (Message Type ORM^O01)...... 62
Use Case...... 62
Description:...... 63
Dynamic Definition...... 63
Static Definition...... 64
3.6 Diagnostic Study Order Cancelled As Requested (Message Type ORR^O02)...... 68
Use Case...... 68
Description:...... 68
Dynamic Definition...... 69
Static Definition...... 70
3.7 Unable to Cancel Diagnostic Study Order (Message Type ORR^O02)...... 72
Use Case...... 72
Description...... 73
Dynamic Definition...... 74
Static Definition...... 74
3.8 Unsolicited Transmission of Observation Results (Message Type ORU^RO1).....77
Use Case...... 78
Description...... 78
Dynamic Definition...... 79
Static Definition...... 80
4.0 Appendices...... 85
4.1 Appendix A...... 86
Admit Patient Content Model Diagram...... 86
ADTA01_AdmitPatient DTD...... 86
4.2 Appendix B...... 87
Transfer Patient Content Model Diagram...... 87
ADTA02_TransferPatient DTD...... 87
4.3 Appendix C...... 88
Discharge Patient Content Model Diagram...... 88
ADTA03_DischargePatient DTD...... 88
4.4 Appendix D...... 89
Register Patient Content Model Diagram...... 89
ADTA04_RegisterPatient DTD...... 89
4.5 Appendix E...... 90
Pre-Admit Patient Content Model Diagram...... 90
ADTA05_PreadmitPatient DTD...... 90
4.6 Appendix F...... 91
Update Patient Info Content Model Diagram...... 91
ADTA08_UpdatePatientInfo DTD...... 91
4.7 Appendix G...... 92
Cancel Admit Content Model Diagram...... 92
ADTA11_CancelAdmit DTD...... 92
4.8 Appendix H...... 93
Admit/Discharge/Transfer Common Segments Definitions...... 93
4.9 Appendix I...... 100
ADT_Common_Segments DTD...... 100
4.10 Appendix J...... 102
ADT Field Definitions...... 102
4.11 Appendix K...... 113
ADT_Fields DTD...... 113
4.12 Appendix L...... 118
New Diagnostic Study Order Content Model Diagram...... 118
ORMO01_NewDiagnosticStudyOrder DTD...... 118
4.13 Appendix M...... 120
Response Diagnostic Study Order Content Model Diagram...... 120
ORRO02_DiagnosticStudyOrderAccepted DTD...... 120
ORRO02_DiagnosticStudyOrderCancelled (by Filler) DTD...... 120
ORRO02_DiagnosticStudyOrderCancelledAsRequested DTD...... 121
ORRO02_UnableToCancelDiagnosticStudyOrder DTD...... 121
Unable to Accept Diagnostic Study Order Content Model Diagram...... 122
ORRO02_UnableToAcceptDiagnosticStudyOrder DTD...... 122
4.14 Appendix N...... 123
Cancel Diagnostic Study Order Content Model Diagram...... 123
ORMO01_CancelDiagnosticStudyOrder DTD...... 123
4.15 Appendix O...... 125
Unsolicited Transmission of Observation Results Content Model Diagram...... 125
ORUR01_UnsolicitedTransmissionOfObservationResults DTD...... 125
4.16 Appendix P...... 127
Order/Result Common Segments Definitions...... 127
4.17 Appendix Q...... 128
OrderResult_CommonSegments DTD...... 128
4.18 Appendix R...... 129
Order/Result Field Definitions...... 129
4.19 Appendix S...... 148
OrderResult_Fields DTD...... 148
4.20 Appendix T...... 153
HL7 V2.3.1 Data Types Table...... 153
4.21 Appendix U...... 157
HL7 V2.3.1 Value Sets Tables...... 157
4.22 Appendix V...... 180
DataTypes DTD...... 180
1
Health Data Courier™ Release 1.2 Change Document
September 15, 2000
Section One - Introduction
Section / Notes1 / Original Release
Section Two – Admit/Discharge/Transfer
Section / Notes2 / Original Release
Section Three – Orders/Results
Section / Notes3 / Original Release
Section Four - Appendices
Section / Notes4 / Original Release
1.0 Introduction
About Killdara
There are very few technologies that will have a greater impact on healthcare management than the integration of electronic patient records. A system for secure and seamless sharing of records would obviously provide compelling benefits to patients – through greater speed and accuracy – and would enable tremendous economies for the healthcare facility.
Killdara Corporation has introduced a groundbreaking healthcare integration device, the Health Data Courier, a secure and intelligent data-sharing product for clinical applications that can be quickly and economically built out to all of a health-care facility’s operating units and business partners. Moreover, we at Killdara are committed to implementing the most widely used standards including:
- HL7 (Health Level Seven), an application protocol for electronic data exchange in healthcare environments;
- XML (eXtensible Markup Language), a common approach to data type definition (DTDs), which will allow healthcare facilities to electronically exchange patient records without the need to manually map each data field; and
- PKI (Public Key Infrastructure), a widely supported security protocol that has been recognized by HIPAA (Health Insurance Portability Accountability Act) and that has been broadly adopted by national healthcare organizations.
But our goal goes beyond using existing standards and maintaining a non-proprietary position. Killdara is also working hard to further these standards, to produce commercially functional and friendly DTDs and to promote conformance within the Healthcare Industry. The purpose of this document is to describe message profiles for admit/ discharge/transfer and orders/results.
An HL7 message profile is a precise and unambiguous specification of a standard HL7 message that has been analyzed for use within a particular set of requirements. Use case analysis and interaction modeling provides explicit message profile documentation, which will allow interface partners to understand what data will be exchanged, the format of the data and the acknowledgement responsibilities of the sender and receiver.
Over the last number of years, the concept of basing standards development on an information model of the application domain has evolved. Development of this approach began in the early meetings of the IEEE P1157 Committee. This led to very similar processes being developed in the American College of Radiology - National Electrical Manufacturers Association (ACR-NEMA), Health Level Seven (HL7), and in the European Committee for Standardization (CEN) standards activities. The approach is based on the recognition that, regardless of the method of communication, the subject matter for health care communications is drawn from a representation or model of health care and health care processes. It follows that a common information model of the health care domain can be used as the starting point for any communication standard.
Development of a coherent set of messages from the Information Model requires a process for mapping the structure and content of the Information Model to the syntax of the messages. This was started in IEEE P1157, has been advanced by the work of CEN TC251 and is being adopted by the HL7 committee for development of their future messaging standards. HL7 Version 3.0 will be based upon an explicit object-oriented information model.
Killdara’s approach is to use an Object Oriented Design complemented by a message profile, which is based on business logic, and use case specification. Our goal is to provide a balance between specificity and flexibility of messaging with deliverables being:
- use case specification
- dynamic definition (sequence diagram, dynamic profile identifier)
- static definition (message profiles, segment profiles, static profile identifier, and user friendly XML DTDs)
In order to accomplish this, we have drawn upon the work done by the Andover Working Group (AWG) now the HL7 Conformance SIG, the Specification for Message Profile Content V2.1 March 9, 2000, and, when needing further clarification, the HL7 V2.3.1 Standard documentation.
About this manual
This book will help you to integrate Killdara’s Health Data Courier by guiding you through the interoperability specifications for Health Level Seven (HL7) messaging. In this first section we’ll give you some background information on HL7, XML and Killdara. In the next two chapters (2.x and 3.x) we’ll break down each HL7 message into a ‘Message Profile’ which will to show you the exact context in which itthe message is intended to must be used. This is what we call a ‘Message Profile’. Finally, the appendixes will show you the actual document type definitions (DTD’s) which are referenced by the Message Profiles. The DTD’s supplied with Health Data Courier allow you to use XML to integrate the exchange of HL7 messages regardless of whether any other nodes on your system are compliant with the HL7 standard.
This manual covers messages for two key areas: handling the flow of patients and the ordering of tests. In HL7 language these are called Admit/Discharge/Transfer and Diagnostic Study Orders. These two areas comprise the majority of messages in the healthcare field and may be entirely sufficient for your needs. If your system requires other messages or variations of these messages you can quickly design new DTD’s using the supplied DTD’s as a model.
HL7 Compatibility
The next release of HL7 (V3.0) [LH1]will be based on an object oriented domain analysis of the healthcare environment. In anticipation of that release the Health Data Courier incorporates concepts such as: unambiguous message specification, conformance testing, and a more usable message encoding scheme (XML).
The message profiles in this book are currently being registered with HL7. This will generate a repository of V3.0 compatible profiles, which everyone in the healthcare information industry can use and contribute to. Eventually, conformance claims will be easily verified against the conformance profile documentation of the HL7 vendor or clinical institution, especially if those profiles are registered with HL7. The XML DTDs included with documentation can be used not only to build compliant messages, but also to validate specific messages. Both vendors and institutions can benefit from this approach since both development and integration costs can be reduced.
Why Message Profiles?Why Message Profiles
Achieving “plug and play” information interchange among a set of healthcare applications requires consistent semantics for the shared domain. The However, the sheer scope of the healthcare domain requires that the method used to define and document those semantics be both efficient and scalable. Furthermore, the rapid evolution of the underlying information systems infrastructure requires that this semantic method be flexible enough to protect the investment in healthcare applications from that evolutionchanges to the infrastructure.
The Information Model used in the Health Data Courier provides an open, standards-based architectural approach to meeting these objectives.
The method for development of the Information Model has been demonstrated to support large-scale development and is consistent with emerging healthcare standards. The method provides for efficiency both through leverage of those standards and through tooling which has been developed to support the method.
The message profiles in this book support the Information Model by defining the responsibilities for sending or receiving one or more interactions. The profiles therefore form the basis for establishing conformance to the specification.
In this document we provide XML DTDs to describe the message profile. This representation of the message structure is easily interpreted by computer application and can be applied for message validation. A message can be tested for compliance to the profile in an automated way.
Object Oriented Approach
Object-Oriented Design (OOD) has evolved over the past decade as computer programmers attempted to reduce complexity and increase reliability by sharing portions of code. In essence, the concept of OOD is to store code in small piecesfactor out segments of code that are used in more than one place, with the relevant piece being called when required. In addition to its elegance, OOD has several benefits for Health Data Courier developers and integrators:
Reduced development time. As code does not have to be rewritten multiple times in various places throughout the DTD, using an Objectobject-Oriented oriented approach greatly reduces development time.
Reduced maintenance and code upgrade time. As each piece of code is written in only one place, altering the code becomes a much simplersimple matter of finding and replacing a single instance of the code, rather than multiple instances
Shorter orientation time for new developers.Gentler learning curve As new developers begin to work with the DTDs, their learning curve is shortened lowered by the consistency of the code. For example, Oonce developers understand what is involved inunderstand the a Message Header Segment, for example, they no longer have to wade through the same code in each message. Instead, the phrase “Message Header Segment” has a single meaning throughout the DTDs.
Fields, data types and those segments that have a common structure across messages use OOD in the creation of XML DTDs. Therefore DTDs are constructed for the following:
- Messages
- Common segment definitions
- Segments
- Fields
- Data types
The reuse of code is complemented by a Killdara’s message profiles which are based on business logic and use case modeling, which provides specificity of messages.