Medicalis Workflow HL7 to SQL Specification

(1)

Medicalis Workflow HL7 to SQL Specification

Medicalis Workflow HL7 to SQL Specification Version 6.7.0

January 2015

Document and Contact Information Document Revisions

Version Date Author(s) Description Document

Status 6.7.0 16 January 2015 Tiffany

Quinlan

Added 'Using this Document' section and links to dictionaries from field specs

6.6.0 December 2014 Balazs Igli OBX updates for observations and reports. Added two result processing instructions.

6.5.0 December 2014 Geoff Wheeler Minor updates for 6.5.0 6.2.0 October 2014 Geoff Wheeler Updated for 6.2.0 6.1.0 October 2014 Jeremy

Hossfeld

Added supplies (RQD), other charges (FT1) and pharmeceuticals (RQD, RQA)

6.0.0 July 2014 Geoff Wheeler Updated for 6.0.0

2.4.3 25 June 2013 Geoff Wheeler Added ZRP-16 - Worklist, ZRP-17 - Image Location, and ZOF Segment 2.2 22 March 2013 Tiffany

Quinlan

Addition of sections:

Required & Optional Fields for HL7 into Professional/Analytics Validating HL7 Against the Medicalis HL7 Spec

2.1 23 November 2012

Balazs Igli Added ZRP-15.1.1 Create Call Report Request

2.0 15 June 2012 Geoff Wheeler Updated for Professional 2.4 1.1 20 January 2012 Geoff Wheeler Added tables for specific code values

0.4 9 June 2011 Balazs Igli Added RWF push data to MClinical (see issue 75278) 0.3 7 January, 2011 Geoff Wheeler Added processing of the DG1 segment and placer order data. 0.2 13 December,

2010

Geoff Wheeler Added processing of the AL1 segment.

0.1 4 August, 2010 Geoff Wheeler Draft document creation – Using CDR HL7-XML Specification (CDR 1.5) as template.

(2)

Primary Contact Corporate Office

Position:

Product Manager

Medicalis Corporation 508 Riverbend Drive Kitchener, Ontario +1 (519) 579-5454

Document Stakeholders and Reviewers

Role Name Email Reviewing Role (Author, Approve, Review,

Copied) Product Manager Cleon Hill

Wood-Salomon

[email protected] Approve

Director, Customer Operations

Derek MacNeil [email protected] Review

Architect Marc Durand [email protected] Review

HL7 Integration Tiffany Quinlan [email protected] Review Development Lead Geoff Wheeler [email protected] Review

DBA Karen Choi [email protected] Review

SV Representative Kristen Taylor [email protected] Review Support Representative Jeff MacDonald [email protected] Review

Legal Information

This document and the information contained herein are proprietary and confidential. It may not be duplicated, redistributed, reused, or displayed to any other party without the express written consent of Medicalis™. Medicalis™ and the Medicalis logo are trademarks of Medicalis Corp. All other names are trademarks of their respective companies, and are only used for identifying product and company information.

Table of Contents 1.0 Introduction 1.1 HL7 Conformance 1.2 Document Overview 1.3 Terms 2.0 Data Communication

2.1 TCP/IP Communication – HL7 Device

2.1.1 MLLP – Minimal Lower Layer Protocol 2.2 File Communication – File Device

2.3 Acknowledgement 2.3.1 ACK Formation 2.4 Invalid Characters 2.5 Escaping

2.6 Null vs. Empty Value

2.7 Data Quality and Asynchronous Messaging 3.0 Message Profile Overview

3.1 Dynamic Definition 3.2 Static Definition

3.2.1 CDR Database Table Column 3.2.2 Notes Column

3.2.3 Usage Column 3.3 Segment Definition

3.3.1 Database.Table.Column 3.3.2 Notes Column

3.4 User-defined Tables and Auto-population

Cleon Hillwood

(3)

3.5 Multiple MRN and Accession Issuers 3.6 Processing Instructions

3.7 Vendor Specific Data Types 3.7.1 WS – Workflow Status 4.0 Message Profiles

4.0.1 Actors

4.1 Patient Update/Register Profile [ADT^A08 / ADT^A04] 4.1.1 Use Case

4.1.2 Interactions 4.1.3 Example Message 4.1.4 Example ACK

4.1.5 Message Static Definition 4.2 Patient Merge Profile [ADT^A18 / ADT^A40]

4.2.1 Use Case 4.2.2 Interactions 4.2.3 Example Message 4.2.4 Example ACK

4.2.5 Message Static Definition 4.3 Patient Link Profile [ADT^A24]

4.3.5 MessageStatic Definition 4.4 General Order Profile [ORM^O01]

4.4.5 Message Static Definition 4.5 Imaging Order Profile [OMI^O23]

4.5.5 Message Static Definition 4.6 Result Profile [ORU^R01]

4.6.5 Message Static Definition 4.7 Update Personnel Record [PMU^B02]

4.7.5 Message Static Definition

4.8 Inventory Item Master File Message [MFN^M15] 4.8.1 Use Case

4.9 Patient Location Master File Message [MFN^M05] 4.9.1 Use Case

4.10 Additional Basic Observation/Service Attributes [MFN^M12] 4.10.1 Use Case

(4)

4.11 Medical Document Management Profile [MDM^T02 / MDM^T04 / MDM^T08 / MDM^T11] 4.11.1 Use Case

4.11.2 Interactions

4.11.3 Example Message – Document Edit Notification 4.11.4 Example ACK

4.12 Application Management Data Message [NMD^N03] 4.12.1 Use Case

4.12.5 Message Static Definition 5.0 HL7 to SQL Mappings 5.0.1 Sample Mapping 5.1 MSH Segment 5.2 EVN Segment 5.3 PID 5.4 PD1 5.5 LAN 5.6 ROL 5.7 NK1 5.8 PV1 5.9 PV2 5.10 AL1 5.11 GT1 5.12 IN1 5.13 MRG 5.14 ORC 5.15 OBR 5.16 CTD 5.17 DG1 5.18 IPC 5.19 ZRP 5.20 ZOF

5.21 OBX (for Reports)

5.22 OBX (for Observations, Lab Results or Precautions) 5.23 OBX (for MDM OLF data)

5.24 BLG 5.25 STF 5.26 OVR 5.27 LOC 5.28 LCH 5.29 IIM 5.30 PRA 5.31 EDU 5.32 NTE 5.33 OM1 5.34 OM7 5.35 TXA 5.36 ZNF 5.37 FT1 5.38 RQD 5.39 RXD 5.40 RXA 6.0 Code Reference 6.1 Abnormal Flag 6.2 Address Type 6.3 Admission Type 6.4 Admit Source 6.5 Allergen Type 6.6 Allergy Clinical Status 6.7 Allergy Reliability 6.8 Allergy Severity 6.9 Ambulatory Status

(5)

6.10 Assigning Authority 6.11 Country

6.12 Employment Status 6.13 Filler Order Status 6.14 Degree

6.15 Filler Order Status 6.16 Hospital Service 6.17 Identity Reliability 6.18 Indication Category 6.19 Individual Sex 6.20 Language Proficiency 6.21 Marital Status 6.22 Name Type

6.23 Observation Result Status 6.24 Patient Class

6.25 Placer Order Status 6.26 Priority Code

6.27 Procedure Step Status 6.28 Province/State 6.29 Race 6.30 Relation Type 6.31 Religion

6.32 Requested Procedure Status 6.33 Result Status 6.34 Subspecialty 6.35 Telecommunication Use 6.36 Time Zone 6.37 VIP Indicator 6.38 Visit Indicator 7.0 Integration Notes

7.1 Order Control Codes

7.2 - 32 Common (ADT^A08, ORM, ORU) Processing Instructions 7.3 - 29 Common (ORM, ORU) Processing Instructions 7.4 - 1 Additional ORM Processing Instructions

7.5 - 6 Additional ORU Processing Instructions 8.0 Using This Document

8.1 Table of Contents 8.2 CTRL + F Hyperlinks 8.3 Required Fields 8.4 Issuers

1.0 Introduction

This document defines how a standard set of HL7 messages for defining data received from a RIS that will be processed into the Medicalis databases. It is assumed that the reader of this document is familiar with the details of the Medicalis Interface Engine and the Medicalis databases. Medicalis employs a 2 part system for processing HL7 data. The Intelligo Interface Engine handles all HL7 communication including queue management, and user defined mappings. Intelligo transports messages but is not a long term clinical database. The CDR service handles processing of each message as a clinical transaction. The CDR deconstructs, validates, and then stores the data in each message into a long term clinical repository.

1.1 HL7 Conformance

This document follows the “Conformance” methodology defined in Chapter 2 of the HL7 specification, version 2.5. The scope of this document covers only those elements of the HL7 Standard which are applicable to the CDR. The CDR data model is also based heavily on the HL7 2.5 specification, and the IHE patient registration, and scheduled order workflows.

(6)

The introductory sections of this document outline the general communication and workflow conformance of Intelligo and the CDR. This includes network communication, escaping, acknowledgement, vendor specific data types and behavior, and extensions to the message profile itself. These sections are followed by chapters for each supported message profile (e.g. ADT, ORM, ORU). The appendices contain reference information such as common user defined tables (e.g. Country Codes).

1.3 Terms

This section defines a series of important terms. These descriptions are valid within the scope of this document: Intelligo

The Intelligo Interface Engine handles all HL7 communication including queue management, and user defined mappings. Intelligo transports messages but is not a long term clinical database. Intelligo is a trademark of Medicalis Corporation.

CDR

The Medicalis CDR (Clinical Data Repository) is a service and SDK that handles processing of each message as a clinical transaction. The CDR deconstructs, validates, and then stores the data in each message into a long term clinical repository. The CDR is used as a foundation or platform for clinical applications such as a PACS, or an order entry application.

Medicalis

The creator of Intelligo and the CDR. Medicalis delivers clinical knowledge to the point-of-care. Created with the goal of delivering evidence-based medicine, and founded upon deep expertise in healthcare information integration, Medicalis has the unique ability to capture clinical knowledge and deliver it to healthcare workers directly involved in patient care decisions.

Queue

Part of the Intelligo Interface Engine. Intelligo processes messages asynchronously. When a message is received it is written to a “Received Queue” and acknowledged. Soon after, the message is processed, and is moved to a “Processed Queue” on success, or “Error Queue” on error. Queues are managed by the Intelligo system administrator.

Placer Order

A diagnostic imaging order created typically by an ordering physician. Typically originates from a HIS or EMR system. A Placer Order is generally a high level request for imaging and is filled by 1 or many Filler Orders. The CDR simply stores the Placer Order Number as a linking attribute for Filler Orders.

Filler Order

A departmental diagnostic imaging order managed by a RIS (Radiology Information System). A Filler Order “fills” a Placer Order. Also known as an Imaging Service Request. A Filler Order is identified by its Filler Order ID, or its Accession number. These are generally the same value, but can be different. These orders contain more detailed information about the study that is specific to the radiology department. Filler Orders are made up of 1 or more Requested Procedures.

Requested Procedure

Part of a Filler Order. This is a reportable unit of work that will typically be coded and billable. The CDR stores additional status information regarding Requested Procedures. In the CDR, results (reports) are associated with Requested Procedures. Requested Procedures are made up on 1 or more Procedure Steps.

Procedure Step

In the CDR, this object represents both a Scheduled Procedure Step and a Performed Procedure Step. These are the most granular units of work that can be acted on. “Scheduled” refers to a unit of work to be done. These are typically units of work that require a Protocol. “Performed” refers to a unit of work that has been done. In a PACS, Performed Procedure Steps would have Series and Instance data attached to them. The CDR does not implement the IHE data model past the level of the Procedure Step.

2.0 Data Communication

(7)

2.1 TCP/IP Communication – HL7 Device

HL7 message communication is handled by the Intelligo Interface Engine. Intelligo is a Java (JDK 1.4.2) based system, and makes use of the standard Java socket communication libraries for access to network resources. The Intelligo HL7 Device uses TCP/IP to communicate HL7 messages as defined in Chapter 2 or the Hl7 2.5 specification.

The sending/receiving ports are configurable and are therefore defined at the time of integration. Intelligo supports receiving messages over multiple connections. However it is recommended that a RIS open a single TCP/IP connection and make best efforts to maintain and reuse that connection for as long as possible.

It is expected that each HL7 message transmitted will be constructed using the basic message formation rules outlined in Chapter 2 of the HL7 specifications (versions 2.0 – 2.5). Also, each message must be terminated with a message separator sequence according to the MLLP (Minimal Lower Layer Protocol).

2.1.1 MLLP – Minimal Lower Layer Protocol

HL7 defines a set of special wrapping characters that enclose an HL7 message. These characters are known as:

Name Symbol Suggested Value (HEX) Purpose

Start Block <SB> 0x0B Marks the beginning of a message (immediately precedes the MSH segment).

End Block <EB> 0x1C Marks the end of a message.

Carriage Return <CR> 0x0D Also marks the end of a message (follows the End Block).

These characters wrap a message like so: <SB>MSH|…sample…<EB><CR>

As noted in the table above, the HL7 specification defines hex characters 0x1C0D as the default separator sequence. Intelligo allows this value to be configured in cases of non compliance. The Intelligo HL7 device does not require a Start Block character to be present when receiving messages. This device instead simply looks for the separator sequence <EB><CR> when reading messages form the socket stream. Therefore a sending system may safely send messages with or without a Start Block. However, all HL7 messages sent form the Intelligo HL7 Device will include a Start Block character. This includes acknowledgements.

2.2 File Communication – File Device

The Intelligo Interface Engine can also process HL7 2.5 messages via a file stream. The behavior of this device is configurable; however it can support reading and writing or individual files per message, or large files containing numerous messages. For large files, messages must be separated using the standard separation sequence (defined above in section 2.1.1). The File Device does not support the HL7 batch protocol.

2.3 Acknowledgement

The Intelligo Interface Engine supports Original Mode Acknowledgement. As per the HL7 specification regarding acknowledgement Intelligo “may acknowledge the message after placing it in an input queue, expecting to fully process the order into its database at a future time. The only assumption is that the input queue is maintained at the same level of integrity as the database.” In this case, “the database” refers to the CDR. Intelligo immediately responds to a message with an Application Acknowledgement when all of the following steps have been completed:

Validate that the HL7 message is well formed and does not contain invalid characters. Store the message to the Received Queue. (This is a persistent queue).

This ACK does not imply that the data elements in the inbound message have been properly processed and inserted into the CDR database. Intelligo simply guarantees delivery of the message(s). Application Acknowledgement Codes include: AA – Accept, AR – Reject, AE – Error.

(8)

In accordance with the HL7 2.5 specification Intelligo uses the following logic when constructing an HL7 ACK message:

“The MSH segment in the response is constructed anew following the rules used to create the initial message described above. In particular, MSH-7-date/time of message and MSH-10-message control ID refer to the response message; they are not echoes of the fields in the initial message. MSH-5-receiving application, MSH-6-receiving facility, and MSH-11-processing ID contain codes that are copied from MSH-3-sending applica-tion, MSH-4-sending facility and MSH-11-processing ID in the initiating message.

In all the responses described above, the following values are put in the MSA segment. Note that the field definitions for the MSA segment fields are in Section Error! Reference source not found..”

Field Notes

MSA-1-acknowledgment code As described above.

MSA-2-message control ID MSH-10-message control ID from MSH segment of incoming message.

MSA-3-text message further describes an error condition

2.4 Invalid Characters

The Intelligo Interface Engine will not process a message, and return an error ACK(AE) when any of the below control characters are present in an HL7 message.

Symbol HEX Value Symbol HEX Value Symbol Hex Value

NUL 0x00 SO 0x0E CAN 0x18

SOH 0x01 SI 0x0F EM 0x19

STX 0x02 DLE 0x10 SUB 0x1A

ETX 0x03 DC1 0x11 ESC 0x1B EOT 0x04 DC2 0x12 GS 0x1D ENQ 0x05 DC3 0x13 RS 0x1E ACK 0x06 DC4 0x14 US 0x1F BEL 0x07 NAK 0x15 BS 0x08 SYN 0x16 FF 0x0C ETB 0x17

2.5 Escaping

The Intelligo Interface Engine supports HL7 escape sequences. The default escape character is “\”, however the appropriate escape character will be read form field MSH.2 per message. All other escape sequences not mentioned below will be ignored and stored into the corresponding database field. The following HL7 escape sequences are supported by Intelligo:

Sequence Name Purpose

\F\ Field Separator Represents the field separator character (usually “|”) \S\ Component Separator Represents the component separator character (usually “^”) \T\ Subcomponent Separator Represents the subcomponent separator character (usually “&”)

(9)

\R\ Repetition Separator Represents the repetition separator character (usually “~”) \E\ Escape Character Represents the escape character (usually “\”)

\Xdddd\ or \Xdd\

Hexadecimal Data Represents a character defined by its hexadecimal value.

Example \X0047\ is the letter “G”. This can also be escaped as \X47\

2.6 Null vs. Empty Value

The Intelligo Interface Engine distinguishes between a value of || and a value of |””|. A value of || in a field of a segment causes no data to be passed to the underlying web service and therefore no update to that attribute stored in the database. A value of |””| in a field of a segments causes a nullifying of that attribute stored in the database. For example, if no value is present in PID-3 (i.e. ||), no patient identifier attribute is sent and no updates occur to that attribute in the database. If an empty string value is present in PID-3 (i.e. |””|), the empty string patient identifier attribute is sent and the patient identifier attribute in the database is nullified. The following table illustrates the general case.

HL7 Value Resulting Attribute Value

|ABC| ABC

|| ABC

|””| NULL

2.7 Data Quality and Asynchronous Messaging

Outbound HL7 messaging from the Medicalis Workflow engine is built on an asynchronous queuing structure and collects message data at the time of message sending. As such, there can be a small period between an action that triggers a message and that message being sent to external systems through Intelligo. During this period there is the possibility of subsequent updates to the relevant data that will be sent out in HL7. Medicalis will always collect and send the most up-to-date data stored in the application. Each triggered message would still be sent, but there is potential for multiple messages with the same up-to-date data being sent regardless of the original triggering action.

3.0 Message Profile Overview

This section addresses any extensions made to the HL7 Message Profile conformance spec to provide further clarity to the document reader. Message profiles for the CDR are broken down by chapter. Each supported message (Message Type and Trigger Event) is defined in its own chapter. In cases where multiple events are supported and treated the same, both/all events will be referenced in the chapter title.

3.1 Dynamic Definition

As per HL7 conformance, each message profile contains a Dynamic Definition. Although every message is processed in the same manner, each profile describes in detail the interactions that take place in diagram form. In addition, each profile provides one or many sample messages, and a sample acknowledgement (ACK). Sample messages contain anonymous data. Every supported field is fully populated.

3.2 Static Definition

As per HL7 conformance, each message profile contains a Static Definition for messages, and for fields where detailed descriptions are necessary. All static definitions include two extra columns: CDR Database Table, and Notes. Static definitions also make use of the Usage column rather than “Optionality”.

3.2.1 CDR Database Table Column

(10)

segment is stored across multiple tables, a list of tables is provided. The value in this column serves as a general pointer to the location where the data will be stored in the clinical database. This document is not intended to be a data dictionary.

It is expected that reader of this document understand the naming conventions and design patterns employed in the CDR clinical database. Therefore database locations are not exhaustively documented. For the purpose of this document, Table names begin with an upper case letter while column names begin with a lower case letter. In cases where a value is stored within a hierarchy of tables via foreign key relationships, table names are simply referred to in a dot (.) delimited format, but to simplify the document no joining “map” tables are included.

For example, the CDR stores patient information such as identifiers (MRNs) in the Patient table. Contact information like names and addresses are stored generically in the Contact table. The value for PID-5-1 (Family Name) is stored in the familyName column of the Contact table. The Contact record is related to a record in the Patient table. Below is a sample static definition for component 1 of the PID-5 field.

HL7 Element HL7 Element Name Database.Table.Column Length Notes

PID-5.1 Patient Name.Family Name.Surname MClinical.Patient.Contact.familyName 50

3.2.2 Notes Column

This column includes any important logic that should be considered when integrating. This column also contains logic for conditional fields.

3.2.3 Usage Column

This message profile specifies Usage instead of “Optionality” as per the conformance spec. The usage codes used in this document are defined below.

Value Description Comment

R Required A conforming sending application shall populate all “R” elements with a non-empty value. RE Required

but may be empty

The element may be missing from the message, but must be sent by the sending application if there is relevant data. A conforming sending application must be capable of providing all "RE" elements. If the conforming sending application knows the required values for the element, then it must send that element. If the conforming sending application does not know the required values, then that element will be omitted.

O Optional This code indicates that the Usage for this element has not yet been defined. C Conditional This usage has an associated condition predicate

If the predicate is satisfied:

A conformant sending application must always send the element. If the predicate is NOT satisfied:

A conformant sending application is not required to send the element. CE Conditional

but it may be empty

This usage has an associated condition predicate. If the predicate is satisfied:

A conformant sending application must always send the element. If the predicate is NOT satisfied:

A conformant sending application is not required to send the element.

X Not

supported

For conformant sending applications, the element will not be sent. The CDR will ignore the element if it is sent.

(11)

As per HL7 conformance, each supported HL7 message segment has a Segment Definition found in the following section.

3.3.1 Database.Table.Column

This column in the segment definition specifies the database table where each segment, field, or component’s data will be stored. In cases where a segment is stored across multiple tables, a list of tables is provided. The value in this column serves as a general pointer to the location where the data will be stored in the clinical database. This document is not intended to be a data dictionary.

It is expected that reader of this document understand the naming conventions and design patterns employed in the CDR clinical database. Therefore database locations are not exhaustively documented. For the purpose of this document, Table names begin with an upper case letter while column names begin with a lower case letter. In cases where a value is stored within a hierarchy of tables via foreign key relationships, table names are simply referred to in a dot (.) delimited format, but to simplify the document no joining “map” tables are included.

For example, the CDR stores patient information such as identifiers (MRNs) in the Patient table. Contact information like names and addresses are stored generically in the Contact table. The value for PID-5-1 (Family Name) is stored in the familyName column of the Contact table. The Contact record is related to a record in the Patient table. Below is a sample static definition for component 1 of the PID-5 field.

HL7 Element HL7 Element Name Database.Table.Column Length Notes

PID-5.1 Patient Name.Family Name.Surname MClinical.Patient.Contact.familyName 50

3.3.2 Notes Column

This column includes any important logic that should be considered when integrating. This column also contains logic for conditional fields. If a column requires a coded element that must match system dictionaries or reference tables a link to the default supported values at the end of this document will be included.

3.4 User-defined Tables and Auto-population

For fields requiring coded elements (CE), user-defined tables are documented (a.k.a. Reference Tables, or Dictionaries. Example: Gender). The CDR supports auto-population of most of its dictionaries. Coded element fields that support this feature contain the phrase “Supports

auto-population” in the notes column of the segment definition. The user-defined tables defined in this document contain the default dictionary entries for the given table. However tables supporting auto-population may in reality be wiped out and completely defined by the sending application (RIS).

Tables that do not support auto-population are relied upon for crucial business logic such as state transition (example: Result Status Codes).

3.5 Multiple MRN and Accession Issuers

Field containing a list of identifiers (one or more) must be paired with an Assigning Authority – Namespace ID (also known as an Issuer or Org/Organization), Identifiers must be unique within that Assigning Authority/Issuer. If an issuer is not provided in the message, Intelligo will set a default value based on its configuration.

3.6 Processing Instructions

The Intelligo Interface Engine and the CDR both support user configurable processing instructions. These processing instructions allow a user of Intelligo (integrator) to control key elements of the CDR’s business logic. For example, ORM events coming from a RIS may be allowed to create and modify patients, and visits. While ORU events coming from a reporting system may be configured to only create new patients, but not modify existing patients or visit information. Each message profile contains a list of all supported processing instructions. By default, all processing instructions are enabled.

Processing instructions can be enabled/disabled as part of mappings in the Intelligo Enterprise Manager. Processing instructions work

independently. They allow the user to control various details of underlying business logic. The vast majority of processing instructions simply allow the user to control whether a message can create new records, or update existing records of a particular entity (Patient, Order, Provider, Result, etc, etc.)

Example: For all "updateIfFound" processing instructions, enabling them allows a message to update any of the entities fields/elements that would otherwise normally allow modification. Turning these instructions off simply entirely skips the update logic for the entity (Visit for example). So if this

was turned off. No visit data would be modifiable, however new records could be created, assuming the

(12)

instruction is enabled. nd

3.7 Vendor Specific Data Types

This section contains custom data types defined by the CDR.

3.7.1 WS – Workflow Status

It is possible to manage the transitions of the some status values by including addition logic in the components of the field. The following table defines the role of each of the components.

HL7 Element

HL7 Element Name Database.Table.Column Length Notes

ZRP-4.1.1 Diagnostic Imaging Status.Status Code

MClinical.RequestedProcedure.diagnosticImagingStatusCd 3

ZRP-4.2.1 Diagnostic Imaging Status.Allowed status list

Status codes separated by commas (,). Only component 2 or component 3 can be set. They are mutually exclusive. ZRP-4.3.1 Diagnostic Imaging

Status.Disallowed status list

See above

Here are some usage examples of values stored in ZRP-4 segments and what they mean. NOTE: THESE ARE EXAMPLES ONLY. THE DIAGNOSTIC IMAGING STATES ARE DEFINED BY THE APPLICATION BUILT ON THE CDR.

ZRP|1|||S|

This message would be used to set the diagnostic imaging workflow status (ZRP-4) to “S”. However the sending system has potential knowledge of the previous state of the order. This status field could be extended to support the additions of workflow syntax to it. For example, below are two examples of possible workflow rules encoded within the same message:

ZRP|1|||S^^X|

The message above could be read as: Set the workflow status to scheduled “S” as long as the status is NOT currently “X”. ZRP|1||| C^C,S,I^|

Or in this example, set the workflow status to complete “C” as long as the status is currently complete “C”, scheduled “S”, or in progress “I”. Note that a state transition from “C” to “C” is not allowed by default, and must be declared.

4.0 Message Profiles

Each supported message type will be detailed in this section.

4.0.1 Actors

Actor: RIS

Receives patient registration or update notification from the HIS, as well as visit changes. Sends demographic updates to downstream systems including the PACS.

(13)

Receives, queues, and acknowledges messages. Applies user defined mappings. Receives messages from the RIS. Actor: CDR

The receiving application. Stores patient identifier, demographic, encounter, and image information associated with orders. Receives information from Intelligo.

4.1 Patient Update/Register Profile [ADT^A08 / ADT^A04]

4.1.1 Use Case

Patient Update and Patient Registration transactions transmit changes to patient demographics, location, visit, and provider information. These changes may occur at any time for a patient record. Both the A08 and A04 trigger events are supported, however they are handled as simple patient updates events by the CDR.

4.1.2 Interactions

4.1.3 Example Message

The following is a sample message for expected ADT^A08 events. This sample also applies to the expected format of ADT^A04 events.

MSH|^~\&|SNDAPP|SNDFAC|RECAPP|RECFAC|20040624153000||ADTÂ08|001|P|2.5| PID|||P123456^^^DPTISS&^^^^^^^|ALT123^^ÂLTISS|DOE&^JOHN^JULIE^JR.^MRS.^PHD|BUCK&^|19690721163000^|F||WHT^|1 23 ANYSTREET^ÂNYTOWN^MOÂNYZIPÛSA^H||+1(905)555-1212^^P^^[email protected]|+1(905)555-3232^Ô^^[email protected]| EN^|M^|ANG^|A456789^^^|SSN12345^|DL123789^|||||1|||FSM^|20050323132900^||FALSE|AL PD1||||001^SMITH MD&^PCP^M^JR^DR^MD^^PCPISS||||||||N LAN|1|EN||1 ROL|1||PP|001^Provider^Test^^^Dr.^MD^^DO^^^^^Â||||||||

(14)

NK1|1|JonesÊunice^M^^Mrs.^^L|OTH|1634 J StÂpt 214^Davis^CA ^95616ÛSA^^^Yolo|(530) 555-4325^^^[email protected]||C|

PV1||I|Left side station^Room3^Bed4^HospitalA&^^^WestBuilding^Floor12^Patient Bed -common^HA-R4B3&LOCISS^CANON&|R|||007^SMITH MD&^ATTEND^M^JR^DR^MD^^VISATTISS&|001^SMITH

MD&^REFER^J^JR.^DR^JD^^VISPROVISS&|008^SMITH MD&^CONSULT^M^JR^DR^MD^^VISCONISS&|MED||||1|A0||009^SMITH MD&^ADMIT^M^JR^DR^MD^^VISADMISS&||V123456^^^VISISS&|||||||||||||||||||||||||20040623090000^|||||||A PV2|||||||ARR|||||Patient in comatose state

ROL|1||ATN|ATN002^SMITH2 MD&^ATTEND2^M^JR^DR^MD^^VISPROVISSATT&||||||||

OBX|1|CE|OBID^LAB^DO|Cholesterol|.65|84^mg/dL|0.7 - 1.3|N|90||F|||201108151203|RIS1|Hubert J. Farnsworth|Fat Sample

NTE|1||lab result comment|RE

AL1||DA|^GENERIC DRUG|SV|HYPOTENS|20050323132900|Y|S|Allergist|AllergySourceSystem GT1||G-NUM|Doe^JaneÂÎV^Miss^Ph.D.||4 Oak Blvd..^^Tampa^FL^45725ÛSA|3331114444|9998884444|19980323132900|M||FTH|5555555|20060323|20080321||Smith^Davi d^M^Jr.^Mr.^PHD|8 Main St.^^Detroit^MC^45725ÛSA|1115553333|EMPID|1|||||||||||||||||||||||||Doe^JohnÔ^Jr.^Mr.^P.Eng.|1115553333||S PO

IN1||PLAN^Generic InsurancePlan|PAYOR^^^PAISS^ÔfficeId|Insurer's|72 Elm St.Ôffice Name^Burbank^CA^90210ÛSA^BÔTHDESIG|Employee^JoeÂÎII^Mr.^Ph.D.^C|5555555555|GRP#|Group Name|GRPJOE|Group|20020323132900|20070323132900|AUTH#|TYPE|Patient^Test^L^Sr.^Mrs.^M.A.Sc.^P|EME|20050528|8 River St.^^Fort Worth^TX^84235ÛSA^PÔTHDESIG|N|IN|1|||||||20060517121200|Verifier|S||||COPLANCD|XX0001100|100|10000|4|||1|M |||XXOLD|H OVR|issuer.doNotAutoCreate^false

4.1.4 Example ACK

MSH|^~\&|RECAPP|RECFAC|SNDAPP|SNDFAC|20070828120632||ACK|1|P|2.5 MSA|AA|001|The message has been queued for processing

4.1.5 Message Static Definition

Segment ADT Message Usage Cardinality Chapter CDR Database Table Notes

MSH Message Header R [1..1] 2 N/A

[ { SFT } ] Software Segment X 2

EVN Event Type O 3 Outbound messages only.

PID Patient Identification R [1..1] 3 Patient, Contact [ PD1 ] Additional

Demographics

RE [0..1] 3 Provider, Contact

[ LAN ] Language Detail O 15 Patient The LAN segment is only processed

when LAN-2 is EN (English).

[{ ROL }] Role O 15 Provider

[{ NK1 }] Next of Kin / Associated Parties

O 3 Contact

PV1 Patient Visit RE [0..1] 3 Visit, Location, Provider The PV1 segment is only processed when PV1-19 is present.

[ PV2 ] Patient Visit -Additional Info.

RE [0..1] 3 Visit The PV2 segment is only processed

when PV1-19 is present.

[{ ROL }] Role O 15 Provider Visit Provider

(15)

[{ OBX}] Observation/Result O 7 ObservationResult

[{ AL1 }] Allergy Information O 3 Allergy

[{ DG1 }] Diagnosis Information O 6 [ DRG ] Diagnosis Related Group X 6 [{ --- PROCEDURE begin PR1 Procedures X 6 [{ ROL }] Role X 15 }] --- PROCEDURE end [{ GT1 }] Guarantor O 6 Guarantor [{ --- INSURANCE begin

IN1 Insurance O 6 InsurancePolicy,

InsurancePlan, InsurancePayor [ IN2 ] Insurance Additional

Info.

X 6

[{ IN3 }] Insurance Additional Info - Cert.

X 6

[{ ROL }] Role 15

}] --- INSURANCE end

[ ACC ] Accident Information X 6

[ UB1 ] Universal Bill Information

X 6

[ UB2 ] Universal Bill 92 Information

X 6

4.2 Patient Merge Profile [ADT^A18 / ADT^A40]

4.2.1 Use Case

The A18 event is used to merge current and previous patient records. This procedure is required, for example, when a previous patient is registered under a new patient identification number because of an error, or because there was insufficient time to determine the actual patient identification number. The merge event occurs when a decision is made to combine the information under either the new or the old identifier(s). The PID segment contains the surviving patient ID information. The MRG segment contains the non-surviving information.

Patients can only be merged within the same Assigning Authority (a.k.a Issuer/Organization). The non-surviving patient record(s) are by default. However this behavior can be controlled via the MRG segment.

Patient Linking is defined in section 4.3 under Patient Link Profile.

Both the A18 and A40 trigger events are supported, however they are handled the same way by the CDR.

(16)

4.2.3 Example Message

The following is a sample message for expected ADT^A18 events. This sample also applies to the expected format of ADT^A40 events.

MSH|^~\&|SNDAPP|SNDFAC|RECAPP|RECFAC|20040624153000||ADTÂ18|001|P|2.5| PID|||P123456^^^DPTISS&^^^^^^^|ALT123^^ÂLTISS|DOE&^JOHN^JULIE^JR.^MRS.^PHD|BUCK&^|19690721163000^|F||WHT^|1 23 ANYSTREET^ÂNYTOWN^MOÂNYZIPÛSA^H||+1(905)555-1212^^P^^[email protected]|+1(905)555-3232^Ô^^[email protected]| EN^|M^|ANG^|A456789^^^|SSN12345^|DL123789^|||||1|||FSM^|20050323132900^||FALSE|AL PD1||||001^SMITH MD&^PCP^M^JR^DR^MD^^PCPISS||||||||N ROL|1||PP|001^Provider^Test^^^Dr.^MD^^DO^^^^^Â||||||||

MRG|P123457^^^DPTISS&^true||||||

PV1||I|Left side station^Room3^Bed4^HospitalA&^^^WestBuilding^Floor12^Patient Bed -common^HA-R4B3&LOCISS^CANON&|R|||007^SMITH MD&^ATTEND^^^^^^VISATTISS&|002^SMITH

MD&^REFER^J^JR.^^JD^^VISPROVISS&|008^SMITH MD&^CONSULT^^^^^^VISCONISS&|MED||||1|A0||009^SMITH MD&^ADMIT^^^^^^VISADMISS&||V123456^^^VISISS&|||||||||||||||||||||||||20040623090000^|||||||A PV2|||||||ARR|||||Patient in comatose state

ROL|1||ATN|ATN002^SMITH2 MD&^ATTEND2^M^JR^DR^MD^^VISPROVISSATT&||||||||

AL1||DA|^GENERIC DRUG|SV|HYPOTENS|20050323132900|Y|S|Allergist|AllergySourceSystem OVR|system.doNotAutoCreate^false

4.2.4 Example ACK

(17)

Segment ADT Message Usage Cardinality Chapter CDR Database Table Notes

EVN Event Type X 3

PID Patient Identification R [1..1] 3 Patient, Contact [ PD1 ] Additional Demographics RE [0..1] 3 Provider, Contact [{ ROL }] Role X 15 [{ NK1 }] Next of Kin / Associated Parties X 3

MRG Merge Information R [0..1] 3 N/A (used for logic only)

PV1 Patient Visit RE [0..1] 3 Visit, Location, Provider The PV1 segment is only processed when PV1-19 is present.

[ PV2 ] Patient Visit -Additional Info.

RE [0..1] 3 Visit The PV2 segment is only processed

when PV1-19 is present.

[{ ROL }] Role X 15 Provider Visit provider

[{ DB1 }] Disability Information X 3

[{ OBX }] Observation/Result X 7 ObservationResult

[{ AL1 }] Allergy Information X 3 Allergy

[{ DG1 }] Diagnosis Information X 6 [ DRG ] Diagnosis Related Group X 6 [{ --- PROCEDURE begin PR1 Procedures X 6 [{ ROL }] Role 15 }] --- PROCEDURE end [{ GT1 }] Guarantor X 6 Guarantor [{ --- INSURANCE begin

IN1 Insurance X 6 InsurancePolicy,

InsurancePlan, InsurancePayor [ IN2 ] Insurance Additional

Info.

X 6

[{ IN3 }] Insurance Additional Info - Cert.

X 6

[{ ROL }] Role X 15

(18)

[ UB1 ] Universal Bill Information

X 6

[ UB2 ] Universal Bill 92 Information

X 6

4.3 Patient Link Profile [ADT^A24]

4.3.1 Use Case

The A24 event is used to link 2 patient records. This procedure is required, for example, when a patient is registered under multiple information domains and is therefore represented by multiple MRNs. Linking patient records together indicates they represent the same person and should be treated as such.

4.3.2 Interactions

4.3.3 Example Message

The following is a sample message for expected ADT^A24 events.

MSH|^~\&|SNDAPP|SNDFAC|RECAPP|RECFAC|20040624153000||ADT^A24|001|P|2.5|

PID|||P123456^^^DPTISS&^^^^^^^|ALT123^^ÂLTISS|DOE&^JOHN^JULIE^JR.^MRS.^PHD|BUCK&^|19690721163000^|F||WHT^|1 23 ANYSTREET^ÂNYTOWN^MOÂNYZIPÛSA^H||+1(905)555-1212^^P^^[email protected]|+1(905)555-3232^Ô^^[email protected]

|EN^|M^|ANG^|A456789^^^|SSN12345^|DL123789^|||||1|||FSM^|20050323132900^||FALSE|AL

om

PD1||||001^SMITH MD&^PCP^M^JR^DR^MD^^PCPISS||||||||N ROL|1||PP|001^Provider^Test^^^Dr.^MD^^DO^^^^^^A||||||||

PID|||P456123^^^DPT2ISS&^^^^^^^|ALT321^^^ALTISS|DOE&^JOHN^JULIE^JR.^MRS.^PHD.|BUCK&^|19690721163000^|F||WHT^ |123

(19)

ANYSTREET^ÂNYTOWN^MOÂNYZIPÛSA^H||+1(905)555-1212^|+1(905)555-3232^|EN^|M^|ANG^|A456789^^^|SSN12345^|DL123 789^|||||1|||FSM^|20050323132900^||FALSE|AL PD1||||001^SMITH MD&^PCP^M^JR^DR^MD^^PCPISS|||||||| OVR|issuer.doNotAutoCreate^false

4.3.4 Example ACK

4.3.5 MessageStatic Definition

Segment ADT Message Usage Cardinality Chapter CDR Database Table

Notes

[{ SFT }] Software Segment X 2

EVN Event Type X 3

Demographics

PV1 Patient Visit RE [0..1] 3 Visit, Location,

Provider

The PV1 segment is only processed when PV1-19 is present.

[{ DB1 }] Disability Information X 3

PID Patient Identification 2

R [1..1] 3 Patient, Contact

[ PD1 ] Additional Demographics 2

PV1 Patient Visit 2 RE [0..1] 3 Visit, Location,

Provider

The PV1[2] segment is only processed when PV1[2]-19 is present.

[{ DB1 }] Disability Information 2

X 3

4.4 General Order Profile [ORM^O01]

4.4.1 Use Case

Left for backward compatibility. It is recommended that the OMI trigger event be used instead when communicating orders and order related

events.

The function of this message is to initiate the transmission of information about an order. This includes placing new orders, cancellation of existing orders, discontinuation, holding, etc. ORM messages can originate also with a placer, filler, or an interested third party. Orders encapsulated in an ORM message assume a 1 to 1 relationship between Placer Order, Filler Order, Requested Procedure, and Procedure Step. When an ORM message is processed, one of each of the previously mentioned records is created automatically. To transmit multiple Filler Orders, Requested Procedures, and/or Procedure Steps, use the OMI message.

(20)

4.4.3 Example Message

The following is a sample message for expected ORM^O01 events.

MSH|^~\&|SNDAPP|SNDFAC|RECAPP|RECFAC|20040624153000||ORM^O01|001|P|2.5|

PID|||P123456^^^DPTISS&|ALT123^^ÂLTISS|DOE&^JOHN^JULIE^JR.^MRS.^PHD|BUCK&^|19690721163000^|F||WHT^|123 ANYSTREET^ÂNYTOWN^MOÂNYZIPÛSA^H||+1(905)555-1212^^P^^[email protected]|+1(905)555-3232^Ô^^[email protected]| EN^|M^|ANG^|A456789^^^|SSN12345^|DL123789^|||||1|||FSM^|20050323132900^||FALSE|AL

PD1||||001^SMITH MD&^PCP^M^JR^DR^MD^^PCPISS||||||||N LAN|1|EN||1

ROL|1||PP|001^Provider^Test^^^Dr.^MD^^DO^^^^^^A||||||||

PV1||I|Left side station^Room3^Bed4^HospitalA&^^^WestBuilding^Floor12^Patient Bed -common^HA-R4B3&LOCISS^CANON&|R|||002^SMITH MD&^ATTEND^M^JR^DR^MD^^VISPROVISSATT&|001^SMITH

MD&^REFER^J^JR.^DR^JD^^VISPROVISS&|003^SMITH MD&^CONSULT^M^JR^DR^MD^^VISPROVISSCON&|MED||||1|A0||004^SMITH MD&^ADMIT^M^JR^DR^MD^^VISPROVISSADM&||V123456^^^VISISS&|||||||||||||||||||||||||20040623090000^|||||||A PV2|||||||ARR|||||Patient in comatose state

ROL|1||ATN|ATN002^SMITH2 MD&ÂTTEND2^M^JR^DR^MD^^VISPROVISSATT&|||||||| AL1||DA|^GENERIC DRUG|SV|HYPOTENS|20050323132900|Y|S|Allergist|AllergySourceSystem GT1||G-NUM|Doe^JaneÂÎV^Miss^Ph.D.||4 Oak Blvd..^^Tampa^FL^45725ÛSA|3331114444|9998884444|19980323132900|M||FTH|5555555|20060323|20080321||Smith^Davi d^M^Jr.^Mr.^PHD|8 Main St.^^Detroit^MC^45725ÛSA|1115553333|EMPID|1|||||||||||||||||||||||||Doe^JohnÔ^Jr.^Mr.^P.Eng.|1115553333||S PO

IN1||PLAN^Generic InsurancePlan|PAYOR^^^PAISS^ÔfficeId|Insurer's|72 Elm St.Ôffice Name^Burbank^CA^90210ÛSA^BÔTHDESIG|Employee^JoeÂÎII^Mr.^Ph.D.^C|5555555555|GRP#|Group Name|GRPJOE|Group|20020323132900|20070323132900|AUTH#|TYPE|Patient^Test^L^Sr.^Mrs.^M.A.Sc.^P|EME|20050528|8 River St.^^Fort Worth^TX^84235ÛSA^PÔTHDESIG|N|IN|1|||||||20060517121200|Verifier|S||||COPLANCD|XX0001100|100|10000|4|||1|M |||XXOLD|H ORC|NW|PO123456^POISS|FO456789^FOISS^DO||SC&SC||1||20040709113600^|005^SMITH

(21)

MD&^ENTBY^^JR^DR^MD^^ORDISS&|025^SMITH MD&^VERIFIEDBY^^JR^DR^MD^^VERFISS&||Pod 1^Room A11^Bed 3A1^CT-FAC&^^^^^CT-Ward^LOC1&ENTISS|+1(905)555-2323|||||015^SMITH

MD&^ACTIONBY^^JR^DR^MD^^ACTISS&||||||||20070323132900

OBR|1|||CTHEAD^CT of the Head^SNOMED|R|||||||SARS^|RECURRENCE|||006^SMITH MD&^ORDPROV^^JR^DR^MD^^ORDPROVISS&||||||||||||006^SMITH

MD&^ORDPROV^^JR^DR^MD^^ORDPROVISS&||WALK|COLD^|||010&SMITH MD&RESULT

TECHNICIAN&&JR.&DR&JD&&RESTECHISS^||20040714091500^|||DDX^Test performed to rule out SARS^SNOMED|Stat

Contact Name^1-800-555-STAT^Stat Type|A|||CTHEAD^CT of the Head^SNOMED|NC^No contrast media^SNOMED&CON|NC^No contrast media^SNOMED&CON

CTD|ENT|||Pod 1^Room A11^Bed 3A1^CT-FAC&^^^^^CT-Ward^LOC1&ENTISS^CANON|

ZRP|1|SCH|SCH|S^^X|false|SourceRIS|ArchivePACS|||America/New_York|ReportSystem||||||AddtionalImagingSystem^2 0131003140000 BLG||GR|258147 OVR|issuer.doNotAutoCreate^false

4.4.4 Example ACK

4.4.5 Message Static Definition

Segment ORM Message Usage Cardinality Chapter CDR Database Table Notes

[ --- PATIENT begin PID Patient Identification R [1..1] 3 Patient, Contact [ PD1 ] Additional Demographics RE [0..1] 3 Provider, Contact [ ---PATIENT_VISIT begin

PV1 Patient Visit RE [0..1] 3 Visit, Location, Provider The PV1 segment is only

processed when PV1-19 is present.

[ PV2 ] Patient Visit-Additional Info

RE [0..1] 3 Visit The PV2 segment is only

[{ ROL }] Role O 15 Provider Visit provider

]

---PATIENT_VISIT end

[{ --- INSURANCE begin

IN1 Insurance X InsurancePolicy, InsurancePlan,

(22)

[ GT1 ] Guarantor X Guarantor

[{ AL1 }] Allergy Information X Allergy

] --- PATIENT end

ORC Common Order R [1..1] 4 PlacerOrder, FillerOrder,

RequestedProcedure, ProcedureStep, Provider, Location

[ --- Procedure begin

[1..1]

OBR Order Detail Segment OBR, etc.

RE [0..1] 4 PlacerOrder, FillerOrder,

[{ ROL }] Role O 15 Provider Order provider

[ZRP] Medicalis Requested Procedure

RE [0..1] FillerOrder, RequestedProcedure, ProcedureStep

Vendor specific segment.

]

4.5 Imaging Order Profile [OMI^O23]

4.5.1 Use Case

This message is used in communication between the information systems involved in the fulfillment of the request directed to the imaging department, such as a Radiology Information System (RIS) and a Picture Archiving and Communication System (PACS). The order for the imaging service is communicated between the Order Placer (such as an Order Entry system) and the Order Filler (such as an RIS). In the imaging department environment, the Order Filler also identifies the set of procedures (studies) and sub-procedures (procedure steps) that have to be performed in the process of fulfilling the order. Each sub-procedure is performed using a single device (station). The Order Filler identifies the type of device and either a specific device or group of devices (for example, by geographic location) one of which is to be used in performing the procedure step.

Orders encapsulated in a CDR OMI message support a single Placer Order, with a single Filler Order, made up of many Requested Procedures, and many Procedure Steps. When an OMI message is processed, one of each of the previously mentioned records is created automatically. However many can be created be transmitting many OBR, ZRP, and IPC segment sequences.

Each OMI message shall convey information about Requested Procedure(s) pertaining to one order. Segment OBR shall correspond to each requested procedure. If the Requested Procedure is comprised of multiple Procedure Steps, multiple IPC segments shall be included for each OBR in the message. In this case, the value of the IPC-2 field shall be identical in all IPC segments related to the same Requested Procedure.

(23)

4.5.3 Example Message

The following is a sample message for expected OMI^O23 events. This example shows a single Placer Order, Filler Order, Requested Procedure, and one Procedure Step.

MSH|^~\&|SNDAPP|SNDFAC|RECAPP|RECFAC|20040624153000||OMI^O23|001|P|2.5|

PID|||P123456^^^DPTISS|ALT123^^ÂLTISS|DOE&^JOHN^JULIE^JR.^MRS.^PHD|BUCK&^|19690721163000^|F||WHT^|123 ANYSTREET^ÂNYTOWN^MOÂNYZIPÛSA^H||+1(905)555-1212^^P^^[email protected]|+1(905)555-3232^Ô^^[email protected]| EN^|M^|ANG^|A456789^^^|SSN12345^|DL123789^|||||1|||FSM^|20050323132900^||FALSE|AL

(24)

MD&ÊNTBY^^JR^DR^MD^ÔRDISS&|025^SMITH MD&^VERIFIEDBY^^JR^DR^MD^^VERFISS&|||+1(905)555-2323|||||015^SMITH MD&ÂCTIONBY^^JR^DR^MD^ÂCTISS&||||||||20070323132900

OBR|1|||CTHEAD^CT of the Head^SNOMED|R|||||||SARS^|RECURRENCE|||006^SMITH MD&^ORDPROV^^JR^DR^MD^^ORDPROVISS&||||||||||||006^SMITH

MD&^ORDPROV^^JR^DR^MD^^ORDPROVISS&||WALK|COLD^|||010&SMITH MD&RESULT

TECHNICIAN&&JR.&DR&JD&&RESTECHISS^||20040714091500^|||DDX^Test performed to rule out SARS^SNOMED|Stat

Contact Name^1-800-555-STAT^Stat Type|A|||CTHEAD^CT of the Head^SNOMED|NC^No contrast media^SNOMED&CON|NC^No contrast media^SNOMED&CON

CTD|ENT|||Pod 1^Room A11^Bed 3A1^CT-FAC&^^^^^CT-Ward^LOC1&ENTISS^CANON|

ZRP|1|SCH|SCH|S^X|false|SourceRIS|ArchivePACS|||America/New_York|ReportSystem||||||AddtionalImagingSystem^20 131003140000 IPC|ACN124680^|RPID864280^|1234.9483.1231.3908^|SPSID573827^|CT01||STSTN|CTRM04^^RESISS|CT-1001 BLG||GR|258147 OVR|system.doNotAutoCreate^false

4.5.4 Example ACK

4.5.5 Message Static Definition

Segment OMI Message Usage Cardinality Chaper CDR Database Table Notes

[ --- PATIENT begin

Demographics

[ --- PATIENT_VISIT begin

] --- PATIENT_VISIT end

InsurancePayor }] --- INSURANCE end

[ GT1 ] Guarantor X Guarantor

(25)

] --- PATIENT end

{ --- ORDER begin [1..1]

{ --- REQUESTED PROCEDURE begin

[1..*]

OBR Observation RE [1..1] 4 PlacerOrder, FillerOrder,

[{ RQD }] Requisition Detail CompletableSupply Only supported in messages

out of application [{ RXD }] Pharmacy/Treatment

Dispense

AdministeredPharmaceutical, Pharmac eutical

Only supported in messages out of application

[{ RXA }] Pharmacy/Treatment Administration

AdministeredPharmaceutical, Pharmac eutical

{ IPC } Imaging Procedure Control

R [1..*] FillerOrder, RequestedProcedure, ProcedureStep

{ ZOF} Online Form Data [0..*] Outbound only

} --- REQUESTED PROCEDURE end

[{ FT1 }] Financial Transaction CompletableOtherCharge Only supported in messages

out of application

} --- ORDER end

4.6 Result Profile [ORU^R01]

4.6.1 Use Case

This event is used to communicate an imaging report. The CDR attaches the results contained in the OBX segments of this message to all Requested Procedures specified in the message. If a result needs to be attached to only a single Requested Procedure, then a message containing only that RP must be transmitted. Furthermore, the CDR assumes that the first Result Identifier located in the first OBX segment (OBX-3.1) is the same result identifier for all subsequent OBX segments. If multiple results need to be transmitted, they must be sent in separate messages.

When sending Addendum messages Medicalis required the entire report text in the OBX segments, not just the amended text.

(26)

4.6.3 Example Message

The following is a sample message for expected ORU^R01 events.

MSH|^~\&|SNDAPP|SNDFAC|RECAPP|RECFAC|20040624153000||ORU^R01|001|P|2.5|

(27)

MD&ÊNTBY^^JR^DR^MD^ÔRDISS&|025^SMITH MD&^VERIFIEDBY^^JR^DR^MD^^VERFISS&|||+1(905)555-2323|||||015^SMITH MD&ÂCTIONBY^^JR^DR^MD^ÂCTISS&||||||||20070323132900

OBR|1|||71020^CHEST XRAY AP \T\

LATERAL^SNOMED|R||198703290800|||9218^MASTERS^JOHN^B||SARS^|RECURRENCE|||006^SMITH MD&^ORDPROV^^JR^DR^MD^^ORDPROVISS&||||||20050528191904^|||P|||006^SMITH

MD&^ORDPROV^^JR^DR^MD^^ORDPROVISS&||WALK|COLD^|007&SMITH MD&PRINCIPAL RESULT INTERPRET&&JR.&DR&JD&&PRINCRESINTREPISS^|008&SMITH MD&ASSISTANT RESULT

INTERPRET&&JR.&DR&JD&&ASSISRESINTREPISS^|010&SMITH MD&RESULT TECHNICIAN&&JR.&DR&JD&&RESTECHISS^|009&SMITH MD&RESULT TRANSCRIPT&&JR.&DR&JD&&RESTRANSISS^|20040714091500^|||DDX^Test performed to rule out

SARS^SNOMED|Stat Contact Name^1-800-555-STAT^Stat Type|A|||71020^CHEST XRAY AP \T\

LATERAL^SNOMED|ACÂdminister contrast media^SNOMED&CON|ACÂdminister contrast media^SNOMED&CON ROL|1||AST|AST008^SMITH2 MD&ÂSSISTANT RESULT INTERPRET2^M^JR^DR^MD^ÂSSISRESINTREPISS7&|||||||| CTD|ENT|||Pod 1^Room A11^Bed 3A1^CT-FAC&^^^^^CT-Ward^LOC1&ENTISS^CANON|

ZRP|1|PRE|COM|P^P,S,I,U,V,C,R,D^|false|SourceRIS|ArchivePACS|||America/New_York|ReportSystem||||||AddtionalI magingSystem^20131003140000

IPC|ACN124680^|RPID864280^|1234.9483.1231.3908^|SPSID573827^|CT01||STSTN|CTRM04^^RESISS|CT-1001 OBX|1|CE|71020&IMP^RADIOLIOGIST'S REPORT^RISISSID|1|^MASS LEFT LOWER LOBE|||A|||P|||198703290800^ NTE|1||lab result comment|RE

BLG||GR|258147

OVR|system.doNotAutoCreate^false

4.6.4 Example ACK

4.6.5 Message Static Definition

Segment ORU Message Usage Cardinality Chapter CDR Database Table Notes

[ --- PATIENT begin

Demographics

[ --- PATIENT_VISIT begin

] --- PATIENT_VISIT end

InsurancePayor }] --- INSURANCE end

(28)

[{ AL1 }] Allergy Information X Allergy ] --- PATIENT end

{ --- ORDER begin [1..1]

{ --- REQUESTED PROCEDURE begin

[1..*]

OBR Observation RE [1..1] 4 PlacerOrder, FillerOrder,

[{ RQD }] Requisition Detail CompletableSupply Only supported in messages

out of application [{ RXD }] Pharmacy/Treatment

Dispense

AdministeredPharmaceutical, Pharmaceutical

[{ RXA }] Pharmacy/Treatment Administration

AdministeredPharmaceutical, Pharmaceutical

[{ ROL }] Role O 15 Provider Order provider

{ IPC } Imaging Procedure Control

RE [1..*] FillerOrder, RequestedProcedure, ProcedureStep

[{ --- OBSERVATION begin

OBX Observation related to OBR

RE [0..*] 7 Result, ResultSection, Provider

}] --- OBSERVATION end

} --- REQUESTED PROCEDURE end

{ ZOF } Online Form Data [0..*] Outbound only

[{ FT1 }] Financial Transaction CompletableOtherCharge Only supported in messages

out of application

} --- ORDER end

4.7 Update Personnel Record [PMU^B02]

4.7.1 Use Case

Provider registry updates transmit demographic updates for personnel. The CDR uses the PMU message to updates its internal provider database.

(29)

4.7.3 Example Message

The following is a sample message for expected PMU^B02 event.

MSH|^~\&|SNDAPP|SNDFAC|RECAPP|RECFAC|200406241530||PMU^B02|001|P|2.5|

STF||PROVID2^^^PROVIS|Smith&&NA^JohnsonÂ^BASc|||||||^^^[email protected]^^^^^WP^^^1-905-555-5555|9 Straight Road&&Apartment 1^^Beverly Hills^CA^90210ÛSAÔ^WTF|^&Medicalis

PRA|||AD NTE|||Notes EDU||BE

4.7.4 Example ACK

4.7.5 Message Static Definition

Segment PMU Message Usage Cardinality Chapter CDR Database Table Notes

EVN Event Type X 3

STF Staff R [1..1] 15 Provider, Contact

(30)

[ { ORG } ] Organization X 15

[ { AFF } ] Affiliation X 15

[ { LAN } ] Language X 15

[ EDU ] Education RE [0..1] 15 Provider

[ { CER } ] Certificate X 15

[ NTE ] Note RE [0..1] Provider

4.8 Inventory Item Master File Message [MFN^M15]

4.8.1 Use Case

This event is used to communicate information that relates to the inventory of modalities that can be used to perform an ordered service in the CDR.

4.8.2 Interactions

4.8.3 Example Message

The following is a sample message for expected MFN^M15 event.

MSH|^~\&|SNDAPP|SNDFAC|RECAPP|RECFAC|200406241530||MFN^M15|001|P|2.5|

IIM|MR-10113^^GE|MR-LAB1-1^Lab 1 - station 1^^192.168.13.101|||GE103396^General Electric^^^^^1.113|^MR Laboratory - 1||||||||MS

(31)

4.8.4 Example ACK

4.8.5 Message Static Definition

Segment MFN Message Usage Cardinality Chapter CDR Database Table Notes

MFI Master File Identification X 8

{ --- MF_INV_ITEM begin X

MFE Master File Entry X 8

IIM Inventory Item Master R [1..1] 8 Modality

} --- MF_INV_ITEM end X

4.9 Patient Location Master File Message [MFN^M05]

4.9.1 Use Case

This section is specifically concerned with describing a master file message that should be used to transmit information which identifies the inventory of resources and the healthcare patient locations, such as nursing units, rooms, beds, clinics, exam rooms, etc, that each resource exists in. In a network environment, this segment can be used to define resources and locations to other applications.

(32)

4.9.3 Example Message

MSH|^~\&|SNDAPP|SNDFAC|RECAPP|RECFAC|200406241530||MFN^M05|001|P|2.5| LOC|^^^^^^^^^RCSCID&ISSID|This is a resource

LCH|^^^^^^^^^LOCID^LOCISS&CANON

4.9.4 Example ACK

4.9.5 Message Static Definition

MFI Master File Identification X

{ --- MF_LOCATION begin [1..*]

LOC Patient Location Master R [1..1] 8 Resource

[{ LCH }] Location Characteristic RE [0..1] 8 Location

(33)

{ --- MF_LOC_DEPT begin

LDP Location Department X 8

[{ LCH }] Location Characteristic X 8

[{ LCC }] Location Charge Code X 8

} --- MF_LOC_DEPT end

} --- MF_LOCATION end

4.10 Additional Basic Observation/Service Attributes [MFN^M12]

4.10.1 Use Case

This event deals with updating the CDR exam code dictionary.

4.10.2 Interactions

4.10.3 Example Message

MSH|^~\&|SNDAPP|SNDFAC|RECAPP|RECFAC|200406241530||MFN^M12|001|P|2.5|

OM1||D405Âbdominal UltrasoundÎ9||||||||||||||||||LANDSCAPE||||||||||||||||||||||||||ADBÂbdomen|US OM7|||AS

(34)

4.10.4 Example ACK

4.10.5 Message Static Definition

[{ SFT }] Software X

MFI Master File Identification

{ --- MF_OBS_ATTRIBUTES begin X [1..*] 8

OM1 General Segment (Fields That Apply to Most Observations) R [1..1] 8 Exam [ OM7 ] Other Basic Observation/Service Attributes RE [0..1] 8 Exam } --- MF_OBS_ATTRIBUTES end

4.11 Medical Document Management Profile [MDM^T02 / MDM^T04 / MDM^T08 /

MDM^T11]

4.11.1 Use Case

This event is used to communicate new or updated documents or information about document status.

(35)

4.11.3 Example Message – Document Edit Notification

The following is a sample message for expected MDM^T08 events.

MSH|^~\&|SNDAPP|SNDFAC|RECAPP|RECFAC|20040624153000||MDM^T08|001|P|2.5|

ORC|NW|PO123456^POISS|FO456789^FOISS^DO||SC&SC||1||20040709113600^|005^SMITH MD&ÊNTBY^^JR^DR^MD^ÔRDISS&|025^SMITH MD&^VERIFIEDBY^^JR^DR^MD^^VERFISS&|||+1(905)555-2323|||||015^SMITH MD&ÂCTIONBY^^JR^DR^MD^ÂCTISS&||||||||20070323132900 OBR|1|||71020^CHEST XRAY AP \T\ LATERAL^SNOMED|R||198703290800|||9218^MASTERS^JOHN^B||SARS^|RECURRENCE|||006^SMITH MD&ÔRDPROV^^JR^DR^MD^ÔRDPROVISS&||||||20050528191904^|||P|||006^SMITH

MD&^ORDPROV^^JR^DR^MD^^ORDPROVISS&||WALK|COLD^|007&SMITH MD&PRINCIPAL RESULT INTERPRET&&JR.&DR&JD&&PRINCRESINTREPISS^|008&SMITH MD&ASSISTANT RESULT

INTERPRET&&JR.&DR&JD&&ASSISRESINTREPISS^|010&SMITH MD&RESULT TECHNICIAN&&JR.&DR&JD&&RESTECHISS^|009&SMITH MD&RESULT TRANSCRIPT&&JR.&DR&JD&&RESTRANSISS^|20040714091500^|||DDX^Test performed to rule out

SARS^SNOMED|Stat Contact Name^1-800-555-STAT^Stat Type|A|||71020^CHEST XRAY AP \T\

LATERAL^SNOMED|AC^Administer contrast media^SNOMED&CON|AC^Administer contrast media^SNOMED&CON

ZRP|1|PRE|COM|P^P,S,I,U,V,C,R,D^|false|SourceRIS|ArchivePACS|||America/New_York|ReportSystem||||||AddtionalI magingSystem^20131003140000