HL7

Connection sheet

SHEET # CONNECTION NAME REV # VERSION

10 HL7: Reception of patient demographics 3 V03.11

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.............................................................5Transmission Diagram..........................................................................................5Data Block Structure.............................................................................................6Information exchange description..........................................................................8

Installation procedure..........................................................................................9

Implementation.....................................................................................................9Defining the communication in the Device dictionary.............................................9Starting the Connection service...........................................................................14Defining "Labconf" parameters............................................................................14

Relevant HL7 messages, segment types and fields........................................15ADT processed messages (Event fields)............................................................15Supported segment types...................................................................................22

Segment descriptions........................................................................................23MSH - Message Header Segment.......................................................................23EVN - Event type segment..................................................................................24PID - Patient identifying segment........................................................................24PV1 - Patient visit information.............................................................................29GT1 - Guarantor segment...................................................................................32IN1 - Insurance segment.....................................................................................34

Examples of ADT messages.................................................................................36

CNXR010 / 3 Reception of patient demographics V03.11 Page 1/37Confidential. This specification requires an end user agreement

Connection sheet

History of document modifications

Version/Revision

Short description of the modifications

V01.53 / 0 Creation of the connection sheet.

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

V01.54 / 2 In PID - 5 Patient name field:Modification of chameleon file. This modification must be performed if the delivered HL7.VMD file has been adapted on site in order to answer specific needs.

V01.54 / 3 In the section "Relevant HL7 messages, segment types and fields": 1) Modification of error code: two 201 error code changed into 200.

2) Addition of a warning about tasks in error (not managed by the connection) to alert the user that vital information might be contained in these tasks and require subsequent user action.

3) Addition of Action D and Action E to manage the resulting risks.

V03.11 / 3 This option must not be used without the consent of TECHNIDATA.In the Device dictionary, Patient demographics reception data flow, addition of the property Management of billing information .

Addition of the following segments: IN1 (Insurance) and GT1 (Guarantor).in ADT messages.


Connection sheet

Technical pre-requisites

The communication must be set up on a computer connected to the network 24 hours/day, 7 days/week and on which the connection service is installed.

The computer must be installed with at least Windows 2000 or XP and must 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 3 Patient Administration

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\Orders\ Results processing).

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

Format DLL : TDCnxFormHL7.DLL (HL7 Format Patients/Orders/Results)

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


http://www.technidata-wed.com/

Connection sheet

Presentation

This document describes the rules for the reception of "Patient demographics" messages (ADT messages) transmitted from a HOST through 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) intent 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 that transaction type.

Communication diagram


Connection sheet

Communication layers: TCP / IP socket

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

Transmission Diagram

After the connection between the client (P.A.S) and the server connection task, data is sent to the server by the client.

P.A.S (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 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 processings, 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

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 message embedded into it. 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 simply 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 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 processings, 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


Connection sheet

Data Block Structure

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

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 a 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 "2" "4" 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 last data 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.


Connection sheet

xxx =Checksum (3 bytes).Exclusive-OR checksum of all characters in the block up to and including the last data 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 on a site specific basis. 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 configured as "End of block character" 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.


Connection sheet

Information exchange description

Data exchange between the Patient Administration System and Communication engine corresponds to data blocks being transmitted through a socket.

In order to enable data exchange, a socket (connection) must first be established. One part must be the server, the other part 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 through the previously established socket.

The Communication engine will act as the server and the P.A.S. as the client.

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

In order for the TCP/IP socket low-level protocol to work properly, several parameters must be set:1. The machine onto which the server will be created must be declared as the "recipient 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 is listening to the configured port.5. At this time one and only one simultaneous connection will be accepted by the server.

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

6. When finished, the client disconnects.

Incident management 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 !


Connection sheet

Installation procedure

The Communication engine must be installed with a Client instance.

When the feature selection screen is displayed:

1. Select HL7: Reception of patient demographics by left-clicking on the related line 2. Choose the option This feature will be installed on local hard drive.

Implementation

To set up this communication, a number of parameter settings must be performed at different levels, as listed hereafter: Defining the communication in the Device dictionary Starting the service specified in the Device dictionary Defining LABCONF parameters in the Site configuration window

Defining the communication in the Device dictionary

This step consists in defining the parameters for reception of patient information (new or updated demographic and visit information about patients).This connection must be defined as a device on the Management database 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.

The following definition of the communication in the Device dictionary is given as an example.

Name Value CommentCodeDevice typeService TDCnx_Instancename_Computernam

ename of the computer where the service is installed

NameAbbreviated textFull textProtocol HL7 low layer Protocol (Socket)Format HL7 format Patients/Orders/ResultsTransport TCP-IP socket transportApplication Patients/Orders/Results processingProperties ...

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

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

● The Properties item is used to define the type of data flow and relevant properties. Depending on the communication specified, several types of data flow must be defined. 1. All (displayed by default).The following data flow is dependent on the type of communication:2. Patient demographics reception data flow.


Connection sheet

1. Type of data flow: All

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) 1000Message control ID TDNTServer counters used to

produce control ID of HL7 message

Number of data per message 1 Do not modify.Number of retries 3Path 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 available (maximum, regular, minimum).

FormatHL7 version 2.3Message recipient code HOST

Message sender code TDR

Unicode messaging No Do not modify.Transport

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

Counter length for files to handle 5FTP connection Timeout Default value: 10. Do not modify.FTP local temporary directory Local directory where the FTP files

are stored. Default value: c:\tmpTo customize on site.

FTP password Password associated with the ftp user

To customize on site.

FTP remote host Server. name.here To modify on site.FTP remote output directory Default value:./tmp To customize on site.FTP Server Port 21FTP user ID Name of the ftp user.

Default value: ftpTo customize on site.

Generated file extension RESGenerated file prefix TDRInternal counter 0Message timeout Default value: 5. Do not modify.Remote input directory for FTP files

/

Semaphore file extension for transmitted files

.ok

File locationChameleon file path Name of the directory where is stored the

"hl7.vmd" Chameleon file.To modify on site if needed.


Connection sheet

2. Type of data flow: Patient demography reception

Device properties

Type of flow: Patient demography reception

Name Value Comment General

The General section define how are managed the patient data received in the HL7 ADT message:* These patient data can be :

- Only set in the Management database,- Only forwarded to another device (through 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.

These actions are both managed by the "Update local database" and "Dispatched to devices" parameters.If Output devices property is completed with the connection identification used to ensure the patient data transfer to another device, a task is created by the ADT connection in order to enable the patient data transfer through the customized connection.

Name Value CommentStream active Default value: No. Must be set to YesHospitalization creation and update

Yes Do not modify

Management of billing information

Yes/No Answer Yes to enable the reception of information about the Insurance of a patient and his/her Guarantor and enable the management of the Medical Necessity indicator.See Note 2

Output devices Name of the device for demographic information transmission.

Prefix of beneficiary number on the Host

Prefix applied to the beneficiary identification, e.g. BEN.

See Note 1

Prefix of hospitalization number on the host

Prefix applied to the hospitalization identification, e.g. HOS.

See Note 1

Prefix of patient number on the host

Prefix applied to the patient identification, e.g. PAT.

See Note 1

Note 1:A prefix can be applied (optional) to the patient identification (Beneficiary, Hospitalization or Patient number) sent in the ADT HL7 message in order to specify the sending Host. These parameters must be empty if the patient identification sent in the HL7 ADT messages must not be modified.

Note 2: The Medical Necessity Required indicator is managed if the property Management of billing information is enabled (set to Yes). This information can be obtained in three ways: for more details refer to the section Segment description, IN1 - Insurance segment paragraph.

Name Value CommentUpdate local database Default value: No (the Management

database is not updated with the demographic data).

Must be set to Yes (the Management database is updated with the


Connection sheet

demographic data).FormatPatient differences Default value: 4 differences. To modify on site if

needed

Update Patient reference (Doc/Loc)

Enables/disables the update of patient reference of the Management database with the data of the HL7 ADT message. If enabled, the reference doctor and reference location fields are updated in the database with data from the received message.Default value: No.

Set it to Yes if needed

* If the patient data must be set in the Management database, controls are performed on the patient's demographic fields before the Management database can be updated with the new received data. This control consists in comparing the demographic information differences against the maximum number of differences that are authorized to update the database. Five fields are controlled on reception of a patient demography message: Patient name, Patient firstname, Patient maiden name, Patient date of birth and Patient sex. The content of these fields is compared with the content of the same fields in the database.The number of authorized differences between the data of the Management database and the data in the HL7 ADT message is set in Patient differences.The patient record in the database is updated with the data of the HL7 ADT message only if the number of differences is lower or equal to the maximum of authorized differences. If the number of fields modified exceeds the authorized number of changes, the HL7 ADT message is not processed.

* If the Management database or if the patient record is locked (protected) when the ADT connection tries to set information in the database, the ADT connection tries several times to access the database. This number of attempts is set in the 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.

Name Value CommentMappingDoctors Code of the coding system used to

map doctor codes. (1).Create/select the code of a coding system.

Financial class Code of the Financial class provided by the HIS in the ADT message and automatically recovered. (2)

Select Autocreate to have the financial class field automatically fed by the communication process.(3)

Hospital Service Code of the Hospital Service provided by the HIS in the ADT message and automatically recovered. (2)

Select Autocreate to have the hospital service class field automatically fed by the communication process.(3)

Locations Code of the coding system used to map location codes. (1).

Create/select the code of a coding system.

Patient classes Code of the Patient class provided by the HIS in the ADT message and automatically recovered. (2)

Select Autocreate to have the patient class field automatically fed by the communication process.(3)

Titles Code of the coding system used to map title codes. (1).

Create/select the code of a coding system.

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


Connection sheet

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


Connection sheet

Starting the Connection service

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

Connection service Addressing

The address of the communication port can be allocated dynamically when the 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:Excluding portsA list of excluded ports by computer can be specified. It must be set up in the registry as in the following example:

Specifying the port for a serviceYou 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\ProductClient-Appli1\servcnx.exe TDCnx1 8011

Defining "Labconf" parameters

In the Laboratory configuration window, General parameters section, make sure that the lengths of the following fields are the same as on the Production database (Parameter setting zone - GST block):- Patient number length- Hospitalization number length- Duplicate stay numbers are allowed (0=No 1=Yes). This parameter must be set to 1 if Hospitalization

numbers are not unique. The default value is 0.- Alternate number length


Connection sheet

Relevant HL7 messages, segment types and fields

ADT processed messages (Event fields)

There are 62 different ADT messages on the HL7 V2.4 version. These 62 messages do not have the same segment structure and can be recognized through the Event field.

3 different actions (Action A, B and C) are performed depending on the Event field.

Action A: The events are managed by the communication, i.e. a task is created for each received ADT message

List of the managed events on the delivered communication:

NOTE All the events listed below are managed as an A08 event, that is, like an update of patient demographics (such as the name, firstname, etc.).

*A01: Admit/visit notification*A02: Transfer a patient *A03: Discharged / end visit *A04: Register a patient *A05: Pre-admit a patient *A06: Change an outpatient to an inpatient*A07: Change an inpatient to an outpatient *A08: Update patient information *A09: Patient departing-tracking *A10: Patient arriving-tracking *A12: Cancel transfer *A13: Cancel discharge/end visit *A14: Pending admit *A32: Cancel patient arriving -tracking*A33: Cancel patient departing -tracking *A54: Change attending doctor*A55: Cancel change attending doctor

If no problem occurs during the management of the message, a positive logical acknowledgement is sent to the Host and the created task 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 no error code 0.

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 message, some errors can occur. In such cases, the created task is set to the "Error" status.

Errors managedThe managed errors are:

- 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 firstname and lastname, the maiden name, the sex and the birthdate of the patient). X is greater than the authorized number of differences customized with the "Patients differences" parameter in the Device dictionary.In such a case, the ADT message is not integrated in the Management database and a negative logical acknowledgement is sent to the host.


Connection sheet

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

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

The MSA-3 field is filled in with the string: 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 ADT 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.

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

The MSA-3 field is filled in with the string: The ID of the patient, order, etc., already exists. Used in response to addition transactions (Admit, New Order, etc.).

Case 3: The ADT message sent by the P.A.S. cannot be properly parsed (problem on the HL7 structure).In such case, the ADT 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 AE (application acknowledgement Error) and the ERR-1 field, subfield 4, "Error code" and the "ERR-1" fields are set to the error code 100.

100 Segment sequence error The message segments were not in the proper order, or required segments are missing.

The MSA-3 field is filled in with the string: The message segments were not in the proper order, or required segments are missing.

- Case 4: The ADT message sent by the P.A.S. is properly parsed and managed but the database is locked/not available or the patient record to update is protected.In such a case, the ADT 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 the "ERR-1" fields are set to the error code 206.

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

The MSA-3 field is filled in with the string: The transaction could not be performed at the application storage level, e.g. database locked.


Connection sheet

Action B: the events are ignored (no task is created)

For these events, the ADT message is not managed 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 200.

200 Unsupported event code The Event Code is not supported.

The MSA-3 field is filled in with the string: The %s Event code is not supported.

List of the ignored events on the delivered communication :*A38: Cancel pre-admit *A11: Cancel admit/visit notification*A27: Cancel pending admit*A15: Pending transfer *A26: Cancel pending transfer*A16: Pending discharge *A25: Cancel pending discharge*A17: Swap patients *A19: Patient query *A20: Bed status update*A21: Patient goes on a leave of absence*A52: Cancel leave of absence for a patient*A22: Patient returns from a leave of absence*A23: Delete a patient record *A53: Cancel patient returns from a leave of absence*A28: Add person or patient information *A29: Delete person information*A30: Merge person information *A31: Update person information*A37: Unlink patient information *A49: Change patient account number*Q21: Get person demographics*Q22: Find candidates*Q23: Get corresponding identifiers*Q24: Allocate identifiers*A60: Update adverse reaction information*A61: Change consulting doctor*A62: Cancel change consulting doctor.


Connection sheet

Action C: the events are managed in error (an error is generated on the Management database, a task in error is created)

For these events (listed below), the ADT message is not managed 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 200.

200 Unsupported event code The Event Code is not supported.

The MSA-3 field is filled in with the string: The %s Event code is not supported.

List of the events managed as errors on the delivered communication :*A18: Merge patient information*A24: Link patient information*A34: Merge patient information (patient ID only)*A35: Merge patient information (account number only)*A36: Merge patient information (patient ID & account number)*A39: Merge person - patient ID *A40: Merge patient - patient identifier list*A41: Merge account - patient account number*A42: Merge visit - visit number*A43: Move patient information -patient identifier list*A44: Move account information -patient account number*A45: Move visit information - visit number*A46: Change patient ID*A47: Change patient identifier list*A48: Change alternate patient ID*A50: Change visit number*A51: Change alternate visit number

We draw your attention to the fact that events managed by this connection as errors (displayed in the Task manager window), might contain vital information that requires subsequent manual action by the user (for example "Change Patient ID"). The Installation engineer must warn the user about the associated risks so that the user can make the necessary verifications to avoid loss of important information.Failure to do this could be dangerous for the patient.In order to manage these risks, the action D and E can be enabled.

Action D: the events are managed in merge error (an error is generated on the Management database and a merge task in error is created)

This management is not automatically implemented on the delivered version, but it might be necessary to implement it in order to merge manually two patients after reception of an A40 message.

Events processed in action D will generate a task in error containing minimum information required to perfom the merge manually, using the Merge functionality available on TD-Synergy (refer to the corresponding online user help).

Example of merge task: Merge (Source: DUPONT Jean, Pat# 222222, Alt# ALT1238 Target: DUPOND Jean, Pat# 784512, Alt# MRCMRC)


Connection sheet

Action E: the events are managed in cancel error (an error is generated on the Management database, a cancel task in error is created)

This management is not automatically implemented on the delivered version, but it might be necessary to implement it so that users can be informed of a cancel pre-admission, cancel admission, cancel patient transfer or cancel patient discharge that could not be performed.

Events processed in action E will generate a task in error containing information related to the cancel event that could not be peformed.

Example of cancel task:A11 : Cancel admission or visit notification (DUPONT LAURENT, Pat# 12345, Alt# MRCMRC, Stay# 12345)A38 : Cancel pre-admission (DUPONT LAURENT, Pat# 12345, Alt# MRCMRC, Stay# 12345)A12 : Cancel patient transfer (DUPONT LAURENT, Pat# 12345, Alt# MRCMRC, Stay# 12345)A13 : Cancel patient discharge or end visit (DUPONT LAURENT, Pat# 12345, Alt# MRCMRC, Stay# 12345)

Note : The definition of the different event lists is performed by CHAMELEON :A first CHAMELEON list gives the events to manage (Action A)


Connection sheet

A second CHAMELEON list gives the events to manage as errors (Action C).

The events not defined in the previous two lists are filtered (Action B).With this management, a new event will be filtered.


Connection sheet

To manage events as merge errors (Actions D), proceed as follows:1) Remove the concerned events from the Action C list2) Add them to the CHAMELEON list for action D events

To manage events as cancel errors (Actions E), proceed as follows:1) Remove the concerned events from the Action C list2) Add them to the CHAMELEON list for action D events


Connection sheet

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

GT1 - Guarantor segmentIt contains guarantor data for patient and insurance billing applications.

IN1 - Insurance segmentIt contains insurance policy coverage information.

Each message must be identified by a "message header" segment and an "end of message" 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 encountered all along in the document.

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

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

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.


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 (task 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. From the TDR-Server to the Host, 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 Host connected. 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).


Connection sheet

EVN - Event type segment

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


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

No information in EVN segment is managed by the connection.

PID - Patient identifying segment

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


1 4 SI Set ID – PID Not Used 2 20 CX Patient ID Not Used3 250 CX Patient Identifier List Patient Number, or

Alternate Patient Number4 20 CX Alternate Patient ID - PID Not Used5 250 XPN Patient Name Patient name6 250 XPN Mother’s Maiden Name Not Used7 26 TS Date/Time of Birth Patient birth date8 1 IS Administrative Sex Patient sex9 250 XPN Patient Alias Not Used

10 250 CE Race Patient ethnic origin11 250 XAD Patient Address Address 1st line

Address 2nd lineCityState ProvincePostal codeCountry

12 4 IS County Code Not Used13 250 XTN Phone Number - Home Telephone number

Telephone number 2FaxEmail address

14 250 XTN Phone Number - Business Not Used15 250 CE Primary Language Not Used16 250 CE Marital Status Not Used17 250 CE Religion Religion18 250 CX Patient Account Number Not Used19 16 ST SSN Number - Patient Not Used20 25 DLN Driver's License Number - Patient Not Used21 250 CX Mother's Identifier Not Used22 250 CE Ethnic Group Not Used23 250 ST Birth Place Not Used24 1 ID Multiple Birth Indicator Not Used25 2 NM Birth Order Not Used26 250 CE Citizenship Not Used27 250 CE Veterans Military Status Not Used


Connection sheet


28 250 CE Nationality Not Used29 26 TS Patient Death Date and Time Not Used30 1 ID Patient Death Indicator Not Used31 1 ID Identity Unknown Indicator Not Used32 20 IS Identity Reliability Code Not Used33 26 TS Last Update Date/Time Not Used34 40 HD Last Update Facility Not Used35 250 CE Species Code Not Used36 250 CE Breed Code Not Used37 80 ST Strain Not Used38 250 CE Production Class Code Not Used

PID - 3 Patient identifier list fieldComponents: <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 403O^^^N^CODFISC~261055502^^^060^CODSAN~STP0501160000004^^^060106^STPCODFISC, CODSAN, STP identify each identification type.403O, 261055502, STP0501160000004 are the identification ID for each identification.

Only two patient identifications are available: either 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 Field Service Engineer during the connection installation using python scripting in the chameleon PatientID table :


Connection sheet

PID - 5 Patient name fieldComponents: In Version 2.3, replaces the PN data type. <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 MARCHESE^MARCO^^^^^L~soprannome^^^^^^ML, M identify each name type.MARCHESE^MARCO, soprannome, are the string for each name.

Two different levels of names are available: the Patient Name and the Maiden name.

On Chameleon, there is an association between the Host patient name type codes and the two Management database patient names.This association can be changed by the Field Service Engineer during the connection installation using python scripting in the chameleon Names table :

Depending on the site (first installation or update of the connection), the HL7.vmd file must be adapted as described below. The length of the patient name, that is to say, lastname and firstname must be truncated in accordance with the values defined on the Production database.

NAMEPossible sizes: 25 or 60 characters max.

If required, adapt the HL7.VMD file by adding a macro python incoming (incoming = "in Equation") to the column LASTNAME of the NAMES table, as described in the example below (example with length=25):


Connection sheet

FIRSTNAMELength: 15 characters max.

Modify the HL7.VMD file by adding a macro python incoming (incoming = "in Equation") to the column FIRSTNAMEof the NAMES table, as described in the example below:

This modification must be performed if the delivered HL7.VMD file has been adapted on site in order to answer specific needs.

PID - 7 Patient birth dateThis field is is used for the patient birth date.

PID - 8 Patient sexThis field is used for the patient sex.

Value Description

F Female

M Male

O Other

U Unknown

A Ambiguous

N Not applicable

PID - 10 Patie0nt ethnic originThis field is used for the patient race.

PID - 11 Patient addressThis field contains all patient addresses. This field is repeatable and each element contains one address.The Communication Engine can only manage one address by patient. So, the first address is always managed by the communication.


Connection sheet

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 phone number.Each phone number is identified by a phone type code : Telephone 1, Telephone 2 and Fax.

In Chameleon, there is an association between the Host phone type codes and the Management database phones. This association can be changed by the FSE during the connection installation using python scripting in the chameleon Telephones table :

PID - 17 Patient religionThis field is used for the patient religion code.


Connection sheet

PV1 - Patient visit information

SEQ LEN DT ELEMENT NAME On Communication Engine

1 4 SI Set ID - PV1 Not Used2 1 IS Patient Class Stay patient class3 80 PL Assigned Patient Location Reference Location ID (sub-field 1)

Room number (sub-field 3)4 2 IS Admission Type Not Used5 250 CX Preadmit Number Not Used6 80 PL Prior Patient Location Not Used7 250 XCN Attending Doctor Attending doctor8 250 XCN Referring Doctor Reference doctor9 250 XCN Consulting Doctor Not Used10 3 IS Hospital Service Hospital service11 80 PL Temporary Location Not Used12 2 IS Preadmit Test Indicator Not Used13 2 IS Re-admission Indicator Not Used14 6 IS Admit Source Not Used15 2 IS Ambulatory Status Not Used16 2 IS VIP Indicator Patient secret and Patient VIP17 250 XCN Admitting Doctor Admitting doctor18 2 IS Patient Type Not Used19 250 CX Visit Number Hospitalization Number20 50 FC Financial Class Hospitalization financial class (sub-field 1)

Date when the financial class is taken into account (sub-field 2)

21 2 IS Charge Price Indicator Not Used22 2 IS Courtesy Code Not Used23 2 IS Credit Rating Not Used24 2 IS Contract Code Not Used25 8 DT Contract Effective Date Not Used26 12 NM Contract Amount Not Used27 3 NM Contract Period Not Used28 2 IS Interest Code Not Used29 1 IS Transfer to Bad Debt Code Not Used30 8 DT Transfer to Bad Debt Date Not Used31 10 IS Bad Debt Agency Code Not Used32 12 NM Bad Debt Transfer Amount Not Used33 12 NM Bad Debt Recovery Amount Not Used34 1 IS Delete Account Indicator Not Used35 8 DT Delete Account Date Not Used36 3 IS Discharge Disposition Not Used37 25 CM Discharged to Location Not Used38 250 CE Diet Type Not Used39 2 IS Servicing Facility Not Used40 1 IS Bed Status Not Used41 2 IS Account Status Not Used42 80 PL Pending Location Not used43 80 PL Prior Temporary Location Not Used44 26 TS Admit Date/Time Admission Date Time45 26 TS Discharge Date/Time Discharge Date Time46 12 NM Current Patient Balance Not Used47 12 NM Total Charges Not Used48 12 NM Total Adjustments Not Used49 12 NM Total Payments Not Used50 250 CX Alternate Visit ID Not Used51 1 IS Visit Indicator Not Used52 250 XCN Other Healthcare Provider Not Used


Connection sheet

PV1 - 2 Patient classThis field is managed as the Stay patient class by the connection.

PV1 - 3 Assigned patient locationThis field is used for the Stay location and Patient reference location by the connection.

PV1 - 7 Attending doctorThis field is managed as the Stay attending doctor by the connection.

PV1 - 8 Referring doctorThis field is managed as the Patient reference doctor by the connection.

PV1 - 10 Hospital ServiceThis field is managed as the Stay hospital service (Medical discipline) by the connection.

PV1 - 16 VIP IndicatorThis field is managed as the Patient VIP and the Patient Secret Result by the connection.But it is possible to manage either the Patient VIP or the Patient Secret Result, if needed. Then, the information to be managed in this field can be indicated by the FSE during the connection installation using the Chameleon mapping logic on the Patient table.

In Chameleon, there is an association between the different values of Patient VIP on the Management database (Yes or No) and HL7 code. This association can be changed by the Field Service Engineer during the connection installation using python scripting in the Chameleon Patient table.

Data (VIP) on Management database

PV1-16 VIP Indicator

1 (yes) YES0,null (no) NO

In the Management database, this information is stored in the PATIENT table, so each visit updates the patient information.

PV1 - 17 Admitting doctorThis field is managed as the Stay admitting doctor by the connection.


Connection sheet

PV1 -19 Visit numberThis field is managed as the Hospitalization number by the connection, according to the labconf parameter: Duplicate stay numbers are allowed (0=No 1=Yes). This parameter must be set to 1 if Hospitalization numbers are not unique. The default value is 0.

PV1 - 44 Admit date/timeThis field is managed as the Admit Date / Time of the hospitalization by the connection.

PV1 - 45 Discharge date/timeThis field is managed as the Discharge Date / Time of the hospitalization by the connection.


Connection sheet

This option must not be used without the consent of TECHNIDATA.

GT1 - Guarantor segmentThe GT1 segment contains guarantor (e.g., the person or the organization with financial responsibility for the payment of a patient account) data for patient and insurane billing applications.


1 4 SI Set ID - GT1 Not Used2 250 CX Guarantor Number Guarantor number (ID sub-field)3 250 XPN Guarantor Name Guarantor Name, Firstname4 250 XPN Guarantor Spouse Name Not Used5 250 XAD Guarantor Address Guarantor Address6 250 XTN Guarantor Ph Num - Home Guarantor Phone Number Home7 250 XTN Guarantor Ph Num - Business Not Used8 26 TS Guarantor Date/Time Of Birth Guarantor Date of birth9 1 IS Guarantor Administrative Sex Guarantor sex10 2 IS Guarantor Type Guarantor Type11 250 CE Guarantor Relationship Relationship to patient12 11 ST Guarantor SSN Garantor Social Security Number13 8 DT Guarantor Date - Begin Not Used14 8 DT Guarantor Date - End Not Used15 2 NM Guarantor Priority Not Used16 250 XPN Guarantor Employer Name Employer Name17 250 XAD Guarantor Employer Address Employer Address18 250 XTN Guarantor Employer Phone

numberEmployer Phone number

19 250 CX Guarantor Employee ID Number Guarantor Employee ID Number (ID sub-field)

20 2 IS Guarantor Employment Status Not Used21 250 XON Guarantor Organization Name Guarantor Organization Name

(Organization Name sub-field)22 1 ID Guarantor Billing Hold Flag Not Used23 250 CE Guarantor Credit Rating Code Not Used24 26 TS Guarantor Death Date And Time Not Used25 1 ID Guarantor Death Flag Not Used26 250 CE Guarantor Charge Adjustment

CodeNot Used

27 10 CP Guarantor Household Annual Income

Not Used

28 3 NM Guarantor Household Size Not Used29 250 CX Guarantor Employer ID Number Not Used30 250 CE Guarantor Marital Status Code Not Used31 8 DT Guarantor Hire Effective Date Not Used32 8 DT Employment Stop Date Not Used33 2 IS Living Dependency Not Used34 2 IS Ambulatory Status Not Used35 250 CE Citizenship Not Used36 250 CE Primary Language Not Used37 2 IS Living Arrangement Not Used38 250 CE Publicity Code Not Used39 1 ID Protection Indicator Not Used40 2 IS Student Indicator Not Used41 250 CE Religion Not Used42 250 XPN Mother’s Maiden Name Not Used43 250 CE Nationality Not Used44 250 CE Ethnic Group Not Used45 250 XPN Contact Person’s Name Not Used46 250 XTN Contact Person’s Telephone

NumberNot Used


Connection sheet


47 250 CE Contact Reason Not Used48 3 IS Contact Relationship Not Used49 20 ST Job Title Not Used50 20 JCC Job Code/Class Not Used51 250 XON Guarantor Employer’s

Organization NameNot Used

52 2 IS Handicap Not Used53 2 IS Job Status Not Used54 50 FC Guarantor Financial Class Not Used55 250 CE Guarantor Race Not Used


Connection sheet

This option must not be used without the consent of TECHNIDATA.

IN1 - Insurance segmentThe IN1 segment contains insurance policy coverage information necessary for billing.


1 4 SI Set ID - IN1 Not Used2 250 CE Insurance Plan ID Insurance Plan ID3 250 CX Insurance Company ID Insurance Company code (ID sub-field)4 250 XON Insurance Company Name Insurance Company Name5 250 XAD Insurance Company Address Insurance Company Address6 250 XPN Insurance Co Contact Person Contact name7 250 XTN Insurance Co Phone Number Insurance Co Phone Number8 12 ST Group Number Group Number9 250 XON Group Name Not Used10 250 CX Insured’s Group Emp ID Employer number11 250 XON Insured’s Group Emp Name Employer Name12 8 DT Plan Effective Date Plan Effective Date13 8 DT Plan Expiration Date Plan Expiration Date14 239 AUI Authorization Information Not Used15 3 IS Plan Type Plan Type16 250 XPN Name Of Insured Insured Name17 250 CE Insured’s Relationship To

PatientRelationship to patient

18 26 TS Insured’s Date Of Birth Not Used19 250 XAD Insured’s Address Insured Address20 2 IS Assignment Of Benefits Assignment of benefits (Y/N)21 2 IS Coordination Of Benefits Not Used22 2 ST Coord Of Ben. Priority Not Used23 1 ID Notice Of Admission Flag Not Used24 8 DT Notice Of Admission Date Not Used25 1 ID Report Of Eligibility Flag Not Used26 8 DT Report Of Eligibility Date Not Used27 2 IS Release Information Code Not Used28 15 ST Pre-Admit Cert (PAC) Not Used29 26 TS Verification Date/Time Not Used30 250 XCN Verification By Not Used31 2 IS Type Of Agreement Code Not Used32 2 IS Billing Status Not Used33 4 NM Lifetime Reserve Days Not Used34 4 NM Delay Before L.R. Day Not Used35 8 IS Company Plan Code Not Used36 15 ST Policy Number Not Used37 12 CP Policy Deductible Not Used38 12 CP Policy Limit - Amount Not Used39 4 NM Policy Limit - Days Not Used40 12 CP Room Rate - Semi-Private Not Used41 12 CP Room Rate - Private Not Used42 250 CE Insured’s Employment Status Insured’s employment status43 1 IS Insured’s Administrative Sex Insured’s administrative sex44 250 XAD Insured’s Employer’s Address Not Used45 2 ST Verification Status Not Used46 8 IS Prior Insurance Plan ID Not Used47 3 IS Coverage Type Not Used48 2 IS Handicap Not Used49 250 CX Insured’s ID Number Insured’s ID Number (ID sub-field)50 1 IS Signature Code Not Used51 8 DT Signature Code Date Not Used


Connection sheet


52 250 ST Insured’s Birth Place Not Used53 2 IS VIP Indicator Not Used

Information related to the Insurance company is stored in the Insurance dictionary of the Management database.

The Medical Necessity Required indicator is processed by the Communication engine if the Management of billing information property is enabled in the Device dictionary. This information can be obtained in three ways, as described below:

1) It can be deduced from the Plan Type field (IN1-15) if the Insurance code is built from the Plan ID and the Company ID fields (IN1-2 + IN1-3).

2) If the Insurance code does not contain the Plan ID, then the indicator is deducted from the value of the Plan Type field. The information to be managed in this field can be indicated by the FSE during the connection installation using the Chameleon mapping logic in the Insured table.Proceed as follows:> Go to the Insured Mapping table and associate the field "15- Plan type" with the field "Medical Necessity".> Go to the Insured Table. On the "Medical Necessitiy" line, click in the "In Equation" cell and define a macro python, as in the following example.

3) This indicator can also be deduced from the Financial Class field of the PV1 segment.


Connection sheet

Examples of ADT messages

MSH|^~\&|SSI|SI|LIS|SMITH|200305081258||ADTÂ01|SI030000000000095400|P|2.03PID||98700021^^^106|98900021^^^LÂSSIPCA~98600021^^^N^CODFISC~98700021^^^060^CODSAN||TESTRLE2^Robin2^^^^^L~Fleurus2^^^^^^M||19850724|M||2056-5^Blanc|9 rue Marcel Cachin^^Meylan^^38100^FRANCE^L^||0476001122^^PH~0600112233^^[email protected]^Înternet||||ATH^Catholic||261055501PV1||O|MEDIR^2^Lit19^^^^^^|||||CLAD^Maraul2^Doc|||||||||||20020001|~~~||||||||||||||||||||||||20030709||||||954||NTE||| PATIENT_COMMENT_TESTRLE5

MSH|^~\&|SSI|SI|LIS|BAYER|200305081258||ADTÂ35|SI030000000000095400|P|2.03PID||261055502^^^106|46619287^^^LÂSSIPCA~MRCMRC75D21I403O^^^N^CODFISC~261055502^^^060^CODSAN~STP0501160000004^^^060106^STP||MARCHESE2^MARCO^^^^^L~soprannome^^^^^^C||19750421|M|||VIA CASARSA,82^ZOPPOLA^^PN^33081^^L^093051~,^^^^33081^^C^||604582||||||261055501PV1||O|019201^1^18^^^^^^||||~^^^^^^^^^^^^050901&010501&L|~^^^^^^^^^^^^050901&010501&L|||||||||||200258423|~~~||||||||||||||||||||||||20030508||||||954||MRG|46619288^^^LÂSSIPCA~MRCMRC75D21I403M^^^N^CODFISC~261055503^^^060^CODSAN~STP0501160000005^^^060106^STP||||||MARCHESE2^MARCO^^^^^L|

Example with:- Assigned patient location "ASSLOC1" with room number "ROOM20" and bed number "B2"- Attending doctor "ATTEN"- Referring doctor "REF1"- Hospital Service "HOSP"- VIP Indicator "VIP"'- Admitting doctor "ADMDOC"

MSH|^~\&|SSI|SI|LMX|BAYER|200305081258||ADTÂ01|SI030000000000095400|P|2.03PID||261055502^^^106|9911111^^^LÂSSIPCA~9911111^^^060^CODSAN||GDS0^GDS0^^^^^L~GDS0MAIDEN^^^^^^M||19750421|M|||VIA CASARSA,82^ZOPPOLA^^PN^33081^^L^093051~,^^^^33081^^C^||604582||||||261055501PV1||O|ASSLOC1^ROOM20^B2^^^^^||||ATTEN1|REF1||HOSP||||||VIP|ADMDOC||9911119|~~~||||||||||||||||||||||||20030508||||||954||


END USER AGREEMENT FOR CONNECTION

The interface specification described in the attached Connection Sheet # CNXR010 "Patient Administration Reception (HL7 2.4 / TCP-IP Socket)" 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 # CNXR010" is for the exclusive use of sites covered by an End User Agreement. Use of the interface specification "Connection Sheet # CNXR010" implies full acceptance of the terms and conditions of the End User Agreement hereunder.

END USER AGREEMENT FOR CONNECTION SHEET # CNXR010

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.


HL7

Documents

end user agreement

ip socket

relevant hl7

level protocol

patient demographics

segment types

tcpip socket

cnxr010 3