Storage Peak. Version 5.3. HL7 Interface Specification

Similar documents
Visage 7. HL7 Interface Specification

HL7 Interface Specification Merge RadSuite v

Candelis, Inc. ImageGrid HL7 Conformance Statement Von Karman Ave. Newport Beach, CA Phone: Fax: Version 3.1.

DICOMStore. HL7 Interface Specification. M7445 Version 5.1 rev1 August 2013

HIMSS and RSNA. IHE Technical Framework Version 4.6. Errata

HL7 Conformance Statement for Image Management Family of Products: vnaplus and imagegateway

HL7 Conformance Statement

KARL STORZ AIDA V1. HL7 Interface Description

KARL STORZ OR1 FUSION V1.4 HL7 Interface Description PRODUCT INFO OR1 OR /2018/PI-E 1/12

Mach7 Enterprise Imaging Platform v HL7 Conformance Statement

OtoAccess HL7 Interface. HL7 Specification

HL7 Conformance Claim

HL7 Conformance Claim

Vianeta Communications OUTBOUND HL7 Interface Specifications

IHE Radiology Technical Framework Volume 2 (IHE RAD TF-2) Transactions

OTObase HL7 Integration

HorizonMIS HL7 Interface Specification For version 2.x of the HL7 Standard

TMY PACS HL7 Conformance Statement

HL7 v2.5 Inbound OMP (Medications) Specification Version 1.0

Health Engine HL7 Conformance Statement. Internal document number: Date:

DICOM CONFORMANCE STATEMENT FOR DIAGNOSTIC ULTRASOUND SYSTEM MODEL SSA-640A V5.0

Philips Medical Systems DICOM Conformance Statement USIT 1.5 L3

Results Reporting Interface Specifications For Results Sent from IntelliPath

Copyright FUJIFILM Corporation, Japan. August, th Edition 897N100760F

nstream Version 3.1 DICOM Conformance Statement

Philips Medical Systems DICOM Conformance Statement USIT 1.5

HISO :2015 edischarge Messaging Interim Standard

GE Healthcare. Technical Publications. ConnectR Plus Version 5.0 DICOM CONFORMANCE STATEMENT. GE Healthcare IT. Direction DOC Revision 0.

IHE IT Infrastructure Technical Framework Supplement. Patient Location Tracking Query (PLQ) Draft for Public Comment

DICOM CONFORMANCE STATEMENT FOR VANTAGE-GALAN TM VERSION V5.0

MediPlus TM PACS&RIS Version 2.6

Echology Server. DICOM Conformance Statement Volume 1. <Storage and Query/Retrieve Server> Revision 1.0 Software Version 5.

DICOM Conformance Statement

KARL STORZ OR1 FUSION V1.3.1 DICOM Conformance Statement

Krames On-Demand Integration Using HL7

Page 1 w: e: T: (203)

IHE Radiology (RAD) Technical Framework. Volume 3 IHE RAD TF-3 Transactions (continued)

DICOM Conformance Statement. Fusion RIS Version 3.1

DICOM Conformance Statement

JiveX Enterprise PACS Solutions. JiveX DICOM Worklist Broker Conformance Statement - DICOM. Version: As of

KARL STORZ AIDA V1.3.1 DICOM Conformance Statement PRODUCT INFO OR1 OR /2017/PI-E 1/32

DICOM CONFORMANCE STATEMENT

IHE Radiology Technical Framework Supplement. Import Reconciliation Workflow (IRWF.b) Rev Trial Implementation

Artwork consists of sixty-five (65) 8 ½ inch x 11 inch pages.

Software Requirements: Application Database. Hardware Requirements: Server Client Workstation

IHE Radiology Technical Framework Supplement. Results Distribution (RD) Rev. 1.0 Draft for Public Comment

ETIAM IDeal Broker. DICOM Conformance Statement.

IT Infrastructure Technical Framework. Volume 2b (ITI TF-2b) Transactions Part B Sections

Exchanging Patient Demographics Information using ANSI/HL7 v2.8.2

IHE Cardiology Technical Framework Supplement Displayable Reports (DRPT)

FUSION RIS 3.30 DICOM Conformance Statement

Topcon Medical Systems

DICOM. Conformance Statement For VINNO Medical Ultrasound System Revision 2.0. Copyright 2012 by VINNO Technology (Suzhou) Co., Ltd.

DICOM 3.0 Conformance Statement DXIMAGE RIS

CoActiv, LLC CoActiv Medical Business Solutions EXAM-PACS Conformance Statement

DBSWIN DICOM Conformance Statement. DBSWIN DD-DICOM Interface. DICOM Conformance Statement V2.1

DICOM Conformance Statement

DICOM Conformance Statement * /02* /02 MADE IN GERMANY

Image Link. User Help. Version: Written by: Product Knowledge, R&D Date: August 2017 LX-DOC-IL1.1.0-UH-EN-REVA

HL7 Web User Interface User s Guide

Laboratory Technical Framework

SIEMENS. DICOM Conformance Statement

Uscan. DICOM Conformance Statement

Software Requirements: Application Database. Hardware Requirements: Server Client Workstation

Slide 1. Slide 2. Slide 3. Component 9 - Networking and Health Information Exchange. Objectives. Why Use Data Interchange Standards?

IHE Radiology (RAD) Technical Framework. Volume 2 IHE RAD TF-2 Transactions

DICOM Conformance Statement AIDA HD Connect

Hologic Physician s Viewer 5.0 DICOM Conformance Statement

AG Mednet Agent DICOM Conformance Statement Version 1.3

The Role of Interoperability in Critical Care Information Systems

Dx Server for Windows NT DICOM 3.0 Conformance Statement

Lumify 1.8.x DICOM Conformance Statement

DICOM Conformance Statement Merge Eye Care PACS v. 4.0

HIMSS and RSNA Integrating the Healthcare Enterprise IHE/MESA ADT Registration Tests

IHE EYECARE Technical Framework Supplement

Wait Time Information System (WTIS) Complex Surgery (OR) Specification

Introduction to HL7 Standards: v 2.x. W. Ed Hammond February 25, 2008

Michigan Department of Health & Human Services

DICOM Conformance Statement for PenFetch

Standard, HL7 Interface Specification Orders Outbound

IHE IT Infrastructure Technical Framework. Volume 2b (ITI TF-2b) Transactions Part B Sections

Technical Publications

DICOM CONFORMANCE STATEMENT FOR TOSHIBA DIGITAL RADIOGRAPHY SYSTEM. Infinix Celeve-i series / Infinix-i series Model XIDF-3DP801 AND ANGIO WORKSTATION

DICOM Conformance Statement

DICOM Conformance Statement

IHE Radiology Technical Framework Supplement. Draft for Public Comment

DICOM CONFORMANCE STATEMENT FOR TOSHIBA DIGITAL RADIOGRAPHY SYSTEM MODEL DRAD-3000A, DRAD-3000E

DICOM CONFORMANCE STATEMENT FOR TOSHIBA DIGITAL RADIOGRAPHY SYSTEM. Infinix Celeve-i series / Infinix-i series Model DFP-8000 series V4.

Technical Publications

Dx Server for Windows NT DICOM 3.0 Conformance Statement

DICOM Conformance Statement FORUM

Quest Diagnostics - Lab Orders & Results interface development using nhapi

MICROMD PM SETUP SPECIFICATIONS FOR SCHUYLER LAB IMPORT

Merge PACS TM v. 7.0 DICOM CONFORMANCE STATEMENT MODALITY WORKLIST. Merge Healthcare 900 Walnut Ridge Drive Hartland, WI 53029

IHE Radiology Technical Framework Supplement. Import Reconciliation Workflow (IRWF.b) Trial Implementation

Exchanging Patient Demographics Information using ANSI/HL7 v2.8.2

Technical Publications

Technical Publication. DICOM Conformance Statement. Trauma 3.0. Document Revision 2. October 5 th, 2010

Message Profiles are Contracts for Implementation

DICOM Conformance Statement for FLEXAVISION HB/FD

Transcription:

Storage Peak Version 5.3 HL7 Interface Specification

Product: StoragePeak Version 5.1 Version 04.02 Document: HL7 Interface Specification 2013-07-11 Contents 1.INTRODUCTION... 2 1.1Revision History... 2 1.2Audience... 2 1.3Remarks... 2 1.4Abbreviations and Acronyms... 3 2.FUNCTIONAL OVERVIEW... 4 2.1General... 4 2.2Framework... 4 3.COMMUNICATION INTERFACE... 5 4.MESSAGE DESCRIPTION... 5 4.1Overview... 5 4.1.1Supported HL7 Versions... 5 4.1.2Supported Message Types... 5 4.2ADT Messages... 6 4.2.1ADT A02 - Patient Transfer... 6 4.2.2ADT A03 - Patient Discharge... 7 4.2.3ADT A08 - Update Patient Information... 8 4.2.4ADT A40 - Merge Patient (Patient Identifier List)... 9 4.3ORM Messages... 10 4.3.1ORM O01 Procedure Scheduled/Updated... 10 4.4ORU Messages... 12 4.4.1ORU R01 Observation Result... 12 4.5Acknowledge Messages... 14 4.5.1Message Contents... 14 4.5.2Message Status... 14 4.6Attribute Mapping... 15 4.6.1Patient Information Reconciliation... 15 Copyright: Digithurst GmbH & Co KG Page 1 of 17

1. Introduction 1.1 Revision History Document Date Description Author Version 01.00 2010-07-15 Release for Storage Peak 4.3 Trautnitz 01.01 2010-12-07 Corrected mistake in handling unknown Sabin patients in MRG in A40 message 02.00 2010-12-08 Release after review Trautnitz 03.00 2011-06-15 Release for Storage Peak 4.4 Trautnitz 03.01 2011-11-10 Storage Peak Version changed to 5.0 Trautnitz 04.00 2011-11-10 Release after review Trautnitz 04.01 2012-02-16 Storage Peak Version changed to 5.1 Milutin 04.02 2013-07-11 Storage Peak Version changed to 5.3 Sabin 1.2 Audience This document is intended for hospital staff, health system integrators, software designers or implementers. It is assumed that the reader has a working understanding of HL7. 1.3 Remarks This document is the HL7 Interface Specification for StoragePeak. HL7, by itself, does not guarantee interoperability. However, the Interface Specification facilitates a first-level validation for interoperability between different applications supporting the same HL7 functionality. This Interface Specification is not intended to replace validation with other HL7 equipment to ensure proper exchange of information intended. The scope of this Interface Specification is to facilitate communication between StoragePeak and other HL7 systems. The Interface Specification should be read and understood in conjunction with the HL7 Standard and the IHE Technical Framework. However, by itself it is not guaranteed to ensure the desired interoperability and a successful interconnectivity. The user should be aware of the following important issues: The comparison of different Interface Specifications is the first step towards assessing interconnectivity between StoragePeak and other HL7 conformant equipment. Test procedures should be defined to validate the desired level of connectivity.

1.4 Abbreviations and Acronyms ACK Acknowledge ADT Admission, Discharge and Transfer CS Client/Server DICOM Digital Imaging and Communications in Medicine DSS Department System Scheduler HL7 Health Level 7 IHE Integrating the Healthcare Enterprise IP Internet Protocol MLLP Minimal Lower Layer Protocol MSA Message Acknowledgement (Segment) MRG Merge Patient Information (Segment) MSH Message Header (Segment) LLP Lower Layer Protocol ORM General Order Message PACS Picture Archiving and Communication System PID Patient Identification (Segment) PIR Patient Information Reconciliation PV1 Patient Visit (Segment) RIS Radiology Information System TCP Transmission Control Protocol UID Unique Identifier UTF Unicode Transformation Format VR Value Representation

2. Functional Overview 2.1 General The StoragePeak concept is based on a modular architecture for distributing medical images and reports within and outside of a clinical area. It allows external systems to send DICOM objects to it for temporary storage and long-term archiving. This requires providing mechanisms for patient information reconciliation. Therefore StoragePeak implements a HL7 Interface which supports a subset of HL7 messages defined by the IHE transaction Patient Update. Storage Peak also handles ORU Messages for receiving reports. The functionality which is provided with the HL7 module is: Reception of incoming HL7 trigger event messages. Converting information received with the HL7 messages into DICOM conformant data sets. Performing patient information reconciliation processes by modifying patient demographic data stored within StoragePeak according to the HL7 requests. Sending appropriate response messages to the sender of the request message. 2.2 Framework The HL7 communication takes place between the ADT actor and StoragePeak which works as the Images Manager / Image Archive actor according to the IHE Standard. Actors are communication systems or components of information systems that produce, manage or act on information associated with operational activities in the enterprise. In the following the actors are described that are affected by the StoragePeak HL7 communication: ADT System: A system responsible for adding and/or updating patient demographic and encounter information. Department System Scheduler / Order Filler: A system that provides functions related to the management of orders received from external systems or through the departments system s user interface. Image Manager: A system that provides functions related to safe storage and management of evidence objects. Image Archive: A system that provides long term storage of evidence objects.

3. Communication Interface The HL7 Standard recommends the Minimal Lower Layer Protocol (MLLP) for the communication between HL7 systems. For this purpose the HL7 Interface of StoragePeak provides a unidirectional TCP/IP socket interface. The Lower Layer Protocol defined by the HL7 Standard is implemented as follows: Default TCP/IP Port 18015 (configurable) Message Start Character: 0x0B Segment End Character: 0x0D Message Stop Characters: 0x1C and 0x0D Character Encoding: ISO 8859-1 4. Message Description 4.1 Overview StoragePeak is able to handle a subset of ADT messages which are used to transmit portions of the Patient Administration data from one system to another. This chapter informs about the supported HL7 versions and message types and describes the expected message contents and in which way the received data is used for further processing. 4.1.1 Supported HL7 Versions The HL7 interface of StoragePeak supports messages which are conform to the subset of HL7 version 2.3. 4.1.2 Supported Message Types The HL7 interface of StoragePeak supports the reception of the subset of ADT, ORM and ORU message types which is listed below. ADT A02 (Transfer a Patient) ADT A03 (Discharge/End Visit) ADT A08 (Update Patient Information) ADT A40 (Merge Patient Patient Identifier List) ORM O01 (Procedure scheduled/updated) ORU R01 (Observation Result)

4.2 ADT Messages 4.2.1 ADT A02 - Patient Transfer The message segments and elements in the following tables are necessary to perform the patient visit update process and to generate an appropriate acknowledge message. The last column of the tables specifies the expected values and their intended use. StoragePeak accepts ADT A02 messages without further processing. MSH Segment 0001 Field Seperator ST For this element is expected. 0002 Encoding Characters ST For this element ^~\& is expected. 0009 Message Type CM For this element ADT^A02 is expected. 0010 Message Control ID ST Used to fill the acknowledge message. 0011 Processing ID PT Used to fill the acknowledge message. 0012 Version ID VIT Used for HL7 version check and to fill the acknowledge message. PID Segment 0003 Patient Identifier List CX Used to identify the patient for the update process. If this field contains more than one identifier only the first one is used for patient identification. PV1 Segment 0003 Assigned Patient Location PL New assigned location for the specified patient. Constraints: A PIR process can only be performed for patients with a valid Patient ID. PIR requests for patients which are not available in StoragePeak are ignored For PIR jobs no retry and visualization mechanisms are provided.

4.2.2 ADT A03 - Patient Discharge This message type is used to signal the end of a patient s stay in a healthcare facility by updating the location of a specific patient. StoragePeak accepts ADT A03 messages without further processing. MSH Segment 0001 Field Separator ST For this element is expected. 0002 Encoding Characters ST For this element ^~\& is expected. 0009 Message Type CM For this element ADT^A03 is expected. 0010 Message Control ID ST Used to fill the acknowledge message. 0011 Processing ID PT Used to fill the acknowledge message. 0012 Version ID VIT Used for HL7 version check and to fill the acknowledge message. PID Segment 0003 Patient Identifier List CX Used to identify the patient for the update process. If this field contains more than one identifier only the first one is used for patient identification. PV1 Segment 0003 Assigned Patient Location PL New assigned location for the specified patient. Constraints: A PIR process can only be performed for patients with a valid Patient ID. PIR requests for patients which are not available in StoragePeak are ignored

4.2.3 ADT A08 - Update Patient Information This message type is used to update demographic and visit information of a specific patient. MSH Segment 0001 Field Separator ST For this element is expected. 0002 Encoding Characters ST For this element ^~\& is expected. 0009 Message Type CM For this element ADT^A08 is expected. 0010 Message Control ID ST Used to fill the acknowledge message. 0011 Processing ID PT Used to fill the acknowledge message. 0012 Version ID VIT Used for HL7 version check and to fill the acknowledge message. PID Segment 0003 Patient Identifier List CX Used to identify the patient for the update process. If this field contains more than one identifier only the first one is used for patient identification. 0005 Patient Name XPN New name for the specified patient. If this field contains more than one name only the first one is used for the update process. 0007 Date/Time Of Birth TS New date/time of birth for the specified patient. 0008 Sex IS New sex for the specified patient. PV1 Segment 0003 Assigned Patient Location PL New assigned location for the specified patient. Constraints: A PIR process can only be performed for patients with a valid Patient ID. PIR requests for patients which are not available in StoragePeak are ignored. StoragePeak cannot perform a PIR process if it results in two or more identical patients. For PIR jobs no retry and visualization mechanisms are provided.

4.2.4 ADT A40 - Merge Patient (Patient Identifier List) This message type is used to merge two patients identified by the Patient ID or to modify the Patient ID value of a specific patient. MSH Segment 0001 Field Separator ST For this element is expected. 0002 Encoding Characters ST For this element ^~\& is expected. 0009 Message Type CM For this element ADT^A40 is expected. 0010 Message Control ID ST Used to fill the acknowledge message. 0011 Processing ID PT Used to fill the acknowledge message. 0012 Version ID VIT Used for HL7 version check and to fill the acknowledge message. PID Segment 0003 Patient Identifier List CX Used to identify the resulting patient of the merge process. MRG Segment 0001 Prior Patient Identifier List CX Used to identify the patient to be merged into the resulting patient. Notes: StoragePeak can handle only one merge request contained in an ADT A40 message. The message is discarded without further processing if the patient specified by Prior Patient Identifier List element of the MRG segment is not known to the StoragePeak database The patient demographics (Patient ID) of the patient specified by the Prior Patient Identifier List element of the MRG segment are updated if the patient specified by the Patient Identifier List element of the PID segment doesn t exist in StoragePeak. Constraints: A PIR process can only be performed for patients with a valid Patient ID. PIR requests for patients which are not available in StoragePeak are ignored. StoragePeak cannot perform a PIR process if it results in two or more identical patients. A patient cannot be merged into another patient with the same Patient ID. For PIR jobs no retry and visualization mechanisms are provided.

4.3 ORM Messages 4.3.1 ORM O01 Procedure Scheduled/Updated This message type is used to convey and update a scheduled procedure for a specific patient. StoragePeak accepts ORM O01 messages without further processing. MSH Segment 0001 Field Separator ST For this element is expected. 0002 Encoding Characters ST For this element ^~\& is expected. 0009 Message Type CM For this element ORM^O01 is expected. 0010 Message Control ID ST Used to fill the acknowledge message. 0011 Processing ID PT Used to fill the acknowledge message. 0012 Version ID VIT Used for HL7 version check and to fill the acknowledge message. PID Segment 0003 Patient Identifier List CX Used to identify the patient for the scheduled procedure. If this field contains more than one identifier only the first one is used for patient identification. 0005 Patient Name XPN Name of the patient. If this field contains more than one name only the first one is used for the update process. 0007 Date/Time Of Birth TS Date/time of birth of the patient. 0008 Sex IS Sex of the specified patient. PV1 Segment 0003 Assigned Patient Location PL Assigned location of the specified patient. 0007 Attending Doctor XCN Maps to DICOM Attending Physician 0008 Referring Doctor XCN Maps to DICOM Referring Physician 0015 Ambulatory Status IS 0019 Visit Number CX ORC Segment

0001 Order Control ID Order Control code, which is one of NW for scheduling new procedures CA for canceled procedures XA for updating procedures DC for discontinuing procedures 0002 Placer Order Number EI 0003 Filler Order Number EI 0005 Order Status ID 0012 Ordering Provider XCN 0017 Entering Organization CE OBR Segment 0004 Universal Service ID CE 0005 Priority ID 0018 Placer Field 1 ST Maps to the DICOM Accession Number 0019 Placer Field 2 ST Maps to the DICOM Requested Procedure ID 0020 Filler Field 1 ST Maps to the DICOM Scheduled Procedure ID 0024 Diagnostic Serv Sect ID ID 0031 Reason For Study CE 0044 Procedure Code CE Maps to DICOM Study Description ZDS Segment 0001 Study Instance UID RP Study Instance UID of the procedure, according to the IHE Technical Framework. The Study Instance UID is contained in the first component of the first field of the ZDS Segment actually.

4.4 ORU Messages 4.4.1 ORU R01 Observation Result This message type is used to convey an observation result for a specific procedure. StoragePeak accepts ORU R01 messages containing plain ASCII results in order to store them in the database. MSH Segment 0001 Field Separator ST For this element is expected. 0002 Encoding Characters ST For this element ^~\& is expected. 0009 Message Type CM For this element ORU^R01 is expected. 0010 Message Control ID ST Used to fill the acknowledge message. 0011 Processing ID PT Used to fill the acknowledge message. 0012 Version ID VIT Used for HL7 version check and to fill the acknowledge message. PID Segment 0003 Patient Identifier List CX ID of the patient. If this field contains more than one identifier only the first one is used for patient identification. 0005 Patient Name XPN Name of the patient. If this field contains more than one name only the first one is used for the update process. 0007 Date/Time Of Birth TS Date/time of birth of the patient. 0008 Sex IS Sex of the specified patient. PV1 Segment 0003 Assigned Patient Location PL Assigned location of the specified patient. 0007 Attending Doctor XCN Maps to DICOM Attending Physician 0008 Referring Doctor XCN Maps to DICOM Referring Physician 0015 Ambulatory Status IS 0019 Visit Number CX ORC Segment

0001 Order Control ID Order Control code, which is one of NW for scheduling new procedures CA for canceled procedures XA for updating procedures DC for discontinuing procedures 0002 Placer Order Number EI 0003 Filler Order Number EI 0005 Order Status ID 0012 Ordering Provider XCN 0017 Entering Organization CE OBR Segment 0001 Set-ID OBR SI Sequence number of the OBR, which increments up by one for each observation segment in the group. 0002 Placer Order Number EI Maps to the DICOM Accession Number 0006 Requested Date/Time TS OBX Segment 0001 Set-ID OBX SI Sequence number of the OBX, which increments up by one for each observation segment in the group. 0002 Value Type ID TX (Text, for alphanumeric responses that the program indicated may exceed 199 characters); 0005 Observation Value TX Actual result value or observation. The data type in OBX-2 Value Type indicates the format of the observation. The length of the observation field is variable, depending upon the value type. 0014 Date/Time of the Observation TS Date and Time Notes: StoragePeak can handle more than one observation results in one ORU R01 message. These multiple results are specified by separate OBR and OCX segment pairs. New results always overwrite previous versions. Constraints: Transporting observation results generally needs a unique order number. If this is not available, StoragePeak cannot process a procedure.

4.5 Acknowledge Messages 4.5.1 Message Contents StoragePeak responds to each received HL7 message with an appropriate acknowledge message. StoragePeak generated acknowledge messages contain the segments whose contents are listed in the following tables. MSH Segment 00001 Field Separator ST This element is always set to. 00002 Encoding Characters ST This element is always set to ^~\&. 00007 Date/Time Of Message TS Current date and time when the acknowledge message is created. 00009 Message Type CM This element is always set to ACK. 00010 Message Control ID ST Message Control ID value from the received message. 00011 Processing ID PT Processing ID value from the received message. 00012 Version ID VIT Version ID value from the received message. MSA Segment 00018 Acknowledgement Code ID see section Message Status for the used values. 00010 Message Control ID ST Message Control ID value from the received message. 4.5.2 Message Status The acknowledge message tells the sender of the HL7 request message the final processing status of the message. For this the acknowledge message contains status information in form of an Acknowledge Code and an Error Condition. The values in the following table are used by the HL7 Interface of StoragePeak. Status Acknowledge Code Description Success AA Message accepted Reject AR Message rejected (could not be stored in StoragePeak)

4.6 Attribute Mapping The attributes received with the HL7 messages are used to modify the DICOM objects which are stored within StoragePeak. This requires the mapping of the HL7 attributes into DICOM conform data types. In this chapter all the attributes are listed which are converted for the patient information reconciliation process and/or for scheduling procedures. If not mentioned otherwise, the following applied to all mappings: If the resulting value is longer than the maximum length allowed for the respective DICOM attribute, the value will be truncated. 4.6.1 Patient Information Reconciliation Patient Identifier List / Prior Patient Identifier List The HL7 Patient Identifier attributes are mapped to the DICOM attribute Patient ID. HL7 DICOM Item Element Name Type Tag Attribute Name VR 00106 Patient Identifier List Prior Patient Identifier List CX 0010,0020 Patient ID LO The resulting DICOM value contains the ID Number part of the Patient Identifier List / Prior Patient Identifier List element. If the resulting value is longer than the maximum length allowed for the DICOM attribute Patient ID (max. 64 characters per element) the value will be truncated. Patient Name The HL7 Patient Name attribute is mapped to the DICOM attribute Patient s Name. HL7 DICOM Item Element Name Type Tag Attribute Name VR 00108 Patient Name XPN 0010,0010 Patient s Name PN The resulting DICOM value consists of the following parts of the Patient Name element. The character ^ is used as delimiter. Trailing delimiters will be deleted. Family Name Given Name Middle Initial Or Name Prefix Suffix Example: Smith^John^J^III^DR

If the resulting value is longer than the maximum length allowed for the DICOM attribute Patient s Name (max. 64 characters per element) the value will be truncated. Date/Time Of Birth The HL7 Date/Time Of Birth attribute is mapped to the DICOM attributes Patient s Birth Date and Patient s Birth Time. HL7 DICOM Item Element Name Type Tag Attribute Name VR 00110 Date/Time Of Birth TS 0010,0030 Patient s Birth Date DA The resulting DICOM birth date value consists of year, month and day information in the format yyyymmdd. Following conditions must be kept to make further processing with this value possible: Year (yyyy) > 1752 (database constraint) Month (mm) between 1 and 12 Day (dd) between 1 and 31 Sex The HL7 Sex attribute is mapped to the DICOM attribute Patient s Sex. HL7 DICOM Item Element Name Type Tag Attribute Name VR 00111 Sex PL 0010,0040 Patient s Sex CS If the resulting value is longer than the maximum length allowed for the DICOM attribute Patient s Sex (max. 16 characters) the value will be truncated. The HL7 values will not be mapped to appropriate DICOM values if the HL7 element contains U, A or N which are not defined in the DICOM standard.