ELEKTRA

HL7 integration

Rev. 2.0

FINAL

1 / 37
PROPRIETÀ DELLE INFORMAZIONI
Il contenuto di questo manuale è basato sul rilascio del software ELEKTRA.

Questo manuale d’uso, i disegni e tutti gli altri documenti forniti con il software sono di proprietà Dedalus
che riserva tutti i diritti. Pertanto, la ricezione o il possesso degli stessi non conferiscono alcun diritto di
riprodurre i contenuti descritti in esso.

I disegni e/o i documenti non possono essere resi disponibili e/o assegnati a terzi senza autorizzazione
scritta di Dedalus. La vendita o la visione, anche parziale, è vietata dalla legge.

Dedalus non si assume alcuna responsabilità per un uso improprio del dispositivo e/o per i danni causati
da operazioni non coperte da questo manuale. © 2021 Dedalus

DEDALUS Italia S.p.A.

Via di Collodi 6c

50141 FIRENZE

ITALIA

2 / 37
3 / 37
DOCUMENT REVISION

Ver. Number Version Date Summary of Changer Responsible

1.0 25/09/2019 First rev L. Torta

2.0 20/04/2021 Add new msg type L. Torta

APPROVALS

The document requires following approvals

Approver Function role Signature Date

Laura Torta PO Author

4 / 37
Sommario
1 Introduction ........................................................................................................................ 8
2 Supported Messages ......................................................................................................... 8

2.1.1 Patient Registration (R) ................................................................................................................................ 8

2.1.2 Patient Update (R) .......................................................................................................................................... 8
2.1.3 Placer Order Management (R) .................................................................................................................... 8
2.1.4 Report Import ................................................................................................................................................. 8

2.2.1 Filler Order Management (R) ....................................................................................................................... 9

2.2.2 Patient Administration .................................................................................................................................. 9
2.2.3 Report Management ..................................................................................................................................... 9

3 ADT Messages .................................................................................................................. 11

3.1.1 MSH - Message Header Segment .............................................................................................................11

3.1.2 EVN - Event Type Segment ........................................................................................................................12
3.1.3 PID - Patient Identification Segment ........................................................................................................12
3.1.4 PD1 - patient additional demographic segment ...................................................................................13
3.1.5 NK1 – Next of Kin Segment ........................................................................................................................13
3.1.6 PV1 - Patient Visit Segment ........................................................................................................................14
3.1.7 AL1 - Allergy Information Segment ..........................................................................................................14
3.1.8 OBX - Segment ..............................................................................................................................................14
3.1.9 Expected Actions in ELEKTRA ....................................................................................................................14

3.3.1 PID Patient Identification Segment ..........................................................................................................15

3.3.2 Expected Actions in ELEKTRA ....................................................................................................................15

3.5.1 MRG – Merge Information Segment ........................................................................................................16

3.5.2 Expected Actions in ELEKTRA ....................................................................................................................16

4 ORM Messages ................................................................................................................. 17

4.1.1 PV1 - Patient Visit Segment ........................................................................................................................17

4.1.2 PV2 - Patient Visit Segment Additional information .............................................................................18
4.1.3 ORC - common order information segment .....................................................................................19

5 / 37
 4.1.4 OBR - common order information segment .....................................................................................19
4.1.5 Expected Actions in ELEKTRA ....................................................................................................................20

4.2.1 PV1 - Patient Visit Segment ........................................................................................................................21

4.2.2 ORC - common order information segment..........................................................................................21
4.2.3 OBR - common order information segment..........................................................................................22
4.2.4 ZDS segment .................................................................................................................................................23

5 ORU Messages.................................................................................................................. 24

5.1.1 OBR - common order information segment .....................................................................................24

5.1.2 OBX – segment (first occurence)..........................................................................................................24
5.1.3 OBX – segment (second occurence) ...................................................................................................25

6 MDM Messages ................................................................................................................ 25

6.1.1 TXA - Transcription Document Header ...................................................................................................25

6.1.2 OBX - segment .............................................................................................................................................26

6.3.1 TXA - Transcription Document Header ...................................................................................................27

6.3.2 OBX - segment .............................................................................................................................................28

7 ORU IMPORT Messages ................................................................................................... 29

7.1.1 OBR - common order information segment .....................................................................................29

7.1.2 OBX - segment .............................................................................................................................................29

8 MDM IMPORT Messages ................................................................................................. 30

8.1.1 OBR - common order information segment .....................................................................................31

8.1.2 OBX - segment .............................................................................................................................................31

9 Comunication protocol .................................................................................................... 32

MSH - Message Header Segment ................................................................................................................................33

MSA Segment ...................................................................................................................................................................33
ERR Segment ....................................................................................................................................................................34

6 / 37
7 / 37
 1 INTRODUCTION
This document provides a list of HL7 messages supported in the ELEKTRA release 4.0.

2 SUPPORTED MESSAGES

2.1 INCOMING MESSAGES

2.1.1 Patient Registration (R)

ADT^A04 - Registration of an outpatient for a visit
ADT^A28 - Registration of a person

2.1.2 Patient Update (R)

ADT^A08 - Update Patient Information
ADT^A31 - Update Person Information
ADT^A40 - Merge Patient Information

2.1.3 Placer Order Management (R)

ORM^O01 (NW) - Registration of a new order request
ORM^O01 (CA) - Cancel of an order
ORM^O01 (SC-SC) - Booked order Notification
ORM^O01 (SC-IP) - Registered order Notification
ORM^O01 (SC-XO) - Change order Notification

2.1.4 Report Import

ORU^R01 - Unsolicited Report
MDM^T02 - Original document notification and content
MDM^T10 - Document Replacement notification and content

Each message shall be acknowledged by the HL7 ACK message. (See §11).

8 / 37
2.2 OUTGOING MESSAGES

2.2.1 Filler Order Management (R)

ORM^O01(NW-SC) - new order creation in ELEKTRA
ORM^O01(SC-SC) - Order scheduled in ELEKTRA
ORM^O01(SC-IP) - Order in progress in ELEKTRA
ORM^O01(SC-CM) - Order completed in ELEKTRA
ORM^O01(CA) - Cancel order in ELEKTRA

2.2.2 Patient Administration

ADT^A04 - Registration of an outpatient for a visit
ADT^A08 - Update Patient Information
ADT^A40 - Merge Patient Information

2.2.3 Report Management

ORU^R01 - Unsolicited Report
MDM^T02 - Original document notification and content
MDM^T10 - Document replacement notification and content
MDM^T01 - Original Document Notification of Report
MDM^T09 - Document Replacement Notification of Report

Each subscriber should be registered into ELEKTRA with his ACK Policy (See Appendix A).

2.3 SEGMENTS DETAILS

Message Segment
ADTA04 MSH / EVN / PID / PD1 / NK1/ PV1 / AL1 / OBX
ADTA08 MSH / EVN / PID / PD1 / NK1/ PV1 / AL1 / OBX
ADTA28 MSH / EVN / PID / PD1 / NK1/ PV1 / AL1 / OBX
ADTA31 MSH / EVN / PID / PV1
ADTA40 MSH / EVN / PID / MRG / PV1
ORMO01 MSH / PID / PV1 / PV2 / ORC / OBR / FT1 (/ZDS)
ORUR01 MSH / EVN / PID / OBR / OBX
MDMT02 MSH / EVN / PID / PV1 / TXA / OBX
MDMT10 MSH / EVN / PID / PV1 / TXA / OBX
MDMT01 MSH / EVN / PID / PV1 / TXA / OBX

9 / 37
MDMT09 MSH / EVN / PID / PV1 / TXA / OBX

10 / 37
 3 ADT MESSAGES

3.1 ADT A04 PATIENT REGISTRATION MESSAGE SEMANTICS

The Patient Registration transaction is conducted by the HL7 ADT message. The ADT Actor (RIS or
PAS system) shall generate the message whenever a patient is admitted, pre-admitted or
registered. In the event that a new patient will be seen as an outpatient at some future time, an
ADT A04 message shall be used to convey patient information required by the Order Placer or Order
Filler.

Next table lists all managed required and optional segments.

ADT A04 Patient Administration Message

MSH Message Header

EVN Event Type
PID Patient Identification
[PD1] Patient additional demographic segment
[{NK1}] Next of Kin
PV1 Patient Visit
[{AL1}] Allergy Information
[{OBX}] Observation Results
Table 1: ADT A04 segments

3.1.1 MSH - Message Header Segment

SEQ LEN DT OPT ELEMENT NAME NOTES
1 1 ST R Field Separator “|”

2 4 ST R Encoding Characters “^~\&”

3 180 EI R Sending Application RIS: “RAD”

4 180 EI R Sending Facility RIS: “ELEKTRA”

5 180 EI R Receiving Application (See MSH-3)

6 180 EI R Receiving Facility (See MSH-4)

9 7 CM R Message Type See note.

10 20 ST R Message Control ID Unique msg id
11 3 PT R Processing ID “P ”

12 60 VID R Version ID “2.5” (HL7 version)

Table 2: ADT A04 MSH segment

11 / 37
Note: field MSH-9 Message Type shall have at least two components. The first component shall
have a value of “ADT”; the second component shall have values of A04. The third component is
optional; however, if present, it shall have a value of ADT_A01.

3.1.2 EVN - Event Type Segment

SEQ LEN DT OPT ELEMENT NAME NOTES
2 26 TS R Recorded Date/Time ISO Format: YYYYMMDD
[HHMMSS]
Table 3: ADT A04 EVN segment

3.1.3 PID - Patient Identification Segment

SEQ LEN DT OP ELEMENT NAME NOTES
T
3 20 CX R Patient Identifier <patient code>^^^^CF~
<primary key in other system>^^^^PK
List
(MRN number)
5 48 XPN R Patient Name <family name>
^<given name>
^<middle initial or name>
^<suffix>
^<prefix>^^L
7 26 TS R Date/Time of ISO Format: YYYYMMDD
Birth [HHMMSS]
8 1 IS R Sex One from: M , F , O , U
11 106 XAD O Patient Address <street address>
^<other designation>
^<city>
^<state or province>
^<zip or postal code (ST)>
13 40 XTN O Phone Number - ^^^^^^<Phone Number>
Home
16 80 CE O Marital Status See USR0002 Table (Appendix B)
22 80 CE O Ethnic Group
17 80 CE O Religion Will be ignored.
29 26 TS O Patient Death ISO Format: YYYYMMDD
Date and Time [HHMMSS]
30 1 ID O Patient Death Y/N
Indicator
Table 4: ADT A04 PID segment

12 / 37
3.1.4 PD1 - patient additional demographic segment
The patient additional demographic segment contains demographic information that is likely to
change about the patient. We will use it for GPs.

SEQ LEN DT OPT ELEMENT NAME NOTES

3 90 XON O Patient Primary Facility This field will be ignored, as
RIS does not manage GP
practice details.
4 90 XCN O Patient Primary Care <ID>
Provider Name & ID No. ^<Family Name>
^<Given Name>
^<Middle Initial or name>
^<Suffix>
^<Prefix>
Table 5: ADT A04 PD1 segment

3.1.5 NK1 – Next of Kin Segment

The NK1 segment contains information about the patient’s other related parties. Any associated
parties may be identified. Utilizing NK1-1-set ID, multiple NK1 segments can be sent to patient
accounts.

If a person or organization fulfills multiple contact roles, for example, a person is an emergency
contact and a next of kin, it is recommended to send a NK1 segment for each contact role (field
7).

SEQ LEN DT OPT ELEMENT NAME NOTES

1 4 SI R Set ID - NK1
2 48 XPN O Name
3 60 CE O Relationship See Note.
4 106 XAD O Address
5 40 XTN O Phone Number
Table 6: ADT A04 NK1 segment
Note: currently RIS does not manage next of kin data, but Hospital System can send this segment
for completeness as it does have these details and would send them to any consumer of our HL7
messages. HL7 RIS interface will ignore this segment.

13 / 37
3.1.6 PV1 - Patient Visit Segment
SEQ LEN DT OPT ELEMENT NAME NOTES
2 1 IS R Patient Class See USR0004 Table (Appendix B)
3 80 PL O Assigned Patient <point of care>^^^^^^
Location <building>^^
<location description>
Table 7: ADT A04 PV1 segment

3.1.7 AL1 - Allergy Information Segment

SEQ LEN DT OPT ELEMENT NAME NOTES

1 4 SI R Set ID – AL1
3 60 CE R Allergy <ID>^<description>
Code/Mnemonic/Descripti
on
6 8 DT O Identification Date ISO Format:
YYYYMMDD[HHMMSS]
Table 8: ADT A04 AL1 segment

3.1.8 OBX - Segment

The OBX segment contains the “observations” about the patient and typically the identification,
description, value and code source, unit of measure and observed value status.

SEQ LEN DT OPT ELEMENT NAME NOTES

1 4 SI R Set ID - OBX
2 3 ID O Value Type
See Note.
3 80 CE R Observation Identifier
5 100 O Observation Value
Table 9: ADT A04 OBX segment

Note: currently RIS does not manage the patient “observations” data, but Hospital System can
send this segment for completeness as it does have these details and would send them to any
consumer of our HL7 messages. HL7 RIS interface will ignore these observations.

3.1.9 Expected Actions in ELEKTRA

The receiver of the ADT Patient Registration transaction message shall create a new patient record
for the patient identified if there is no current record for the Patient ID (defined by the field PID-
3). The ADT Patient Registration transaction shall not be used to update information in an existing
patient record. Patient Update shall be used instead (see sec. 3).

3.2 ADT A28 PERSON REGISTRATION MESSAGE SEMANTICS

See 3.1

14 / 37
3.3 ADT A08 PATIENT INFORMATION UPDATE MESSAGE SEMANTIC
This trigger event is used when any patient information has changed but when no other trigger
event has occurred. For example, an A08 event can be used to notify the receiving systems of a
change of address or a name change. We recommend that the A08 transaction be used to update
fields that are not related to any of the other trigger events. The A08 event can include information
specific to an episode of care, but it can also be used for demographic information only.

ADT A08 Patient Administration Message Notes

MSH Message Header = to A04 MSH

EVN Event Type = to A04 EVN
PID Patient Identification
[PD1] Patient additional demographic segment = to A04 PD1
[{NK1}] Next of Kin = to A04 NK1
PV1 Patient Visit = to A04 PV1
[{AL1}] Allergy Information = to A04 AL1
[{OBX}] Observation Results = to A04 OBX
Table 14: ADT A08 segments.

3.3.1 PID Patient Identification Segment

SEQ LEN DT OPT ELEMENT NAME
3 20 CX R Patient Identifier List
5 48 XPN R Patient Name
7 26 TS O Date/Time of Birth
8 1 IS O Sex
11 106 XAD O Patient Address
13 40 XTN O Phone Number - Home
16 80 CE O Marital Status
22 80 CE O Ethnic Group
17 80 CE O Religion
29 26 TS O Patient Death Date and
Time
30 1 ID O Patient Death Indicator

Table 15: ADT A08 PID segment

3.3.2 Expected Actions in ELEKTRA

The receiver of the ADT Patient Update transaction message shall modify a patient record for the
patient identified. The ADT Patient Update transaction shall not be used to update location
information. (PV1 segment)

15 / 37
3.4 ADT A31 PERSON UPDATE INFORMATION
See 3.6

3.5 ADT A40 PATIENT MERGE MESSAGE SEMANTICS

The event A40 is used to merge current and previous patient identification numbers. A merge
happens when a decision is made to combine the information under either the old or new identifiers.
For example, when previous patients is registered under a new patient ID number due to an error,
or because there was insufficient time to determine the actual patient ID number.

An A40 message indicates that a merge has been done at the internal identifier level. That is, PID-
3-patient ID identifier has been merged with MRG-1 Patient ID. This message is initiated by Elektra
RIS.

Next table lists all managed required and optional segments.

ADT A40 Patient Administration Message Notes

MSH Message Header = to A04 MSH

EVN Event Type = to A04 EVN
PID Patient Identification = to A08 PID
{MRG} Merge Information
[PV1] Patient Visit = to A08 PV1
Table 24: ADT A40 segments

3.5.1 MRG – Merge Information Segment

The PID and PV1 segments contain the dominant patient information, including Patient ID. The
MRG segment identifies the “old” or secondary patient records to be de-referenced. HL7 does not
require that the “old” record be deleted; it does require that the “incorrect” identifier not be
referenced in future transactions following the merge.

SEQ LEN DT OPT ELEMENT NAME NOTES

1 20 CX R Prior Patient <patient ID>^^^^PID~
<codicefiscale>^^^^CF~
Identifier List
<primary key in other
system>^^^^PK
Table 25: ADT A40 MRG segment

3.5.2 Expected Actions in ELEKTRA

It is expected that after receiving a Patient Merge message (A40) the receiving system will perform
updates to reflect the fact that two patient records have been merged into a single record. If the

16 / 37
correct target patient was not known to the receiving system, it is expected that the receiving
system will create a patient record using the patient identifiers and demographics from the available
PID segment data.

4 ORM MESSAGES

4.1 ORM O01 ORDER MESSAGE SEMANTICS

This transaction is used by the Order Placer to place a new order with the Order Filler (RIS). To
change order information, the Order Placer would cancel the initial order and place the new one.

The order start date/time or exam date/time is required in the “Quantity/Timing” field of both the
ORC and OBR segments.

Next table lists all managed required and optional segments.

ORM O01 Order Message Notes

MSH Message Header = to A04 MSH

PID Patient Identification = to A08 PID
PV1 Patient Visit
PV2 Other Patient Visit

{ ORC Common Order

OBR} Order Detail

FT1 Financial Transaction
Table 26: ORM O01 segments

4.1.1 PV1 - Patient Visit Segment

SEQ LEN DT OPT ELEMENT NAME NOTES

2 1 IS R Patient Class See USR0004 Table (Appendix B).

It defines the source of request
3 80 PL O Assigned Patient <point of care>^^^^^^
Location <building>^^
<location description>. It defines
the ward of source of request
7 60 XCN O Attending Doctor <ID>
^<Family Name>
^<Given Name>
^<Middle Initial or name>
^<Suffix>
^<Prefix>

17 / 37
 19 60 CX O Visit Number Recover number (inpatients) or
episode number (outpatients,
emergency patients)
20 FC O Financial Class PV1.20^0 = Institution type /
disbursement regime

Table 27: ORM O01 PV1 segment

4.1.2 PV2 - Patient Visit Segment Additional information

SEQ RP DT OPT ELEMENT NAME NOTES
7 Y IS O Visit user code Reports the movement progressive number which
identifies the movement event inside of the
episode (f.e. a specific transfer)
36 ID O Newborn baby indicator Y if the patient is a newborn
N otherwise
45 Y CE O Patient Class Repetition: Privacy
CE.2 = 'SI' / 'NO' = anonimization requested /not
requested

CE.3 = 'PRIVACY'

Repetition: Obscuring Drug addiction

CE.2 = 'SI' / 'NO' = information obscured/not
obscured

CE.3 = '10'

Repetition: Obscuring HIV

CE.2 = 'SI' / 'NO' = information obscured/not
obscured
CE.3 = '20'

Repetition: Obscuring violences suffered

CE.2 = 'SI' / 'NO' = information obscured/not
obscured
CE.3 = '30'

Repetition: Obscuring Voluntary Termination

of Pregnancy
CE.2 = 'SI' / 'NO' = information obscured/not
obscured
CE.3 = '40'

Repetition: Obscurign Citizen Voluntary

CE.2 = 'SI' / 'NO' = information obscured/not
obscured
CE.3 = '50'

Table 28: ORM O01 PV2 segment

18 / 37
4.1.3 ORC - common order information segment
SEQ LEN DT O ELEMENT NAME NOTES
P
T
1 2 ID R Order Control <NW> (new order) or <CA> (cancel
order)
2 22 EI C Place Order Number Placer order number

3 22 EI C Filler Order Number Filler Order Number

4 22 EI O Placer Group Number Placer Group Number

7 200 TQ R Quantity/Timing 1^^^^<start date/time>^

<end date/time>^
<priority>
Date in ISO Format: YYYYMMDD
[HHMMSS].

8 200 EIP O Parent IUP (Unique code for booking

SISS)
9 26 TS R Date/Time of ISO Format: YYYYMMDD
Transaction [HHMMSS]. It defines the date of
transaction. (=request dt of
booking)
12 120 XCN R Ordering Provider <ID>
^<Family Name>
^<Given Name>
^<Middle Initial or name>
^<Suffix>
^<Prefix>
13 80 PL O Enterer’s Location
17 60 CE R Entering Organization <ID>
^<Free Text Description>
Table 29: ORM O01 ORC segment

4.1.4 OBR - common order information segment

SEQ LEN DT OPT ELEMENT NAME NOTES
2 75 EI R Place Order <Pas Order Identifier>
Number
3 22 EI C Filler Order Filler Order Number
Number
4 200 CE R Universal Service <Exam ID>^<free text description>
ID
13 300 ST O Relevant Clinical See Note
Info

19 / 37
 16 80 XCN R Ordering Provider <ID>
^<Family Name>
^<Given Name>
^<Middle Initial or name>
^<Suffix>
^<Prefix>
24 10 ID O Diagnostic Serv <ID>
^<description> or modality name
Sect ID
30 20 ID O Transportation
mode
31 250 CE O Reason for study
32 200 NDL O Principal Result
Interpreter +
34 200 NDL O Technician +
36 200 TS R Date of booking
Date in ISO Format: YYYYMMDD
Scheduled
[HHMMSS]. It defines booking
Date/Time
date for outpatient or request
date for Inpatient
Table 30: ORM O01 OBR segment

Note: Field OBR-13 Relevant Clinical Info shall be populated if patient record contains any medical
alerts that may be relevant to the order and, in particular, need to be communicated to the
technologist. Also the LMP date will be included here.

Identical Element Mappings between ORC and OBR Segments are listed below.

Element Name ORC Segment OBR Segment Element

Element
Placer Order ORC-2 OBR-2
Number
Quantity/Timing ORC-7 OBR-27

4.1.5 Expected Actions in ELEKTRA

Department System Scheduler/Order Filler (RIS system) shall accept the order information for
fulfillment (if control code “NW”). If error in data prevents it from fulfilling the order, it shall notify
the Order Placer by returning proper information in the ACK message (see Appendix A).

After receiving the ORM message with the control code “CA”, Order Filler shall discard the record
of the order and shall not attempt to schedule or otherwise to fulfill it.

4.2 ORM O01 ORDER MESSAGE SEMANTICS (MESSAGE TO PACS)

This transaction is used by Order Filler (RIS) to inform the PACS about a new order.

Next table lists all managed required and optional segments.

20 / 37
 ORM O01 Order Message Notes

MSH Message Header = to A04 MSH

PID Patient Identification = to A08 PID
PV1 Patient Visit

{ ORC Common Order

OBR} Order Detail

ZDS StudyInstanceUID Detail
Table 31: ORM O01 segments

4.2.1 PV1 - Patient Visit Segment

SEQ LEN DT OPT ELEMENT NAME NOTES

2 1 IS R Patient Class See USR0004 Table (Appendix B).

It defines the source of request
3 80 PL O Assigned Patient <point of care>^^^^^^
Location <building>^^
<location description>. It defines
the ward of source of request
7 60 XCN O Attending Doctor <ID>
^<Family Name>
^<Given Name>
^<Middle Initial or name>
^<Suffix>
^<Prefix>
19 60 CX O Visit Number Recover number (inpatients) or
episode number (outpatients or
emergency)
20 FC O Financial Class PV1.20^0 = Institution type /
disbursement regime

Table 32: ORM O01 PV1 segment

4.2.2 ORC - common order information segment

SEQ LEN DT OPT ELEMENT NAME NOTES
1 2 ID R Order Control NW

2 22 EI R Place Order Placer order number

Number

21 / 37
 3 22 EI R Filler Order Filler order number
Number

5 2 ID R Order Status SC

7 200 TQ R Quantity/Timing 1^once^^20110730073453

Where 4° Subcomponent is a Date in
ISO Format: YYYYMMDD [HHMMSS].

9 26 TS R Date/Time of ISO Format: YYYYMMDD

Transaction [HHMMSS]. It defines the date of
transaction. (=request dt of
reception)
12 120 XCN R Ordering Provider <ID>
^<Family Name>
^<Given Name>
^<Middle Initial or name>
^<Suffix>
^<Prefix>
Table 33: ORM O01 ORC segment

4.2.3 OBR - common order information segment

SEQ LEN DT OPT ELEMENT NAME NOTES
1 4 SI O Set ID
2 75 EI R Place Order
Number
3 22 EI R Filler Order
Number

4 200 CE R Universal Service <Exam ID>^<free text description>

ID
7 200 TQ R Quantity/Timing 1^once^^20110730073453
Where 4° Subcomponent is a Date in
ISO Format: YYYYMMDD [HHMMSS].

13 300 ST O Relevant Clinical See Note

Info
16 80 XCN R Ordering Provider <ID>
^<Family Name>
^<Given Name>
^<Middle Initial or name>
^<Suffix>
^<Prefix>
18 60 ST O Placer Field1 Accession Number

19 60 ST O Placer Field2 ReqProcedureID

20 60 ST O Filler Field1 Step ProcedureID

22 / 37
 24 10 ID O Diagnostic Serv <ID>
^<description> or modality name
Sect ID
Date in ISO Format: YYYYMMDD
27 200 TQ R Quantity Timing
[HHMMSS]
Table 34: ORM O01 OBR segment

4.2.4 ZDS segment

SEQ LEN DT OPT ELEMENT NAME NOTES

1 255 ST R StudyInstanceUID
Table 35: ORM O01 ZDS segment

Example of ORM to PACS

MSH|^~\&|RIS|ELEKTRA|RIS|RAD|201110281117||ORM^O01|HL7201110281117|P|2.5|||AL|NE|
ITA|ASCII
PID|||1227546^^^^PID||TEST^GIAN||19371114|M||||||||||TSTGCR37S14H501D

PV1||O|E||||||||||||||||AN0000268464||||||||||||||||||||||||||||||||V

ORC|NW||0000268479||SC||1^once^^20110730073453||20110730073500|||FER^MEDICO^REF
ERENTE^M^^DOTTOR|||||

OBR|1||0000268479|0871^TC ARCATE DENTARIE X

ARCATA|||20110730073453|||||||||FER^MEDICO^REFERENTE^M^^DOTTOR||AN0000268464|RPI
D0000268479|SPSID0000351447||||CT|||1^once^^20110730073453||||||||||||||

ZDS|1.2.826.0.1.3802357.101.70000268479

23 / 37
 5 ORU MESSAGES

5.1 ORU R01 UNSOLICITED REPORT MESSAGE SEMANTICS

When Reports are verified and finalized by the RIS system, it will send unsolicited ORU transactions
to the EPR.

Next table lists all managed required and optional segments.

ORU R01 Unsolicited Report Message Notes

MSH Message Header = to A04 MSH

PID Patient Identification = to A08 PID
[{OBR}] Order Detail
{OBX} Observation Result
Table 42: ORU O01 segments

5.1.1 OBR - common order information segment

SEQ LEN DT OPT ELEMENT NAME NOTES
2 22 EI R Place Order Number <PAS Order Identifier>

3 22 EI R Filler Order Number <RIS ID>

4 200 CE R Universal Service ID <Exam ID>^<free text

description>

7 26 TS R Observation ISO Format: YYYYMMDD

Date/Time [HHMMSS]
20 250 ST O RIS StudyInstanceUID ^
Accessionumber
25 1 ID R Result Status <F>
Table 43: ORU O01 OBR segment

5.1.2 OBX – segment (first occurence)

SEQ LEN DT OPT ELEMENT NAME NOTES
1 4 SI O Set ID Sequence number <1>

2 3 ID R Value Type <TX>

3 80 CE R Observation REPORT ID
Identifier
5 8000 TX R Observation Value <report text>
See Note

11 1 ID R Result Status <F>

Table 44: ORU O01 OBX segment

24 / 37
Note: Report text will have rows delimited by “\x0d\\x0a\” (CR and LF) special characters.

5.1.3 OBX – segment (second occurence)

SEQ LEN DT OPT ELEMENT NAME NOTES
1 4 SI O Set ID Sequence number <2>

2 3 ID R Value Type <RF>

3 80 CE R Observation REPORT ID
Identifier
5 8000 RF R Observation Value <images web link address>

11 1 ID R Result Status <F>

Table 45: ORU O01 OBX segment

6 MDM MESSAGES

6.1 MDM T02 ORIGINAL DOCUMENT NOTIFICATION AND CONTENT MESSAGE

SEMANTICS
When Reports are verified and finalized by the RIS system, it will send MDM transactions to the
EMR.

Next table lists all managed required and optional segments.

MDM T02 Unsolicited Report Message Notes

MSH Message Header = to A04 MSH

EVN Event Type = to A04 EVN
PID Patient Identification = to A08 PID
[{OBR}] Order Detail = to R01 OBR
TXA Transcription Document Header
{OBX} Observation Result
Table 46: MDM T02 segments

6.1.1 TXA - Transcription Document Header

SEQ LEN DT OPT ELEMENT NAME NOTES

25 / 37
 1 4 SI R Id - TXA
2 30 IS R Document Type CN

3 2 ID R Document Content PDF

Presentation
4 26 TS O Activity date/time Request Date/hour ISO Format:
YYYYMMDD [HHMMSS]

6 26 TS O Origination Creation Date/hour ISO Format:

date/time YYYYMMDD [HHMMSS]
9 60 XCN O Originator Document author
Code/Name
12 30 EI R Unique Document Document Code
Number
13 30 EI C Parent Document Only for MDMT10
Number
14 22 EI O Placer Order
Number
15 22 EI O Filler Order Number
16 30 ST C Unique Document
File Name
17 2 ID R Document Document state (<LA>)
Completion status
22 60 PPN C Authentication Report Validator
Person Time Stamp
Table 47: MDM T02 - TXA segment

6.1.2 OBX - segment

SEQ LEN DT OPT ELEMENT NAME NOTES
2 3 ID R Value Type <ED>

3 80 CE R Observation REPORT ID
Identifier

5 8000 … R Observation Value PDF STREAM B64

11 1 ID R Observation Result <F>

Status
Table 48: MDM T02 OBX segment

6.2 MDM T10 DOCUMENT REPLACEMENT NOTIFICATION AND CONTENT MESSAGE

SEMANTICS
See 7.1

26 / 37
6.3 MDM T01 ORIGINAL DOCUMENT NOTIFICATION MESSAGE SEMANTICS
When Reports are verified and finalized by the RIS system, it will send MDM transactions to the
EMR.

Next table lists all managed required and optional segments.

MDM T02 Unsolicited Report Message Notes

MSH Message Header = to A04 MSH

EVN Event Type = to A04 EVN
PID Patient Identification = to A08 PID
[{OBR}] Order Detail = to R01 OBR
TXA Transcription Document Header = to MDM T02
{OBX} Observation Result
Table 49: MDM T02 segments

6.3.1 TXA - Transcription Document Header

SEQ LEN DT OPT ELEMENT NAME NOTES
1 4 SI R Id - TXA
2 30 IS R Document Type CN

3 2 ID R Document Content PDF

Presentation
4 26 TS O Activity date/time Request Date/hour ISO Format:
YYYYMMDD [HHMMSS]

6 26 TS O Origination Creation Date/hour ISO Format:

date/time YYYYMMDD [HHMMSS]
9 60 XCN O Originator Document author
Code/Name
12 30 EI R Unique Document Document Code
Number
13 30 EI C Parent Document Only for MDMT10
Number
14 22 EI O Placer Order
Number
15 22 EI O Accession Number
16 30 ST C Unique Document
File Name
17 2 ID R Document Document state (<LA>)
Completion status
22 60 PPN C Authentication Report Validator
Person Time Stamp
Table 50: MDM T01 - TXA segment

27 / 37
6.3.2 OBX - segment
SEQ LEN DT OPT ELEMENT NAME NOTES
2 3 ID R Value Type <RP>

3 80 CE R Observation REPORT ID
Identifier

5 8000 … R Observation Value Web Link to PDF

11 1 ID R Observation Result <F>

Status
Table 51: MDM T01 OBX segment

6.4 MDM T09 DOCUMENT REPLACEMENT NOTIFICATION MESSAGE SEMANTICS

See 7.3

28 / 37
 7 ORU IMPORT MESSAGES

7.1 ORU R01 UNSOLICITED REPORT MESSAGE SEMANTICS

The ORU message is used for importing results from other systems. With the OBX and the OBR
segments, one can construct almost any clinical report as a three-level hierarchy, with the Patient
Context within the PID segment at the upper level, an order record within the OBR segment at the
next level and one or more observation records within the OBX at the bottom. The third OBX
contains the report PDF in B64 stream.

Next table lists all managed required and optional segments.

ORU R01 Unsolicited Report Message Notes

MSH Message Header = to A04 MSH

PID Patient Identification = to A08 PID
[{OBR}] Order Detail
{OBX} Observation Result
Table 52: ORU O01 segments

7.1.1 OBR - common order information segment

SEQ LEN DT OPT ELEMENT NAME NOTES
3 22 EI R Filler Order Number RIS Accession Number

4 200 CE R Universal Service ID <Exam ID>^<free text

description>

7 26 TS R Observation ISO Format: YYYYMMDD

Date/Time [HHMMSS]
24 250 ST O Modality Description
25 1 ID R Result Status <P>, <F>
Table 53: ORU O01 OBR segment

7.1.2 OBX - segment

SEQ LEN DT OPT ELEMENT NAME NOTES
2 3 ID R Value Type <CE>, <FT>,<ED>

5 8000 TX R Observation Value Observation (RTF, XML or pdf

Base64 stream)

11 1 ID R Result Status <P>, <F>

Table 54: ORU O01 OBX segment

29 / 37
The message contains the:

• report in plain text format is conveyed within the OBX2-5 Observation Value
• the report in PDF format is encoded as Base64 string within the OBX3-5 Observation
Value
• the structured finding and study information in CDA format is sent within the OBX4-5
Observation Value

When RIS Elektra receives ORU message, decodes the stream present in OBX3-5 and attaches the
report PDF at the study with the Accession Number contained in OBR-3.

ORU Sample

8 MDM IMPORT MESSAGES

8.1 MDM T02 ORIGINAL DOCUMENT NOTIFICATION AND CONTENT MESSAGE

The MDM message is used for importing results from other systems. With the OBX and the OBR
segments, one can construct almost any clinical report as a three-level hierarchy, with the Patient
Context within the PID segment at the upper level, an order record within the OBR segment at the
next level and one or more observation records within the OBX at the bottom. The second OBX
contains the report PDF in B64 stream.

30 / 37
Next table lists all managed required and optional segments.

MDM T02 Original document Notification Notes

Message
MSH Message Header = to A04 MSH
EVN Event Type = to A04 EVN
PID Patient Identification = to A08 PID
[{OBR}] Order Detail
TXA Transcription Document Header = to T02 TXA
{OBX} Observation Result
Table 55: MDM T02 segments

8.1.1 OBR - common order information segment

SEQ LEN DT OPT ELEMENT NAME NOTES
3 22 EI R Filler Order Number RIS Accession Number

4 200 CE R Universal Service ID <Exam ID>^<free text

description>

7 26 TS R Observation ISO Format: YYYYMMDD

Date/Time [HHMMSS]
25 1 ID R Result Status <P>, <F>
Table 56: MDM T02 OBR segment

8.1.2 OBX - segment

SEQ LEN DT OPT ELEMENT NAME NOTES
2 3 ID R Value Type <HD>,<ED>

5 8000 TX R Observation Value Observation (pdf Base64 stream)

11 1 ID R Result Status <P>, <F>

Table 57: MDM T02 OBX segment

The message contains the:

• the report in PDF format is encoded as Base64 string within the OBX2-5 Observation
Value

When RIS Elektra receives MDM message, decodes the stream present in OBX2-5 and attaches the
report PDF at the study with the Accession Number contained in OBR-3.

31 / 37
 9 COMUNICATION PROTOCOL
Communication protocol is based on HL7 v.2.5 in conformance with previous issues of same
standard.

Transport protocol of HL7 messages is TCP/IP. ELEKTRA exposes a TCP/IP server listener on a
configurable port of one or all IP addresses of hosting machine.

RIS system and network infrastructure must be configured in a way that allows connection to
previously mentioned server. TCP/IP must be closed after message is sent ( Keep-alive=false).

HL7 communication follows “Minimal Lower Layer Protocol” guidelines – Appendix C – “Lower Layer
Protocols”, section “Implementation Support Guide”, HL7 version 2.5.

Upon receipt of each message, ACK message must be issues.

32 / 37
 APPENDIX A
ACK (ACKNOWLEDGE)
Applications that receive HL7 messages shall send acknowledgments using the HL7 Original Mode.
The segments of the ACK message listed below are required, and their detailed descriptions are
provided in the following tables, and corresponding notes. ERR segment shall be present if MSA-1
field is “AE” or “AR”.

ACK Acknowledgement Message Notes

MSH Message Header

MSA Message Acknowledgement
[ERR] Error
Table 58: ACK segment

MSH - Message Header Segment

SEQ LEN DT OPT ELEMENT NAME NOTES
1 1 ST R Field Separator “|”

2 4 ST R Encoding Characters “^~\&”

3 180 EI R Sending Application ??

4 180 EI R Sending Facility ??

5 180 EI R Receiving Application (See MSH-3)

6 180 EI R Receiving Facility (See MSH-4)

9 7 CM R Message Type Message type

10 20 ST R Message Control ID Unique msg id
11 3 PT R Processing ID “P ”

12 60 VID R Version ID “2.5” (HL7

version)
Table 59: ACK MSH segment

MSA Segment

SEQ LEN DT OPT ELEMENT NAME NOTES

1 2 ID R Acknowledgment AA – successful completion
AE – application error
Code
AR – application reject

33 / 37
 2 20 ST R Message Control Shall contain the Message
ID ID from the MSH-10
Message Control ID of the
incoming message .
6 100 CE O Error Condition < ID >^< TEXT >
See table HL70357
Table 60: ACK MSA segment

ERR Segment

SEQ LEN DT OPT ELEMENT NAME NOTES

1 2 ID R Acknowledgment AA – successful completion
AE – application error
Code
AR – application reject
2 20 ST R Message Control Shall contain the Message
ID ID from the MSH-10
Message Control ID of the
incoming message for
which this
acknowledgement is sent.
3 100 CE O Error Condition HL7 ERROR CODE

See table HL70357

Table 61: ACK ERR segment

34 / 37
APPENDIX B
HL7 / USER TABLES

HL7 0357 table error condition code

35 / 37
 VALUE DESCRIPTION COMMENT

SUCCESS
Success. Optional, as the AA conveys
0 Message accepted success. Used for systems that must
always return a status code.
ERRORS
The message segments were not in
Segment sequence
100 the proper order, or required
error
segments are missing.
A required field is missing from a
101 Required field missing
segment
The field contained data of the wrong
102 Data type error data type, e.g. an NM field contained
"FOO".
A field of data type ID or IS was
103 Table value not found compared against the corresponding
table, and no match was found.
REJECTION
Unsupported message
200 The Message Type is not supported.
type
201 Unsupported event code The Event Code is not supported.
Unsupported processing
202 The Processing ID is not supported.
id
203 Unsupported version id The Version ID is not supported.
The ID of the patient, order, etc., was
not found. Used for transactions
204 Unknown key identifier
other than additions, e.g. transfer of
a non-existent patient.
The ID of the patient, order, etc.,
already exists. Used in response to
205 Duplicate key identifier
addition transactions (Admit, New
Order, etc.).

The transaction could not be

Application record
206 performed at the application storage
locked
level, e.g. database locked.

Application internal A catchall for internal errors not

207
error explicitly covered by other codes.

36 / 37
 HL7 user Table USR0002 marital status

VALUE DESCRIPTION COMMENT

1 nubile
2 celibe
3 coniugato/a
4 Vedovo/a
5 Separato/a

HL7 user Table USR0004 patient Class

VALUE DESCRIPTION COMMENT

I Interno (Ricoverato)
O Esterno
E Pronto soccorso
P Post Ricovero
R Pre Ricovero
D Day Hospital

END OF DOCUMENT

37 / 37