hl7 order reception

36
Connection sheet SHEET # CONNECTION NAME REV # VERSION 11 Order Reception (HL7 2.4 / TCP-IP Socket) 3 V02.01 This interface specification is confidential and is strictly reserved for communication with a Hospital Information System. An End User Agreement containing the text on the final page of the present document must be agreed by the Customer (End User). This interface specification is for the exclusive use of sites covered by an End User Agreement. Use of this interface specification implies full acceptance of the terms and conditions of the End User Agreement included hereafter. Table of contents Technical pre-requisites ...................................3 References..................................................3 Program identification......................................3 Presentation............................................... 4 Communication diagram.......................................4 Communication layers: TCP / IP socket......................6 Transmission diagram........................................6 Data Block Structure........................................7 Information exchange description............................9 Installation procedure....................................10 Implementation............................................10 "Labconf" parameters.......................................10 Device dictionary..........................................11 Activation of the connection service.......................15 Relevant HL7 messages, segment types and fields ...........16 Processed messages.........................................16 Supported segment types....................................16 Acknowledgement............................................17 Segment descriptions ......................................19 MSH - Message Header Segment...............................19 EVN - Event type segment...................................20 PID - Patient identification segment.......................20 PV1 - Patient visit information............................20 ORC - Common order Segment.................................20 OBR - observation request segment..........................22 OBX - observation / result.................................23 CNXR011 / 3 HL7: Order Reception V02.01 Page 1/36 Confidential. This specification requires an end user agreement.

Upload: jerome-b-agliam

Post on 16-Apr-2015

34 views

Category:

Documents


4 download

DESCRIPTION

HL7 Order Reception

TRANSCRIPT

Page 1: HL7 Order Reception

Connection sheet

SHEET # CONNECTION NAME REV # VERSION

11 Order Reception (HL7 2.4 / TCP-IP Socket)

3 V02.01

This interface specification is confidential and is strictly reserved for communication with a Hospital Information System. An End User Agreement containing the text on the final page of the present document must be agreed by the Customer (End User). This interface specification is for the exclusive use of sites covered by an End User Agreement. Use of this interface specification implies full acceptance of the terms and conditions of the End User Agreement included hereafter.

Table of contents

Technical pre-requisites.......................................................................................3

References............................................................................................................3Program identification...........................................................................................3

Presentation..........................................................................................................4Communication diagram.......................................................................................4

Communication layers: TCP / IP socket.............................................................6Transmission diagram...........................................................................................6Data Block Structure.............................................................................................7Information exchange description..........................................................................9

Installation procedure........................................................................................10

Implementation...................................................................................................10"Labconf" parameters..........................................................................................10Device dictionary.................................................................................................11Activation of the connection service.....................................................................15

Relevant HL7 messages, segment types and fields........................................16Processed messages..........................................................................................16Supported segment types...................................................................................16Acknowledgement...............................................................................................17

Segment descriptions........................................................................................19MSH - Message Header Segment.......................................................................19EVN - Event type segment..................................................................................20PID - Patient identification segment.....................................................................20PV1 - Patient visit information.............................................................................20ORC - Common order Segment..........................................................................20OBR - observation request segment....................................................................22OBX - observation / result...................................................................................23General constraints.............................................................................................24

Examples of ORM messages...............................................................................25

CNXR011 / 3 HL7: Order Reception V02.01 Page 1/26Confidential. This specification requires an end user agreement.

Page 2: HL7 Order Reception

Connection sheet

History of document modifications

Related version

Rev. Short description of the modification

V01.53 0 Creation of the connection sheet.

V01.53 1 Change layout/format of the connection sheet.

V02.01 2 In the Device dictionary definition paragraph, Type of flow. Order Reception:Addition of the following properties Accept assigned message number (NA).Exam grouping, Exam grouping time frame, Topography parameter code, Collection source parameter code and related Notes 1 and 2.

V02.01.h 3 - Addition of the paragraph Management of order cancelation or duplicate order message in the Presentation topic.

- Modification of the Communication diagram: Addition of the Step (4).

- In the Device dictionary definition, Type of flow Order Reception: the following property and its related Note4, have been added:Process order cancelation or duplicate order message

Page 2/26 V02.01 HL7: Order Reception CNXR011 / 3Confidential. This specification requires an end user agreement.

Page 3: HL7 Order Reception

Connection sheet

Technical pre-requisites

The connection for Order Reception (in HL7 2.4 / TCP-IP Socket) must be installed on a computer connected to the network 24 hours/day and 7 days/week (computer on which is installed the connection service).

The computer must be installed with at least Windows 2000 or XP and must be conform to the recommendations specified in the Description of System components document, available on our website (www.technidata-web.com).

References

Reference number of HL7 standard (High Level Protocol): High Level protocol HL7 2.4Chapter 4 Order Entry

Date of this standard: November 2000

Reference number of HL7 standard(Low Level Protocol)

Low Level protocol HL7 2.3Appendix C Lower Layer Protocols

Date of this standard: June 1998

Program identification

Application DLL: TDCnxAppWRH.DLL (Patients \ Order \ Results processing).

Protocol DLL: TDCnxProtoHISADT.DLL (HL7 Low Level Protocol (Socket))

Format DLL: TDCnxFormHL7.DLL (HL7 High Level Protocol)

Transport DLL: TDCnxTransTCPIPSocket.DLL (TCP-IP Socket Transport if TCP-IP Socket transport)

CNXR011 / 3 HL7: Order Reception V02.01 Page 3/26Confidential. This specification requires an end user agreement.

Page 4: HL7 Order Reception

Connection sheet

Presentation

This document describes the rules for reception of Order Entry messages (ORM messages) transmitted from a HOST via:- HL7, for the high-level protocol and,- TCP/IP socket.This description is based on the principles given by the HL7 Appendix C Lower Layer Protocols chapter.The generic rules that apply to all messages and the specific messages to be exchanged among certain applications can be found in the HL7 documentation.

HL7protocol (Health Level Seven) objective is to provide standards relative to the structure of the information to be exchanged between multiple healthcare information systems, such as laboratories, radiology.

The referenced high-level protocol is the HL7 version 2.4 (Standard specification for transferring clinical observations between independent computer systems) and the aim of this document is to present the mechanisms of that protocol implemented for receiving order on the management database.

Communication diagram

Page 4/26 V02.01 HL7: Order Reception CNXR011 / 3Confidential. This specification requires an end user agreement.

Page 5: HL7 Order Reception

Connection sheet

Management of order cancelation or duplicate order message (Step 4 in the above diagram)

When this management is enabled (by the property Process order cancelation or duplicate order message in the Device dictionary, "Order reception" data flow), the following cases are processed:

Duplicate order asked by the HIS

1. The PON (Placer Order Number) does not exist in the requestWhen the LIS receives a test code already present in the order but with a PON different from the already received order, an ORM message is sent to the HIS with the field ORC-1=OC (Order Canceled). This message is sent whatever the tube status (collected or not) may be. The HIS has to acknowledge this message.

2. The PON already exists in the requestWhen the LIS receives a test already present in the order with a PON already received:

- If at least one tube associated with the request has been collected, the LIS does not take into account this new order, but no cancelation message (ORM message with ORC-1 = OC) is sent to the HIS.

- If no tube associated with the request has been collected, the test is updated normally.

Order cancelation asked by the HIS When the HIS wants to cancel a test, it sends an ORM message with the field ORC-1=CA (Cancel Order). In this case a number of verifications are made.

1. If the PON already exists and the tube associated with the test B is already collected or declared arrived at the laboratory, the test cannot be canceled. Then an ORM message is transmitted to the HIS with the field ORC-1=UC (Unable to Cancel).

2. If the PON already exists and the tube associated with the test B is not collected, the requested cancelation is performed.

Examples:1) – The request contains the tests A and B

Test A tube 1 (collected)Test B tube 2 (not collected)

The HIS sends a cancelation message for test B, and test B is canceled.

2) – The request contains the tests A and BTest A tube 1 (collected)Test B tube 1

The HIS sends a cancelation message for the test B, and- test B is NOT canceled- an ORM message with ORC-1=UC (Unable to Cancel) is sent to the host.

In this case, test B is not canceled because, in some cases, tests are billable as soon as the sample is collected.

Addition of a test asked by the HISWhen the HIS wants to add a test to an existing order, it sends an ORM message with the field ORC-1=NW (New). After verification, if the test cannot be added (the order contains a tube already "collected") an ORM message is transmitted to the HIS with the field ORC-1=OC (Order Canceled).

When this management is enabled an Output device must be specified to transmit orders to the HIS. Refer to the connection sheet CNXR023 Transmission of orders for this part of the communication.

CNXR011 / 3 HL7: Order Reception V02.01 Page 5/26Confidential. This specification requires an end user agreement.

Page 6: HL7 Order Reception

Connection sheet

Communication layers: TCP / IP socket

TCP/IP socket low-level protocol is the transport layer used for exchanging data between devices located on the same network. The purpose of this chapter is to describe the exchange between a Host Information System and the Communication engine when TCP/IP socket is implemented as low-level protocol.

Transmission diagram

After the connection between the client and the server connection task, data are sent to the server by the client.

Host Information System (Client) Connection (Server)

Connection phase between the client and the server: Socket creation, establishment of the connection etc …(cf : Information exchange description)

<SB>tvv<CR>ddddcccccxxx<EB><CR> ¾¾¾>

Data block sent by the client with an HL7 ADT (patient administration) embedded message. After control of the correct data transfer (physical integrity), the HL7 message is parsed and managed. Depending on the result of these processes, an HL7 ACK message is sent with the error code in case of problem.

Data block sent by the server with a HL7 ACK message embedded

<¾¾¾ <SB>tvv<CR>ddddcccccxxx<EB><CR>"dddd" contains the different HL7 messages composing the logical acknowledgement (MSH, MSA and ERR segments).

It is up to the client system to close the connection upon reception of the Acknowledgement

Connection phase between the client and the server: Socket creation, establishment of the connection etc …(cf : Information exchange description)

<SB>tvv<CR>ddddcccccxxx<EB><CR> ¾¾¾> Data block sent by the client with an HL7 ADT (Patient administration)message embedded. On the physical integrity control, a wrong block format has been detected. A special data block is sent (NAK block).

Data block sent by the server with a physical NAK message embedded into it (character 'C')

<¾¾¾ <SB>Nvv<CR>C000EBxxx<EB><CR>Negative physical acknowledgement sent by the connection if something is wrong on the physical transmission (wrong checksum, wrong count of characters)

It is up to the client to send the data block back or to discard it and to execute its own error handling routine

<SB>tvv<CR>ddddcccccxxx<EB><CR> ¾¾¾> Data block sent by the client with an HL7 ADT (Patient administration)message embedded into it. After control of the correct data transfer (physical integrity), the HL7 message is parsed and managed. Depending on the result of these processes, an HL7 ACK message is sent with the error code in case of problem or without error code if all is correct.

Data block sent by the server with a HL7 ACK message embedded into it

<¾¾¾ <SB>tvv<CR>ddddcccccxxx<EB><CR>"dddd" contains the different HL7 messages composing the logical acknowledgement (MSH, MSA and ERR segments).

It is up to the client to close the connection upon reception of the Acknowledgement

Page 6/26 V02.01 HL7: Order Reception CNXR011 / 3Confidential. This specification requires an end user agreement.

Page 7: HL7 Order Reception

Connection sheet

Data Block Structure

Depending on the TCP-IP Lower Layer Protocol parameter in the Device Dictionary, 2 data block structures are possible. The Hybrid and the Minimal.

1. Hybrid HL7 Low Layer Protocol

There are two types of blocks: the data blocks and the NAK blocks.HL7 messages are transmitted in single data blocks.NAK blocks are used to signal physical transmission errors (NAK is used at low level protocol, instead of Nack used at high level protocol).

Both block types have the same format:<SB>tvv<CR>ddddcccccxxx<EB><CR>

Blocks consist of the following fields:

<SB> = Start Block character (1 byte).Configurable on site specific basis. Unless there is a conflict, the value should be ASCII <VT>, i.e. <0x0B>. This should not be confused with the SOH or STX ASCII characters.This character must equal the one configured as "Start of block character" in the device dictionary.

t = Block Type (1 byte)."D" = Data block"N" = NAK block

vv = Protocol ID (2 bytes).Characters "24" for this version.

<CR> = Carriage Return (1 byte).The ASCII carriage return character, i.e. <0x0D>.

dddd = Data (variable number of bytes).In a data block, it corresponds to the data content of the block. The data can contain any displayable ASCII characters and the carriage return character, <CR>. Carriage returns that are not part of the HL7 message may be inserted as described in "Carriage Return Stuffing."

In a NAK block, this field contains a 1-byte reason code as follows:'C' - character count wrong in previous data block received'X' - checksum wrong in previous data block received'B' - data too long for input buffer in previous block received'G' - Error not covered elsewhere.

ccccc = Block Size (5 bytes).Character count of all characters so far in the data block up to and including the data last character. For this protocol version, it corresponds to 5 + the size of the "dddd" field. Note: HL7 message ends with a <CR> character. This character is considered as part of the data.

CNXR011 / 3 HL7: Order Reception V02.01 Page 7/26Confidential. This specification requires an end user agreement.

Page 8: HL7 Order Reception

Connection sheet

xxx = Checksum (3 bytes).Exclusive-OR checksum of all characters in the block up to and including the data last character. The checksum is expressed as a decimal number in three ASCII digits. If the value of this field is 999, the checksum should not be computed.Processing will proceed as if it were correct. This feature is used for applications where the messages will be translated from one character set to another during transmission.The "Checksum type" parameter in the device dictionary must be set to "Checksum for HL7 low layer protocol".

<EB> = End Block character (1 byte).Configurable according to the site. Unless there is a conflict, the value should be ASCII <FS>, i.e. <0x1C>. This should not be confused with the ETX or EOT ASCII characters.This character must equal the one defined as "End of block character" parameter in the Device dictionary.

<CR> = Carriage Return (1 byte).The ASCII carriage return character, i.e., <0x0D>.

2. Minimal HL7 Low Layer Protocol

HL7 messages are enclosed by special characters to form a block. The format is as follows:

<SB>dddd<EB><CR>

<SB> = Start Block character (1 byte)ASCII <VT>, i.e. <0x0B>. This should not be confused with the ASCII characters SOH or STX.

This character must equal the one configured as "Start of block character" in the Device dictionary.

dddd = Data (variable number of bytes)

This is the HL7 data content of the block. The data can contain any displayable ASCII characters and the carriage return character, <CR>.

<EB> = End Block character (1 byte)ASCII <FS>, i.e., <0x1C>. This should not be confused with the ASCII characters ETX or EOT.

<CR> = Carriage Return (1 byte)The ASCII carriage return character, i.e. <0x0D>.

This character must equal the one configured as "End of block character" in the Device dictionary.

Page 8/26 V02.01 HL7: Order Reception CNXR011 / 3Confidential. This specification requires an end user agreement.

Page 9: HL7 Order Reception

Connection sheet

Information exchange description

Data exchange between the Host Information system and the Communication engine corresponds to data blocks being transmitted through a socket.

In order to perform the data exchange, a socket (connection) must be established first. One system has to be the server, the other must be the client. The client will ask the server permission to connect to a specific port. The server on its side must be listening to this port.

The sequence order in which operations must be performed is:1. The server must be created and must be listening to a specific port. 2. The client will ask the server permission to connect to this port. If granted, a socket is established

between the client and the server. Data can be sent back and forth via the previously established socket.

In our case, the Communication engine will act as the server and the Host Information system as the client.

Pre-requisites and sequence of operations (see also "Example of definition for TCP/IP socket" paragraph further in the document)

In order for the TCP/IP socket low-level protocol to work properly, several parameters must be set:1. The machine on which the server will be created, must be declared as the "recipient's network address" (it can be the network name or the dotted address).2. The port the server will be listening to is declared as the listening port.3. The transmission mode is set to Mono client server transmission mode.4. The connection (Communication engine) has to be started and listening to the configured port.5. At this time one and only one simultaneous connection will be accepted by the server.

After being allowed to access to the server, the client can send its data blocks through the socket and it can read answers back.

6. When it is finished, the client disconnects.

Incidents managed on the socket

* If the server tries to accept a client connection while already having a client connected to it, the following error is generated: More than one connection has been opened on the server!

* If the server could not instantiate a client socket upon creation, the following error is generated:Invalid client socket retrieved!

* If the server cannot accept a client connection, the following error is generated:Couldn't accept connection!

* If any exception occurs while reading from the socket, the next error is generated:Couldn't receive data through socket!

CNXR011 / 3 HL7: Order Reception V02.01 Page 9/26Confidential. This specification requires an end user agreement.

Page 10: HL7 Order Reception

Connection sheet

Installation procedure

The Communication engine must be installed with a Client instance.

When the connection selection screen is displayed:

1. Select HL7: Order reception by left-clicking on the corresponding line 2. Choose This feature will be installed on local hard drive option.

Implementation

To implement this connection, a number of parameter settings must be performed at different levels, as listed hereafter:

- Definition of Labconf parameters on the management database- Device dictionary the management database- Activation of the service specified in the Device dictionary

"Labconf" parameters

You must verify some "Labconf" parameters on the management database before starting the implementation. Make sure that the lengths of the following fields are the same as on the production database (Parameter setting zone – GST block):

These parameters are:- Patient number length- Alternate patient number length- Hospitalization number length- Reduced access number length- Database name (*)

* Database name is the logical name of the database. It is used both by the Web module and this connection. It must be the same for both. Refer to the Web module parameters to verify it (Administration tool, File menu, Databases item, Name field.

Page 10/26 V02.01 HL7: Order Reception CNXR011 / 3Confidential. This specification requires an end user agreement.

Page 11: HL7 Order Reception

Connection sheet

Device dictionary

This step consists in defining and customizing the parameters used for the reception of orders (new or updated information about orders). This connection must be defined as a device and consequently it must be defined in the Device dictionary.

Create a new device.From the TD Control panel, select System Setup (Dictionaries), General dictionaries then Device. In the menu bar, click on the ++ sign.

Name Value CommentCodeDevice typeService TDCnx_InstanceName_Computernam

ename of the computer where is installed the service.

NameAbbreviated textFull textProtocol HL7 low layer Protocol (Socket)Format HL7 formatTransport TCP-IP socket transportApplication Patients/Order/Results processingProperties More...

The Protocol, Transport, Format and Application parameters give the user-friendly names of the different DLLs used for the connection. These DLLs are automatically installed by the setup program.

Once you reach this step, you must click the OK button to update the Properties.

The Properties parameters are used for defining the parameters related to a type of flow. Three types of flow must be defined:1. All (displayed by default).2. Patient demographic data reception flow.3. Order reception

1. Type of flow: AllOnly the connection specific parameters are described here.

Device properties

Type of flow: All

Name Value CommentGeneralInterval before task purging (days) If this parameter is not defined here,

the same parameter defined in the Laboratory configuration is applied.

Maximum size of spy file (KB) 1000Number of insertion retries in the database

1 Do not modify.

Path of spy file C:\technidata\spy.txtSpy traces enabled Yes Once the installation is

finished and you have checked it runs well, set it to No.

Trace level of spy file Maximum Three level of traces are available: minimum, regular, maximum

CNXR011 / 3 HL7: Order Reception V02.01 Page 11/26Confidential. This specification requires an end user agreement.

Page 12: HL7 Order Reception

Connection sheet

FormatHL7 version 2.3 For exampleMessage recipient code TDR

Message sender code HOST

Unicode messagingTransport

The Transport section contains the different parameters used for defining the characteristics of the TCP-IP.

Name Value CommentChecksum type Checksum applied on the socket

frame. Must be set to HL7 Low Layer Protocol

End of block character Last character of the socket (<1C> in the definition of the socket frame)

Do not modify

Listening port Input port 8102 for exampleMessage time-out Period of time (in seconds) during

which data is expected on the socket. After this time, the server considers the link broken.

30 for example

Outgoing port Output port

When selecting a port (either listening or outgoing), make sure that the port is not already used by another application.

Name Value CommentProtocol version 23 23 for Keane Recipient network address IP address or logical name of the

receiverSender network address IP address or logical name of the

sender.Start of block character First character of the socket (<0B> in

the definition of the socket frame)Do not modify

TCP-IP layer protocol Hybrid/Minimal To modify on siteMinimal for Keane

Transmission mode Defines the mode used by the socket connection (client/server, Mono/Multi client).

Must be set to Mono client server transmission mode

File locationChameleon file path Name of the path for the hl7.vmd

Chameleon file.Input processed folder c:\technidata For example

2. Type of flow: Patient demographics reception

A patient demographics reception flow must be defined. Refer to the connection sheet CNXR010 to define the Patient demographics reception flow.

Page 12/26 V02.01 HL7: Order Reception CNXR011 / 3Confidential. This specification requires an end user agreement.

Page 13: HL7 Order Reception

Connection sheet

3. Type of flow: Order reception

Device properties

Type of flow: Order reception

Name Value Comment General

The General section defines how the test order data received in the HL7 message are managed:These test order data can be:- only set in the Management database,- only forwarded to another device, for this flow only demographic data is forwarded (via a FTP

transfer of ASTM 1238 files to send the demographic data to the Production database for example),

- set in the Management database and forwarded to another device.- set in the Management database and transmitted to laboratory by (through a file transfer of ASTM

1238 files by the "rectube" process of the Web module).

"Set in Management database" and "forwarded to another device" possibilities are both managed by the Update local database and Output devices parameters. If Output devices is filled in with the connection identification used to ensure the patient data transfer to another device, a job is created to enable the patient data transfer through the customized connection.

Name Value CommentStream active Yes, activated flow.

No, not activated flowAccept assigned message number (NA)

Yes, activated flow Set Yes to enable the reception of the Number Assigned by the Host, in answer to a Placer order number query message from the Laboratory Information System

Automatic activation for immediate orders

Yes, activatedNo, not activated

Automatic activation for routine orders

Yes, activatedNo, not activated

Automatic activation for urgent orders

Yes, activatedNo, not activated

Numbering of order:This parameter is used to define how to create the Full Access Number.If the Host sends this number (numbering mechanism should be identical to the numbering supported by the Management database), the automatic number mechanism is ignored.

Name Value CommentAutomatic number for orders Select the counter which are used for

create the Full Access Number

The counter must be previously declared and set up on TDNTPanel. Refer to the related documentation to create this counter.

When defining the counter, make sure that the range of numbers is reserved for order creation on the Management database

It is possible to transmit test order automatically to the production database by ASTM 1238.The following parameters are used to activate automatic transmission of test order to the production database or another H.I.S.

Name Value CommentExam grouping Yes (to enable grouping several tests

into a single order)

CNXR011 / 3 HL7: Order Reception V02.01 Page 13/26Confidential. This specification requires an end user agreement.

Page 14: HL7 Order Reception

Connection sheet

Exam grouping timeframe (minutes)

10Default value = 35

See Note 1

Output devices […] Opens a window to select the Device and the data flow it is used for

Set to HL7 device used to send data to HIS: HL7HIS / Order sending

Processing type Must be set to Test Orders.

Process order cancelation or duplicate order message

Yes/NoDefault value = Yes

See Note 4

Sample reception DLL file path Path to access to TD-Web Rectube process (TDCollectionReception.dll).

See (*)

Update local database YesFormatCollection source parameter code

Code of the complementary parameter used with results received in OBR-15.1

See Note 2To define if needed by the H.I.S.

Topography parameter code Code of the complementary parameter used with results received in OBR-15.4

See Note 2To define if needed by the H.I.S.

MappingCoded texts Code of the coding system used to

map coded text codes. See Note 3.Create/select the code of a coding system.

Doctors Code of the coding system used to map doctor codes. See Note 3.

Create/select the code of a coding system.

Locations Code of the coding system used to map location codes. See Note 3.

Create/select the code of a coding system.

Tests Code of the coding system used to map test codes. See Note 3.

Create/select the code of a coding system.

Titles Code of the coding system used to map title codes. See Note 3.

Create/select the code of a coding system.

Note 1:An algorithm is used to group together several tests into a same order. This algorithm respects the following rules:-Same patient and same hospital stay for the test order -The location of the new test should be the same as for the other tests-The reference collection date/time corresponds to the scheduled collection date/time of the first received

test ( with +/- n minutes definable in the Exam grouping timeframe parameter.

Note 2:Both data will be stored as coded text type results and are associated with two complementary parameters. These complementary parameters are used to store the corresponding information.

Note 3:Mapping is used to create correspondences between the Management database and Host systems code values (local codes and alternate codes). You can find the description of "Mapping alternate codes" in the Technical guide online help under Installation book.

Note 4:This property is used to enable (answer Yes) or disable (answer No) the processing of order cancelation or duplicate order message.To enable the transmission of order cancelation or duplicate order messages to the H.I.S, answer Yes and specify an Output device. The Output device used should be the one used for the connection Transmission of Orders (CNXR023).If this property is enabled and no Output device is associated with the order reception device the task created by the received message will be set to the error status and a message will ask the user to specify an output device.

(*)TD-Web Reception of tubes tool (Rectube)

Page 14/26 V02.01 HL7: Order Reception CNXR011 / 3Confidential. This specification requires an end user agreement.

Page 15: HL7 Order Reception

Connection sheet

The Reception of tubes tool of the Web module is installed with the setup of the Web module. Please refer to the Web module installation for this components and its parameter setting. For the Sample DLL reception file path parameter, please specify the path to access to the TDCollectionReception.dll (in the path of Reception of tubes tool installation)

In the Parameters window of the Reception of tubes tool, under Connection tab, field Directory, you must enter an absolute pathname and not a volume mounting (e.g.,\\labo\tmp\ftp

Activation of the Connection service

Use the Windows Service manager to start the TDConnexion service. The connection service appears under the name "TDCnx_InstanceName".

CNXR011 / 3 HL7: Order Reception V02.01 Page 15/26Confidential. This specification requires an end user agreement.

Page 16: HL7 Order Reception

Connection sheet

Relevant HL7 messages, segment types and fields

Processed messages

This connection can manage three types of messages:- ORM : General order message (event O01)- OMG : General clinical order message (event O19)- OML : Laboratory order message (event O21)

For the OML message, the information or the segments relating to the sample data or to the previous results are ignored.

This connection is limited to the processing of Segment / Field / SubField described further.

Supported segment types

You will find in this chapter general information of these segment types.

MSH - Message Header Segment.It defines the type, the event of the message and indicates other information such as the sender, the receiver.

EVT - Event information segment.It defines the Event of the message.

PID - Patient information segmentIt contains patient information exchanged between the sender and the receiver.

PV1 - Hospitalization information segment.It contains hospitalization visit information exchanged between the sender and the receiver.

ORC - Common Order segment.It contains information necessary to create or update prescriptions.

OBR - Observation Request SegmentIt contains information necessary to create or update prescription tests.

OBX - Observation / Result SegmentIt contains information necessary to create or update additional parameters for the tests.

Each message must be identified by a "message header" segment.

A segment is composed of fields.A field is the basic element of information in any segment. For each type of record, HL7 protocol lists all the fields possibly used for medical information exchanges. Only the processed fields and their corresponding meaning are described for each record type in "Segments description".

The next part of the paragraph deals with characteristics common to all fields. It concerns field rules and the different abbreviations used all along in the document.

The field identificationIn each segment type, fields are identified by a number. This identification corresponds to the HL7 definition.

The field delimitersA character defined as a delimiter separates each field from the next one. This field delimiter must even follow the last field of a record.

Page 16/26 V02.01 HL7: Order Reception CNXR011 / 3Confidential. This specification requires an end user agreement.

Page 17: HL7 Order Reception

Connection sheet

The field sizeAll field sizes given in the document are maximum sizes as specified in HL7 standards. Each field contains only significant information, without any left or right filling characters.

The DT column of the HL7 data types by category table gives the Data Type of the field. The complete list of the HL7 Data Types is defined in the Chapter 2-Control of the HL7 version 2.4.

Acknowledgement

If no problem occurs during the management of the message, a positive logical acknowledgement is sent to the Host and the created job is set to the "Completed" status.In the positive logical acknowledgement sent by the connection, the MSA-1 field Acknowledgment code is set to "AA" (application acknowledgement Accept) and the ERR-1 field, subfield 4, "Error code" is set to the "0" error code.

0 Message accepted Success. Optional, as the AA conveys success. Used for systems that must always return a status code.

During the management of the ADT (Patient administration) message , some errors can occur. In such cases, the created job is set to the "Error" status.

Incident management

- Case 1: The connection has detected X differences between the demographic data of the patient in the management database and the transmitted demographic data (the controls on the demographic data are done on the first name and last name, the maiden name, the sex and the birth date of the patient). X is greater than the authorized number of differences customized with the Patient differences parameter.In such a case, the OMG / OML / ORM message is not integrated in the management database and a negative logical acknowledgement is sent to the host.

In the negative logical acknowledgement sent by the connection, the MSA-1 field Acknowledgment code is set to "AR" (application acknowledgement Reject) and the ERR-1 field, subfield 4, "Error code" is set to the "207" error code, and the MSA-3 field is filled in with the string "A catchall for internal errors not explicitly covered by other codes".

207 Application internal error

A catchall for internal errors not explicitly covered by other codes.

- Case 2: The previous control is correct but the connection has detected two different patients with the same "Alternate number" in the management database.In such a case, the OMG / OML / ORM message is not integrated in the management database and a negative logical acknowledgement is sent to the host.In the negative logical acknowledgement sent by the connection, the MSA-1 field Acknowledgment code is set to "AR" (application acknowledgement Reject) and the ERR-1 field, subfield 4, "Error code" and the "ERR-1" fields are set to the error code "205". The MSA-3 field is filled in with the string "The ID of the patient, order, etc., already exists".

205 Duplicate key identifier

The ID of the patient, order, etc., already exists. Used in response to addition transactions (Admit, New Order, etc.).

Case 3: The OMG / OML / ORM message sent by the Host cannot be properly parsed (problem on the HL7 structure).In such a case, the OMG / OML / ORM message is not integrated in the management database and a negative logical acknowledgement is sent to the Host.

CNXR011 / 3 HL7: Order Reception V02.01 Page 17/26Confidential. This specification requires an end user agreement.

Page 18: HL7 Order Reception

Connection sheet

In the negative logical acknowledgement sent by the connection, the MSA-1 field Acknowledgment code is set to "AE" (application acknowledgement Error) and the ERR-1 field, subfield 4, "Error code" and "ERR-1" fields are set to the error code "100". The MSA-3 field is filled in with the string The message segments were not in the proper order, or required segments are missing.

100 Segment sequence error

The message segments were not in the proper order, or required segments are missing.

Case 4: The OMG / OML / ORM message sent by the Host is properly parsed and managed but the database is locked / not available or the patient / Prescription record to update is protected.In such a case, the OMG / OML / ORM message cannot be integrated in the management database and a negative logical acknowledgement is sent to the Host.In the negative logical acknowledgement sent by the connection, the MSA-1 field Acknowledgement code is set to "AR" (application acknowledgement Reject) and the ERR-1 field, subfield 4, "Error code" and "ERR-1" fields are set to the error code "206". The MSA-3 field is filled in with the string The transaction could not be performed at the application storage level.

206 Application record locked

The transaction could not be performed at the application storage level, e.g. database locked.

Case 5: The test order message sent by the Host is properly parsed but some data are no correct, for example: - A test or an additional parameter is unknown- A test is not requestable- A test is duplicate- A results of type coded text is expected and the coded results is not definedIn such a case, the test order message is partially integrated in the management database and a negative logical acknowledgement is sent to the Host.In the negative logical acknowledgement sent by the connection, the MSA-1 field Acknowledgment code is set to "AR" (application acknowledgement Reject) and the ERR-1 field, subfield 4, "Error code" and "ERR-1" fields are set to the "207" error code. The MSA-3 field is filled in with the string "A catchall for internal errors not explicitly covered by other codes (Test order : #XXXXXXXXXX)."XXXXXX corresponds to the access number or external order number if it is transmitted by the Host.

207 Application internal error

A catchall for internal errors not explicitly covered by other codes.

Case 6: The update test order message sent by the Host is properly received but for this test order the corresponding specimen is already received in the laboratory.

In such a case, the test order message cannot be integrated in the management database and a negative logical acknowledgement is sent to the Host.In the negative logical acknowledgement sent by the connection, the MSA-1 field Acknowledgment code is set to "AR" (application acknowledgement Reject) and the ERR-1 field, subfield 4, "Error code" and "ERR-1" fields are set to the "207" error code. The MSA-3 field is filled in with the string " A catchall for internal errors not explicitly covered by other codes (Specimen received for test order: #XXXXXXXXXX)." XXXXXX corresponds to the access number or external order number if it is transmitted by the Host.

207 Application internal error

A catchall for internal errors not explicitly covered by other codes.

Page 18/26 V02.01 HL7: Order Reception CNXR011 / 3Confidential. This specification requires an end user agreement.

Page 19: HL7 Order Reception

Connection sheet

Segment descriptions

MSH - Message Header Segment

SEQ LEN DT FIELD NAME On Communication Engine

1 1 ST Field Separator Used to parse the HL7 message2 4 ST Encoding Characters Used to parse the HL7 message3 180 HD Sending Application Used for message acknowledgment4 180 HD Sending Facility Not Used5 180 HD Receiving Application Used for message acknowledgment6 180 HD Receiving Facility Not Used7 26 TS Date/Time Of Message Not Used8 40 ST Security Not Used9 13 CM Message Type Used to determine the message type

10 20 ST Message Control ID Used to identify the rejected message in case of error (job information)

11 3 PT Processing ID Not Used12 60 VID Version ID Not Used13 15 NM Sequence Number Not Used14 180 ST Continuation Pointer Not Used15 2 ID Accept Acknowledgment Type Not Used16 2 ID Application Acknowledgment Type Not Used17 3 ID Country Code Not Used18 16 ID Character Set Not Used19 250 CE Principal Language Of Message Not Used20 20 ID Alternate Character Set Handling

SchemeNot Used

21 10 ID Conformance Statement ID Not Used

MSH 1 - 2 Field Separator / Encoding CharactersDefines the message delimiters.The first five-character set following the H character |^~\& defines which field separators are used. The following ones are used:| = Field delimiter.^ = Sub-field delimiter.~ = Repeat sub-field delimiter.\ = ESCAPE sequence & = Sub-field component delimiter.

MSH - 3 Sending ApplicationDetermines the connected Host. Used for acknowledgment message.

MSH - 5 Receiving ApplicationDetermines the receiving application. Used for acknowledgment message.

MSH - 9 Message TypeDetermines the message type (Message type code + event code).

CNXR011 / 3 HL7: Order Reception V02.01 Page 19/26Confidential. This specification requires an end user agreement.

Page 20: HL7 Order Reception

Connection sheet

EVN - Event type segment

The EVN segment is used for communicating necessary trigger event information to receiving applications.

SEQ LEN DT FIELD NAME On Communication Engine

1 3 ID Event Type Code Not Used2 26 TS Recorded Date/Time Not Used3 26 TS Date/Time Planned Event Not Used4 3 IS Event Reason Code Not Used5 250 XCN Operator ID Not Used6 26 TS Event Occurred Not Used7 180 HD Event Facility Not Used

None of EVN information is managed by the connection.

PID - Patient identification segment

The PID segment contains patient information exchanged between the sender and the receiver.

The description of that segment can be found in the "Patient Administration Reception" connection sheet, referenced "CNXR010".

PV1 - Patient visit information

The description of that segment can be found in the "Patient Administration Reception" connection sheet, referenced "CNXR010".

ORC - Common order Segment

SEQ LEN DT ELEMENT NAME On Communication Engine

1 2 ID Order Control Order control2 22 EI Placer Order Number External Order Number3 22 EI Filler Order Number Full Access Number4 22 EI Placer Group Number Not Used5 2 ID Order Status Not Used6 1 ID Response Flag Not Used7 200 TQ Quantity/Timing Not Used8 200 CM Parent Not Used9 26 TS Date/Time of Transaction Not Used

10 250 XCN Entered By Not Used11 250 XCN Verified By Not Used12 250 XCN Ordering Provider Prescriber Code13 80 PL Enterer’s Location Location Code14 250 XTN Call Back Phone Number Test order comment15 26 TS Order Effective Date/Time Collection date and time16 250 CE Order Control Code Reason Not Used17 250 CE Entering Organization Not Used18 250 CE Entering Device Not Used19 250 XCN Action By Not Used20 250 CE Advanced Beneficiary Notice Code Not Used21 250 XON Ordering Facility Name Not Used22 250 XAD Ordering Facility Address Not Used

Page 20/26 V02.01 HL7: Order Reception CNXR011 / 3Confidential. This specification requires an end user agreement.

Page 21: HL7 Order Reception

Connection sheet

SEQ LEN DT ELEMENT NAME On Communication Engine

23 250 XTN Ordering Facility Phone Number Not Used24 250 XAD Ordering Provider Address Not Used25 250 CWE Order Status Modifier Not Used

ORC - 1 Order Control

- NW (New order), causes the creation of the Test Order.- CA (Cancel order), causes the cancellation/deletion of the order if the associated specimen are not yet

received by the laboratory. - OC (Order Cancelled), same as CA but does not require acknowledgement.

ORC - 2 Placer Order Number

This field contains the External order number. It must be unique for a test order.

ORC - 3 Filler Order Number

This field contains the Full Access Number or the Reduced Access Number of the request defined on the production database . In most cases, it should be left empty by the Host, unless the Request/Specimen numbering mechanism is identical to the Request/Specimen numbering of the production database.

It must be unique for a test order. It is not possible to change this number by a CDE (the first value is kept).

In the case of a Reduced Access Number:The Full Access Number is built from the collection date (ORC-15) if specified or with the system date otherwise.The length of the received Reduced Access Number must be in accordance with the parameter Reduced access number length defined on the management database (Laboratory configuration).

ORC - 12 Ordering Provider

The first subfield contains either the Host system Text or the Mnemonic code of the Prescriber (Dr1 in production database). This field should be identical to the OBR 16 field.

ORC - 13 Enterer’s Location

The first subfield contains either the Host system Text or the Mnemonic code of the requesting Location (CR in production database).

ORC - 14 Call Back Phone Number

Since there is no dedicated field in the production database to store this information, the content of this field is stored in Clinical Details field (RCO) of the production database.

ORC - 15 Order Effective Date/Time

This field contains the Collection date and time. If the specimen are "To Be collected", this field indicates the date and time when they should be collected.

CNXR011 / 3 HL7: Order Reception V02.01 Page 21/26Confidential. This specification requires an end user agreement.

Page 22: HL7 Order Reception

Connection sheet

OBR - observation request segment

SEQ LEN DT ELEMENT NAME On Communication Engine

1 4 SI Set ID - OBR Not Used2 22 EI Placer Order Number External Order Number3 22 EI Filler Order Number Full Access Number4 250 CE Universal Service Identifier Test Code5 2 ID Priority - OBR Not Used6 26 TS Requested Date/Time Not Used7 26 TS Observation Date/Time # Not Used8 26 TS Observation End Date/Time # Not Used9 20 CQ Collection Volume Not Used

10 250 XCN Collector Identifier Not Used11 1 ID Specimen Action Code Action Code12 250 CE Danger Code Not Used13 300 ST Relevant Clinical Information Prescription comment14 26 TS Specimen Received Date/Time Not Used15 300 CM Specimen Source Not Used16 250 XCN Ordering Provider Doctor17 250 XTN Order Callback Phone Number Not Used18 60 ST Placer Field 1 Not Used19 60 ST Placer Field 2 Not Used20 60 ST Filler Field 1 + Not Used21 60 ST Filler Field 2 + Not Used22 26 TS Results Rpt/Status Chng - Date/Time + Not Used23 40 CM Charge to Practice + Not Used24 10 ID Diagnostic Serv Sect ID Not Used25 1 ID Result Status + Not Used26 400 CM Parent Result + Not Used27 200 TQ Quantity/Timing Priority28 250 XCN Result Copies To Not Used29 200 CM Parent Not Used30 20 ID Transportation Mode Not Used31 250 CE Reason for Study Not Used32 200 CM Principal Result Interpreter + Not Used33 200 CM Assistant Result Interpreter + Not Used34 200 CM Technician + Not Used35 200 CM Transcriptionist + Not Used36 26 TS Scheduled Date/Time + Not Used37 4 NM Number of Sample Containers Not Used38 250 CE Transport Logistics of Collected Sample Not Used39 250 CE Collector’s Comment Not Used40 250 CE Transport Arrangement Responsibility Not Used41 30 ID Transport Arranged Not Used42 1 ID Escort Required Not Used43 250 CE Planned Patient Transport Comment Not Used44 250 CE Procedure Code Not Used45 250 CE Procedure Code Modifier Not Used46 250 CE Placer Supplemental Service Information Not Used47 250 CE Filler Supplemental Service Information Not Used

OBR - 2 Placer Order Number

Same as ORC-2 field. If this information is present in the ORC segment, then it is ignored in the OBR segment.

Page 22/26 V02.01 HL7: Order Reception CNXR011 / 3Confidential. This specification requires an end user agreement.

Page 23: HL7 Order Reception

Connection sheet

OBR - 3 Filler Order Number

Same as ORC-3 field. If this information is present in the ORC segment, then it is ignored in the OBR segment.

OBR - 4 Universal Service Identifier

The first subfield must contain the Host System text of the requested test. The requested test must be present in the replicated Tests Dictionary and must be defined as requestable separately.

OBR - 11 Specimen Action Code

On reception of the Test Order, the communication engine only processes the A (Added test), R (Revised Order) action codes.

OBR - 13 Relevant Clinical Info

The content of this field is stored in Clinical Details field (RCO) of the production database for the first OBR segment of the test order.

OBR - 16 Ordering Provider

The first sub-field contains the doctor code of the Prescriber (Dr1 on the production database).

OBR - 27 Quantity/Timing

The communication engine only processes the 6th subfield (priority). The values that are processed are: S (Stat), A (ASAP), R (Routine). Value P (preoperative) is processed as R. Value C (Call back) is processed as S. Value T (Timing Critical) is processed as S.

OBX - observation / result

SEQ LEN DT ELEMENT NAME On Communication Engine

1 4 SI Set ID – OBX Not Used2 2 ID Value Type Result type 3 250 CE Observation Identifier Test Code 4 20 ST Observation Sub-ID Not Used5 65536i * Observation Value Result Value6 250 CE Units Not Used7 60 ST Reference Range Not Used8 5 IS Abnormal Flags Not Used9 5 NM Probability Not Used

10 2 ID Nature of Abnormal Test Not Used11 1 ID Observation Result Status Not Used12 26 TS Date Last Observation Normal Value Not Used13 20 ST User Defined Access Checks Not Used14 26 TS Date/Time of the Observation Not Used15 250 CE Producer's ID Not Used16 250 XC

NResponsible Observer Not Used

17 250 CE Observation Method Not Used18 22 EI Equipment Instance Identifier Not Used19 26 TS Date/Time of the Analysis Not Used

i

CNXR011 / 3 HL7: Order Reception V02.01 Page 23/26Confidential. This specification requires an end user agreement.

Page 24: HL7 Order Reception

Connection sheet

OBX - 2 Value Type

Type of result. For additional parameter, the Communication Engine supports the following values: CE for Coded Text; DT for Date; NM for Numeric; TX for free text (limited to 2000 char.); and ST for String Data, SN for structured numeric.

Processing ‘ST’ String data result:String Data result is stored as "Limit" result type if the result is in the format <xxxx or >xxxx; it is stored as Alphabetical string if the result is no more than 4 characters long; it is stored as a free text in all other cases.

Processing ‘DT’ Date :Only the complete date is accepted by the connection (YYYYMMDD). The partial date is not integrated correctly.

Processing ‘NM’ Numeric :The decimal separator must be ‘.’.

Processing ‘SN’ Structured numeric :Structured Numeric result is stored as "Limit" result type if the result is in the format <^xxxx or >^xxxx and xxxx is numeric, else it is stored as a free text.

OBX - 3 Observation Identifier

The first subfield must contain the Host System text of the Additional Parameter.

OBX – 5 Observation Value

If the Value type is CE, the first subfield corresponds to the Mnemonic code of the coded text.

General constraints

The External Order Number is limited to 9 numeric characters. This number must be unique for a test order.The Full Access Number must be unique for a test order.

A HL7 test order message contains only a message and a test order.

If the specimen identification and collection are managed by the Host, the specimen numbering mechanism should be identical to the specimen numbering supported by the production database.

Only the first ORC segment of each order is processed. In every segment ORC External order number or/and Full Access Number is repeated as the first one.

The requested test (field OBR-4) must be a Single test or a Combined test. Profile cannot be used as they are just a facility for manual order entry and the code of a profile cannot be returned to the Host with the results.

If there is a need to transmit additional parameters for a requested test, each result of these additional parameters should be transmitted in dedicated OBX record that immediately follows the OBR segment of the requested test.

Page 24/26 V02.01 HL7: Order Reception CNXR011 / 3Confidential. This specification requires an end user agreement.

Page 25: HL7 Order Reception

Connection sheet

Examples of ORM messages

Simple test order :

MSH|^~\&|SSI|SI|LMX|TECHNIDATA|200305081258||ORM^O01|SI030000000000095401|P|2.04PID||261055502^^^106|ALTNUMBER1^^^N^CODFISC||MARTIN^Jean^^^^^L||19750421|M|||9 rue Marcel Cachin^^Meylan^^38100^FRANCE^L^||604582||||||261055501ORC|NW|^050901^019201^L|9000000032^050901^003900^L||||||200305081258|||ALBM|BDR|OBR|1|^050901^019201^L|9000000032^050901^003900^L|ADEN2^^L|||20030508|||||||||019201ORC|NW|^050901^019201^L|9000000032^050901^003900^L||||||200305081258|||ALBM|BDR|OBR|2|^050901^019201^L|9000000032^050901^003900^L|ACTDI^^L|||20030508|||||||||019201

Test order with urgent test and full access number :

MSH|^~\&|SSI|SI|LIS|TECHNIDATA|200305081258||ORM^O01|SI030000000000095400|P|2.04PID||98700021^^^106|98900021^^^L^ASSIPCA~98600021^^^N^CODFISC~98700021^^^060^CODSAN||DUPOND^Jean^^^^^L~Fleurus^^^^^^M||19850724|M||2056-5^Blanc|9 rue Marcel Cachin^^Meylan^^38100^FRANCE^L^||0476001122^^PH~0600112233^^[email protected]^^Internet||||||261055501PV1|1||MEDIR^2^Lit19^^^^^^|||||CLAD^Maraul2^Doc|||||||||||20020001|~~~||||||||||||||||||||||||20030709||||||954||NTE|||Patient commentORC|NW|^050901^019201^L|4021200009^050901^003900^L||||||200305081258|||ALBM|BDR|OBR|1|^050901^019201^L|4021200009^050901^003900^L|ADEN2^^L|||20030508|||||||||019201|||||||||||^^^^^A|ORC|NW|^050901^019201^L|4021200009^050901^003900^L||||||200305081258|||ALBM|BDR|OBR|2|^050901^019201^L|4021200009^050901^003900^L|ACTDI^^L|||20030508|||||||||019201|

Test order with external order number and complementary parameter :

MSH|^~\&|SSI|SI|LMX|TECHNIDATA|200305081258||ORM^O01|SI030000000000095401|P|2.04PID||261055502^^^106|ALTNUMBER1^^^N^CODFISC||MARTIN^Jean^^^^^L||19750421|M|||10 rue du Générale^^Meylan^^38100^FRANCE^L^||604582||||||261055501ORC|NW|HOSTNUM1^050901^019201^L|^050901^003900^L||||||200305081258|||ALBM|BDR|OBR|1| HOSTNUM1^050901^019201^L|^050901^003900^L|ADEN2^^L|||20030508|||||||||019201ORC|NW|HOSTNUM1^050901^019201^L|^050901^003900^L||||||200305081258|||ALBM|BDR|OBR|2| HOSTNUM1^050901^019201^L|^050901^003900^L|ACTDI^^L|||20030508|||||||||019201ORC|NW|HOSTNUM1^050901^019201^L|^050901^003900^L||||||200305081258|||ALBM|BDR|OBR|3| HOSTNUM1^050901^019201^L|^050901^003900^L|NUM^^L|||20030508|||||||||019201|OBX||DT|PDAT^Date||20040101|OBX||TX|PFT^Free texte||Free texte|OBX||CE|PCT^Coded texte||POS|

CNXR011 / 3 HL7: Order Reception V02.01 Page 25/26Confidential. This specification requires an end user agreement.

Page 26: HL7 Order Reception

END USER AGREEMENT FOR CONNECTION

The interface specification described in the attached Connection Sheet # CNXR011 "HL7: Order Reception" is confidential and is strictly reserved for communication with a Hospital Information System. An End User Agreement containing the text hereunder must be agreed by the Customer (End User). The interface specification "Connection Sheet # CNXR011" is for the exclusive use of sites covered by an End User Agreement. Use of the interface specification "Connection Sheet # CNXR011" implies full acceptance of the terms and conditions of the End User Agreement hereunder.

END USER AGREEMENT FOR CONNECTION SHEET # CNXR011

PLEASE READ THIS AGREEMENT CAREFULLY.THE USE OF THE INTERFACE SPECIFICATION SHALL IMPLY ACCEPTANCE OF THIS AGREEMENT.

IF YOU DO NOT AGREE, YOU MUST NOT USE THE INTERFACE SPECIFICATION.

OWNERSHIP

TECHNIDATA shall retain all titles and intellectual property rights of the attached interface specification. The interface specification is protected under international laws related to intellectual property rights.

The Customer agrees that it does not have any title or ownership on the attached interface specification.

USE

The Customer may use the Interface Specification, provided that the product license has been properly acquired.

The Customer shall only use the Interface Specification for his own needs.

The Customer shall only use the Interface Specification for the purpose of communication with a Hospital Information System. Consequently, Customer is not authorized, in any way, to use the Interface Specification for any other type of communication or for any other purpose.

The Customer shall not use any portion of the said Interface Specification for the purpose of interfacing or creating new software programs to be made available to any third party, either free of charge or for pecuniary benefit.

The Customer shall not disclose, communicate or use for the benefit of any third party any portion of the said Interface Specification.

The Customer must be aware that the Interface Specification is likely to evolve. The Customer therefore agrees that any software that relies on this Interface Specification may require to be updated to maintain existing functionality.

Upon termination of this Agreement, the Customer shall return all materials which contain information related to the Interface Specification, including written notes, photographs, memoranda or notes taken.

Page 26/26 V02.01 HL7: Order Reception CNXR011 / 3Confidential. This specification requires an end user agreement.