Health Data Courier Application Guide
[pic]
Health Data Courier™
[pic]
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 7
1.0 Introduction 8
About Killdara 8
About this manual 9
Why Message Profiles 10
Object Oriented Approach 10
XML and HL7 11
HL7 Compatibility 12
HL7 Acknowledgement Modes 13
Translation of message symbol definition description to XML DTD form 13
2.0 Admit Discharge Transfer (ADT) Messages Overview 15
Introduction – ADT semantics 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) 23
Use Case 23
Description 23
Dynamic Definition 24
Static Definition 25
2.4 Register a Patient (Message Type ADT^A04 / ACK^A04) 26
Use Case 26
Description 26
Dynamic Definition 27
Static Definition 28
2.5 Pre-admit a Patient (Message Type ADT^A05) 29
Use Case 29
Description 29
Dynamic Definition 30
Static Definition 31
2.6 Update Patient Information (Message Type ADT^A08) 32
Use Case 32
Description 32
Dynamic Definition 33
Static Definition 34
2.7 Cancel Admit (Message Type ADT^A11) 35
Use Case 35
Description 35
Dynamic Definition 36
Static Definition 37
3.0 Diagnostic Study Order Overview 38
Introduction 38
Actors 38
What is an order? 38
Who creates the order? 38
Use Case – Overview 40
3.1 New Diagnostic Study Order (Message type ORM^O01) 42
Use Case 42
Description 43
Dynamic Definition 44
Static Definition 44
3.2 Diagnostic Study Order Accepted (Message Type ORR^O02) 48
Use Case 48
Description: 48
Dynamic Definition 49
Static Definition 50
3.3 Unable to Accept Diagnostic Study Order (Message Type ORR^O02) 52
Use Case 52
Description 53
Dynamic Definition 54
Static Definition 54
3.4 Diagnostic Study Order Cancelled by Filler (Message Type ORR^O02) 57
Use Case 57
Description: 57
Dynamic Definition 58
Static Definition 59
3.5 Cancel Diagnostic Study Order (Message Type ORM^O01) 61
Use Case 61
Description: 62
Dynamic Definition 62
Static Definition 63
3.6 Diagnostic Study Order Cancelled As Requested (Message Type ORR^O02) 67
Use Case 67
Description: 67
Dynamic Definition 68
Static Definition 69
3.7 Unable to Cancel Diagnostic Study Order (Message Type ORR^O02) 71
Use Case 71
Description 72
Dynamic Definition 73
Static Definition 73
3.8 Unsolicited Transmission of Observation Results (Message Type ORU^RO1) 76
Use Case 77
Description 77
Dynamic Definition 78
Static Definition 79
4.0 Appendices 84
4.1 Appendix A 85
Admit Patient Content Model Diagram 85
ADTA01_AdmitPatient DTD 85
4.2 Appendix B 86
Transfer Patient Content Model Diagram 86
ADTA02_TransferPatient DTD 86
4.3 Appendix C 87
Discharge Patient Content Model Diagram 87
ADTA03_DischargePatient DTD 87
4.4 Appendix D 88
Register Patient Content Model Diagram 88
ADTA04_RegisterPatient DTD 88
4.5 Appendix E 89
Pre-Admit Patient Content Model Diagram 89
ADTA05_PreadmitPatient DTD 89
4.6 Appendix F 90
Update Patient Info Content Model Diagram 90
ADTA08_UpdatePatientInfo DTD 90
4.7 Appendix G 91
Cancel Admit Content Model Diagram 91
ADTA11_CancelAdmit DTD 91
4.8 Appendix H 92
Admit/Discharge/Transfer Common Segments Definitions 92
4.9 Appendix I 99
ADT_Common_Segments DTD 99
4.10 Appendix J 101
ADT Field Definitions 101
4.11 Appendix K 112
ADT_Fields DTD 112
4.12 Appendix L 117
New Diagnostic Study Order Content Model Diagram 117
ORMO01_NewDiagnosticStudyOrder DTD 117
4.13 Appendix M 119
Response Diagnostic Study Order Content Model Diagram 119
ORRO02_DiagnosticStudyOrderAccepted DTD 119
ORRO02_DiagnosticStudyOrderCancelled (by Filler) DTD 119
ORRO02_DiagnosticStudyOrderCancelledAsRequested DTD 120
ORRO02_UnableToCancelDiagnosticStudyOrder DTD 120
Unable to Accept Diagnostic Study Order Content Model Diagram 121
ORRO02_UnableToAcceptDiagnosticStudyOrder DTD 121
4.14 Appendix N 122
Cancel Diagnostic Study Order Content Model Diagram 122
ORMO01_CancelDiagnosticStudyOrder DTD 122
4.15 Appendix O 124
Unsolicited Transmission of Observation Results Content Model Diagram 124
ORUR01_UnsolicitedTransmissionOfObservationResults DTD 124
4.16 Appendix P 126
Order/Result Common Segments Definitions 126
4.17 Appendix Q 127
OrderResult_CommonSegments DTD 127
4.18 Appendix R 128
Order/Result Field Definitions 128
4.19 Appendix S 147
OrderResult_Fields DTD 147
4.20 Appendix T 152
HL7 V2.3.1 Data Types Table 152
4.21 Appendix U 156
HL7 V2.3.1 Value Sets Tables 156
4.22 Appendix V 179
DataTypes DTD 179
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
Health Data Courier™ Release 1.2 Change Document
September 15, 2000
Section One - Introduction
|Section |Notes |
|1 |Original Release |
Section Two – Admit/Discharge/Transfer
|Section |Notes |
|2 |Original Release |
Section Three – Orders/Results
|Section |Notes |
|3 |Original Release |
Section Four - Appendices
|Section |Notes |
|4 |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) 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:
1. Messages
2. Common segment definitions
3. Segments
4. Fields
5. 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.
Schemas are unnecessary at this point as the functionality available in the HL7 V2.2 Conformance SIG is captured in the DTDs. Once these DTDs are registered with the HL7 Conformance SIG Registry, they will not change.
XML and HL7
The World Wide Web Consortium (W3C) has released the first version of the Extensible Markup Language (XML) specification to broad support within the industry. XML was designed to fill a deficiency identified in other Internet and markup standards, like HTML, by supporting data definition and information processing requirements. It provides a middle ground between the limitations and general inflexibility of HTML, and the overall complexity of SGML. This specification is widely seen as leading to the next generation of Internet capabilities. Extensions and enhancements to the XML specification are under development within the W3C. As these are completed and released, they will be reviewed by Killdara for applicability in support of further enabling application to possible enhancement of the HD Courier™.
This section describes the process for development, translation, and implementation of HL7 compliant Document Type Definitions in XML. For detailed information on the XML specification itself, and other related W3C projects, please refer to the official W3C web site at , or one of the many available publications on the topic.
Implementation projects using HL7 may be based on the original message structure, or in the XML format. The decision to use one format or another is left to the systems integrators, application vendors, and ultimately, the customers. It is expected that the need for support of both approaches will decrease over time, as migration to XML occurs, and software vendors begin to support XML as a native integration mechanism within their products. As migration and adoption progresses, the proprietary format may be phased out.
As an overall design principle, Killdara’s approach to XML is focused on simplicity and usability. Killdara has tried to provide the entire body of knowledge contained in Order/Result and Admit/Discharge/Transfer within the our set of distributed DTDs, while avoiding the use of some of the more sophisticated XML constructs unless absolutely necessary.
While this document reviews each major component of the HL7 as implemented in XML, it is not intended to be a primer or training guide. A working knowledge of both XML and the HL7 is assumed.
The Case for XML
XML provides significant advantages over more traditional approaches to inter-application messaging and interface development. The result is a framework that strongly supports the implementation needs of the vendor, integrator, and customer communities. A number of considerations in this area are provided here.
3rd Third Party Tool and Development Support: Vendors and customers may leverage the rapidly expanding market of available 3rd third party tools and development libraries as a part of their implementation solutions. These include parsing and validating APIs and message generation tools. As the XML standard continues to be expanded, solution providers will be well positioned to take advantage of the applicable enhancements with little incremental internal development effort.
Readability: Traditional messaging and interface techniques have often been implemented using cryptic message formats. Development and troubleshooting these solutions is correspondingly difficult. XML is easy to read and structured intuitively.
Extensibility: A unique characteristic of an XML implementation is its support for vendor and implementation specific extensions. There will be a number of circumstances where implementations need to support data elements that are not a part of the HL7 specification. These extensions may be incorporated into the solution without adding complexity or increasing maintenance effort.
Knowledge and Skills Base: The widespread awareness and adoption of XML has resulted in a significant knowledge base for customer and vendor support. Unlike proprietary solutions, knowledge and support of integration solutions based on XML may be obtained throughout the industry. As XML gains in popularity, the available resource pool promises to continue to grow.
Related Technologies: Another advantage of an XML implementation is the opportunity for incorporation into other types of solutions based on the same technology. These include web browser support, programming tools, and knowledge management systems.
In general, Killdara’s use of XML will be limited to the standard implementation as released by the World Wide Web Consortium. In order to maintain flexibility and openness, the use of proprietary extensions or non-standard constructs will not be supported.
Implementation Overview
Within the scope of business application integration, XML solutions are comprised of two key components:; the DTDs (Document Type Definitions), and the XML transaction messages themselves. (XSL style sheets are not used for the current implementation.) The DTD is used to formally define and validate the overall structure and content of a message. Simply put, the DTD acts as a template used to define the message structure and relationships between the data elements. In some cases, the DTD information is embedded inside the XML message. For the purposes of HL7 XML implementation, DTDs will always be deployed as a set of separate files.
According to the W3C Frequently Asked Questions list,
"A DTD is usually a file (or several files to be used together) which contains a formal definition of a particular type of document. This sets out what names can be used for elements, where they may occur, and how they all fit together."
Mapping from the HL7 Interoperability Specification to XML requires the development of a set of DTDs. The sections belowfollowing chapters outline the specifications and their supporting DTD. The Admit/Discharge/Transfer and Orders/Results messages are converted into DTDs and can be found in the appendices.
HL7 Compatibility
The next release of HL7 (V3.0) 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.
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 increased 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.
HL7 Acknowledgement Modes
The HL7 standard provides two kinds of acknowledgement to an initiating message.
• Accept (Acc) acknowledgement (for example the unsolicited acknowledgement message)
• Application (App) acknowledgement (i.e., the ORR^O02 order response message)
The AccNE (accept never) is an unsolicited acknowledgement message, which signifies that the receiver got the message only. If the application is using the AppAL (application always) message, it is redundant to use AccNE. The application acknowledgement (ORR^O02) is sent only if the dynamic profile identifier specifies it. The AccNe is also not necessary if a reliable/robust transport mechanism guarantees messages will not be lost if, for example, the power shuts down. The message is persistent when it makes sure the destination receives the message or if, when necessary, the application can regenerate the message to respond to a query.
The AccNE_AppNE indicates to the receiver that when the message is received it is not necessary to send the order accepted; otherwise an endless cycle of “I received your message, I received your received message …” ensues.
Translation of message symbol definition description to XML DTD form
The following chart shows how HL7 2.x messages are translated into an XML DTD.
HL7 segment’s (tabular format) also offers a ‘conditional’ state under column R/O. Another way, not listed below, of defining fields is conditional. Please note that “conditional” is documented in the tabular form (column R/O) as conditional The conditional status but is mapped into a DTD as “optional” and it remains the responsibility of the application to address it. For an example see the segment OBX in the Cancel Diagnostic Study Order, ORM^O01.
[pic]
Segment Optionality Descriptors
R Required. A conforming sending application must provide a valid value for all “R” fields. The value must be of the specified type and within the range specified for the field.
RE Required, but may be empty. A conforming sending application must be capable of providing a valid value for all “RE” fields. If the conforming sending application knows the value for this field, then the field value must be provided of the specified type and within the range specified for the field. If the conforming sending application does not know the value for this field, then the field value must be specified as empty. For HL7 Encoding Rules, empty is a distinguished value. For the purposes of the DTDs this is an optional field.
C Conditional. There is a predicate associated with this field, which identifies the conditions under which the value of the field should be specified. The predicate must be based on other field values within this message. This predicate may be expressed as a mathematical expression or in text and may utilize use operators such as equivalence, logical AND, and logical OR. The conforming sending application must evaluate the predicate. If the predicate is satisfied, then the conforming sending application must provide a value of the specified type and within the range specified for the field. If the predicate is not satisfied, then the field value should be specified as empty. For the purposes of the DTDs this is an optional field and is an application issue.
CE Conditional, but may be empty. There is a predicate associated with this field that identifies the conditions under which the value of the field should be specified. The predicate must be based on other field values within this message. This predicate may be expressed as a mathematical expression or in text and may utilize use operators such as equivalence, logical AND, and logical OR. The conforming sending application must evaluate the predicate. If the predicate is satisfied and the conforming sending application knows the value for the field, then the conforming sending application must provide a value of the specified type and within the range specified for the field. If the predicate is satisfied but the conforming sending application does not know the value for this field, then the field value should be specified as empty. If the predicate is not satisfied, then the field value should be specified as empty. For the purposes of the DTDs this is an optional field and is an application issue.
2.0 Admit Discharge Transfer (ADT) Messages Overview
Introduction – ADT semantics
The language of healthcare information has been undergoing evolution and refinement since the time of Hippocrates. While a degree of ambiguity may have been acceptable in earlier times, modern information systems require that careful attention be paid to semantics. Because our message profiles are based on the most recent HL7 standards, throughout the book we will note differences with earlier semantic conventions that may still be in use.
In V2.3 terms for patient class are described;For example, to match the current HL7 standard “admitted” patient will be used instead of “inpatient” to indicate any patient classes that are assigned to a patient bed for at least a few hours. “Non-admitted” patients will be used instead of “outpatients” to indicate any patient classes that are not assigned to a bed, but rather to an exam room or another type of encounter room or clinic waiting room.
We recognize that different hospital systems use different definitions of for the terms “inpatient,” “outpatient,” “emergency room,” and “recurring patient classes,” or handle these patients differently. Therefore, the trigger events are not defined as specific to any patient class. The patient class for any visit related information must be specified in PV1-2-patient class in order to enable each system to handle the transaction properly. This means that both the event and the patient class must be checked in order to determine how to handle the transaction. If a certain patient class can sometimes be assigned to a bed and sometimes not, for example, “observation patients,” then PV1-3-assigned patient location must also be checked.
In order to accommodate non-admitted patient events without using the same trigger events as those for admitted patients, we would need an entirely new set of non-admitted patient events. If we do that, disparate systems would still have a hard time agreeing about whether certain patient classes should use the admitted patient events or the non-admitted patient events, because of the differences between how admitted and non-admitted patients are defined and handled. Both admitted and non-admitted patient events are transmitted using most of the same events. The meaning or interpretation of those events will depend upon the patient class.
In order to alleviate this ambiguity, we recommend that the A08 transaction be used to update fields that are not necessarily related to any of the other trigger events. For example, if an ADT system allows the transfer function of the patient’s medical service and attending doctor to be changed, the ADT system should send two HL7 messages. It should send an A02 to reflect the location change, followed by an A08 to reflect the change in the medical service and the attending doctor.
Actors
1. Hospital Registration System or Patient Management System -- is responsible for notifying all interested Clinical Information Systems. Essentially the Patient Management System is an ADT message, a specialization, which trigger an event. The action taken by the Patient Management System depending on the trigger event. The terms “Hospital Registration System” and “Patient Management System” are used interchangeably.
2. Clinical Information System -- is responsible for all departmental operation and provides the services required.
ADT Use Case Overview
[pic]
The following DTDs apply to this use case model and must be located in the same directory for parsing:
ADTA01_AdmitPatient.dtd
ADTA02_TransferPatient.dtd
ADTA03_DischargePatient.dtd
ADTA04_RegisterPatient.dtd
ADTA05_PPreadmitPatient.dtd
ADTA08_UpdatePatientInfo.dtd
ADTA11_CancelAdmit.dtd
ADT_Fields.dtd
ADT_Common_Segments.dtd
DataTypes.dtd
2.1 Admit a Patient/Visit Notification (Message Type ADT^A01)
In V2.2 the admission is processed and then the ADT^A01 message is triggered by the Hospital Registration System to notify the Clinical Information Systems. It includes short-stay and John Doe admissions. In V2.3 an A01 event is intended to be used for “Admitted” patients only. An A01 event is sent as a result of a patient undergoing the admission process, which assigns the patient to a bed. It signals the beginning of a patient’s stay in a healthcare facility. Normally, this information is entered in the Hospital Registration System and broadcast to the Clinical Information Systems. It includes short stay and John Doe admissions.
For example, an A01 event can be used to notify: the pharmacy system that a patient has been admitted and may be legitimately prescribed drugs; the nursing system that the patient has been admitted and needs a care plan prepared; the finance system of the start of the billing period; the dietary system that a new patient has been installed and requires dietary services; the laboratory, pathology, radiology systems that a patient has been admitted and is entitled to receive services; the clinical repository that an admission has taken place for the EMR (electronic medical record).
The PV-3 Assigned patient location field can be specified with the bed component as empty. This would relate to an admission to a unit/room where the patient is “out-of-bed”.
Use Case
[pic]
Description
A patient undergoes the admission process which assigns the patient to a bed and notifies other applications, including: Pharmacy_System, Nursing_System, Dietary_System, Laboratory_System, Pathology_System, Radiology_System and the EMR_System that the patient has been admitted and is entitled to receive services.
Actors
Please see Actors ADT overview page 2015.
Preconditions
The patient is ready to be admitted
Flow of Events
1. A patient undergoes the process of admission and is assigned a bed
2. The Hospital Registration System notifies appropriate systems to provide services
Post Conditions
The patient is entitled to receive services
Derives Events
Killdara(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A01(1).NULL(0).NULL(0).1(1)
Dynamic Definition
Sequence Diagram
[pic]
Dynamic Profile
For ADT^A01: AccNE_AppAL
For further explanation, see HL7 Acknowledgement Modes, page 1513.
Static Definition
Message Level Profile
|ADT |Cardinality |Message Description |
|MSH |[1,1] |Message Header |
|EVN |[1,1] |Event Type |
|PID (1) |[1,1] |Patient Demographics |
|[{ NK1 }] |[0,+] |Next of Kin |
|PV1 (2) |[1,1] |Admit Visit Info |
|PV2 (2) |[1,1] |More Admit Visit Info |
|[{ AL1 }] |[0,+] |Allergy Info |
Segment Level Profile
In the tabular representation, the fields contained within each supported segment, the data type, and repeat count is defined. Where available, the HL7 table corresponding to the value set for each field is also identified. For further information translation of message symbol definition description to XML DTD form page 1613.
ADT_Common Segments Definitions
(See Appendix H)
Field Level Profile
ADT_Fields DTD
(See Appendix K)
Content Model Diagram
(See Appendix A)
ADT^A01 Admit A Patient/Visit Notification DTD
Killdara(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A01(1).NULL(0).NULL(0).1(1)
(See Appendix A)
Value sets taken from HL7 Standard V2.3.1
(See Appendix U)
Data Types DTD
(See Appendix V)
2.2 Transfer a Patient (Message Type ADT^A02)
In V2.2 the message type ADT^A02 meant that a patient moves from one location to another. In V2.3 anAn A02 event is issued as a result of the patient changing his or her assigned location. This A02 event can be used with admitted and non-admitted patients. The new patient location should appear in PV1-3-assigned patient location while the old patient location should appear in PV1-6-Prior patient location. For example, an A02 event can be used to notify: laboratory, radiology, pathology that the patient has changed location and test results should be redirected; pharmacy that drugs should be redirected for the patient; dietary that the meals should be delivered to a different location; the clinical repository that a transfer has taken place for the EMR.
Both PV1-3 Assigned Patient Location and PV1-6 Prior Patient Location are required indicating what location (unit, room, bed) the patient is being transferred to and from. A02 can also be used for moving a patient in or out of a bed, for example if the patient is going to a temporary location (such as the O/R, XRAY, LIMBO, the HALLWAY).
Use Case
[pic]
Description
A patient changes location and certain resources should be redirected to this new location. This message is sent by the ADT_System, the event code A02 is used to notify a redirection of services to other applications, including: Pharmacy_System, Nursing_System, Dietary_System, Laboratory_System, Pathology_System, Radiology_System and the EMR_System.
Actors
Please see Actors ADT overview page 20page 15.
Preconditions
The patient’s condition requires that the patient be transferred to another facility, room or bed
Flow of Events
1. A patient undergoes a transfer of location
2. The Hospital Registration System notifies appropriate systems to redirect services
Post Conditions
The patient is transferred to a new location and receives required services
Derives Events
Killdara(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A02(2).NULL(0).NULL(0).1(1)
Dynamic Definition
Sequence Diagram
[pic]
Dynamic Profile
For ADT^A02: AccNe_AppAL
For further explanation see, HL7 Acknowledgement Modes, page 15page 13.
Static Definition
Message Level Profile
|ADT |Cardinality |Message Description |
|MSH |[1,1] |Message Header |
|EVN |[1,1] |Event Type |
|PID (1) |[1,1] |Patient Demographics |
|[{ NK1 }] |[0,+] |Next of Kin |
|PV1 (3) |[1,1] |Transfer Visit Info |
|PV2 (3) |[1,1] |More Transfer Visit Info |
|[{ AL1 }] |[0,+] |Allergy Info |
Segment Level Profile
In the tabular representation, the fields contained within each supported segment, the data type, and repeat count is defined. Where available, the HL7 table corresponding to the value set for each field is also identified. For further information see translation of message symbol definition description to XML DTD form page 16page 13.
Common Segments Definitions
(See Appendix H)
Field Level Profile
ADT_Fields DTD
(See Appendix K)
Content Model Diagram
(See Appendix B)
ADT^A02 Transfer a Patient DTD
Killdara(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A02(2).NULL(0).NULL(0).1(1)
(See Appendix B)
Value sets taken from HL7 Standard V2.3.1
(See Appendix U)
Data Types DTD
(See Appendix V)
2.3 Discharge a Patient / End Visit (Message Type ADT^A03)
In V2.2 message type ADT^A03 refers to changing a patient’s status from, for example, inpatient to discharge. In V2.3 anAn A03 event signals marks the end of a patient’s stay in a healthcare facility. It signals that the patient’s status has changed to “discharged” and that a discharge date has been recorded. The patient is no longer in the facility. The patient’s location prior to discharge should be entered in PV1-3-assigned patient location.
An A03 event can be sent to notify: the pharmacy that the patient’s stay has ended and that entitlement to drugs has changed accordingly, the nursing system that the patient has been discharged and that the care plan can be completed, the finance system that the patient billing period has ended, and/or the clinical repository that discharge has taken place for the EMR. For non-admitted patients, an A03 event signals the end of a patient’s visit to a healthcare facility. It could be used to signal the end of a visit for a one-time or recurring outpatient who is not assigned to a bed. It could also be used to signal the end of a visit to the Emergency Room. PV1-45-discharge date/time can be used for the Visit End Date/Time.
Use Case
[pic]
Description
The A03 message is sent by the ADT_System and is broadcast to other applications that have registered interest. It can notify other applications, including: Pharmacy_System, Nursing_System, Dietary_System, Laboratory_System, Pathology_System, Radiology_System and the EMR_System that a patient is no longer in the facility.
Actors
Please see Actors ADT overview page 20page 15.
Preconditions
The patient is registered in the Hospital Registration System
Flow of Events
1. An A03 event is triggered at the end of a patient’s stay in the healthcare facility
2. It can be used to signal the end of a visit for an outpatient who is not assigned a bed
3. The Hospital Registration System notifies the appropriate systems of the discharge
Post Conditions
The patient is not longer in the facility
Derives Events
Killdara(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A03(3).NULL(0).NULL(0).1(1)
Dynamic Definition
Sequence Diagram
[pic]
Dynamic Profile
For ADT^A03: AccNe_AppAL
For further explanation see, HL7 Acknowledgement Modes, page 15page 13.
Static Definition
Message Level Profile
|ADT |Cardinality |Message Description |
|MSH |[1,1] |Message Header |
|EVN |[1,1] |Event Type |
|PID (2) |[1,1] |Patient Identification |
|PV1 (4) |[1,1] |Discharge Visit Info |
Segment Level Profile
In the tabular representation, the fields contained within each supported segment, the data type, and repeat count is defined. Where available, the HL7 table corresponding to the value set for each field is also identified. For further information translation of message symbol definition description to XML DTD form page 16page 13.
Common Segments Definitions
(See Appendix H)
Field Level Profile
ADT_Fields DTD
(See Appendix K)
Content Model Diagram
(See Appendix C)
ADT^A03_DischargeAPatient/EndVisit DTD
Killdara(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A03(3).NULL(0).NULL(0).1(1)
(See Appendix C)
Value sets taken from HL7 Standard V2.3.1
(See Appendix U)
Data Types DTD
(See Appendix V)
2.4 Register a Patient (Message Type ADT^A04 / ACK^A04)
In V2.2 message type ADT^A04 includes emergency room patients and outpatients. In V2.3 aAn A04 event signals that the patient has arrived or checked in as a one-time, or recurring outpatient, and is not assigned to a bed. One example might be its use to signal the beginning of a visit to the Emergency Room. Note that some systems refer to these events as outpatient registrations or emergency admissions. PV1--44-admit date time is used for the visit start date/time.
Use Case
[pic]
Description
An A04 event signals that a patient has arrived or checked in but is not assigned a bed.
Actors
Please see Actors ADT overview page 20page 15.
Preconditions
The patient is ready for a clinical attention supplying demographic information
Flow of Events
1. A patient is registered into the Hospital Registration System
2. The patient has outpatient status or emergency admission and is not assigned a bed
Post Conditions
The patient is registered and the clinical information system is notified
Derives Events
Killdara(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A04(4).NULL(0).NULL(0).1(1)
Dynamic Definition
Sequence Diagram
[pic]
Dynamic Profile
For ADT^A04: AccNe_AppAL
For further explanation see, HL7 Acknowledgement Modes, page 15page 13.
Static Definition
Message Level Profile
|ADT |Cardinality |Message Description |
|MSH |[1,1] |Message Header |
|EVN |[1,1] |Event Type |
|PID (1) |[1,1] |Patient Demographics |
|[{ NK1 }] |[0,+] |Next of Kin |
|PV1 (2) |[1,1] |Admit Visit Info |
|PV2 (2) |[1,1] |More Admit Visit Info |
|[{ AL1 }] |[0,+] |Allergy Info |
Segment Level Profile
In the tabular representation, the fields contained within each supported segment, the data type, and repeat count is defined. Where available, the HL7 table corresponding to the value set for each field is also identified. For further information translation of message symbol definition description to XML DTD form page 16page 13.
Common Segments Definitions
(See Appendix H)
Field Level Profile
ADT_Fields DTD
(See Appendix K)
Content Model Diagram
(See Appendix D)
ADT^A04_RegisterAPatient DTD
Killdara(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A04(4).NULL(0).NULL(0).1(1)
(See Appendix D)
Value sets taken from HL7 Standard V2.3.1
(See Appendix U)
Data Types DTD
(See Appendix V)
2.5 Pre-admit a Patient (Message Type ADT^A05)
In V2.2 aA patient may be pre-admitted for a variety of reasons; e.g., prior to surgery so that they will be able to receive tests administered in the lab. The data may be entered into the surgery scheduling system and passed to the ADT system. In V2.3 an An A05 event is sent when as a result of a patient undergoing the pre-admission process. During this process, episode-related data is collected in preparation for a patient’s visit or stay in a healthcare facility. For example, a pre-admit may be performed prior to inpatient or outpatient surgery so that lab tests can be performed prior to the surgery. This event can also be used to pre-register a non-admitted patient.
The PV1-5 Assigned Patient Location is a Required field indicating the care unit where the patient will be admitted.
Use Case
[pic]
Description
An A05 event is sent when a patient undergoes the pre-admission process, which in preparation for a patient’s visit or stay in a healthcare facility, episode-related data is collected.
Actors
Please see Actors ADT overview page 20page 15.
Preconditions
Preadmission for a variety of reasons i.e. prior to surgery?
Flow of Events
1. The data is entered into another system and passed to the Hospital Registration System
2. The Hospital Registration System notifies the Clinical Information System
Post Conditions
The patient is prepared for a visit or stay in a healthcare facility
Derives Events
Killdara(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A05(5).NULL(0).NULL(0).1(1)
Dynamic Definition
Sequence Diagram
[pic]
Dynamic Profile
For ADT^A05: AccNE_AppAL
For further explanation see, HL7 Acknowledgement Modes, page 15page 13.
Static Definition
Message Level Profile
|ADT |Cardinality |Message Description |
|MSH |[1,1] |Message Header |
|EVN |[1,1] |Event Type |
|PID (1) |[1,1] |Patient Demographics |
|[{ NK1 }] |[0,+] |Next of Kin |
|PV1 (5) |[1,1] |Preadmit Visit Info |
|PV2 (4) |[1,1] |More Preadmit Visit Info |
|[{ AL1 }] |[0,+] |Allergy Info |
Segment Level Profile
In the tabular representation, the fields contained within each supported segment, the data type, and repeat count is defined. Where available, the HL7 table corresponding to the value set for each field is also identified. For further information translation of message symbol definition description to XML DTD form page 16page 13.
Common Segments Definitions
(See Appendix H)
Field Level Profile
ADT_Fields DTD
(See Appendix K)
Content Model Diagram
(See Appendix E)
ADT^A05 Pre-AdmitAPatient DTD
Killdara(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A05(5).NULL(0).NULL(0).1(1)
(See Appendix E)
Value sets taken from HL7 Standard V2.3.1
(See Appendix U)
Data Types DTD
(See Appendix V)
2.6 Update Patient Information (Message Type ADT^A08)
In V2.2 tThe ADT^A08 trigger event is used when any patient information has changed, but no other trigger event has occurred. In V2.3 for example, aAn A08 event can be used to notify the receiving systems of a change of address or a name change. We recommend that the A08 transaction be used to update fields that are not related to any of the other trigger events. The A08 event can include information specific to an episode of care, but it can also be used for demographic information only.
Receiving systems should always evaluate the complete set of NK1 and AL1 segments for changed information in these repeating segments.
The A08 should not be used to change certain fields related to a patient’s identifier, class or location unless the intention is to correct an error.
Use Case
[pic]
Description
This A08 event is used when patient information or demographic information has changed but no other trigger event has occurred.
Actors
Please see Actors ADT overview page 20page 15.
Preconditions
Patient information is added or corrected
Flow of Events
1. A change in the patient file is detected
2. An A08 event notifies the receiving system that a change has occurred
3. Updates are done when warranted, i.e. correction in address error
Post Conditions
An update to the patient file has occurred.
Derives Events
Killdara(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A08(8).NULL(0).NULL(0).1(1)
Dynamic Definition
Sequence Diagram
[pic]
Dynamic Profile
For ADT^A01: AccNe_AppAL
For further explanation see HL7 Acknowledgement Modes page 15page 13.
Static Definition
Message Level Profile
|ADT |Cardinality |Message Description |
|MSH |[1,1] |Message Header |
|EVN |[1,1] |Event Type |
|PID (1) |[1,1] |Patient Demographics |
|[{ NK1 }] |[0,+] |Next of Kin |
|PV1 (1) |[1,1] |Visit Info |
|PV2 (1) |[1,1] |More Visit Info |
|[{ AL1 }] |[0,+] |Allergy Info |
Segment Level Profile
In the tabular representation, the fields contained within each supported segment, the data type, and repeat count is defined. Where available, the HL7 table corresponding to the value set for each field is also identified. For further information translation of message symbol definition description to XML DTD form page 16page 13.
Common Segments Definitions
(See Appendix H)
Field Level Profile
ADT_Fields DTD
(See Appendix K)
Content Model Diagram
(See Appendix F)
ADT^A08_UpdatePatientInformation DTD
Killdara(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A08(8).NULL(0).NULL(0).1(1)
(See Appendix F)
Value sets taken from HL7 Standard V2.3.1
(See Appendix U)
Data Types DTD
(See Appendix V)
2.7 Cancel Admit (Message Type ADT^A11)
In V2.3 fFor “admitted” patients, the A11 event is sent when an A01 (admit/visit notification) event is canceled. For “non-admitted” patients, the A11 event is sent when an A01 (admit/visit notification) event is canceled, either because of an erroneous entry of the A01 event, or because of a decision not to check the patient in for the visit after all.
The field PV1-3 Assigned patient Patient location Location should contain the location the patient was previously admitted to.
Use Case
[pic]
Description
The A11 event is sent when an A01 (admit/visit notification) event is canceled.
Actors
Please see Actors page 20page 15.
Preconditions
An A01 (admit/visit notification) has occurred
Flow of Events
1. An A01 admit/visit notification occurs
2. Due to an erroneous entry or a change of a decision not to admit a patient an A11 cancel admit/visit occurs
Post Conditions
The patient is not admitted
Derives Events
Killdara(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A11(11).NULL(0).NULL(0).1(1)
Dynamic Definition
Sequence Diagram
[pic]
Dynamic Profile
For ADT^A11: AccNe_AppAL
For further explanation see, HL7 Acknowledgement Modes, page 15page 13.
Static Definition
Message Level Profile
|ADT |Cardinality |Message Description |
|MSH |[1,1] |Message Header |
|EVN |[1,1] |Event Type |
|PID (2) |[1,1] |Patient Identification |
|PV1 (2) |[1,1] |Admit Visit Info |
Segment Level Profile
In the tabular representation, the fields contained within each supported segment, the data type, and repeat count is defined. Where available, the HL7 table corresponding to the value set for each field is also identified. For further information translation of message symbol definition description to XML DTD form page 16page 13.
Common Segments Definitions
(See Appendix H)
Field Level Profile
ADT_Fields DTD
(See Appendix K)
Content Model Diagram
(See Appendix G)
ADT^A11_CancelAdmit DTD
Killdara(1).HL7(1).v2_2(4).static-profile(1).ADT(3).A11(11).NULL(0).NULL(0).1(1)
(See Appendix G)
Value sets taken from HL7 Standard V2.3.1
(See Appendix U)
Data Types DTD
(See Appendix V)
3.0 Diagnostic Study Order Overview
Introduction
The Diagnostic Study Order is used for generating orders for clinical observations and diagnostic studies. It could be an order for a service, test or treatment. The message initiates the transmission of information and subsequent actions that can be taken once a new order has been placed. This includes acceptance, cancellation, discontinuation, holding, releasing, and changing the order.
Actors
1. Ordering System – responsible for the order of a service, test or treatment
a. Clinician - Is legally responsible for signing or countersigning all orders that are considered “invasive” i.e. medications, surgery, tests, procedures. Responsible for authorizing orders.
b. Nursing orders – defined in Standards of Care within an organization.
c. Non-medical services – Admission/discharge/transfer (ADT) clerks, maintenance personnel, pharmacists, inventory and storehouse personnel.
2. Filler System – is responsible for fulfilling the order based on the criteria provided by the placer in the order message. In this use case, the dynamic profile of the initiating message requires the filler to send an application acknowledgement (ORR).
What is an order?
1. A health professional writing a note to him/herself or to another health professional to make an observation on a patient at a later date. The placer and filler of a service request may be one and the same.
2. A patient or an authorized agent:
a. Licensed agent - ordering laboratory tests, bedside monitoring, diagnostic imaging, electrocardiograms, and vital signs by a clinician
b. Allied Health Professionals – procedures, surgery, medical equipment, home visits
c. Clerical agent – delivers non-medical services such as meals
Who creates the order?
Who is authorized to order needs to be carefully identified.
1. clinician
2. dentist
3. nursing orders which do not have to be countersigned by a physician
4. social worker for medical devices, splints, antiseptics
The general workflow, which defines the life cycle of a diagnostic study order, involves several trigger events, which reflect a change to an order. These events can be further specialized into the following:
1. New Diagnostic Study Order
2. Diagnostic Study Order Accepted
3. Unable to Accept Diagnostic Study Order
4. Diagnostic Study Order Cancelled (by Filler)
5. Cancel Diagnostic Study Order
6. Diagnostic Study Order Cancelled As Requested
7. Unable to Cancel Diagnostic Study Order
8. Unsolicited Transmission of Observation Results
For each of the above trigger events, there will be a message profile containing:
1. Use case model
2. Dynamic Definition
a. Interaction Model
b. Dynamic Profile
3. Static Definition
a. Message Level Profile
b. Segment Level Profile
c. Field Level Profile
d. Static Profile Identifier
e. XML DTD describing the static message and segment profiles
There will be separate abstract message definitions and field level definitions specified. Each order is associated with a single patient.
Order Request (ORM^O01)
Order Response (ORR^O02)
Use Case – Overview
[pic]
The following DTDs apply to this use case model and must be located in the same directory for parsing:
ORMO01_NewDiagnosticStudyOrder.dtd
ORRO02_DiagnosticStudyOrderAccepted.dtd
ORRO02_UnableToAcceptDiagnosticStudyOrder.dtd
ORRO02_DiagnosticStudyOrderCancelled.dtd
ORMO01_CancelDiagnosticStudyOrder.dtd
ORRO02_DiagnosticStudyOrderCancelledAsRequested.dtd
ORRO02_UnableToCancelDiagnosticStudyOrder.dtd
OrderResult_Fields.dtd
OrderResult_Common_Segments.dtd
DataTypes.dtd
3.1 New Diagnostic Study Order (Message type ORM^O01)
This message requires information, which identifies the patient with whom this order is associated, as well as the patient’s location. In addition, the specific test or study to perform must be specified, along with scheduling information to indicate when the test or study should be done. There may be results of previous tests or studies included with this new order, which provide supporting information, which can be used by the filler of this order.
The NTE segments are used to provide notes related to the observation request or any of the observation results. There may be zero, one or many NTE segments.
Use Case
[pic]
Description
An Ordering System authorizes and places a New Diagnostic Study Order for a patient
Actors
Please see Actors, Diagnostic Study Overview page 43page 38
Preconditions
1. The Ordering System receives a New Diagnostic Study Order
Flow of Events
1. The Ordering System authorizes a New Diagnostic Study Order
2. The Ordering System sends an order notification (ORM) to the appropriate destination
Post Conditions
1. The Filler system was notified of a new Diagnostic Study Order.
Derives Events
Killdara(1).HL7(113883) v2.2 (4)static profile(1)ORM(21).O01(92).
DiagnosticStudyOrder.(1).NewOrder(1)
Dynamic Definition
Sequence Diagram
[pic]
Dynamic Profile
For ORM^O01: … AccNE_AppAL
For further explanation see, HL7 Acknowledgement Modes, page 15page 13.
Static Definition
Message Level Profile
|ORM |Cardinality |Message Description |
|MSH |[1,1] |Message Header |
|PID |[1,1] |Patient Identification |
|PV1 |[1,1] |Patient Visit |
|ORC |[1,1] |Common Order |
|{ |[1,*] |OBR Group |
| OBR |[1,1] |Observation Request |
| [{NTE}] |[0,*] |Notes |
| { |[1,*] |OBX Group |
| OBX |[1,1] |Observation/Result |
| [{NTE}] |[0,*] |Notes |
| } | | |
|} | | |
Segment Level Profile
In the tabular representation, the fields contained within each supported segment, the data type, and repeat count is defined. Where available, the HL7 table corresponding to the value set for each field is also identified. For further information translation of message symbol definition description to XML DTD form page 16page 13.
MSH - Message Header Segment
The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message. For the details of this segment, please refer to Appendix P.
PID - Patient Identification
The PID segment is used by all applications as the primary means of communication patient identification information. This segment contains permanent patient identifying and demographic information. Note that the patient demographic information is included as part of this order message to allow legacy applications which do not support ADT messages to provide the necessary information to the filler application to be able to process the order.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|2 |CK |RE | | |00105 |Patient ID (External ID) |
|3 |CM |R |Y | |00106 |Patient ID (Internal ID) |
|4 |ST |RE |Y | |00107 |Alternate Patient ID |
|5 |PN |R | | |00108 |Patient Name |
|6 |ST |RE | | |00109 |Mother’s Maiden Name |
|7 |TS |RE | | |00110 |Date Of Birth |
|8 |ID |RE | |0001 |00111 |Sex |
|9 |PN |RE |Y | |00112 |Patient Alias |
|10 |ID |RE | |0005 |00113 |Race |
|11 |AD |RE |Y/3 | |00114 |Patient Address |
|13 |TN |RE |Y/3 | |00116 |Phone Number – Home |
|14 |TN |RE |Y/3 | |00117 |Phone Number – Business |
|15 |ST |RE | | |00118 |Primary Language |
|16 |ID |RE | |0002 |00119 |Marital Status |
|17 |ID |RE | |0006 |00120 |Religion |
|18 |CK |RE | | |00121 |Patient Account Number |
|19 |ST |RE | | |00122 |SSN Number – Patient |
|20 |CM |RE | | |00123 |Driver’s Lic Num – Patient |
|23 |ST |RE | | |00126 |Birth Place |
|26 |ID |RE |Y |0171 |00129 |Citizenship |
|27 |CE |RE | |0172 |00130 |Veterans Military Status |
PV1 – Patient Visit
The PV1 segment is used in this message to communicate information regarding the location of the patient.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|3 |CM |RE | | |00133 |Assigned Patient Location |
|6 |CM |RE | | |00136 |Prior Patient Location |
|11 |CM |RE | | |00141 |Temporary Location |
|42 |CM |RE | | |00172 |Pending Location |
|43 |CM |RE | | |00173 |Prior Temporary Location |
ORC - Common Order Segment
The Common Order segment (ORC) is used to identify an order and to transmit data elements that are common to all orders (all types of services that are requested). ORC-1, Order Control, must be specified as “NW”.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|2 |CM |RE | | |00216 |Placer Order Number |
|3 |CM |RE | | |00217 |Filler Order Number |
|4 |CM |RE | | |00218 |Placer Group Number |
|5 |ID |RE | |0038 |00219 |Order Status |
|7 |TQ |RE | | |00221 |Quantity/Timing |
|8 |CM |RE | | |00222 |Parent |
|9 |TS |RE | | |00223 |Date/Time of Transaction |
|10 |CN |RE | | |00224 |Entered By |
|11 |CN |RE | | |00225 |Verified By |
|12 |CN |RE | | |00226 |Ordering Provider |
|13 |CM |RE | | |00227 |Enterer’s Location |
|14 |TN |RE |Y/2 | |00228 |Call Back Phone Number |
|16 |CE |RE | | |00230 |Order Control Code Reason |
|17 |CE |RE | | |00231 |Entering Organization |
OBR – Observation Request Segment
The Observation Request Segment (OBR) is used to transmit information specific to an order for a diagnostic study or observation, physical exam, or assessment.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|2 |CM |RE | | |00216 |Placer Order Number |
|3 |CM |RE | | |00217 |Filler Order Number |
|4 |CE |R | | |00238 |Universal Service ID |
|7 |TS |RE | | |00241 |Observation Date/Time # |
|8 |TS |RE | | |00242 |Observation End Date/Time # |
|9 |CQ |RE | | |00243 |Collection Volume * |
|10 |CN |RE |Y | |00244 |Collector Identifier * |
|11 |ID |RE | |0065 |00245 |Specimen Action Code * |
|12 |CE |RE | | |00246 |Danger Code |
|13 |ST |RE | | |00247 |Relevant Clinical Info. |
|14 |TS |RE | | |00248 |Specimen Received Date/Time * |
|15 |CM |RE | |0070 |00249 |Specimen Source * |
|16 |CN |RE |Y | |00226 |Ordering Provider |
|17 |TN |RE |Y/2 | |00250 |Order Callback Phone Number |
|18 |ST |RE | | |00251 |Placer field 1 |
|19 |ST |RE | | |00252 |Placer field 2 |
|20 |ST |RE | | |00253 |Filler Field 1 + |
|21 |ST |RE | | |00254 |Filler Field 2 + |
|22 |TS |RE | | |00255 |Results Rpt/Status Chng – Date/Time + |
|24 |ID |RE | |0074 |00257 |Diagnostic Serv Sect ID |
|25 |ID |RE | |0123 |00258 |Result Status + |
|26 |CM |RE | | |00259 |Parent Result + |
|29 |CM |RE | | |00261 |Parent Number + |
|30 |ID |RE | |0124 |00262 |Transportation Mode |
|31 |CE |RE |Y | |00263 |Reason For Study |
NTE – Notes Segment
The Notes Segment (NTE) is a common format for sending notes and comments. For the details of this segment, please refer to Appendix P.
OBX – Observation/Result
The Observation/Result Segment (OBX) is used to transmit a single observation fragment. In this message, the OBX carries clinical information needed by the filler to interpret the observation the filler makes.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|2 |ID |R | |0125 |00570 |Value Type |
|3 |CE |R | | |00571 |Observation Identifier |
|4 |ST |RE | | |00572 |Observation Sub-ID |
|5 |* |C | | |00573 |Observation Value |
|6 |CE |RE | | |00574 |Units |
|7 |ST |RE | | |00575 |References Range |
|8 |ID |RE |Y/3 |0078 |00576 |Abnormal Flags |
|11 |ID |R | |0085 |00579 |Observ Result Status |
|14 |TS |RE | | |00582 |Date/Time of the Observation |
|15 |CE |RE | | |00583 |Producer’s ID |
|16 |CN |RE | | |00584 |Responsible Observer |
Field Level Profile
OrderResult_Fields DTD
(See Appendix S)
Content Model Diagram
(See Appendix L)
ORMO01_NewDiagnosticStudyOrder DTD
Killdara(1).HL7(113883) v2.2 (4)static profile(1)ORM(21).O01(92).
DiagnosticStudyOrder.(1).NewOrder(1)
(See Appendix L)
Value sets taken from HL7 Standard V2.3.1
(See Appendix U)
Data Types DTD
(See Appendix V)
3.2 Diagnostic Study Order Accepted (Message Type ORR^O02)
The purpose of thisThis message is to responds to a New Diagnostic Study Order message. It indicates that the filler application received the order request and was able to accept the requested order. The PID segment is used to identify the patient with whom the order is associated. The ORC segment identifies the order that was accepted.
Use Case
[pic]
Description
The Filler System has received an order and accepts the order requested
Actors
Please see Actors, Diagnostic Study Overview, page 43page 38
Preconditions
1. The Filler System receives an order
Flow of Events
1. The Filler System acknowledges receipt of the order notification
2. At the same time the order response (ORR) indicates the filler can complete it
Post Conditions
1. The Filler System acknowledges receipt and accepts to fulfill the New Diagnostic Study Order
Derives Events
Killdara(1).HL7(113883) v2.2 (4)static profile(1)ORR(2.2).O02(9).
DiagnosticStudyOrder.(1).OrderAcceptedAndOK(2)
Dynamic Definition
Sequence Diagram
[pic]
Dynamic Profile
For ORM^O01: AccNE_AppAL
For ORR^O02: AccNE_AppNE
For further explanation see, HL7 Acknowledgement Modes, page 15page 13.
Static Definition
Message Level Profile
|ORR |Cardinality |Message Description |
|MSH |[1,1] |Message Header |
|MSA |[1,1] |Message Acknowledgement |
|PID |[1,1] |Patient Identification |
|ORC |[1,1] |Common Order |
Segment Level Profile
In the tabular representation, the fields contained within each supported segment, the data type, and repeat count is defined. Where available, the HL7 table corresponding to the value set for each field is also identified. For further information translation of message symbol definition description to XML DTD form page16.
MSH - Message Header Segment
The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message. For the details of this segment, please refer to Appendix P.
MSA - Message Acknowledgement Segment
The MSA segment contains information sent while acknowledging another message. For the details of this segment, please refer to Appendix P.
PID - Patient Identification
The PID segment is used in this message to communicate patient identification information.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|3 |CM |R |Y | |00106 |Patient ID (Internal ID) |
|5 |PN |R | | |00108 |Patient Name |
|6 |ST |RE | | |00109 |Mother’s Maiden Name |
|7 |TS |RE | | |00110 |Date Of Birth |
|8 |ID |RE | |0001 |00111 |Sex |
|11 |AD |RE |Y/3 | |00114 |Patient Address |
|19 |ST |RE | | |00122 |SSN Number – Patient |
|23 |ST |RE | | |00126 |Birth Place |
ORC - Common Order Segment
The Common Order segment (ORC) is used to identify the specific order, which was accepted by the filler. ORC-1, Order Control, must be specified as “OK”.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|2 |CM |RE | | |00216 |Placer Order Number |
|3 |CM |RE | | |00217 |Filler Order Number |
Field Level Profile
OrderResult_Fields DTD
(See Appendix S)
Content Model Diagram
(See Appendix M)
ORRO02_DiagnosticStudyOrderAccepted DTD
Killdara(1).HL7(113883) v2.2 (4)static profile(1)ORR(22).O02(93).
DiagnosticStudyOrder.(1).OrderAcceptedAndOK(2)
(See Appendix M)
Value sets taken from HL7 Standard V2.3.1
(See Appendix U)
Data Types DTD
(See Appendix V)
3.3 Unable to Accept Diagnostic Study Order (Message Type ORR^O02)
This is the response message sent from the Filler System to indicate that the diagnostic study order identified in this message could not be accepted as specified. The order filler application may not be able to accept the new order for a number of reasons, including not having sufficient resources available to perform the requested order, there may be a conflict in the scheduling of the order relative to other existing orders, or the filler may not be capable of performing the requested order. In these cases, the filler application would respond to the new order request, specifying the new order, which cannot be accepted (in the ORC segment) and providing the reason why the order was not accepted (error condition MSA-6).
Use Case
[pic]
Description
The Filler System has received the order and is unable to accept the order requested
Actors
Please see Actors, Diagnostic Study Overview, page 43page 38
Preconditions
The Filler System receives an order
Flow of Events
1. The Filler System acknowledges receipt of the order notification
2. At the same time the order response (ORR) indicates it is unable to complete the order
Post Conditions
1. The Filler System acknowledges receipt and indicates that it is unable to fulfill the new Diagnostic Study Order
Derives Events
Killdara(1).HL7(113883) v2.2 (4)static profile(1)ORR(22).O02(93).
DiagnosticStudyOrder.(1).UnableToAcceptOrder(3)
Dynamic Definition
Sequence Diagram
[pic]
Dynamic Profile
For ORM^O01: AccNE_AppAL
For ORR^O02: AccNE_AppNE
For further explanation see, HL7 Acknowledgement Modes, page 15page 13.
Static Definition
Message Level Profile
|ORR |Cardinality |Message Description |
|MSH |[1,1] |Message Header |
|MSA |[1,1] |Message Acknowledgement |
|PID |[1,1] |Patient Identification |
|ORC |[1,1] |Common Order |
Segment Level Profile
In the tabular representation, the fields contained within each supported segment, the data type, and repeat count is defined. Where available, the HL7 table corresponding to the value set for each field is also identified. For further information translation of message symbol definition description to XML DTD form page 16page 13
MSH - Message Header Segment
The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message. For the details of this segment, please refer to Appendix P.
MSA - Message Acknowledgement Segment
The MSA segment contains information sent while acknowledging another message. For the details of this segment, please refer to Appendix P.
PID - Patient Identification
The PID segment is used in this message to communicate patient identification information.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|3 |CM |R |Y | |00106 |Patient ID (Internal ID) |
|5 |PN |R | | |00108 |Patient Name |
|6 |ST |RE | | |00109 |Mother’s Maiden Name |
|7 |TS |RE | | |00110 |Date Of Birth |
|8 |ID |RE | |0001 |00111 |Sex |
|11 |AD |RE |Y/3 | |00114 |Patient Address |
|19 |ST |RE | | |00122 |SSN Number – Patient |
|23 |ST |RE | | |00126 |Birth Place |
ORC - Common Order Segment
The Common Order segment (ORC) is used to identify the specific order, which was unable to be accepted by the filler. ORC-1, Order Control, must be specified as “UA”.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|2 |CM |RE | | |00216 |Placer Order Number |
|3 |CM |RE | | |00217 |Filler Order Number |
Field Level Profile
OrderResult_Fields DTD
(See Appendix S)
Content Model Diagram
(See Appendix M)
ORRO02_UnableToAcceptDiagnosticStudyOrder DTD
Killdara(1).HL7(113883) v2.2 (4)static profile(1)ORR(22).O02(93).
DiagnosticStudyOrder.(1).UnableToAcceptOrder(3)
(See Appendix M)
Value sets taken from HL7 Standard V2.3.1
(See Appendix U)
Data Types DTD
(See Appendix V)
3.4 Diagnostic Study Order Cancelled by Filler (Message Type ORR^O02)
This message is sent from the filler to indicate that the diagnostic study order identified in this message has been cancelled. Note that this is an unsolicited message, as the receiver of this message may not have sent the request to cancel this order.
The information contained in this message includes the identification of the patient associated with the order, and the specific order that was cancelled. Additionally, the specific reason for cancellation of the order would be specified in MSA-6.
Use Case
[pic]
Description
The Filler System has received the order and indicates that the diagnostic study order identified in this message has been cancelled
Actors
Please see Actors, Diagnostic Study Overview, page 43page 38
Preconditions
The Filler System receives an order
Flow of Events
1. The Filler System acknowledges receipt of the order notification
2. At the same time the order response (ORR) indicates it is unable to fill the order
3. The filler has cancelled the order
Post Conditions
1. The Filler System acknowledges receipt and has cancelled the New Diagnostic Study Order
Derives Events
Killdara(1).HL7(113883) v2.2 (4)static profile(1)ORR(22).O02(93).
DiagnosticStudyOrder.(1).OrderCancelled(5)
Dynamic Definition
Sequence Diagram
[pic]
Dynamic Profile
For ORM^O01: AccNE_AppAL
For ORR^O02: AccNE_AppNE
For further explanation see, HL7 Acknowledgement Modes, page 15page 13.
Static Definition
Message Level Profile
|ORR |Cardinality |Message Description |
|MSH |[1,1] |Message Header |
|MSA |[1,1] |Message Acknowledgement |
|PID |[1,1] |Patient Identification |
|ORC |[1,1] |Common Order |
Segment Level Profile
In the tabular representation, the fields contained within each supported segment, the data type, and repeat count is defined. Where available, the HL7 table corresponding to the value set for each field is also identified. For further information translation of message symbol definition description to XML DTD form page 16page 13.
MSH - Message Header Segment
The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message. For the details of this segment, please refer to Appendix P.
MSA - Message Acknowledgement Segment
The MSA segment contains information sent while acknowledging another message. For the details of this segment, please refer to Appendix P.
ORC - Common Order Segment
The Common Order segment (ORC) identifies the order, which was cancelled. ORC-1, Order Control, must be specified as “OC”.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|2 |CM |RE | | |00216 |Placer Order Number |
|3 |CM |RE | | |00217 |Filler Order Number |
PID - Patient Identification
The PID segment is used in this message to communicate patient identification information.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|3 |CM |R |Y | |00106 |Patient ID (Internal ID) |
|5 |PN |R | | |00108 |Patient Name |
|6 |ST |RE | | |00109 |Mother’s Maiden Name |
|7 |TS |RE | | |00110 |Date Of Birth |
|8 |ID |RE | |0001 |00111 |Sex |
|11 |AD |RE |Y/3 | |00114 |Patient Address |
|19 |ST |RE | | |00122 |SSN Number – Patient |
|23 |ST |RE | | |00126 |Birth Place |
Field Level Profile
OrderResult_Fields DTD
(See Appendix S)
Content Model Diagram
(See Appendix M)
ORRO02_DiagnosticStudyOrderCancelled (by Filler) DTD
Killdara(1).HL7(113883) v2.2 (4)static profile(1)ORR(22).O02(93).
DiagnosticStudyOrder.(1).OrderCancelled(5)
(see Appendix M)
Value sets taken from HL7 Standard V2.3.1
(See Appendix U)
Data Types DTD
(See Appendix V)
3.5 Cancel Diagnostic Study Order (Message Type ORM^O01)
This is a request to cancel an existing order, which has already been delivered from the placer to the filler. A cancellation is a request not to do a previously ordered service. Confirmation of the cancellation request is provided by the filler.
The NTE segment may be used to provide notes related to any of the observation results segments. There may be zero, one or many NTE segments.
Use Case
[pic]
Description:
The Ordering System cancels an existing order
Actors
Please see Actors, Diagnostic Study Overview, page 43page 38
Preconditions
1. The Filler System receives an order for services
Flow of Events
1. The Filler System receives a New Diagnostic Study Order from the Ordering System (ORM)
2. The Ordering System sends an order cancellation (ORM) to cancel the previous order
Post Conditions
1. The Filler System provides confirmation of the cancellation request (ORM) to the Ordering System
Derives Events
Killdara(1).HL7(113883) v2.2 (4)static profile(1)ORM(21).O01(92).
DiagnosticStudyOrder.(1).CancelOrderRequest(4)
Dynamic Definition
Sequence Diagram
[pic]
Dynamic Profile
For ORM^O01: AccNE_AppAL
For further explanation see, HL7 Acknowledgement Modes, page 15page 13.
Static Definition
Message Level Profile
|ORM |Cardinality |Message Description |
|MSH |[1,1] |Message Header |
|PID |[1,1] |Patient Identification (Demographic Information) |
|PV1 |[1,1] |Patient Visit (Location Visit Information) |
|ORC |[1,1] |Common Order |
|{ |[1,*] |OBR Group |
| OBR |[1,1] |Observation Request |
| { |[1,*] |OBX Group |
| OBX |[1,1] |Observation/Result |
| [{NTE}] |[0,*] |Notes |
| } | | |
|} | | |
Segment Level Profile
In the tabular representation, the fields contained within each supported segment, the data type, and repeat count is defined. Where available, the HL7 table corresponding to the value set for each field is also identified. For further information translation of message symbol definition description to XML DTD form page 16page 13.
MSH - Message Header Segment
The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message. For the details of this segment, please refer to Appendix P.
PID - Patient Identification
The PID segment is used by all applications as the primary means of communicating patient identification information. This segment contains patient identification and demographic information. Note that the patient demographic information is included as part of this order message to allow legacy applications which do not support ADT messages to provide the necessary information to the filler application to be able to process the order.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|2 |CK |RE | | |00105 |Patient ID (External ID) |
|3 |CM |R |Y | |00106 |Patient ID (Internal ID) |
|4 |ST |RE |Y | |00107 |Alternate Patient ID |
|5 |PN |R | | |00108 |Patient Name |
|6 |ST |RE | | |00109 |Mother’s Maiden Name |
|7 |TS |RE | | |00110 |Date Of Birth |
|8 |ID |RE | |0001 |00111 |Sex |
|9 |PN |RE |Y | |00112 |Patient Alias |
|10 |ID |RE | |0005 |00113 |Race |
|11 |AD |RE |Y/3 | |00114 |Patient Address |
|13 |TN |RE |Y/3 | |00116 |Phone Number – Home |
|14 |TN |RE |Y/3 | |00117 |Phone Number – Business |
|15 |ST |RE | | |00118 |Primary Language |
|16 |ID |RE | |0002 |00119 |Marital Status |
|17 |ID |RE | |0006 |00120 |Religion |
|18 |CK |RE | | |00121 |Patient Account Number |
|19 |ST |RE | | |00122 |SSN Number – Patient |
|20 |CM |RE | | |00123 |Driver’s License Number – Patient |
|23 |ST |RE | | |00126 |Birth Place |
|26 |ID |RE |Y |0171 |00129 |Citizenship |
|27 |CE |RE | |0172 |00130 |Veterans Military Status |
PV1 – Patient Visit
The PV1 segment is used in this message to communicate information regarding the location of the patient.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|3 |CM |RE | | |00133 |Assigned Patient Location |
|6 |CM |RE | | |00136 |Prior Patient Location |
|11 |CM |RE | | |00141 |Temporary Location |
|42 |CM |RE | | |00172 |Pending Location |
|43 |CM |RE | | |00173 |Prior Temporary Location |
ORC - Common Order Segment
The Common Order segment (ORC) identifies the order to cancel. ORC-1, Order Control, must be specified as “CA”.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|2 |CM |RE | | |00216 |Placer Order Number |
|3 |CM |RE | | |00217 |Filler Order Number |
|4 |CM |RE | | |00218 |Placer Group Number |
|5 |ID |RE | |0038 |00219 |Order Status |
|7 |TQ |RE | | |00221 |Quantity/Timing |
|8 |CM |RE | | |00222 |Parent |
|9 |TS |RE | | |00223 |Date/Time of Transaction |
|10 |CN |RE | | |00224 |Entered By |
|11 |CN |RE | | |00225 |Verified By |
|12 |CN |RE | | |00226 |Ordering Provider |
|13 |CM |RE | | |00227 |Enterer’s Location |
|14 |TN |RE |Y/2 | |00228 |Call Back Phone Number |
|16 |CE |RE | | |00230 |Order Control Code Reason |
|17 |CE |RE | | |00231 |Entering Organization |
OBR – Observation Request Segment
The Observation Request Segment (OBR) is used to transmit information specific to the order to cancel.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|2 |CM |RE | | |00216 |Placer Order Number |
|3 |CM |RE | | |00217 |Filler Order Number |
|4 |CE |R | | |00238 |Universal Service ID |
|7 |TS |RE | | |00241 |Observation Date/Time # |
|8 |TS |RE | | |00242 |Observation End Date/Time # |
|9 |CQ |RE | | |00243 |Collection Volume * |
|10 |CN |RE |Y | |00244 |Collector Identifier * |
|11 |ID |RE | |0065 |00245 |Specimen Action Code * |
|12 |CE |RE | | |00246 |Danger Code |
|13 |ST |RE | | |00247 |Relevant Clinical Info. |
|14 |TS |RE | | |00248 |Specimen Received Date/Time * |
|15 |CM |RE | |0070 |00249 |Specimen Source * |
|16 |CN |RE |Y | |00226 |Ordering Provider |
|17 |TN |RE |Y/2 | |00250 |Order Callback Phone Number |
|18 |ST |RE | | |00251 |Placer field 1 |
|19 |ST |RE | | |00252 |Placer field 2 |
|20 |ST |RE | | |00253 |Filler Field 1 + |
|21 |ST |RE | | |00254 |Filler Field 2 + |
|22 |TS |RE | | |00255 |Results Rpt/Status Chng – Date/Time + |
|24 |ID |RE | |0074 |00257 |Diagnostic Serv Sect ID |
|25 |ID |RE | |0123 |00258 |Result Status + |
|26 |CM |RE | | |00259 |Parent Result + |
|29 |CM |RE | | |00261 |Parent Number + |
|30 |ID |RE | |0124 |00262 |Transportation Mode |
|31 |CE |RE |Y | |00263 |Reason For Study |
OBX – Observation/Result
The Observation/Result Segment (OBX) is used to transmit a single observation or observation fragment. In this message, the OBX carries clinical information needed by the filler to interpret the observation the filler makes. For example, an OBX is needed to report the inspired oxygen on an order for a blood oxygen to a blood gas lab, or to report the menstrual phase information which should be included on an order for a pap smear to a cytology lab.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|3 |CE |R | | |00571 |Observation Identifier |
|4 |ST |RE | | |00572 |Observation Sub-ID |
|5 |* |C | | |00573 |Observation Value |
|6 |CE |RE | | |00574 |Units |
|11 |ID |R | |0085 |00579 |Observ Result Status |
|14 |TS |RE | | |00582 |Date/Time of the Observation |
*The following is addressed at the application level only. The Observation Value (OBX.5) has no data type assigned. The data type is linked to Value Type (OBX.2) in an application. If the Observation Result Status (OBX.11) is NOT set to “X” by the sender, the data type will reflect this in the Value Type (OBX.2). If Observation Result Status (OBX.11) is set to “X” that means that the receiving application should ignore the Observation Result Status (OBX.11) and use the Abnormal Flags (OBX.8).
NTE – Notes Segment
The Notes Segment (NTE) is a common format for sending notes and comments. For the details of this segment, please refer to Appendix P.
Field Level Profile
OrderResult_Fields DTD
(See Appendix S)
Content Model Diagram
(See Appendix N)
ORMO01_CancelDiagnosticStudyOrder DTD
Killdara(1).HL7(113883) v2.2 (4)static profile(1)ORM(21).O01(92).
DiagnosticStudyOrder.(1).CancelOrderRequest(4)
(See Appendix N)
Value sets taken from HL7 Standard V2.3.1
(See Appendix U)
Data Types DTD
(See Appendix V)
3.6 Diagnostic Study Order Cancelled As Requested (Message Type ORR^O02)
This is the response message sent from the filler to confirm that the diagnostic study order identified in this message has been cancelled as requested. This message is a response to the Cancel Diagnostic Study Order message.
The contents of this message include the identification of the specific order, which was cancelled and the patient with which the order was associated.
Use Case
[pic]
Description
The Filler System confirms that the diagnostic study order identified in this message has been cancelled as requested
Actors
Please see Actors, Diagnostic Study Overview, page 43page 38
Preconditions
1. The Filler System receives a cancellation order
Flow of Events
1. The Ordering System sends a cancellation order (ORM)
2. The Filler System sends an order response (ORR) indicating the filler has cancelled the order as requested
Post Conditions
The Ordering System was notified that the Filler has cancelled the Diagnostic Study Order as requested and will not fulfill the new Diagnostic Study Order
Derives Events
Killdara(1).HL7(113883) v2.2 (4)static profile(1)ORR(22).O02(93).
DiagnosticStudyOrder.(1).CancelledAsRequested(6)
Dynamic Definition
Sequence Diagram
[pic]
[pic]
Dynamic Profile
For ORM^O01: AccNE_AppAL
For ORR^O02: AccNE_AppNE
For further explanation see, HL7 Acknowledgement Modes, page 15page 13.
Static Definition
Message Level Profile
|ORR |Cardinality |Message Description |
|MSH |[1,1] |Message Header |
|MSA |[1,1] |Message Acknowledgement |
|PID |[1,1] |Patient Identification |
|ORC |[1,1] |Common Order |
Segment Level Profile
In the tabular representation, the fields contained within each supported segment, the data type, and repeat count is defined. Where available, the HL7 table corresponding to the value set for each field is also identified. For further information translation of message symbol definition description to XML DTD form page 16page 13.
MSH - Message Header Segment
The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message. For the details of this segment, please refer to Appendix P.
MSA - Message Acknowledgement Segment
The MSA segment contains information sent while acknowledging another message. For the details of this segment, please refer to Appendix P.
ORC - Common Order Segment
The Common Order segment (ORC) identifies the order which was cancelled. ORC-1, Order Control, must be specified as “CR”.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|2 |CM |RE | | |00216 |Placer Order Number |
|3 |CM |RE | | |00217 |Filler Order Number |
PID - Patient Identification
The PID segment is used in this message to communicate patient identification information.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|3 |CM |R |Y | |00106 |Patient ID (Internal ID) |
|5 |PN |R | | |00108 |Patient Name |
|6 |ST |RE | | |00109 |Mother’s Maiden Name |
|7 |TS |RE | | |00110 |Date Of Birth |
|8 |ID |RE | |0001 |00111 |Sex |
|11 |AD |RE |Y/3 | |00114 |Patient Address |
|19 |ST |RE | | |00122 |SSN Number – Patient |
|23 |ST |RE | | |00126 |Birth Place |
Field Level Profile
OrderResult_Fields DTD
(See Appendix S)
Content Model Diagram
(See Appendix M)
ORRO02_DiagnosticStudyOrderCancelledAsRequested DTD
Killdara(1).HL7(113883) v2.2 (4)static profile(1)ORR(22).O02(93).
DiagnosticStudyOrder.(1).CancelledAsRequested(6)
(See Appendix M)
Value sets taken from HL7 Standard V2.3.1
(See Appendix U)
Data Types DTD
(See Appendix V)
3.7 Unable to Cancel Diagnostic Study Order (Message Type ORR^O02)
This is the response message sent from the filler to indicate that the request to cancel the diagnostic study order identified in this message could not be completed. The filler will send this message when the ordered service is at a point where the filler cannot cancel it or when the local rules prevent cancellation by the filler.
The content of this message includes the specific order that was to be cancelled and the identification of the patient with which this order was associated. In addition, the reason why this order could not be cancelled will be identified (using the MSA-6).
Use Case
Description
The Filler System has received the cancellation order and is unable to cancel the order requested
Actors
Please see Actors, Diagnostic Study Overview, page 43page 38
Preconditions
The Filler system receives a cancellation order
Flow of Events
1. The Ordering System sends a cancellation order (ORM)
2. The Filler System sends an order response (ORR) indicating the filler is unable to cancel the order as requested
Post Conditions
The Ordering System was notified that the Filler is unable to cancel the Diagnostic Study Order
Derives Events
Killdara(1).HL7(113883) v2.2 (4)static profile(1)ORR(22).O02(93).
DiagnosticStudyOrder.(1).UnableToCancel(7)
Dynamic Definition
Sequence Diagram
[pic]
[pic]
Dynamic Profile
For ORM^O01: AccNE_AppAL
For ORR^O02: AccNE_AppNE
For further explanation see, HL7 Acknowledgement Modes, page 15page 13.
Static Definition
Message Level Profile
|ORR |Cardinality |Message Description |
|MSH |[1,1] |Message Header |
|MSA |[1,1] |Message Acknowledgement |
|PID |[1, 1] |Patient Identification |
|ORC |[1,1] |Common Order |
Segment Level Profile
In the tabular representation, the fields contained within each supported segment, the data type, and repeat count is defined. Where available, the HL7 table corresponding to the value set for each field is also identified. For further information translation of message symbol definition description to XML DTD form page 16page 13.
MSH - Message Header Segment
The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message. For the details of this segment, please refer to Appendix P.
MSA - Message Acknowledgement Segment
The MSA segment contains information sent while acknowledging another message. For the details of this segment, please refer to Appendix P.
PID - Patient Identification
The PID segment is used in this message to communicate patient identification information.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|3 |CM |R |Y | |00106 |Patient ID (Internal ID) |
|5 |PN |R | | |00108 |Patient Name |
|6 |ST |RE | | |00109 |Mother’s Maiden Name |
|7 |TS |RE | | |00110 |Date Of Birth |
|8 |ID |RE | |0001 |00111 |Sex |
|11 |AD |RE |Y/3 | |00114 |Patient Address |
|19 |ST |RE | | |00122 |SSN Number – Patient |
|23 |ST |RE | | |00126 |Birth Place |
ORC - Common Order Segment
The Common Order segment (ORC), which could not be canceled ORC-1, Order Control, must be specified as “UC”.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|2 |CM |RE | | |00216 |Placer Order Number |
|3 |CM |RE | | |00217 |Filler Order Number |
Field Level Profile
OrderResult_Fields DTD
(See Appendix S)
Content Model Diagram
(See Appendix M)
ORRO02_UnableToCancelDiagnosticStudyOrder DTD
Killdara(1).HL7(113883) v2.2 (4)static profile(1)ORR(22).O02(93).
DiagnosticStudyOrder.(1).UnableToCancel(7)
(See Appendix M)
Value sets taken from HL7 Standard V2.3.1
(See Appendix U)
Data Types DTD
(See Appendix V)
3.8 Unsolicited Transmission of Observation Results (Message Type ORU^RO1)
Individual observations are transmitted as separate logical entities, and within each entity, separate fields are defined for identifying the observation, its values, units, and normal ranges such that the receiving system can “understand,” reorganize, and /or react to the contents of the messages.
The unsolicited mode of transmitting observations is used primarily to transmit the values of new observations. The ordering system sends a request to the filler system to make an observation. Using the unsolicited mode, the filler system returns the value of an observation as soon as it is available. The results can be broadcasted to systems other than the ordering system, for example an archival medical record system.
Transmission of Observation Results (Message Type ORU^R01)
In the ORU^R01 the segments identify: the patient, the order, the specimen and the test results. Examples of results could be narrative reports from services such as Radiology usually consist of a number of sub-components (e.g., a chest x-ray report may consist of a description, an impression, and a recommendation). Other studies, such as echocardiograms, contain analogous components, as well as numeric observations (e.g., left ventricular and diastolic diameter). Surgical pathology reports may contain information about multiple specimens and reports: the anatomic source, the gross description, the microscopic description, and a diagnostic impression for each specimen.
Each component of a narrative report is treated as a separate "test" or observation. For example a CHEM12 is transmitted as an order segment (OBR) plus 12 OBX segments, a chest x-ray would be transmitted as an order (OBR) segment plus three OBX segments, one for the description, one for the impression, and one for the recommendations. Similarly, an EKG report would be transmitted as an order segment (OBR), two OBX segments for the impression and recommendation, and additional OBX segments for each EKG measurement, e.g. the PR interval, QR interval, QRS axis, and so on.
Use Case
[pic]
Description
The unsolicited mode of transmitting observation results to the ordering system plus other receivers designated by the application
Actors
Please see Actors, Diagnostic Study Overview, page 43page 38
Preconditions
The filler System has fulfilled the request for the completion of a New Diagnostic Study Order
Flow of Events
1. Using the unsolicited mode, the filler system returns the value of an observation as soon as it is available
Post Conditions
1. The Receiver System stores and displays the results to the users as needed
Derives Events
{Killdara hl7 (113883) v2.2(4) static profile (1) ORU (23) R01 (112) null (0) null (0) v1(1)}
Dynamic Definition
Sequence Diagram
[pic]
[pic]
Dynamic Profile
For ORU^R01: AccNE_AppNE
For further explanation see, HL7 Acknowledgement Modes, page 15page 13.
Static Definition
Message Level Profile
|ORU |Cardinality |Message Description |
|MSH |[1,1] |Message Header |
|PID |[1,1] |Patient Identification (Demographic Information) |
| [{NTE}] |[0, *] |Notes |
| [PV1] |[0,1] |Patient Visit (Location Visit Information) |
|ORC |[1,1] |Common Order |
|{ |[1,*] |OBR Group |
| OBR |[1,1] |Observation Request |
| [{NTE}] |[0,*] |Notes |
|{ |[1,*] |OBX Group |
| OBX |[1,1] |Observation/Result |
| [{NTE}] |[0,*] |Notes |
| } | |End of Result Group |
|} | |End of Observation Group |
NOTE: The Observation Group and the Result Group will not appear in the DTD as a separate ELEMENT but will be represented as nested structures.
The NTE segments are used to provide notes with the immediately preceding segment. In this message, NTE segments are allowed after the OBR segment to describe the general observation header information and after each OBX segment to describe each separate observation. In each case, there may be zero, or more NTE segments.
Segment Level Profile
In the tabular representation, the fields contained within each supported segment, the data type, and repeat count is defined. Where available, the HL7 table corresponding to the value set for each field is also identified. For further information see translation of HL7 message field cardinality to XML DTD form page 16page 13.
OBR – Observation Request Segment
In the reporting of clinical data, the OBR serves as the group header. It identifies the observation set and includes relevant ordering information when that applies. It contains many of the attributes that usually apply to all of the included observations. It includes a field that identifies a particular battery (or panel or set) of observations (e.g., electrolytes, vital signs or Admission). The observation set is referred to as the battery. The battery usually corresponds to the entity that is ordered or performed as a unit.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|2 |CM |RE | | |00216 |Placer Order Number |
|3 |CM |RE | | |00217 |Filler Order Number |
|4 |CE |R | | |00238 |Universal Service ID |
|7 |TS |RE | | |00241 |Observation Date/Time # |
|8 |TS |RE | | |00242 |Observation End Date/Time # |
|9 |CQ |RE | | |00243 |Collection Volume * |
|10 |CN |RE |Y | |00244 |Collector Identifier * |
|11 |ID |RE | |0065 |00245 |Specimen Action Code * |
|12 |CE |RE | | |00246 |Danger Code |
|13 |ST |RE | | |00247 |Relevant Clinical Info. |
|14 |TS |RE | | |00248 |Specimen Received Date/Time * |
|15 |CM |RE | |0070 |00249 |Specimen Source * |
|16 |CN |RE |Y | |00226 |Ordering Provider |
|17 |TN |RE |Y/2 | |00250 |Order Callback Phone Number |
|18 |ST |RE | | |00251 |Placer field 1 |
|19 |ST |RE | | |00252 |Placer field 2 |
|20 |ST |RE | | |00253 |Filler Field 1 + |
|21 |ST |RE | | |00254 |Filler Field 2 + |
|22 |TS |RE | | |00255 |Results Rpt/Status Chng – Date/Time + |
|24 |ID |RE | |0074 |00257 |Diagnostic Serv Sect ID |
|25 |ID |RE | |0123 |00258 |Result Status + |
|26 |CM |RE | | |00259 |Parent Result + |
|29 |CM |RE | | |00261 |Parent Number + |
|30 |ID |RE | |0124 |00262 |Transportation Mode |
|31 |CE |RE |Y | |00263 |Reason For Study |
OBX - Observation/Result Segment
The OBX segment is used to transmit a single observation or observation fragment. It represents the smallest indivisible unit of a message.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|2 |ID |R | |0125 |00570 |Value Type |
|3 |CE |R | | |00571 |Observation Identifier |
|4 |ST |RE | | |00572 |Observation Sub-ID |
|5 |* |RE | | |00573 |Observation Value |
|6 |CE |RE | | |00574 |Units |
|7 |ST |RE | | |00575 |References Range |
|8 |ID |RE |Y/3 |0078 |00576 |Abnormal Flags |
|11 |ID |R | |0085 |00579 |Observ Result Status |
|14 |TS |RE | | |00582 |Date/Time of the Observation |
|15 |CE |RE | | |00583 |Producer’s ID |
|16 |CN |RE | | |00584 |Responsible Observer |
*The following is addressed at the application level only. The Observation Value (OBX.5) has no data type assigned. The data type is linked to Value Type (OBX.2) in an application. If the Observation Result Status (OBX.11) is NOT set to “X” by the sender, the data type will reflect this in the Value Type (OBX.2). If Observation Result Status (OBX.11) is set to “X” that means that the receiving application should ignore the Observation Result Status (OBX.11) and use the Abnormal Flags (OBX.8).
ORC - Common Order Segment
The Common Order segment (ORC) is used to transmit data elements that are common to all of the observations included in this message. The Order Control (ORC-1) field must be set to the value “RE” to indicate “results are to follow”. This is used to indicate that these results have been generated as a result of some order, as identified by ORC-2 and/or ORC-3. Note that these fields may be “empty” if these results are not associated with an order.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|2 |CM |RE | | |00216 |Placer Order Number |
|3 |CM |RE | | |00217 |Filler Order Number |
|4 |CM |RE | | |00218 |Placer Group Number |
|5 |ID |RE | |0038 |00219 |Order Status |
|7 |TQ |RE | | |00221 |Quantity/Timing |
|8 |CM |RE | | |00222 |Parent |
|9 |TS |RE | | |00223 |Date/Time of Transaction |
|10 |CN |RE | | |00224 |Entered By |
|11 |CN |RE | | |00225 |Verified By |
|12 |CN |RE | | |00226 |Ordering Provider |
|13 |CM |RE | | |00227 |Enterer’s Location |
|14 |TN |RE |Y/2 | |00228 |Call Back Phone Number |
|16 |CE |RE | | |00230 |Order Control Code Reason |
|17 |CE |RE | | |00231 |Entering Organization |
PID - Patient Identification
The PID segment is used to specify patient identification information and patient demographic information.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|2 |CK |RE | | |00105 |Patient ID (External ID) |
|3 |CM |R |Y | |00106 |Patient ID (Internal ID) |
|4 |ST |RE |Y | |00107 |Alternate Patient ID |
|5 |PN |R | | |00108 |Patient Name |
|6 |ST |RE | | |00109 |Mother’s Maiden Name |
|7 |TS |RE | | |00110 |Date Of Birth |
|8 |ID |RE | |0001 |00111 |Sex |
|9 |PN |RE |Y | |00112 |Patient Alias |
|10 |ID |RE | |0005 |00113 |Race |
|11 |AD |RE |Y/3 | |00114 |Patient Address |
|13 |TN |RE |Y/3 | |00116 |Phone Number – Home |
|14 |TN |RE |Y/3 | |00117 |Phone Number – Business |
|15 |ST |RE | | |00118 |Primary Language |
|16 |ID |RE | |0002 |00119 |Marital Status |
|17 |ID |RE | |0006 |00120 |Religion |
|18 |CK |RE | | |00121 |Patient Account Number |
|19 |ST |RE | | |00122 |SSN Number – Patient |
|20 |CM |RE | | |00123 |Driver’s Lic Num – Patient |
|23 |ST |RE | | |00126 |Birth Place |
|26 |ID |RE |Y |0171 |00129 |Citizenship |
|27 |CE |RE | |0172 |00130 |Veterans Military Status |
PV1 - Patient Visit
The PV1 segment is used to specify patient location information.
|SEQ |DT |R/O |RP/# |TBL# |ITEM# |ELEMENT NAME |
|3 |CM |RE | | |00133 |Assigned Patient Location |
|6 |CM |RE | | |00136 |Prior Patient Location |
|11 |CM |RE | | |00141 |Temporary Location |
|42 |CM |RE | | |00172 |Pending Location |
|43 |CM |RE | | |00173 |Prior Temporary Location |
Field Level Profile
OrderResult_Fields DTD
(See Appendix S)
Content Model Diagram
(See Appendix O)
ORUR01_UnsolicitedTransmissionOfObservationResults DTD
{Killdara hl7 (113883) v2.2(4) static profile (1) ORU (23) R01 (112) null (0) null (0) v1(1)}
(See Appendix O)
Value sets taken from HL7 Standard V2.3.1
(See Appendix U)
Data Types DTD
(See Appendix V)
4.0 Appendices
4.1 Appendix A
Admit Patient Content Model Diagram
[pic]
ADTA01_AdmitPatient DTD
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- preventing alcohol tobacco and other substance exposed
- c p service clinician s guide
- ob gyn student study guide
- health data courier application guide
- a 34 year old woman comes to the clinic because of left
- university of toronto
- quarterly reporting template united nations development
- v2 8 chapter 2c control code tables
Related searches
- health data analyst job description
- health guide usa license lookup
- medical courier jobs near me
- xps courier tracking
- tci freight courier tracking
- tci express courier tracking online
- ottumwa courier newspaper ottumwa iowa
- ottumwa courier police reports
- health data sets
- why is health data important
- quest diagnostics courier pickup
- health data sets in excel