HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i
Transcript of HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i
ImagePilot HL7 Conformance Statement
i
Revision History
Date Version Description
August 28, 2009 Rev. 1.0 April 1, 2010 Rev. 1.1 Values that can be assigned to “ORC-1 Order Control” are added.
November 26, 2010 Rev. 1.2 SIU type message receiving and ORU type message sending are added.
May 12, 2011 Rev. 1.3 MDM type message sending is added.
July 10, 2012 Rev. 1.4 Combination of OBX-2 and OBX-5 is added to “5.9 OBX – OBSERVATION RESULT SEGMENT.”
Notice: Specifications in this document are subject to change without notice. 2009, Konica Minolta Medical & Graphic ,Inc. All rights reserved. Printed in JPN. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form, by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of Konica Minolta Medical & Graphic, Inc.
ImagePilot HL7 Conformance Statement
ii
Table of Contents
1. INTRODUCTION ............................................................................................................................................. 1
2. OVERVIEW ...................................................................................................................................................... 1
3. IMPLEMENTATION MODEL......................................................................................................................... 2
3.1 APPLICATION DATA FLOW .................................................................................................................................2 3.2 HL7 MESSAGE AND ITS COMPONENTS.................................................................................................................2 3.3 FIELDS AND FIELD ATTRIBUTES..........................................................................................................................3
4. SUPPORTED MESSAGE TYPES AND EVENT TYPES ................................................................................. 4
4.1 ADT TYPE MESSAGES .......................................................................................................................................4 4.2 ORM TYPE MESSAGES ......................................................................................................................................4 4.3 SIU TYPE MESSAGES.........................................................................................................................................4 4.4 ORU TYPE MESSAGES.......................................................................................................................................5 4.5 MDM TYPE MESSAGES .....................................................................................................................................5
5. MESSAGE CONSTRUCTION RULES ............................................................................................................ 6
5.1 MESSAGE DELIMITERS.......................................................................................................................................6 5.2 MSH – MESSAGE HEADER SEGMENT ..................................................................................................................6 5.3 EVN – EVENT TYPE SEGMENT ............................................................................................................................7 5.4 PID – PATIENT IDENTIFICATION SEGMENT...........................................................................................................8 5.5 PV1 – PATIENT VISIT SEGMENT ..........................................................................................................................9 5.6 MRG – MERGE PATIENT SEGMENT .....................................................................................................................9 5.7 ORC – COMMON ORDER SEGMENT ...................................................................................................................10 5.8 OBR – OBSERVATION REQUEST SEGMENT.........................................................................................................11 5.9 OBX – OBSERVATION RESULT SEGMENT ..........................................................................................................12 5.10 ZDS – STUDY INSTANCE UID SEGMENT ............................................................................................................14 5.11 SCH – SCHEDULE ACTIVITY INFORMATION SEGMENT .............................................................................15 5.12 TXA-TRANSCRIPTION DOCUMENT HEADER SEGMENT.............................................................................16
6. COMMUNICATIONS ENVIRONMENT ....................................................................................................... 18
6.1 LOWER LEVEL PROTOCOL................................................................................................................................18 6.2 FAULT TOLERANCE .........................................................................................................................................18
ImagePilot HL7 Conformance Statement
1
1. Introduction
This document describes the electronic data exchange of the ImagePilot HL7 compliant interfaces. It covers field mappings from ImagePilot software modules to ANSI/HL7 standard Version 2.3 and implementation-specific message creation and processing rules.
2. Overview
The Health Level Seven Standard (HL7) is used for data exchange between healthcare computer systems. It does not require a specific computer operating system, programming language or communication protocol for its implementation. HL7's mission is: "To provide (global) standards for the exchange, management and integration of data that supports clinical patient care and the management, delivery and evaluation of healthcare services. Specifically, to create flexible, cost effective approaches, standards, guidelines, methodologies, and enable healthcare information system interoperability and sharing of electronic health records."
ImagePilot HL7 Conformance Statement
2
3. Implementation Model
ImagePilot receives message from external EMR/PMS/HIS/RIS, saves information to internal database about HL7. Stored data will be used in ImagePilot later. TCP/IP communication protocol is being used in ImagePilot implementation.
3.1 APPLICATION DATA FLOW
3.1.1 Receive HL7 message
ADT, ORM, SIU are supported.
3.1.2 Send HL7 message
ORU, MDM are supported.
3.2 HL7 MESSAGE AND ITS COMPONENTS
3.2.1 Message
Message is the atomic unit of data transferred between systems. It is comprised of a group of segments in a defined sequence. The message type defines its purpose. For example, ADT type message is used to transmit Patient Administration data.
EMR/PMS/HIS/RIS
ImagePilot
HL7 Service
Data base
1. Request sending
2. Response Acknowledge
EMR/PMS/HIS/RIS
ImagePilot
HL7 Service
1. Request sending
2. Response Acknowledge
ImagePilot HL7 Conformance Statement
3
3.2.2 Segment
Segment is a logical grouping of data fields. Segments may be required or optional. They may be allowed to repeat. Each segment is given a name. For example: Message Header (MSH), Event Type (EVN), Patient Identification (PID), etc.
3.2.3 Field
A field is a string of characters. Null (“”) is a possible value. It is different than omitting the field. Omitted fields keep data value with no change, while null fields reset existing data to null.
3.3 FIELDS AND FIELD ATTRIBUTES
Each field has the following attributes specified: SEQ - Position LEN - Maximum length DT - Data Type OPT - Optionality (R, O, C, X, B) The designations
R - required
O - optional
C - conditional on the trigger event or on some other field(s). The field definitions following the segment attribute table should specify the algorithm that defines the conditionality for this field.
X - not used with this trigger event
B - left in for backward compatibility with previous versions of HL7. The field definitions following the segment attribute table should denote the optionality of the field for prior versions.
Name - ELEMENT NAME
ImagePilot Value - Contents of the field in a typical ImagePilot data exchange
Fields are further divided into components and subcomponents and some fields may be repeated a number of times.
The ImagePilot message construction rules follow the HL7 Version 2.3 recommendations. For a more detailed description of attributes, please refer to the HL7 Standard.
ImagePilot HL7 Conformance Statement
4
4. Supported Message Types and Event Types
ImagePilot data exchange interfaces support different message types and events, all in conformance with ANSI/HL7 standard Version 2.3.
4.1 ADT TYPE MESSAGES
The ADT message is used to send schedule request or appointment. ImagePilot software modules use ADT messages for import and update of patient demographic data. The following table lists the events supported by the ImagePilot ADT interface.
Event Types Supported by ImagePilot ADT Interface
VALUE DESCRIPTION
A01 ADT/ACK - Admit/visit notification
A04 ADT/ACK - Register a patient
A05 ADT/ACK - Pre-admit a patient
A08 ADT/ACK - Update patient information
A40 ADT/ACK - Merge patient information – Patient Identifier List
4.2 ORM TYPE MESSAGES
The ORM message is used to transfer radiology order information. ImagePilot software modules use ORM messages for import and update of procedure order data. The following table lists the events supported by the ImagePilot ORM interface. The ZDS segment by IHE is also supported.
Event Types Supported by ImagePilot ORM Interface
VALUE DESCRIPTION
O01 ORM/ACK - Order message
4.3 SIU TYPE MESSAGES
The SIU message is used to send schedule request or appointment. ImagePilot software modules use SIU messages for import and update of patient demographic data. The following table lists the events supported by the ImagePilot SIU interface.
Event Types Supported by ImagePilot SIU Interface
VALUE DESCRIPTION
S12 SIU/ACK - Notification of new appointment booking
S14 SIU/ACK - Notification of appointment modification
S15 SIU/ACK - Notification of appointment cancellation
ImagePilot HL7 Conformance Statement
5
4.4 ORU TYPE MESSAGES
The ORU message is used to send observation reporting. ImagePilot software modules use ORU messages for sending link to image study information. The following table lists the events supported by the ImagePilot ORU interface.
Event Types Supported by ImagePilot ORU Interface
VALUE DESCRIPTION
R01 ORU/ACK - Unsolicited transmission of an observation message
4.5 MDM TYPE MESSAGES
The MDM message is used to send observation reporting. ImagePilot software modules use MDM messages for sending link to image study information. The following table lists the events supported by the ImagePilot MDM interface.
Event Types Supported by ImagePilot MDM Interface
VALUE DESCRIPTION
T02 MDM/ACK - Original document notification and content
ImagePilot HL7 Conformance Statement
6
5. Message Construction Rules
5.1 MESSAGE DELIMITERS
The ImagePilot interfaces follow HL7 Version 2.3 recommended message delimiters as follows:
Delimiter Suggested Value Usage
Segment Terminator <cr>
Hex 0D
Terminates a segment record. This value cannot be changed by implementors.
Field Separator | Separates two adjacent data fields within a segment. It also separates the segment ID from the first data field in each segment.
Component Separator ^ Separates adjacent components of data fields where allowed.
Subcomponent Separator & Separates adjacent subcomponents of data fields where allowed. If there are no subcomponents, this character may be omitted.
Repetition Separator ~ Separates multiple occurrences of a field where allowed.
Escape Character \ Escape character for use with any field represented by an ST, TX or FT data type, or for use with the data (fourth) component of the ED data type If no escape characters are used in a message, this character may be omitted. However, it must be present if subcomponents are used in the message.
5.2 MSH – MESSAGE HEADER SEGMENT
The Message Header Segment is used to convey intent, content, source, destination, and some specifics of the syntax of a message. The Message Header Segment is constructed as follows:
Message Header Segment (MSH) Attributes
SEQ LEN DT OPT ELEMENT NAME ImagePilot FIELD CONTENT
1 1 ST R Field Separator “|”
2 4 ST R Encoding Characters “^~\&”
3 180 HD R Sending Application ImagePilot
4 180 HD O Sending Facility
5 180 HD O Receiving Application
6 180 HD O Receiving Facility
7 26 TS O Date/Time Of Message YYYYMMDDHHMMSS
8 40 ST O Security
9 7 CM R Message Type Message Type^Event Code
10 20 ST R Message Control ID Unique number
11 3 PT R Processing ID P
12 60 VID R Version ID “2.3”
13 15 NM O Sequence Number
14 180 ST O Continuation Pointer
15 2 ID O Accept Acknowledgment Type
16 2 ID O Application Acknowledgment Type
ImagePilot HL7 Conformance Statement
7
17 2 ID O Country Code
18 16 ID O Character Set
19 60 CE O Principal Language Of Message
20 20 ID O Alternate Character Set Handling
Scheme
MSH field definitions MSH-1 Field Separator (ST) 00001
This field contains the separator between the segment ID and the first real field, MSH-2-encoding characters. As such it serves as the separator and defines the character to be used as a separator for the rest of the message. Recommended value is |, (ASCII 124).
MSH-2 Encoding Characters (ST) 00002
This field contains the four characters in the following order: the component separator, repetition separator, escape character, and subcomponent separator. Recommended values are ^~\&, (ASCII 94, 126, 92, and 38, respectively).
MSH-3 Sending Application (HD) 00003 This field uniquely identifies the sending application
MSH-9 Message Type (MSG) 00009
This field contains the message type, trigger event, and abstract message structure code for the message. The receiving system uses this field to recognize the data segments , and possibly, the application to which to route this message. Example: MSH|^~\&|IMAGE PILOT||7000||20040416135703||ADT^A04|AAAAAA|P|2.3
5.3 EVN – EVENT TYPE SEGMENT
The Event Type Segment is used to communicate necessary trigger event information to receiving applications. The Event Type Segment is constructed as follows:
Event Type Segment (EVN) Attributes
SEQ LEN DT OPT ELEMENT NAME ImagePilot FIELD CONTENT
1 3 ID B Event Type Code
2 24 DTM R Recorded Date/Time YYYYMMDDHHMMSS
3 24 DTM O Date/Time Planned Event
4 3 IS O Event Reason Code
5 250 XCN O Operator ID
6 24 DTM O Event Occurred
7 241 HD O Event Facility
ImagePilot HL7 Conformance Statement
8
EVN field definition EVN-2 Recorded Date/Time (TS) 00100
Most systems will default to the system date/time when the transaction was entered, but they should also permit an override.
Example: EVN||20090816102345
5.4 PID – PATIENT IDENTIFICATION SEGMENT
The Patient Identification Segment is used to convey patient identification information. It contains permanent patient identifying and demographic information. The Patient Identification Segment is constructed as follows:
Patient Identification Segment (PID) Attributes
SEQ LEN DT OPT ELEMENT NAME ImagePilot FIELD CONTENT
1 4 SI O Set ID - PID
2 20 CX B Patient ID
3 20 CX R Patient Identifier List Patient ID
4 20 CX B Alternate Patient ID - PID
5 48 XPN R Patient Name Patient Name
6 48 XPN O Mother’s Maiden Name
7 26 TS O Date/Time of Birth
8 1 IS O Sex
PID field definitions
PID-3 Patient ID (internal ID) (CX) 00106 This field contains the list of identifiers (one or more) used by the facility to uniquely identify a patient (e.g., medical record number, billing number, birth registry, national unique individual identifier, etc.).
PID-5 Patient Name (XPN) 00108
This data type includes multiple free text components. The sending system may send upper- and lowercase or all uppercase. The receiving system may convert to all uppercase if required. This field contains the legal name of the patient. Example: PID|||98999000||Henry^Jacobson
ImagePilot HL7 Conformance Statement
9
5.5 PV1 – PATIENT VISIT SEGMENT
The Patient Visit Segment is used by Registration/Patient Administration applications to communicate information on an account or visit-specific basis. The Message Header Segment is constructed as follows:
Patient Visit Segment (PV1) Attributes
SEQ LEN DT OPT ELEMENT NAME ImagePilot FIELD CONTENT
1 4 SI O Set ID –PV1
2 1 IS R Patient Class “I” or “O”
3 80 PL O Assigned Patient Location
PV1 field definitions PV1-2 Patient Class (IS) 00132
A common field used by systems to categorize patients by site. It does not have a consistent industry-wide definition. Subject to site-specific variations. Refer to user-defined table 0004 - patient class for suggested codes.
Example: PV1||O
5.6 MRG – MERGE PATIENT SEGMENT
The Merge Patient Segment provides receiving applications with information necessary to initiate the merging of patient data as well as groups of records. The Merge Patient Segment is constructed as follows:
Merge Patient Segment (MRG) Attributes
SEQ LEN DT OPT ELEMENT NAME ImagePilot FIELD CONTENT
1 250 CX R Prior Patient Identifier List Prior Patient ID
2 250 CX B Prior Alternate Patient ID
3 250 CX O Prior Patient Account Number
4 250 CX B Prior Patient ID
5 250 CX O Prior Visit Number
6 250 CX O Prior Alternate Visit ID
7 250 XPN O Prior Patient Name
MRG field definitions MRG-1 Prior Patient Identifier List (CX) 00211
This field contains the prior patient identifier list. This field contains a list of potential "old" numbers to match. Only one old number can be merged with one new number in a transaction.
ImagePilot HL7 Conformance Statement
10
Example: MRG|3001
5.7 ORC – COMMON ORDER SEGMENT
The Common Order Segment is used to transmit fields that are common to all orders (all types of services that are requested). The Common Order Segment is constructed as follows:
Order Common Segment (ORC) Attributes
SEQ LEN DT OPT ELEMENT NAME ImagePilot FIELD CONTENT
1 2 ID R Order Control
2 22 EI C Placer Order Number
3 22 EI C Filler Order Number
4 22 EI O Placer Group Number
5 2 ID O Order Status
6 1 ID O Response Flag
7 200 TQ O Quantity/Timing
8 200 CM O Parent
9 26 TS O Date/Time of Transaction
10 120 XCN O Entered By
11 120 XCN O Verified By
12 120 XCN O Ordering Provider
13 80 PL O Enterer’s Location
ORC field definitions ORC-1 Order Control (ID) 00215 Determines the function of the order segment. When ORC-1 is NW, XO, SN, and PA, an order is registered, and when ORC-1 is CA and DC, the order of applicable Placer Order Number is canceled.
ORC-2 Placer Order Number ( EI) 00216 This field is the placer application’s order number.
ORC-12 Ordering Provider (XCN) 00226 This field contains the identity of the person who is responsible for creating the request (i.e., ordering physician).
Example: ORC|NW|6000|B103Z||SC||1^once^^^^S||200007010900|^ROSEWOOD^RANDOLPH||7101^ESTRADA^JAIME^P^^DR||(314)555-1212|200007010900||922229-10
ImagePilot HL7 Conformance Statement
11
5.8 OBR – OBSERVATION REQUEST SEGMENT
OBR serves as the order detail. The requesting application will use some fields to describe the observation requested. Posting from DICOM MWL may be included in the field of an OBR segment.
Observation Request Segment (OBR) Attributes
SEQ LEN DT OPT ELEMENT NAME ImagePilot FIELD CONTENT
1 4 SI O Set ID - OBR
2 22 EI C Placer Order Number
3 22 EI C Filler Order Number
4 200 CE R Universal Service ID Protocol Code
5 2 ID B Priority - OBR
6 26 TS B Requested Date/Time
7 26 TS C Observation Date/Time
8 26 TS O Observation End Date/Time
9 20 CQ O Collection Volume
10 60 XCN O Collector Identifier
11 1 ID O Specimen Action Code
12 60 CE O Danger Code
13 300 ST O Relevant Clinical Info.
14 26 TS C Specimen Received Date/Time
15 300 CM O Specimen Source L/R indicator
16 120 XCN O Ordering Provider
17 40 XTN O Order Callback Phone Number
18 60 ST O Placer Field 1 Accession Number
19 60 ST O Placer Field 2 Requested Procedure ID
20 60 ST O Filler Field 1 Scheduled Procedure Step ID
21 60 ST O Filler Field 2
22 26 TS C Results Rpt/Status Chng
23 40 CM O Date/Time
24 10 ID O Diagnostic Serv Sect ID DICOM Modality
25 1 ID C Result Status
26 200 CM O Parent Result
27 200 TQ O Quantity/Timing
28 150 XCN O Result Copies To
29 200 CM O Parent
30 20 ID O Transportation Mod
31 300 CE O Reason for Study
32 200 CM O Principal Result Interpreter
33 200 CM O Assistant Result Interpreter
34 200 CM O Technician
35 200 CM O Transcriptionist
36 26 TS O Scheduled Date/Time
37 4 NM O Number of Sample Containers
ImagePilot HL7 Conformance Statement
12
38 60 CE O Transport Logistics of Collected
39 200 CE O Collector’s Comment
40 60 CE O Transport Arrangement
41 30 ID O Transport Arranged
42 1 ID O Escort Required
43 200 CE O Planned Patient Transport
44 80 CE O Procedure Code Requested Procedure Code and Requested
Procedure Description
45 80 CE O Procedure Code Modifier
OBR field definitions OBR-4 Universal Service ID (CE) 00238
This field contains the identifier code for the requested observation/test/battery. This can be based on local and/or “universal” codes. We recommend the “universal” procedure identifier. The structure of this CE data type is described in the control section.
Example:
OBR|1|6000|B103Z |P1^Procedure1|||||||||||Radiology^^^^R|7101^ESTRADA||B103Z|RP103|SS103||||MR||| 1^once^^^^S|||WALK|||||||||||A|||P1^Procedure 1
5.9 OBX – OBSERVATION RESULT SEGMENT
The OBX segment is used to transmit a single observation or observation fragment. It represents the smallest indivisible unit of a clinical observation or report. The Observation Result Segment (OBX) is constructed as follows:
Observation Result Segment (OBX) Attributes
SEQ LEN DT OPT ELEMENT NAME ImagePilot FIELD CONTENT
1 4 SI O Set ID - OBX Sequential counter
2 3 ID C Value Type ST or CE or SN or ED or RP
3 80 CE R Observation Identifier Observation Code and Text
4 20 ST C Observation Sub-ID Sequential counter
5 65536 * C Observation Value Text or Code or Numeric
6 60 CE O Units
7 60 ST O References Range
8 5 ID O Abnormal Flags
9 5 NM O Probability
10 2 ID O Nature of Abnormal Test
11 1 ID R Observation Result Status F
12 26 TS O Date Last Obs Normal Values
13 20 ST O User Defined Access Checks
14 26 TS O Date/Time of the Observation Date/Time of the Observation
15 60 CE O Producer's ID
16 80 SCN O Responsible Observer
17 60 CE O Observation Method
ImagePilot HL7 Conformance Statement
13
The length of the observation value field is variable, depending upon value type. See OBX-2-value type. OBX field definitions OBX-2 Value Type(ID) 00570 This field contains the format of the observation value in OBX.
OBX-3 Observation Identifier (CE) 00571 This field contains a unique identifier for the observation.
OBX-5 Observation Value (*) 00573
This field contains the value observed by the observation producer. OBX-2-value type contains the data type for this field according to which observation value is formatted.
Combination of OBX-2 and OBX-5 in a ORU / MDM message:
OBX-2 OBX-5 OBX-5 (Example)
ST The HTTP link to ImagePilot http://10.51.21.109/KimLinkScreen/KimLinkScreen.application?pid=
100001\T\oprt=open\T\stuid=1.2.392.200036.9107.500.11111205180
02\T\uname=nologin
ST The HTTP link to a JPEG file http://10.51.21.109/KimDataJpeg/CnvImg2.0.jpg
ED The BASE64 encoding string of a JPEG file ^multipart^JPEG^A^\X0D0A\MIME-Version: 1.0\X0D0A\Content-
Type: image/jpeg\X0D0A\Content-Transfer-Encoding:
base64\X0D0A\/9j/4AAQSkZJRgABAQEAYABgAAD/2…
RP The CIFS link to a JPEG file \\10.51.21.109\Data\Jpeg\CnvImg10.0.jpg
Example: OBX|4|TX|1001^AMY^NEO^2002||TEXTTEXTTEXT||||||F
ImagePilot HL7 Conformance Statement
14
5.10 ZDS – STUDY INSTANCE UID SEGMENT
The Study Instance UID Segment is used to send DICOM Study Instance UID of a order. The Study Instance UID Segment is constructed as follows:
Study Instance UID Segment (ZDS) Attributes
SEQ LEN DT OPT ELEMENT NAME ImagePilot FIELD CONTENT
1 200 RP R Study Instance UID “1.1.1”
ZDS field definitions ZDS-1 Study Instance UID (RP)
Globally unique identifier assigned by the workflow management IDIS to the Imaging Study under which all images and other DICOM objects produced in the course of the Requested Procedure shall be collected. Example: ZDS| 1.113654.3.104.1^100^Application^DICOM
ImagePilot HL7 Conformance Statement
15
5.11 SCH – SCHEDULE ACTIVITY INFORMATION SEGMENT
The SCH segment contains general information about scheduled appointment.
Schedule Activity Information Segment (SCH) Attributes
SEQ LEN DT OPT ELEMENT NAME ImagePilot FIELD CONTENT
1 75 EI C Placer Appointment ID 20101124000001
2 75 EI C Filler Appointment ID
3 5 NM C Occurrence Number
4 22 EI O Placer Group Number
5 200 CE O Schedule ID
6 200 CE R Event Reason 123^Reason^L
7 200 CE O Appointment Reason
8 200 CE O Appointment Type
9 20 NM O Appointment Duration
10 200 CE O Appointment Duration Units
11 200 TQ R Appointment Timing Quantity ^^^^^R
12 48 XCN O Placer Contact Person
13 40 XTN O Placer Contact Phone Number
14 106 XAD O Placer Contact Address
15 80 PL O Placer Contact Location
16 38 XCN R Filler Contact Person 745^Contact Person’s name
17 40 XTN O Filler Contact Phone Number
18 106 XAD O Filler Contact Address
19 80 PL O Filler Contact Location
20 48 XCN R Entered by Person 766^Entered Person’s name
21 40 XTN O Entered by Phone Number
22 80 PL O Entered by Location
23 75 EI O Parent Placer Appointment ID
24 75 EI O Parent Filler Appointment ID
25 200 CE O Filler Status Code
SCH-1 Placer appointment ID (EI) 00860 This field contains the placer application’s permanent identifier for the appointment request (and the scheduled appointment it self, when it has been confirmed as a booked slot by the filler application). This is composite field.
SCH -2 Filler appointment ID (EI) 00861 This field contains the filler application’s permanent identifier for the appointment request (and the scheduled appointment itself, when it has been confirmed as a booked slot by the filler application). This is a composite field.
Example: SCH|20101124000001|||||123^Reason^L|||||^^^^^R|||||745^ Contact Person’s name||||766^ Entered Person’s name
ImagePilot HL7 Conformance Statement
16
5.12 TXA-TRANSCRIPTION DOCUMENT HEADER SEGMENT
The TXA segment contains information specific to a transcribed document.
Transcription Document Header(TXA)Attributes
SEQ LEN DT OPT ELEMENT NAME ImagePilot FIELD CONTENT
1 4 SI R Set ID- TXA 1
2 30 IS R Document Type DI
3 2 ID C Document Content Presentation
4 24 DTM O Activity Date/Time
5 250 XCN C Primary Activity Provider Code/Name
6 24 DTM O Origination Date/Time
7 24 DTM C Transcription Date/Time
8 24 DTM O Edit Date/Time
9 250 XCN O Originator Code/Name
10 250 XCN O Assigned Document Authenticator
11 250 XCN C Transcriptionist Code/Name
12 427 EI R Unique Document Number 20110328102024
13 427 EI C Parent Document Number
14 427 EI O Placer Order Number
15 427 EI O Filler Order Number
16 30 ST O Unique Document File Name
17 2 ID R Document Completion Status PA
18 2 ID O Document Confidentiality Status
19 2 ID O Document Availability Status
20 2 ID O Document Storage Status
21 30 ST C Document Change Reason
22 250 PPN C Authentication Person, Time Stamp (set)
23 250 XCN O Distributed Copies (Code and Name of Recipient(s) )
TXA-1 Set ID - TXA (SI) 00914 This field contains a number that uniquely identifies this transaction for the purpose of adding, changing, or deleting the transaction.
TXA-2 Document Type (IS) 00915 This field identifies the type of document (as defined in the transcription system).
TXA-12 Unique Document Number (EI) 00925 This field contains a unique document identification number assigned by the sending system. This document number is used to assist the receiving system in matching future updates to the document, as well as to identify the document in a query. When the vendor does not provide a unique document ID number, some type of document identifier should be entered here, or the Unique Document File name should be utilized.
ImagePilot HL7 Conformance Statement
17
TXA-17 Document Completion Status (ID) 00928 This field identifies the current completion state of the document. This is a required, field.
Example: TXA|1|DI||||||||||20110328102024|||||PA
ImagePilot HL7 Conformance Statement
18
6. Communications Environment
Message exchanging is performed generally in a networked environment. This type of environment provides error free data transmission (e.g., network over TCP/IP).
6.1 LOWER LEVEL PROTOCOL
ImagePilot interfaces implement the HL7 Lower Level Protocol (LLP), which enhances the capabilities of the communications environment. The HL7 Lower Level Protocol is defined in the HL7 Implementation Guide, which is not an official part of the Standard.
6.2 FAULT TOLERANCE
All the lower level protocols may help in communicating the data reliably but any one of the communicating systems cannot assume that the message was received unless it receives an acknowledgement message.
ImagePilot interfaces will send acknowledgements only after the received data is processed and saved. This approach creates an inherent fault tolerance so network or system crashes will not cause loss of data or non-reliable application-level communications.
When the ImagePilot system is the sender of information, the system will resend messages that did not receive acknowledgements.