Connection sheet

SHEET # CONNECTION NAME REV # VERSION

10

HL7: Reception of patient demographics

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 2 References 2 Presentation 3
Communication diagram 3

Communication layers: TCP / IP socket 4

Transmission Diagram 4 Data Block Structure 4 Information exchange description 7

Relevant HL7 messages, segment types and fields 8

ADT processed messages (Event fields) 8 Supported segment types 12

Segment descriptions 13
MSH - Message Header Segment 13 EVN - Event type segment 14 PID - Patient identifying segment 14 PV1 - Patient visit information 18

CNXR010 / 3

Reception of patient demographics

V03.11

Page 1/21

Confidential. This specification requires an end user agreement

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.4 Chapter 3 Patient Administration Date of this standard: November 2000 Reference number of HL7 standard (Low Level Protocol) Date of this standard: Low Level protocol HL7 2.3 Appendix C Lower Layer Protocols June 1998

CNXR010 / 3

Reception of patient demographics

V03.11

Page 2/21

Confidential. This specification requires an end user agreement

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

CNXR010 / 3

Reception of patient demographics

V03.11

Page 3/21

Confidential. This specification requires an end user agreement

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 lowlevel 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 server with a HL7 ACK message embedded into it

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

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). <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 server with a HL7 ACK message embedded into it

<

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

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

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

Connection sheet

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 Protocol ID (2 bytes). Characters "2" "4" 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 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. 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".

vv = <CR> = dddd =

xxx =

CNXR010 / 3

Reception of patient demographics

V03.11

Page 5/21

Confidential. This specification requires an end user agreement

Connection sheet <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. Carriage Return (1 byte). The ASCII carriage return character, i.e., <0x0D>.

<CR> =

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

CNXR010 / 3

Reception of patient demographics

V03.11

Page 6/21

Confidential. This specification requires an end user agreement

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 !

* * *

CNXR010 / 3

Reception of patient demographics

V03.11

Page 7/21

Confidential. This specification requires an end user agreement

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

CNXR010 / 3

Reception of patient demographics

V03.11

Page 8/21

Confidential. This specification requires an end user agreement

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.

CNXR010 / 3

Reception of patient demographics

V03.11

Page 9/21

Confidential. This specification requires an end user agreement

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

CNXR010 / 3

Reception of patient demographics

V03.11

Page 10/21

Confidential. This specification requires an end user agreement

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 "ERR1" 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)

CNXR010 / 3

Reception of patient demographics

V03.11

Page 11/21

Confidential. This specification requires an end user agreement

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.

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 segment It 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 segment It contains guarantor data for patient and insurance billing applications. IN1 - Insurance segment It 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 size All 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.

CNXR010 / 3

Reception of patient demographics

V03.11

Page 12/21

Confidential. This specification requires an end user agreement

Connection sheet

Segment descriptions 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 parse the HL7 message Used to parse the HL7 message Used for message acknowledgment Not Used Used for message acknowledgment Not Used Not Used Not Used Used to determine the message type Used to identify the rejected message in case of error (task information) Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used Not Used

MSH 1 - 2 Field Separator / Encoding Characters

Defines 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 Application

Determines the Host connected. Used for acknowledgment message.

MSH - 5 Receiving Application

Determines the receiving application. Used for acknowledgment message.

MSH - 9 Message Type

Determines the message type (Message type code + event code).

CNXR010 / 3

Reception of patient demographics

V03.11

Page 13/21

Confidential. This specification requires an end user agreement

Connection sheet

EVN - Event type segment

The EVN segment is used for communicating necessary trigger event information to receiving applications. SEQ 1 2 3 4 5 6 7 LEN 3 26 26 3 250 26 180 DT ID TS TS IS XCN TS HD FIELD NAME Event Type Code Recorded Date/Time Date/Time Planned Event Event Reason Code Operator ID Event Occurred Event Facility On Communication Engine Not Used Not Used Not Used Not Used Not Used Not Used 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. 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 Administrative Sex Patient Alias Race Patient Address On Communication Engine Not Used Not Used Patient Number, or Alternate Patient Number Not Used Patient name Not Used Patient birth date Patient sex Not Used Patient ethnic origin 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 Not Used Page 14/21

12 13

4 250

IS XTN

County Code Phone Number - Home

14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 CNXR010 / 3

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

XTN CE CE CE CX ST DLN CX CE ST ID NM CE 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 Nationality V03.11

Reception of patient demographics

Confidential. This specification requires an end user agreement

Connection sheet SEQ 29 30 31 32 33 34 35 36 37 38 LEN 26 1 1 20 26 40 250 250 80 250 DT TS ID ID IS TS HD CE CE ST CE FIELD NAME Patient Death Date and Time Patient Death Indicator Identity Unknown Indicator Identity Reliability Code Last Update Date/Time Last Update Facility Species Code Breed Code Strain Production Class Code On Communication Engine Not Not Not Not Not Not Not Not Not Not Used Used Used Used Used Used Used Used Used Used

PID - 3 Patient identifier list field

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 403O^^^N^CODFISC~261055502^^^060^CODSAN~STP0501160000004^^^060106^STP CODFISC, 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.

CNXR010 / 3

Reception of patient demographics

V03.11

Page 15/21

Confidential. This specification requires an end user agreement

Connection sheet

PID - 5 Patient name field

Components: 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^^^^^^M L, 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.

PID - 7 Patient birth date

This field is is used for the patient birth date.

PID - 8 Patient sex

This field is used for the patient sex. Value F M O U A N Description Female Male Other Unknown Ambiguous Not applicable

PID - 10 Patie0nt ethnic origin

This field is used for the patient race.

PID - 11 Patient address

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

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.

PID - 17 Patient religion

This field is used for the patient religion code. CNXR010 / 3 Reception of patient demographics V03.11 Page 16/21

Confidential. This specification requires an end user agreement

Connection sheet

CNXR010 / 3

Reception of patient demographics

V03.11

Page 17/21

Confidential. This specification requires an end user agreement

Connection sheet

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 49 50 51 52 CNXR010 / 3 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 12 250 1 250 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 NM CX IS XCN 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 Total Payments Alternate Visit ID Visit Indicator Other Healthcare Provider On Communication Engine Not Used Stay patient class Reference Location ID (sub-field 1) Room number (sub-field 3) Not Used Not Used Not Used Attending doctor Reference doctor Not Used Hospital service Not Used Not Used Not Used Not Used Not Used Patient secret and Patient VIP Admitting doctor Not Used Hospitalization Number Hospitalization financial class (sub-field 1) Date when the financial class is taken into account (sub-field 2) 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 Not Used Not Used Not Used Not Used V03.11 Page 18/21

Reception of patient demographics

Confidential. This specification requires an end user agreement

Connection sheet

PV1 - 2 Patient class

This field is managed as the Stay patient class by the connection.

PV1 - 3 Assigned patient location

This field is used for the Stay location and Patient reference 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 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 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.

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 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/time

This field is managed as the Admit Date / Time of the hospitalization by the connection.

PV1 - 45 Discharge date/time

This field is managed as the Discharge Date / Time of the hospitalization by the connection.

CNXR010 / 3

Reception of patient demographics

V03.11

Page 19/21

Confidential. This specification requires an end user agreement

Connection sheet Examples of ADT messages MSH|^~\&|SSI|SI|LIS|SMITH|200305081258||ADT^A01|SI030000000000095400|P|2.03 PID||98700021^^^106|98900021^^^L^ASSIPCA~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^^CP~toto@wanadoo.FR^^Internet|||| ATH^Catholic||261055501 PV1||O|MEDIR^2^Lit19^^^^^^|||||CLAD^Maraul2^Doc|||||||||||20020001|~~~||||||||||||||||||||||||20030709||||||954|| NTE||| PATIENT_COMMENT_TESTRLE5 MSH|^~\&|SSI|SI|LIS|BAYER|200305081258||ADT^A35|SI030000000000095400|P|2.03 PID||261055502^^^106| 46619287^^^L^ASSIPCA~MRCMRC75D21I403O^^^N^CODFISC~261055502^^^060^CODSAN~STP05011 60000004^^^060106^STP||MARCHESE2^MARCO^^^^^L~soprannome^^^^^^C||19750421|M|||VIA CASARSA,82^ZOPPOLA^^PN^33081^^L^093051~,^^^^33081^^C^||604582||||||261055501 PV1||O|019201^1^18^^^^^^||||~^^^^^^^^^^^^050901&010501&L|~^^^^^^^^^^^^050901&010501&L||||||||||| 200258423|~~~||||||||||||||||||||||||20030508||||||954|| MRG|46619288^^^L^ASSIPCA~MRCMRC75D21I403M^^^N^CODFISC~261055503^^^060^CODSAN~STP0 501160000005^^^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^A01|SI030000000000095400|P|2.03 PID||261055502^^^106|9911111^^^L^ASSIPCA~9911111^^^060^CODSAN|| GDS0^GDS0^^^^^L~GDS0MAIDEN^^^^^^M||19750421|M|||VIA CASARSA,82^ZOPPOLA^^PN^33081^^L^093051~,^^^^33081^^C^||604582||||||261055501 PV1||O|ASSLOC1^ROOM20^B2^^^^^||||ATTEN1|REF1||HOSP||||||VIP|ADMDOC||9911119| ~~~||||||||||||||||||||||||20030508||||||954||

CNXR010 / 3

Reception of patient demographics

V03.11

Page 20/21

Confidential. This specification requires an end user agreement

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.

CNXR010 / 3

Reception of patient demographics

V03.11

Page 21/21

Confidential. This specification requires an end user agreement