Connection sheet

Sheet #

Connection name

Rev #

Version

19

HL7: Transmission of results (from Histology/Cytology module)

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 5 References 5
Program 5 identification

pre-requisites

Presentation 6
Principle 6 Communication 6 of the connection diagram

Communication 7
Transmission 7 Data 8 Information 10

layers:

TCP/IP

socket
diagram

block exchange

structure description

Installation 11 Implementation 11
Labconf 11 TDNTServer 11 Device 11 Specialty 14 Histology/Cytology 14 Activation 15

procedure of the connection

parameters auto number dictionary codes module of the connection dictionary parameters service

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 1/30

Connection sheet

Relevant 16

HL7

messages,

segment
of

types

and

fields
messages

Structure 16

Segments 17

description

MSH Message header segment 17 MSH 1 and MSH - 2 Field Separator / Encoding Characters 17 MSH 3 Sending Application 17 MSH 5 Receiving Application 17 MSH 7 Date Time of message 17 MSH 9 Message Type 17 MSH 10 Message Control ID 17 MSH 11 Processing ID 18 MSH 12 Version ID 18 PID Patient identifying segment 18 PID-5 Patient Name 19 PID 6 Mothers Maiden Name 19 PID 7 Patient birthdate 19 PID 8 Patient sex 20 * Not used in case of transmission of Histology/Cytology results. 20 PID 10 Patient race 20 PID 11 Patient address 20 PID 13 Patient phone numbers (Home) 20 PID 17 Patient religion 21 PV1 Patient visit information 21 PV1 2 Patient class 22 PV1 3 Assigned Patient Location 22 PV1 7 Attending doctor 22 PV1 8 Referring doctor 22 PV1 10 Hospital Service 22 PV1 16 VIP Indicator 22 PV1 17 Admitting doctor 22 CNXR019 / 0 V02.01
Confidential. This specification requires an end user agreement

Page 2/30

Connection sheet

PV1 22 PV1 22 PV1 22 PV1 22 ORC 23 ORC 23 ORC 23 ORC 23 ORC 23 ORC 23 ORC 24 ORC 24 ORC 24 OBR 24 OBR 25 OBR 25 OBR 25 OBR 25 OBR 25 OBR 25 OBR 25 OBR 25 OBR 25 OBR 25 OBR 26 OBX 26 OBX 26 OBX 26 OBX 26 OBX 26 OBX 26 CNXR019 / 0

14 24 3 4 5 32 25 11 4 2 3 15 3 2

19 20 44 45 Common 1 Placer Filler 5 7 12 13 Order Observation Placer Filler Universal 10 Specimen Received

Visit Financial Admit Discharge order Order Order Order Order Number

number class date/time date/time segment Control Number

Status Quantity/Timing

Ordering Enterers Effective request Order Order Service Collector Action Date /

Provider Location Date/Time segment Number Number Identifier identifier Code Time Provider Status + ID

Specimen 16

Ordering Result

Diagnostic 27 Principal Observation 2

Serv

Sect

Quantity/Timing Result / Value Observation Observation Observation 6 Interpreter + result Type Identifier Sub-ID Value Units Page 3/30

V02.01
Confidential. This specification requires an end user agreement

Connection sheet

OBX 26 OBX 27 OBX 27

11

6 8 Observation

Reference Abnormal Result

range flags Status

Example 27 Troubleshooting 28
Error 28

of

ORU

message

management

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 4/30

Connection sheet

History of document modifications

Related Version/ Revision V02.01 / 0 Short description of the modification Creation of the connection sheet.

Technical pre-requisites
The connection must be installed on a computer connected to the network 24 hours a day/7 days a week (computer on which the connection service is installed). 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 web site (www.technidata-web.com). To know the minimal Product configurations required to run this connection (Management database, Production database, Data model), refer to the Technical guide, Connection sheets, External system connection topic.

References
Reference number of HL7 standard (High Level Protocol): Date of this standard : Reference number of HL7 standard (Low Level Protocol) Date of this standard : High Level protocol HL7 2.4 Chapter 4 Order Entry November 2000 Low Level protocol HL7 2.3 Appendix C Lower Layer Protocols June 1998

Program identification
Protocol DLL: Format DLL: Transport DLL: TDCnxProtoHISADT.dll (HL7 Low Layer Protocol (Socket)) TDCnxFormHL7.dll (HL7 Format Patients / Orders / Results) TDCnxTransTCPIPSocket.dll (TCP-IP socket transport)

Application DLL: TDCnxAppResult.dll (Orders/Results transmission)

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 5/30

Connection sheet

Presentation Principle of the connection

The purpose of this connection is to send patient results to a Host (Correspondent defined with Regular electronic interchange in the Location dictionary) as soon as the request is validated and printed.

Communication diagram
Not available Required conditions to create a connection task: - the request must be "Validated and Printed" (VR status on the Histology/Cytology module) - the concerned Correspondent(s) must be defined in the Location dictionary with the Regular electronic interchange parameter set to the device code of the connection. 1) When the above conditions are satisfied, a connection task is automatically created in the Task Manager window and a notification is sent to the Communication engine. 2) The Communication engine queries the Task Manager if there is any task to perform. 3) The Communication engine processes the task. The task processing consists in formatting messages and transmitting them to the correspondent of the request through the HL7 socket transfer mode.

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 6/30

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 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. <SB>tvv<CR>ddddcccccxxx<EB><CR> "dddd" contains the different HL7 messages composing the logical acknowledgement (MSH, MSA and ERR segments).

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

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 server with a physical NAK message embedded into it (character 'C')

Data block sent by the client with an HL7 message embedded. On the physical integrity control, a wrong block format has been detected. A special data block is sent (NAK block). <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 server with a HL7 ACK message embedded into it

<

Data block sent by the client with an HL7 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. <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

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 7/30

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. Hybrid HL7 Low Layer Protocol There are two types of blocks: data blocks and NAK blocks. HL7 messages are transmitted in single data block. 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 to the one configured as "Start of block character" in the Device dictionary. Block Type (1 byte). "D" = Data block "N" = NAK block Protocol ID (2 bytes). Characters "23 " for this version. Carriage Return (1 byte). The ASCII carriage return character, i.e. <0x0D>. 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.

t=

vv = <CR> = dddd =

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 8/30

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". 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. Carriage Return (1 byte). The ASCII carriage return character, i.e., <0x0D>. 2. Minimal HL7 Low Layer Protocol

<EB> =

<CR> =

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. 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.

<CR> =

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 9/30

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 one 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 client and the Host system as the server. Pre-requisites and sequence of operations In order that the TCP/IP socket low-level protocol can 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 Client transmission mode. 4. Then you can start your server (Host) and Communication engine
5. 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 stopped, the client disconnects. Incidents generated on the socket management * If any exception occurs while reading from the socket, the next error is generated: Couldn't receive data through socket!

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 10/30

Connection sheet

Installation procedure
The Communication engine must be installed with a Client instance. When the connection selection screen is displayed: 1. Select HL7: Transmission of results by left-clicking on the related line. 2. Choose This feature will be installed on local hard drive option.

Implementation of the connection

To implement this connection, a number of parameter settings must be performed at different levels, as listed hereafter: - Labconf parameters - TDNTServer auto number - Device dictionary - Specialties codes dictionary - Histology/Cytology module parameters - Activation of the service specified in the Device dictionary

Labconf parameters
You must verify some "Labconf" parameters on the Management database (General parameters) before starting the implementation. These parameters are: - Patient number length - Alternate patient number length - Hospitalization number length

TDNTServer auto number

You have to define an auto number used for the Message control ID parameter (MSH) It is necessary to define a counter with option: - Minimum value : 1 - Maximum value : 9999999999 - Initialization periodicity : Automatic

Device dictionary
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 , then General dictionaries then Device. In the menu bar, click on the + sign.

The following definition of the connection in the Device dictionary is given as an example. The parameters appearing in bold are mandatory. Name Code Device type CNXR019 / 0 Value HL7_HOST (this is an example) Connection V02.01
Confidential. This specification requires an end user agreement

comment

Page 11/30

Connection sheet

Service Name Abbreviated text Full text Protocol Format Transport Application Properties

TDCnx_InstanceName_Computername

Name of the computer where is installed the service

HL7 Low Layer Protocol (Socket) HL7 Format Patients/Orders/Results TCP-IP socket transport Orders/Results transmission

The Protocol, Format, Transport 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 to define the parameters related to a type of flow. Several types of flow must be defined: 1. All (displayed by default). 2. Patient demographics sending 3. Result sending

1. Type of flow: All

Device properties HL7_HOST Type of flow All Name
General Interval before job purging (days)

Value If this parameter is not defined here, the same parameter defined in the Site configuration window is applied.
3*

Comment

Message control ID Number of retries Spy file maximal size Spy file path Spy file trace level Spy traces enabled

1024
C:\TECHNIDATA\spy.txt Maximum / regular / minimum Yes/No

To modify on site. Once the installation is finished and you checked it runs well, set it to No. HL7 version (could be modified if needed in 2.3 or 2.5 values)

Format HL7 Version Message recipient code Message sender code Unicode messaging Transport Checksum type

2.4 HOST TDR No

End of block character

Listening port Outgoing port Protocol version

Checksum applied on the socket frame. None as default value. Last character of the socket (<1C> in the definition of the socket frame). Input port. Default value: 8000. Output port Default value: 8001.
23

Must be set to HL7 Low Layer Protocol Do not modify. To modify on site. To modify on site. Protocol version filled into socket frame, to be modified only if needed

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 12/30

Connection sheet

Recipient network address

Sender network address

Start of block character

IP address or logical name of the receiver Value: localhost IP address or logical name of the sender. Value: localhost First character of the socket (<0B> in the definition of the socket frame).
Hybrid/Minimal

To modify on site. To modify on site. Do not modify. To modify on site. Must be set to Client transmission mode

TCP-IP layer protocol Transmission mode

Defines the mode used by the socket connection (client/server, Mono/Multi client). Default value: Unknown transmission mode. Name of the directory where is stored the "hl7.vmd" Chameleon file.
C:\TECHNIDATA

File location Chameleon file path

To modify on site. Name of the directory where trace files of sent data are stored if spy trace is set to Maximum.

Processed folder

If the patient record is locked (protected) when the connection tries to write information in the database or when a NAK is received, the connection tries several times to access the database. The number of attempts is set in the parameter Number of retries in the database. The connection waits 2 seconds between each attempt. If the number of attempts has been reached, an error handling routine is executed. A message is logged as an
error in the event viewer.

2. Type of flow: Patient demography sending

Device properties Type of flow: Patient demography sending Name Value
General

Comment

The General section defines how is managed the patient data sent in the HL7 message: Name Stream active
Alternate patients number length Hospitalization number length Patients number length

Value Default value: No.

Comment Must be set to Yes.

Prefix of beneficiary number on the Host Prefix of hospitalization number on the Host Prefix of patient number on the Host

Prefix applied to the beneficiary identification, e.g. BEN. Prefix applied to the hospitalization identification, e.g. HOS. Prefix applied to the patient identification, e.g. PAT.

The use of a prefix is optional. A prefix can be applied to the patient identification (Beneficiary, Hospitalization or Patient number) sent in the HL7 message in order to specify the sending Host. These parameters must be empty if the patient identification sent in the HL7 messages must not be modified.

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 13/30

Connection sheet

Name Mapping Doctors Locations Titles Patient class

Value Code of the coding system used to map doctor codes. (1). Code of the coding system used to map location codes. (1). Code of the coding system used to map title codes. (1). Code of the Patient class provided by the HIS in the ORU message and automatically recovered. (2) Code of the Financial class provided by the HIS in the ORU message and automatically recovered. (2) Code of the Hospital Service provided by the HIS in the ORU message and automatically recovered. (2)

Comment Create/select the code of a coding system. Create/select the code of a coding system. Create/select the code of a coding system. Select "Autocreate" to have the patient class field automatically fed by the communication process.(3) Select "Autocreate" to have the financial class field automatically fed by the communication process.(3) Select "Autocreate" to have the hospital service class field automatically fed by the communication process.(3)

Financial class

Hospital Service

(1) Mapping is used to create correspondences between the Management database and Host systems code values (local codes and alternate codes). (2) Up to now, no coding system is available and there is no user interface for those dictionaries. Only automatic creation is available. (3) The elements of the dictionaries are not updated when the latter are modified. Only the creation of new items are taken into account.

3. Type of flow: Result sending

No properties must be set but this flow must be set to "enabled" (Stream active: Yes).

Specialty codes dictionary

Define a name for the combined test in the Tests for connection section. This name is used in the OBX as the test code (e.g.: HISTO).

Histology/Cytology module parameters

Make sure that Edit validated report is checked.

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 14/30

Connection sheet

Activation of the connection service

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

Addressing Connection service

There is a possible dynamic allocation of communication port address when Connection service is started (search for an available address on the concerned computer). It uses the first port available, starting at 8000. You can modify the way it works: - A list of excluded ports, by computer can be used. It must be setup in the registry as in the following example:

You can also specify the port to be used by the service: In regedit, go to HKLM\SYSTEM\CurrentControlSet\Services\<Service name>-<instance name> Then modify the value of Image path, adding the port number at the end of the line. Example: c:\technidata\TDRClient-Appli1\servcnx.exe TDCnx1 8011

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 15/30

Connection sheet

Relevant HL7 messages, segment types and fields

The transmitted file (one file by patient) is composed of the following segments:

Segment MSH : identifies the communication (Sender / Receiver). Segment PID: identifies the patient. Segment PV1: identifies the patient visit. Segment ORC: identifies the order control. Segment OBR: contains data related to the test request such as: Access number, Prescriber code Segment OBX: contains data related to results.

The message can contain NTE segments. The NTE segment can be placed at any level of the hierarchy, it is comment data related to the previous segment.

Structure of messages
Structure of ORU message:
ORU^R01
MSH { [ PID [{NTE}] [PV1 ] { [ORC] OBR {[NTE]} { [OBX] {[NTE]} } } }

Observational Results (Unsolicited)

Message Header Patient Identification Notes and Comments Patient Visit Order common Observations Report ID Notes and comments Observation/Result Notes and comments

ACK^R01
MSH MSA

Acknowledgment
Message header Message acknowledgment

Each HL7 file contains only one MSH segment.

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 16/30

Connection sheet

Segments description MSH Message header segment

SEQ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 LEN 1 4 180 180 180 180 26 40 13 20 3 60 15 180 2 2 3 16 250 20 10 DT ST ST HD HD HD HD TS ST CM ST PT VID NM ST ID ID ID ID CE ID ID FIELD NAME Field Separator Encoding Characters Sending Application Sending Facility Receiving Application Receiving Facility Date/Time Of Message Security Message Type Message Control ID Processing ID Version ID Sequence Number Continuation Pointer Accept Acknowledgment Type Application Acknowledgment Type Country Code Character Set Principal Language Of Message Alternate Character Set Handling Scheme Conformance Statement ID On Communication Engine Used to process HL7 message Used to process HL7 message Message sender identification Not Used Message recipient identification Not Used Current date time Not Used ORU^R01 TDNT Server counter P HL7 version Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used

Example: MSH|^~\&|TD||HOST||200305081258||ORU^O01|TD0000000001|P|2.3 MSH 1 and MSH - 2 Field Separator / Encoding Characters Defines 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 Application Corresponds to the parameter Message sender identification. By default the value is TDR. MSH - 5 Receiving Application Corresponds to the parameter Message recipient identification. By default the value is HOST. MSH - 7 Date Time of message The current date and time when the message is processed. MSH - 9 Message Type The value is ORU^R01. MSH 10 Message Control ID Value of the counter corresponding to the parameter: Message control ID. CNXR019 / 0 V02.01
Confidential. This specification requires an end user agreement

Page 17/30

Connection sheet

The value is formatted on 10 digits with the prefix TD. For example: TD0000000001. For this parameter, it is necessary to define a counter on TDNTServer (Tools/Autonumbers) with the following options : - Minimum value : 1 - Maximum value : 9999999999 - Initialization periodicity : Automatic MSH 11 Processing ID P corresponds to a production message. MSH 12 Version ID This field contains the value of HL7 version parameter. The protocol version supported by this connection is HL7 V2.3.

PID Patient identifying segment

SEQ 1 2 3 4 5 6 7 8 9 10 11 LEN 4 20 250 20 250 250 26 1 250 250 250 DT SI CX CX CX XPN XPN TS IS XPN CE XAD FIELD NAME Set ID - PID Patient ID Patient Identifier List Alternate Patient ID - PID Patient Name Mothers Maiden Name Date/Time of Birth Sex Patient Alias Race Patient Address On Communication Engine Not Used Not Used Patient Number or Alternate Patient Number Not Used Patient name Name First Name Maiden Name Patient birth date Patient sex Not Used Patient race Address 1st line Address 2nd line City State Province Postal code Country Not Used Telephone number Telephone number 2 Fax Email address Not Used Not Used Not Used Religion Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Page 18/30

12 13

4 250

IS XTN

Country Code Phone Number - Home

14 15 16 17 18 19 20 21 22 23 24 25 26 27 CNXR019 / 0

250 250 250 250 250 16 25 250 250 250 1 2 250 250

XTN CE CE CE CX ST DLN CX CE ST ID NM CE CE

Phone Number - Business Primary Language Marital Status Religion Patient Account Number SSN Number - Patient Driver's License Number - Patient Mother's Identifier Ethnic Group Birth Place Multiple Birth Indicator Birth Order Citizenship Veterans Military Status V02.01

Confidential. This specification requires an end user agreement

Connection sheet

SEQ 28 29 30

LEN 250 26 1

DT CE TS ID

FIELD NAME Nationality Patient Death Date and Time Patient Death Indicator

On Communication Engine Not Used Not Used Not Used

In the following items, the bold data are managed by the connection. PID-3 Patient Identifier List Components: <ID (ST)> ^ <check digit (ST)> ^ <code identifying the check digit scheme employed (ID)> ^ < assigning authority (HD)> ^ <identifier type code (ID)> ^ < assigning facility (HD) ^ <effective date (DT)> ^ <expiration date (DT)> Subcomponents of assigning authority: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)> Subcomponents of assigning facility: <namespace ID (IS)> & <universal ID (ST)> & <universal ID type (ID)> This field contains all patient identifications. It is repeatable and each element contains one identification. Each identification is identified by a user-defined type code:
Example 1245789632^^^^PATNUMBER~000BENNUM1^^^^ALTNUMBER PATNUMBER, ALTNUMBER identify each identification type. 1245789632, 000BENNUM1 are the identification ID for each identification.

Only two patient identifications are available: the Patient number or the Alternate number. On Chameleon, there is an association between the Host user-defined patient identification codes and the two patient identifications. This association can be changed by the FSE during the connection installation using python scripting in the chameleon PatientID table. PID-5 Patient Name Components: <family name (FN)> ^ <given name (ST)> ^ <second and further given names or initials thereof (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (IS)> ^ <name type code (ID) > ^ <name representation code (ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ <name assembly order (ID)> Subcomponents of family name: <family name (ST)> & <own family name prefix (ST)> & <own family name (ST)> & <family name prefix from partner/spouse (ST)> & <family name from partner/spouse (ST)> This field contains all patient names. It is repeatable and each element contains one name. Each name is identified by a type code:
Example NAME^FIRST NAME^^^^^L~OTHER NAME^^^^^^T L or T identify each name type. NAME, FIRSTNAME and OTHER NAME are the string for each name.

Different levels of names are available: Patient Name, First name... On Chameleon, there is an association between the Host patient name type codes and the two patient names. This association can be changed by the Field Service Engineer during the connection installation using python scripting in the chameleon Names table : PID - 6 Mothers Maiden Name This field is managed as the Maiden name by the connection. PID - 7 Patient birthdate This field is managed as the patient birthdate by the connection.

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 19/30

Connection sheet

PID - 8 Patient sex This field is managed as the patient sex by the connection. Value F M O U A N Description Female Male Other* Unknown Ambiguous* Not applicable* * Not used in case of transmission of Histology/Cytology results. PID - 10 Patient race This field is managed as the patient ethnic origin by the connection. PID - 11 Patient address Components: <street address (ST)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^ < address type (ID)> ^ <other geographic designation (ST)> ^ <county/parish code (IS)> ^ <census tract (IS)> ^ <address representation code (ID)> ^ <address validity range (DR)> The Patient address is managed on the Management database and the Address type = L (Legal address). Data Address 1st line Address 2nt line City State Province Postal code Country Field used <street address (ST)> <other designation (ST)> <city (ST)> <state or province (ST)> <zip or postal code (ST)> <country (ID)>

PID - 13 Patient phone numbers (Home) Components: [NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication use code (ID)> ^ <telecommunication equipment type (ID)> ^ <e-mail address (ST)> ^ <country code (NM)> ^ <area/city code (NM)> ^ <phone number (NM)> ^ <extension (NM)> ^ <any text (ST)> This field contains all patient phones. This field is repeatable and each element contains one telephone number. Each telephone number is identified by a phone type code : Telephon 1, Telephon 2, Fax and Email address. In Chameleon, there is an association between the Host phone type codes and the phones on the Management database. This association can be changed by the FSE during the connection installation using python scripting in the chameleon Telephone table. Data Telephone Telephone 2 Fax Email address Telecommunication equipment type (ID) PH (Telephone) CP (Cellular phone) FX (Fax) Internet (Internet address)

In the case of a transmission of Histology/Cytology result, Telephone 2 and Email address is empty.

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 20/30

Connection sheet

PID - 17 Patient religion This field is managed as the patient religion code by the connection In the case of a transmission of Histology/Cytology result, Patient religion is not used.

PV1 Patient visit information

SEQ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 CNXR019 / 0 LEN 4 1 80 2 250 80 250 250 250 3 80 2 2 6 2 2 250 2 250 50 2 2 2 2 8 12 3 2 1 8 10 12 12 1 8 3 25 250 2 1 2 80 80 26 26 12 12 12 DT SI IS PL IS CX PL XCN XCN XCN IS PL IS IS IS IS IS XCN IS CX FC IS IS IS IS DT NM NM IS IS DT IS NM NM IS DT IS CM CE IS IS IS PL PL TS TS NM NM NM ELEMENT NAME Set ID - PV1 Patient Class Assigned Patient Location Admission Type Preadmit Number Prior Patient Location Attending Doctor Referring Doctor Consulting Doctor Hospital Service Temporary Location Preadmit Test Indicator Re-admission Indicator Admit Source Ambulatory Status VIP Indicator Admitting Doctor Patient Type Visit Number Financial Class Charge Price Indicator Courtesy Code Credit Rating Contract Code Contract Effective Date Contract Amount Contract Period Interest Code Transfer to Bad Debt Code Transfer to Bad Debt Date Bad Debt Agency Code Bad Debt Transfer Amount Bad Debt Recovery Amount Delete Account Indicator Delete Account Date Discharge Disposition Discharged to Location Diet Type Servicing Facility Bed Status Account Status Pending Location Prior Temporary Location Admit Date/Time Discharge Date/Time Current Patient Balance Total Charges Total Adjustments V02.01
Confidential. This specification requires an end user agreement

On Communication Engine Not Used Patient class code (*) Location (*) Not Used Not Used Not Used Attending doctor code (*) Reference doctor code (*) Not Used Hospital service code (*) Not Used Not Used Not Used Not Used Not Used VIP or Confidential indicator (*) Admitting doctor code (*) Not Used Stay Number Financial class code and effective date (*) Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Admission Date Time Discharge Date Time Not Used Not Used Not Used Page 21/30

Connection sheet

SEQ 49 50 51 52

LEN 12 250 1 250

DT NM CX IS XCN

ELEMENT NAME Total Payments Alternate Visit ID Visit Indicator Other Healthcare Provider

On Communication Engine Not Used Not Used Not Used Not Used

(*) Information available only with HL7 ADT connection (Communication Engine). PV1 - 2 Patient class This field is managed as the Stay patient class by the connection. PV1 - 3 Assigned Patient Location This field is managed as the Stay location by the connection. PV1 - 7 Attending doctor This field is managed as the Stay attending doctor by the connection. PV1 - 8 Referring doctor This field is managed as the Stay referring doctor and Patient reference doctor by the connection. PV1 - 10 Hospital Service This field is managed as the Stay hospital service (Medical discipline) by the connection. PV1 - 16 VIP Indicator This field is managed as the Patient VIP by the connection. It is possible to manage it as confidential indicator, this modification can be changed by the FSE during the connection installation using mapping of chameleon on the Patient table. In Chameleon, there is an association between the different value of the Management database Patient VIP (Yes or No) and HL7 code. This association can be changed by the FSE during the connection installation using python scripting in the chameleon Patient table. Data (VIP) 1 (yes) 0,null (no) PV1-16 VIP Indicator Yes No

PV1 - 17 Admitting doctor This field is managed as the Stay admitting doctor by the connection PV1 - 19 Visit number This field is managed as the Stay number by the connection. PV1 - 20 Financial class This field is managed as the Financial class and effective date by the connection. Components: <financial class (IS)> ^ <effective date (TS)> PV1 - 44 Admit date/time This field is managed as the Admit Date / Time of the stay by the connection. PV1 - 45 Discharge date/time This field is managed as the Discharge Date / Time of the stay by the connection.

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 22/30

Connection sheet

ORC Common order segment

SEQ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 LEN 2 22 22 22 2 1 200 200 26 250 250 250 80 250 26 250 250 250 250 250 250 250 250 250 DT ID EI EI EI ID ID TQ CM TS XCN XCN XCN PL XTN TS CE CE CE XCN CE XON XAD XTN XAD ELEMENT NAME Order Control Placer Order Number Filler Order Number Placer Group Number Order Status Response Flag Quantity/Timing Parent Date/Time of Transaction Entered By Verified By Ordering Provider Enterers Location Call Back Phone Number Order Effective Date/Time Order Control Code Reason Entering Organization Entering Device Action By Advanced Beneficiary Notice Code Ordering Facility Name Ordering Facility Address Ordering Facility Phone Number Ordering Provider Address On Communication Engine Order control Host order number Full Access Number Not Used Status Not Used Priority Not Used Date/Time of Transaction Not Used Not Used Prescriber Code Location Code Not used Collection date and time Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used

ORC - 1 Order Control This field contains NW for a new reporting request. ORC - 2 Placer Order Number This field contains the "External Order Number" (Host order number). Not used for Histology/Cytology result transmission. ORC - 3 Filler Order Number This field contains the "Full Access Number". In the case of a Histology/Cytology transmission, this field contains the requests full access number. ORC - 5 Order Status In the case of a Histology/Cytology transmission, this field contains for each transmission CM : Order is completed. ORC - 7 Quantity/Timing This field contains the priority of the request. Data Immediate Urgent Routine HL7 Priority code S (Stat With highest priority) A (Asap) R (Routine)

Only R and A are used by Histology/Cytology result transmission.

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 23/30

Connection sheet

Components: <quantity (CQ)> ^ <interval (CM)> ^ <duration (ST)> ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <priority (ST)> ^ <condition (ST)> ^ <text (TX)> ^ <conjunction (ST)> ^ <order sequencing (CM)> ^ <occurrence duration (CE)> ^ <total occurrences (NM)> ORC - 12 Ordering Provider The first subfield contains the doctor code of the Prescriber (Dr1 in Production database). This field should be identical to the OBR 16 field. ORC - 13 Enterers Location The first subfield contains the location code of the requesting Location (CR in Production database). ORC - 15 Order Effective Date/Time This field contains the collection date and time of the request.

OBR Observation request segment

SEQ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 LEN 4 22 22 250 2 26 26 26 20 250 1 250 300 26 300 250 250 60 60 60 60 26 40 10 1 400 200 250 200 20 250 200 200 200 200 26 4 250 DT SI EI EI CE ID TS TS TS CQ XCN ID CE ST TS CM XCN XTN ST ST ST ST TS CM ID ID CM TQ XCN CM ID CE CM CM CM CM TS NM CE ELEMENT NAME Set ID - OBR Placer Order Number Filler Order Number Universal Service Identifier Priority - OBR Requested Date/Time Observation Date/Time # Observation End Date/Time # Collection Volume Collector Identifier Specimen Action Code Danger Code Relevant Clinical Information Specimen Received Date/Time Specimen Source Ordering Provider Order Callback Phone Number Placer Field 1 Placer Field 2 Filler Field 1 + Filler Field 2 + Results Rpt/Status Chng Date/Time + Charge to Practice + Diagnostic Serv Sect ID Result Status + Parent Result + Quantity/Timing Result Copies To Parent Transportation Mode Reason for Study Principal Result Interpreter + Assistant Result Interpreter + Technician + Transcriptionist + Scheduled Date/Time + Number of Sample Containers Transport Logistics of Collected V02.01
Confidential. This specification requires an end user agreement

On Communication Engine Not Used Host order number Full Access Number Test Code and Test Abbreviated text Not Used Not Used Not Used Not Used Not Used Collector code Action code Not Used Not Used Specimen received date Not Used Prescriber code Not Used Not Used Not Used Not Used Not Used Not Used Not Used Specialty code Status Not Used Collection data and time / Priority Not Used Not Used Not Used Not Used Person who validate Not Used Not Used Not Used Not Used Not Used Not Used Page 24/30

CNXR019 / 0

Connection sheet

SEQ 39 40 41 42 43 44 45

LEN 250 250 30 1 250 250 250

DT CE CE ID ID CE CE CE

ELEMENT NAME Sample Collectors Comment Transport Arrangement Responsibility Transport Arranged Escort Required Planned Patient Transport Comment Procedure Code Procedure Code Modifier

On Communication Engine Not Used Not Used Not Used Not Used Not Used Not Used Not Used

OBR - 2 Placer Order Number Same as ORC-2 field. External order number is duplicated in this field. Not used for Histology/Cytology result transmission. OBR - 3 Filler Order Number Same as ORC-3 field. Full Access Number is duplicated in this field. OBR - 4 Universal Service Identifier The first subfield contains the mnemonic code and the second subfield contains the abbreviated text of the test. In the case of a transmission of:Histology/Cytology results - The mnemonic test code corresponds to the specialty dictionary parameter Combined test in Test for connection rubric. If complementary report is used, the test code is suffixed by _1 and for next _2 - The second field is empty. OBR - 10 Collector identifier The first subfield contains collector code. OBR - 11 Specimen Action Code TDR only manages the A (Added test), R (Revised Order) action codes. OBR - 14 Specimen Received Date / Time Date of the specimen reception in the laboratory. OBR - 16 Ordering Provider The first subfield contains doctor code of the Prescriber (Dr1 in Production database). OBR - 25 Result Status + In the case of a Histology/Cytology result transmission, only F status is processed. OBR - 24 Diagnostic Serv Sect ID In the case of a Histology/Cytology result transmission, this field contains the specialty code. OBR - 27 Quantity/Timing The 4 subfield contains the collection date. The 6th subfield contains the priority.
th

Data on Mgt database Immediate Urgent Routine

HL7 Priority code S (Stat With highest priority) A (Asap) R (Routine)

Only R and A are used by Histology/Cytology result transmission. CNXR019 / 0 V02.01

Confidential. This specification requires an end user agreement

Page 25/30

Connection sheet

OBR - 32 Principal Result Interpreter + Contains validation initials in subfield 1. Components: <name (CN)<ID number>> > ^ <start date/time (TS)> ^ <end date/time (TS)> ^ <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)> ^ <location status (IS)> ^ <patient location type (IS)> ^ <building (IS)> ^ <floor (IS)>

OBX Observation / result

SEQ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 LEN 4 2 250 20 65536 250 60 5 5 2 1 26 20 26 250 250 250 22 26 DT SI ID CE ST * CE ST IS NM ID ID TS ST TS CE XC N CE EI TS ELEMENT NAME Set ID OBX Value Type Observation Identifier Observation Sub-ID Observation Value Units Reference Range Abnormal Flags Probability Nature of Abnormal Test Observation Result Status Date Last Observation Normal Value User Defined Access Checks Date/Time of the Observation Producer's ID Responsible Observer Observation Method Equipment Instance Identifier Date/Time of the Analysis On Communication Engine Not Used Result type Test code and abbreviated text Used in case of long result Result Value Units Range Abnormal Flags Not Used Not Used Status Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used

OBX - 2 Value Type In the case of a Histology/Cytology result transmission, the result is a free text, then the value type is TX. OBX - 3 Observation Identifier The first subfield contains the mnemonic code and the second subfield contains the abbreviated text of test. In the case of a Histology/Cytology result transmission: - The mnemonic test code corresponds to the specialty dictionary parameter: Combined test in Test for connection rubric. - The second field is empty. OBX 4 Observation Sub-ID The result value is limited by HL7 to 65535 char. If the text result is too long, an other OBX segment is generated to complete the result. The first segment OBX have OBX-4 =1 the second have OBX-4 =2 OBX 5 Observation Value In the case of a Histology/Cytology result transmission, this field contains the report (text format). OBX 6 Units Not used for Histology/Cytology result transmission. OBX 6 Reference range Not used for Histology/Cytology result transmission.

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 26/30

Connection sheet

OBX 8 Abnormal flags In Histology/Cytology result transmission: - N Normal - A Abnormal The definition of the value normal and abnormal corresponds to the definition of Cytology setup for Cyto pattern values for parameters. OBX 11 Observation Result Status For a Histology/Cytology result, this field contains F (final result).

Example of ORU message

MSH|^~\&|TDR||HOST||20041228142641||ORU^R01|TD0000000312|P|2.3| PID|1||0000000002^^^^PATNUMBER~6546545454654654^^^^ALTNUMBER||SMITH^Bob^^^M|^|19460306000000| F|||12, rue des plantes vertes^appart. C^VAULNAVEYS LE BAS^Dauphin^38600^France|| 0476215699^^PH~0488447755^^FX||||| PV1||||||||||||||||No|||000003213213212|||||||||||||||||||||||||20040427000000| NTE|||Patient comment| ORC|NW||HG04000055||CM||^^^20041228000000^^R|||||CLAF|CORGNT||20041228000000| NTE|||Request comment| OBR|1||HG04000055|HISTO||||||DOE^John DOE|A|||20041228000000||CLAF||||||||HGNT|F|| ^^^20041228000000^^R|||||GNT| OBX|1|TX|HISTO|1|Result text||||||F|

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 27/30

Connection sheet

Troubleshooting Error management

For each ORU^R01message the connection is waiting for an ACK message (ACK^R01): ORU^R01 Histo/Cy ACK^R01 HOST

In the acknowledge message the following information is processed: MSH Segment : - MSH-10 Message control ID. MSA Segment: - MSA-1 Acknowledgement code : positive or negative acknowledgement - MSA-3 Text message: error text. ERR Segment (in case of negative acknowledgment ) : - ERR-1 Error code and location: Details of ERR-1: Components: <segment ID (ST)> ^ <sequence (NM)> ^ <field position (NM)> ^ <code identifying error (CE)>

Positive acknowledgment
An ACK (Accept acknowledgement) is received: MSA-1 Acknowledgement code = AA. => The connection job is set to COMPLETED.

Negative acknowledgment
An ACK (Accept acknowledgement) is received: MSA-1 Acknowledgement is different from code= AA. The ERR segment gives an error code allowing to identify the error. 2 different treatments are possible: - Retry n: n retries occurs according the Number of retries parameter in the Device dictionary. - Rejected: no retry. The error codes are processed as follows: - Retry n : 206;207;100;101;102;103;204;205 - Rejected : 200;201;202;203 Message error status codes
Error Condition Code Error Condition Text Description/Comment

Errors 100 101 102 Segment sequence error Required field missing Data type error The message segments were not in the proper order, or required segments are missing. A required field is missing from a segment The field contained data of the wrong data type, e.g. an NM field contained "FOO".

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 28/30

Connection sheet

Error Condition Code

Error Condition Text

Description/Comment

103 Rejection 200 201 202 203 204

Table value not found

A field of data type ID or IS was compared against the corresponding table, and no match was found.

Unsupported message type Unsupported event code Unsupported processing id Unsupported version id Unknown key identifier

The Message Type is not supported. The Event Code is not supported. The Processing ID is not supported. The Version ID is not supported. The ID of the patient, order, etc., was not found. Used for transactions other than additions, e.g. transfer of a nonexistent patient. The ID of the patient, order, etc., already exists. Used in response to addition transactions (Admit, New Order, etc.). The transaction could not be performed at the application storage level, e.g. database locked. A catchall for internal errors not explicitly covered by other codes.

205 206 207

Duplicate key identifier Application record locked Application internal error

After n retries the connection job is set to the ERROR status. An error message is logged, whose structure is: Negative acknowledgment (MSA code : XX, ERR code : YYY ) : error text in the MSA-3 field plus ERR segment ( segment ID (ST) - sequence (NM) ^ field position (NM) - code identifying error (CE)). XX: MSA-1 Acknowledgment code YY: ERR-1 code sub field code identifying error (CE) Example: FSE CONTEXT DATA : Negative acknowledgment (MSA code : AR, ERR code : 207 ) : A catchall for internal errors not explicitly covered by other codes, Application internal error, PID 1 5 207.

No acknowledgment
The process waits for a few seconds. If no acknowledgement is received, retries occur according the Number of retries parameter defined in the Device dictionary. After n retries if no answer is received, the device status is set to Warning and the connection task remains in READY status.

CNXR019 / 0

V02.01
Confidential. This specification requires an end user agreement

Page 29/30

END USER AGREEMENT FOR CONNECTION The interface specification described in the attached Connection Sheet # CNXR019 HL7: Transmission of Results 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 # CNXR019" is for the exclusive use of sites covered by an End User Agreement. Use of the interface specification "Connection Sheet # CNXR019" implies full acceptance of the terms and conditions of the End User Agreement hereunder.

END USER AGREEMENT FOR CONNECTION SHEET # CNXR019

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 between the Technidata information system and other information systems/equipment. 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.

CNXR019 / 0

V02.01

Page 30/30