HL 7 Integration Guide

IntelePACS
3. 7. 1 and lat er
HL7 I nt egr at ion G uide
COPYRIGHT and data can be communicated, processed, manipulated, enhanced, stored,
© 2004-2017 Intelerad Medical Systems Incorporated. All Rights and displayed within the system and/or across computer networks at
Reserved. distributed locations. Post-processing of the images can be performed
using Multi Planar Reconstruction (MPR).
No portion of the contents of this publication may be reproduced or
transmitted in any form or by any means without the express written Mammographic images may only be interpreted using an FDA-cleared
permission of Intelerad Medical Systems Incorporated. monitor that meets technical specifications reviewed and cleared by FDA.
Except as expressly provided otherwise in writing, the information Typical users of this system are trained professionals, physicians, nurses,
provided in this document is provided AS IS, without any condition or and technicians.
warranty, whether written, oral, express, implied, legal, or statutory. No
condition or warranty of merchantability or fitness for a particular purpose CONTRAINDICATIONS—Lossy compressed images and digitized film
applies to anything provided by Intelerad except as expressly provided in screen images must not be reviewed for primary image interpretations.
writing within a Service or License Agreement. Without limiting the
foregoing, except as specifically set forth in a Service or License Caution: Federal law restricts this device to sale by or on the order of a
Agreement, Intelerad nor any of its suppliers warrants this documentation physician.
is or will be accurate, error free or meets or will meet user requirements.
MANUFACTURER
TRADEMARKS Intelerad Medical Systems Incorporated
Intelerad and the Intelerad logo, IntelePACS, InteleBrowser, IntelePACS 895 de la Gauchetiere St W, Suite 400
Browser, InteleViewer, Reporting Worklist Module, InteleOne, InteleOne Montreal, QC Canada H3B 4G1
XE, InteleFlex, Assignment Engine, InteleWeb, Acquisition Traffic
Controller, Multi-Method Reporting, Intelerad Pulse, IntelePACS 3D, DECLARATION OF CONFORMITY
Image Fusion, InteleSuite, InteleRIS, Flow, Nuage, Disaster Recovery We hereby certify that IntelePACS, a Class IIa Medical Device, is in
Services, Cloud Imaging Platform, Intelerad Peer Review, Panorama, compliance with Council Directive 93/42/EEC and marked with
InteleConnect, and InteleConnect EV are either registered trademarks or
trademarks of Intelerad Medical Systems Incorporated.
THIRD-PARTY TRADEMARKS
Adobe, Acrobat, and Reader are either registered trademarks or trademarks
of Adobe Systems Incorporated in the United States and/or other
countries. Firefox is a registered trademark of Mozilla Foundation in the
United States and other countries. Google Chrome browser is a registered
trademark of Google Inc. in the United States and other countries. Internet
Explorer is a registered trademark of Microsoft Corporation in the United AUSTRALIAN SPONSOR
States and other countries. Intel, Pentium, Pentium II Xeon, and Pentium Emergo Australia
III Xeon are trademarks or registered trademarks of Intel Corporation or its 201 Sussex Street, Darling Park, Tower 2, Level 20
subsidiaries in the United States and other countries. Microsoft and Sydney, NSW 2000, Australia
Windows are either registered trademarks or trademarks of Microsoft tel: +61.0.2.9006.1662
Corporation in the United States and/or other countries. NVIDIA is a
trademark or registered trademark of NVIDIA Corporation in the United
Title: IntelePACS HL7 Integration Guide
States and/or other countries. Oracle and Java are registered trademarks of
Oracle Corporation and or its affiliates. PowerScribe 360 is a trademark or Software version: 3.7.1 and later
registered trademark of Nuance Communications Inc. or its affiliates in the Date: April 13, 2017
United States and/or other countries. Sun, Sun Microsystems, and Java are Part number: RISEN3711IG-O Issue 005
trademarks or registered trademarks of Sun Microsystems, Inc. in the
United States and other countries. Safari, Mac, and OS X are trademarks of
Apple Inc., registered in the United States and other countries.
All other brand names, product names, or trademarks belong to their

respective holders.
INDICATIONS FOR USE

IntelePACS™ is a device that receives digital images and data from
various sources (such as, CT scanners, MR scanners, ultrasound systems,
R/F units, computer and direct radiographic devices, secondary capture
devices, scanners, imaging gateways, or other imaging sources). Images
Table of
Contents
1 Getting Started 1
About HL7 Integration with IntelePACS . . . . . . . . . . . . . . . . . . . . .2
Conforming to the IHE Technical Framework . . . . . . . . . . . . . . . . .2
Interpreting HL7 Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2
Specifying Patient Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Specifying Visit, Order, and Procedure Identifiers . . . . . . . . . . . . . .3
Ensuring Unique Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Working with DICOM Modality Worklists . . . . . . . . . . . . . . . . . . . .5
Connecting to Intelerad’s HL7 Integration Test Server . . . . . . . . . .5
2 Sending Order Messages 7

Scheduling a Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8
Marking a Patient as Arrived . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Marking a Procedure as Finished . . . . . . . . . . . . . . . . . . . . . . . . . 11
Cancelling a Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Descriptions of Fields for Order Messages . . . . . . . . . . . . . . . . . . 14
3 Sending Reports to IntelePACS 20

Sending a Report. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Sending an Addendum or Correction . . . . . . . . . . . . . . . . . . . . . . 22
Sending and Migrating Historical Reports . . . . . . . . . . . . . . . . . . . 23
Descriptions of Fields for Report Messages . . . . . . . . . . . . . . . . . . 23
4 Sending Administration Messages 27
Updating Patient Demographics. . . . . . . . . . . . . . . . . . . . . . . . . . 28
Merging Patient Demographics . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Accepted ADT Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5 Receiving Orders from IntelePACS 32

Receiving New Orders from AOG . . . . . . . . . . . . . . . . . . . . . . . . . 33
Receiving New Orders From OET . . . . . . . . . . . . . . . . . . . . . . . . 34
Receiving Orders Updated by Manual Order Completion . . . . . . . . 35
Receiving Orders Updated by Time-Based Completion . . . . . . . . . . 37
Receiving Orders Updated by Dictation . . . . . . . . . . . . . . . . . . . . 38
Receiving Cancelled Orders . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Descriptions of Fields for Order Messages . . . . . . . . . . . . . . . . . . 40
6 Receiving Reports from IntelePACS 42

About Receiving Reports from IntelePACS . . . . . . . . . . . . . . . . . . 43
Descriptions of Fields for Report Messages . . . . . . . . . . . . . . . . . 45
A HL7 Fields for Modality Worklists 47

Key Fields for DICOM Modality Worklists . . . . . . . . . . . . . . . . . . . 48
Descriptions of Fields for DICOM Modality Worklists . . . . . . . . . . . 48
B HL7 Fields for RIS-Driven Prefetching 52

Fields for RIS-Driven Prefetching . . . . . . . . . . . . . . . . . . . . . . . . . 53
Descriptions of Fields for RIS Prefetching . . . . . . . . . . . . . . . . . . 54
C HL7 Fields in IntelePACS 58

HL7 Fields for Order Entry Module . . . . . . . . . . . . . . . . . . . . . . . . 59
iv
1
Getting
Started
Many healthcare management systems use the Health Level Seven (HL7)
standard to transfer patient information to other systems. This guide
describes how to use HL7 to integrate your system with IntelePACS to
manage radiological orders, procedures, and reports.
In this Chapter:
About HL7 Integration with IntelePACS . . . . . . . . . . . . . . . . 2
Conforming to the IHE Technical Framework . . . . . . . . . . . . . 2
Interpreting HL7 Segments ........................ 2
Specifying Patient Identifiers ....................... 3
Specifying Visit, Order, and Procedure Identifiers . . . . . . . . . 3
Ensuring Unique Identifiers ........................ 4
Working with DICOM Modality Worklists . . . . . . . . . . . . . . . . 5
Connecting to Intelerad’s HL7 Integration Test Server . . . . . . 5
Conforming to the IHE Technical Framework
About HL7 Integration with IntelePACS

As an HL7 integrator, you can use this guide to connect your system to IntelePACS.
This chapter gives an overview of the concepts and terminology that the rest of this
guide uses to describe how to integrate your system with IntelePACS.
Conforming to the IHE Technical Framework

Some of the data that your system sends to and receives from IntelePACS must follow
extra requirements that the HL7 standard does not specify. IntelePACS expects these
extra requirements because it conforms to the Integrating the Healthcare Enterprise
(IHE) Technical Framework. This framework encourages interoperability among HL7
systems and Digital Imaging and Communications in Medicine (DICOM) systems.
For example, the HL7 standard specifies that field OBR-18 can contain arbitrary data
(HL7 2.4, section 4.5.3.18). However, the IHE Technical Framework specifies that this
HL7 field must contain the accession number for an order (IHE Technical Framework,
vol. II: Transactions, Rev 6.0, Table 4.4-6).
Interpreting HL7 Segments

The numbering scheme for fields in an HL7 message header (MSH) segment can cause
confusion when compared with the numbering scheme for fields in other segments:
• For MSH segments, field 1 specifies the field separator character. Field 2 specifies
encoding characters.
• For all other segments, field numbers start at 1.
Example of Field Numbering
1 2 3
MSH|^~\&|RIS|...
PID|||1234||...
1 2
3
In the MSH segment, field 1 must be the pipe character (“|”) and field 2 must be the
caret, tilde, backslash, and ampersand characters (“^~\&”).
2
Getting Started 1
Specifying Patient Identifiers

A patient identifier (patient ID) uniquely identifies a patient within the hospital or
radiology facility. A synonym for patient ID is Medical Record Number (MRN). For
related information, see “Ensuring Unique Identifiers” on page 4.
A patient ID must meet these requirements:
• Be unique among all applications that send HL7 data to IntelePACS and all
IntelePACS sites. Two or more patients cannot share the same patient ID.
• Contain a maximum of 20 characters including organization codes.
• Contain only alphanumeric, dash (-), dot (.), and underscore (_) characters. Other
characters are not recommended.
• Can be padded with leading or trailing spaces.
Note: If your system launches InteleViewer directly and your system uses
lowercase letters in patient IDs, then please consult the Intelerad RIS
Integration team. In this situation, InteleViewer might not be able to
successfully display images for a patient.
Specifying Visit, Order, and Procedure Identifiers

An HL7 system identifies each radiological order by an accession number. Each order
can have one or more procedures, each identified by a requested procedure ID.
Example of Orders and Procedures
Accession 37
Procedure 1 (right foot)
Accession 38
Procedure 1 (chest)
Procedure 2 (abdomen)
Procedure 3 (pelvis)
Some HL7 systems associate a visit number with one or more orders. Intelerad
recommends that your system not send visit numbers in HL7 data. If your system must
send visit numbers to IntelePACS, ensure that they are consistently associated with the
same accession numbers and patient IDs. For more information, see “Avoiding Order
Binding Errors” on page 30.
3
Ensuring Unique Identifiers
Requirements for Accession Numbers

An accession number must meet these requirements:
• Be unique among all applications that send HL7 data to IntelePACS and all
IntelePACS sites. See “Ensuring Unique Identifiers” on page 4.
• Contain only alphanumeric, dash (-), dot (.), and underscore (_) characters. Other
characters are not recommended.
• Can be padded with leading or trailing spaces.
Note: If your system uses lowercase letters in accession numbers, please
consult the Intelerad RIS Integration team. If your system launches
InteleViewer directly, then InteleViewer will not be able to display images for a
patient when there are lowercase letters in the accession numbers that your
system generates.
Requirements for Procedure IDs

A requested procedure ID must meet these requirements:
• Be unique among the procedures IDs in the order.
• Contain only alphanumeric, dash (-), dot (.), and underscore (_) characters.
Ensuring Unique Identifiers

To make sure that identifiers are unique across all incoming HL7 feeds, IntelePACS or
the sending application can add a suffix to any of these identifiers:
• patient ID
• accession number
• visit number
For example, a large radiological reading group uses IntelePACS to provide reading
services to many third-party imaging facilities, each with its own RIS. The reading
group must ensure that the identifiers from each of these imaging facilities are unique
in the PACS. To achieve this requirement, each facility appends its own unique
organization code to each of the identifiers that it sends to IntelePACS.
The need for adding a suffix to identifiers is determined by you (the HL7 integrator),
the radiology client, and Intelerad at the start of an HL7 integration project.
4
Getting Started 1
Working with DICOM Modality Worklists

IntelePACS can provide DICOM Modality Worklists (DMWLs). These worklists
allow scanners to directly query IntelePACS for orders, freeing technologists/
radiographers from manually typing order information into a scanner console. By
reducing typographical errors and time needed to prepare a scanner for a patient,
DMWLs dramatically improve the efficiency of a radiology facility and ensure better
patient safety.
Think of these worklists as buckets or bins that contain order information to be queried
by one or more modalities, such as CR scanners and ultrasound machines. When your
system schedules a procedure, it should specify which DMWL in IntelePACS should
be populated with that procedure.
For example, in the diagram below, a RIS identifies which DMWL to fill by specifying
a simple string within an HL7 message. With this information, IntelePACS fills a bin
for one of its DMWLs. The scanners, in turn, are configured to query the appropriate
DMWL in IntelePACS.
Example DMWLs in IntelePACS
RIS
IntelePACS
CTWL USWL MRWL
CT Scanner US Scanner 1 US Scanner 2 MR Scanner
For detailed information about how IntelePACS generates the DICOM data that is sent
to modalities, see Appendix A, “HL7 Fields for Modality Worklists”.
Connecting to Intelerad’s HL7 Integration Test Server

It is always a good idea to start testing an integration right away. For example, there is
often a risk that hardware is not available for a test system to be installed on-site until
late in a project. To encourage you to test your integration early in the project, Intelerad
offers a test server. This server is on the internet and is completely open for TCP
5
Connecting to Intelerad’s HL7 Integration Test Server
connections. For information on connecting to this server, contact your Intelerad RIS
Integration Specialist.
Respect Patient Confidentiality

Do not send confidential patient information to this server! This connection is not
encrypted, so always send anonymized test data only.
You should test your connectivity as early in the project as possible, well before your
project begins sending HL7 messages.
To connect to the integration test server:

1. Open a web browser from your test environment and try connecting to:
https://<test hostname>
where <test hostname> is the name of the test server provided to you by Intelerad.
If you see a login screen asking for a username and password, then you know you
can reach this server.
2. At a command line, type:
telnet <test hostname> 5005
A blank screen or no error indicates that you have successfully connected.
If you cannot connect successfully, the telnet command will report this error:
Could not open connection to the host, on port 5005:
Connect failed
3. Close the command line.
Note: If you encounter problems connecting to the test server, first verify
the Intelerad host name, IP address, and port (5005) that you are using are
correct. If the problem persists, a firewall or other network device might be
impeding your connection to the Intelerad test server. Please contact your
IT department to resolve this situation.
6
2
Sending Order
Messages
Your system can send order information to IntelePACS with ORM

messages. IntelePACS uses fields in these messages to manage the
radiology workflow and validate the images that it stores.
In this Chapter:
Scheduling a Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Marking a Patient as Arrived . . . . . . . . . . . . . . . . . . . . . . . . 9
Marking a Procedure as Finished . . . . . . . . . . . . . . . . . . . . 11
Cancelling a Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Descriptions of Fields for Order Messages . . . . . . . . . . . . . . 14
Scheduling a Procedure
Alerting IntelePACS that a procedure is scheduled is not required, but it is desirable.
IntelePACS can use the data in a scheduling message to configure RIS-driven
prefetching of prior images. The more HL7 fields that your system supplies, the more
precisely IntelePACS will be able to match its rules for prefetching studies, which
improves the radiologist’s workflow. For more information, see Appendix B, “HL7
Fields for RIS-Driven Prefetching”.
Physical Trigger Effect

The front desk schedules an order by Just before the scheduled time for the
entering it into a RIS. procedure, IntelePACS prefetches prior
studies for the radiologist’s convenience.
Below is an example of a scheduling message sent from an HL7 system to IntelePACS,

with all required and recommended fields filled:
MSH|^~\&|RIS|BCREEK|INTELEPACS|Intelerad|20080124164827||ORMÔ01|||2.3
PID|||1234||Brown^Roger^||19700203|M
PV1||||||||MHIBROY^Hibroy^M
ORC||885|885||SC
OBR||885|885|MRWL^SPINE||200710191649||||||||||||885|1|1||||CR
If your system is unable to assign an accession number to a study at the time of

scheduling, your system can send an SIU (scheduling message) instead of an
ORMÔ01 message. Note that an SIU message provides less useful information for
the IntelePACS RIS-prefetching service. For more information, see “HL7 Fields for
RIS-Driven Prefetching” on page 52.
The following table lists the required (R) and optional (O) fields for ORMÔ01
scheduling messages. Fields marked with an asterisk (*) might be required depending
on the IntelePACS workflow. For detailed information, see “Descriptions of Fields for
Order Messages” on page 14.
Seg Field Length Opt Definition

MSH 3 180 R Name of your sending application.
4 180 R Name of the sending facility.
5 180 R Name of receiving application (INTELEPACS).
6 180 R Name of receiving facility (Intelerad).
9 15 R Message type (ORMÔ01).
PID 3 20 R Patient ID/MRN.
5 64 R Patient Name.
7 26 R Patient Date of Birth (YYYYMMDD).
8 1 R Patient Sex (M, F, O, or blank).
8
Sending Order Messages 2

PV1 8 60 * Referring Physician.
19 20 O Visit Number. Should be suppressed in most
cases. See “Avoiding Order Binding Errors” on
page 30.
ORC 2 16 R Placer Order Number. Can be the accession
number.
3 16 R Filler Order Number. Can be the accession
number.
5 2 R Order Status (SC).
17 8 O Entering Organization.
OBR 2 16 R Placer Order Number. Can be the accession
number.
number.
4.1 185 to 248 * DICOM Modality Worklists.
4.2 64 O Study Description.
6 26 R Requested Date/Time (YYYYMMDDhhmm).
7 26 O Observation Date/Time (YYYYMMDDhhmm).
13 16K O Relevant Clinical Information.
16 60 * Ordering Provider.
18 16 R Accession Number.
19 16 R Requested Procedure ID.
20 16 R Scheduled Step ID (1).
24 2 R Modality.
31 250 O Reason for Study.
44 16 O Procedure Code (DICOM CodeValue).
ZDS 1 64 * Study Instance UID.
Marking a Patient as Arrived

IntelePACS must be alerted when the patient arrives and is about to be scanned, or as
close to that event as possible. With this information IntelePACS can fill the
appropriate DICOM Modality Worklist (DMWL) with relevant patient demographics
and the requested procedure name.

The front desk enters information in the IntelePACS fills the appropriate modality
RIS about the arrival of the patient. worklist bins with the orders for the
patient.
9
Marking a Patient as Arrived
Below is an example of an arrival message with the required fields filled:
PID|||1234||Brown^Roger^||19700203|M
ORC||885|885||IP
OBR||885|885|MRWL^NECK||200710191645|200710191700|||||||||||885|1|1||||CR
The following table lists the required (R) and optional (O) fields for patient arrival
messages. Fields marked with an asterisk (*) are recommended depending on the
IntelePACS workflow. For detailed information, see “Descriptions of Fields for Order
Messages” on page 14.

4 180 R Name of your sending facility.
19 20 O Visit Number. Should be suppressed in most cases.
See “Avoiding Order Binding Errors” on page 30.
number.
number.
5 2 R Order Status (IP).
10

number.
number.
4.2 64 R Study Description.
7 26 R Observation Date/Time (YYYYMMDDhhmm).
24 2 R Modality.
Marking a Procedure as Finished

Your system sends a completion message to IntelePACS to communicate that the
technologist/radiographer has completed a procedure.

Technologist/radiographer finishes taking IntelePACS removes the order from the
images. modality worklist and inserts it into the
radiologist’s worklist.
Below is an example of a procedure completion message with all required and

recommended fields filled:
PID|||1234||Brown^Roger^||19700203|M
ORC||885|885||CM
OBR||885|885|||||200710191723||||||||||885|1|1||||CR
The following table lists the required (R) and optional (O) fields for ORMÔ01
procedure completion messages. Fields marked with an asterisk (*) might be required,
11
Marking a Procedure as Finished
depending on IntelePACS workflow. For detailed information, see “Descriptions of

Fields for Order Messages” on page 14.

19 20 O Visit Number. Should be suppressed in most cases.
See “Avoiding Order Binding Errors” on page 30.
number.
number.
5 2 R Order Status (CM).
number.
number.
4.2 64 R Study Description.
7 26 R Observation Date/Time (YYYYMMDDhhmm).
8 26 O Observation End Date/Time
(YYYYMMDDhhmm).
24 2 R Modality.
32 200 * Principal Result Interpreter.
34 200 * Technician.
12

Cancelling a Procedure
Your system can alert IntelePACS that a procedure has been cancelled by sending a
cancellation message.

Although there are many reasons for IntelePACS sets the order to a special status,
triggering this event, the most common is “CA.” IntelePACS also removes the order
that the patient cancels an appointment. from modality worklists and hides related
reports from InteleViewer and IntelePACS
Browser.
Note: Your system must not re-use the accession numbers of cancelled orders
for new orders. Cancelling an order in IntelePACS is not the same as deleting
an order. Cancelling only marks the status of the cancelled order with the
special value “CA”.
Below is an example of a cancellation message with all required and recommended

fields filled:
PID|||1234||Brown^Roger^||19700203|M
ORC||885|885||CA
OBR||885|885|||||||||||||||885|1|1
The following table lists the required (R) and optional (O) fields for cancellation
messages. Fields marked with an asterisk (*) might be required, depending on the
IntelePACS workflow. For detailed information, see “Descriptions of Fields for Order
Messages” on page 14.

13
Descriptions of Fields for Order Messages

19 20 O Visit Number. Should be suppressed in most
cases. See “Avoiding Order Binding Errors” on
page 30.
number.
number.
5 2 R Order Status (CA).
number.
number.

This section describes some of the fields in order messages.
Patient ID (PID-3)
IntelePACS only accepts the first field component, PID-3.1, for the patient ID. Only
one patient ID may be specified in this component.
Referring Physician (PV1-8)

IntelePACS uses referring physician information in several ways:
• Displays it in the InteleViewer Report Viewer, the IntelePACS Browser Report
Viewer, and the Reporting Worklist.
• Triggers rules for RIS-driven prefetching.
• Grants access to studies through auto-linking.
14
• Automatically sends reports to referring physicians through the Report Distribution

Module.
Field Name Definition/Details

Component
PV1-8.1 Referring Physician ID A unique ID from your system for the
referring physician. This ID must match
the RIS ID configured in the
IntelePACS user account for this
physician.
PV1-8.2 - 8.4 Referring Physician LAST^FIRST^MIDDLE
Name
Note: If this field is empty, IntelePACS will use Ordering Provider (OBR-16) for
the referring physician information.
Entering Organization (ORC-17)

Entering Organization is a code for uniquely identifying the department or group to
which an order or report belongs. IntelePACS uses this information to restrict access
to patient information, for differentiating items in the Reporting Worklist, and for RIS-
driven prefetching.
Examples:
• A radiology practice offers its services to several clients, with each client using a
unique organization code. The PACS administrator can configure the PACS so that the
users from each client may only see the reports for their own orders.
• A radiologist can sort and filter studies in the Reporting Worklist to read studies for
specific organizations.
• A PACS administrator can configure the IntelePACS to prefetch studies for a
department’s orders that meet the clinical or regulatory requirements that this
department specifies.
Note: This field is required when the IntelePACS is configured for site code
restrictions. Orders and reports without this field are not accessible by users.
DICOM Modality Worklist Bin (OBR-4.1)

IntelePACS uses this data for filling DICOM Modality Worklists (DMWL) and for
RIS-prefetching. For more information see “Working with DICOM Modality
Worklists” on page 5.
The maximum length for a DMWL name is 16 characters. Your HL7 system may
specify more than one DWML specifying them as separate subcomponents. For
example: Worklist1&Worklist2&Worklist3. The total maximum length of
OBR-4 is 250 characters.
15
If your HL7 provides its own DMWL, then this component can be left blank but your
system is required to provide a ZDS segment.
Study Description (OBR-4.2)

IntelePACS presents the second component of the Universal Service ID (OBR-4) as
text to end users for the principal description for the study.
The maximum length for this component is 64 characters. The total maximum length
of all components in the OBR-4 field is 250 characters.
Observation End Date/Time (OBR-8)

The date and time that the technologist completes the imaging. If this field is not
supplied by the RIS, the IntelePACS server will use its own current date and time to
supply this information.
Relevant Clinical Information (OBR-13)

IntelePACS appends the contents of this field to the contents of the Reason for Study
(OBR-31) field. The InteleViewer Report Viewer and the patient history panel of the
To Read tab of the Reporting Worklist window present this combined text to the end
user.
Ordering Provider (OBR-16)

When a message does not specify Referring Physician (PV1-8), IntelePACS uses the
ordering provider information to specify the referring physician.
Note: If a message specifies PV1-8, the IntelePACS ignores the OBR-16 field.

Component
OBR-16.1 Ordering Provider ID A unique ID from your system. This ID
must match the RIS ID configured in the
physician.
OBR-16.2 - 16.4 Ordering Provider Name LAST^FIRST^MIDDLE
Procedure ID (OBR-19)
If orders from your system can have multiple procedures, then your system must
provide a unique ID for each procedure in the order. If your system only associates one
procedure to each order, then you can set this field to 1.
For more information, see “Specifying Visit, Order, and Procedure Identifiers” on
page 3.
16
Modality (OBR-24)
Scanners can use the following 2-letter codes when querying IntelePACS for their
worklists.
DICOM Modality Code Code Description

AS Angioscopy
CR Computed Radiography
CS Cystoscopy
CT Computed Tomography
DM Digital Microscopy
DR Digital Radiography
EC Echocardiography
ES Endoscopy
FS Fundoscopy
LP Laparoscopy
MG Mammography
MR Magnetic Resonance
NM Nuclear Medicine
OT Other
PT Positron Emission Tomography
RF Radio Fluoroscopy
TG Thermography
US Ultrasound
XA X-Ray Angiography
Reason for Study (OBR-31)

IntelePACS prepends the contents of this field to the beginning of the contents of the
Relevant Clinical Information (OBR-13) field. InteleViewer and Reporting Worklist
present this combined text to the end user.
Principal Result Interpreter (OBR-32)

In workflows where radiologists use your system to dictate reports, your system must
provide identifying information about the reporting radiologist and the time of
dictation. In workflows that use the Reporting Worklist from Intelerad, leave this field
blank.

Component
OBR-32.1 Radiologist ID A unique ID from your system for the
radiologist. This ID must match the RIS
ID configured in the IntelePACS user
account for this radiologist.
17

Component
OBR-32.2 - 32.4 Radiologist Name LAST^FIRST^MIDDLE
OBR-32.6 Dictation Date/Time YYYYMMDDhhmm
Technician (OBR-34)
In IntelePACS workflows with the Image Quality Review Module, your system must
provide identifying information about the technologist/radiographer and the starting
time of the procedure. IntelePACS uses this information to associate technical reviews
of images from radiologists with the technologist/radiographer who took the images.

Component
OBR-34.1.1 ID A unique ID from your system for the
technologist/radiographer. This ID must
match the RIS ID configured in the
technologist/radiographer.
OBR-34.1.2 - Name LAST&FIRST&MIDDLE
34.1.4
OBR-34.2 Date/Time YYYYMMDDhhmm
For example:
VSMITH&Smitch&Valentine&Michael^20090612140317
Procedure Code (OBR-44)

The scanner, typically a CR or DR modality, translates a procedure code to a sequence
of mouse clicks, keyboard strokes, or button presses for the scanner’s console. These
operations would otherwise be performed manually by the technologist/radiographer.
IntelePACS passes this code from your system to the scanner via the DICOM Modality
Worklist. For more information on the format of this code, see the documentation from
the manufacturer of the scanner.
Study Instance UID (ZDS)

When your system, typically a RIS, provides the DICOM Modality Worklist
(DMWL), your RIS must provide the ZDS segment. Make sure that the study instance
UID that your RIS provides to the modality is the same as the study instance UID that
it provides to IntelePACS. If this segment is missing, or the study instance UIDs that
the modality and IntelePACS receive are not consistent, then the images might not pass
validation in IntelePACS.
If your RIS can assign more than one procedure to an order, then your RIS must
provide a unique study instance UID for each procedure in an order.
18
If your RIS does not provide a DMWL, this segment is optional.

Below is an example of a ZDS segment:
ZDS|1.2.840.113619.2.55.3.1973400610.6285.1193307214.115
^Âpplication^DICOM
19
3
Sending
Reports to
IntelePACS
Your system can send inbound report and addendum information to

IntelePACS with ORU messages.
In this Chapter:
Sending a Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Sending an Addendum or Correction . . . . . . . . . . . . . . . . . 22
Sending and Migrating Historical Reports . . . . . . . . . . . . . . 23
Descriptions of Fields for Report Messages . . . . . . . . . . . . . 23
Sending Reports to IntelePACS 3
Sending a Report
A report message informs IntelePACS of a report for an existing order.

Report is dictated, transcribed, then IntelePACS displays report text in the
signed. report viewers in InteleViewer and
IntelePACS Browser.
Below is an example of a report message with all required fields filled:
MSH|^~\&|RIS|BCREEK|INTELEPACS|Intelerad|20080124164827||ORU^R01|||2.3
PID|||1234||Brown^Roger^||19700203|M
ORC||885|885||ZZ
OBR||885|885|||||||||||||||885|1|1||||||||||||48^Doe^John^^^20090116174405|
||52^Lee^Hugh^^^20090117083405
OBX|||||Original report.||||||F
The following table lists the required (R) and optional (O) fields for report and
addendum messages. Fields marked with an asterisk (*) might be required, depending
on the IntelePACS workflow. For detailed explanations of the fields for addenda, see
“Descriptions of Fields for Report Messages” on page 23.

9 15 R Message type (ORU^R01).
number.
number.
5 2 R Order Status (ZZ for final reports and ZY for
preliminary reports. In most cases only final
reports are sent to IntelePACS.)
21
Sending an Addendum or Correction

number.
number.
32 200 R Principal Result Interpreter.
35 200 R Transcriptionist.
OBX 5 64K R Observation Value.
11 1 R Result status.
Sending an Addendum or Correction

Your system sends a report message to inform IntelePACS of an addendum or
correction to an existing report for an existing order. The format for an addendum or
correction message is identical to a report message. For more information, see
“Sending a Report” on page 21.
Note: When your system sends an addendum or correction message to
IntelePACS, your system must include the original report, all prior addenda,
and all prior corrections. When IntelePACS receives a report message, it
overwrites its own report information with the new information.

Report addendum or correction is IntelePACS displays report text in the
finalized. report viewers in the InteleViewer and
IntelePACS Browser.
For detailed explanations of the fields for addenda, see “Descriptions of Fields for
Report Messages” on page 23.
Below is an example of an addendum message with all required fields filled:
PID|||1234||Brown^Roger^||19700203|M
ORC||885|885||ZZ
OBR||885|885|||||||||||||||885|1|1||||||||||||48^Doe^John^^^200901161744|||
52^Lee^Hugh^^^200901170834
OBX|||||This is an addendum<br>Original report.||||||F
22
Sending and Migrating Historical Reports

If your system will be sending historical reports to IntelePACS, these will be the first,
and possibly only, HL7 records for prior exams. To ensure that IntelePACS can
correctly associate these reports to prior exams, it is important that your HL7 system
provides all of the fields that would normally be sent at different stages of an order’s
life cycle.
When historical reports are presented to a user in a patient’s list of prior exams, these
fields are used to provide a brief overview of the study. It is particularly important to
send this information:
• Patient identification information in PID-3, PID-5, PID-7, and PID-8.
• Entering organization code in ORC-17.
• Study description in OBR-4.2
• Relevant study dates in OBR-6, OBR-7 and OBR-8. If you have only one timestamp
for the study, you can replicate it in OBR-6, OBR-7 and OBR-8.
• Accession number in OBR-18.
• Modality code in OBR-24.
• If you have information for the referring physician that should also be included in
PV1-8 or OBR-16.
Below is an example of a prior report with all of the required fields filled:
PID|||1234||Brown^Roger^||19700203|M
ORC||885|885||ZZ||||||||||||BCR
OBR||885|885|MRWL^NECK||200710191645|200710191700|200710191700||||||||||885
|1|1||||CR||||||||48^Doe^John^ ^^200901161744|||52^Lee^Hugh^^^200901170834
OBX|||||This is an historical report.||||||F
Descriptions of Fields for Report Messages

This section describes some of the fields in report messages.
Patient ID (PID-3)

23

Module.

Component
physician.
Name

driven prefetching.
Examples:
Relevant Clinical Information (OBR-13)

IntelePACS appends the contents of this field to the contents of the Reason for Study
(OBR-31) field. The InteleViewer Report Viewer and the patient history panel of the
To Read tab of the Reporting Worklist window present this combined text to the end
user.
24


Component
physician.
page 3.
Reason for Study (OBR-31)

IntelePACS prepends the contents of this field to the beginning of the contents of the
Relevant Clinical Information (OBR-13) field. InteleViewer and Reporting Worklist
present this combined text to the end user.

blank.

Component
25
Transcriptionist (OBR-35)
In workflows where transcriptionists use the RIS to transcribe reports, the RIS must
provide identifying information about the transcriptionist and the time of transcription.
In workflows that use the Transcription Module from Intelerad, leave this field blank.

component
OBR-35.1 Transcriptionist ID A unique ID from your system for the
transcriptionist. This ID must match
transcriptionist.
OBR-35.2 - 35.4 Transcriptionist Name LAST^FIRST^MIDDLE
OBR-35.6 Transcription Date/Time YYYYMMDDhhmm
26
4
Sending
Administration
Messages
Your system can send patient update and patient merge information to
IntelePACS with ADT messages.
In this Chapter:
Updating Patient Demographics . . . . . . . . . . . . . . . . . . . . 28
Merging Patient Demographics . . . . . . . . . . . . . . . . . . . . . 28
Accepted ADT Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Merging Patient Demographics
Updating Patient Demographics

Your system sends a patient update message to synchronize patient data in your system
with the patient and image data in IntelePACS.
Note: Update messages are important and necessary to keep patient data
consistent between your system and IntelePACS.

A patient informs the front desk staff of an IntelePACS updates all studies belonging
error in her family name, date of birth, or to that patient.
sex.
Below is an example of a patient update message:
MSH|^~\&|RIS|BCREEK|INTELEPACS|Intelerad|20080110164521||ADTÂ08|||2.3
PID|||1234||Brown^Roger^||19700512|M
The following table lists the required (R) and optional (O) fields for a demographic
update message. This message must contain at least one of the PID-5, PID-7, or PID-
8 fields, which are marked with an asterisk (*).
Seg Field Len Opt Definition

MSH 3 180 R Name of your sending application
4 180 R Name of your sending facility
5 180 R Name of receiving application (INTELEPACS)
6 180 R Name of receiving facility (Intelerad)
9 15 R Message type. See “Accepted ADT Events” on page
31.
PID 3 20 R Patient ID/MRN
5 64 * Updated Patient Name
7 26 * Updated Patient Date of Birth (YYYYMMDD)
8 1 * Updated Patient Sex (M, F, O, or blank)
Patient ID (PID-3)

Your system sends a merge message to instruct IntelePACS to move the studies for one
patient to another patient.
Warning: For every patient merge operation that your system performs on its
own data, it must also send a corresponding patient merge message to
IntelePACS.
28
Sending Administration Messages 4
After sending a merge message, your system should make sure that it receives an
acknowledgement message from IntelePACS and that this acknowledgement confirms
a successful merge operation.

The front desk staff assigns a new MRN to IntelePACS moves and updates all studies
an existing patient. Later, the front desk from a source patient to destination patient.
staff discovers that the patient already has IntelePACS deletes all demographic data
studies in IntelePACS under a different for the source patient.
MRN.
Note: A patient merge operation cannot be undone.

The only links between HL7 orders in your system and images in IntelePACS are the
accession number (OBR-18) and MRN (PID-3). It is therefore crucial that the
accession numbers and MRNs associated with images in the IntelePACS database
always match the same identifiers in your system’s database.
For example, these tasks depend on consistent data between your system and
IntelePACS:
• A referring physician can use your system to view images by launching InteleViewer
directly.
• IntelePACS can retrieve prior studies for viewing by a radiologist.
• Your system can attach reports to images that are stored in IntelePACS.
Upon receiving any ORM or ORU message, IntelePACS will check its database to
ensure that the MRN number in the message is consistent with messages that your
system has previously sent for the same accession number. If IntelePACS finds a
mismatch, it will reject the message to avoid the possibility of erroneously attaching a
procedure or report to the wrong patient, which could affect patient safety.
The only acceptable manner to change the MRN that is bound to orders is to send a
patient merge message to IntelePACS. This is an explicit request for IntelePACS to
bind all orders for a source MRN to the destination MRN. All subsequent ORM and
ORU messages that your system sends to IntelePACS for this patient will always
contain the destination MRN.
Below is an example of a patient merge message:
MSH|^~\&|RIS|BCREEK|INTELEPACS|Intelerad|20080124164827||ADTÂ18|||2.3
PID|||3322
MRG|3344
When IntelePACS receives this message, it moves and updates all studies for the
patient with MRN 3344 to the patient with MRN 3322. IntelePACS then deletes
demographics data for MRN 3344.
29
These fields are required to merge patient data:

MSH 3 180 R Name of your sending application
4 180 R Name of your sending facility
5 180 R Name of receiving application (INTELEPACS)
6 180 R Name of receiving facility (Intelerad)
9 15 R Message type (ADTÂ18)
PID 3 20 R Destination Patient ID/MRN
MRG 1 20 R Source Patient ID/MRN
Avoiding Order Binding Errors

The word binding comes from the notion that a single patient is bound to a visit or
accession number and that an accession number is bound to a single visit. The PACS
performs integrity tests to ensure that the data within the message received from your
HL7 system is consistent with the data in the IntelePACS before committing an update
to an order in the IntelePACS. This is especially important for reports where errors
could potentially affect diagnosis and possibly patient safety.
The PACS verifies that the following conditions are satisfied:
• For any given accession number (OBR-18) there can be only one patient (PID-3).
• There must be only one Patient ID (PID-3) associated with a Visit Number (PV1-19).
• An accession number (OBR-18) can only be associated with a single Visit Number
(PV1-19).
Intelerad advises that HL7 systems should not send visit numbers (PV1-19) to avoid
binding errors. If the HL7 system must send a PV1 segment that contains a PV1-19
field (Visit Number), then the PACS also verifies these conditions:
Examples of Binding Errors

In a case where your RIS performs a patient merge operation (the patient ID changes)
without sending a corresponding message to the IntelePACS, an order binding error is
likely to occur.
Binding errors can also be caused if the visit number is changed for a study.
Some HL7 software “recycle” accession numbers that are cancelled. This is highly
inadvisable and will result in binding errors.
30
Sending Administration Messages 4
Accepted ADT Events

The following table lists the ADT messages that IntelePACS accepts. When applying
updates, IntelePACS only uses the PID segment and ignores all other segments.
Message Description
Update ADTÂ02 Patient transferred
Events
ADTÂ06 Transfer outpatient to inpatient
ADTÂ07 Transfer inpatient to outpatient
ADTÂ08 Patient updated
ADTÂ09 Patient departing
ADTÂ10 Patient arriving
ADTÂ12 Cancel transfer
ADTÂ17 Bed swap
ADTÂ31 Update patient information
ADTÂ32 Cancel patient arriving
ADTÂ33 Cancel patient departing
Merge ADTÂ18 Patient merged
Events
ADTÂ30 Merge person
ADTÂ34 Merge patient information
ADTÂ40 Merge patient, internal ID
31
5
Receiving
Orders from
IntelePACS
In some workflows, your HL7 system can receive outbound orders from
IntelePACS.
In this Chapter:
Receiving New Orders from AOG . . . . . . . . . . . . . . . . . . . . 33
Receiving New Orders From OET . . . . . . . . . . . . . . . . . . . . 34
Receiving Orders Updated by Manual Order Completion . . . . 35
Receiving Orders Updated by Time-Based Completion . . . . . 37
Receiving Orders Updated by Dictation . . . . . . . . . . . . . . . 38
Receiving Cancelled Orders . . . . . . . . . . . . . . . . . . . . . . . 39
Descriptions of Fields for Order Messages . . . . . . . . . . . . . . 40
Receiving Orders from IntelePACS 5
Receiving New Orders from AOG

In some workflows, IntelePACS generates orders dynamically, only when it receives
DICOM data. The Automatic Order Generation (AOG) module generates these orders.
Trigger Effects
IntelePACS receives a study from a scanner AOG creates an order to associate with the
or from another PACS. study. If required by your workflow,
IntelePACS sends the order to your HL7
system.
Below is an example of an outbound ORMÔ01 message from the AOG module in

IntelePACS:
MSH|^~\&|IntelePACS|BCR|ReceivingApp|ReceivingFacility|20100423102832||ORM^
O01|20100423102832|P|2.3
PID|||1927228||Brown^Roger^||19700203|M
PV1||||||||^Hibroy^M|||||||||||G100423102832788
ORC|NW|AS443V7|AS443V7||OC||||||||||||BCR
OBR|||AS443V7|H1970CT1Âbdomen\S\ABD_PEL_WO||20100423093858|20100423102832|
20100423102832||||||||||AS443V7|1|1||||CT|||||||Fell off balcony.
The following table lists the fields that IntelePACS provides for ORMÔ01 messages
created by AOG.
Seg Field Length Definition

MSH 3 180 Name of the sending application, IntelePACS.
4 180 Name of the sending facility.
5 180 Name of receiving application.
6 180 Name of receiving facility.
9 15 Message type (ORMÔ01).
PID 3 20 Patient ID/MRN.
5 64 Patient Name.
7 26 Patient Date of Birth (YYYYMMDD).
8 1 Patient Sex (M, F, O, or blank).
PV1 8 60 Name of the Referring Physician. The ID is not provided.
19 20 Visit Number. Should be ignored.
ORC 2 16 Placer Order Number. It is the same as the accession
number.
3 16 Filler Order Number. It is the same as the accession
number.
5 2 Order Status (OC).
17 8 Entering Organization.
33
Receiving New Orders From OET

OBR 3 16 Filler Order Number. It is the accession number.
4.1 185 to 248 DICOM application entity (AE) title of the system that
sent the study.
4.2 64 Study Description.
6 26 Requested Date/Time (YYYYMMDDhhmm).
7 26 Order Created Date/Time (YYYYMMDDhhmm). This
date and time reflects when this order was generated by
AOG.
8 26 Order Created Date/Time (YYYYMMDDhhmm). The
same as OBR-7.
18 16 Accession Number.
19 16 Requested Procedure ID (1).
20 16 Scheduled Step ID (1).
24 2 Modality.
31 64 Reason for Study.
Receiving New Orders From OET

In some workflows, IntelePACS provides the Order Entry Tool (OET) to allow front-
desk staff to enter new orders.
Trigger Effects
A patient arrives at a radiology facility. The OET creates an order. If required by your
front desk enters an order into IntelePACS workflow, IntelePACS sends the order to
by using OET. your HL7 system.
It is also possible for authorized IntelePACS users to modify existing orders with OET.
For more details, see “HL7 Fields for Order Entry Module” on page 59.
Additional ORMÔ01 messages might be available for export to external HL7
systems for these events but is beyond the current scope of this document.
Below is an example of an outbound ORMÔ01 message from the OET module in
IntelePACS:
O01|20100427103041|P|2.3
PID|||1927228||Brown^Roger^||19700203|M
PV1||||||||ID101^Hibroy^M|||||||||||24A2
ORC|NW|24A2|24A2||IP||||||||||||BCR
OBR||24A2|24A2|SVCTWL1^SINUS-
WO|RO|201004271029||||||||||||24A2||1||||CT|||||||^LT NASAL PAIN
34
The following table lists fields that IntelePACS provides for orders created by OET
and sent from IntelePACS.

4 180 Name of the sending facility
5 64 Patient Name.
7 26 Patient Date of Birth (YYYYMMDD).
8 1 Patient Sex (M, F, O, or blank).
PV1 8 60 Name of the Referring Physician, including ID.
19 20 Visit Number. Same as accession number.
ORC 2 16 Placer Order Number. Same as the accession number.
3 16 Filler Order Number. Same as the accession number.
5 2 Order Status (IP).
17 8 Entering Organization.
OBR 2 16 Placer Order Number. Same as the accession number.
3 16 Filler Order Number. It is the accession number.
4.1 185 to 248 DICOM Modality Worklists.
4.2 64 Study Description.
6 26 Requested Date/Time (YYYYMMDDhhmm).
19 16 Requested Procedure ID.
24 2 Modality.
Receiving Orders Updated by Manual Order Completion

In some workflows, IntelePACS provides the provides the Order Completion and
Assignment tool to complete orders in IntelePACS.
Trigger Effects
An administrator marks an order as IntelePACS changes the status of the order
completed. to completed. If required by your
workflow, IntelePACS sends the updated
order to your HL7 system.
35
Receiving Orders Updated by Manual Order Completion
O01|20100427102004|P|2.3
PID|||A0905|
PV1||||||||ID101^Hibroy^M|||||||||||100379
ORC|XO|100379|100379||CM
OBR||100379|100379||||20100427092618|20100427102004|||||||||705-555-
1212|100379||1||||CT||||||||0203^Dolittle^D
The following table lists fields that IntelePACS provides for orders completed with the
Order Completion Tool and sent from IntelePACS. For detailed information about
some of these fields, see “Descriptions of Fields for Order Messages” on page 40.

9 15 Message type (ORMÔ01)
PV1 8 60 Name of the Referring Physician, including ID.
19 20 Visit Number.
5 2 Order Status (CM).
7 26 Observation Date/Time (YYYYMMDDhhmm)
8 26 Observation End Date/Time (YYYYMMDDhhmm)
17 250 Ordering physician callback telephone number.
24 2 Modality.
32 200 Principal Result Interpreter.
36
Receiving Orders Updated by Time-Based Completion

The time-based completion feature automatically marks an order as completed when
a scanner or other system stops sending images to the IntelePACS after a period of
time.
Trigger Effects
A modality finishes sending a study to IntelePACS changes the status of the order
IntelePACS and a configured time period to completed. If required by your
has elapsed. workflow, IntelePACS sends the updated
order to your HL7 system.
O01|20100426162603|P|2.3
PID|||1927228||Brown^Roger
PV1|||||||||||||||||||249A
ORC|XO|249A|249A||CM
OBR||249A|249A||||20100426160920|||||||||||249A||1
The following table lists fields that IntelePACS provides for orders updated by the
time-based completion feature and sent from IntelePACS.

9 15 Message type (ORMÔ01)
5 64 Patient Name.
PV1 19 20 Visit Number.
5 2 Order Status (CM).
8 26 Observation End Date/Time (YYYYMMDDhhmm)
37
Receiving Orders Updated by Dictation
Receiving Orders Updated by Dictation

The InteleViewer Reporting Worklist module allows users to mark an order as dictated.
Trigger Effects
A radiologist dictates a report and marks it IntelePACS changes the status of the order
as dictated in the InteleViewer Reporting to dictated. If required by your workflow,
Worklist. IntelePACS sends the updated order to
your HL7 system.
O01|20100427102606|P|2.3
PID|||1297228||Brown^Roger
PV1|||||||||||||||||||100420
ORC|XO|100420|100420||ZA
OBR||100420|100420|||||||||||||||100420||1||||||||||||0017^Hibroy^M^^^20100
427102606^^^^^192.168.13.140
The following table lists fields that IntelePACS provides for orders that are updated
when a radiologist marks an order as dictated using the InteleViewer Reporting
Worklist Module. For detailed information about some of these fields, see
“Descriptions of Fields for Order Messages” on page 40.

5 64 Patient Name.
5 2 Order Status (ZA).
32 200 Principal Result Interpreter.
38
Receiving Cancelled Orders

IntelePACS can alert your system that a procedure is cancelled.

Although there are many reasons for IntelePACS changes the status of the order
triggering this event, the most common is to cancelled. If required by your workflow,
that the patient cancels an appointment. IntelePACS sends the updated order to your
HL7 system.
O01|20100422161649|P|2.3
PID|||038492
PV1|||||||||||||||||||92E7
ORC|XO|92E7|92E7||CA
OBR||92E7|92E7|||||||||||||||92E7||1
The following table lists fields that IntelePACS provides for cancelled orders sent from
IntelePACS. For detailed information about some of these fields, see “Descriptions of
Fields for Order Messages” on page 40.

5 2 Order Status (CA).
39

This section describes some of the fields in order messages.

In outbound orders from IntelePACS to an HL7 system, IntelePACS provides
information about the radiologist who dictated the report.

Component
OBR-32.1 Radiologist ID A unique ID that is configured in the
radiologist.
OBR-32.11 IP Address The IP address of the workstation on
which the radiologist dictated a report
for this order. IntelePACS only provides
this information for orders that have
been marked as dictated using the
InteleViewer Reporting Worklist.
40
41
6
Receiving
Reports from
IntelePACS
In some workflows, your HL7 system can receive outbound reports from
IntelePACS.
In this Chapter:
About Receiving Reports from IntelePACS . . . . . . . . . . . . . 43
Descriptions of Fields for Report Messages . . . . . . . . . . . . . 45
Receiving Reports from IntelePACS 6
About Receiving Reports from IntelePACS

A report message from IntelePACS informs your system about a report for an order.
This section documents the public outbound report format for reports generated by the
Intelerad Results Reporting module. It does not cover formats produced by third party
transcription systems that interact with IntelePACS.
Physical Triggers Effects

A transcriptionist transcribes a If required by your workflow,
preliminary report into IntelePACS. IntelePACS is configured to send a
message to your system for the
preliminary report.
A transcriptionist transcribes an If required by your workflow,
addendum to a preliminary report into IntelePACS is configured to send a
IntelePACS. message to your system for the
preliminary addendum.
A radiologist finalizes a report or Your system receives a message for a
addendum in IntelePACS. final report or addendum.
An IntelePACS administrator marks a If required by your workflow
report as deleted. IntelePACS is configured to send a
message to your system for the report
deletion.
Below is an example of an outbound report message:
MSH|^~\&|INTELEPACS|Intelerad|RIS|BCREEK|20080124164827||ORU^R01|||2.3
PID|||1234||Brown^Roger^||19700203|M
ORC||885|885||ZZ||||||||||||BCR
OBR||885|885|||||||||||||||885|1|1|||||F|||||||48^Doe^John^^^2009011617440
5|||52^Lee^Hugh^^^20090117083405
OBX|1||||Original report.||||||F
This table lists the fields that IntelePACS uses to indicate the state of the outbound
report that it sends to your system.
Event ORC-5 OBR-25 OBX-11

Preliminary Report ZY P P
Preliminary Addendum ZY C C
Final Report ZZ F F
Final Addendum ZZ C C
Delete Report ZW D D
In a deleted report, IntelePACS appends a short phrase to the OBX-5 field that contains
the name of the user who deleted the report. This phrase also includes the date and time
that the report was deleted. For example:
43
Deleted by: Mary Hibroy (May 28, 2010 14:12:54)
The following table lists the fields that the IntelePACS sends. For detailed
explanations of these fields, see “Descriptions of Fields for Report Messages” on page
45.

MSH 3 180 Name of your sending application
4 180 Name of your sending facility
5 180 Name of receiving application (INTELEPACS)
6 180 Name of receiving facility (Intelerad)
PID 3 20 Patient ID/MRN
5 64 Patient Name
7 26 Patient Date of Birth (YYYYMMDD)
8 1 Patient Sex (M, F, O, or blank)
ORC 2 16 Placer Order Number. This number either comes from the
original order that was received from a RIS or generated
by IntelePACS.
3 16 Filler Order Number. This number either comes from the
by IntelePACS.
5 2 Order Status. Contains ZZ for final reports and ZY for
preliminary reports. In most cases only final reports are
sent from IntelePACS.
17 8 Entering Organization
OBR 2 16 Placer Order Number. This number either comes from the
by IntelePACS.
3 16 Filler Order Number. This number either comes from the
by IntelePACS.
18 16 Accession Number
19 16 Requested Procedure ID
20 16 Scheduled Step ID (1)
25 1 Observation Result Status. Contains P for preliminary, F
for final, C for addendum, and D for deleted.
32 200 Principal Result Interpreter
35 200 Transcriptionist
OBX 5 64K Observation Value, including the name of the user who
deleted the report and the date on which the report was
deleted.
11 1 Result status. Contains P for preliminary, F for final, C for
addendum, and D for deleted.
44
Receiving Reports from IntelePACS 6

This section describes some of the fields in report messages sent from IntelePACS.

driven prefetching.
Examples:
page 3.

In outbound reports from IntelePACS to an HL7 system, IntelePACS provides
information about the radiologist who dictated the report.

Component
OBR-32.1 Radiologist ID A unique ID that is configured in the
radiologist.
45
Transcriptionist (OBR-35)
In outbound reports from IntelePACS to an HL7 system, IntelePACS provides
information about the transcriptionist who entered a report.

component
OBR-35.1 Transcriptionist ID A unique ID that is configured in the
transcriptionist.
OBR-35.2 - 35.4 Transcriptionist Name LAST^FIRST^MIDDLE
OBR-35.6 Transcription Date/Time YYYYMMDDhhmm
46
A
HL7 Fields for
Modality
Worklists
This appendix lists key HL7 fields for the DICOM Modality Worklists
(DMWL) that IntelePACS provides.
In this Appendix:
Key Fields for DICOM Modality Worklists . . . . . . . . . . . . . . 48
Descriptions of Fields for DICOM Modality Worklists . . . . . . . 48
Descriptions of Fields for DICOM Modality Worklists
Key Fields for DICOM Modality Worklists

The following table shows the DICOM tags that IntelePACS provides to modalities.
IntelePACS translates HL7 data into DICOM data that modalities use to fill their
worklists.
The Max Length column specifies the maximum number of bytes for the DICOM tag.
DICOM HL7 Max

Length
(0008,0050) AccessionNumber OBR-18 16
(0008,0090) ReferringPhysiciansName PV1-8/ 60
OBR-16
(0010,0010) PatientsName PID-5 64
(0010,0020) PatientID PID-3 20
(0010,0030) PatientsBirthDate PID-7 26
(0010,0040) PatientsSex PID-8 1
(0020,000d) StudyInstanceUID ZDS-1 64
(0040,0100)>(0040,0007) OBR-4.2 64
ScheduledProcedureStepDescription
(0032,1060) RequestedProcedureDescription OBR-4.2 64
(0040,0100)>(0040,0002) ScheduledProcedureStepStartDate OBR-6 26
(0040,0100)>(0040,0002) ScheduledProcedureStepStartTime
(0040,1001) RequestedProcedureID OBR-19 16
(0040,0100)>(0008,0060) Modality OBR-24 2
(0008,0100) CodeValue OBR-44 16
Here is an example of a worklist on a scanner and the HL7 fields that were used to fill
the worklist columns.
Example of a DICOM Modality Worklist on a Scanner
OBR-18 PID-3 PID-5 PID-7 PID-8 OBR-6 OBR-4.2

This section gives detailed descriptions of some of the HL7 fields that are useful for
DICOM Modality Worklists (DMWL) that IntelePACS provides.
48
HL7 Fields for Modality Worklists A
Patient ID (PID-3)

Module.

Component
physician.
Name

49


Component
physician.
page 3.
Modality (OBR-24)
worklists.

AS Angioscopy
CS Cystoscopy
EC Echocardiography
ES Endoscopy
FS Fundoscopy
LP Laparoscopy
MG Mammography
NM Nuclear Medicine
OT Other
50
HL7 Fields for Modality Worklists A

TG Thermography
US Ultrasound
Procedure Code (OBR-44)

The scanner, typically a CR or DR modality, translates a procedure code to a sequence
of mouse clicks, keyboard strokes, or button presses for the scanner’s console. These
operations would otherwise be performed manually by the technologist/radiographer.
IntelePACS passes this code from your system to the scanner via the DICOM Modality
Worklist. For more information on the format of this code, see the documentation from
the manufacturer of the scanner.
51
B
HL7 Fields for
RIS-Driven
Prefetching
IntelePACS can prefetch studies based on HL7 data that it receives from
your system, typically a RIS. IntelePACS selects which studies to prefetch
by applying rules that refer to specific fields in this HL7 data.
In this Appendix:
Fields for RIS-Driven Prefetching . . . . . . . . . . . . . . . . . . . . 53
Descriptions of Fields for RIS Prefetching . . . . . . . . . . . . . . 54
HL7 Fields for RIS-Driven Prefetching B
Fields for RIS-Driven Prefetching

There are two types of messages that can be used to prefetch prior studies: ORM and
SIU messages.
RIS-Driven Prefetching from ORMÔ01 Messages

ORMÔ01 (“O-R-M-caret-O-zero-one”) messages are the preferred way to schedule
an order in IntelePACS. ORM messages allow your system to populate more fields,
which provides more flexibility in building the rules for prefetching. An ORM
message with status “scheduled” (SC) will automatically be considered for
prefetching. For more information, see “Scheduling a Procedure” on page 8.
Below is an example of an ORMÔ01 message. The fields that can be referred to by
prefetching rules are in bold.
MSH|^~\&|RIS|BCREEK|PACS|Intelerad|20080124164827||ORMÔ01|||2.3
PID|||1234||Brown^Roger^||19700203|M
ORC||885|885||SC||||||||||||BGR
OBR||885|885|MRWL^SPINE||200910191345|||||||||^^^FOOT|||885|1|1||||CR||||||
||48^Doe^John
RIS-Driven Prefetching from SIU^S12 Messages

If your system does not send an ORM message at scheduling time, your system can
instead transmit an SIU message. However, an SIU message does not provide as many
fields as an ORM message, which affects the precision and effectiveness for triggering
RIS-driven prefetch rules in IntelePACS.
The following message shows a sample SIU message coming to IntelePACS from an
HL7 system. The fields that can be referred to by prefetching rules are in bold.
MSH|^~\&|RIS|BCREEK|PACS|INTELERAD|20090113162500||SIU^S12||P|2.3
PID|||1234||Smith^Roger^||19700512|M
AIL|||USWL|US|BCR|200910191345
Fields for RIS-Driven Prefetching

IntelePACS RIS-driven prefetching rules refer to the fields listed in the following
table:
Name ORM Field SIU Field Details

Patient Id PID-3 PID-3
Patient Name PID-5 PID-5
Entering Organization ORC-17 AIL-5
53
Descriptions of Fields for RIS Prefetching
Name ORM Field SIU Field Details

Imaging Location OBR-4.1 AIL-3 See “DICOM Modality
Worklist Bin (OBR-4.1)”
on page 55.
Study Description OBR-4.2 See “Study Description
(OBR-4.2)” on page 56.
Study Date Time OBR-6 AIL-6 YYYYMMDDhhmm
Body Part Examined OBR-15.4 Also used for denoting
medical specialty in
Reporting Worklist.
Referring Physician PV1-8/OBR-16 See “Referring Physician
Name (PV1-8)” on page 54 and
“Ordering Provider (OBR-
16)” on page 56.
Accession Number OBR-18 See “Specifying Visit,
Order, and Procedure
Identifiers” on page 3.
Modality OBR-24 AIL-4
Radiologist OBR-32 See “Principal Result
Interpreter (OBR-32)” on
page 57.

This section gives detailed descriptions of some of the HL7 fields that are useful for
RIS prefetching by IntelePACS.
Patient ID (PID-3)

54

Module.

Component
physician.
Name

driven prefetching.
Examples:
DICOM Modality Worklist Bin (OBR-4.1)

IntelePACS uses this data for filling DICOM Modality Worklists (DMWL) and for
RIS-prefetching. For more information see “Working with DICOM Modality
Worklists” on page 5.
The maximum length for a DMWL name is 16 characters. Your HL7 system may
specify more than one DWML specifying them as separate subcomponents. For
example: Worklist1&Worklist2&Worklist3. The total maximum length of
OBR-4 is 250 characters.
55
If your HL7 provides its own DMWL, then this component can be left blank but your
system is required to provide a ZDS segment.



Component
physician.
Modality (OBR-24)
worklists.

AS Angioscopy
CS Cystoscopy
EC Echocardiography
ES Endoscopy
FS Fundoscopy
LP Laparoscopy
MG Mammography
NM Nuclear Medicine
OT Other
56

TG Thermography
US Ultrasound

blank.

Component
57
C
HL7 Fields in
IntelePACS
The HL7 data that IntelePACS receives is presented to users in many ways.
This appendix shows how the HL7 data received by IntelePACS is
displayed in IntelePACS Browser.
In this Appendix:
HL7 Fields for Order Entry Module . . . . . . . . . . . . . . . . . . . 59
HL7 Fields in IntelePACS C
HL7 Fields for Order Entry Module

The Order Entry Module in IntelePACS Browser uses these HL7 fields to fill the items
in the form for creating and modifying orders in IntelePACS.
IntelePACS HL7 Field Mapping
PID-8 PID-7 PID-3
OBR-24
PID-5 OBR-5
OBR-4.2
OBR-16
ORC-17
OBR-4.1
OBR-19
OBR-18
OBR-31 ORC-5 OBR-6
59
Document Revisions
Revisio- Date Modifications Authors

n
Version June 2, 2008 Initial creation of document. Sean

1.0 McGuire
Issue April 3, 2009 First release. Kate

001 Hanratty,
Anibal
Jodor-
covsky,
Sean
McGuire,
Marc
Paquette
Issue June 19, 2009 Changed title to HL7 Integration Kate

002 Guide. New policy on sending Hanratty,
visit numbers. Updated OBR-24, Anibal
PID-3, OBR-16, PV1, and OBR- Jodor-
34. Minor corrections. covsky,
Sean
McGuire,
Marc
Paquette
Issue March 26, Updated OBR-16, PV1-8, ORC- Kate

003 2010 17. New section, “Sending and Hanratty,
Migrating Historical Reports” on Sean
page 23. Applied rebranded McGuire,
layout. Marc
Paquette
Issue May 28, 2010 New chapter, “Receiving Orders Kate

004 from IntelePACS” on page 32. Hanratty,
New chapter, “Receiving Reports Sean
from IntelePACS” on page 42. McGuire,
Marc
Paquette
Issue April 13, 2017 Updated the cover page and Irene Plokar
005 headers with Intelerad's recent
corporate logo.

HL 7 Integration Guide

Uploaded by

Copyright:

Available Formats

HL 7 Integration Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HL 7 Integration Guide

Uploaded by

Copyright:

Available Formats

IntelePACS

All other brand names, product names, or trademarks belong to their

INDICATIONS FOR USE

2 Sending Order Messages 7

3 Sending Reports to IntelePACS 20

5 Receiving Orders from IntelePACS 32

6 Receiving Reports from IntelePACS 42

A HL7 Fields for Modality Worklists 47

B HL7 Fields for RIS-Driven Prefetching 52

C HL7 Fields in IntelePACS 58

About HL7 Integration with IntelePACS

Conforming to the IHE Technical Framework

Interpreting HL7 Segments

Specifying Patient Identifiers

Specifying Visit, Order, and Procedure Identifiers

Procedure 1 (right foot)

Requirements for Accession Numbers

Requirements for Procedure IDs

Ensuring Unique Identifiers

Working with DICOM Modality Worklists

CTWL USWL MRWL

CT Scanner US Scanner 1 US Scanner 2 MR Scanner

Connecting to Intelerad’s HL7 Integration Test Server

Respect Patient Confidentiality

To connect to the integration test server:

Your system can send order information to IntelePACS with ORM

Physical Trigger Effect

Below is an example of a scheduling message sent from an HL7 system to IntelePACS,

If your system is unable to assign an accession number to a study at the time of

Seg Field Length Opt Definition

Seg Field Length Opt Definition

Marking a Patient as Arrived

Physical Trigger Effect

Below is an example of an arrival message with the required fields filled:

Seg Field Length Opt Definition

Seg Field Length Opt Definition

Marking a Procedure as Finished

Physical Trigger Effect

Below is an example of a procedure completion message with all required and

depending on IntelePACS workflow. For detailed information, see “Descriptions of

Seg Field Length Opt Definition

Seg Field Length Opt Definition

Physical Trigger Effect

Below is an example of a cancellation message with all required and recommended

Seg Field Length Opt Definition

Seg Field Length Opt Definition

Descriptions of Fields for Order Messages

Referring Physician (PV1-8)

• Automatically sends reports to referring physicians through the Report Distribution

Field Name Definition/Details

Entering Organization (ORC-17)

DICOM Modality Worklist Bin (OBR-4.1)

Study Description (OBR-4.2)

Observation End Date/Time (OBR-8)

Relevant Clinical Information (OBR-13)

Ordering Provider (OBR-16)

Field Name Definition/Details

DICOM Modality Code Code Description

Reason for Study (OBR-31)