DXNET HL7 IMPLEMENTATION PROFILE

Table of Contents :

INTRODUCTION

This document describes the Medasys Digital Systems implementation profile of the HL7 standard into the DxNet application.

DxArchive application is a general image server for the purpose of image information handling and archiving using the Medasys Digital Systems image database.

DxNet application is the subset of the DxArchive application related to network connections management.

The abbreviation MDS is used for Medasys Digital Systems company name.

The abbreviation DxDBase is used for Medasys Digital Systems image database name.

DxHL7server, DxHL7proxi and DxHL7client applications are designed to support the version 2.2 of the HL7 standard, but offers in their current implementation compatibility with the previous version 2.1 of the standard, providing only original processing rules (i.e. original acknowledgement mode).

IMPLEMENTATION MODEL

APPLICATION DATA FLOW DIAGRAM

DxHL7server and DxHL7proxi are the process of DxNet application which are responsible for the incoming HL7 notifications management.

DxHL7client is the process in charge of the outgoing HL7 notifications.

The possible exchanges are describes in the Figure 1.

As de/picted in the Figure 1, there are two ways for a HL7 request to be received in order to manage objects in DxDBase. A remote application (e.g. HIS/RIS systems) can either send HL7 notifications to the DxHL7server by opening a connection on the server machine at the port associated with DxHL7server or be called by the DxHL7proxi that will establish a TCP/IP connection. DxHL7server and DxHL7proxi both send an acknowledge message when an HL7 message has been received. This acknowledge allows the HIS/RIS system to verify if the message sent has been successfully received and decoded by DxHL7server or DxHL7proxi.

During the import process of images/patients files, it is possible to generate HL7 notifications. Those notifications give details about patients and the related studies that have been created during the import process. The notifications are stored and can be sent to a remote application using DxHL7client. DxHL7client sends the notifications created by DxArchive to a remote system and waits for an acknowledge. If the acknowledge is not received before a time out or if the acknowledge is negative, DxHL7client will try to send the message later on.

DxArchive can also create HL7 notifications during the process called Orphan Pool. In this case, DxHL7client can send the resulting HL7 notifications to a remote application by using DxHL7client as explained above.

APPLICATION FUNCTIONAL DEFINITION

DxHL7server and DxHL7proxi

DxHL7server and DxHL7proxi applications act as service providers for the following services :

	patient creation,
	study creation,
	patient merge,
	patient delete,
	patient information update.

DxHL7server uses its standard input and output to respectively receive HL7 notification and send HL7 acknowledge. DxHL7server can be associated with a port number using the inetd daemon.

DxHL7proxi connects itself to a remote application via TCP/IP and wait for a HL7 message. DxHL7proxi can be initialised using inittab to automatically respawn after each received message.

Accepted incoming messages

The following message types are accepted by DxHL7server et DxHL7proxi : ADT, ORM, ORU. Other message types will be rejected by DxHL7proxi an DxHL7server.

For each message an associated action on DxDBase is configured. Refer to this section to find out the required fields for all the possible actions.

Note : It is also possible to use other messages and to assign them a special meaning via the configuration files. For examples ADT A04 (Register a patient) can be associated with a Patient creation action in DxDBase.

Processed segments and fields

During the HL7 notification decoding process, DxHL7server and DxHL7proxi use a dictionary to assign a HL7 message field to a field of DxDBase. This allows to take into account site specific message segment construction rules of a given site.

MSH segment

MSH segment information are used to :

	configure the HL7 decoding rules,
	associate an action on DxDBase with the message type,
	control the network parameters

The network control allows DxHL7server and DxHL7proxi to check if the incoming message is issued by a specified application and facility and if DxHL7server or DxHL7proxi are the recipient for the notification. This control can be enabled or disabled.

EVN segment

EVN segment information are not processed in the current implementation.

PID segment

PID segment information are used to create a Patient entry in the DxDBase, to update the associated Patient, to delete a Patient or to merge Patients.

OBR segment

OBR segment information are used to create a Study.

The resulting Study is shown on Figure 2

MRG segment

MRG segment information are used to merge patients information.

Other segments

PV1 and NK1 are recognised but the current implementation does not stored information found in these fields.

Use of escape sequences in text fields

When a field of type TX, FT, or CF is being encoded, the escape character may be used. For the purposes of this section, the character '\' will be used to represent the escape code. The following escape sequences are recognised by the DxHL7 Net applications :

	\H\ start highlighting,
	\N\ normal text (end highlighting),
	\F\ field separator,
	\S\ component separator,
	\T\ sub component separator,
	\R\ repetition character,
	\E\ escape character,
	\Xdddd\ hexadecimal data,
	\Zdddd\ locally defined escape sequence.

Acknowledge messages description

MSH segment

The MSH segment fields of acknowledge notifications send by DxHL7server or DxHL7proxi are filled as specified in the HL7 specification standard.

MSA segment

ERR segment

Where location is the part of the HL7 notification that generates the error.

DxHL7client

DxHL7client application acts as a messages sender. DxArchive and the archiving process can issue some HL7 notifications to notify the RIS/HIS system of operations realised (image archiving or orphan resolution).

DxHL7client does not create the HL7 notifications. The notifications send by this process are constructed by the image archiving process or the orphan pool (refer here and here).

DxHL7client can be launched by the impd daemon, on one or more directories where the orphan resolution and image archiving notification are stored. If a notification failed to be send, it will be kept and send later on.

COMMUNICATION PROFILES

DxNet applications provides TCP/IP Network Communication Support. DxNet applications inherit their TCP/IP stack from the HP-UX UNIX operating system upon which they execute.

DxHL7server application accepts association on a communication port controlled by the inetd Internet Daemon of the HP-UX UNIX operating system.

As DxArchive use DxHL7client to send HL7 notifications to remote applications, this process allows a retry process to ensure that all the notification are successfully received by the remote application.

RESULTING OPERATION IN DXARCHIVE

DxHL7server and DxHL7proxi are used to create, update, delete or merge patients and to create studies. The following sections show the appearance of a patient and its study in DxArchive.

Object selection window

Figure 2 is the result of a patient and a study creation in the DxDBase. The first set of information found in the selected patient area shows some of the PID segment informations. More patient related information can be found in the 'patient information' window. The object list area shows a study created for the selected patient. The information displayed are the ones found in the OBR segment.

Patient information window

As shown on Figure 3, all the information decoded from the PID segment are stored in DxDBase. DxArchive allows to display those information.

DXARCHIVE ORPHAN RESOLUTION NOTIFICATIONS

DxArchive can create notifications during the process of orphan resolution (Orphan Pool). This function allows to merge information from an orphan patient with the ones from a real patient.

The type of message used to express an orphan resolution is an ORU message. Each segment of this message is used as explained in the following table :

This segment is not filled because conforming to the HL7 standard it is used to store study information (refer to §5.4). 

The configuration file used while image archiving gives all the information to be stored in the OBX segment. The OBX segment fields are composed of the following components separated by HL7 component separator character:

	DxArchive item name,
	item value,
	item comment.

Some extra OBX segments are added to the end of the HL7 notification. The DICOM UID of all the images of the orphan patient are provided.

MSH segment

EVN segment

As define in the HL7 standard.

PID segment

The PID segment gives information about the real patient who has been merged with the orphan patient. The orphan patient information are found in the OBX segments.

OBR segment

The OBX segment is present in the notification but its fields are empty. No study ID is given because the following OBX segments give information about all the studies related to the orphan patient (refer here and here).

Configurable OBX segment

The first OBX segment show a keyword to express the fact that the notification refer to merge action in DxDBase Orphan Pool. This keyword is MDS_MERGE_NOTIFICATION. Following this first OBX segment some configurable segment are provided as explained in the next table.

A configuration file allows to add to the HL7 notification as many OBX segments as needed to provide information on the archived patient/image file. The field contains 3 sub components :

	DxArchive item name,
	item value,
	item comment.

The item name and the comment are found in the configuration file. The item value is retrieved from the DxDBase.

Some extra OBX segments are provided to give information about all the images stored for the orphan patient. Those OBX segments show the keyword 'Dicom UID' followed by the ID of the image fount in the DxDBase.

DXMULTIMODALITY NOTIFICATIONS

The DxMultiModality interface can create, update or delete patients. Therefore those actions can produce some HL7 Notifications. Those notifications can be configure as desired : the type of message can be chosen and the content of the segments id fully configurable.

From the Object Selection Window the following actions are possible:

• Create a new patient,
• Delete a patient.

From the Patient Information Window the following actions are possible:

• Update a patient

From the Orphan Pool Window

• Create a new patient,
• Delete a patient,
• Merge two patients (see § 5).

The availables types of message are the following :

• ADT^A01
• ADT^A03
• ADT^A08
• ADT^A18
• ADT^A23
• ORU

(1) The OBX segments may be added depending on the options chosen in the configuration.

IMAGE ARCHIVING NOTIFICATIONS

DxArchive system initiates association messages to remote applications when an image is successfully archived in DxDBase. The messages provided are based on the ORU message type.

DxArchive archiving process use different segments of the ORU message type in the notification message, to reference and identify the image imported as described in the following sections.

The configuration file used while image archiving gives all the information to be stored in the OBX segments. The OBX segments are composed of the following components separated by HL7 component separator character:

	DxArchive item name,
	item value,
	item comment.

A list of the available is DxArchive items is provided to allow site information needs adjustments.

MSH segment

EVN segment

As defined in the HL7 standard.

PID segment

Most of the PID segment fields are field if the decoding process found out the needed information in the patient/image file.

OBR segment

DxDBase OBX segment

By default a single OBX segment is found in the HL7 notification issued by the archiving process. The following table describe this particular segment.

Fixed to a set of DICOM information, necessary to identify the archived image as required by the DICOM standard. This field shall contain 9 components, the definition of each one being as following:

	Patient Orphan Flag
	Study Orphan Flag
	Patient ID
	Study Instance UID
	Series Instance UID
	SOP Instance UID
	SOP Class UID
	Transfer Syntax
	Modality

The Patient Orphan Flag refers to the orphan status of the patient associated with the image for which the notification is sent, while Study Orphan Flag refers to the orphan status of the related study. Possible values for those two components are:

	Y if orphan
	N if not orphan

Refer to the DICOM standard for further descriptions of the remaining components.

Configurable OBX segment

A configuration file allows to add to the HL7 notification as many OBX segments as needed to provide information on the archived patient/image file. The field contains 3 sub components :

	DxArchive item name,
	item value,
	item comment.

The item name and the comment are found in the configuration file. The item value is retrieved from the DxDBase.

QUERIES

QUERY MESSAGE

The HL7server process is able to answer to simple queries as define in the following sections. The query response are provided in a non-deffered way. The information provided by the response are configurable and can contain any data that have been stored in the DxDatabase that are related to the patient or its studies.

MSH segment

QRD segment

QRF segment

DISPLAY RESPONSE MESSAGE

MSH segment

MSA segment

ERR segment

QAK segment

QRD segment

The complete segment is copied from the original message.

QRF segment

The complete segment is copied from the original message.

DSP segment

CONFIGURATION

DxHL7server, DxHL7proxi, DxHL7client and the images archiving process are providing different levels of configuration through the use of resources found in configuration files. Therefore it is possible to specify :

	message construction rules (separators, encoding format, headers, trailers, ...),
	information provided by the images archiving process,
	assignment of HL7 notification fields to DxDBase fields,
	control of receiving and sending application or facility,
	action to associate to a specified HL7 message type.
	assignment of different type of HL7 notification to the different events in DxMultiModality.

Refer to the document UL/P6/XCA/24Oct96/120 DxArchive System Configuration and Administration for a complete description of the configuration of the DxNet HL7 Implementation.