Académique Documents
Professionnel Documents
Culture Documents
10
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 4 References 4
Program identification 4
Presentation 5
Communication diagram 5
Segment descriptions 24
MSH - Message Header Segment 24 EVN - Event type segment 25 PID - Patient identifying segment 25 CNXR010 / 3 Reception of patient demographics V03.11 Page 1/38
Connection sheet PV1 - Patient visit information 30 GT1 - Guarantor segment 33 IN1 - Insurance segment 35
CNXR010 / 3
V03.11
Page 2/38
Connection sheet
V01.54 / 3
V03.11 / 3
CNXR010 / 3
V03.11
Page 3/38
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
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
CNXR010 / 3
V03.11
Page 4/38
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
V03.11
Page 5/38
Connection sheet
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).
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).
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
V03.11
Page 7/38
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> =
<CR> =
CNXR010 / 3
V03.11
Page 8/38
Connection sheet
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.
* * *
CNXR010 / 3
V03.11
Page 9/38
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
HL7 low layer Protocol (Socket) HL7 format Patients/Orders/Results TCP-IP socket transport Patients/Orders/Results processing ...
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
Value If this parameter is not defined here, the same parameter defined in the Laboratory configuration is applied.
1000
Comment
1 3
C:\technidata\spy.txt Yes
TDNTServer counters used to produce control ID of HL7 message Do not modify. Once the installation is finished and you have checked it runs well, set it to No. Three level of traces available (maximum, regular, minimum).
Maximum
Format
HL7 version
No
Do not modify.
The Transport section contains the different parameters used for defining the characteristics of the TCP-IP. Counter length for files to handle 5 FTP connection Timeout Default value: 10. Do not modify. FTP local temporary directory Local directory where the FTP files To customize on site. are stored. Default value: c:\tmp FTP password Password associated with the ftp To customize on site. user FTP remote host Server. name.here To modify on site. FTP remote output directory Default value:./tmp To customize on site. FTP Server Port 21 FTP user ID Name of the ftp user. To customize on site. Default value: ftp Generated file extension RES Generated file prefix TDR Internal counter 0 Message timeout Default value: 5. Do not modify. Remote input directory for FTP / files Semaphore file extension for .ok transmitted files File location Chameleon file path Name of the directory where is stored the To modify on site if "hl7.vmd" Chameleon file. needed.
CNXR010 / 3
V03.11
Page 11/38
Connection sheet
Comment
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 Stream active Hospitalization creation and update Management of billing information Value Default value: No. Yes Yes/No Comment Must be set to Yes Do not modify 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 Prefix of beneficiary number on the Host Prefix of hospitalization number on the host Prefix of patient number on the host
Name of the device for demographic information transmission. Prefix applied to the beneficiary identification, e.g. BEN. Prefix applied to the hospitalization identification, e.g. HOS. Prefix applied to the patient identification, e.g. PAT.
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 Update local database Value Default value: No (the Management database is not updated with the demographic data). Comment Must be set to Yes (the Management database is updated with the demographic data). Page 12/38
Connection sheet Patient differences Update Patient reference (Doc/Loc) Default value: 4 differences. 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. To modify on site if needed 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 Mapping Doctors Financial class Value Code of the coding system used to map doctor codes. (1). Code of the Financial class provided by the HIS in the ADT message and automatically recovered. (2) Code of the Hospital Service provided by the HIS in the ADT message and automatically recovered. (2) Code of the coding system used to map location codes. (1). Code of the Patient class provided by the HIS in the ADT message and automatically recovered. (2) Code of the coding system used to map title codes. (1). Comment Create/select the code of a coding system. Select Autocreate to have the financial class field automatically fed by the communication process.(3) Select Autocreate to have the hospital service class field automatically fed by the communication process. (3) Create/select the code of a coding system. Select Autocreate to have the patient class field automatically fed by the communication process.(3) Create/select the code of a coding system.
Hospital Service
Titles
(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. (2) Up to now, no coding system is available and there is no user interface for those dictionaries. Only automatic creation is available.
CNXR010 / 3
V03.11
Page 13/38
Connection sheet (3) The elements of the dictionaries are not updated when the latter are modified. Only the creation of new items are taken into account.
CNXR010 / 3
V03.11
Page 14/38
Connection sheet
Specifying the port for a service You can also specify the port to be used by the service: In regedit, go to HKLM\SYSTEM\CurrentControlSet\Services\<Service name>-<instance name> Then modify the value of Image path, adding the port number at the end of the line. Example: c:\technidata\ProductClient-Appli1\servcnx.exe TDCnx1 8011
CNXR010 / 3
V03.11
Page 15/38
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
V03.11
Page 16/38
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
V03.11
Page 17/38
Connection sheet
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
V03.11
Page 18/38
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
V03.11
Page 19/38
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)
CNXR010 / 3
V03.11
Page 20/38
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.
CNXR010 / 3
V03.11
Page 21/38
Connection sheet To manage events as merge errors (Actions D), proceed as follows: 1) Remove the concerned events from the Action C list 2) 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 list 2) Add them to the CHAMELEON list for action D events
CNXR010 / 3
V03.11
Page 22/38
Connection sheet
CNXR010 / 3
V03.11
Page 23/38
Connection sheet
CNXR010 / 3
V03.11
Page 24/38
Connection sheet
12 13
4 250
IS XTN
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
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
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 :
CNXR010 / 3
V03.11
Page 26/38
Connection sheet
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. NAME Possible 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):
CNXR010 / 3
V03.11
Page 27/38
Connection sheet
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.
CNXR010 / 3
V03.11
Page 28/38
Connection sheet
CNXR010 / 3
V03.11
Page 29/38
Connection sheet
Connection sheet
In the Management database, this information is stored in the PATIENT table, so each visit updates the patient information.
Connection sheet 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.
CNXR010 / 3
V03.11
Page 32/38
Connection sheet This option must not be used without the consent of TECHNIDATA.
CNXR010 / 3
V03.11
Page 33/38
Connection sheet SEQ 47 48 49 50 51 52 53 54 55 LEN 250 3 20 20 250 2 2 50 250 DT CE IS ST JCC XON IS IS FC CE ELEMENT NAME Contact Reason Contact Relationship Job Title Job Code/Class Guarantor Employers Organization Name Handicap Job Status Guarantor Financial Class Guarantor Race On Communication Engine Not Not Not Not Not Not Not Not Not Used Used Used Used Used Used Used Used Used
CNXR010 / 3
V03.11
Page 34/38
Connection sheet This option must not be used without the consent of TECHNIDATA.
Connection sheet SEQ 52 53 LEN 250 2 DT ST IS ELEMENT NAME Insureds Birth Place VIP Indicator On Communication Engine Not Used 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.
CNXR010 / 3
V03.11
Page 36/38
Connection sheet
CNXR010 / 3
V03.11
Page 37/38
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.
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
V03.11
Page 38/38