IRADIMED 3880 MRI Patient Monitoring Device Integration Guide

Table of Contents 1.

HL7 NETWORK SETUP ... 4 1.1. Intended Audience ... 4 1.2. LAN System Requirements ... 4 1.3. LAN Export ... 4 1.4. Enabling the 3880 LAN Data Export ... 4 1.4.1. Step 1: 3880 System Setup... 4 1.4.2. Step 2: Enter Service Mode ... 5 1.4.3. Step 3: Configure the Data Interval Rate ... 6 1.4.4. Step 4: Enable Data Output ... 6 1.4.5. Step 5: Enable Patient Identity ... 6 1.4.6. Step 6: Synchronize the System Clock ... 6 1.4.7. Step 7: Set the IP Assignment ... 7 1.4.8. Step 8: Configure the Network ... 7 1.4.9. Step 9: Confirm Communication ... 7 1.4.10. Step 10: Optional Patient Admission ... 7 1.5. Terms and Acronyms ... 8

2.

HL7 MESSAGE CONVENTIONS ... 9 2.1. Notation Conventions ... 9 2.2. Block Format ... 9

3.

DATA EXPORT COMMUNICATION ... 10 3.1. TCP / IP Communication... 10 3.1.1. MLLP – Minimum Lower Layer Protocol...10 3.2. Acknowledgement ... 10 3.2.1. ACK Formation ...10 3.3. Delimiter Characters ... 11 3.4. Segment Data Fields ... 12 3.4.1. Position ...12 3.4.2. Maximum Length ...12 3.4.3. Data Type ...12 3.4.4. Optionality ...12

4.

MESSAGE PROFILE OVERVIEW ... 16 4.1. Unsolicited Observation Reporting (ORU) Message Syntax ... 16 4.2. Segment Naming Convention ... 16 4.3. ORU Message Segments ... 16 4.4. Flow of Events... 17 4.5. Profiles Supported ... 17 4.6. Reference Documents ... 17

5.

OBSERVATION RESULTS INTEGRATION PROFILE (ORU) ... 18 5.1. Results Profile [ORU^R01] ... 18 5.1.1. Use Case...18 5.1.2. Actors ...18

IRadimed 3880 Device Integration Guide

2

5.1.3. 5.1.4. 5.1.5. 5.1.6. 6.

Message ...18 ORU Message Static Definition...18 Message Acknowledgement ...19 Example HL7 Messages ...19

SEGMENT STATIC DEFINITIONS ... 20 6.1. Message Header (MSH) Segment ... 20 6.2. Patient Identification (PID) Segment... 21 6.3. Patient Visit (PV1) Segment... 22 6.4. Observation Request (OBR) Segment ... 24 6.5. Observation/Result (OBX) Segment ... 26

7.

FIELD DEFINITIONS ... 28 7.1. MSH Field Definitions ... 28 7.1.1. MSH-1 Field Separator (ST) 00001...28 7.1.2. MSH-2 Encoding Characters (ST) 00002 ...28 7.1.3. MSH-3 Sending Application (HD) 00003 ...28 7.1.4. MSH-7 Date/Time of Message (DTM) 00007 ...28 7.1.5. MSH-9 Message Type (MSG) 00009 ...28 7.1.6. MSH-10 Message Control ID (ST) 00010 ...28 7.1.7. MSH-11 Processing ID (PT) 00011 ...29 7.1.8. MSH-12 Version ID (VID) 00012 ...29 7.1.9. MSH-15 Accept Acknowledgment Type (ID) 00015 ...29 7.1.10. MSH-16 Application Acknowledgment Type (ID) 00016 ...29 7.1.11. MSH-18 Character Set (ID) 00692 ...30 7.2. PID Field Definitions ... 30 7.2.1. PID-3 Patient Identifier List (CX) 00106 ...30 7.2.2. PID-5 Patient Name (XPN) 00108 ...31 7.3. PV1 Field Definitions ... 31 7.3.1. PV1-2 Patient Class (IS) 00132...31 7.3.2. PV1-3 Assigned Patient Location (PL) 00133 ...31 7.3.3. PV1-18 Patient Type (IS) 00148 ...32 7.4. OBR Field Definitions ... 32 7.4.1. OBR-4 Universal Service Identifier (CWE) 00238 ...32 7.4.2. OBR-7 Observation Date/Time (DTM) 00241...33 7.5. OBX Field Definitions ... 33 7.5.1. OBX-1 Set ID - OBX (SI) 00569 ...33 7.5.2. OBX-2 Value Type (ID) 00570 ...33 7.5.3. OBX-3 Observation Identifier (CWE) 00571 ...34 7.5.4. OBX-5 Observation Value (varies) 00573 ...34 7.5.5. OBX-6 Units (CWE) 00574 ...34 7.5.6. OBX-11 Observation Result Status (ID) 00579 ...34 7.6. Acknowledgment (ACK) Message Syntax ... 35 7.7. Medical Device Interface Language Codes ... 35 7.7.1. Sample HL7 Message with MDIL (or MDC) coding system ...37

IRadimed 3880 Device Integration Guide

3

1. HL7 Network Setup The 3880 System equipped with the optional 3885-B Base Station can export patient data to a receiving HIS / EMR system through the LAN in the MRI control room. The exported patient data sent in messages that comply with the Health Level Seven (HL7) standard and includes vital signs measurements and patient identifying information displayed on the 3880 MRI Patient Monitoring System. This document describes the syntax and structure of the HL7 messages used for patient records exchanged. NOTE • Users attempting to interface the 3880 digital data with an information system should be familiar with HL7 2.6 standard.

1.1. Intended Audience Programmers who want to develop an internal application that will receive the data exported from the IRadimed 3885-B. Programmers should be familiar with HL7 version 2.6.

1.2. LAN System Requirements The 3880 system exports patient data over a wired local area network (LAN) using the TCP/IPv4 transport protocol. The receiving system must meet the following conditions: • Ethernet TCP / IPv4 • Cat 5, RJ-45 or better network cables

1.3. LAN Export The IRadimed 3880 can output the data in either of these 2 methods: • Unconditionally, whether or not a patient is entered • Only when a user Admits a patient into the 3880 System

1.4. Enabling the 3880 LAN Data Export After you configure the TCP / IP address of the designated server and enable the Data Ouput settings, the system can begin exporting patient records. To interface the 3880 System with the HIS / EMR system follow the steps below:

1.4.1. Step 1: 3880 System Setup Before the 3880 System can start outputting data it must be correctly setup first. Please refer to the operator’s manual (P/N 1200) for information on how to synchronize the IRadimed system on the same wireless channel. 1. Ensure all 3880 system components are synchronized wirelessly 2. Ensure the Base station is connected to the hospital LAN in the MRI control room using an RJ-45 Ethernet cable

IRadimed 3880 Device Integration Guide

4

Ethernet Connector

1.4.2. Step 2: Enter Service Mode 1. Press the “SETTINGS” button 2. Select “Service Mode” and enter passcode 3. Select “HL7 / Network” Setup You should now see a menu similar to figure A below. Please reference this menu for steps 3 – 9.

Figure A

IRadimed 3880 Device Integration Guide

5

1.4.3. Step 3: Configure the Data Interval Rate Access the drop-down menu associated with the Data Interval Rate. This is the frequency that the 3880 System will export records to the Hospital HIS. The interval choices are: • Every 1 Second • Every 30 Seconds • Every 1 Minute • Every 5 Minutes • Every 10 Minutes • Every time a new NIBP Measurement is displayed

1.4.4. Step 4: Enable Data Output Data Output is defaulted to be disabled from the factory. To enable the Data Output feature access the drop-down menu and select one of the following: • Disabled – Does not output any records • Admission – Only outputs records when the clinician successfully “admits” the patient • Always – Data will be sent unconditionally at the configured interval even when a patient is not admitted

1.4.5. Step 5: Enable Patient Identity By default, the 3880 system exports the patient’s identity and location. To control the appearance of the patient’s identity in the HL7 output access the associated drop-down menu. • De-Identify: OFF – This outputs the patient’s name and location • De-Identify: ON – This does not send the patient’s name and location

1.4.6. Step 6: Synchronize the System Clock The 3880 System clock can be synchronized to a central clock on the hospitals HIS server or interface engine or be set independently. • Independent Clock Management – Select “OFF” under the HL7 Time Sync menu. Reference the Operator’s Manual to set the system clock manually. • HL7 Time Sync – Select “ON” under the HL7 Time Sync menu to allow the 3880 to automatically adjust the system clocks to the hospitals server. During the data export process, the 3880 system sends patient data to the receiving system, and then expects an Acknowledgement (ACK) message from the receiving system indicating that the patient data was received and validated. The Message Header (MSH) segment of the ACK message contains a timestamp, shown in bold type in the following example: MSH|^~&|||||20090101002459||ACK^^ACK_ALL|398098728972|P|2.4 Upon receiving the ACK message, the 3880 System retrieves the timestamp sent by the receiving system and then updates the system clock if the difference is greater than 3 seconds.

IRadimed 3880 Device Integration Guide

6

1.4.7. Step 7: Set the IP Assignment The IP address can be set manually by the user or automatically through a DCHP protocol. To adjust this setting access the drop-down menu associated with “IP Assignment”. • Static – When Static is selected the IP address, Subnet Mast and Gateway; must be manually configured. • DHCP – When DHCP is selected the IP address will automatically be assigned.

1.4.8. Step 8: Configure the Network Using the onscreen numeric keypad type in the following information by selecting each input box and selecting the “Enter” button after each input: • HIS Server IP • HIS Server Port For Static Configured systems you must also input the following data: • IP Address • Subnet Mast • Default Gateway

1.4.9. Step 9: Confirm Communication Reference the top of the HL7 / Network setup menu and reference the following areas: • Link Status o Up: Ethernet link is established o Down: No Ethernet link • HIS Status o Connected: LAN connection has been established and will output data o Not Connected: LAN connection has not been established and will not output data Example below:

1.4.10. Step 10: Optional Patient Admission If the 3880 system is set to Admission you will need to admit a patient before the system will output data. • Exit the service menu • select the Patient Information Bar at the top of the 3880 running screen • Enter characters into the fields with the onscreen keyboard • Press Admit Button to start

IRadimed 3880 Device Integration Guide

7

1.5. Terms and Acronyms Term or Acronym EMR MRI HL7 IHE MSH PID PV1 OBR OBX ORU RIS HIS MLLP

IRadimed 3880 Device Integration Guide

Meaning Electronic Medical Record Magnetic Resonance Imaging Health Level 7 Integrating the Healthcare Enterprise Message Header Segment Patient ID Segment Patient Visit Segment Observation Request Segment Observation Result Segment Observation Results – Unsolicited Message Radiology Information System Hospital Information System Minimal Lower Layer Protocol

8

2. HL7 Message Conventions This section describes the format and conventions used in the HL7 messages used by the IRadimed 3880 System

2.1. Notation Conventions The HL7 messages use the following notation conventions: • Single ASCII characters are enclosed in single quotes. • Special characters or non-printing ASCII characters are enclosed in angle brackets, < >. Special characters are the Lower Layer Protocol (LLP) Start Block and End Block characters. Nonprinting ASCII characters can be written as abbreviations; for example, ESC for the Escape character. They also may be written as hex values in the form 0xXX, where X is a hexadecimal digit. For example, in Standard ASCII, <ESC> is <0x1B>. • The HL7 Minimal Lower Layer Protocol is used to mark message boundaries. Because TCP/IP is a byte-stream protocol and does not provide messaging boundaries, a wrapping protocol is required to recognize the start and end of HL7 messages. HL7, the standard for the upper-level protocol, is based on messages, but does not provide a mechanism to detect message termination.

2.2. Block Format HL7 messages are enclosed by special characters to form a block. The format is as follows: <SB>ddddd<EB><CR> where: <SB> = Start Block character (1 byte). The ASCII vertical tab character <VT>, for example, <0x0B>. Do not confuse this with the ASCII characters SOH or STX. ddddd = Data (variable number of bytes). This is the HL7 data content of the block. The data can contain any ASCII characters and the carriage return character, <CR>, as a delimiter of individual message segments. UTF-8encoding is used for languages that cannot use ASCII characters. <EB> = End Block character (1 byte). The ASCII field separator character <FS>, for example, <0x1C>. Do not confuse this with the ASCII characters ETX or EOT. <CR> = Carriage Return (1 byte). The ASCII carriage return character, for example, <0x0D>.

IRadimed 3880 Device Integration Guide

9

3. Data Export Communication The data communication elements related to the HL7 message profile contain the fundamental structure detailed in this section.

3.1. TCP / IP Communication The Hospital Information System (HIS) acts as server and the IRadimed 3880 System acts as client. Clients initiate communication sessions. Each client uses a TCP/IP socket connection to communicate. 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.6). Also, each message must be terminated with a message separator sequence according to the MLLP (Minimal Lower Layer Protocol).

3.1.1. MLLP – Minimum Lower Layer Protocol A set of special wrapping characters enclose an HL7 message, as defined in the table below. Name Start Block

Symbol <SB>

Suggested Value (Hex) 0x0B

End Block

<EB>

0x1C

Carriage Return

<CR>

0x0D

Purpose Marks the beginning of a message (immediately precedes the MSH segment) Marks the end of a message. Also marks the end of a message (follows the End Block)

These characters wrap a message as follows: <SB>MSH|…sample…<EB><CR> As noted in the table above, the HL7 specification defines hex characters 0x1C0D as the default separator sequence.

3.2. Acknowledgement The receiving system must acknowledge each message by returning an acknowledgment message to the sending system. The IRadimed 3880 system consumes ACK messages. The IRadimed 3880 system ignores ACKs except to process time sync on occasion.

3.2.1. ACK Formation In accordance with the HL7 2.6 specification, the receiving application 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

IRadimed 3880 Device Integration Guide

10

the initial message described above. In particular, MSH-7-date/time of message and MSH10-message control ID refer to the response message; they are not echoes of the fields in the initial message. MSH-5receiving application, MSH-6-receiving facility, and MSH-11processing ID contain codes that are copied from MSH-3-sending application, MSH-4sending 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. Field MSA-1-acknowledgment code

MSA-2-message control ID MSA-3-text message

Notes The receiving system guarantees delivery of the message(s) by sending the ACK code in this field. Application Acknowledgement Codes include: • AA – Application Accepted • AR – Application Rejected • AE – Application Error MSH-10-message control ID from MSH segment of incoming message. Further describes an error condition

3.3. Delimiter Characters The delimiter characters that are normally used in HL7 messages are listed below. An HL7 message can choose to use different delimiter characters if the standard characters are not convenient to use. In any HL7 message, the delimiter characters that the message is using are specified as the first field of the MSH segment (i.e., MSH.2 [every HL7 message must include an MSH segment, and that the MSH segment must be the first segment of the message]). If the message is using the default delimiter characters, the MSH segment of the message starts with the following: MSH|^~& Character <CR>

Sequence -

Name Segment Terminator

|

F

Field Separator

^

S

Component Separator

~

R

Repetition Separator

E

Escape Character

IRadimed 3880 Device Integration Guide

Purpose Terminates a segment record. This value cannot be changed by implementers. Separates two adjacent data fields within a segment. It also separates the segment ID. Separates adjacent components of data fields where allowed. Separates multiple occurrences of a field where allowed. 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. Best practice is to

11

&

T

Subcomponent Separator

Xdddd or Xdd

Hexadecimal Data

always include this character. Separates adjacent subcomponents of data fields where allowed. If there are no subcomponents, this character may be omitted. Best practice is to always include this character. Represents a character defined by its hexadecimal value. Example X0047 is the letter “G”. This can also be escaped as X47.

3.4. Segment Data Fields Each message segment description contains the following data fields:

3.4.1. Position Is the ordinal position of the data field within the segment. This number is used to refer to the data field in the text comments that follow the segment definition table. In the segment attribute tables, this information is provided in the column labeled SEQ.

3.4.2. Maximum Length Is the maximum number of characters that one occurrence of the data field may occupy. In the segment attribute tables, this information is in a column labeled LEN.

3.4.3. Data Type Is the basic building block used to construct or restrict the contents of a data field. In the segment attribute tables, this information is provided in the column labeled DT. If the data type of the field is variable, the notation “varies” will be displayed.

3.4.4. Optionality Determines if the field is required, optional, or conditional in a segment. In the segment attribute tables, this information is provided in the column labeled OPT. Value Description 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

IRadimed 3880 Device Integration Guide

12

Value B

W

Description The field definitions following the segment attribute table should denote the optionality of the field for prior versions. (Retained for backward compatibility with previous versions of HL7.) Withdrawn

3.4.4.1. Usage Are the circumstances under which an element appears in a message. Some elements must always be present, others may never be present, and others may only be present in certain circumstances. A set of codes has been defined to clearly identify the rules governing the presence of a particular element. The rules govern the expected behavior of the sending application and limited restrictions on the receiving application with respect to the element. These usage codes expand/clarify the optionality codes defined in the HL7 standard. In the segment attribute tables, this information is provided in the column labeled Usage. Value R

Description Required

RE

Required but may be empty

O

Optional

C

Conditional

CE

Conditional but it may be empty

X

Not supported

IRadimed 3880 Device Integration Guide

Comment A conforming sending application shall populate all “R” elements with a non-empty value. 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. This code indicates that the Usage for this element has not yet been defined 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. 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. For conformant sending applications, the element will not be sent. The receiving application will ignore the element if it is sent.

13

3.4.4.2. Cardinality Identifies the minimum and maximum number of repetitions for a particular element (Segment Group, Segment or Field). Cardinalities are expressed as a minimum-maximum pair of non-negative integers. A conformant application must always send at least the minimum number of repetitions, and may never send more than the maximum number of repetitions. There are two special values for cardinality. If the minimum number of repetitions is 0, the element may be omitted from a message. In certain circumstances, the maximum number of repetitions may have no practical limit. In this case, it is identified as * The following are examples of common cardinality combinations. Value [0..0] [0..1] [1..1] [0..n] [1..n] [0..*] [1..*] [m..n]

Description Element never present Element may be omitted and it can have at most one occurrence Element must have exactly one occurrence Element may be omitted or may repeat up to n times Element must appear at least once, and may repeat up to n times Element may be omitted or repeat for an unlimited number of times Element must appear at least once, and may repeat unlimited number of times Element must appear at least _m_ and at most_ n_ times

3.4.4.3. Repetition Determines whether the field may repeat. The value that appears in the repetitions column is the maximum number of allowed occurrences (for example, a value of 3 would mean that the field can have three occurrences). If unspecified, there is only one occurrence (that is, the field cannot repeat). In the segment attribute tables, this information is provided in the column labeled RP/#. Value N or blank Y (merge)

Description No repetition The field may repeat an indefinite or site-determined number of times. The field may repeat up to the number of times specified by the integer.

3.4.4.3.1.

Table

Specifies the HL7 identifier for a set of coded values. In the segment attribute tables, the table identifier is provided in the column labeled TBL#. If this attribute is not valued or blank, there is not a table of values defined for the field.

3.4.4.3.2.

ID Number

Is an integer that uniquely identifies the data item throughout the Standard. In the segment attribute tables, this information is provided in the column labeled Item #.

IRadimed 3880 Device Integration Guide

14

3.4.4.3.3.

Name

Is a descriptive name for the data item. In the segment attribute tables, this information is provided in the column labeled Element Name. When the same name is used in more than one segment, it must have the same data type and semantic meaning in each segment as well as the same ID number. To deal with any ambiguities arising from this convention, whenever a field is referenced herein, the segment name and position must always be included.

IRadimed 3880 Device Integration Guide

15

4. Message Profile Overview 4.1. Unsolicited Observation Reporting (ORU) Message Syntax The Unsolicited Observation Reporting (ORU) message that the IRADIMED 3880 SYSTEM sends to the server contains patient data, including: • Patient information o Medical Record Number (MRN) or other ID used as the patient identifier o First name o Middle name o Last name • Location (bed) ID • All valid vital signs parameters (that are currently on) and patient identifiable information currently available on the IRADIMED 3880 SYSTEM.

4.2. Segment Naming Convention Mandatory segments that are to be present in the HL7 message are marked in BOLD. • HL7 message segment fields and components/subcomponents of the respective field that are supported by the IRadimed 3880 System are highlighted in a light yellow color. • Segments can be depicted (in documentation) as: o XXX Required segments o [XXX] Optional segments o {XXX} Repeatable segments

4.3. ORU Message Segments The following table describes the mandatory segments that must be in the ORU message. Segment Description Usage Min Max MSH Message Header R 1 1 PID Patient Identification R 1 1 PV1 Common Order R 1 1 OBR Observation Request R 1 1 {OBX} Observation/Result R 1 None

IRadimed 3880 Device Integration Guide

16

4.4. Flow of Events The flow of events (see diagram below) that usually occurs when the IRADIMED 3880 SYSTEM (Sender) sends a HL7 message to a server (Receiving Application): 1. The IRADIMED 3880 SYSTEM sends an ORU message containing vital signs results to the server. 2. The server receives the ORU message and attempts to process the message. 3. If the server is unable to process the message, it returns an ACK message with an AR (Application Reject) acknowledgment code to the IRADIMED 3880 SYSTEM. 4. If the server successfully processes the message, it returns an ACK message with an AA (Application Accept) acknowledgment code to the IRADIMED 3880 SYSTEM. 5. The IRADIMED 3880 SYSTEM sends the next ORU message, unsolicited and without ACK (AA) message processing to a receiving application.

Sender

Receiving Application Reply

Ignore Reply Ignore Ignore

Reply

4.5. Profiles Supported The following profile is supported by the IRADIMED 3880 SYSTEM and is described in the documents. • Observations

4.6. Reference Documents •

HL7 Standard V2.6 (see www.hl7.org)

IRadimed 3880 Device Integration Guide

17

5. Observation Results Integration Profile (ORU) 5.1. Results Profile [ORU^R01] 5.1.1. Use Case The ORU message is for transmitting laboratory results to other systems. One result segment (OBX) is transmitted for each component of a diagnostic report, such as an EKG, obstetrical ultrasound or electrolyte battery. The 3880 System generates the OBX segments with all the vital sign numeric values and sends it to the HIS server at the user-selected message interval rate.

5.1.2. Actors Actor Name IRadimed 3880 System HIS Server

Description The sender: Generates the result events to server. The receiving application: Stores patient identifier, demographic, encounter, and vital sign information associated with orders (entirely site dependent).

5.1.3. Message Message Name ORU R01 Observation Reports

Description This message updates the system with reports.

5.1.4. ORU Message Static Definition

MSH { [

ORU _ Unsolicited Observation Message (Event R01) ORU^R01^ORU_R01 Unsolicited observation message Message Header --- PATIENT_RESULT begin --- PATIENT begin Patient Identification PID [{OBX}] Observation (for Patient ID) [ --- VISIT begin Patient Visit PV1 ] --- VISIT end --- PATIENT end ] --- ORDER_OBSERVATION begin { Observations Request OBR --- OBSERVATION begin [{ Observation related to OBR OBX --- SPECIMEN end }] --- ORDER_OBSERVATION end } --- PATIENT_RESULT end }

IRadimed 3880 Device Integration Guide

18

Many report headers (OBR) may be sent beneath each patient segment, with many separate observation segments (OBX) related to the order / observation request beneath each OBR.

5.1.5. Message Acknowledgement The Acknowledgment (ACK) message is sent by the server back to the IRADIMED 3880 SYSTEM to acknowledge that the message was received and validated. ACK^R01^ACK Acknowledgment MSH Message Header MSA Message acknowledgment

5.1.6. Example HL7 Messages The following are sample messages for expected ORU^R01 events from the IRadimed 3880 System.

5.1.6.1. ORU message containing one OBX for each vital sign MSH|^~&|IRM3880||||20170920110215||ORU^R01|20170920110215150|P|2 .6|||AL|NE||UNICODE UTF-8| PID|||581652148||Smith^John^Q| PV1||I|^MR ROOM 1|||||||||||||||A| OBR||||MONITOR|||20170920110215| OBX|1|NM|0002-4182^HR^MDC||60|0004-0aa0^bpm^MDC|||||F| OBX|2|NM|0002-f0a5^P1s^MDC||13.3|0004-0f03^kPa^MDC|||||F| OBX|3|NM|0002-f0a7^P1m^MDC||10.1|0004-0f03^kPa^MDC|||||F| OBX|4|NM|0002-f0a6^P1d^MDC||8.4|0004-0f03^kPa^MDC|||||F| OBX|5|NM|0002-f0a9^P2s^MDC||2.7|0004-0f03^kPa^MDC|||||F| OBX|6|NM|0002-f0ab^P2m^MDC||1.9|0004-0f03^kPa^MDC|||||F| OBX|7|NM|0002-f0aa^P2d^MDC||1.3|0004-0f03^kPa^MDC|||||F| OBX|8|NM|0002-4bb8^SpO2^MDC||99|0004-0220^%^MDC|||||F| OBX|9|NM|0002-5012^awRR^MDC||73|0004-0ae0^rpm^MDC|||||F| OBX|10|NM|0002-50b0^etCO2^MDC||5.1|0004-0f03^kPa^MDC|||||F| OBX|11|NM|0002-50ba^imCO2^MDC||0.3|0004-0f03^kPa^MDC|||||F| OBX|12|NM|0002-5280^inN2O^MDC||55|0004-0220^%^MDC|||||F| OBX|13|NM|0002-522c^etN2O^MDC||50|0004-0220^%^MDC|||||F| OBX|14|NM|0002-7498^FIO2^MDC||40|0004-0220^%^MDC|||||F| OBX|15|NM|0002-5220^etSEV^MDC||2.10|0004-0220^%^MDC|||||F| OBX|16|NM|0002-5278^inISO^MDC||1.30|0004-0220^%^MDC|||||F| OBX|17|NM|0002-521c^etHAL^MDC||2.20|0004-0220^%^MDC|||||F| OBX|18|NM|0002-526c^inENF^MDC||1.20|0004-0220^%^MDC|||||F| OBX|19|NM|0002-4b48^Temp^MDC||37.0|0004-17a0^°C^MDC|||||F|

5.1.6.2. Acknowledgement Message MSH|^&~|VHIS|VHIS|IRM3880 |20170920110215||ACK|20170920110215150|D|2.6||||| MSA|AA|20170920110215150|Message Received Successfully|

IRadimed 3880 Device Integration Guide

19

6. Segment Static Definitions 6.1. Message Header (MSH) Segment Every ORU message begins with the MSH segment, which contains message envelope information, such as the source, destination, and some specifics of the message syntax. The MSH segment does not contain clinical information. Example: This MSH segment shows an ORU message being sent from the IRADIMED 3880 SYSTEM on October 1, 2009, at 02:15:59 am. MSH|^~&|IRM3880||||20170920110215||ORU^R01|20170920110215150| P|2.6|||AL|NE||UNICODE UTF-8|<CR> The following table describes each field in the MSH segment. SEQ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

LEN 1 4 227 227 227 227 24 40 15 199 3 60 15 180 2

HL7 Attribute Table - MSH - Message Header DT OPT Usage Cardinality RP/# TBL # ST R R [1..1] ST R R [1..1] HD O RE [0..1] 0361 HD O X 0362 HD O X 0361 HD O X 0362 DTM R R [1..1] ST O X MSG R R [1..1] ST R R [1..1] PT R R [1..1] VID R R [1..1] NM O X ST O X ID O RE [0..1] 0155

16

2

ID

O

RE

17 18 19

3 16 250

ID ID CWE

X O O

X RE X

20

20

ID

O

X

21 22

427 567

EI XON

O O

X X

23

567

XON

O

X

[0..1]

0155

[0..1]

0399 0211

IRadimed 3880 Device Integration Guide

Y

0356 Y

Item # 00001 00001 000003 000004 000005 000006 000007 000008 000009 000010 000011 000012 000013 000014 000015

Element Name Field Separator Encoding Characters Sending Application Sending Facility Receiving Application Receiving Facility Date/Time Of Message Security Message Type Message Control ID Processing ID Version ID Sequence Number Continuation Pointer Accept Acknowledgment Type 000016 Application Acknowledgment Type 000017 Country Code 00692 Character Set 00693 Principal Language Of Message 01317 Alternate Character Set Handling Scheme 01598 Message Profile Identifier 01823 Sending Responsible Organization 01824 Receiving Responsible

20