ImagePilot. HL7 Conformance Statement. Manufacturer: 1 Sakura-machi, Hino-shi Tokyo , Japan

Transcription

1 ImagePilot HL7 Conformance Statement Manufacturer: 1 Sakura-machi, Hino-shi Tokyo , Japan

2

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

4 Table of Contents 1. INTRODUCTION OVERVIEW IMPLEMENTATION MODEL APPLICATION DATA FLOW HL7 MESSAGE AND ITS COMPONENTS FIELDS AND FIELD ATTRIBUTES SUPPORTED MESSAGE TYPES AND EVENT TYPES ADT TYPE MESSAGES ORM TYPE MESSAGES SIU TYPE MESSAGES ORU TYPE MESSAGES MDM TYPE MESSAGES MESSAGE CONSTRUCTION RULES MESSAGE DELIMITERS MSH MESSAGE HEADER SEGMENT EVN EVENT TYPE SEGMENT PID PATIENT IDENTIFICATION SEGMENT PV1 PATIENT VISIT SEGMENT MRG MERGE PATIENT SEGMENT ORC COMMON ORDER SEGMENT OBR OBSERVATION REQUEST SEGMENT OBX OBSERVATION RESULT SEGMENT ZDS STUDY INSTANCE UID SEGMENT SCH SCHEDULE ACTIVITY INFORMATION SEGMENT TXA-TRANSCRIPTION DOCUMENT HEADER SEGMENT COMMUNICATIONS ENVIRONMENT LOWER LEVEL PROTOCOL FAULT TOLERANCE...18 ii

5 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." 1

6 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 Receive HL7 message ADT, ORM, SIU are supported. 1. Request sending ImagePilot EMR/PMS/HIS/RIS HL7 Service Data base 2. Response Acknowledge Send HL7 message ORU, MDM are supported. ImagePilot 1. Request sending HL7 Service EMR/PMS/HIS/RIS 2. Response Acknowledge 3.2 HL7 MESSAGE AND ITS COMPONENTS 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. 2

7 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 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 Name - ELEMENT NAME 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. 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. 3

8 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 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 A01 A04 A05 A08 A40 DESCRIPTION ADT/ACK - Admit/visit notification ADT/ACK - Register a patient ADT/ACK - Pre-admit a patient ADT/ACK - Update patient information 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 S12 S14 S15 DESCRIPTION SIU/ACK - Notification of new appointment booking SIU/ACK - Notification of appointment modification SIU/ACK - Notification of appointment cancellation 4

9 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 R01 DESCRIPTION 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 T02 DESCRIPTION MDM/ACK - Original document notification and content 5

10 5. Message Construction Rules 5.1 MESSAGE DELIMITERS The ImagePilot interfaces follow HL7 Version 2.3 recommended message delimiters as follows: Segment Terminator Delimiter Suggested Value Usage <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 ^~\& HD R Sending Application ImagePilot HD O Sending Facility HD O Receiving Application 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 ST R Message Control ID Unique number 11 3 PT R Processing ID P VID R Version ID NM O Sequence Number ST O Continuation Pointer 15 2 ID O Accept Acknowledgment Type 16 2 ID O Application Acknowledgment Type 6

11 17 2 ID O Country Code ID O Character Set CE O Principal Language Of Message ID O Alternate Character Set Handling Scheme MSH field definitions MSH-1 Field Separator (ST) 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) 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) This field uniquely identifies the sending application MSH-9 Message Type (MSG) 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 ADT^A04 AAAAAA P 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 XCN O Operator ID 6 24 DTM O Event Occurred HD O Event Facility 7

12 EVN field definition EVN-2 Recorded Date/Time (TS) Most systems will default to the system date/time when the transaction was entered, but they should also permit an override. Example: EVN 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) 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) 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 Henry^Jacobson 8

13 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) A common field used by systems to categorize patients by site. It does not have a consistent industrywide definition. Subject to site-specific variations. Refer to user-defined table 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 CX R Prior Patient Identifier List Prior Patient ID CX B Prior Alternate Patient ID CX O Prior Patient Account Number CX B Prior Patient ID CX O Prior Visit Number CX O Prior Alternate Visit ID XPN O Prior Patient Name MRG field definitions MRG-1 Prior Patient Identifier List (CX) 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. 9

14 Example: MRG 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 TQ O Quantity/Timing CM O Parent 9 26 TS O Date/Time of Transaction XCN O Entered By XCN O Verified By XCN O Ordering Provider PL O Enterer s Location ORC field definitions ORC-1 Order Control (ID) 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) This field is the placer application s order number. ORC-12 Ordering Provider (XCN) 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 ^ROSEWOOD^RANDOLPH 7101^ESTRAD A^JAIME^P^^DR (314)

15 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 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 XCN O Collector Identifier 11 1 ID O Specimen Action Code CE O Danger Code ST O Relevant Clinical Info TS C Specimen Received Date/Time CM O Specimen Source L/R indicator XCN O Ordering Provider XTN O Order Callback Phone Number ST O Placer Field 1 Accession Number ST O Placer Field 2 Requested Procedure ID ST O Filler Field 1 Scheduled Procedure Step ID ST O Filler Field TS C Results Rpt/Status Chng CM O Date/Time ID O Diagnostic Serv Sect ID DICOM Modality 25 1 ID C Result Status CM O Parent Result TQ O Quantity/Timing XCN O Result Copies To CM O Parent ID O Transportation Mod CE O Reason for Study CM O Principal Result Interpreter CM O Assistant Result Interpreter CM O Technician CM O Transcriptionist TS O Scheduled Date/Time 37 4 NM O Number of Sample Containers 11

16 38 60 CE O Transport Logistics of Collected CE O Collector s Comment CE O Transport Arrangement ID O Transport Arranged 42 1 ID O Escort Required CE O Planned Patient Transport CE O Procedure Code Requested Procedure Code and Requested Procedure Description CE O Procedure Code Modifier OBR field definitions OBR-4 Universal Service ID (CE) 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 B103Z P1^Procedure1 Radiology^^^^R 7101^ESTRADA B103Z RP103 SS103 MR 1^once^^^^S WALK A P1^Procedure 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 * 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 TS O Date Last Obs Normal Values ST O User Defined Access Checks TS O Date/Time of the Observation Date/Time of the Observation CE O Producer's ID SCN O Responsible Observer CE O Observation Method 12

17 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) This field contains the format of the observation value in OBX. OBX-3 Observation Identifier (CE) This field contains a unique identifier for the observation. OBX-5 Observation Value (*) 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 \T\oprt=open\T\stuid= \T\uname=nologin ST The HTTP link to a JPEG file 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 \\ \Data\Jpeg\CnvImg10.0.jpg Example: OBX 4 TX 1001^AMY^NEO^2002 TEXTTEXTTEXT F 13

18 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 RP R Study Instance UID 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 ^100^Application^DICOM 14

19 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 EI C Filler Appointment ID 3 5 NM C Occurrence Number 4 22 EI O Placer Group Number CE O Schedule ID CE R Event Reason 123^Reason^L CE O Appointment Reason CE O Appointment Type 9 20 NM O Appointment Duration CE O Appointment Duration Units TQ R Appointment Timing Quantity ^^^^^R XCN O Placer Contact Person XTN O Placer Contact Phone Number XAD O Placer Contact Address PL O Placer Contact Location XCN R Filler Contact Person 745^Contact Person s name XTN O Filler Contact Phone Number XAD O Filler Contact Address PL O Filler Contact Location XCN R Entered by Person 766^Entered Person s name XTN O Entered by Phone Number PL O Entered by Location EI O Parent Placer Appointment ID EI O Parent Filler Appointment ID CE O Filler Status Code SCH-1 Placer appointment ID (EI) 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) 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 ^Reason^L ^^^^^R 745^ Contact Person s name 766^ Entered Person s name 15

20 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 IS R Document Type DI 3 2 ID C Document Content Presentation 4 24 DTM O Activity Date/Time 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 XCN O Originator Code/Name XCN O Assigned Document Authenticator XCN C Transcriptionist Code/Name EI R Unique Document Number EI C Parent Document Number EI O Placer Order Number EI O Filler Order Number 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 ST C Document Change Reason PPN C Authentication Person, Time Stamp (set) XCN O Distributed Copies (Code and Name of Recipient(s) ) TXA-1 Set ID - TXA (SI) 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) This field identifies the type of document (as defined in the transcription system). TXA-12 Unique Document Number (EI) 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. 16

21 TXA-17 Document Completion Status (ID) This field identifies the current completion state of the document. This is a required, field. Example: TXA 1 DI PA 17

22 6. Communications Environment Message exchanging is performed generally in a networked environment. environment provides error free data transmission (e.g., network over TCP/IP). This type of 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. 18

23

24 0604YA321 G JD