Académique Documents
Professionnel Documents
Culture Documents
11
V02.01
This interface specification is confidential and is strictly reserved for communication with a Hospital Information System. An End User Agreement containing the text on the final page of the present document must be agreed by the Customer (End User). This interface specification is for the exclusive use of sites covered by an End User Agreement. Use of this interface specification implies full acceptance of the terms and conditions of the End User Agreement included hereafter.
Table of contents
Technical pre-requisites 4 References 4
Program identification 4
Presentation 5
Communication diagram 5 Management of order cancelation or duplicate order message (Step 4 in the above diagram) 6
Connection sheet 18
Segment descriptions 20
MSH - Message Header Segment 20 EVN - Event type segment 21 PID - Patient identification segment 21 PV1 - Patient visit information 21 ORC - Common order Segment 21 OBR - observation request segment 23 OBX - observation / result 24 General constraints 25
Page 2/27
V02.01 HL7: Order Reception Confidential. This specification requires an end user agreement.
CNXR011 / 3
Connection sheet
V02.01.h
CNXR011 / 3
HL7: Order Reception V02.01 Confidential. This specification requires an end user agreement.
Page 3/27
Connection sheet
Technical pre-requisites
The connection for Order Reception (in HL7 2.4 / TCP-IP Socket) must be installed on a computer connected to the network 24 hours/day and 7 days/week (computer on which is installed the connection service). The computer must be installed with at least Windows 2000 or XP and must be conform to the recommendations specified in the Description of System components document, available on our website (www.technidata-web.com).
References
Reference number of HL7 standard (High Level Protocol): Date of this standard: Reference number of HL7 standard (Low Level Protocol) Date of this standard: High Level protocol HL7 2.4 Chapter 4 Order Entry November 2000 Low Level protocol HL7 2.3 Appendix C Lower Layer Protocols June 1998
Program identification
Application DLL: TDCnxAppWRH.DLL (Patients \ Order \ Results processing). Protocol DLL: TDCnxProtoHISADT.DLL (HL7 Low Level Protocol (Socket)) Format DLL: TDCnxFormHL7.DLL (HL7 High Level Protocol) Transport DLL: TDCnxTransTCPIPSocket.DLL (TCP-IP Socket Transport if TCP-IP Socket transport)
Page 4/27
V02.01 HL7: Order Reception Confidential. This specification requires an end user agreement.
CNXR011 / 3
Connection sheet
Presentation
This document describes the rules for reception of Order Entry messages (ORM messages) transmitted from a HOST via: - HL7, for the high-level protocol and, - TCP/IP socket. This description is based on the principles given by the HL7 Appendix C Lower Layer Protocols chapter. The generic rules that apply to all messages and the specific messages to be exchanged among certain applications can be found in the HL7 documentation. HL7protocol (Health Level Seven) objective is to provide standards relative to the structure of the information to be exchanged between multiple healthcare information systems, such as laboratories, radiology. The referenced high-level protocol is the HL7 version 2.4 (Standard specification for transferring clinical observations between independent computer systems) and the aim of this document is to present the mechanisms of that protocol implemented for receiving order on the management database.
Communication diagram
CNXR011 / 3
HL7: Order Reception V02.01 Confidential. This specification requires an end user agreement.
Page 5/27
Connection sheet
Page 6/27
V02.01 HL7: Order Reception Confidential. This specification requires an end user agreement.
CNXR011 / 3
Connection sheet
Transmission diagram
After the connection between the client and the server connection task, data are sent to the server by the client.
Host Information System (Client) Connection (Server)
Connection phase between the client and the server: Socket creation, establishment of the connection etc (cf : Information exchange description)
<SB>tvv<CR>ddddcccccxxx<EB><CR>
> <
Data block sent by the server with a HL7 ACK message embedded
Data block sent by the client with an HL7 ADT (patient administration) embedded message. After control of the correct data transfer (physical integrity), the HL7 message is parsed and managed. Depending on the result of these processes, an HL7 ACK message is sent with the error code in case of problem. <SB>tvv<CR>ddddcccccxxx<EB><CR> "dddd" contains the different HL7 messages composing the logical acknowledgement (MSH, MSA and ERR segments).
It is up to the client system to close the connection upon reception of the Acknowledgement
Connection phase between the client and the server: Socket creation, establishment of the connection etc (cf : Information exchange description)
<SB>tvv<CR>ddddcccccxxx<EB><CR>
> <
Data block sent by the server with a physical NAK message embedded into it (character 'C')
Data block sent by the client with an HL7 ADT (Patient administration)message embedded. On the physical integrity control, a wrong block format has been detected. A special data block is sent (NAK block). <SB>Nvv<CR>C000EBxxx<EB><CR> Negative physical acknowledgement sent by the connection if something is wrong on the physical transmission (wrong checksum, wrong count of characters)
It is up to the client to send the data block back or to discard it and to execute its own error handling routine
<SB>tvv<CR>ddddcccccxxx<EB><CR>
>
Data block sent by the server with a HL7 ACK message embedded into it
<
Data block sent by the client with an HL7 ADT (Patient administration)message embedded into it. After control of the correct data transfer (physical integrity), the HL7 message is parsed and managed. Depending on the result of these processes, an HL7 ACK message is sent with the error code in case of problem or without error code if all is correct. <SB>tvv<CR>ddddcccccxxx<EB><CR> "dddd" contains the different HL7 messages composing the logical acknowledgement (MSH, MSA and ERR segments).
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 (NAK is used at low level protocol, instead of Nack used at high level protocol). Both block types have the same format: <SB>tvv<CR>ddddcccccxxx<EB><CR> Blocks consist of the following fields: <SB> = Start Block character (1 byte). Configurable on site specific basis. Unless there is a conflict, the value should be ASCII <VT>, i.e. <0x0B>. This should not be confused with the SOH or STX ASCII characters. This character must equal the one configured as "Start of block character" in the device dictionary. Block Type (1 byte). "D" = Data block "N" = NAK block Protocol ID (2 bytes). Characters "24" for this version. Carriage Return (1 byte). The ASCII carriage return character, i.e. <0x0D>. Data (variable number of bytes). In a data block, it corresponds to the data content of the block. The data can contain any displayable ASCII characters and the carriage return character, <CR>. Carriage returns that are not part of the HL7 message may be inserted as described in "Carriage Return Stuffing." In a NAK block, this field contains a 1-byte reason code as follows: 'C' - character count wrong in previous data block received 'X' - checksum wrong in previous data block received 'B' - data too long for input buffer in previous block received 'G' - Error not covered elsewhere. ccccc = Block Size (5 bytes). Character count of all characters so far in the data block up to and including the data last character. For this protocol version, it corresponds to 5 + the size of the "dddd" field. Note: HL7 message ends with a <CR> character. This character is considered as part of the data. Checksum (3 bytes). Exclusive-OR checksum of all characters in the block up to and including the data last character. The checksum is expressed as a decimal number in three ASCII digits. If the value of this field is 999, the checksum should not be computed. Processing will proceed as if it were correct. This feature is used for applications where the messages will be translated from one character set to another during transmission. The "Checksum type" parameter in the device dictionary must be set to "Checksum for HL7 low layer protocol".
t=
vv = <CR> = dddd =
xxx =
Page 8/27
V02.01 HL7: Order Reception Confidential. This specification requires an end user agreement.
CNXR011 / 3
Connection sheet <EB> = End Block character (1 byte). Configurable according to the site. Unless there is a conflict, the value should be ASCII <FS>, i.e. <0x1C>. This should not be confused with the ETX or EOT ASCII characters. This character must equal the one defined as "End of block character" parameter in the Device dictionary. Carriage Return (1 byte). The ASCII carriage return character, i.e., <0x0D>.
<CR> =
<CR> =
CNXR011 / 3
HL7: Order Reception V02.01 Confidential. This specification requires an end user agreement.
Page 9/27
Connection sheet
Pre-requisites and sequence of operations (see also "Example of definition for TCP/IP socket" paragraph further in the document)
In order for the TCP/IP socket low-level protocol to work properly, several parameters must be set: 1. The machine on which the server will be created, must be declared as the "recipient's network address" (it can be the network name or the dotted address). 2. The port the server will be listening to is declared as the listening port. 3. The transmission mode is set to Mono client server transmission mode. 4. The connection (Communication engine) has to be started and listening to the configured port. 5. At this time one and only one simultaneous connection will be accepted by the server. After being allowed to access to the server, the client can send its data blocks through the socket and it can read answers back. 6. When it is finished, the client disconnects.
* * *
Page 10/27
V02.01 HL7: Order Reception Confidential. This specification requires an end user agreement.
CNXR011 / 3
Connection sheet
Installation procedure
The Communication engine must be installed with a Client instance. When the connection selection screen is displayed: 1. Select HL7: Order reception by left-clicking on the corresponding line 2. Choose This feature will be installed on local hard drive option.
Implementation
To implement this connection, a number of parameter settings must be performed at different levels, as listed hereafter: - Definition of Labconf parameters on the management database - Device dictionary the management database - Activation of the service specified in the Device dictionary
"Labconf" parameters
You must verify some "Labconf" parameters on the management database before starting the implementation. Make sure that the lengths of the following fields are the same as on the production database (Parameter setting zone GST block): These parameters are: - Patient number length - Alternate patient number length - Hospitalization number length - Reduced access number length - Database name (*) * Database name is the logical name of the database. It is used both by the Web module and this connection. It must be the same for both. Refer to the Web module parameters to verify it (Administration tool, File menu, Databases item, Name field.
CNXR011 / 3
HL7: Order Reception V02.01 Confidential. This specification requires an end user agreement.
Page 11/27
Connection sheet
Device dictionary
This step consists in defining and customizing the parameters used for the reception of orders (new or updated information about orders). This connection must be defined as a device and consequently it must be defined in the Device dictionary. Create a new device. From the TD Control panel, select System Setup (Dictionaries), General dictionaries then Device. In the menu bar, click on the + sign. Name Code Device type Service Name Abbreviated text Full text Protocol Format Transport Application Properties Value TDCnx_InstanceName_Computernam e Comment name of the computer where is installed the service.
HL7 low layer Protocol (Socket) HL7 format TCP-IP socket transport Patients/Order/Results processing More...
The Protocol, Transport, Format and Application parameters give the user-friendly names of the different DLLs used for the connection. These DLLs are automatically installed by the setup program. Once you reach this step, you must click the OK button to update the Properties. The Properties parameters are used for defining the parameters related to a type of flow. Three types of flow must be defined: 1. All (displayed by default). 2. Patient demographic data reception flow. 3. Order reception
Value If this parameter is not defined here, the same parameter defined in the Laboratory configuration is applied.
1000
Comment
1
C:\technidata\spy.txt Yes
Do not modify. Once the installation is finished and you have checked it runs well, set it to No. Three level of traces are available: minimum, regular, maximum
Maximum
Page 12/27
V02.01 HL7: Order Reception Confidential. This specification requires an end user agreement.
CNXR011 / 3
For example
The Transport section contains the different parameters used for defining the characteristics of the TCP-IP. Name Checksum type End of block character Listening port Message time-out Value Checksum applied on the socket frame. Last character of the socket (<1C> in the definition of the socket frame) Input port Period of time (in seconds) during which data is expected on the socket. After this time, the server considers the link broken. Output port Comment Must be set to HL7 Low Layer Protocol Do not modify 8102 for example 30 for example
Outgoing port
When selecting a port (either listening or outgoing), make sure that the port is not already used by another application. Name
Protocol version
Value 23 IP address or logical name of the receiver IP address or logical name of the sender. First character of the socket (<0B> in the definition of the socket frame)
Hybrid/Minimal
Do not modify To modify on site Minimal for Keane Must be set to Mono client server transmission mode
Transmission mode File location Chameleon file path Input processed folder
Defines the mode used by the socket connection (client/server, Mono/Multi client). Name of the path for the hl7.vmd Chameleon file. c:\technidata
For example
Value
Comment
The General section defines how the test order data received in the HL7 message are managed: These test order data can be: CNXR011 / 3 HL7: Order Reception V02.01 Confidential. This specification requires an end user agreement. Page 13/27
Connection sheet only set in the Management database, only forwarded to another device, for this flow only demographic data is forwarded (via a FTP transfer of ASTM 1238 files to send the demographic data to the Production database for example), set in the Management database and forwarded to another device. set in the Management database and transmitted to laboratory by (through a file transfer of ASTM 1238 files by the "rectube" process of the Web module).
"Set in Management database" and "forwarded to another device" possibilities are both managed by the Update local database and Output devices parameters. If Output devices is filled in with the connection identification used to ensure the patient data transfer to another device, a job is created to enable the patient data transfer through the customized connection. Name Stream active Accept assigned message number (NA) Automatic activation for immediate orders Automatic activation for routine orders Automatic activation for urgent orders Value Yes, activated flow. No, not activated flow Yes, activated flow Comment Set Yes to enable the reception of the Number Assigned by the Host, in answer to a Placer order number query message from the Laboratory Information System
Yes, activated No, not activated Yes, activated No, not activated Yes, activated No, not activated
Numbering of order: This parameter is used to define how to create the Full Access Number. If the Host sends this number (numbering mechanism should be identical to the numbering supported by the Management database), the automatic number mechanism is ignored. Name Automatic number for orders Value Select the counter which are used for create the Full Access Number Comment
The counter must be previously declared and set up on TDNTPanel. Refer to the related documentation to create this counter. When defining the counter, make sure that the range of numbers is reserved for order creation on the Management database It is possible to transmit test order automatically to the production database by ASTM 1238. The following parameters are used to activate automatic transmission of test order to the production database or another H.I.S. Name Exam grouping Exam grouping timeframe (minutes) Output devices Processing type Process order cancelation or duplicate order message Value Comment Yes (to enable grouping several tests into a single order) 10 See Note 1 Default value = 35 [] Set to HL7 device used to Opens a window to select the Device send data to HIS: and the data flow it is used for HL7HIS / Order sending Must be set to Test Orders. Yes/No See Note 4 Default value = Yes
Page 14/27
V02.01 HL7: Order Reception Confidential. This specification requires an end user agreement.
CNXR011 / 3
Connection sheet Sample reception DLL file path Update local database Format Collection source parameter code Topography parameter code Mapping Coded texts Doctors Locations Tests Titles Path to access to TD-Web Rectube process (TDCollectionReception.dll). Yes Code of the complementary parameter used with results received in OBR-15.1 Code of the complementary parameter used with results received in OBR-15.4 Code of the coding system used to map coded text codes. See Note 3. Code of the coding system used to map doctor codes. See Note 3. Code of the coding system used to map location codes. See Note 3. Code of the coding system used to map test codes. See Note 3. Code of the coding system used to map title codes. See Note 3. See (*)
See Note 2 To define if needed by the H.I.S. See Note 2 To define if needed by the H.I.S. Create/select the code of a coding system. Create/select the code of a coding system. Create/select the code of a coding system. Create/select the code of a coding system. Create/select the code of a coding system.
Note 1: An algorithm is used to group together several tests into a same order. This algorithm respects the following rules: -Same patient and same hospital stay for the test order -The location of the new test should be the same as for the other tests -The reference collection date/time corresponds to the scheduled collection date/time of the first received test ( with +/- n minutes definable in the Exam grouping timeframe parameter. Note 2: Both data will be stored as coded text type results and are associated with two complementary parameters. These complementary parameters are used to store the corresponding information. Note 3: Mapping is used to create correspondences between the Management database and Host systems code values (local codes and alternate codes). You can find the description of "Mapping alternate codes" in the Technical guide online help under Installation book. Note 4: This property is used to enable (answer Yes) or disable (answer No) the processing of order cancelation or duplicate order message. To enable the transmission of order cancelation or duplicate order messages to the H.I.S, answer Yes and specify an Output device. The Output device used should be the one used for the connection Transmission of Orders (CNXR023). If this property is enabled and no Output device is associated with the order reception device the task created by the received message will be set to the error status and a message will ask the user to specify an output device.
Connection sheet
Use the Windows Service manager to start the TDConnexion service. The connection service appears under the name "TDCnx_InstanceName".
Page 16/27
V02.01 HL7: Order Reception Confidential. This specification requires an end user agreement.
CNXR011 / 3
Connection sheet
CNXR011 / 3
HL7: Order Reception V02.01 Confidential. This specification requires an end user agreement.
Page 17/27
Connection sheet 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.
Acknowledgement
If no problem occurs during the management of the message, a positive logical acknowledgement is sent to the Host and the created job is set to the "Completed" status. In the positive logical acknowledgement sent by the connection, the MSA-1 field Acknowledgment code is set to "AA" (application acknowledgement Accept) and the ERR-1 field, subfield 4, "Error code" is set to the "0" error code. 0 Message accepted Success. Optional, as the AA conveys success. Used for systems that must always return a status code.
During the management of the ADT (Patient administration) message , some errors can occur. In such cases, the created job is set to the "Error" status.
Incident management
Case 1: The connection has detected X differences between the demographic data of the patient in the management database and the transmitted demographic data (the controls on the demographic data are done on the first name and last name, the maiden name, the sex and the birth date of the patient). X is greater than the authorized number of differences customized with the Patient differences parameter. In such a case, the OMG / OML / ORM message is not integrated in the management database and a negative logical acknowledgement is sent to the host. In the negative logical acknowledgement sent by the connection, the MSA-1 field Acknowledgment code is set to "AR" (application acknowledgement Reject) and the ERR-1 field, subfield 4, "Error code" is set to the "207" error code, and the MSA-3 field is filled in with the string "A catchall for internal errors not explicitly covered by other codes". 207 Application internal error A catchall for internal errors not explicitly covered by other codes.
Case 2: The previous control is correct but the connection has detected two different patients with the same "Alternate number" in the management database. In such a case, the OMG / OML / ORM message is not integrated in the management database and a negative logical acknowledgement is sent to the host. In the negative logical acknowledgement sent by the connection, the MSA-1 field Acknowledgment code is set to "AR" (application acknowledgement Reject) and the ERR-1 field, subfield 4, "Error code" and the "ERR-1" fields are set to the error code "205". The MSA-3 field is filled in with the string "The ID of the patient, order, etc., already exists". 205 Duplicate key identifier The ID of the patient, order, etc., already exists. Used in response to addition transactions (Admit, New Order, etc.).
Case 3: The OMG / OML / ORM message sent by the Host cannot be properly parsed (problem on the HL7 structure). In such a case, the OMG / OML / ORM message is not integrated in the management database and a negative logical acknowledgement is sent to the Host. 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" Page 18/27 V02.01 HL7: Order Reception Confidential. This specification requires an end user agreement. CNXR011 / 3
Connection sheet and "ERR-1" fields are set to the error code "100". The MSA-3 field is filled in with the string The message segments were not in the proper order, or required segments are missing. 100 Segment sequence error The message segments were not in the proper order, or required segments are missing.
Case 4: The OMG / OML / ORM message sent by the Host is properly parsed and managed but the database is locked / not available or the patient / Prescription record to update is protected. In such a case, the OMG / OML / ORM message cannot be integrated in the management database and a negative logical acknowledgement is sent to the Host. In the negative logical acknowledgement sent by the connection, the MSA-1 field Acknowledgement code is set to "AR" (application acknowledgement Reject) and the ERR-1 field, subfield 4, "Error code" and "ERR-1" fields are set to the error code "206". The MSA-3 field is filled in with the string The transaction could not be performed at the application storage level. 206 Application record locked The transaction could not be performed at the application storage level, e.g. database locked.
Case 5: The test order message sent by the Host is properly parsed but some data are no correct, for example: - A test or an additional parameter is unknown - A test is not requestable - A test is duplicate - A results of type coded text is expected and the coded results is not defined In such a case, the test order message is partially integrated in the management database and a negative logical acknowledgement is sent to the Host. In the negative logical acknowledgement sent by the connection, the MSA-1 field Acknowledgment code is set to "AR" (application acknowledgement Reject) and the ERR-1 field, subfield 4, "Error code" and "ERR-1" fields are set to the "207" error code. The MSA-3 field is filled in with the string "A catchall for internal errors not explicitly covered by other codes (Test order : #XXXXXXXXXX)."XXXXXX corresponds to the access number or external order number if it is transmitted by the Host. 207 Application internal error A catchall for internal errors not explicitly covered by other codes.
Case 6: The update test order message sent by the Host is properly received but for this test order the corresponding specimen is already received in the laboratory. In such a case, the test order message cannot be integrated in the management database and a negative logical acknowledgement is sent to the Host. In the negative logical acknowledgement sent by the connection, the MSA-1 field Acknowledgment code is set to "AR" (application acknowledgement Reject) and the ERR-1 field, subfield 4, "Error code" and "ERR-1" fields are set to the "207" error code. The MSA-3 field is filled in with the string " A catchall for internal errors not explicitly covered by other codes (Specimen received for test order: #XXXXXXXXXX)." XXXXXX corresponds to the access number or external order number if it is transmitted by the Host. 207 Application internal error A catchall for internal errors not explicitly covered by other codes.
CNXR011 / 3
HL7: Order Reception V02.01 Confidential. This specification requires an end user agreement.
Page 19/27
Connection sheet
Page 20/27
V02.01 HL7: Order Reception Confidential. This specification requires an end user agreement.
CNXR011 / 3
Connection sheet
CNXR011 / 3
HL7: Order Reception V02.01 Confidential. This specification requires an end user agreement.
Connection sheet SEQ 24 25 LEN 250 250 DT XAD CWE ELEMENT NAME Ordering Provider Address Order Status Modifier On Communication Engine Not Used Not Used
Page 22/27
V02.01 HL7: Order Reception Confidential. This specification requires an end user agreement.
CNXR011 / 3
Connection sheet
CNXR011 / 3
HL7: Order Reception V02.01 Confidential. This specification requires an end user agreement.
Page 23/27
Connection sheet
OBR - 27 Quantity/Timing
The communication engine only processes the 6th subfield (priority). The values that are processed are: S (Stat), A (ASAP), R (Routine). Value P (preoperative) is processed as R. Value C (Call back) is processed as S. Value T (Timing Critical) is processed as S.
Page 24/27
V02.01 HL7: Order Reception Confidential. This specification requires an end user agreement.
CNXR011 / 3
Connection sheet
Type of result. For additional parameter, the Communication Engine supports the following values: CE for Coded Text; DT for Date; NM for Numeric; TX for free text (limited to 2000 char.); and ST for String Data, SN for structured numeric. Processing ST String data result: String Data result is stored as "Limit" result type if the result is in the format <xxxx or >xxxx; it is stored as Alphabetical string if the result is no more than 4 characters long; it is stored as a free text in all other cases. Processing DT Date : Only the complete date is accepted by the connection (YYYYMMDD). The partial date is not integrated correctly. Processing NM Numeric : The decimal separator must be .. Processing SN Structured numeric : Structured Numeric result is stored as "Limit" result type if the result is in the format <^xxxx or >^xxxx and xxxx is numeric, else it is stored as a free text.
General constraints
The External Order Number is limited to 9 numeric characters. This number must be unique for a test order. The Full Access Number must be unique for a test order. A HL7 test order message contains only a message and a test order. If the specimen identification and collection are managed by the Host, the specimen numbering mechanism should be identical to the specimen numbering supported by the production database. Only the first ORC segment of each order is processed. In every segment ORC External order number or/and Full Access Number is repeated as the first one. The requested test (field OBR-4) must be a Single test or a Combined test. Profile cannot be used as they are just a facility for manual order entry and the code of a profile cannot be returned to the Host with the results. If there is a need to transmit additional parameters for a requested test, each result of these additional parameters should be transmitted in dedicated OBX record that immediately follows the OBR segment of the requested test.
CNXR011 / 3
HL7: Order Reception V02.01 Confidential. This specification requires an end user agreement.
Page 25/27
Connection sheet
Page 26/27
V02.01 HL7: Order Reception Confidential. This specification requires an end user agreement.
CNXR011 / 3
TECHNIDATA
M E D I C A L S O F T W A R E E N G I N E E R I N G
END USER AGREEMENT FOR CONNECTION The interface specification described in the attached Connection Sheet # CNXR011 "HL7: Order Reception" is confidential and is strictly reserved for communication with a Hospital Information System. An End User Agreement containing the text hereunder must be agreed by the Customer (End User). The interface specification "Connection Sheet # CNXR011" is for the exclusive use of sites covered by an End User Agreement. Use of the interface specification "Connection Sheet # CNXR011" implies full acceptance of the terms and conditions of the End User Agreement hereunder.
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.