HL7 Conformance Statement

HL7
Conformance
Statement
Version 1.70
0197
EN 04
ImagePilot HL7 Conformance Statement
Revision History
Date Version Description

August 28, 2009 Rev. 1.0
April 1, 2010 Rev. 1.1 Values that can be assigned to “ORC-1 Order Control” are added.
November 26, 2010 Rev. 1.2 SIU type message receiving and ORU type message sending are added.
May 12, 2011 Rev. 1.3 MDM type message sending is added.
Combination of OBX-2 and OBX-5 is added to “5.9 OBX – OBSERVATION RESULT
July 10, 2012 Rev. 1.4
SEGMENT”.
September 4, 2012 Rev. 1.5 Correct the value of “5.8 OBR-OBSERVATION REQUEST SEGMENT OBR-4”.
January 18, 2013 Rev. 1.6 Revision of “5. Message Construction Rules ImagePilot FIELD CONTENT”.
April 1, 2013 Rev. 1.7 Change of the company name.
September 25, 2014 Rev. 1.8 Message Definition
July 17, 2015 Rev. 1.9 Changed the design of cover page.
September 18, 2015 Rev. 2.0 Changed the design of cover page.
Notice: Specifications in this document are subject to change without notice.
Copyright © 2009 - 2015 Konica Minolta, Inc. All Rights Reserved. Printed in JPN.
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form, by any
means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of
i
Table of Contents
1. INTRODUCTION ........................................................................................................................ 1
2. OVERVIEW ................................................................................................................................. 1
3. IMPLEMENTATION MODEL ................................................................................................... 2

3.1 APPLICATION DATA FLOW ............................................................................................................2
3.2 HL7 MESSAGE AND ITS COMPONENTS ...........................................................................................2
3.3 FIELDS AND FIELD ATTRIBUTES ....................................................................................................3
4. SUPPORTED MESSAGE TYPES AND EVENT TYPES ............................................................ 4
4.1 ADT TYPE MESSAGES .................................................................................................................4
4.2 ORM TYPE MESSAGES .................................................................................................................7
4.3 SIU TYPE MESSAGES ...................................................................................................................9
4.4 ORU TYPE MESSAGES ...............................................................................................................10
4.5 MDM TYPE MESSAGES ..............................................................................................................11
5. MESSAGE CONSTRUCTION RULES ..................................................................................... 12
5.1 MESSAGE DELIMITERS ...............................................................................................................12
5.2 MSH – MESSAGE HEADER SEGMENT ...........................................................................................12
5.3 EVN – EVENT TYPE SEGMENT ....................................................................................................13
5.4 PID – PATIENT IDENTIFICATION SEGMENT ...................................................................................14
5.5 PV1 – PATIENT VISIT SEGMENT...................................................................................................15
5.6 MRG – MERGE PATIENT SEGMENT ..............................................................................................15
5.7 ORC – COMMON ORDER SEGMENT ..............................................................................................16
5.8 OBR – OBSERVATION REQUEST SEGMENT ...................................................................................17
5.9 OBX – OBSERVATION RESULT SEGMENT .....................................................................................18
5.10 ZDS – STUDY INSTANCE UID SEGMENT .......................................................................................20
5.11 SCH – SCHEDULE ACTIVITY INFORMATION SEGMENT ........................................................21
5.12 TXA-TRANSCRIPTION DOCUMENT HEADER SEGMENT .......................................................22
6. COMMUNICATIONS ENVIRONMENT .................................................................................. 24
6.1 LOWER LEVEL PROTOCOL ..........................................................................................................24
6.2 FAULT TOLERANCE ....................................................................................................................24
ii
1. Introduction
This document describes the electronic data exchange of the ImagePilot HL7 compliant
interfaces. It covers field mappings from ImagePilot software modules to ANSI/HL7
standard Version 2.3 and implementation-specific message creation and processing rules.
2. Overview
The Health Level Seven Standard (HL7) is used for data exchange between healthcare
computer systems. It does not require a specific computer operating system, programming
language or communication protocol for its implementation.
HL7's mission is: "To provide (global) standards for the exchange, management and
integration of data that supports clinical patient care and the management, delivery and
evaluation of healthcare services. Specifically, to create flexible, cost effective approaches,
standards, guidelines, methodologies, and enable healthcare information system
interoperability and sharing of electronic health records."
1
3. Implementation Model
ImagePilot receives message from external EMR/PMS/HIS/RIS, saves information to

internal database about HL7. Stored data will be used in ImagePilot later. TCP/IP
communication protocol is being used in ImagePilot implementation.
3.1 APPLICATION DATA FLOW
3.1.1 Receive HL7 message
ADT, ORM, SIU are supported.
1. Request sending ImagePilot
EMR/PMS/HIS/RIS
HL7 Service Data base
2. Response Acknowledge
3.1.2 Send HL7 message
ORU, MDM are supported.
ImagePilot 1. Request sending
EMR/PMS/HIS/RIS
HL7
Service
2. Response Acknowledge
3.2 HL7 MESSAGE AND ITS COMPONENTS
3.2.1 Message
Message is the atomic unit of data transferred between systems. It is comprised of a group
of segments in a defined sequence. The message type defines its purpose. For example,
ADT type message is used to transmit Patient Administration data.
2
3.2.2 Segment
Segment is a logical grouping of data fields. Segments may be required or optional. They
may be allowed to repeat. Each segment is given a name. For example: Message Header
(MSH), Event Type (EVN), Patient Identification (PID), etc.
3.2.3 Field
A field is a string of characters. Null (“”) is a possible value. It is different than omitting
the field. Omitted fields keep data value with no change, while null fields reset existing data
to null.
3.3 FIELDS AND FIELD ATTRIBUTES

Each field has the following
attributes specified:
SEQ - Position
LEN - Maximum length
DT - Data Type
OPT - Optionality (R, O, C, X, B)
The designations
R - required
O - optional
C - conditional on the trigger event or on some other field(s).
The field definitions following the segment attribute table
should specify the algorithm that defines the conditionality
for this field.
X - not used with this trigger event
B - left in for backward compatibility with previous versions of
HL7. The field definitions following the segment attribute
table should denote the optionality of the field for prior
versions.
Name - ELEMENT NAME
ImagePilot Value - Contents of the field in a typical ImagePilot data exchange
Fields are further divided into components and subcomponents and some fields may be
repeated a number of times.
The ImagePilot message construction rules follow the HL7 Version 2.3 recommendations.
For a more detailed description of attributes, please refer to the HL7 Standard.
3
4. Supported Message Types and Event Types
ImagePilot data exchange interfaces support different message types and events, all in
conformance with ANSI/HL7 standard Version 2.3.
4.1 ADT TYPE MESSAGES

The ADT message is used to send schedule request or appointment. ImagePilot software
modules use ADT messages for import and update of patient demographic data.
The following table lists the events supported by the ImagePilot ADT interface.
Event Types Supported by ImagePilot ADT Interface
VALUE DESCRIPTION
A01 ADT/ACK - Admit/visit notification
A04 ADT/ACK - Register a patient
A05 ADT/ACK - Pre-admit a patient
A08 ADT/ACK - Update patient information
A40 ADT/ACK - Merge patient information – Patient Identifier List
Message Definition by ImagePilot ADT Interface
ADTÂ01, A04, A08 ADT Message
MSH Message Header
[{SFT}] Software Segment
EVN Event Type
PID Patient Identification
[PD1] Additional Demographics
[{ROL}] Role
[{NK1}] Next of Kin / Associated Parties
PV1 Patient Visit
[PV2] Patient Visit- Additional Info
[{ROL}] Role
[{DB1}] Disability Information
[{OBX}] Observation Result
[{AL1}] Allergy Information
[{DG1}] Diagnosis
[DRG] Diagnosis Related Group
[{
4
PR1 Procedures
[{ROL}] Role
}]
[{GT1}] Guarantor
[{
IN1 Insurance
[IN2] Insurance Additional Information
[{IN3}] Insurance Additional Information, Certification
[{ROL}] Role
}]
[ACC] Accident Information
[UB1] Universal Bill Information
[UB2] Universal Bill 92 Information
[PDA] Patient Death and Autopsy
ADTÂ05 ADT Message
MSH Message Header
[{SFT}] Software Segment
EVN Event Type
[{ROL}] Role
[{NK1}] Next of Kin / Associated Parties
PV1 Patient Visit
[{ROL}] Role
[{DB1}] Disability Information
[{DG1}] Diagnosis
[DRG] Diagnosis Related Group
[{
PR1 Procedures
[{ROL}] Role
}]
[{GT1}] Guarantor
5
[{
IN1 Insurance
[{IN3}] Insurance Additional Information, Certification
[{ROL}] Role
}]
[ACC] Accident Information
[UB1] Universal Bill Information
[UB2] Universal Bill 92 Information
ADTÂ40 ADT Message
MSH Message Header
EVN Event Type
MRG Merge Patient
[PV1] Patient Visit
6
4.2 ORM TYPE MESSAGES

The ORM message is used to transfer radiology order information. ImagePilot software
modules use ORM messages for import and update of procedure order data.
The following table lists the events supported by the ImagePilot ORM interface.
The ZDS segment by IHE is also supported.
Event Types Supported by ImagePilot ORM Interface
VALUE DESCRIPTION
O01 ORM/ACK - Order message
Message Definition by ImagePilot ORM Interface
ORM General Order Message
MSH Message Header
[{NTE}] Notes and Comments (for Header)
[EVN] Event Type
[{NTE}] Notes and Comments (for Patient ID)
PV1 Patient Visit
[{
IN1 Insurance
[IN3] Insurance Additional Information, Certification
}]
[GT1] Guarantor
ORC Common Order
OBR Observation Request
[{NTE}] Notes and Comments (for Detail)
7
[{DG1}] Diagnosis
[{
OBX Observation Result
[{NTE}] Notes and Comments (for Results)
}]
[{CTI}] Clinical Trial Identification
[BLG] Billing Segment
[ZDS] Study Instance UID
8
4.3 SIU TYPE MESSAGES

The SIU message is used to send schedule request or appointment. ImagePilot software
modules use SIU messages for import and update of patient demographic data.
The following table lists the events supported by the ImagePilot SIU interface.
Event Types Supported by ImagePilot SIU Interface
VALUE DESCRIPTION
S12 SIU/ACK - Notification of new appointment booking
S14 SIU/ACK - Notification of appointment modification
S15 SIU/ACK - Notification of appointment cancellation
Message Definition by ImagePilot SIU Interface
SIU Schedule Information Unsolicited
MSH Message Header
SCH Schedule Activity Information
[{NTE}] Notes and Comments for the SCH
[{
[PV1] Patient Visit
[{DG1}] Diagnosis
}]
RGS Resource Group Segment
[{
AIS Appointment Information - Service
[{NTE}] Notes and Comments for the AIS
}]
[{
AIG Appointment Information - General Resource
[{NTE}] Notes and Comments for the AIG
}]
[{
AIL Appointment Information - Location Resource
[{NTE}] Notes and Comments for the AIL
}]
9
[{
AIP Appointment Information - Personnel Resource
[{NTE}] Notes and Comments for the AIP
}]
4.4 ORU TYPE MESSAGES

The ORU message is used to send observation reporting. ImagePilot software modules use
ORU messages for sending link to image study information.
The following table lists the events supported by the ImagePilot ORU interface.
Event Types Supported by ImagePilot ORU Interface
VALUE DESCRIPTION
R01 ORU/ACK - Unsolicited transmission of an observation message
Message Definition by ImagePilot ORU Interface
ORU Unsolicited Observation Message
MSH Message Header
PV1 Patient Visit
ORC Common Order
{OBX} Observation Result
10
4.5 MDM TYPE MESSAGES
The MDM message is used to send observation reporting. ImagePilot software modules use
MDM messages for sending link to image study information.
The following table lists the events supported by the ImagePilot MDM interface.
Event Types Supported by ImagePilot MDM Interface
VALUE DESCRIPTION
T02 MDM/ACK - Original document notification and content
Message Definition by ImagePilot MDM Interface
MDM Original Document Notification & Content
MSH Message Header
PV1 Patient Visit
ORC Common Order
TXA Transcription Document Header
{OBX} Observation Result
11
5. Message Construction Rules
5.1 MESSAGE DELIMITERS

The ImagePilot interfaces follow HL7 Version 2.3 recommended message delimiters as
follows:
Delimiter Suggested Value Usage
Segment Terminator <cr> Terminates a segment record. This value cannot be changed by
Hex 0D implementors.
Field Separator | Separates two adjacent data fields within a segment. It also separates
the segment ID from the first data field in each segment.
Component Separator ^ Separates adjacent components of data fields where allowed.
Subcomponent Separator & Separates adjacent subcomponents of data fields where allowed.
If there are no subcomponents, this character may be omitted.
Repetition Separator ~ Separates multiple occurrences of a field where allowed.
Escape Character \ Escape character for use with any field represented by an ST, TX or
FT data type, or for use with the data (fourth) component of the ED
data type If no escape characters are used in a message, this
character may be omitted. However, it must be present if
subcomponents are used in the message.
5.2 MSH – MESSAGE HEADER SEGMENT

The Message Header Segment is used to convey intent, content, source,
destination, and some specifics of the syntax of a message. The Message Header
Segment is constructed as follows:
Message Header Segment (MSH) Attributes
SEQ LEN DT OPT ELEMENT NAME ImagePilot FIELD CONTENT
1 1 ST R Field Separator “|”

2 4 ST R Encoding Characters “^~\&”
3 180 HD R Sending Application ImagePilot
4 180 HD O Sending Facility Facility Name or Facility Code
(ORU/MDM Message Only)
5 180 HD O Receiving Application
6 180 HD O Receiving Facility Facility Name or Facility Code
(ORU/MDM Message Only)
7 26 TS O Date/Time Of Message YYYYMMDDHHMMSS
8 40 ST O Security
9 7 CM R Message Type Message TypeÊvent Code
10 20 ST R Message Control ID Unique number
11 3 PT R Processing ID P
12 60 VID R Version ID “2.3”
13 15 NM O Sequence Number
12
14 180 ST O Continuation Pointer

15 2 ID O Accept Acknowledgment Type
16 2 ID O Application Acknowledgment Type
17 2 ID O Country Code
18 16 ID O Character Set
19 60 CE O Principal Language Of Message
20 20 ID O Alternate Character Set Handling
Scheme
MSH field definitions
MSH-1 Field Separator (ST) 00001

This field contains the separator between the segment ID and the first real field, MSH-2-
encoding characters. As such it serves as the separator and defines the character to be used
as a separator for the rest of the message. Recommended value is |, (ASCII 124).
MSH-2 Encoding Characters (ST) 00002

This field contains the four characters in the following order: the component separator,
repetition separator, escape character, and subcomponent separator. Recommended values
are ^~\&, (ASCII 94, 126, 92, and 38, respectively).
MSH-3 Sending Application (HD) 00003

This field uniquely identifies the sending application
MSH-9 Message Type (MSG) 00009

This field contains the message type, trigger event, and abstract message structure code for
the message. The receiving system uses this field to recognize the data segments , and
possibly, the application to which to route this message.
Example:
MSH|^~\&|IMAGE PILOT||7000||20040416135703||ADTÂ04|AAAAAA|P|2.3
5.3 EVN – EVENT TYPE SEGMENT

The Event Type Segment is used to communicate necessary trigger event information to
receiving applications. The Event Type Segment is constructed as follows:
Event Type Segment (EVN) Attributes
1 3 ID B Event Type Code

2 24 DTM R Recorded Date/Time YYYYMMDDHHMMSS
3 24 DTM O Date/Time Planned Event
4 3 IS O Event Reason Code
13
5 250 XCN O Operator ID

6 24 DTM O Event Occurred
7 241 HD O Event Facility
EVN field definition
EVN-2 Recorded Date/Time (TS) 00100

Most systems will default to the system date/time when the transaction was entered, but they
should also permit an override.
Example:
EVN||20090816102345
5.4 PID – PATIENT IDENTIFICATION SEGMENT

The Patient Identification Segment is used to convey patient identification information.
It contains permanent patient identifying and demographic information.
The Patient Identification Segment is constructed as follows:
Patient Identification Segment (PID) Attributes
1 4 SI O Set ID - PID
2 20 CX B Patient ID
3 20 CX R Patient Identifier List Patient ID
4 20 CX B Alternate Patient ID - PID
5 48 XPN R Patient Name Patient Name
6 48 XPN O Mother’s Maiden Name
7 26 TS O Date/Time of Birth
8 1 IS O Sex
PID field definitions
PID-3 Patient ID (internal ID) (CX) 00106

This field contains the list of identifiers (one or more) used by the facility to uniquely
identify a patient (e.g., medical record number, billing number, birth registry, national
unique individual identifier, etc.).
PID-5 Patient Name (XPN) 00108

This data type includes multiple free text components. The sending system may send upper-
and lowercase or all uppercase. The receiving system may convert to all uppercase if
required.
This field contains the legal name of the patient.
Example:
PID|||98999000||Henry^Jacobson
14
5.5 PV1 – PATIENT VISIT SEGMENT

The Patient Visit Segment is used by Registration/Patient Administration applications to
communicate information on an account or visit-specific basis. The Message Header
Segment is constructed as follows:
Patient Visit Segment (PV1) Attributes
1 4 SI O Set ID –PV1
2 1 IS R Patient Class “I” or “O”
3 80 PL O Assigned Patient Location
PV1 field definitions
PV1-2 Patient Class (IS) 00132

A common field used by systems to categorize patients by site. It does not have a consistent
industry-wide definition. Subject to site-specific variations. Refer to user-defined table 0004
- patient class for suggested codes.
Example:
PV1||O
5.6 MRG – MERGE PATIENT SEGMENT

The Merge Patient Segment provides receiving applications with information necessary to
initiate the merging of patient data as well as groups of records. The Merge Patient Segment
is constructed as follows:
Merge Patient Segment (MRG) Attributes
1 250 CX R Prior Patient Identifier List Prior Patient ID

2 250 CX B Prior Alternate Patient ID
3 250 CX O Prior Patient Account Number
4 250 CX B Prior Patient ID
5 250 CX O Prior Visit Number
6 250 CX O Prior Alternate Visit ID
7 250 XPN O Prior Patient Name
MRG field definitions
MRG-1 Prior Patient Identifier List (CX) 00211

This field contains the prior patient identifier list. This field contains a list of potential "old"
numbers to match. Only one old number can be merged with one new number in a
transaction.
15
Example:
MRG|3001
5.7 ORC – COMMON ORDER SEGMENT

The Common Order Segment is used to transmit fields that are common to all orders (all
types of services that are requested). The Common Order Segment is constructed as follows:
Order Common Segment (ORC) Attributes
1 2 ID R Order Control
2 22 EI C Placer Order Number
3 22 EI C Filler Order Number
4 22 EI O Placer Group Number
5 2 ID O Order Status
6 1 ID O Response Flag
7 200 TQ O Quantity/Timing
8 200 CM O Parent
9 26 TS O Date/Time of Transaction
10 120 XCN O Entered By
11 120 XCN O Verified By
12 120 XCN O Ordering Provider
13 80 PL O Enterer’s Location
ORC field definitions
ORC-1 Order Control (ID) 00215

Determines the function of the order segment.
When ORC-1 is NW, XO, SN, and PA, an order is registered, and when ORC-1 is CA and
DC, the order of applicable Placer Order Number is canceled.
ORC-2 Placer Order Number ( EI) 00216

This field is the placer application’s order number.
ORC-12 Ordering Provider (XCN) 00226

This field contains the identity of the person who is responsible for creating the request (i.e.,
ordering physician).
Example:
ORC|NW|6000|B103Z||SC||1ônce^^^^S||200007010900|^ROSEWOOD^RANDOLPH||7101
ÊSTRADA^JAIME^P^^DR||(314)555-1212|200007010900||922229-10
16
5.8 OBR – OBSERVATION REQUEST SEGMENT
OBR serves as the order detail. The requesting application will use some fields to describe
the observation requested. Posting from DICOM MWL may be included in the field of an
OBR segment.
Observation Request Segment (OBR) Attributes
1 4 SI O Set ID - OBR
2 22 EI C Placer Order Number
3 22 EI C Filler Order Number
4 200 CE R Universal Service ID Components 4-6 : Scheduled Protocol Code
5 2 ID B Priority - OBR
6 26 TS B Requested Date/Time
7 26 TS C Observation Date/Time
8 26 TS O Observation End Date/Time
9 20 CQ O Collection Volume
10 60 XCN O Collector Identifier
11 1 ID O Specimen Action Code
12 60 CE O Danger Code
13 300 ST O Relevant Clinical Info.
14 26 TS C Specimen Received Date/Time
15 300 CM O Specimen Source L/R indicator
16 120 XCN O Ordering Provider
17 40 XTN O Order Callback Phone Number
18 60 ST O Placer Field 1 Accession Number
19 60 ST O Placer Field 2 Requested Procedure ID
20 60 ST O Filler Field 1 Scheduled Procedure Step ID
21 60 ST O Filler Field 2
22 26 TS C Results Rpt/Status Chng
23 40 CM O Date/Time
24 10 ID O Diagnostic Serv Sect ID DICOM Modality
25 1 ID C Result Status
26 200 CM O Parent Result
27 200 TQ O Quantity/Timing
28 150 XCN O Result Copies To
29 200 CM O Parent
30 20 ID O Transportation Mod
31 300 CE O Reason for Study
32 200 CM O Principal Result Interpreter
33 200 CM O Assistant Result Interpreter
34 200 CM O Technician
35 200 CM O Transcriptionist
36 26 TS O Scheduled Date/Time
17
37 4 NM O Number of Sample Containers

38 60 CE O Transport Logistics of Collected
39 200 CE O Collector’s Comment
40 60 CE O Transport Arrangement
41 30 ID O Transport Arranged
42 1 ID O Escort Required
43 200 CE O Planned Patient Transport
44 80 CE O Procedure Code Requested Procedure Code and Requested
Procedure Description
45 80 CE O Procedure Code Modifier
OBR field definitions
OBR-4 Universal Service ID (CE) 00238

This field contains the identifier code for the requested observation/test/battery. This can be
based on local and/or “universal” codes. We recommend the “universal” procedure identifier.
The structure of this CE data type is described in the control section.
Example:
OBR|1|6000|B103Z |P1^Procedure 1^L^X1_A1^SP Action
Item^L|||||||||||Radiology^^^^R|7101ÊSTRADA||
B103Z|RP103|SS103||||MR|||1ônce^^^^S|||WALK|||||||||||A|||P1^Procedure 1
5.9 OBX – OBSERVATION RESULT SEGMENT

The OBX segment is used to transmit a single observation or observation fragment.
It represents the smallest indivisible unit of a clinical observation or report.
The Observation Result Segment (OBX) is constructed as follows:
Observation Result Segment (OBX) Attributes
1 4 SI O Set ID - OBX Sequential counter

2 3 ID C Value Type ST or CE or SN or ED or RP
3 80 CE R Observation Identifier Observation Code and Text
4 20 ST C Observation Sub-ID Sequential counter
5 65536 * C Observation Value Text or Code or Numeric
6 60 CE O Units
7 60 ST O References Range
8 5 ID O Abnormal Flags
9 5 NM O Probability
10 2 ID O Nature of Abnormal Test
11 1 ID R Observation Result Status F
12 26 TS O Date Last Obs Normal Values
13 20 ST O User Defined Access Checks
18
14 26 TS O Date/Time of the Observation Date/Time of the Observation

15 60 CE O Producer's ID
16 80 SCN O Responsible Observer
17 60 CE O Observation Method
The length of the observation value field is variable, depending upon value type. See OBX-2-
value type.
OBX field definitions
OBX-2 Value Type(ID) 00570

This field contains the format of the observation value in OBX.
OBX-3 Observation Identifier (CE) 00571

This field contains a unique identifier for the observation.
OBX-5 Observation Value (*) 00573

This field contains the value observed by the observation producer. OBX-2-value type
contains the data type for this field according to which observation value is formatted.
Combination of OBX-2 and OBX-5 in a ORU / MDM message:
OBX-2 OBX-5 OBX-5 (Example)
ST The HTTP link to ImagePilot http://10.51.21.109/KimLinkScreen/KimLinkScreen.application?pid=

100001\T\oprt=open\T\stuid=1.2.392.200036.9107.500.11111205180
02\T\uname=nologin
ST The HTTP link to a JPEG file http://10.51.21.109/KimDataJpeg/CnvImg2.0.jpg
ED The BASE64 encoding string of a JPEG file ^multipart^JPEGÂ^\X0D0A\MIME-Version: 1.0\X0D0A\Content-
Type: image/jpeg\X0D0A\Content-Transfer-Encoding:
base64\X0D0A\/9j/4AAQSkZJRgABAQEAYABgAAD/2…\X0D0A\
RP The CIFS link to a JPEG file \\10.51.21.109\Data\Jpeg\CnvImg10.0.jpg^ÎM^JPEG
Example:
OBX|4|TX|1001ÂMY^NEO^2002||TEXTTEXTTEXT||||||F
19
5.10 ZDS – STUDY INSTANCE UID SEGMENT

The Study Instance UID Segment is used to send DICOM Study Instance UID of a order.
The Study Instance UID Segment is constructed as follows:
Study Instance UID Segment (ZDS) Attributes
1 200 RP R Study Instance UID “1.1.1”
ZDS field definitions
ZDS-1 Study Instance UID (RP)

Globally unique identifier assigned by the workflow management IDIS to the Imaging Study
under which all images and other DICOM objects produced in the course of the Requested
Procedure shall be collected.
Example:
ZDS| 1.113654.3.104.1^100Âpplication^DICOM
20
5.11 SCH – SCHEDULE ACTIVITY INFORMATION SEGMENT

The SCH segment contains general information about scheduled appointment.
Schedule Activity Information Segment (SCH) Attributes
1 75 EI C Placer Appointment ID 20101124000001

2 75 EI C Filler Appointment ID
3 5 NM C Occurrence Number
4 22 EI O Placer Group Number
5 200 CE O Schedule ID
6 200 CE R Event Reason 123^Reason^L
7 200 CE O Appointment Reason
8 200 CE O Appointment Type
9 20 NM O Appointment Duration
10 200 CE O Appointment Duration Units
11 200 TQ R Appointment Timing Quantity ^^^^^R
12 48 XCN O Placer Contact Person
13 40 XTN O Placer Contact Phone Number
14 106 XAD O Placer Contact Address
15 80 PL O Placer Contact Location
16 38 XCN R Filler Contact Person 745^Contact Person’s name
17 40 XTN O Filler Contact Phone Number
18 106 XAD O Filler Contact Address
19 80 PL O Filler Contact Location
20 48 XCN R Entered by Person 766Êntered Person’s name
21 40 XTN O Entered by Phone Number
22 80 PL O Entered by Location
23 75 EI O Parent Placer Appointment ID
24 75 EI O Parent Filler Appointment ID
25 200 CE O Filler Status Code
SCH-1 Placer appointment ID (EI) 00860

This field contains the placer application’s permanent identifier for the appointment request
(and the scheduled appointment it self, when it has been confirmed as a booked slot by the
filler application). This is composite field.
SCH -2 Filler appointment ID (EI) 00861

This field contains the filler application’s permanent identifier for the appointment request
(and the scheduled appointment itself, when it has been confirmed as a booked slot by the
filler application). This is a composite field.
Example:
SCH|20101124000001|||||123^Reason^L|||||^^^^^R|||||745^ Contact Person’s name||||766^
Entered Person’s name
21
5.12 TXA-TRANSCRIPTION DOCUMENT HEADER SEGMENT

The TXA segment contains information specific to a transcribed document.
Transcription Document Header(TXA)Attributes
1 4 SI R Set ID- TXA 1

2 30 IS R Document Type DI
3 2 ID C Document Content Presentation
4 24 DTM O Activity Date/Time
5 250 XCN C Primary Activity Provider Code/Name
6 24 DTM O Origination Date/Time
7 24 DTM C Transcription Date/Time
8 24 DTM O Edit Date/Time
9 250 XCN O Originator Code/Name
10 250 XCN O Assigned Document Authenticator
11 250 XCN C Transcriptionist Code/Name
12 427 EI R Unique Document Number 20110328102024
13 427 EI C Parent Document Number
14 427 EI O Placer Order Number
15 427 EI O Filler Order Number
16 30 ST O Unique Document File Name
17 2 ID R Document Completion Status PA
18 2 ID O Document Confidentiality Status
19 2 ID O Document Availability Status
20 2 ID O Document Storage Status
21 30 ST C Document Change Reason
22 250 PPN C Authentication Person, Time Stamp (set)
23 250 XCN O Distributed Copies (Code and Name of
Recipient(s) )
TXA-1 Set ID - TXA (SI) 00914

This field contains a number that uniquely identifies this transaction for the purpose of
adding, changing, or deleting the transaction.
TXA-2 Document Type (IS) 00915

This field identifies the type of document (as defined in the transcription system).
TXA-12 Unique Document Number (EI) 00925

This field contains a unique document identification number assigned by the sending system.
This document number is used to assist the receiving system in matching future updates to
the document, as well as to identify the document in a query. When the vendor does not
provide a unique document ID number, some type of document identifier should be entered
here, or the Unique Document File name should be utilized.
22
TXA-17 Document Completion Status (ID) 00928

This field identifies the current completion state of the document. This is a required, field.
Example:
TXA|1|DI||||||||||20110328102024|||||PA
23
6. Communications Environment
Message exchanging is performed generally in a networked environment.
This type of environment provides error free data transmission (e.g., network over TCP/IP).
6.1 LOWER LEVEL PROTOCOL

ImagePilot interfaces implement the HL7 Lower Level Protocol (LLP), which enhances the
capabilities of the communications environment. The HL7 Lower Level Protocol is
defined in the HL7 Implementation Guide, which is not an official part of the Standard.
6.2 FAULT TOLERANCE

All the lower level protocols may help in communicating the data reliably but any one of
the communicating systems cannot assume that the message was received unless it receives
an acknowledgement message.
ImagePilot interfaces will send acknowledgements only after the received data is processed
and saved. This approach creates an inherent fault tolerance so network or system crashes
will not cause loss of data or non-reliable application-level communications.
When the ImagePilot system is the sender of information, the system will resend messages
that did not receive acknowledgements.
24
0604EA02EN04
2015-09-18
(JD)

HL7 Conformance Statement

Uploaded by

Document Information

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

HL7 Conformance Statement

Uploaded by

Copyright:

Available Formats

HL7

Date Version Description

Notice: Specifications in this document are subject to change without notice.

3. IMPLEMENTATION MODEL ................................................................................................... 2

ImagePilot receives message from external EMR/PMS/HIS/RIS, saves information to

3.1 APPLICATION DATA FLOW

3.1.1 Receive HL7 message

ADT, ORM, SIU are supported.

1. Request sending ImagePilot

3.1.2 Send HL7 message

ORU, MDM are supported.

ImagePilot 1. Request sending

3.2 HL7 MESSAGE AND ITS COMPONENTS

3.3 FIELDS AND FIELD ATTRIBUTES

Name - ELEMENT NAME

ImagePilot Value - Contents of the field in a typical ImagePilot data exchange

4. Supported Message Types and Event Types

4.1 ADT TYPE MESSAGES

A01 ADT/ACK - Admit/visit notification

A04 ADT/ACK - Register a patient

A05 ADT/ACK - Pre-admit a patient

A08 ADT/ACK - Update patient information

A40 ADT/ACK - Merge patient information – Patient Identifier List

Message Definition by ImagePilot ADT Interface

ADT^A01, A04, A08 ADT Message

MSH Message Header

[{SFT}] Software Segment

EVN Event Type

PID Patient Identification

[PD1] Additional Demographics

[{NK1}] Next of Kin / Associated Parties

PV1 Patient Visit

[PV2] Patient Visit- Additional Info

[{DB1}] Disability Information

[{OBX}] Observation Result

[{AL1}] Allergy Information

[DRG] Diagnosis Related Group

[IN2] Insurance Additional Information

[{IN3}] Insurance Additional Information, Certification

[ACC] Accident Information

[UB1] Universal Bill Information

[UB2] Universal Bill 92 Information

[PDA] Patient Death and Autopsy

ADT^A05 ADT Message

MSH Message Header

[{SFT}] Software Segment

EVN Event Type

PID Patient Identification

[PD1] Additional Demographics

[{NK1}] Next of Kin / Associated Parties

PV1 Patient Visit

[PV2] Patient Visit- Additional Info

[{DB1}] Disability Information

[{OBX}] Observation Result

[{AL1}] Allergy Information

[DRG] Diagnosis Related Group

[IN2] Insurance Additional Information

[{IN3}] Insurance Additional Information, Certification

[ACC] Accident Information

[UB1] Universal Bill Information

[UB2] Universal Bill 92 Information

ADT^A40 ADT Message

MSH Message Header

EVN Event Type