S02 ATTACHMENT D.23 - VISTA_PACS_HL7_PROFILE_1_2S.pdf

Profiles for HL7 Messages from VistA to Commercial PACS Including Business and Functional Requirements

Version: 1.2 Date: 5 September 2008

Document History

Date Description

5-Sep-08 This document (Version 1.2)

29-Mar-06 Version 1.1

21-Nov-05 Version 1.0

Profiles for VistA HL7 Messages i

Table of Contents

Foreword........................................................................................................................... xi

Organization of This Document ..................................................................................... xi

Changes for Version 1.2 ................................................................................................ xiii

Introduction: Basic Data Sets ....................................................................................... xv

0.1 Basic Patient Data Set........................................................................... xv

0.2 Basic Visit Data Set ............................................................................. xvi

0.3 Basic Order Data Set .......................................................................... xvii

0.4 Basic Report Data Set ........................................................................... xx

Terminology.................................................................................................................... xxi

1 Patient Registration Profile

1.1 Use Case

1.1.1 Scope

1.1.2 Actors and Roles

1.2 Interactions

1.3 Dynamic Definition

1.3.1 Patient Registration Message (ADT)

1.3.1.1 ADT Message Received – ICN Not Found

1.3.1.2 ADT Received for Existing ICN (Non-Update, Non-Merge)

1.3.1.3 ADT Received for Sensitive/Employee Patient

1.3.1.4 ADT Received – More than 1 Value for Same Identifier

1.3.2 Acknowledgment Message (ACK)

1.3.2.1 Original Mode ACK To Be Returned

1.3.2.2 ERR Segment To Be Sent for AE and AR Conditions

1.3.2.3 Incorrect Message Type, Trigger Event, Version ID, or Processing Code to Cause Reject

1.3.2.4 Incorrect Receiving Application or Receiving Facility to Cause Error .. 4

1.4 Static Definition – Message Level

1.4.1 Patient Registration Message

1.4.2 Acknowledgment Message

1.5 Static Definition – Segment Level

1.5.1 MSH Segment

1.5.2 EVN Segment

1.5.3 PID Segment

1.5.4 PV1 Segment

1.5.5 ROL Segment

1.5.6 DG1 Segment

1.5.7 OBX Segment

1.5.8 AL1 Segment

1.5.9 MSA Segment

1.5.10 ERR Segment

1.6 Static Definition – Field Level

1.6.1 MSH Segment Fields

MSH-1-Field Separator MSH-2-Encoding Characters MSH-3-Sending Application MSH-4-Sending Facility MSH-5-Receiving Application MSH-6-Receiving Facility MSH-7-Date/Time of Message MSH-9-Message Type MSH-10-Message Control ID MSH-11-Processing ID MSH-12-Version ID MSH-17-Country Code

1.6.2 EVN Segment Fields

EVN-1-Event Type Code EVN-2-Recorded Date/Time EVN-6-Event Occurred

1.6.3 PID Segment Fields

PID-3-Patient Identifier List PID-5-Patient Name PID-7-Date/Time of Birth PID-8-Sex PID-10-Race PID-11-Patient Address PID-13-Phone Number – Home PID-14-Phone Number – Business PID-19-SSN Number – Patient PID-22-Ethnic Group

1.6.4 PV1 Segment Fields

PV1-2-Patient Class PV1-3-Assigned Patient Location PV1-7-Attending Doctor PV1-8-Referring Doctor PV1-10-Hospital Service PV1-15-Ambulatory Status PV1-16-VIP Indicator PV1-19-Visit PV1-44-Admit Date/Time

1.6.5 ROL Segment Fields

ROL-1-Role Instance ID ROL-2-Action Code ROL-3-Role ROL-4-Role Person ROL-12-Phone

1.6.6 DG1 Segment Fields

ii

DG1-1-Set ID DG1-3-Diagnosis Code DG1-6-Diagnosis Type

1.6.7 OBX Segment Fields

OBX-1-Set ID OBX-2-Value Type OBX-3-Observation Identifier OBX-5-Observation Value OBX-6-Units OBX-11-Observation Result Status

1.6.8 AL1 Segment Fields

AL1-1-Set ID AL1-2-Allergy Type AL1-3-Allergy Code/Mnemonic/Description AL1-5-Allergy Reaction AL1-6-Identification Date

1.6.9 MSA Segment Fields

MSA-1-Acknowledgment Code MSA-2-Message Control ID MSA-3-Text Message MSA-6-Error Condition

1.6.10 ERR Segment Fields

ERR-1-Error Code and Location

2 Patient Update Profile

2.1 Use Case

2.1.1 Scope

2.1.2 Actors and Roles

2.2 Interactions

2.3 Dynamic Definition

2.3.1 Patient Update Message (ADT)

2.3.1.1 Update Received for Existing ICN (Non-Demo, Non-Merge)

2.3.1.2 Update Received for ICN Not on File (Non-Demo, Non-Merge)

2.3.1.3 Update Received for Existing ICN (Update Demographics)

2.3.1.4 Update Received for ICN Not on File (Update Demographics)

2.3.1.5 Update Received for Existing ICN (Merge)

2.3.1.6 Update Received for ICN Not on File (Merge)

2.3.1.7 Update Received for Existing ICN (Change ID)

2.3.1.8 Update Received for ICN Not on File (Change ID)

2.3.1.9 Update Received – More than 1 Value for Same Identifier

2.3.1.10 Update Received for Sensitive/Employee Patient

2.3.2 Acknowledgment Message (ACK)

2.3.2.1 Original Mode ACK To Be Returned

2.3.2.2 ERR Segment To Be Sent for AE and AR Conditions

2.3.2.3 Incorrect Message Type, Trigger Event, Version ID, or Processing Code to Cause Reject iii

2.3.2.4 Incorrect Receiving Application or Receiving Facility to Cause Error 35

2.4 Static Definition – Message Level

2.4.1 Patient Update Message: Transfer

2.4.2 Patient Update Message: Discharge

2.4.3 Patient Update Message: Update Patient Information

2.4.4 Patient Update Message: Merge Patient Identifier List

2.4.5 Patient Update Message: Change Patient Identifier List

2.4.6 Patient Update Message: Cancel Admit

2.4.7 Patient Update Message: Cancel Transfer

2.4.8 Patient Update Message: Cancel Discharge

2.4.9 Acknowledgment Message

2.5 Static Definition – Segment Level

2.5.1 MSH Segment

2.5.2 EVN Segment

2.5.3 PID Segment

2.5.4 MRG Segment

2.5.5 PV1 Segment

2.5.6 ROL Segment

2.5.7 DG1 Segment

2.5.8 OBX Segment

2.5.9 AL1 Segment

2.5.10 MSA Segment

2.5.11 ERR Segment

2.6 Static Definition – Field Level

2.6.1 MSH Segment Fields

MSH-1-Field Separator MSH-2-Encoding Characters MSH-3-Sending Application MSH-4-Sending Facility MSH-5-Receiving Application MSH-6-Receiving Facility MSH-7-Date/Time of Message MSH-9-Message Type MSH-10-Message Control ID MSH-11-Processing ID MSH-12-Version ID MSH-17-Country Code

2.6.2 EVN Segment Fields

EVN-1-Event Type Code EVN-2-Recorded Date/Time EVN-6-Event Occurred

2.6.3 PID Segment Fields

PID-3-Patient Identifier List PID-5-Patient Name PID-7-Date/Time of Birth PID-8-Sex iv

PID-10-Race PID-11-Patient Address PID-13-Phone Number – Home PID-14-Phone Number – Business PID-19-SSN Number – Patient PID-22-Ethnic Group

2.6.4 MRG Segment Fields

MRG-1-Prior Patient Identifier List

2.6.5 PV1 Segment Fields

PV1-2-Patient Class PV1-3-Assigned Patient Location PV1-7-Attending Doctor PV1-8-Referring Doctor PV1-10-Hospital Service PV1-15-Ambulatory Status PV1-16-VIP Indicator PV1-19-Visit PV1-44-Admit Date/Time PV1-45-Discharge Date/Time

2.6.6 ROL Segment Fields

ROL-1-Role Instance ID ROL-2-Action Code ROL-3-Role ROL-4-Role Person ROL-12-Phone

2.6.7 DG1 Segment Fields

DG1-1-Set ID DG1-3-Diagnosis Code DG1-6-Diagnosis Type

2.6.8 OBX Segment Fields

OBX-2-Value Type OBX-3-Observation Identifier OBX-5-Observation Value OBX-6-Units OBX-11-Observation Result Status

2.6.9 AL1 Segment Fields

AL1-1-Set ID AL1-2-Allergy Type AL1-3-Allergy Code/Mnemonic/Description AL1-5-Allergy Reaction AL1-6-Identification Date

2.6.10 MSA Segment Fields

MSA-1-Acknowledgment Code MSA-2-Message Control ID MSA-3-Text Message MSA-6-Error Condition v

2.6.11 ERR Segment Fields

3 Order Entry/Update Profile

3.1 Use Case

3.1.1 Scope

3.1.2 Actors and Roles

3.2 Interactions

3.3 Dynamic Definition

3.3.1 Order Message (ORM)

3.3.1.1 New Order – Case, Study Instance UID and ICN Not Found

3.3.1.2 New Order – Case and Study Instance UID Not Found, ICN Found ... 67

3.3.1.3 New Order – Case and Study Instance UID Found, ICN Does Not

Match

3.3.1.4 New Study for Existing Order – Case and ICN Found, Study Instance

UID Does Not Match

3.3.1.5 New Order – Case, Study Instance UID and Matching ICN Found, Orderable Item Code Does Not Match

3.3.1.6 Order Cancellation – Case and Matching ICN Found

3.3.1.7 Order Cancellation – Case Found, ICN, SSN and/or Study Instance UID

Do Not Match

3.3.1.8 Order Cancellation – Case Found, DOB, Sex or Name Do Not Match 69

3.3.1.9 Order Cancellation – Case and Matching ICN Not Found

3.3.1.10 Patient Examined – Case and Matching ICN Found

3.3.1.11 Patient Examined – Case Not Found

3.3.1.12 Patient Examined – Case Found, ICN, SSN and/or Study Instance UID

Do Not Match

3.3.1.13 Patient Examined – Case Found, DOB, Sex or Name Do Not Match.. 70

3.3.1.14 Patient Examined – Case and Matching ICN Found, Orderable Item

Code Does Not Match

3.3.1.15 New or Updated Order – Study Instance UID To Be Assigned from

ZDS Segment

3.3.1.16 New Order –VistA Code To Be Stored, CPT Code May Be Stored

3.3.1.17 Order Received and Filed for Pregnant Patient

3.3.1.18 Order Received and Filed for Sensitive/Employee Patient

3.3.1.19 Order or Order Update Received – More than 1 Value for Same

Identifier

3.3.2 Acknowledgment Message (ACK)

3.3.2.1 Original Mode ACK To Be Returned

3.3.2.2 ERR Segment To Be Sent for AE and AR Conditions

3.3.2.3 Incorrect Message Type, Trigger Event, Version ID, or Processing Code to Cause Reject

3.3.2.4 Incorrect Receiving Application or Receiving Facility to Cause Error 72

3.4 Static Definition – Message Level

3.4.1 Order Message

3.4.2 Acknowledgment Message

3.5 Static Definition – Segment Level

3.5.1 MSH Segment

vi

3.5.2 PID Segment

3.5.3 PV1 Segment

3.5.4 ORC Segment

3.5.5 OBR Segment

3.5.6 ZDS Segment

3.5.7 OBX Segment

3.5.8 MSA Segment

3.5.9 ERR Segment

3.6 Static Definition – Field Level

3.6.1 MSH Segment Fields

MSH-1-Field Separator MSH-2-Encoding Characters MSH-3-Sending Application MSH-4-Sending Facility MSH-5-Receiving Application MSH-6-Receiving Facility MSH-7-Date/Time of Message MSH-9-Message Type MSH-10-Message Control ID MSH-11-Processing ID MSH-12-Version ID MSH-17-Country Code

3.6.2 PID Segment Fields

PID-3-Patient Identifier List PID-5-Patient Name PID-7-Date/Time of Birth PID-8-Sex PID-10-Race PID-11-Patient Address PID-13-Phone Number – Home PID-14-Phone Number – Business PID-19-SSN Number – Patient PID-22-Ethnic Group

3.6.3 PV1 Segment Fields

PV1-2-Patient Class PV1-3-Assigned Patient Location PV1-7-Attending Doctor PV1-8-Referring Doctor PV1-10-Hospital Service PV1-15-Ambulatory Status PV1-16-VIP Indicator PV1-19-Visit

3.6.4 ORC Segment Fields

ORC-1-Order Control ORC-2-Placer Order Number ORC-3-Filler Order Number vii

ORC-5-Order Status ORC-7-Quantity/Timing ORC-8-Parent ORC-9-Date/Time of Transaction ORC-10-Entered By ORC-12-Ordering Provider ORC-13-Enterer’s Location ORC-14-Call Back Phone Number ORC-17-Entering Organization

3.6.5 OBR Segment Fields

OBR-1-Set ID OBR-2-Placer Order Number OBR-3-Filler Order Number OBR-4-Universal Service Identifier OBR-5-Priority OBR-15-Specimen Source OBR-16-Ordering Provider OBR-17-Order Callback Phone Number OBR-18-Placer Field 1 OBR-19-Placer Field 2 OBR-21-Filler Field 2 OBR-24-Diagnostic Service Section ID OBR-27-Quantity/Timing OBR-29-Parent OBR-30-Transportation Mode OBR-31-Reason for Study

3.6.6 ZDS Segment Fields

ZDS-1-Study Instance UID

3.6.7 OBX Segment Fields

OBX-2-Value Type OBX-3-Observation Identifier OBX-5-Observation Value OBX-6-Units OBX-11-Observation Result Status

3.6.8 MSA Segment Fields

3.6.9 ERR Segment Fields

4 Report Transmission & Storage Profile

4.1 Use Case

4.1.1 Scope

4.1.2 Actors and Roles

4.2 Interactions

4.3 Dynamic Definition

4.3.1 Report Message (ORU)

4.3.1.1 VistA Is System of Legal Record

4.3.1.2 Report Received by PACS – Case and ICN Found, No Previous Report on File viii

4.3.1.3 Report Received by PACS – Case and ICN Found, Previous Report Already on File

4.3.1.4 Report Received by PACS – Case and ICN Not Found

4.3.2 Acknowledgment Message (ACK)

4.3.2.1 Original Mode ACK To Be Returned

4.3.2.2 ERR Segment To Be Sent for AE and AR Conditions

4.3.2.3 Incorrect Message Type, Trigger Event, Version ID, or Processing Code to Cause Reject

4.3.2.4 Incorrect Receiving Application or Receiving Facility to Cause Error

4.4 Static Definition – Message Level

4.4.1 Report Message

4.4.2 Acknowledgment Message

4.5 Static Definition – Segment Level

4.5.1 MSH Segment

4.5.2 PID Segment

4.5.3 OBR Segment

4.5.4 OBX Segment

4.5.5 MSA Segment

4.5.6 ERR Segment

4.6 Static Definition – Field Level

4.6.1 MSH Segment Fields

MSH-1-Field Separator MSH-2-Encoding Characters MSH-3-Sending Application MSH-4-Sending Facility MSH-5-Receiving Application MSH-6-Receiving Facility MSH-7-Date/Time of Message MSH-9-Message Type MSH-10-Message Control ID MSH-11-Processing ID MSH-12-Version ID MSH-17-Country Code

4.6.2 PID Segment Fields

4.6.3 OBR Segment Fields

OBR-1-Set ID OBR-2-Placer Order Number OBR-3-Filler Order Number OBR-4-Universal Service Identifier OBR-7-Observation Date/Time OBR-15-Specimen Source OBR-16-Ordering Provider OBR-17-Order Callback Phone Number OBR-18-Placer Field 1 OBR-19-Placer Field 2 ix

OBR-21-Filler Field 2 OBR-22-Results Rpt/Status Chng – Date/Time OBR-25-Status OBR-29-Parent OBR-32-Principal Result Interpreter OBR-33-Assistant Result Interpreter OBR-35-Transcriptionist

4.6.4 OBX Segment Fields

OBX-2-Value Type OBX-3-Observation Identifier OBX-5-Observation Value OBX-6-Units OBX-11-Observation Result Status

4.6.5 Fields Used in the MSA Segment

4.6.6 Fields Used in the ERR Segment

x

Foreword

This document contains profiles for all messages using the Health Level Seven (HL7) Standard that are sent from the VistA medical center system to commercial Picture Archiving and Communication Systems (PACS). The purpose of this messaging is to support DICOM Modality Worklist functionality on PACS, indicate DICOM mapping of received order data into stored and forwarded IOD instances, and to allow storage of VistA reports on PACS. A suggested DICOM to HL7 mapping is also given for reports generated on PACS* and forwarded to VistA via HL7.

VA has been a leader in the development of HIS-RIS-PACS interfaces for over 10 years.

The currently running VA-PACS interface is based on the DICOM standard. At the present time, VA is updating this interface by adding functionality to the current DICOM Text Gateway that will support an IHE-compliant HL7 interface as well as an ADT registration interface. VA will be sending HL7 Version 2.3.1 messages, as required by IHE. However, a number of HL7 Version 2.4 structures will be pre-adopted: for example, the ROL segment, which can accommodate multiple telephone numbers for clinicians.

This document serves two purposes. It identifies the VistA HIS data elements that will be handled by the new interface, as well as the HL7 and DICOM fields that contain those data elements. It also defines the functional business requirements of this interface, including the various conditions that can occur during operation and the expected behavior of the PACS under the possible circumstances.

Specifications in this document are organized into conformance profiles covering registration, order, and report messaging. The methodology used is that of the Conformance section (2.12) of Chapter 2 of HL7 Version 2.5. The order messages used are intended to support the Scheduled Workflow (SWF) profile of the Integrating the Healthcare Enterprise (IHE) Radiology Technical Framework (Rad-TF), while the ADT update messages used are intended to support the IHE Rad-TF Patient Information Reconciliation (PIR) profile.

Organization of This Document

The Introduction to this document contains four tables that group the key elements that are communicated by the HL7 interface. These Basic Data Sets include elements relating to patients, visits, orders, and reports. Within the tables are the names of the elements in the VistA system, the names of the corresponding HL7 elements, and the names and tags of the corresponding DICOM elements. These tables will be referred to throughout the document.

* This option implies that the PACS owns the transcription system and provides report messages to VistA.

xi

Following the Introduction, three HL7 profiles are presented. Each of these profiles is divided into sections as prescribed by the Conformance section of the HL7 Standard:

• Use case, including actors and roles

• Interactions, showing the message sent and expected processing within the communications portion of the interface

• Dynamic definition, which contains the business and functional requirements for message processing

• Message level static definition, showing the segment structure of the HL7 message used for the profile

• Segment level static definition, showing the elements used in each segment

• Field level static definition, describing how field elements (and, where applicable, subelements) are populated, including values for enterprise-wide controlled vocabularies

The sections listed above conform to the conventions used in the discussion of HL7 Conformance Profiles in the Health Level Seven Standard, Version 2.5, Section 2.12.

IHE Radiology support is provided by the following HL7 messages:

Message Trigger Event(s) Order

Code(s) Profile VistA IHE

Actor Destination IHE Actor

Transaction

ADT A01, A04 Scheduled Workflow

ADT DSS/Order Filler

Patient Registration (1)

ADT A02, A03, A08,

A11, A12, A13, A40, A47

Patient Information Reconciliation

DSS/Order Filler

Image Manager

Patient Update (12)

ORM O01 NW Scheduled Workflow

DSS/Order Filler

Image Manager

Procedure Scheduled (4)

ORM O01 XO, CA Patient Information Reconciliation

DSS/Order Filler

Image Manager

Procedure Update (13)

Note: The current VA Radiology package does not support the transmission of multiple Scheduled

Procedure Steps in a single HL7 message.

xii

Changes for Version 1.2

The following changes are introduced in Version 1.2 of this specification.

1. Syntax for the A11 (Cancel Admit) message has been added at Section 2.4.6.

2. The usage of PV1-7-Attending Doctor is now CE (conditional but may be empty) in all cases. If a patient is an inpatient and an attending doctor’s name is on file, the attending doctor’s name will be sent.

3. The usage of PV1-8-Referring Doctor has been changed from CE (conditional but may be empty) to RE (required but may be empty). If a referring doctor’s name is on file, the referring doctor’s name will be sent.

4. Sensitive and employee patients are flagged in PV1-16-VIP Indicator, as directed by the IHE Radiology Technical Framework. Formerly, PV1-18-Patient Type had been used; this practice has been discontinued.

5. PV1-45-Discharge Date/Time will not be populated for patient registration messages.

6. The use of the CE data type for Field ROL-3-Role is now fully documented.

7. The values to be used for DG1-6-Diagnosis Type are now fully documented.

8. Field ORC-7.6-Priority is now the primary source for priority information.

Formerly, the primary source for priority information had been OBR-27.6- Priority.

9. OBR-20-Filler Field 1 has been reserved by the IHE Radiology Technical

Framework for the value of Scheduled Procedure Step, which is not used in this interface. The data formerly carried in OBR-20-Filler Field 1 are now carried in OBR-21-Filler Field 2.

10. OBR-31-Reason for Study is now populated as specified in the IHE Radiology

Technical Framework. Formerly, OBX segments had been used for Reason for Study; this practice has been discontinued.

11. The length and data type of OBX-5-Observation Value vary according to the value of OBX-2-Value Type, as specified by the HL7 Standard. The use of the ID data type has been discontinued.

12. In order and report messages, Field OBX-6-Units is populated for quantitative data if units of measure are available. The field was formerly shown as not used.

xiii

13. Metric units of measure are used in OBX-6-Units. The use of English units of measure has been discontinued.

14. In field OBX-6-Units, the usage of components OBX-6.1-Identifier and OBX-6.3-

Name of Coding System has been changed from X (not used) to R (required).

15. In the Basic Order Data Set, technologists’ comments in OBX segments are mapped to DICOM element (0032,4000) in the Modality Worklist SOP Class.

16. Details of error acknowledgments are specified in the dynamic definitions in

Sections 1.3, 2.3, and 3.3.

17. Discharge date and time have been added to the Basic Visit Data Set at Section 0.2.

18. Appropriate behavior when multiple ICNs are received in an order message has been documented.

19. The documentation of behavior when multiple identifiers are received in an ADT message has been revised to reflect the usage of ICN alone as a patient identifier.

20. Only the first triplet (CPT code and text) of OBR-4-Universal Service Identifier will be used to populate the procedure code field on PACS.

21. Review of patient merges initiated by VistA is now an optional step.

22. The data types and usages for field OBX-5-Observation Value in order messages have been clarified.

xiv

Introduction: Basic Data Sets

The following basic data sets will be referred to throughout these profiles. These tables list the patient-related, order-related, and message-related elements that will be transmitted, stored, and/or used by interfaced systems.

0.1 Basic Patient Data Set

The following are the elements of the Basic Patient Data Set. All mapped DICOM fields, if they were provided and listed below, must be preserved in the PACS generated DICOM Modality Worklist (C-FIND) SOP class, as well as in all C-STORE storage SOP classes that are used to store and forward Instances by PACS.

VistA Data Description

HL7 DICOM

Social Security Number (SSN)

PID-19-SSN Number-Patient [HL7 recommends populating this field for backward compatibility: if PID-3 did not carry the Patient ID]

(0010,0020) Patient

ID

(0010,0021) Issuer of Patient ID

ICN [Integration Control Number]

PID-3-Patient Identifier List occurrence containing PID-3.4-Assigning Authority value USVHA and PID-3.5-Identifier Type value NI

(0010,1000) Other Patient ID

Name PID-5-Patient Name (0010,0010) Patient Name

Sex PID-8-Sex (0010,0040) Patient Sex

Race PID-10-Race (0010,2160) Patient Ethnic Group

DOB PID-7-Date/Time of Birth [may be as imprecise as YYYY; is NOT zero filled]

(0010,0030) Patient Birth Date (0010,0032) Patient Birth Time

Patient Size OBX instance containing HEIGHT in OBX- 3.2-Text

(0010,1020) Patient Size (height in meters)

Patient Weight OBX instance containing WEIGHT in OBX- (0010,1030) Patient xv

VistA Data HL7 DICOM

3.2-Text Weight (weight in kg)

Address PID-11-Patient Address (0010,1040) Patient’s Address

0.2 Basic Visit Data Set

The following are the elements of the Basic Visit Data Set. All mapped DICOM fields, if they were provided and listed below, must be preserved in the PACS generated DICOM Modality Worklist (C-FIND) SOP class, as well as in all C-STORE storage SOP classes that are used to store and forward Instances by PACS. Superscript MWL is used if only the Modality Worklist applies.

VistA Data Description

HL7 DICOM

Category of Exam [inpatient, outpatient, etc.]

PV1-2-Patient Class (0038,4000) Visit Comments

Room-Bed PV1-3-Assigned Patient Location (0038,0300) Current Patient Location

Attending Physician PV1-7-Attending Doctor [also carried in an occurrence of the ROL segment]

(0008,1050) Performing Physician(s)

Ordering Physician PV1-8-Referring Doctor [also carried in an occurrence of the ROL segment]

(0008,0090) Referring Physician(s)

Allergies OBX instance containing ALLERGIES in OBX-3.2-Text

(0010,2000) Medical Alerts

Pregnancy Status PV1-15-Ambulatory Status (value B6 indicates that patient is pregnant)

(0010,21C0) Pregnancy Status

Patient Sensitivity (employee, flagged sensitive, etc.)

PV1-16-VIP Indicator (0040,3001) Patient Confidentiality Constraint

(0040,1008) MWL

Confidentiality Code xvi

VistA Data HL7 DICOM

Admission ID PV1-19-Visit Number (0038,0010) Admission

ID

Date/Time of Admission PV1-44-Admit Date and Time (0038,0020) Admitting Date and (0038,0021) Admitting Time

Date/Time of Discharge PV1-45-Discharge Date and Time (0038,0030) Discharge Date and (0038,0032) Discharge Time

0.3 Basic Order Data Set

The following are the elements of the Basic Order Data Set. All mapped DICOM elements, if they were provided and listed below, must be preserved either in the PACS generated DICOM Modality Worklist (C-FIND) SOP class and/or in all C-STORE storage SOP classes that are used to store and forward Instances by PACS. Superscript MWL is used if only the Modality Worklist SOP class applies.

VistA Data Description HL7 DICOM Order set ORC-8-Parent No DICOM mapping as this field merely holds together multiple VistA Cases (Imaging Service Requests) for the same Patient

Location/Institution (Contains institution and location where imaging is performed)

OBR-20-Filler Field 1 (0040,0011) MWL Scheduled Procedure Step Location (0008,0080) Institution Name (0008,0082) Institution Code --

SQ

Ordering Provider OBR-16-Ordering Provider

(0032,1032) Requesting Physician

Callback Phone Number OBR-17-Order Callback Phone Number

(0040,2010) MWL Order Callback Phone Number xvii

Full Accession Number (exam date concatenated with the Case Number:

‘MMDDYY-nnnnn’)

OBR-19-Placer Field 2 Full Accession Number:

(0008,0050) Accession Number Case Number only (‘nnnnn’):

(0020,0010) Study ID (0040,0100) MWL Sch.Proc.Step (0040,1001)MWL Requested Procedure ID

Procedure (orderable item codes – CPT code and text)

OBR-4-Universal Service

ID

CPT-4 code and text:

(0032,1064) MWL Requested Procedure Code Sequence –

SQ:

(0008,0100) Code Value (0008,0102) Coding Scheme Designator (0008,0104) Code Meaning

Request Urgency ORC-7.6-Priority:

S = STAT (with highest priority) A = ASAP (fill after

Stat orders) R = ROUTINE (the default)

(0040,1003) MWL Requested Procedure Priority The HL7 values shown in the previous column are to be mapped to DICOM values as follows:

HL7 DICOM

S STAT

A HIGH

R ROUTINE

Modifiers – procedure and

CPT

OBX instance containing MODIFIERS in OBX- 3.2-Text -3 Types:

‘M’ - Procedure modifiers (local) ‘C4’ - CPT modifiers (national)

(0032,1060) MWL Requested Procedure Description:

applicable modifiers concatenated and optionally appended with laterality indicator xviii

Modality OBR-24 (Diagnostic Service Section ID)

(0008,0060) Modality

(0040,0100) MWL

Sched.Procedure Step – SQ:

(0008,0060) Modality

Scheduled Date/Time ORC-7.4.1-Time (in Component OBR-27.4- Start Date/Time of Field

OBR-27-

Quantity/Timing) OBR-27.4.1- Time (in Component OBR-27.4- Start Date/Time of Field

OBR-27-

Quantity/Timing)

(0032,1000) MWL Sched.Study Start Date (0032,1001) MWL Sched.Study Start Time (0040,0100) MWL Scheduled Procedure Step -- SQ:

(0040,0002) MWL Sched.

Proc.

Step Start Date (0040,0003) MWL Sched.

Proc.

Step Start Time

History (unlimited text) OBX instance containing HISTORY in OBX-3.2- Text

For backward compatibility, the following element may be populated:

(0010,21B0) Additional Patient History

Reason for Study OBR-31-Reason for Study

Should be displayed for Modality Worklist and stored in DICOM header in the following elements:

(0040,1002) Reason for the Requested Procedure AND (0040,1400) Requested Procedure Comments (0032,1030) Reason for Study

Technologist’s Comment OBX instance containing TECH COMMENT in OBX-3.2-Text

(0032,4000) Study Comment

Study Instance UID ZDS-1.1-Study Instance

UID

Value sent in HL7 message MUST be used by PACS.

(0020,000D) Study Instance

UID

xix

0.4 Basic Report Data Set

The following are the elements of the Basic Report Data Set. This is not a normative mapping for Report data. PACS is responsible for its own storage of report data, but if the PACS owns a transcription system, the context identified by the given DICOM tags must be stored in the appropriate outgoing HL7 ORU^R01 messages (which are not a part of this specification).

VistA Data Description

HL7 DICOM

Report Status OBR-25-Result Status (4008,0210) Interpretation Type ID – CS: [REPORT, AMENDMENT]

Report Status – Codes: F for final and R for released not verified

OBR-25-Result Status (4008,0212) Interpretation Status ID – CS:

[TRANSCRIBED,

APPROVED]

Date/Time of Transaction OBR-22-Results Rpt/Status Chg – Date/Time if OBR- 18 = ‘R’

(4008,0108) Interpretation Transcription Date (4008,0109) Interpretation Transcription Time

Impression Text OBX instance containing IMPRESSION in OBX- 3.2-Text

(4008,0300) Impressions

Report Text OBX instance containing REPORT in OBX-3.2-Text

(4008,100B) Interpretation Text

Diagnostic Code OBX instance containing DIAGNOSTIC CODE in OBX-3.2-Text

(4008,0117) Interpretation Diagnosis Code Sequence –

SQ

Primary Interpreting Resident

OBR-33-Assistant Result Interpreter

(4008,010C) Interpretation Author

Verifying Physician OBR-32-Principal Result Interpreter

(4008,0114) Physician Approving Interpretation xx

Terminology

The term file, when used as a proper term, shall be understood to mean a VA File Manager file on the local VistA system, unless this document explicitly indicates otherwise. Likewise, the term table, when used as a proper term, shall be understood to mean a table (HL7-defined or user-defined) cited in the Health Level Seven Standard.

In the static definition portions of the profile, the following abbreviations are employed in the Usage column. Note the constraints on the HL7 definitions of CE and X: the conformant receiving application shall NOT raise an error if such fields are populated.

Value Description Comment

R Required A conforming sending application shall populate all “R” elements with a non-empty value. A conforming receiving application shall process (save/print/archive/etc.) or ignore the information conveyed by required elements. A conforming receiving application must not raise an error due to the presence of a required element, but may raise an error due to the absence of a required element.

RE Required but may be empty The element may be missing from the message, but must be sent by the sending application if there is relevant data. A conforming sending application must be capable of providing all "RE" elements. If the conforming sending application knows the required values for the element, then it must send that element. If the conforming sending application does not know the required values, then that element will be omitted.

Receiving applications will be expected to process (save/print/archive/etc.) or ignore data contained in the element, but must be able to successfully process the message if the element is omitted (no error message should be generated because the element is missing).

C Conditional This usage has an associated condition predicate.

If the predicate is satisfied:

A conformant sending application must always send the element. A conformant receiving application must process or ignore data in the element. It may raise an error if the element is not present.

If the predicate is NOT satisfied:

A conformant sending application must NOT send the element.

A conformant receiving application must NOT raise an error if the condition predicate is false, whether the element is present or not.

xxi

Value Description Comment

CE Conditional but it may be empty This usage has an associated condition predicate.

If the predicate is satisfied:

If the conforming sending application knows the required values for the element, then the application must send the element. If the conforming sending application does not know the values required for this element, then the element shall be omitted. The conforming sending application must be capable of knowing the element (when the predicate is true) for all ‘CE’ elements.

If the element is present, the conformant receiving application shall process (display/print/archive/etc.) or ignore the values of that element. If the element is not present, the conformant receiving application shall not raise an error due to the presence or absence of the element.

If the predicate is not satisfied:

A conformant sending application must NOT send the element.

A conformant receiving application must NOT raise an error if the condition predicate is false, whether the element is present or not.

B Retained for backward compatibility

A conforming sending application may populate this element.

However, this element has been deprecated in the HL7 Standard and may be withdrawn from a future version of the Standard. A future version of this Profile may withdraw support for this field.

A conforming receiving application shall process (save/print/archive/etc.) or ignore the information conveyed. A conforming receiving application must not raise an error due to the presence or absence of a deprecated element.

X Not supported For conformant sending applications, the element will not be sent. Conformant receiving applications shall ignore the element whether it is sent or not.

xxii

1 Patient Registration Profile

1.1 Use Case

1.1.1 Scope

The Patient Registration transaction conveys the patient demographic and visit information that was captured at the point of encounter. This transaction is used both for inpatients (i.e., those who are assigned a bed at the facility) and outpatients (i.e., those who are not assigned a bed at the facility). It is implemented only for PACS that assert support for the Modality Worklist Service Class Provider.

1.1.2 Actors and Roles

Actor: VistA Imaging

Role: Receives patient registration notification from VistA Patient Information Management System. Transmits appropriate demographic and encounter information to associated imaging systems including commercial Picture Archiving and Communication Systems (PACS).

Actor: PACS

Role: Receives and stores patient demographic and encounter information for use in building the Modality Worklist (MWL) when orders are received from VistA Radiology.

1.2 Interactions

The actors in this use case shall perform the behaviors shown in the following activity diagram.

1.3 Dynamic Definition

Vista and PACS shall generate and process HL7 messages according to the following functional and business requirements.

1.3.1 Patient Registration Message (ADT)

VistA Imaging shall transmit an ADT message to PACS upon patient registration.

If PACS accepts ADT messages, it shall process the message in conformance with the following requirements.

1.3.1.1 ADT Message Received – ICN Not Found

When PACS receives an ADT registration message for a patient for which it does not find an ICN in its system, PACS will create a new patient record and will extract from the HL7 message, and will store in its system, the information contained in the Basic Patient Data Set (see Section 0.1 above) and the Basic Visit Data Set (see Section 0.2 above).

1.3.1.2 ADT Received for Existing ICN (Non-Update, Non-Merge) When PACS receives an ADT registration message for a patient for which it finds an ICN in its system, PACS will verify that name, SSN, sex, and DOB exactly match what is already in its system: if so, PACS will extract from the HL7 message, and will store in its system, the information contained in the Basic Patient Data Set (see Section 0.1 above) and the Basic Visit Data Set (see Section

0.2 above); if not, PACS will put the message onto a reconciliation queue and notify the sending system of the anomaly(ies) via an HL7 application acknowledgment containing a value of AE (application error) in field MSA-1-acknowledgment code and a fully populated occurrence of ERR-1-error code and location, as described in Section 1.6.10 below, including code 204 (unknown key identifier) in component 4.

1.3.1.3 ADT Received for Sensitive/Employee Patient

When PACS receives an ADT registration message for a patient whose VIP Indicator value in PV1-16 is set to E (employee) or S (sensitive), PACS shall safeguard the identity of the patient using VA rules for suppressing patient name and other identifying information.

1.3.1.4 ADT Received – More than 1 Value for Same Identifier

When PACS receives an ADT registration message containing more than one value for the ICN, PACS will notify the sending system of the anomaly(ies) via an HL7 application acknowledgment and will not update any patient record. The application acknowledgment shall contain a value of AE (application error) in field MSA-1-acknowledgment code and a fully populated occurrence of ERR-1-error code and location, as described in Section 1.6.10 below, including code 207 (application internal error) in component 4. PACS is responsible for notifying support staff and users of anomalies as needed.

1.3.2 Acknowledgment Message (ACK)

1.3.2.1 Original Mode ACK To Be Returned

If PACS accepts ADT registration messages, it shall return an original mode ACK application acknowledgment, as defined in the HL7 Standard and prescribed by the IHE Radiology Technical Framework. The trigger event of the acknowledgment message shall be equal to the trigger event of the message that was received.

1.3.2.2 ERR Segment To Be Sent for AE and AR Conditions

When an error is determined to have occurred, PACS shall return the acknowledgment code AE (Application Error) or AR (Application Reject) as appropriate, and shall populate Field ERR-1-error code and location with the relevant error information including the appropriate error code from HL7 Table 0357. See Section 1.6.10 for more information on populating ERR-1-error code and location.

1.3.2.3 Incorrect Message Type, Trigger Event, Version ID, or Processing Code se Reject to Cau

If the value received in MSH-9.1-message type, MSH-9.2-trigger event, MSH-11-processing code, or MSH-12-version ID is invalid, the value AR (application reject) shall be returned in MSA-1-acknowledgment code, and the appropriate value from HL7 Table 0357 shall be returned in ERR-1-error code and location.

See Section 1.6.10 for more information on populating ERR-1-error code and location.

1.3.2.4 Incorrect Receiving Application or Receiving Facility to Cause Error If the value received in MSH-5-receiving application or MSH-6-receiving facility is invalid, the value AE (application error) shall be returned in MSA-1-acknowledgment code, and the value 103 (table value not found) shall be returned in ERR-1-error code and location. See Section 1.6.10 for more information on populating ERR-1-error code and location.

1.4 Static Definition – Message Level

HL7 messages shall be populated and processed according to the following abstract message definitions.

1.4.1 Patient Registration Message

Segment ADT Message Usage Cardinality HL7 Chapter MSH Message Header R [1..1] 2 EVN Event Type R [1..1] 3 PID Patient Identification R [1..1] 3 [ PD1 ] Additional Demographics X [0..0] 3 [ { NK1 } ] Next of Kin / Associated Parties X [0..0] 3 PV1 Patient Visit R [1..1] 3 [ PV2 ] Patient Visit – Additional Info. X [0..0] 3

[ { ROL } ] Role RE [0..2] 12 [ { DB1 } ] Disability Information X [0..0] 3 [ { OBX } ] Observation / Result R [2..2] 7 [ { AL1 } ] Allergy Information RE [0..99] 3 [ { DG1 } ] Diagnosis Information RE [0..1] 6 [ DRG ] Diagnosis Related Group X [0..0] 6 [ { PR1 Procedures X [0..0] 6 [ { ROL } ] Role X [0..0] 12 [ { GT1 } ] Guarantor X [0..0] 6 [ { IN1 Insurance X [0..0] 6 [ IN2 ] Insurance Additional Info. X [0..0] 6 [ { IN3 } ] Insurance Additional Info. – Cert. X [0..0] 6 [ ACC ] Accident Information X [0..0] 6 [ UB1 ] Universal Bill Information X [0..0] 6 [ UB2 ] Universal Bill 92 Information X [0..0] 6

1.4.2 Acknowledgment Message

Segment ACK Message Usage Cardinality HL7 Chapter MSH Message Header R [1..1] 2 MSA Message Acknowledgment R [1..1] 2 [ ERR ] Error RE [0..1] 2

1.5 Static Definition – Segment Level

Fields in HL7 messages shall be populated and processed according to the following Segment Attribute Tables.

1.5.1 MSH Segment

Refer to Section 1.6.1, MSH Segment Fields, for a detailed explanation of the fields used in this segment.

Seq Len DT Usage Cardinality TBL# Item # Element Name 1 1 ST R [1..1] 00001 Field Separator 2 4 ST R [1..1] 00002 Encoding Characters 3 180 HD R [1..1] 0361 00003 Sending Application 4 180 HD R [1..1] 0362 00004 Sending Facility 5 180 HD R [1..1] 0361 00005 Receiving Application 6 180 HD R [1..1] 0362 00006 Receiving Facility

7 26 TS R [1..1] 00007 Date/Time of Message 8 40 ST X [0..0] 00008 Security

9 13 CM R [1..1] 0076

00009 Message Type

10 20 ST R [1..1] 00010 Message Control ID 11 3 PT R [1..1] 00011 Processing ID 12 60 VID R [1..1] 0104 00012 Version ID 13 15 NM X [0..0] 00013 Sequence Number 14 180 ST X [0..0] 00014 Continuation Pointer 15 2 ID X [0..0] 0155 00015 Accept Acknowledgment Type 16 2 ID X [0..0] 0155 00016 Application Acknowledgment Type 17 3 ID R [1..1] 00017 Country Code 18 16 ID X [0..0] 0211 00692 Character Set 19 250 CE X [0..0] 00693 Principal Language of Message 20 20 ID X [0..0] 0356 01317 Alternate Character Set Handling Scheme 21 10 ID X [0..0] 01598 Conformance Statement ID

1.5.2 EVN Segment

The following is a listing of all the fields defined for the EVN Segment in HL7. Refer to Section 1.6.2, EVN Segment Fields, for a more detailed explanation of the fields used by VistA.

1 3 ID R [1..1] 0003 00099 Event Type Code 2 26 TS R [1..1] 00100 Recorded Date/Time 3 26 TS X [0..0] 00101 Date/Time Planned Event 4 3 IS X [0..0] 0062 00102 Event Reason Code 5 60 XCN X [0..0] 0188 00103 Operator ID 6 26 TS RE [0..1] 01278 Event Occurred 7 180 HD X [0..0] 01534 Event Facility

1.5.3 PID Segment

The following is a listing of all the fields defined for the PID Segment in HL7. Refer to Section 1.6.3, PID Segment Fields, for a more detailed explanation of the fields used by

1 4 SI X [0..0] 00104 Set ID - PID 2 20 CX X [0..0] 00105 Patient ID 3 250 CX R [1..1] 00106 Patient Identifier List 4 20 CX X [0..0] 00107 Alternate Patient ID - PID 5 250 XPN R [1..1] 00108 Patient Name 6 250 XPN X [0..0] 00109 Mother’s Maiden Name 7 26 TS RE [0..1] 00110 Date/Time of Birth 8 1 IS RE [0..1] 0001 00111 Sex 9 250 XPN X [0..0] 00112 Patient Alias

10 250 CE RE [0..1] 0005 00113 Race 11 250 XAD RE [0..1] 00114 Patient Address 12 4 IS X [0..0] 0289 00115 County Code 13 250 XTN RE [0..1] 00116 Phone Number - Home 14 250 XTN RE [0..1] 00117 Phone Number - Business 15 250 CE X [0..0] 0296 00118 Primary Language 16 250 CE X [0..0] 0002 00119 Marital Status 17 250 CE X [0..0] 0006 00120 Religion 18 250 CX X [0..0] 00121 Patient Account Number 19 16 ST R [1..1] 00122 SSN Number - Patient 20 25 DLN X [0..0] 00123 Driver's License Number - Patient 21 250 CX X [0..0] 00124 Mother's Identifier 22 250 CE RE [0..1] 0189 00125 Ethnic Group 23 250 ST X [0..0] 00126 Birth Place 24 1 ID X [0..0] 0136 00127 Multiple Birth Indicator 25 2 NM X [0..0] 00128 Birth Order 26 250 CE X [0..0] 0171 00129 Citizenship 27 250 CE X [0..0] 0172 00130 Veterans Military Status 28 250 CE X [0..0] 0212 00739 Nationality 29 26 TS X [0..0] 00740 Patient Death Date and Time 30 1 ID X [0..0] 0136 00741 Patient Death Indicator 31 1 ID X [0..0] 0136 01535 Identity Unknown Indicator 32 20 IS X [0..0] 0445 01536 Identity Reliability Code 33 26 TS X [0..0] 01537 Last Update Date/Time 34 40 HD X [0..0] 01538 Last Update Facility 35 250 CE X [0..0] 0446 01539 Species Code 36 250 CE X [0..0] 0447 01540 Breed Code 37 80 ST X [0..0] 01541 Strain 38 250 CE X [0..0] 0429 01542 Production Class Code

1.5.4 PV1 Segment

The following is a listing of all the fields defined for the PV1 Segment in HL7. Refer to Section 1.6.4, PV1 Segment Fields, for a more detailed explanation of the fields used by

1 4 SI X [0..0] 00131 Set ID - PV1 2 1 IS R [1..1] 0004 00132 Patient Class 3 80 PL C [0..1] 00133 Assigned Patient Location 4 2 IS X [0..0] 0007 00134 Admission Type 5 250 CX X [0..0] 00135 Preadmit Number 6 80 PL X [0..0] 00136 Prior Patient Location 7 250 XCN CE [0..1] 0010 00137 Attending Doctor 8 250 XCN RE [0..1] 0010 00138 Referring Doctor 9 250 XCN X [0..0] 0010 00139 Consulting Doctor 10 30 IS C [0..1] 0069 00140 Hospital Service 11 80 PL X [0..0] 00141 Temporary Location 12 2 IS X [0..0] 0087 00142 Preadmit Test Indicator 13 2 IS X [0..0] 0092 00143 Re-admission Indicator

14 6 IS X [0..0] 0023 00144 Admit Source 15 2 IS RE [0..2] 0009 00145 Ambulatory Status 16 2 IS RE [0..1] 0099 00146 VIP Indicator 17 250 XCN X [0..0] 0010 00147 Admitting Doctor 18 2 IS X [0..0] 0018 00148 Patient Type 19 250 CX RE [0..1] 00149 Visit Number 20 50 FC X [0..0] 0064 00150 Financial Class 21 2 IS X [0..0] 0032 00151 Charge Price Indicator 22 2 IS X [0..0] 0045 00152 Courtesy Code 23 2 IS X [0..0] 0046 00153 Credit Rating 24 2 IS X [0..0] 0044 00154 Contract Code 25 8 DT X [0..0] 00155 Contract Effective Date 26 12 NM X [0..0] 00156 Contract Amount 27 3 NM X [0..0] 00157 Contract Period 28 2 IS X [0..0] 0073 00158 Interest Code 29 1 IS X [0..0] 0110 00159 Transfer to Bad Debt Code 30 8 DT X [0..0] 00160 Transfer to Bad Debt Date 31 10 IS X [0..0] 0021 00161 Bad Debt Agency Code 32 12 NM X [0..0] 00162 Bad Debt Transfer Amount 33 12 NM X [0..0] 00163 Bad Debt Recovery Amount 34 1 IS X [0..0] 0111 00164 Delete Account Indicator 35 8 DT X [0..0] 00165 Delete Account Date 36 3 IS X [0..0] 0112 00166 Discharge Disposition 37 25 CM X [0..0] 0113 00167 Discharged to Location 38 250 CE X [0..0] 0114 00168 Diet Type 39 2 IS X [0..0] 0115 00169 Servicing Facility 40 1 IS X [0..0] 0116 00170 Bed Status 41 2 IS X [0..0] 0117 00171 Account Status 42 80 PL X [0..0] 00172 Pending Location 43 80 PL X [0..0] 00173 Prior Temporary Location 44 26 TS RE [0..1] 00174 Admit Date/Time 45 26 TS X [0..0] 00175 Discharge Date/Time 46 12 NM X [0..0] 00176 Current Patient Balance 47 12 NM X [0..0] 00177 Total Charges 48 12 NM X [0..0] 00178 Total Adjustments 49 12 NM X [0..0] 00179 Total Payments 50 250 CX X [0..0] 0203 00180 Alternate Visit ID 51 1 IS X [0..0] 0326 01226 Visit Indicator 52 250 XCN X [0..0] 0010 01274 Other Healthcare Provider

1.5.5 ROL Segment

The ROL Segment is used to give more complete information about the patient’s referring and attending physicians than is permitted by the PV1 Segment. Specifically, the ROL Segment allows for the transmission of multiple callback numbers for each physician.

The following is a listing of all the fields defined for the ROL Segment in HL7. Refer to Section 1.6.5, ROL Segment Fields, for a more detailed explanation of the fields used by

1 60 EI R [1..1] 01206 Role Instance ID 2 2 ID R [1..1] 0287 00816 Action Code 3 250 CE R [1..1] 0443 01197 Role-ROL 4 250 XCN R [1..1] 01198 Role Person 5 26 TS X [0..0] 01199 Role Begin Date/Time 6 26 TS X [0..0] 01200 Role End Date/Time 7 250 CE X [0..0] 01201 Role Duration 8 250 CE X [0..0] 01205 Role Action Reason 9 250 CE X [0..0] 01510 Provider Type 10 250 CE X [0..0] 0406 01461 Organization Unit Type 11 250 XAD X [0..0] 00679 Office/Home Address 12 250 XTN RE [0..8] 00678 Phone

1.5.6 DG1 Segment

The following is a listing of all the fields defined for the DG1 Segment in HL7. Refer to Section 1.6.6, DG1 Segment Fields, for a more detailed explanation of the fields used by

1 4 SI R [1..1] 00375 Set ID - DG1 2 2 ID X [0..0] 0053 00376 Diagnosis Coding Method 3 250 CE R [1..1] 0051 00377 Diagnosis Code - DG1 4 40 ST X [0..0] 00378 Diagnosis Description 5 26 TS X [0..0] 00379 Diagnosis Date/Time 6 2 IS RE [0..1] 0052 00380 Diagnosis Type 7 250 CE X [0..0] 0118 00381 Major Diagnostic Category 8 250 CE X [0..0] 0055 00382 Diagnostic Related Group 9 1 ID X [0..0] 0136 00383 DRG Approval Indicator 10 2 IS X [0..0] 0056 00384 DRG Grouper Review Code 11 250 CE X [0..0] 0083 00385 Outlier Type 12 3 NM X [0..0] 00386 Outlier Days 13 12 CP X [0..0] 00387 Outlier Cost 14 4 ST X [0..0] 00388 Grouper Version And Type 15 2 ID X [0..0] 0359 00389 Diagnosis Priority 16 250 XCN X [0..0] 00390 Diagnosing Clinician 17 3 IS X [0..0] 0228 00766 Diagnosis Classification 18 1 ID X [0..0] 0136 00767 Confidential Indicator

Seq Len Usage Cardinality TBL# Item # Element Name DT 19 26 TS X [0..0] 00768 Attestation Date/Time

1.5.7 OBX Segment

In the ADT registration message, the OBX Segment is used to communicate height and weight of the patient. The following is a listing of all the fields defined for the OBX Segment in HL7. Refer to Section 1.6.7, OBX Segment Fields, for a more detailed explanation of the fields used by VistA.

1 4 SI R [1..1] 00569 Set ID – OBX 2 2 ID R [1..1] 0125 00570 Value Type 3 250 CE R [1..1] 00571 Observation Identifier 4 20 ST X [0..0] 00572 Observation Sub-ID 5 65536†

R [1..1] 00573 Observation Value 6 250 CE R [1..1] 00574 Units 7 60 ST X [0..0] 00575 Reference Range 8 5 IS X [0..0] 0078 00576 Abnormal Flags 9 5 NM X [0..0] 00577 Probability 10 2 ID X [0..0] 00578 Nature of Abnormal Test 11 1 ID R [1..1] 0085 00579 Observation Result Status 12 26 TS X [0..0] 00580 Date Last Observation Normal Value 13 20 ST X [0..0] 00581 User Defined Access Checks 14 26 TS X [0..0] 00582 Date/Time of the Observation 15 250 CE X [0..0] 00583 Producer’s ID 16 250 XCN X [0..0] 00584 Responsible Observer 17 250 CE X [0..0] 00936 Observation Method 18 22 EI X [0..0] 01479 Equipment Instance Identifier 19 26 TS X [0..0] 01480 Date/Time of the Analysis

1.5.8 AL1 Segment

The following is a listing of all the fields defined for the AL1 Segment in HL7. Refer to Section 1.6.8, AL1 Segment Fields, for a more detailed explanation of the fields used by

1 4 SI R [1..1] 00203 Set ID – AL1 2 2 IS R [1..1] 0127 00204 Allergy Type 3 250 CE R [1..1] 00205 Allergy Code/Mnemonic/Description 4 2 IS X [0..0] 0128 00206 Allergy Severity 5 250 ST RE [0..99] 00207 Allergy Reaction 6 8 DT RE [0..1] 00208 Identification Date

† The length and data type of this field are variable, depending on OBX-2-Value Type.

1.5.9 MSA Segment

The following is a listing of all the fields defined for the MSA Segment in HL7. MSA is used only in the acknowledgment message. Refer to Section 1.6.9, MSA Segment Fields, for a more detailed explanation of the fields used by VistA.

1 2 ID R [1..1] 0003 00018 Acknowledgment Code 2 20 ST R [1..1] 00010 Message Control ID 3 80 ST B [0..1] 00020 Text Message 4 15 NM X [0..0] 00021 Expected Sequence Number 5 1 ID X [0..0] 0102 00022 Delayed Acknowledgment Type 6 250 CE B [0..1] 00023 Error Condition

1.5.10 ERR Segment

The following is a listing of all the fields defined for the ERR Segment in HL7. ERR is used only in the acknowledgment message. Refer to Section 1.6.10, ERR Segment Fields, for a more detailed explanation of the fields used by VistA.

1 80 CM R [1..999] 00024 Error Code and Location

1.6 Static Definition – Field Level

1.6.1 MSH Segment Fields

MSH-1-Field Separator This field contains the top-level delimiter for HL7 elements within segments.

MSH-2-Encoding Characters This field contains the component separator (secondary element delimiter), repetition separator, escape character, and subcomponent separator (tertiary element delimiter).

MSH-3-Sending Application This field is of data type HD, which has 3 components that are defined as…