Top Banner
ImagePilot HL7 Conformance Statement Manufacturer: 1 Sakura-machi, Hino-shi Tokyo 191-8511, Japan
24

HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

Jul 06, 2018

Download

Documents

dinhkien
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

ImagePilotHL7 Conformance Statement

Manufacturer:

1 Sakura-machi, Hino-shi Tokyo 191-8511, Japan

Page 2: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i
Page 3: 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.

Page 4: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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

Page 5: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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

Page 6: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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

Page 7: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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.

Page 8: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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

Page 9: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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

Page 10: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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

Page 11: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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

Page 12: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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

Page 13: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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.

Page 14: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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

Page 15: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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

Page 16: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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

Page 17: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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

Page 18: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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

Page 19: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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

Page 20: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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.

Page 21: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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

Page 22: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

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.

Page 23: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i
Page 24: HL7 Conformance Statement - KONICA MINOLTA Europe · ImagePilot HL7 Conformance Statement i

0604YA321 G

20120710JD