mosaiq 2 - - zachodniopomorskie centrum onkologii · 4.1.1 operational requirements of the external...

MOSAIQ 2.60

External Systems Interface (ESI) Requirements Specification

Document ID: LEDESI0033(8.0)

Language: English

Publication Date: [2015]-[10]

LEDESI0033 / 8.0 MOSAIQ 2.60 External Systems Interface (ESI) Requirements Specification

2015-11-05 ©2015 IMPAC Medical Systems, Inc. All rights reserved.

Copyright statement © 2015 IMPAC Medical Systems, Inc. All rights reserved. Do not make printed or electronic copies of this guide, or parts of it, without written authority from IMPAC Medical Systems, Inc. The information in this guide is for the sole use of IMPAC Medical Systems, Inc. personnel, authorized users and licensees of IMPAC Medical Systems, Inc. products, and no other purpose.

Use of trademarks and trade names statement The Elekta® trademarks, service marks, logos, and trade names that we use in this document are the registered and unregistered trademarks and trade names of Elekta AB (publ.), its affiliates, or a third party that has licensed its trademarks and trade names to Elekta AB (publ.) or its affiliates. Do not make copies, show, or use trademarks or trade names without written authority from IMPAC Medical Systems, Inc. an affiliate of Elekta AB (publ.).

Acknowledgement of other trademarks and trade names Elekta acknowledges the trademarks and trade names of other manufacturers that we use in this document.

Referenced documents Elekta does not supply all documents that we refer to in this document in printed forms. Elekta reserves the right to make the decision on which of the documents it supplies in printed form.

Contact information

Contact Software Support: http://www.elekta.com/healthcare-professionals/products/elekta-services/service-and-support/software-support.html Contact Information: http://www.elekta.com/meta/contact.html

http://www.elekta.com/healthcare-professionals/products/elekta-services/service-and-support/software-support.html

http://www.elekta.com/healthcare-professionals/products/elekta-services/service-and-support/software-support.html

http://www.elekta.com/meta/contact.html



Page 1

Table of Contents 1. Introduction ........................................................................................................................................................... 7

1.1 Purpose ................................................................................................................................................................................. 7 1.2 Scope ..................................................................................................................................................................................... 7 1.3 References ............................................................................................................................................................................ 7 1.4 Overview .............................................................................................................................................................................. 7 1.5 Documentation Conventions ........................................................................................................................................... 7 1.6 General Constraints............................................................................................................................................................ 8

2. General Description ............................................................................................................................................... 9 2.1 Product Description ........................................................................................................................................................... 9

3. Environment ........................................................................................................................................................ 12

4. Specific Functional Requirements....................................................................................................................... 12 4.1 Transport Mechanism ...................................................................................................................................................... 12

4.1.1 Operational Requirements of the External System ...................................................................................... 12 4.2 Definitions ......................................................................................................................................................................... 12

4.2.1 Messages ............................................................................................................................................................. 12 4.2.2 Data Fields .......................................................................................................................................................... 13 4.2.3 Message Encoding Rules .................................................................................................................................. 14 4.2.4 Special Character Definitions .......................................................................................................................... 14 4.2.5 Message Construction Rules ........................................................................................................................... 15 4.2.6 Data Types.......................................................................................................................................................... 16 4.2.7 Processing Rules ................................................................................................................................................ 19

4.3 Processing Mode ............................................................................................................................................................... 20 4.3.1 Interactive Mode ............................................................................................................................................... 20 4.3.2 Polling Mode...................................................................................................................................................... 20 4.3.3 TCP/IP Mode ..................................................................................................................................................... 20

4.4 Tables .................................................................................................................................................................................. 21 4.5 MOSAIQ ESI Messages ................................................................................................................................................... 21

4.5.1 Control Messages .............................................................................................................................................. 21 4.5.2 Batch Processing ............................................................................................................................................... 22 4.5.3 Outbound Messages – Trimming of White-Space ....................................................................................... 23 4.5.4 Admission/Discharge/Transfer Messages (ADT Inbound) ........................................................................ 24

4.5.4.1 Event Code: A01 - Admit / Visit Notification ......................................................................................... 24 4.5.4.2 Event Code: A02 – Transfer a Patient ....................................................................................................... 25 4.5.4.3 Event Code: A03 – Discharge / End Visit ................................................................................................ 25 4.5.4.4 Event Code: A04 - Register a Patient ........................................................................................................ 25 4.5.4.5 Event Code: A05 – Pre-Admit a Patient ................................................................................................... 26 4.5.4.6 Event Code: A06 – Change an Outpatient to Inpatient ......................................................................... 27 4.5.4.7 Event Code: A07 – Change an Inpatient to Outpatient ......................................................................... 27 4.5.4.8 Event Code: A08 - Update Patient Information ...................................................................................... 27 4.5.4.9 Event Code: A11 – Cancel Admission / Visit .......................................................................................... 28 4.5.4.10 Event Code: A12 – Cancel Admission / Visit .......................................................................................... 28 4.5.4.11 Event Code: A13 – Cancel Discharge/End Visit ..................................................................................... 29 4.5.4.12 Event Code: A17 - Swap Patient Location ................................................................................................ 29 4.5.4.13 Event Code: A18 - Merge Patient Information (ESI:ADT) ................................................................... 30 4.5.4.14 Event Code: A19 - Patient Query .............................................................................................................. 30 4.5.4.15 Event Code: A23 - Delete a Patient Record .............................................................................................. 31



Page 2

4.5.4.16 Event Code: A28 – Add Person or Patient Information ........................................................................ 31 4.5.4.17 Event Code: A30 - Merge Person Information (ESI:ADT) .................................................................... 32 4.5.4.18 Event Code: A31 - Update Person Information ...................................................................................... 32 4.5.4.19 Event Code: A34 - Merge Patient Information - Patient ID Only (ESI:ADT) .................................... 33 4.5.4.20 Event Code: A35 - Merge Patient Information - Account Number Only (ESI:ADT) ....................... 33 4.5.4.21 Event Code: A36 - Merge Patient Information - Patient ID and Account Number (ESI:ADT) ...... 33 4.5.4.22 Event Code: A38 – Cancel Pre-Admit ...................................................................................................... 34 4.5.4.23 Event Code: A40 - Merge Patient - Patient Identifier List (ESI:ADT) ................................................. 34 4.5.4.24 Event Code: A18, A30, A34, and A40 Merge Events (IIM:ADT) ......................................................... 34

4.5.5 Finance (BAR and DFT) Messages ................................................................................................................. 36 4.5.5.1 Event Code: P01 - Finance: Add and Update Patient Accounts ........................................................... 36 4.5.5.2 Event Code: P03 - Finance: Post detail financial transactions - Inbound............................................ 37 4.5.5.3 Event Code: P03 - Finance: Post detail financial transactions - Outbound ........................................ 37

4.5.6 Observation Reporting Messages .................................................................................................................... 40 4.5.6.1 Event Code R01 - Unsolicited Transmission of an Observation .......................................................... 40

4.5.7 Document Management Messages ................................................................................................................. 41 4.5.7.1 Event Code T02 – Original Document Notification and Content ....................................................... 41 4.5.7.2 Event Code T10 – Document replacement notification and content .................................................. 41 4.5.7.3 Event Code T11 – Document Cancel Notification ................................................................................. 41

4.5.8 Lab Order Messages .......................................................................................................................................... 42 4.5.8.1 Event Code O01 – General Order Message ............................................................................................. 42

4.5.9 Radiotherapy requisition Messages ................................................................................................................ 43 4.5.9.1 Event Code O01 – General Order Message ............................................................................................. 43

4.5.10 Pharmacy Order Messages............................................................................................................................... 44 4.5.10.1 Event Code O01 – General Order Message ............................................................................................. 44

4.5.11 Locally Defined Messages ................................................................................................................................ 46 4.5.11.1 Event Code: Z01 - Physician Add/Update/Delete................................................................................... 46 4.5.11.2 Event Code: Z02 - Insurance Add/Update/Delete .................................................................................. 46

4.5.12 Admission/Discharge/Transfer Messages (ADT Outbound) ..................................................................... 47 4.5.12.1 Event Code: A04 - Register a Patient ........................................................................................................ 47

4.5.13 Syndromic Surveillance Export (OIM) .......................................................................................................... 48 4.5.13.1 Event Code A04 – Send a Syndromic Surveillance message based on a ‘Working’ diagnosis.......... 48 4.5.13.2 Event Code A03 – Send a Syndromic Surveillance message based on a ‘Final’ diagnosis................. 48

4.5.14 Schedule Messages (Outbound) ...................................................................................................................... 50 4.5.14.1 Event Code: S12 – Notification of new appointment booking .............................................................. 50 4.5.14.2 Event Code: S13 – Notification of appointment rescheduling .............................................................. 50 4.5.14.3 Event Code: S14 – Notification of appointment modification .............................................................. 50 4.5.14.4 Event Code: S15 – Notification of appointment cancellation ............................................................... 50 4.5.14.5 Event Code: S26 – Notification that patient did not show up for appointment ................................. 51

4.5.15 Schedule Messages (Inbound) ......................................................................................................................... 51 4.5.15.1 Event Code: S12 – Notification of new appointment booking .............................................................. 51 4.5.15.2 Event Code: S13 – Notification of appointment rescheduling .............................................................. 51 4.5.15.3 Event Code: S14 – Notification of appointment modification .............................................................. 51 4.5.15.4 Event Code: S15 – Notification of appointment cancellation ............................................................... 52 4.5.15.5 Event Code: S17 – Notification of appointment deletion ...................................................................... 52 4.5.15.6 Event Code: S26 – Notification that patient did not show up for appointment ................................. 52

4.5.16 Vaccine (VXU) Messages ................................................................................................................................. 53 4.5.16.1 Event Code: V04 - Vaccine: Unsolicited Update to Vaccination Record ............................................ 53



Page 3

5. User Configurable Switches ................................................................................................................................. 54 5.1 Configurable Options....................................................................................................................................................... 54

5.1.1 Import Options.................................................................................................................................................. 54 5.1.1.1 Query Configuration ................................................................................................................................... 54 5.1.1.2 Admit, Update and Secondary Search Configuration ............................................................................ 54 5.1.1.3 Process Delete Patient Messages ................................................................................................................ 55 5.1.1.4 Charge Inbound Configuration ................................................................................................................. 55 5.1.1.5 ADT Inbound Configuration ..................................................................................................................... 55 5.1.1.6 Charge Outbound Configuration .............................................................................................................. 56

5.1.2 Export Options .................................................................................................................................................. 56 5.2 Halt Time/Duration ......................................................................................................................................................... 57

6. User Configurable HL7 Message Translation (IIM) ........................................................................................... 58 6.1 Creation of Mapping Tables ........................................................................................................................................... 58 6.2 Mapping Table Contents ................................................................................................................................................. 59

6.2.1 Mapping Table Contents (ADT Interface) .................................................................................................... 59 6.2.2 Mapping Table Contents (Schedule Interface) ............................................................................................. 60 6.2.3 Mapping Table Contents (Radiotherapy Requisition Interface) ................................................................ 62 6.2.4 Sample XML Mapping Files ............................................................................................................................ 63

6.3 Mapping Table Editing .................................................................................................................................................... 64

7. Log Files ................................................................................................................................................................ 65 7.1 Transaction Log Files ....................................................................................................................................................... 65 7.2 TCP/IP Log Files ............................................................................................................................................................... 65

8. Errors .................................................................................................................................................................... 66 8.1 Error Handling .................................................................................................................................................................. 66 8.2 Error Logging .................................................................................................................................................................... 67

9. Appendix A. Tables .............................................................................................................................................. 68

10. Appendix B. Examples ......................................................................................................................................... 74 10.1 HL7 (variable position, variable length) examples ................................................................................................ 74

10.1.1 Admit a Patient - Trigger Event A01:............................................................................................................. 74 10.1.2 Add and Update Patient Accounts - Trigger Event P01: ............................................................................. 75

11. Appendix C. HL7 to MOSAIQ Data Item Cross Reference ............................................................................... 76 11.1 Purpose ........................................................................................................................................................................ 76 11.2 Conventions ................................................................................................................................................................ 76 11.3 AIL – Appointment Information – Location Resource ....................................................................................... 77

AIL Field Notes .................................................................................................................................................................. 79 12.1 AIP – Appointment Information – Personnel Resource ..................................................................................... 80

AIP Field Notes .................................................................................................................................................................. 81 12.2 AIS – Appointment Information - Service ............................................................................................................. 82

AIS Field Notes .................................................................................................................................................................. 83 12.3 AL1 – Patient Allergy Information Segment ......................................................................................................... 84

AL1 Field Notes ................................................................................................................................................................. 86 12.4 BHS – Batch Header Segment .................................................................................................................................. 87

BHS Field Notes ................................................................................................................................................................. 88 12.5 BTS – Batch Trailer Segment ................................................................................................................................... 90

BTS Field Notes ................................................................................................................................................................. 90 12.6 DG1 – Diagnosis Segment ........................................................................................................................................ 91



Page 4

DG1 Field Notes ................................................................................................................................................................ 92 12.7 ERR – Error Segment ................................................................................................................................................ 95

ERR Field Notes ................................................................................................................................................................. 95 12.8 EVN – Event Type Segment ..................................................................................................................................... 96

EVN Field Notes ................................................................................................................................................................ 96 12.9 FHS – File Header Segment ...................................................................................................................................... 97

FHS Field Notes ................................................................................................................................................................. 98 12.10 FTS – File Trailer Segment ................................................................................................................................... 99

FTS Field Notes .................................................................................................................................................................. 99 12.11 FT1 – Financial Transaction Segment .............................................................................................................. 100

FT1 Field Notes ................................................................................................................................................................ 104 12.12 FT1 – Financial Transaction Segment (IIM: ADT Inbound Interface) ....................................................... 107

FT1 Field Notes ................................................................................................................................................................ 109 12.13 GT1 – Guarantor Segment ................................................................................................................................. 110

GT1 Field Notes ............................................................................................................................................................... 115 GT1 Outbound Processing Details ............................................................................................................................... 116

12.14 IN1 – Insurance Segment ................................................................................................................................... 117 IN1 Field Notes ................................................................................................................................................................ 121 12.14.1 IN1 Processing Rules (Inbound Interface Manager (IIM) ADT Interface) ............................................ 123

12.14.1.1 IN1 Processing Rules (Overview) ............................................................................................................ 125 12.14.1.2 IN1 Special Cases (Inbound Interface Manager (IIM) ADT Interface) ............................................. 138

IN1 Processing Details (ESI:Manager ADT Processing) ........................................................................................... 139 IN1 Outbound Processing Details ................................................................................................................................ 139

12.15 MRG – Merge Segment ...................................................................................................................................... 140 MRG Field Notes ............................................................................................................................................................. 140

12.16 MSA – Message Acknowledgment Segment ................................................................................................... 141 MSA Field Notes .............................................................................................................................................................. 141

12.17 MSH – Message Header Segment (Mapping for Outbound Interface Manager) ...................................... 142 MSH Field Notes.............................................................................................................................................................. 143

12.18 MSH – Message Header Segment (Mapping for Inbound Interface Manager Lab Results Interface) ... 145 MSH Field Notes.............................................................................................................................................................. 146

12.19 MSH – Message Header Segment (Mapping for ESI Manager and Charge Export) ................................. 148 MSH Field Notes.............................................................................................................................................................. 150

12.20 MSH – Message Header Segment (OIM:Syndromic Surveillance Interface) ............................................. 152 MSH Field Notes.............................................................................................................................................................. 154

12.21 MSH – Message Header Segment (OIM: Immunization Export Interface) ............................................... 156 MSH Field Notes.............................................................................................................................................................. 158

12.22 NK1 – Next of Kin Segment .............................................................................................................................. 159 NK1 Field Notes............................................................................................................................................................... 162

12.23 NK1 – Next of Kin Segment (OIM: Immunization Export Interface) ........................................................ 163 NK1 Field Notes............................................................................................................................................................... 164

12.24 NTE – Note Segment .......................................................................................................................................... 165 NTE Field Notes .............................................................................................................................................................. 165

12.25 OBR – Observation Request Segment .............................................................................................................. 167 OBR Field Notes .............................................................................................................................................................. 171

12.26 OBR – Observation Request Segment (For Inbound Lab Results Interface HL7 2.5) .............................. 173 OBR Field Notes .............................................................................................................................................................. 177

12.27 OBR – Observation Request Segment (For ESI:Doc Inbound Interfaces) .................................................. 180 OBR Field Notes .............................................................................................................................................................. 182



Page 5

12.28 OBR – Observation Request Segment (For OIM:Doc Outbound Interfaces) ............................................ 183 OBR Field Notes .............................................................................................................................................................. 185

12.29 OBR – Observation Request Segment (OIM: Lab Order Outbound Interface) ......................................... 186 OBR Field Notes .............................................................................................................................................................. 189

12.30 OBX – Observation / Result Segment (IIM:Lab Result Inbound Interface) ............................................... 190 OBX Field Notes .............................................................................................................................................................. 192

12.31 OBX – Observation / Result Segment (IIM:Doc Inbound Interface) .......................................................... 194 OBX Field Notes .............................................................................................................................................................. 194

12.32 OBX – Observation / Result Segment (OIM:Doc Outbound Interface) ..................................................... 196 OBX Field Notes .............................................................................................................................................................. 197

12.33 OBX – Observation / Result Segment (OIM:Pharmacy Outbound Interface) ........................................... 199 OBX Field Notes .............................................................................................................................................................. 200

12.34 OBX – Observation / Result Segment (OIM:Charge Export Interface) ...................................................... 201 OBX Field Notes .............................................................................................................................................................. 202

12.35 OBX – Observation / Result Segment (OIM: Immunization Export Interface)......................................... 203 OBX Field Notes .............................................................................................................................................................. 208

12.36 OBX – Observation / Result Segment (OIM:Syndromic Surveillance Interface) ...................................... 209 12.36.1 OBX|1| - for Facility Information ................................................................................................................. 209 12.36.2 OBX|2| - for Age .............................................................................................................................................. 210 12.36.3 OBX|3| - for Chief Complaint ....................................................................................................................... 210

12.37 ORC – Common Order Segment (for Lab Orders) ........................................................................................ 212 ORC Field Notes .............................................................................................................................................................. 214

12.38 ORC – Common Order Segment (for Pharmacy Orders) ............................................................................ 217 ORC Field Notes .............................................................................................................................................................. 220

12.39 ORC – Common Order Segment (OIM: Immunization Export Interface) ................................................ 226 ORC Field Notes .............................................................................................................................................................. 228

12.40 PD1 – Patient Demographic Segment (OIM: Immunization Export Interface) ........................................ 229 PD1 Field Notes ............................................................................................................................................................... 230

12.41 PID – Patient Identification Segment ............................................................................................................... 231 PID Field Notes ................................................................................................................................................................ 236

12.42 PID – Patient Identification Segment (OIM: Immunization Export Interface) ......................................... 239 PID Field Notes ................................................................................................................................................................ 242

12.43 ID – Patient Identification Segment (OIM:Syndromic Surveillance Interface) ......................................... 243 PID Field Notes ................................................................................................................................................................ 245

12.44 PV1 – Patient Visit Segment .............................................................................................................................. 248 PV1 Field Notes ............................................................................................................................................................... 252

12.45 PV1 – Patient Visit Segment (OIM:Syndromic Surveillance Interface) ...................................................... 254 12.46 QRD – Query Segment ....................................................................................................................................... 258

QRD Field Notes .............................................................................................................................................................. 258 12.47 RGS – Resource Group Segment ....................................................................................................................... 259

RGS Field Notes ............................................................................................................................................................... 259 12.48 RXA – Pharmacy/Treatment Administration Segment (OIM: Immunization Export Interface) ........... 260

RXA Field Notes .............................................................................................................................................................. 264 12.49 RXC – Pharmacy/Treatment Component Order Segment ........................................................................... 265

RXC Field Notes .............................................................................................................................................................. 267 12.50 RXO – Pharmacy/Treatment Order Segment ................................................................................................. 268

RXO Field Notes .............................................................................................................................................................. 274 12.51 RXR – Pharmacy/Treatment Route Segment .................................................................................................. 275

RXR Field Notes............................................................................................................................................................... 275



Page 6

12.52 SCH – Appointment Activity Information...................................................................................................... 276 SCH Field Notes............................................................................................................................................................... 279

12.53 SPM – Specimen Segment (IIM:Lab Result Inbound Interface) .................................................................. 282 SPM Field Notes .............................................................................................................................................................. 283

12.54 TQ1 – Timing Quantity Segment (IIM:Lab Result Inbound Interface) ...................................................... 284 TQ1 Field Notes ............................................................................................................................................................... 284

12.55 TXA – Transcription document header segment (IIM:Doc Import and OIM:Doc Export) ................... 285 TXA Field Notes .............................................................................................................................................................. 287

12.56 ZCH – Proprietary charge segment .................................................................................................................. 288 ZCH Field Notes .............................................................................................................................................................. 292

12.57 ZCP – Proprietary course segment ................................................................................................................... 293 ZCP Field Notes ............................................................................................................................................................... 293

12.58 ZDX – Proprietary diagnosis segment ............................................................................................................. 294 ZDX Field Notes .............................................................................................................................................................. 295

12.59 ZIL – Insurance Local Segment ......................................................................................................................... 296 ZIL Field Notes ................................................................................................................................................................ 297

12.60 ZPH – Physician Identification Local Segment .............................................................................................. 298 ZPH Field Notes .............................................................................................................................................................. 300

12.61 ZPR – Protocol Information .............................................................................................................................. 301 ZPR Field Notes ............................................................................................................................................................... 301

12.62 ZPT – Proprietary patient segment .................................................................................................................. 302 12.63 ZRF – Proprietary referral segment .................................................................................................................. 304 12.64 ZTX – Proprietary treatment segment ............................................................................................................. 306

ZTX Field Notes ............................................................................................................................................................... 310 12.65 ZXO - Proprietary Pharmacy/Treatment Order Extensions......................................................................... 311

ZXO Field Notes .............................................................................................................................................................. 311

MOSAIQ 2.60 ESI Requirements Specification Introduction



Page 7

1. Introduction 1.1 Purpose This document specifies the interface used to exchange data between an external system and the Elekta MOSAIQ Oncology Management System. Elekta believes that the information in this specification is accurate and reliable but accepts no responsibility for any consequences arising from unforeseen events. The information contained in this document is subject to change. Revisions and updates will be issued from time to time to document changes and/or additions.

1.2 Scope This specification is primarily for those individuals who develop and maintain the External System Interface (ESI). Hereafter the MOSAIQ External System Interface is referred to as MOSAIQ ESI or ESI.

1.3 References This document references the following documents:

DID TITLE

LSR99001 MOSAIQ Hardware/Software Requirements Specifications LRMESI0019 HL7 Charge Export Configuration Guide

1.4 Overview This document specifies the exchange of data between the MOSAIQ system and an external system. Data items required for transmission are explained, as well as the process required for exchange. User configurable options and logging for transactions and errors are also explained. The appendices provide information about data tables, examples of MOSAIQ ESI messages, and ESI mapping to HL7 codes.

1.5 Documentation Conventions This document uses these conventions:

• Menu commands, list items from a drop-down list, and control buttons are in bold. Vertical lines divide menu commands that are done one directly after another. Example: File | Tools | Options.

• Window elements, such as fields, radio buttons, check boxes, tabs and footnotes, are in italics or, if in a table are in Bold Sans Serif font. Example:

Element Description

Patient Information Header Shows basic patient information such as patient name, attending physician, medical record number, and date of birth.

Flowsheets Opens the Flowsheet window, which shows treatment information for the selected patient.

• Text that you type as shown, such as commands or responses, is bold shaded.

• File names, file paths, databases, and database fields are printed in mixed-case Courier typeface.

• Words or phrases that are new and could be misunderstood are initially “in quotes.”

MOSAIQ 2.60 ESI Requirements Specification Introduction



Page 8

• Function keys and booster keys appear in upper case bold print. Example: F2 or Ctrl. A plus sign divides more than one key that you press at the same time. Example: Ctrl+ F4.

1.6 General Constraints The ADT, Financial and Laboratory Observation messages that ESI supports are HL7 compatible; however, they do not represent the full range of HL7 transaction messages. If required in later revisions of ESI, these additional messages may be added without disturbing the functionality specified in this document. Because ESI is based on the HL7 standard, it may receive and accept data that MOSAIQ subprograms ignore. Although the HL7 Standard is defined in terms of the client-server (remote operation) model, this standard is equally applicable to file transfers. MOSAIQ ESI supports batch file transfers (Section 4.1, Transport Mechanism) and accepts one or more messages encoded according to the encoding rules and grouped in a file. Responses (if supported by the external system) are also grouped in a file and similarly transmitted. Discussion of any file transfer protocol is not within the scope of this document. ESI follows the HL7 standard for batch or TCP/IP message transmission. The processing mode supported by ESI is immediate processing. If ESI is down for an extended period of time, the sending external system should hold all transactions until ESI returns to operational status. There are data items that must be coordinated between external systems and MOSAIQ ESI users. This coordination is accomplished through a data table scheme described in Section 4.4 on page 21. Data tables that are site-editable are specified in Appendix A. T on page 68.

MOSAIQ 2.60 ESI Requirements Specification General Description



Page 9

2. General Description 2.1 Product Description The MOSAIQ HL7 interfaces (MOSAIQ ESI) are Health Industry Level 7 Interface Standard (HL7) Version 2.1 ~ 2.3.1 compliant interfaces that allows data to be transmitted between the MOSAIQ system and external systems. These MOSAIQ HL7 interfaces receive registration, billing, observation results and other information, and export billable procedures, registration, pharmacy orders and other information that is captured and stored in the MOSAIQ system. The following transaction messages are supported:

ESI:ADT (Inbound)

(A01) Admit a Patient (A19) Patient Query (A02) Transfer a Patient (A23) Delete a Patient Record (A03) Discharge a Patient (A28) Add Person or Patient Information (A04) Register a Patient (A30) Merge Person Information (A05) Pre-Admit a Patient (A31) Update Person Information (A06) Transfer Outpatient to Inpatient (A34) Merge Patient Information - Patient ID (A08) Update Patient Information (A35) Merge Patient Information - Account Number Only (A17) Swap Patients (A36) Merge Patient Information - Patient ID and

Account Number (A18) Merge Patient Information (A40) Merge Patient - Patient Identifier List (P01) Add/Update Patient Accounts (Z01) Physician Add/Update/Delete (Z02) Insurance Add/Update/Delete

IIM:ADT (Inbound)

(A01) Admit a Patient (A17) Swap Patients (A02) Transfer a Patient (A18) Merge Patient Information (A03) Discharge a Patient (A19) Patient Query (A04) Register a Patient (A28) Add Person or Patient Information (A05) Pre-Admit a Patient (A30) Merge Person Information (A06) Transfer Outpatient to Inpatient (A31) Update Person Information (A07) Transfer Inpatient to Outpatient (A34) Merge Patient Information - Patient ID (A08) Update Patient Information (A38) Cancel Pre-Admit (A11) Cancel Admission / Visit (A40) Merge Patient - Patient Identifier List (A12) Cancel Transfer (A13) Cancel Discharge / End Visit

IIM:Doc (Inbound)

(R01) Unsolicited Transmission of an observation message

(T02) Original Document Notification and Content




Page 10

IIM:Lab (Inbound)


IIM:SCH (Inbound)

(S12) Notification of new appointment booking (S15) Notification of new appointment cancellation (S13) Notification of new appointment rescheduling (S17) Notification the appointment for patient was deleted. (S14) Notification of new appointment modification (S26) Notification that patient did not show up for

appointment

IIM:RTR (Inbound)

(O01) General Order Message

ESI:Charge (Inbound)

(P03) Post Detail Financial Transactions

ESI:Charge (Outbound)

(P03) Post Detail Financial Transactions

OIM:Schedule (Outbound)

(S12) Notification of new appointment booking (S15) Notification of new appointment cancellation (S13) Notification of new appointment rescheduling (S26) Notification that patient did not show up for

appointment

(S14) Notification of new appointment modification

OIM:ADT (Outbound)

(A04) Register a Patient

OIM:DOC (Outbound)


(T10) Document Replacement Notification and Content

(T02) Original Document Notification and Content (T11) Document Cancel Notification

OIM:Charge (Outbound)

(P03) Post Detail Financial Transactions (V04) Unsolicited Vaccination Record Update

OIM:Syndromic Surveillance (Outbound)

(A04) Register a Patient

OIM:Lab Orders (Outbound)





Page 11

OIM:Pharmacy Orders (Outbound)


OIM:Immunization Export (Outbound)

(V04) Immunization History

On inbound interfaces, the MOSAIQ ESI interfaces acknowledge receipt of incoming messages, if required, with the response type: General Acknowledgement (message type ACK). ESI transaction messages are compatible with the HL7 version 2 and are external system independent. They include an information superset that may be received from external systems. HL7 uses a variable position, variable length format. MOSAIQ ESI can be configured to accept transaction messages either:

♦ In “Interactive mode” (process only one batch file at a time) ♦ In “Polling mode” (process all new batch files at a user defined interval). ♦ In “TCP/IP mode” (process incoming messages received on the defined socket)

MOSAIQ ESI can export financial messages to a file via Interactive mode only. The HL7 Query Acknowledgment message is supported. The Query Acknowledgment message occurs in response to a query sent to an external system (Event Code A19). The Query Acknowledgment is treated either as an admit or update. Note that only the acknowledgment is supported, not the initiating message. External systems that prefer not to screen messages can set up a process that initiates a query when a patient comes into an institution.

MOSAIQ 2.60 ESI Requirements Specification Environment



Page 12

3. Environment See LSR99001 (MOSAIQ System Requirements).

4. Specific Functional Requirements 4.1 Transport Mechanism This section describes the mechanisms utilized to transfer ADT, Charge and Laboratory Result information between the External System Database and the MOSAIQ database.

4.1.1 Operational Requirements of the External System If not using TCP/IP for sending/receiving messages, the external system must be able to read and write DOS ASCII files on the MOSAIQ fileserver or to a local disk on a workstation connected to the network on which the MOSAIQ fileserver resides. If using the TCP/IP mechanism, the external system must be able to create Sockets, put the information into a message buffer, and send and receive messages. If a local workstation disk is utilized, the workstation must be able to execute a standard DOS program, have DOS ASCII file access (read/write) to the local disk and have network access to the MOSAIQ fileserver.

4.2 Definitions 4.2.1 Messages A “message” is a unit of data transferred between external systems and MOSAIQ ESI. It consists of a group of “segments” sent from one system to another. Each message has a message type that defines its purpose. Each message type is represented by a 3-character code contained within the message. The MOSAIQ ESI currently supports one patient per message. The event that initiates an exchange of messages is called a trigger event. Table 0003 in Appendix A contains the codes that represent all trigger events accepted by MOSAIQ ESI. MOSAIQ ESI uses two locally defined messages (i.e., messages with HL7 data types and segments, but not part of the HL7 standard message set). In accordance with the HL7 standard, these messages use message type and trigger event codes beginning with the letter Z. A “segment” is a logical grouping of data fields. Segments of a message may be required or optional. They may occur only once in a message or they may be allowed to repeat. Each segment is given a name. For example, the Patient Visit ADT message contains the following segments: Message Header (MSH), Event Type (EVN), Patient ID (PID) and Patient Visit (PV1). Each segment is identified by a unique 3-character code known as the “Segment ID”. MOSAIQ ESI uses two locally defined segments. The locally defined segments have Segment IDs that begin with the letter Z. Within a message definition, brackets ( [ and ] ) are used to specify when segments are optional. Braces ( { and } ) are used to specify when segments may repeat one or more times. Some sample message definitions are provided below.

MOSAIQ 2.60 ESI Requirements Specification Specific Functional Requirements



Page 13

Example 1: A message (MS1) consists of the ABC segment that is followed by one or more DEF segments, each of which is followed by a single GHI segment followed by zero or more JKL segments.† MS1

ABC

{ DEF

GHI

{ [JKL] }

} Example 2: If the GHI and JKL segments need to appear in pairs but the pairs are optional and can repeat, MS1 would be revised as follows. MS1

ABC

{ DEF

[ { GHI

JKL

} ]

}

Example 3: If at least one pair of GHI and JKL segments must follow a DEF, then MS1 would be revised as follows. MS1

ABC

{ DEF

{ GHI

JKL

}

}

4.2.2 Data Fields The segment data fields are defined in the sections that use them. Descriptions of the data fields and characteristics of their usage are also specified. In sections that specify data segments the following acronyms are used:

♦ SEQ - Sequence Number. ♦ LEN - Length of a single occurrence. ♦ TYPE - Data Types. ♦ R/O - Required/Optional. ♦ REP - Repeatable.

The “SEQ” provides the 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. The “LEN” specifies the maximum number of characters that one occurrence of the data field may occupy in any message. It is calculated assuming that the MOSAIQ ESI encoding rules are applied. As such, it includes the defined component and sub-component separators. Because it specifies the length of a single occurrence, the repetition character is not used when calculating maximum length.

† The Example format follows that found in HL7 ver. 2.3.




Page 14

The “TYPE” specifies the contents of the data field. The data types and their formats are further defined in section 4.3.3 Data Types. The “R/O” specifies whether a data field is required (R) or optional (O). The “REP” designates whether a field may repeat (Y) or not (N). If the number of repetitions is limited, then REP = Y will be followed by a number specifying the limit. “TABLE” refers to the number of a table file (see section 4.4 on page 20 and Appendix A on page 68), ITEM refers to an HL7 data dictionary reference number, and NAME gives the specified data field name.

The HL7 data dictionary reference number is given in order to provide users with further references. Any other reference to or use of this item number is beyond the scope of this document. MOSAIQ ESI specified local segments provide no ITEM numbers.

4.2.3 Message Encoding Rules This section describes the process of constructing data that makes up the segments.

4.2.4 Special Character Definitions In constructing a message, the following special characters are used:

♦ Segment terminator ♦ Field separator ♦ Component separator ♦ Sub-component separator ♦ Repetition separator

The “segment terminator” is the last character of every segment. The default is the ASCII CR character (hex 0D). MOSAIQ ESI also accepts the ASCII CR LF character (Hex 0D 0A) sequence. The “field separator” separates two adjacent data fields within a segment. It also separates the segment ID from the first data field in the segment. The value that represents the field separator may be defined differently for each message. The character that is the fourth character of the Message Header (MSH) segment (i.e., between the segment ID and the Encoding Characters data field) serves as the field separator for all segments in the message. Absent other considerations, it is recommended that all sending applications use “ | ” as the field separator. However, MOSAIQ ESI accepts whichever character is included in this position and uses it to parse the message. The “component separator” separates adjacent components of some data fields. Its use is described in the descriptions of the relevant data fields. The character that represents the component separator is specified for each message as the first character in the Encoding Characters data field of the MSH segment. Absent other considerations, it is recommended that all sending applications use “^“ as the component separator. However, MOSAIQ ESI accepts whichever character is included in the Message Header and uses it to parse the message. The “sub-component separator” separates adjacent sub-components of some data fields. Its use is described in the descriptions of the relevant data fields. The character that represents the sub-component separator is specified for each message as the fourth character in the Encoding Characters data fields of the MSH segment. Apart from other considerations, Elekta recommends that all sending applications use “&” as the sub-component separator. However, MOSAIQ ESI accepts whichever character is included in the Message Header and uses it to parse the message. The “repetition separator” separates multiple occurrences of a particular field in some data fields. It is used only where specifically authorized in the descriptions of the relevant data fields. The character that represents the repetition separator is specified for each message as the second character in the Encoding Characters data field of the MSH segment. Absent other considerations, it is recommended that all sending applications use “~” as the repetition




Page 15

separator. However, MOSAIQ ESI accepts whichever character is included in the Message Header and uses it to parse the message. In text fields (Data Type TX) the “escape character” is also allowed. The single character that represents the escape character is specified as the third character in the Encoding Characters data field of the MSH segment. MOSAIQ ESI does not currently include segments that use the TX data type and therefore ignores any characters occurring as the third character of the Encoding Characters data field.

4.2.5 Message Construction Rules (1) Construct the segments in the order defined for the message. Each message is constructed as follows:

(a) The first three characters are the segment ID code.

(b) Each data field in sequence is inserted in the segment in the following manner:

(i) A field separator is placed in the segment.

(ii) If the value is “not present,” no further characters are required.

(iii) If the value is present, but null, the characters "" (two consecutive double quote marks) are placed in the field.

(iv) Otherwise, place the characters of the value in the segment. As many characters can be included as the maximum defined for the data field. It is not necessary to pad fields to fixed lengths. However, padding to fixed lengths is permitted.

Encode the individual data fields as shown in Section 4.2.6, Data Types on page 12.

(v) If the field definition calls for a field to be broken into components, the following rules are used:

(a) If more than one component is included separate them using the component separator.

(b) Components that are present but null are represented by the characters "".

(c) Components that are not present are treated by including no characters in the component.

(d) Components that are not present at the end of a field need not be represented by component separators. For example, the two following data fields are equivalent:

|QRS^TUV^^| and |QRS^TUV|

(vi) If the field definition calls for a field to be broken into sub-components, the following rules are used:

(a) If more than one sub-component is included, separate them using the sub-component separator.

(b) Sub-components that are present but null are represented by the characters "".

(c) Sub-components that are not present are treated by including no characters in the sub-component.

(d) Sub-components that are not present at the end of a field need not be represented by sub-component separators. For example, the following two data components are equivalent:




Page 16

^AAA&BBB&&^ and ^AAA&BBB^

(vii) If the field definition permits repetition of a field, the repetition separator is used only if more than one occurrence is actually present and is placed between occurrences (If three occurrences are transmitted, two repetition separators are used.) In the example below, two occurrences of telephone number are being sent:

|324-7120~699-1292X129|

(c) Repeat step (b) as long as there are any data elements present to be sent. If all the data fields remaining in the segment definition are not present there is no requirement to include any more delimiters.

(d) End each segment with an ASCII carriage return character.

(2) Repeat step (1) until all segments have been generated.

The following rules apply to receiving MOSAIQ ESI messages and converting their contents to data values:

(1) Ignore segments, fields, components and extra repetitions of a field that are present but were not expected.

(2) Treat segments that were expected but are not present as consisting entirely of fields that are not present.

(3) Treat fields and components that are expected but were not included in a segment as not present.

(4) If MOSAIQ ESI cannot make a distinction between data fields that are not present and those that are null, it will treat data fields that are not present as null.

4.2.6 Data Types

Data Types represent restrictions on the contents of the data fields. The following types are defined†:

ST String - Any display characters are allowed. String data is left justified with trailing blanks optional. Example:

|almost any data at all|

NM Numeric - A leading "+" or "-" sign may be included. In the absence of a sign, the number is assumed to be positive. A decimal point may be included. If there is no decimal point, the number is assumed to be an integer. Leading zeros, or trailing zeros after a decimal point, are not significant. The two values "01.20" and "1.2" are identical. Example:

|888|

|-123.456|

DT Date - Always includes 4-digit year (YYYYMMDD). Example:

|20010704| July 4, 2001

TM Time - Always in the format HHMM[SS][+/-ZZZZ]* using a 24 hour clock notation. Seconds are optional. Seconds not present are interpreted as 00. The time zone (+/-ZZZZ) is optional. If not otherwise specified, the local time zone of the sender is assumed. Midnight is represented as 0000. Example:

|0900| Nine AM.

|235959| One second before midnight.

† The format of these definitions does not conform to either Elekta or HL7 documentation conventions. *This data field is not used by the current version of MOSAIQ ESI.




Page 17

TS Time Stamp - Contains the exact time of an event, including the date (YYYYMMDDHHMM[SS][+/-ZZZZ]*). Seconds are optional. Seconds not present are interpreted as 00. The time zone is optional, but if present either the + or - sign must be included, but not both. Midnight is represented as 0000 combined with the date of the day that is just beginning. The maximum length of a TS field is 19 characters. 200107050000 represents midnight on the night extending from July 4 to July 5, 2001 in the local time zone of the sender. Examples:

|20010704010159| 1:01:59 on July 4, 2001.

PT Processing Type - Specifies the type of database used. Components are: [Processing ID (ID)]^[Processing Mode(ID)].

PL Person Location - This data type is used to specify a patient location within a healthcare institution, in Point of care [(IS )] ^ [room (IS )] ^ [bed (IS )] format. Example:

|RADT^200^100|

PN Person Name - Specified as multiple components: last name, first name, middle initial or name, suffix (e.g.: JR or III), prefix (e.g.: DR), and degree (e.g. MD). The sending system may send upper and lower case or all upper case. The receiving system may convert to all upper case if required. Example:

|KILDARE^MIKE^R^""^DR^PHD|

|BART^BLACKÂÎII^""^""|

XPN Person Name - In version 2.3 replaces the PN data type. Additional components are not used by MOSAIQ ESI.

TN “Telephone Number - Always in the form:

[NN][(999)]999-9999[X99999][B99999]*[C any text]*

The optional first two digits are the country code. The optional X portion gives an extension. While no explicit limit is placed on the text field, receiving systems may be expected to truncate values that are more than 10 characters long. Examples:

|(555)555-5555X222|

|555-5555|

XTN Telephone Number - In version 2.3 replaces the TN data type; MOSAIQ ESI does not use additional components.

AD Address - Consists of the following components separated by the component separator: street address, other designation, city, state or providence, zip, country. For use within the United States, state or province should be represented by the official US Postal service two-letter codes. For use within the United States, zip takes the form 99999[-9999]. For use within the United States, the country code is assumed to be USA if null. Example:

|101 MARINA BLVD^#32ÂNYPLACE^CA^94105^""|

XAD Address - In version 2.3 replaces the AD data type; MOSAIQ ESI does not use additional components.

ID Coded Value - The value of such a field follows the formatting rules for an ST field except that it is drawn from a table of legal values. Examples of ID fields include physician ID, religion, and gender. Any time the ID data field appears, the legal values for that data field appear in a table.




Page 18

The manner in which the valid values are defined for ID fields vary. Certain fields, such as Physician ID or Patient Location, have values that vary from institution to institution. Others, like Event type, are limited because they affect the interpretation of messages that contain them.

IS Coded Value for user defined table - The value of such a field follows the formatting rules for an ST field except that it is drawn from a user defined table of legal values.

SI Sequence ID - Always a positive, non-zero integer in the form of an NM field. Certain segments may repeat within a message. A field of this type is included as the second data field within each such segment. The fields follow the syntactic rules for a Numeric field. Generally, in an initial message they follow the sequence 1, 2, 3, ... for repetitions of the same segment type.

The segment IDs in response messages or in updates of previous messages occur in arbitrary order and identify the specific occurrence of the segment data fields being referred to or being altered.

Because of the way information is stored and used within the MOSAIQ system, Sequence IDs are generally not used to uniquely identify previously sent information.

CE Coded Element – A field that contains codes and the text associated with that code. To allow all six types of this data type to be valued, the maximum length of this data type must be at least sixty.

CM Composite - A field that is a combination of other meaningful data fields. Each portion is called a component. Certain specific composites have been separately identified and are described below.

CK Composite ID with check digit - A composite consisting of three components: an id number, a check digit, and a code indicating the check digit scheme employed. If an external system requires use a check digit scheme, MOSAIQ ESI accepts the check digit and appends it on the end of the ID for use in the MOSAIQ system. If required for export, the ID is re-formatted according to the check digit scheme and exported. Example:

|1289526|

|128952^6^M11| If received, this CK is stored as 1289526 in MOSAIQ.

CN Composite ID and Name - A field identifying a person both as a coded value and with a text name. The first component is the coded ID according to a site-specific table. The second and subsequent components are the person's name in the form of a PN field.

For physician IDs, ESI requires only a valid, unique ID number. Names may be used when an external system does not support unique IDs. However, both first and last name must match those stored in MOSAIQ. A name may be included along with an ID, but the ID will be used during processing. Examples:

|00087^Doctor^This^""^MD|

|00087|

|^Doctor^This|

EI Entity Identifier - The entity identifier defines a given entity within a specified series of identifiers. Components are: [entity identifier (ST)] ^ [namespace ID (IS)[ ^ [universal ID (ST)] ^ [universal ID type (ID)].

XCN Composite ID and Name - In version 2.3 replaces the CN data type; MOSAIQ ESI does not use additional components.




Page 19

LA2 Location with Address Variation 2 – Specifies a location and its address. This has limited use and will only contain the Facility OID defined in the interface as in the example.

|^^^2.16.840.1.113883.3.526.2.1492|

The MOSAIQ ESI segments specified in this document do not use the HL7 TX, FT, and CQ data types. As stated above the CK and CN data types are accepted, but only portions of the components included within the data type may be used, depending on site-specific configuration.

4.2.7 Processing Rules The processing rules described here apply to all MOSAIQ ESI message exchanges. MOSAIQ ESI processes messages in accordance with HL7 original acknowledgement mode. In the original acknowledgement-processing mode, MOSAIQ ESI validates the message syntactically, processes it and sends an acknowledgement to the initiating external system. MOSAIQ ESI requires no acknowledgment from external systems following output of transaction messages. An external system creates a message with data values as defined in the appropriate chapter of this document. The data values provided in the Message Header (MSH) segment must include as a minimum the required data fields. The message is encoded according to the applicable rules, grouped as one or more messages in a batch file, and delivered to MOSAIQ ESI. Upon receiving a message from an external system MOSAIQ ESI: 1. Accepts the message.

2. Partially validates it syntactically and against the rules described below:

a. The Message Type in the MSH segment is acceptable.

b. The Processing ID in the MSH segment is appropriate.

c. The Receiving Facility in the MSH segment matches configured value.

e. The Receiving Application in the MSH segment matches configured value.

If any of these fail, the message is rejected (General Acknowledgment (ACK) message with Application Reject ('AR') in the Acknowledgment Code)

3. When processing the message, one of the following functions will occur:

a. The message is processed successfully, generating the response message (message type ACK). The MSA segment of the response message contains “AA” in the Acknowledgment Code field.

-OR-

b. An error response message is sent, providing error information in functional segments to be included in the response message. The MSA segment of the response message contains Application Error (“AE”) in the Acknowledgment Code.

-OR-

c. The message is rejected for reasons unrelated to its content or format (system down, internal error, etc.). The MSA segment of the response message contains Application Reject ('AR') in the Acknowledgment Code.

4. Sends the response, error, or reject message to the sending external system. The message is type ACK.

The MSH segment in the response is constructed following the rules used to create the initial message. In particular, the date, time, and message control ID refer to the response message; they are not echoes of the fields in the initial




Page 20

message. The Receiving Application and Receiving Facility, and Processing ID fields contain codes that are copied from the Sending Application, Sending Facility and Processing ID fields of the external system message. MOSAIQ ESI does not currently support either the Sequence Number Protocol or Continuation Messages and Segments HL7 message protocol variants. Each ACK message is either sent back individually via TCP/IP or grouped together in a file as defined in the interface definition.

4.3 Processing Mode Messages can be processed via different processing modes. The user can select a particular processing mode for each interface definition.

4.3.1 Interactive Mode Interactive mode enables the user to process the messages from an ASCII file. This mode only processes one file at a time. The interactive mode is intended for use in testing interfaces, one time data imports and manual file based interfaces. Interactive mode can be used with or without FTP functionality. Without FTP functionality, the user specified file is processed through the ESI. With FTP functionality, the file is pulled from an FTP server based on the FTP settings and is copied to the user specified Destination prior to being processed through the ESI. Note that the input file is not deleted from the original directory. Results are written to the interface log file.

4.3.2 Polling Mode Polling mode enables the user to process the messages from several ASCII files. The Polling interface searches for files matching the user-defined settings at user-defined intervals. When files are found, they are processed through the ESI. All files residing in the Destination directory will be processed. Note that wildcards can be used when specifying the Input File specifications. Input file(s) are deleted from their original location to prevent duplicate file processing. Once processed, the files will be moved from the Destination directory to a subdirectory labeled “BACK” if the interface is configured to “Backup Files After Processing”. Otherwise, the files will be deleted. Polling mode can be used with or without FTP functionality. Without FTP, the ESI searches for the user specified input file(s). If any files are found, these files are copied to the user specified Destination and processed through the ESI. With FTP functionality, the input files(s) are pulled from an FTP server based on the FTP settings and copied to the user specified Destination prior to being processed through the ESI. Results are written to the interface log file.

4.3.3 TCP/IP Mode The TCP/IP mode is intended for use in real-time interfaces. Based on a user defined setting, the ESI waits for and receives HL7 messages wrapped in “MLLP” (minimum lower level protocol). ESI expects each message to be sent in its entirety; messages will not be reconstructed by ESI. Each message is processed and results are written to the interface log. The interface can be configured to send an ACK (acknowledgement) back to the originator of the message. The interface can also be configured to send messages on to up to three additional ports with either the same or different IP addresses.




Page 21

4.4 Tables Some of the data fields in the HL7 messages must be specified in terms of a coded value that represents a text equivalent. The relationship between the coded value and the text equivalent is defined in a table. Some of the tables are HL7 standard tables and some are maintained within MOSAIQ tables. The tables are specified in the message segment definition sections using four character numbers. Although some tables are considered HL7 standard, such as table 0006, RELIGION, the values in the tables can be changed if MOSAIQ ESI and the external system agree on the contents. Default values for these tables are listed, by table number, in Appendix A. Some of the tables listed in Appendix A are user defined, and as such, may contain values other than the default values listed. Alternatively, translation code mapping may be defined within MOSAIQ should the MOSAIQ ESI and the external system require different coded values for the same field. A translation code-mapping document can be obtained from Elekta Client Services if required.

4.5 MOSAIQ ESI Messages 4.5.1 Control Messages As specified in section 4.2.7, Processing Rules on page 19, MOSAIQ ESI uses HL7 original acknowledgment mode for processing messages. ACK: General Acknowledgment The ACK message is sent after MOSAIQ ESI has received and processed a message following the structure:

ACK General Acknowledgment

MSH Message Header MSA Message Acknowledgment [ ERR ] Error

By default, ESI writes all ACK messages to the transaction log file (Section 7). MOSAIQ ESI can provide the messages directly to the sending application if the interface is configured for TCP/IP communications. This option is described in Section 5.1, Configurable Options on page 54.




Page 22

4.5.2 Batch Processing This section makes no assumptions concerning the file transfer protocol. Batch processing is currently used for HL7 charge export processing. The structure of a MOSAIQ ESI HL7 compatible batch file is given in Figure 1 below.

[FHS] File Header Segment

{ [BHS] Batch Header Segment

{MSH One or more HL7 Encoded Messages

... ...

...

}

[BTS] Batch Trailer Segment

}

[FTS] File Trailer Segment

FIGURE 1 - MOSAIQ ESI BATCH FILE FORMAT




Page 23

4.5.3 Outbound Messages – Trimming of White-Space In general, every field, component, and repeating field of a segment is trimmed of leading and trailing white-space before OIM puts it into a segment. For example, a value of “ xxxxx ” will be inserted into the segment as “xxxxx”. A value of “ ” will result in an empty field.

Note that trimming of data may occur at any point in the workflow, depending on the design of the application. Data may be trimmed (in this order):

1. As the user enters data into a form in MOSAIQ.

2. As the user-entered data is stored in the MOSAIQ database.

3. As the data is retrieved from the database, by a database query in OIM.

4. As the data for the field is constructed, by the interface-specific message formatting code in OIM.

5. As the field data is put into the segment, by the generic message formatting code in OIM. ***

*** The final point at which data can be trimmed is in the generic message formatting code in OIM. This is where the generic message formatter concatenates together all the fields that have been built by an interface-specific message formatter. At this point, ALL fields are trimmed EXCEPT FOR the fields in the NTE, OBX, or TXA segments. These special segments may contain white-space which is significant, so it is left to the specific interfaces to decide whether or not to trim the data in these segments.




Page 24

4.5.4 Admission/Discharge/Transfer Messages (ADT Inbound) The ADT Transaction Set provides for transmitting new or updated information about patients. Generally, information is entered into the ADT system and passed to MOSAIQ ESI in the form of an unsolicited update.

Each triggering event supported by the ESI:ADT product is listed below, along with the applicable form of the message exchange.

4.5.4.1 Event Code: A01 - Admit / Visit Notification

An A01 event is intended to be used for “Admitted” patients only. An A01 event is sent as a result of a patient undergoing the admission process which assigns the patient to a bed. It signals the beginning of a patient’s stay in a healthcare facility. Normally, this information is entered in the primary Patient Administration system and broadcast to the nursing units and ancillary systems. See 2.1 (Product Description) to determine which interface product supports this event.

ADT^A01 ADT Message Rep# ACK^A01 General Acknowledgment

MSH Message Header MSH Message Header EVN Event Type MSA Message Acknowledgment PID Patient Identification [ ERR ] Error [ { NK1 } ] Next of Kin /Associated Parties 3 PV1 Patient Visit [ { AL1 } } Allergy Information 0-Many [ { DG1 } ] Diagnosis Information 10 [ { GT1 } ] Guarantor 1 [ { IN1 } ] Insurance 5

MOSAIQ ESI inserts or updates (configurable, see section 5.1.1.2) patient demographic for A01, A04, A05, A08, A28 and A31 events. The information to be inserted or updated includes:

♦ PID – Patient Demographics (name, address, phone, … etc.) ♦ NK1 – Related Parties (relative and emergency contact) ♦ PV1 – Patient Visit Information (patient class, location, admit date/time, links to physicians, … etc.) ♦ AL1 – Allergies. This is only supported by IIM ADT Inbound. ♦ DG1 – Diagnosis Code ♦ GT1 – Guarantor (name, address, phone, employer information … etc.) ♦ IN1 – Links to patient’s insurance companies (name, policy number, contact, … etc.)

See the mapping for each HL7 segment for more details.




Page 25

4.5.4.2 Event Code: A02 – Transfer a Patient

An A02 event is issued as a result of the patient changing his or her assigned physical location. See 2.1 (Product Description) to determine which interface product supports this event.


MSH Message Header MSH Message Header EVN Event Type MSA Message Acknowledgment PID Patient Identification [ ERR ] Error PV1 Patient Visit

MOSAIQ ESI updates patient demographic data for A02. The information to be updated includes: ♦ PID – Patient Demographics (name, address, phone, … etc.) ♦ PV1 – Patient Visit Information (patient class, location, admit date/time, links to physicians, … etc.)

4.5.4.3 Event Code: A03 – Discharge / End Visit

Event Code A03: An A03 event signals the end of a patient’s stay in a healthcare facility. It signals that the patient’s status has changed to “discharged” and that a discharge date has been recorded. The patient is no longer in the facility. The patient’s location prior to discharge should be entered in PV1-3-assigned patient location. See 2.1 (Product Description) to determine which interface product supports this event.



MOSAIQ ESI limits the data being updated for this event code to the following: ♦ PV1-3 (Assigned Patient Location) – Used to update ADM:room_num, ADM:nurse_unit and

ADM:bed_num. ♦ PV1-45 (Discharge Date / Time) – Used to update ADM:discharge. ♦ PID-18 (Account Number) – Used to inactivate an Accounts record.

4.5.4.4 Event Code: A04 - Register a Patient

Event Code A04: An A04 event signals that the patient has arrived or checked in as a one-time, or recurring outpatient, and is not assigned to a bed.

See 2.1 (Product Description) to determine which interface product supports this event.






Page 26



See the mapping for each HL7 segment for more details. A04 event code is also used to export Patient Syndromic Problems from MOSAIQ through OIM. Patient problems are exported within the DG1 segment of an A04 message similar to patient diagnosis. The message structure for the A04 pertaining to the export of patient problems requires MSH,EVN,PID,PV1 and DG1 segments as shown below. No other segments are exported within the message. See 2.1 (Product Description) to determine which interface product supports this event.


MSH Message Header MSH Message Header EVN Event Type MSA Message Acknowledgment PID Patient Identification [ ERR ] Error PV1 Patient Visit { DG1 } Diagnosis Information 4

4.5.4.5 Event Code: A05 – Pre-Admit a Patient

An A05 event is sent when a patient undergoes the pre-admission process. During this process, episode-related data is collected in preparation for a patient’s visit or stay in a healthcare facility. See 2.1 (Product Description) to determine which interface product supports this event.



MOSAIQ ESI inserts or updates (configurable, see section 5.1.1.2) patient demographic for A01, A04, A05, A08, A28 and A31 events. For MOSAIQ purposes this event will be treated like an A01. The information to be inserted or updated includes:

♦ PID – Patient Demographics (name, address, phone, … etc.) ♦ NK1 – Related Parties (relative and emergency contact)




Page 27

♦ PV1 – Patient Visit Information (patient class, location, admit date/time, links to physicians, … etc.) ♦ AL1 – Allergies. This is only supported by IIM ADT Inbound. ♦ DG1 – Diagnosis Code ♦ GT1 – Guarantor (name, address, phone, employer information … etc.) ♦ IN1 – Links to patient’s insurance companies (name, policy number, contact, … etc.)


4.5.4.6 Event Code: A06 – Change an Outpatient to Inpatient

An A06 event is sent when a patient who was present for a non-admitted visit is being admitted after an evaluation of the seriousness of the patient’s condition. This event changes a patient’s status from “non-admitted” to “admitted.” The new patient location should appear in PV1-3-assigned patient location. See 2.1 (Product Description) to determine which interface product supports this event.



MOSAIQ ESI updates patient demographic for A06. The information to be inserted or updated includes: ♦ PID – Patient Demographics (name, address, phone, … etc.) ♦ PV1 – Patient Visit Information (patient class, location, admit date/time, links to physicians, … etc.)

4.5.4.7 Event Code: A07 – Change an Inpatient to Outpatient

An A07 event is sent when a patient who was admitted changes his/her status to “no longer admitted” but is still being seen for this episode of care. This event changes a patient from an “admitted” to a “non-admitted” status. The new patient location should appear in PV1-3-assigned patient location. See 2.1 (Product Description) to determine which interface product supports this event.



MOSAIQ ESI updates patient demographic for A06. The information to be inserted or updated includes: ♦ PID – Patient Demographics (name, address, phone, … etc.) ♦ PV1 – Patient Visit Information (patient class, location, admit date/time, links to physicians, … etc.)

4.5.4.8 Event Code: A08 - Update Patient Information

This trigger event is used when any patient information has changed but when no other trigger event has occurred. For example, an A08 event can be used to notify the receiving systems of a change of address or a name change. See 2.1 (Product Description) to determine which interface product supports this event.




Page 28






4.5.4.9 Event Code: A11 – Cancel Admission / Visit

Event code A11 is used when the admission or outpatient registration has been cancelled, either because of erroneous data entry or a decision to not admit/check-in the patient. The registration clerk will cancel the admission or registration in the HIS. See 2.1 (Product Description) to determine which interface product supports this event.

A11 ADT Message Rep# ACK^A11 General Acknowledgment


MOSAIQ ESI updates patient demographics for A11 for the patient identified in the message. The information updated includes:

♦ PID – Patient Demographics (accounts inactive date/time and voided indicator ) ♦ PV1 – Patient Visit Information (admission date/time)

4.5.4.10 Event Code: A12 – Cancel Admission / Visit

Event code A12 is used when a transfer event has been cancelled, because of either erroneous data entry or a decision to not move the patient. The registration clerk will cancel the transfer in the HIS. Note: the prior patient location will be stored in PV1-3. See 2.1 (Product Description) to determine which interface product supports this event.




Page 29




♦ PV1 – Patient Visit Information (nurse unit, room number and bed number)

4.5.4.11 Event Code: A13 – Cancel Discharge/End Visit

Event code A13 is used when the inpatient discharge or outpatient end-visit has been cancelled, because of either erroneous data entry or a decision to not release the patient. The registration clerk will cancel the discharge or end visit action in the HIS. See 2.1 (Product Description) to determine which interface product supports this event.




♦ PID – Patient Demographics (accounts inactive date/time) ♦ PV1 – Patient Visit Information (discharge date/time)

4.5.4.12 Event Code: A17 - Swap Patient Location

Event code A17 is used when it is decided that two patients will exchange beds. The patient ID and visit data are repeated for the two patients changing places. See 2.1 (Product Description) to determine which interface product supports this event.


MSH Message Header MSH Message Header EVN Event Type MSA Message Acknowledgment PID Patient Identification [ ERR ] Error PV1 Patient Visit PID Patient Identification PV1 Patient Visit

MOSAIQ ESI updates patient demographics for A17 and swaps the room and bed numbers for the two patients identified in the message. The information to be updated includes:

♦ PID – Patient Demographics (name, address, phone, … etc.) ♦ PV1 – Patient Visit Information (patient class, location, admit date/time, links to physicians, … etc.)




Page 30

4.5.4.13 Event Code: A18 - Merge Patient Information (ESI:ADT)

The A18 event is used to merge current and previous patient identification numbers: PID-3-patient identifier list, PID-2-patient ID, PID-4-alternate patient ID-PID, and PID-18-patient account number. The PID segment contains the surviving patient ID information. The MRG segment contains the non-surviving information.



MSH Message Header MSH Message Header EVN Event Type MSA Message Acknowledgment PID Patient Identification [ ERR ] Error MRG Merge Information PV1 Patient Visit

MOSAIQ ESI limits the data being updated for this event code to the following: ♦ PID-2 (Patient ID – External) – Used to update one of IDT:IDA – IDT:IDF ♦ PID-3 (Patient ID – Internal) – Used to update IDT:IDA or IDT:IDB ♦ PID-4 (Alternate Patient ID) – Used to update one of IDT:IDA – IDT:IDF ♦ PID-18 (Patient Account Number) – Used to update one of IDT:IDA – IDT:IDF

4.5.4.14 Event Code: A19 - Patient Query

Another application determines a need for ADT data about a patient and sends a query to an external ADT system. The Who Filter in the QRD identifies the patient ID upon which the query is defined and the Format Code must be R (record oriented). The ADT Event Type Segment, if included in the response, describes the event for which the ADT system initiated an unsolicited update. The Query Acknowledgment message occurs in response to a query sent to an external system. Note that only the acknowledgment is supported, not the initiating message. External systems that prefer not to screen messages can configure a process that initiates a query when a patient comes into an institution. See 2.1 (Product Description) to determine which interface product supports this event.

ADTÂ01 ADT Message Repeat

MSH Message Header QRD Query Definition

MOSAIQ ESI accepts the following ADT Response from the QRY Message. The Format Code must be R (record oriented) and the Who Filter must contain PATIENT ID - INTERNAL. Event types of A01, A08, and P01 are accepted, if the optional EVN segment is not included, the default shall be A08. Although EVN, PID, and PV1 segments may repeat for the ADT response, only those with PATIENT ID - INTERNAL matching the Who Filter will be accepted.

ADT^19 ADT Message Rep# ACKÂ19 General Acknowledgment

MSH Message Header MSH Message Header MSA Message Acknowledgment MSA Message Acknowledgment QRD Query Definition [ ERR ] Error { [ EVN ] Event Type PID Patient Identification PV1 Patient Visit }

IIM accepts the following ADR Â19




Page 31

ADR^A19 ADT Message Rep# ACK General Acknowledgment

MSH Message Header MSH Message Header PID Patient Identification [ ERR ] Error [ { NK1 } ] Next of Kin /Associated Parties 3 PV1 Patient Visit [ { AL1 } } Allergy Information 0-Many [ { DG1 } ] Diagnosis Information 10 [ { GT1 } ] Guarantor 1 [ { IN1 } ] Insurance 5

4.5.4.15 Event Code: A23 - Delete a Patient Record

The A23 event is used to delete patient and associated records from the database. MOSAIQ ESI supports the A23 event code using the MOSAIQ Database Maintenance API; therefore, the functionality of this request is restricted to the existing capabilities of DBM. Specifically, patients can only be deleted if no charge or billing records exist for the patient. See 2.1 (Product Description) to determine which interface product supports this event.



4.5.4.16 Event Code: A28 – Add Person or Patient Information

For MOSAIQ purposes this event will be treated like an A04. See 2.1 (Product Description) to determine which interface product supports this event.








Page 32


4.5.4.17 Event Code: A30 - Merge Person Information (ESI:ADT)

The A30 event is used to merge person information on an MPI. For MOSAIQ this event will be treated as an A34 event. See 2.1 (Product Description) to determine which interface product supports this event.


MSH Message Header MSH Message Header EVN Event Type MSA Message Acknowledgment PID Patient Identification [ ERR ] Error MRG Merge Information

MOSAIQ ESI limits the data being updated for this event code to the following: ♦ PID-3 (Patient ID – Internal) – Used to update IDT:IDA or IDT:IDB.

4.5.4.18 Event Code: A31 - Update Person Information

An A31 event can be used to update person information on an MPI. For MOSAIQ purposes this event will be treated like an A08. See 2.1 (Product Description) to determine which interface product supports this event.









Page 33

4.5.4.19 Event Code: A34 - Merge Patient Information - Patient ID Only (ESI:ADT)

The A34 event is used to merge current and previous patient IDs only. The PID segment contains the surviving patient ID information. The MRG segment contains the non-surviving information. Only PID-3-patient identifier list is updated as a result of the merge. See 2.1 (Product Description) to determine which interface product supports this event.




4.5.4.20 Event Code: A35 - Merge Patient Information - Account Number Only (ESI:ADT)

The A35 event is used to merge current and previous patient account numbers only. The PID segment contains the surviving patient ID information. The MRG segment contains the non-surviving information. See 2.1 (Product Description) to determine which interface product supports this event.



MOSAIQ ESI limits the data being updated for this event code to the following: ♦ PID-18 (Patient Account Number) – Used to update one of IDT:IDA – IDT:IDF.

4.5.4.21 Event Code: A36 - Merge Patient Information - Patient ID and Account Number (ESI:ADT)

The A36 event is used to merge current and previous patient IDs and account numbers only. The PID segment contains the surviving patient ID information. The MRG segment contains the non-surviving information. See 2.1 (Product Description) to determine which interface product supports this event.



MOSAIQ ESI limits the data being updated for this event code to the following: ♦ PID-3 (Patient ID – Internal) – Used to update IDT:IDA or IDT:IDB. ♦ PID-18 (Patient Account Number) – Used to update one of IDT:IDA – IDT:IDF.




Page 34

4.5.4.22 Event Code: A38 – Cancel Pre-Admit

An A38 event is sent when a patient incorrectly undergoes the pre-admission process and a correction is required. See 2.1 (Product Description) to determine which interface product supports this event.



MOSAIQ ESI updates patient demographics for A38 for the patient identified in the message. This event code is processed the same as A11. The information updated includes:

♦ PID – Patient Demographics (accounts inactive date/time and voided indicator ) ♦ PV1 – Patient Visit Information (admission date/time)

4.5.4.23 Event Code: A40 - Merge Patient - Patient Identifier List (ESI:ADT)

An A40 event is used to signal a merge of records for a patient that was incorrectly filed under two different identifiers. The MRG segment contains the non-surviving information. Only PID-3-patient identifier list is updated as a result of the merge. For MOSAIQ purposes this event will be treated like an A34.





4.5.4.24 Event Code: A18, A30, A34, and A40 Merge Events (IIM:ADT)

There are multiple Merge events defined in HL7. For IIM:ADT we will support A18, A30, A34 and A40. We will process all of them the same way. The following details discuss the merge event from the A40 perspective.

Within MOSAIQ, we do not provide a way to automatically combine two patient records and all of their associated data under one patient. Instead, we provide links via patient logging (PatLog table) to indicate that two or more sets of patient records belong together







Page 35

If the global option “Allow Update with Merge” is checked then after the normal merge processing the survivor patient will be updated according to normal update rules for an A08. Otherwise, MOSAIQ ESI limits the data being updated for this event code to the following:

♦ PID-3 (Patient ID – Internal) – Used to update IDT:IDA or IDT:IDB. ♦ PatLog table inserts.

Following are the processing rules with respect to matching patients for the PID and MRG segments:

♦ When a match is found on both the correct (PID-3) and incorrect (MRG:1) IDs, we will add PatLog records to indicate the linkage between two Patient records.

♦ When we are unable to find a match based on the incorrect identifier (MRG:1), we will simply write a warning to the interface log indicating that no match was found.

♦ When we are able to find a match with the incorrect identifier, but no match on the correct identifier, we will change the incorrect identifier to the correct identifier.

♦ When we are unable to find a match based on the incorrect identifier (MRG:1) or the correct identifier (PID-3), we will reject the message with a patient not found message.




Page 36

4.5.5 Finance (BAR and DFT) Messages The Finance Transaction Set provides for transmitting new or updated information about patients including demographics, charges and insurance information. Each triggering event supported by the ESI:ADT product is listed below, along with the applicable form of the message exchange.

4.5.5.1 Event Code: P01 - Finance: Add and Update Patient Accounts

P01 is the only BAR message we support. The P01 message is imported via the MOSAIQ ESI ADT Inbound interface. We do not export the P01 or any other BAR message.


BAR^P01 BAR Message Rep# ACK^P01 General Acknowledgment

MSH Message Header MSH Message Header EVN Event Type MSA Message Acknowledgment PID Patient Identification [ ERR ] Error [ PV1 ] Patient Visit [ { DG1 } ] Diagnosis Information 4 [ { GT1 } ] Guarantor 1 [ { NK1 } ] Next of Kin /Associated Parties 2 [ { IN1 } ] Insurance 5

MOSAIQ ESI inserts or updates (configurable, see section 5.1.1.2) patient demographic for P01, A01, A04, A05, A08, A28 and A31 events. The information to be inserted or updated includes:

♦ PID – Patient Demographics (name, address, phone, … etc.) ♦ NK1 – Related Parties (relative and emergency contact) ♦ PV1 – Patient Visit Information (patient class, location, admit date/time, links to physicians, … etc.) ♦ DG1 – Diagnosis Code ♦ AL1 – Allergies. This is only supported by IIM ADT Inbound. ♦ GT1 – Guarantor (name, address, phone, employer information … etc.) ♦ IN1 – Links to patient’s insurance companies (name, policy number, contact, … etc.)

See the mapping for each HL7 segment for more details. The MOSAIQ database accepts up to four admitting diagnosis.




Page 37

4.5.5.2 Event Code: P03 - Finance: Post detail financial transactions - Inbound

Event Code P03. The Detail Financial Transaction is used to describe a financial transaction imported into MOSAIQ for billing purposes. In addition, ESI can be configured to optionally add or update patient demographics and payer information. Note that the transaction code (FT1-7) must be specified in terms of hospital codes in order for the messages to be successfully imported.


DFT^P03 DFT Message Rep# ACK^P03 General Acknowledgment

MSH Message Header MSH Message Header EVN Event Type MSA Message Acknowledgment PID Patient Identification [ ERR ] Error [ PV1 ] Patient Visit { FT1 } Financial Transaction 10 [ { DG1 } ] Diagnosis Information 4 [ { GT1 } ] Guarantor 1 [ { IN1 } ] Insurance 5

MOSAIQ ESI optionally inserts or updates (configurable, see section 5.1.1.4) patient demographic for the P03 events. It also inserts financial transactions. The information to be inserted or updated includes:

♦ PID – Patient Demographics (name, address, phone, … etc.) ♦ PV1 – Patient Visit Information (patient class, location, admit date/time, links to physicians, … etc.) ♦ DG1 – Diagnosis Code ♦ GT1 – Guarantor (name, address, phone, employer information … etc.) ♦ IN1 – Links to patient’s insurance companies (name, policy number, contact, … etc.) ♦ FT1 – Charges associated with a patient (hospital code, CPT code, quantity, ICD code, … etc.)

See the mapping for each HL7 segment for more details. See section 5.1.1.4 for information regarding HL7 Charge Inbound configuration settings.

4.5.5.3 Event Code: P03 - Finance: Post detail financial transactions - Outbound

Event code P03. The Detail Financial Transaction is used to describe a financial transaction exported from MOSAIQ for use by an external billing system. See 2.1 (Product Description) to determine which interface product supports this event.

DFT^P03 DFT Message Rep#

MSH Message Header EVN Event Type PID Patient Identification [ PV1 ] Patient Visit { FT1 Financial Transaction N** [NTE] Notes and comments 1 [ { OBX } ] Observations/Results N [ { DG1 Diagnosis Information 10 [ ZDX ] Additional diagnosis information 10




Page 38

} ] [ { GT1 } ] Guarantor 1 [ { IN1 } ] Insurance 5 [ZPT] Additional patient data 1 [ZCH] Additional charge data 1 [ZRF] Referral data 1 [{ZTX}] Treatment data No

Limit }

MOSAIQ ESI exports financial transactions (charges). It also optionally exports patient demographics. The information to be exported includes:

♦ PID – Patient Demographics (name, address, phone, … etc.) ♦ PV1 – Patient Visit Information (patient class, location, admit date/time, links to physicians, … etc.) ♦ FT1 – Charges associated with a patient (hospital code, CPT code, quantity, ICD code, … etc.) ♦ NTE – Notes and comments from the charge slip. ♦ OBX – Test Results/Measurements from the charge slip. ♦ DG1 – Diagnosis Code ♦ ZDX – Proprietary Diagnosis Segment, one ZDX segment following each DG1 segment ♦ GT1 – Guarantor (name, address, phone, employer information … etc.) ♦ IN1 – Links to patient’s insurance companies (name, policy number, contact, … etc.) ♦ ZPT – Additional patient data ♦ ZCH – Additional charge data ♦ ZRF – Referral data ♦ ZTX – Treatment data

The NTE, OBX, ZPT, ZCH, ZRF, ZTX and ZDX segments only apply to OIM Charge Export, not HL7 Code Export on MOSAIQ. See the mapping for each HL7 segment for more details. ** For HL7 Code Export, the repeat number for the FT1 segment group is “1”, that is, there is only one charge per message. For OIM Charge Export, there will be one or more charges per message. The ordering in which charges are exported by OIM Charge Export and the grouping of charges within HL7 messages is defined below: When “Group Charges by Appointment ID” in the “Other Options” tab is checked, the following rules define the grouping and ordering of these records.

1. Charge records passing the filtering criteria (including Charge.SCH_ID IS NOT NULL) will be exported in the following sort order: 1.1. Patient Name (Last, First, Middle) 1.2. Appointment ID (Charge.SCH_ID) 1.3. Charge or Credit (Based on (Charge.Days_Units) 1.4. Procedure Date Time (Charge.Proc_DtTm) 1.5. Charge ID (Charge.CHG_ID)

2. A new HL7 message will be created for each set of Charge records with the same values for:




Page 39

2.1. Patient Name (Last, First, Middle) 2.2. Appointment ID (Charge.SCH_ID) 2.3. Charge or Credit (Based on (Charge.Days_Units)

3. For each Charge record, FT1 segments will be ordered by: 3.1. Procedure Date Time (Charge.Proc_DtTm) 3.2. Charge ID (Charge.CHG_ID)

When “Group Charges by Appointment ID” in the “Other Options” tab is not checked, the following rules define the ordering of these records.

1. Charge records passing the filtering criteria will be exported in the following sort order: 1.1. Patient Name (Last, First, Middle) 1.2. Procedure Date Time (Charge.Proc_DtTm) 1.3. Charge ID (Charge.CHG_ID)

2. A new HL7 message will be created for each Charge record.




Page 40

4.5.6 Observation Reporting Messages The observation reporting set provides for transmission of unsolicited observations reports for patients registered in the MOSAIQ system. Each trigger event supported by the Lab Results Inbound and Document Inbound interfaces is listed below, along with the applicable form of the message.

4.5.6.1 Event Code R01 - Unsolicited Transmission of an Observation

The R01 event code is supported by both the ESI:Doc Inbound interface and the ESI:Lab Results Inbound interface. The mapping of information between the HL7 segments and the MOSAIQ database differ for each of these interfaces. The business validation rules also differ. In order to import lab results, the message must contain at least one valid OBR. For an OBR to be valid, the message must be contain at least one OBX segment per OBR segment. The interface supports multiple OBR segments in a single message. The Doc Inbound interface supports a single document per message. For ORU^R01 the ORC segment is repeating according to the HL7 2.3 standard; but support within the interface is limited to a single instance of this segment. Only the first of multiple documents is processed. See 2.1 (Product Description) to determine which interface product supports this event.

ORU^R01 ORU Message Rep# ACK General Acknowledgment

MSH Message Header MSH Message Header [ MSA Message Acknowledgment PID Patient Identification [ ERR ] Error [PD1] Additional Demographics OBR Observation Report ID [{NTE} ] Notes and Comments No limit [{OBX}] Observation / Result {NTE}] Notes and Comments No limit [DSC] Continuation Pointer

NOTE: The DSC segment is only used by the ESI:Doc Inbound interface. If a message is too large for the sending system to transmit entirely it may be split up into a number of messages each containing a part of the total message. These are called continuation messages and the DSC segment and MSH.14 is used to manage these. These messages must be received in sequence and that sequence is determined by the value of MSH.14 and DSC.1 If the message is a partial message and it is not the last message in the sequence it will have a value in DSC.1 which identifies itself. For example DSC|Frag001. The next message received must have this value in MSH.14 (i.e. Frag001) indicating it follows what was in the Frag001 message. It will also have a value in DSC.1 identifying itself if it is not the last in the sequence. NOTE ON DUPLICATE MESSAGE CHECKING: Documents imported are checked for existing documents if the HL7 message has values in MSH.3, MSH.4 and OBR.3. These three values are saved with each document and if a subsequent message contains these values then the document is regarded as a replacement. The original document status will be set to Void if the IBD is configured to do that.




Page 41

4.5.7 Document Management Messages The medical document management set provides for transmission of new or updated documents or information about their status(es). We will process these messages for patients registered in the MOSAIQ system. Each trigger event supported by the IIM:Doc Inbound and OIM:Doc Outbound interfaces is listed below, along with the applicable form of the message. There is a functional size limit of 1 MB per individual HL7 message for the Document interface. HL7 messages that exceed this size can cause processing delays or fail to process successfully.

4.5.7.1 Event Code T02 – Original Document Notification and Content

The T02 event code is supported by both the IIM:Doc Inbound and OIM:Doc Outbound interfaces. See 2.1 (Product Description) to determine which interface product supports this event.


MSH Message Header MSH Message Header EVN MSA Message Acknowledgment PID Patient Identification [ ERR ] Error PV1 Patient Visit TXA Document Notification {OBX}

4.5.7.2 Event Code T10 – Document replacement notification and content

The T10 event code is supported by the OIM:Doc Outbound interface. See 2.1 (Product Description) to determine which interface product supports this event.



4.5.7.3 Event Code T11 – Document Cancel Notification

The T11 event code is supported by the OIM:Doc Outbound interface. See 2.1 (Product Description) to determine which interface product supports this event.






Page 42

4.5.8 Lab Order Messages The lab order set provides for lab order transmission for patients registered in the MOSAIQ system.

4.5.8.1 Event Code O01 – General Order Message

The function of this message is to initiate the transmission of order information. This includes placing new orders, canceling existing orders, discontinuation, holding, etc. ORM messages can also originate with a placer, filler, or an interested third party. The trigger event for this message is any change to an order. Such changes include submission of new orders, cancellations and updates. See 2.1 (Product Description) to determine which interface product supports this event.

ORM^O01 ORM Message Rep# ORR^O02 General Acknowledgment

MSH Message Header MSH Message Header PID Patient Identification MSA Message Acknowledgment [ PV1 ] Patient Visit [ ERR ] Error [ {IN1} ] Insurance 4 [ {NTE} ] Notes and Comments (for

Patient ID) [ GT1 ] Guarantor 1 [ PID Patient Identification { [ {NTE} ] ORC Common Order { OBR Order Detail Segment

OBR, etc. ORC Common Order

[ {NTE} ] Notes and Comments 0-1 OBR Order Detail Segment OBR, etc.

[ {DG1} ] Diagnosis 0-10 } } ]

The NTE segment is not created if there are no notes associated with the lab order. The DG1 segment(s) is not created if there is no diagnosis associated with the lab order. When an approved order is modified, first a message with an event status of CA (Cancel) is sent, and then a message with an event status of NW (New) is sent. The CA (Cancel) message will be identical to the original message except that the event status is CA and the DG1 segments are not included in the message.




Page 43

4.5.9 Radiotherapy requisition Messages This order set imports Radiotherapy requisition information to patients registered in the MOSAIQ system.


The function of this message is to create and/or update Radiotherapy requisition information in MOSAIQ. This includes add a new care plan and diagnosis and updating an existing care plan and diagnosis. See 2.1 (Product Description) to determine which interface product supports this event.


MSH Message Header MSH Message Header PID Patient Identification MSA Message Acknowledgment { [ {NTE} ] ORC Common Order { OBR Order Detail Segment

OBR, etc. ORC Common Order

[ {DG1} ] Diagnosis ZDX 0-1 ZCP [ {NTE} ] Notes and Comments } ]




Page 44

4.5.10 Pharmacy Order Messages The Pharmacy order set provides for pharmacy order transmission for patients registered in the MOSAIQ system. Each trigger event supported by the ESI:Pharmacy Order Export product is listed below, along with the applicable form of the message.


The function of this message is to initiate the transmission of order information. This includes placing new orders, canceling existing orders, discontinuation, holding, etc. The trigger event for this message is any new pharmacy order or any change to an approved order. Such changes include cancellations and updates. See 2.1 (Product Description) to determine which interface product supports this event.


MSH Message Header 1 MSH Message Header PID Patient Identification 1 MSA Message Acknowledgment [ PV1 ] Patient Visit 0-1 [ ERR ] Error [ {IN1} ] Insurance 0-4 [ {NTE} ] Notes and Comments (for

Patient ID) [ GT1 ] Guarantor 0-1 [ [ {AL1} ] Allergy Information 0-N PID Patient Identification { [ {NTE} ] ORC Common Order 1 { RXO Pharmacy/Treatment Order 1 ORC Common Order [RXR] Pharmacy/treatment route 0-1 RXO Order Detail Segment RXO,

etc. [ZXO] Proprietary component

info 0-1 }

[{RXC Pharmacy/treatment component segment

0-N ]

[ZXO]}] Proprietary component info

0-N

[{DG1}] Diagnosis 1 [{OBX}] Observation 1 [ZPR] Protocol 1 }

The PV1, IN1, and GT1 segments are conditional on interface configuration and on whether or not there is insurance and/or guarantor information defined for the patient. The AL1 segment is conditional on interface configuration and on whether or not the patient has allergies. The RXR segment is conditional on a route being present the order. The RXC segment is conditional on order components in the order. If the order is defined as a solution with additives, there will be an RXC segment in the message for each additive. The DG1 segment is conditional on interface configuration and on whether or not there is a diagnosis associated with the pharmacy order. The OBX segment for BSA (Body Surface Area) is conditional on interface configuration and on whether or not any of the components in the order have a BSA.




Page 45

The OBX segment for Weight (kg), Weight (lb), Height (cm), and Height (in) are conditional on interface configuration and on whether or not the patient has the height or weight value available. The ZPR segment is conditional on interface configuration and on whether or not there is protocol information available for the drug. The ZXO segment is conditional on interface configuration and on whether or not there is data available for this segment (currently holds Dose Basis information).




Page 46

4.5.11 Locally Defined Messages HL7 specifies that all messages that begin with “Z” be locally defined. MOSAIQ ESI has two locally defined messages.

4.5.11.1 Event Code: Z01 - Physician Add/Update/Delete

The MOSAIQ system must be able to recognize valid doctor names/IDs when classifying attending, referring, consulting or admitting physicians. A local message exists in order to add, update and remove valid physicians in the system. See 2.1 (Product Description) to determine which interface product supports this event.

ZPA^Z01 ADT Message Rep# ACK^Z01 General Acknowledgment

MSH Message Header MSH Message Header EVN Event Type MSA Message Acknowledgment ZPH Physician Identification [ ERR ] Error

MOSAIQ ESI inserts / updates (configurable, see section 5.1.1.2) or deletes Staff or External physicians. The information to be inserted or updated includes:

♦ ZPH – Staff or External Physician Identification information (name, license, UPIN, address, phone, … etc.) See the mapping for each HL7 segment for more details.

4.5.11.2 Event Code: Z02 - Insurance Add/Update/Delete

The MOSAIQ system must be able to recognize valid insurance company names/IDs when processing patient information. In order to receive and remove valid insurance providers in the system, a local message exists.

ZIN^Z02 ADT Message Rep# ACK^Z02 General Acknowledgment

MSH Message Header MSH Message Header EVN Event Type MSA Message Acknowledgment ZIL Insurance Local [ ERR ] Error

MOSAIQ ESI inserts / updates (configurable, see section 5.1.1.2) or deletes Payers (Insurance Companies). The information to be inserted or updated includes:

♦ ZIL – Insurance Identification information (Company name, ID, Plan ID, address, contact, phone, … etc.) See the mapping for each HL7 segment for more details.




Page 47

4.5.12 Admission/Discharge/Transfer Messages (ADT Outbound) The ADT Outbound Transaction Set provides for transmitting new or updated information about patients. Generally, information is entered into MOSAIQ and sent out, unsolicited, to an external ADT system. Each triggering event supported by the OIM:ADT product is listed below, along with the applicable form of the message exchange.

4.5.12.1 Event Code: A04 - Register a Patient

Event Code A04: An A04 event signals that the patient has arrived or checked in as a one-time, or recurring outpatient, and is not assigned to a bed. See 2.1 (Product Description) to determine which interface product supports this event.


MSH Message Header MSH Message Header EVN Event Type MSA Message Acknowledgment PID Patient Identification [ ERR ] Error PV1 Patient Visit [{AL1}] Allergy Information [{ DG1} ] Diagnosis Information 4 [{ GT1} ] Guarantor 1 [{ IN1} ] Insurance

MOSAIQ sends out patient demographic for the A04 event. The information sent includes: ♦ EVN – Event Information ♦ PID – Patient Demographics (name, address, phone, etc.) ♦ PV1 – Patient Visit Information (patient class, location, admit date/time, links to physicians, etc.) ♦ AL1 – Patient Allergy Information ♦ DG1 – Diagnosis Code ♦ GT1 – Guarantor (name, address, phone, employer information, etc.) ♦ IN1 – Links to patient’s insurance companies (name, policy number, contact, etc.)





Page 48

4.5.13 Syndromic Surveillance Export (OIM) The Syndromic Surveillance Export Interface exports Syndromic information from the MOSAIQ database to an external system (Public Health Agency), based on configuration specified in the database. The information is exported in HL7 format. Typically the information is exported as-is from the database.

4.5.13.1 Event Code A04 – Send a Syndromic Surveillance message based on a ‘Working’ diagnosis

Event Code A04: An A04 event signals a ‘Working’ diagnosis for Syndromic Surveillance patient problem. It signals that the associated diagnosis is preliminary.. See 2.1 (Product Description) to determine which interface product supports this event.


MSH Message Header None EVN Event Type PID Patient Identification PV1 Patient Visit { DG1} Diagnosis Information – Status F OBX Observation / Result Segment 3

The A04 message is exported by the OIM Syndromic Surveillance Export interface. The information to be exported includes:

♦ EVN - Facility ♦ PID – Patient Demographics (no name – anonymous, sex, race code, ethnicity code) ♦ PV1 – Visit number, visit date and time ♦ OBX – Facility ♦ OBX – Age ♦ OBX – Chief Complaint – If Chief Complaint is not available for the patient, this segment is not present. ♦ DG1 – Diagnosis Code (description optional), Codeset (e.g I9CDX), Diagnosis Status (Final) See the mapping for each HL7 segment for more details.

4.5.13.2 Event Code A03 – Send a Syndromic Surveillance message based on a ‘Final’ diagnosis

Event Code A03: An A03 event signals a ‘Final’ diagnosis for Syndromic Surveillance patient problem. It signals that the associated diagnosis has been finalized. See 2.1 (Product Description) to determine which interface product supports this event.


MSH Message Header None EVN Event Type PID Patient Identification PV1 Patient Visit { DG1} Diagnosis Information – Status F 4 OBX Observation / Result Segment

The A03 message is exported by the OIM Syndromic Surveillance Export interface. The information to be exported includes:

♦ EVN - Facility ♦ PID – Patient Demographics (no name – anonymous, sex, race code, ethnicity code)




Page 49

♦ PV1 – Visit number, visit date and time ♦ OBX – Facility ♦ OBX – Age ♦ OBX – Chief Complaint – If the Chief Complaint is not available for the patient, this segment is left out. ♦ DG1 – Diagnosis Code (description optional), Codeset (e.g I9CDX), Diagnosis Status (Final) See the mapping for each HL7 segment for more details.




Page 50

4.5.14 Schedule Messages (Outbound) The Schedule Transaction Set provides for transmitting new or updated information about appointments to external systems. Schedule information is entered into MOSAIQ and sent, unsolicited, to an external system.

Each triggering event supported by the OIM:Schedule product is listed below, along with the applicable form of the message exchange.

4.5.14.1 Event Code: S12 – Notification of new appointment booking

A filler application sends this message to notify other applications when a new appointment is booked. The information provided in the SCH segment and the other detail segments as appropriate describes the appointment booked by the filler application. See 2.1 (Product Description) to determine which interface product supports this event.

SIU^S12, S13,S14, S15,S26

ADT Message Rep# ACK^A01 General Acknowledgment

MSH Message Header MSH Message Header SCH Appointment Activity Information MSA Message Acknowledgment [{NTE}] Notes and Comments [ ERR ] Error PID Patient Identification [PV1] Patient Visit {RGS Resource Group Segment [{AIS}] Appointment Information –

Service

[{AIL}] Appointment Information – Location Resource

[{AIP}] Appointment Information – Personnel Resource

}


4.5.14.2 Event Code: S13 – Notification of appointment rescheduling

A filler application sends this message to notify other applications when an existing appointment is rescheduled. The information in the SCH segment and the other detail segments as appropriate describe the new date(s) and time(s) to which the previously booked appointment is changed. Additionally, it describes the unchanged information in the previously booked appointment.

The message structure is the same as that for Event Code S12. See Section 4.5.14.1.

4.5.14.3 Event Code: S14 – Notification of appointment modification

This message notifies other applications when the filler application modifies an existing appointment. This trigger event should only be used for incomplete appointments, or parent appointments with incomplete child appointments.


4.5.14.4 Event Code: S15 – Notification of appointment cancellation

A filler application sends a notice of cancellation to other applications when an existing appointment is canceled. A cancel event stops a valid appointment from taking place. For example, if a patient cancels a scheduled exam, then the filler application cancels the appointment.





Page 51

4.5.14.5 Event Code: S26 – Notification that patient did not show up for appointment

Event S26 is a notification that a patient did not show up for an appointment. For example, when a patient does not arrive for a scheduled a clinic visit, this trigger event can set a status on the appointment record for statistical purposes, as well as free resources assigned to the appointment (or any other application level actions that must take place in the event a patient does not appear for an appointment).

4.5.15 Schedule Messages (Inbound) The Schedule Transaction Set provides for transmitting new or updated appointments from external systems. Schedule information is entered into an external system and received, unsolicited into MOSAIQ.

Each triggering event supported by the ESI_IN:SCH product is listed below, along with the applicable form of the message exchange.

4.5.15.1 Event Code: S12 – Notification of new appointment booking

A filler application sends this message to notify other applications when a new appointment is booked. The information provided in the SCH segment and the other detail segments as appropriate describes the appointment booked by the filler application. See 2.1 (Product Description) to determine which interface product supports this event.

SIU^S12, S13,S14, S15,S17, S26

ADT Message Rep# ACK^A01 General Acknowledgment

MSH Message Header MSH Message Header SCH Appointment Activity Information MSA Message Acknowledgment [{NTE}] Notes and Comments [ ERR ] Error PID Patient Identification [PV1] Patient Visit {RGS Resource Group Segment [{AIS}] Appointment Information –

Service 1

[{AIL}] Appointment Information – Location Resource

1

[{AIP}] Appointment Information – Personnel Resource

0-Many

}


4.5.15.2 Event Code: S13 – Notification of appointment rescheduling

A filler application sends this message to notify other applications when an existing appointment is rescheduled. The information in the SCH segment and the other detail segments as appropriate describe the new date(s) and time(s) to which the previously booked appointment is changed. Additionally, it describes the unchanged information in the previously booked appointment.


4.5.15.3 Event Code: S14 – Notification of appointment modification

This message notifies other applications when the filler application modifies an existing appointment. This trigger event should only be used for incomplete appointments, or parent appointments with incomplete child appointments.





Page 52

4.5.15.4 Event Code: S15 – Notification of appointment cancellation

A filler application sends a notice of cancellation to other applications when an existing appointment is canceled. A cancel event stops a valid appointment from taking place. For example, if a patient cancels a scheduled exam, then the filler application cancels the appointment.


4.5.15.5 Event Code: S17 – Notification of appointment deletion

A user deletes an existing appointment(s) in the centralized scheduling system. The scheduling system sends delete (HL7 SIU S17) message to MOSAIQ and it is accepted and displayed in MOSAIQ schedule. A filler application sends a notice of deletion to other applications when an existing appointment is deleted. A delete event removes an existing appointment. For example, a notification of appointment deletion is sent by the filler application to other applications when an appointment that had been entered in error has been removed from the system.


4.5.15.6 Event Code: S26 – Notification that patient did not show up for appointment

Event S26 is a notification that a patient did not show up for an appointment. For example, when a patient does not arrive for a scheduled clinic visit, this trigger event can set a status on the appointment record for statistical purposes, as well as free resources assigned to the appointment (or any other application level actions that must take place in the event a patient does not appear for an appointment).





Page 53

4.5.16 Vaccine (VXU) Messages The Vaccine Transaction Set provides for transmitting new or updated vaccination information about patients. Each triggering event supported by the ESI:Immunization Export product is listed below, along with the applicable form of the message exchange.

4.5.16.1 Event Code: V04 - Vaccine: Unsolicited Update to Vaccination Record


VXU^V04 BAR Message Rep#

MSH Message Header PID Patient Identification [PD1] Privacy, reminder, active

patient status

[{NK1}] Next of Kin Segment 0-N { 1-N ORC Common OrderSegment RXA Pharmacy Administration Segment [RXR] Pharmacy/Treatment Route Segment [{OBX}] Observation / Result Segment 0-N }

The V04 message is exported by the OIM Immunization Export interface. Immunization verifications on patients in MOSAIQ shall trigger an Immunization History to be sent and export the V04 message. The information to be exported includes:

♦ PID – Patient Demographics (name, address, phone, … etc.) ♦ PD1 – Privacy, reminder, active patient status ♦ NK1 – Guardian or responsible person ♦ ORC – Ordering information if available ♦ RXA – Medication information ♦ RXR – Administration site and route ♦ OBX – Vaccine for Children (VFC) information ♦ OBX – Vaccine Information Statement (VIS) - Vaccine Type ♦ OBX – VIS – Publish date ♦ OBX – VIS – Presentation date ♦ OBX – Presumed Immunity


MOSAIQ 2.60 ESI Requirements Specification User Configurable Switches



Page 54

5. User Configurable Switches Some data fields exist that are site specific and must be coordinated between Elekta and the parties responsible for maintaining the external systems. All coordination between MOSAIQ ESI and an external system will occur through use of the data table scheme. Site-specific tables must be defined for items such as patient class, physician IDs, Insurance Company IDs, etc. (i.e., all data types CN and ID). Site-defined tables are noted as such in Appendix A on page 68. Detailed descriptions of the various configuration items may be found in the MOSAIQ user manuals.

5.1 Configurable Options The following import and export options within MOSAIQ ESI are configurable.

5.1.1 Import Options ♦ Null Character Value. ♦ HL7 Production Value. ♦ Receiving Application Name. ♦ Receiving Facility Name.

♦ Send Acknowledgment.1 (TRUE/FALSE).

♦ MOSAIQ to HL7 Patient ID mapping.2 You can configure data items coordinated through the HL7 data tables to be accepted with or without validation on a per table basis on imports. The segment terminator (last character of every segment) defaults to ASCII CR (Hex 0D) in ESI. The segment terminator is end-user configurable.. If DOS ASCII files are used for message exchange, ASCII CR LF (Hex 0D 0A) is recommended to maintain compatibility with standard text editors.

5.1.1.1 Query Configuration

Future versions of ESI will be configurable as to whether the HIS is screening messages for destination or the query and send scheme is being used. This item will not be supported until MOSAIQ patient registration supports query initiation; however, the current version of ESI does respond to query acknowledgments.

5.1.1.2 Admit, Update and Secondary Search Configuration

MOSAIQ ESI is configurable as to whether the following features are enabled: ♦ Admit transactions are treated as updates if they are received when a matching record is already in the

system. This applies to add of patients, insurance companies and physicians. ♦ Update transactions are treated as admits if received prior to an admit occurring. This applies to updating

patients, insurance companies and physicians. ♦ Search for a patient with matching last name and social security number if a failure to match using Internal

ID occurs for admit, update, register, or add/update patient accounts messages occurs.

1 The Send Acknowledgement flag is used to determine whether the external system is expecting a general acknowledgment (ACK) message. ACKs are routinely written to the transaction log file.

2 The MOSAIQ to HL7 Patient ID mapping includes assignment of MOSAIQ IDs to HL7 IDs (Example: MOSAIQ Pat_IDA is almost always assigned to HL7 Internal ID for use as a coordinating medical record number), check digit scheme configuration and whether the mapping extends to inpatients, outpatients or both for a particular ID.




Page 55

5.1.1.3 Process Delete Patient Messages

If checked, the Delete Patient (event code A23) messages are processed to attempt to delete patient records.

5.1.1.4 Charge Inbound Configuration

MOSAIQ ESI provides the additional configuration options specific to the processing of P03 (Post Financial Transactions) inbound messages.

♦ Add Patient: If set, patient demographics are added to the database if the patient does not already exist. Patient will be added according to the processing rules for an A01 (Admit a Patient) event code.

♦ Update Patient: If set, existing patients are updated in the database according to the processing rules for an A08 (Update Patient Information) event code.

If either of the above options is set, the IN1 segments included in the message are analyzed. If an ESI coordinating ID exists for the IN1 record, a relationship is established between the patient and the payer. If an ESI coordinating ID does not exist for the IN1 record, a new payer record is created, an ESI_ID is created with the value from IN1-2, and a relationship is established between the patient and the payer.

5.1.1.5 ADT Inbound Configuration

The “ADT Inbound” tab is visible when the Interface Type is set to ADT Inbound. When “Use Department Mapping” is checked, ADT messages are evaluated to determine if the patient location in PV1-3 matches a department entry in the ESI Mapping table. If a department match is found, the patient ADT data is updated to assign that department as the patient home department. If there is no department match, the ADT update message can be configured to be discarded, to be assigned to a default department, or to be updated to the system as an unregistered patient.

If the “Discard Unknown” checkbox is checked, the non-matching transactions are discarded and not updated to the database.

If “Use Department Mapping” is checked and “Discard Unknown” is not checked, the “Department Mapping Settings” group box is enabled on the ADT Inbound tab. Two mutually exclusive settings are provided: “Assign Default Department” and “Unregistered Patient”. The following special processing based on these settings will occur when an HL7 message being processed fails on department mapping:

• Assign Default Department - Default for new interfaces

When set the Department identified in the “Department” dropdown will be used as the home department for the non-department-mapped HL7 message being processed.

• Unregistered Patient

When “Unregistered Patient” is set this non-department-mapped message will be processed differently based on whether this message is for an existing patient in MOSAIQ.

o New Patient: 1. The patient data will be updated and the patient clinical status will be set to Unregistered.

o Existing Patient with a Patient Status = Unregistered:

1. The patient data are updated to the unregistered patient and the clinical status remains unchanged.




Page 56

o Existing Registered Patient: 1. The patient data not specific to a department will be updated but patient IDs IDA – IDF will not

be updated.> 2. No PV1 data will be processed. 3. No DG1 data will be processed.

5.1.1.6 Charge Outbound Configuration

MOSAIQ ESI provides additional configuration options specific to processing outbound P03 (Post Financial Transactions) messages.

♦ Within the “Billing” tab in DEPARTMENT SETUP, there is a setting entitled “Require Charges to be reviewed before Exporting”. When this checkbox is checked, only those charges that are reviewed can be exported.

5.1.2 Export Options ♦ Null Character Value. ♦ HL7 Version. ♦ HL7 Production Value. ♦ HL7 Encoding Characters. ♦ Receiving Application Name. ♦ Receiving Facility Name. ♦ Sending Application Name. ♦ Sending Facility Name.

♦ MOSAIQ to HL7 Patient ID mapping.2

♦ Use Department Code, Cost Center Code or Department Abbreviation3 (FT1 Segment DEPARTMENT CODE).

♦ Use Hospital Charge Code or CPT Code4 (FT1 Segment TRANSACTION CODE). ♦ Use Batch Headers/Footers (TRUE/FALSE). ♦ Use File Headers/Footers (TRUE/FALSE). ♦ Export Credits (TRUE/FALSE). ♦ Use PV1, Use DG1, Use GT1, Use IN1, Use OBX (TRUE/FALSE)

HL7 Data items exported through ESI are configurable as unused or required. If a data item is required and not present, the export will not occur. If a data item is unused, then regardless of whether it is present, it will not be included in the export.

ESI can maintain multiple export destination configurations and be coordinated for use with the MOSAIQ Billing Module to control rights to the export of technical and professional components of charges. Example 1: Hospital

2 The MOSAIQ to HL7 Patient ID mapping includes assigning MOSAIQ IDs to HL7 IDs (Example: MOSAIQ Pat_IDA is typically assigned to HL7 Internal ID for use as a coordinating medical record number), check digit scheme configuration and whether the particular ID mapping extends to inpatients, outpatients or both.

3 It is end-user configurable whether a department code, cost center code or department abbreviation appears in the FT1 segment DEPARTMENT CODE field.

4 It is end-user configurable whether a Charge’s Hospital Charge Code or CPT Code appears in the FT1 segment TRANSACTION CODE field.




Page 57

receives technical charges, MOSAIQ Billing Module receives professional charges. Example 2: Hospital receives technical charges, Professional Billing Service receives professional charges.

5.2 Halt Time/Duration ESI is configurable as to what time and duration the ESI program is not to run. This enables data backups to proceed during specified time periods. A message displays during the halt time stating that the program has been disabled.

MOSAIQ 2.60 ESI Requirements Specification User Configurable HL7 Message Translation (IIM)



Page 58

6. User Configurable HL7 Message Translation (IIM) Within HL7 messages the contents of some fields contain coded values. One example of this is Relationship, which is used in GT1-11 (Guarantor Relationship) and NK1-3 (Relationship). Both of these fields are defined in HL7 as datatype = CE (Coded Element). The HL7 specification provides recommendations for the codes to be used for many of these Coded Element fields, but these recommendations are not always followed. To properly represent these coded values in MOSAIQ, IIM (Inbound Interface Manager) provides interface-specific mapping files to assist in this translation. This section will describe the creation, content and editing of these files.

6.1 Creation of Mapping Tables A mapping table is created for the following interface types the first time the interface starts:

• ADT

• Schedule The mapping table is named MQ_MappingTable.XML and it is placed in the \Settings folder underneath the folder for the interface. Assuming IIM is installed in the default location and the interface name is “ADT1”, then the mapping table will be placed in the following location:

• C:\Program Files\IMPAC Applications\Inbound Interface\MQADT_ADT1\Settings\

NOTE: If an interface starts and is unable to find a mapping file, it will recreate it with default values extracted from the MOSAIQ database.




Page 59

6.2 Mapping Table Contents The default contents of the mapping table file is interface specific and contains information extracted from the MOSAIQ database. Although the content of the data in the file is interface specific, the schema the same. However, not all nodes are in use by all interfaces types as defined below.

6.2.1 Mapping Table Contents (ADT Interface) The default contents of the ADT mapping table comes from the ObsDef and Prompt tables. The following table provides the mapping between the XML Nodes, IIM Business Object properties and the MOSAIQ database.

XML Node IIM Business Object Property

HL7 Field Mapping (default) MOSAIQ DB Mapping

<Genders> Gender PID-8 (Sex) ObsDef records where Type = 6 and Tbl = 1

<PatClass> Patient Status Account Status*

PV1-2 (Patient Class)

ObsDef records where Type = 6 and Tbl = 4

<Races> Race PID-10 (Race) ObsDef records where Type = 6 and Tbl = 5

<Religions> Religion PID-17 (Religion) ObsDef records where Type = 6 and Tbl = 6

<Maritals> Marital Status PID-16 (Marital Status)


<Relationships> Relationship NK1-3 (Relationship) GT1-11 (Guarantor Relationship)


<ScheduleStatuses> N/A N/A N/A <ScheduleUserStatuses> N/A N/A N/A <AccountSts> N/A N/A N/A <DiagnosisTypeTexts DiagType DG1.3.3 or DG1.2 Prompt table

values where PGroup = ‘Diag’

<Languages> Language PID-15 (Primary Language)

Prompt table values where PGroup = ‘Lang’

<Ethnicity> Ethnicity PID-22 (Ethnicity) ObsDef records where Type = 6 and Tbl = 189

Each XML Node contains a pair of fields that are used to perform the mapping between the data from the HL7 message and the value to be used for processing into MOSAIQ. The <ScheduleStatuses> node uses <FillerStatusCode> and <ScheduleStatusID> to define the mapping. For all other XML Nodes, <Code> and <Value> define the mapping.




Page 60

As shown above, <PatClass> maps to both the Patient Status and Account Status business object properties.

• The mapping to Patient Status is very limited. Although multiple mappings may be present, we’re only interested in Inpatient and Outpatient because we’re ultimately using this mapping to set Admin.IsInpatient to True (Inpatient) or False (Outpatient). The table below shows the values we support:

Code Value MOSIAQ DB Mapping (Admin.IsInpatient)

I Inpatient 1 O Outpatient 0

<null> None 0 <other> None 0

• The mapping to Account Status supports a wider range of values. The table below shows the values we support:

Code Value MOSIAQ DB Mapping (Accounts.AccountStatus)

I Inpatient 1 O Outpatient 2 R Recurring patient 3 E Emergency 4 P Preadmit 5

<null> None 0 <other> None 0

6.2.2 Mapping Table Contents (Schedule Interface) The default contents of the Schedule mapping table are hard-coded in IIM (Inbound Interface Manager). The following table provides the mapping between the IIM Business Object properties and the MOSAIQ database.


HL7 Field Mapping (default)

MOSAIQ DB Mapping

<Genders> N/A N/A N/A

<PatClass> N/A N/A N/A

<Races> N/A N/A N/A

<Religions> N/A N/A N/A

<Maritals> N/A N/A N/A

<Relationships> N/A N/A N/A

<ScheduleStatuses> Schedules.

FillerStatusCode

SCH.25.1 (Filler Status Code – Identifier)

Schedule_SchedulStatus_MTM.ScheduleStatusID Schedule.SchStatus_Hist_SD




Page 61



MOSAIQ DB Mapping

<ScheduleUserStatuses>

Schedules.

FillerStatusCode

SCH.25.1 (Filler Status Code – Identifier)

Schedule_SchedulStatus_MTM.ScheduleStatusID Schedule.SchStatus_Hist_UD

<AccountSts> N/A N/A N/A

<Languages> N/A N/A N/A

The Schedule interface supports mapping from the Filler Status Code to a subset of MOSAIQ system-defined status values. The following table shows the default mapping:

HL7 Filler Status Code – Identifier (SCH.25.1)

MOSAIQ System Defined Status Short Description

ScheduleStatus.StatusShortDesc

<FillerStatusCode>

MOSAIQ System Defined Status ID

ScheduleStatus.ScheduleStatusID

<ScheduleStatusID>

<Null> Unresolved 1

Waitlist Unresolved 1

Booked Unresolved 1

Deleted Unresolved 1

Blocked Unresolved 1

Overbook Unresolved 1

Complete Unresolved 1

Dc Break 2

No Show No Show 3

Started New Start 8

Cancelled Cancelled 8

Non-Billable Complete NonBillCom 10

Ended Ended 31

B Break 2

N No Show 3

S New Start 5

X Cancelled 8

D NonBillCom 10

E Ended 31




Page 62

6.2.3 Mapping Table Contents (Radiotherapy Requisition Interface) The default contents of the Radiotherapy mapping table are hard-coded in IIM (Inbound Interface Manager). The following table provides the mapping between the IIM Business Object properties and the MOSAIQ database.



MOSAIQ DB Mapping

<Genders> N/A N/A N/A

<PatClass> N/A N/A N/A

<Races> N/A N/A N/A

<Religions> N/A N/A N/A

<Maritals> N/A N/A N/A

<Relationships> N/A N/A N/A

<ScheduleStatuses> N/A N/A N/A

<ScheduleUserStatuses>

N/A N/A N/A

<AccountSts> N/A N/A N/A

<DiagnosisTypeTexts>

DiagType DG1.3.3 or DG1.2 Prompt table values where PGroup = ‘Diag’

<Languages> N/A N/A N/A

<Ethnicitys> N/A N/A N/A




Page 63

6.2.4 Sample XML Mapping Files The following table shows partial contents from the XML mapping files for both the ADT and Schedule interfaces.

XML Nodes (ADT) XML Nodes (Schedule) <Genders> <Gender> <Code>F</Code> <Value>Female</Value> </Gender> </Genders> <PatClass> <PatClass> <Code>O</Code> <Value>Outpatient</Value> </PatClass> </PatClass> <Races> <Race> <Code>O</Code> <Value>Other</Value> </Race> </Races> <Religions> <Religion> <Code>U</Code> <Value>Unknown</Value> </Religion> </Religions> <Maritals> <Marital> <Code>S</Code> <Value>Single</Value> </Marital> </Maritals> <Relationships> <Relationship> <Code>M</Code> <Value>Mother</Value> </Relationship> </Relationships> <ScheduleStatuses /> <AccountSts /> <Languages> <Language> <Code>English</Code> <Value>English</Value> </Language> </Languages>

<Genders /> <PatClass /> <Races /> <Religions /> <Maritals /> <Relationships /> <ScheduleStatuses> <ScheduleStatus> <FillerStatusCode>Waitlist</FillerStatusCode> <ScheduleStatusID>1</ScheduleStatusID> </ScheduleStatus> <ScheduleStatus> <FillerStatusCode>Booked</FillerStatusCode> <ScheduleStatusID>1</ScheduleStatusID> </ScheduleStatus> <ScheduleStatus> <FillerStatusCode>Started</FillerStatusCode> <ScheduleStatusID>5</ScheduleStatusID> </ScheduleStatus> <ScheduleStatus> <FillerStatusCode>Complete</FillerStatusCode> <ScheduleStatusID>1</ScheduleStatusID> </ScheduleStatus> <ScheduleStatus> <FillerStatusCode>Cancelled</FillerStatusCode> <ScheduleStatusID>8</ScheduleStatusID> </ScheduleStatus> <FillerStatusCode>Deleted</FillerStatusCode> <ScheduleStatusID>1</ScheduleStatusID> </ScheduleStatus> <ScheduleStatus> <FillerStatusCode>Noshow</FillerStatusCode> <ScheduleStatusID>3</ScheduleStatusID> </ScheduleStatus> </ScheduleStatuses> <ScheduleUserStatuses> <ScheduleUserStatus> <Code>Urgent Vis</Code> <Value>25</Value> </ScheduleUserStatus> <ScheduleUserStatus> <Code>Vacation</Code> <Value>29</Value> </ScheduleUserStatus> <ScheduleUserStatus> <Code>Needs supp</Code> <Value>35</Value> </ScheduleUserStatus> </ScheduleUserStatuses> <AccountSts /> <Languages />




Page 64

6.3 Mapping Table Editing The mapping table files can be edited with a text editor such as Notepad. You can edit the files to insert, update and delete content. The following table shows examples of each:

Action Before After 1) Change <Code> for Female from “F” to “1”. 2) Change <Code> for Male from “M” to “2”.

<Genders> <Gender> <Code>F</Code> <Value>Female</Value> </Gender> <Gender> <Code>M</Code> <Value>Male</Value> </Gender> </Genders>

<Genders> <Gender> <Code>1</Code> <Value>Female</Value> </Gender> <Gender> <Code>2</Code> <Value>Male</Value> </Gender> </Genders>

Add new Code/Value pair for Other


<Genders> <Gender> <Code>F</Code> <Value>Female</Value> </Gender> <Gender> <Code>M</Code> <Value>Male</Value> </Gender> <Gender> <Code>O</Code> <Value>Other</Value> </Gender> </Genders>

Remove Code/Value pair for Other

<Genders> <Gender> <Code>F</Code> <Value>Female</Value> </Gender> <Gender> <Code>M</Code> <Value>Male</Value> </Gender> <Gender> <Code>O</Code> <Value>Other</Value> </Gender> </Genders>


MOSAIQ 2.60 ESI Requirements Specification Log Files



Page 65

7. Log Files 7.1 Transaction Log Files For each inbound interface, a file called <interfacename>.Lxx, in which “xx” is today’s date, is used to keep a record of all the transactions occurring within a 24-hour period. The log file contents can be filtered and viewed from the ESI Manager, Log File button. The log file contains details of the processing of inbound messages including:

• Message Content - The original message content received.

• Error Details – Details regarding any errors encountered while processing the message. The information is this section will vary based on the error, but enough information will be provided to enable the user to identify the type of error and the data associated with the error. The general format for the error data is to include a description of the error followed by the relevant data. NOTE: Additional information is written to the log file when errors are encountered importing lab results or charges. Any lab result or charge not imported will be documented in the log file. This will enable users to more easily identify and resolve these errors.

• Warning Details – Details regarding any warnings encountered while processing the message. The information is this section will vary based on the error, but enough information will be provided to allow the user to identify the type of warning and the data associated with the warning.

• Message Acknowledgment - The content of the HL7 acknowledgement message.

• Patient Information – Patient identification information from the HL7 message content. Transaction messages received and ignored or discarded will be listed in the transaction log file. MOSAIQ ESI keeps the thirty-one most recent transaction log files (one month's worth). The files are stored as <interfacename>.L1 through <interfacename>.L31. Following completion of a 31-day cycle, the <interfacename>.Lxx file is overwritten. The <interfacename>.Lxx files utilize the DOS environmental variable ESI to identify the directory.

7.2 TCP/IP Log Files For TCP/IP interfaces, two additional log files are created.

• CESI.LOG: Contains general information that applies to the TCP/IP communication protocol.

• <interfacename>.TCP: Contains more detailed information to help diagnosis error. The original message content is also included if the ‘Save Message Content’ is checked in the Interface definition.

MOSAIQ 2.60 ESI Requirements Specification Errors



Page 66

8. Errors 8.1 Error Handling MOSAIQ ESI does not allow transaction messages to be input into the MOSAIQ system in which it has detected errors. Duplicate transaction messages (ex: two admit messages for a patient) and messages for invalid patients (ex: transfer or purge a nonexistent patient) are not allowed. Physician and Insurance codes transmitted from external systems must match valid ID numbers in the MOSAIQ system. When errors occur, MOSAIQ ESI does not accept the transaction message as input. The error is recorded in the MOSAIQ ESI Transaction Log File. The MOSAIQ ESI has a list of Anomaly Codes (Returned in ERR Segment as fourth component of ERROR CODE AND LOCATION) that are used as rules when processing messages. The table below lists the anomaly code, whether the anomaly response is end-user configurable (error, warning, none) and the default values for each code. All error codes that are not end-user configurable are considered fatal error conditions.

ANOMALY CODE

DESCRIPTION

END-USER CONFIGURABLE

DEFAULT

01 Invalid Patient No Error 02 Invalid Physician Yes None 03 Invalid Insurance Yes None 04 Missing Required Data Field/Component Yes None 05 Invalid Data Repetition Yes None 06 Missing Required Data Segment No Error 07 Invalid Event Type Yes Error 08 Duplicate Message No Error 09 Invalid Data Field/Component Yes None 10 Invalid Data Field Length Yes None 11 Invalid Segment No None 12 File Error No Error 13 Application Error No Error 14 Invalid Time Stamp Yes None 15 Invalid Application Yes None 16 Invalid Facility Yes None 17 Unexpected Segment Yes None 30 Entry Not Found No Error 33 Record Not Available No Error 35 Record Not Found No Error 37 File Not Open No Error 40 Creates Duplicate key No Error 43 Record is Already Hold No Error

For end user configurable anomalies: ♦ “Error” stops processing when the error is encountered. However, some data may have already been

completely processed resulting in additions or updates to the database.

MOSAIQ 2.60 ESI Requirements Specification Errors



Page 67

♦ “Warn” warns the user that an error has occurred, but continues processing the message. ♦ “None” ignores the error when it occurs and continues processing the message.

8.2 Error Logging The <interfacename>.Lxx file is also used to keep a record of all the errors that occur between MOSAIQ ESI and the external system. The file contains all errors that occur within a 24-hour period. Errors are not logged for any ADT messages received which were ignored/discarded. Errors are only logged for those messages that resulted in an error when an attempt was made to process the data. Any ADT messages received and ignored/discarded will be listed in the transaction log file. For each Error, the ERR segment appears as part of the ACK message. Note that the ERR segment is an optional segment in the ACK messages. The ACK message Acknowledgment segment should have the MSA ACKNOWLEDGMENT CODE equal to either AR (Application Reject) or AE (Application Error) whenever an ERR segment is present.

MOSAIQ 2.60 ESI Requirements Specification Appendix A. Tables



Page 68

9. Appendix A. Tables The table ID number references column six (TABLE) from the HL7 segment definitions in this document. The tables represent data which may be standardized across institutions, but for which no applicable official standard exists. For these a set of suggested values is listed below. See section 4.4, Tables on page 21 for detailed information concerning the use of HL7 data tables. For more information on maintaining these tables refer to the ESI Data Mapping Guide. 1 Indicates that this version of MOSAIQ ESI does not support the use of this table. 2 Indicates that this table is user defined. Listed table values are examples only.

The tables detailed in this appendix do not include the entire set of HL7 defined tables.

TABLE ID: 0001 SEX2

VALUE DESCRIPTION

F Female M Male O Other U Unknown

TABLE ID: 0002 MARITAL STATUS2

VALUE DESCRIPTION

A Separated D Divorced M Married S Single

W Widowed




Page 69

TABLE ID: 0003 EVENT TYPE CODE

VALUE DESCRIPTION

A01 Admit a patient A02 Transfer a patient A03 Discharge a patient A04 Register a patient A05 Pre-Admit a Patient A06 Transfer outpatient to inpatient A07 Transfer inpatient to outpatient A08 Update patient information A17 Swap a Patient A18 Merge patient information A19 Patient Query A23 Delete a Patient A28 Add Person or Patient Information A30 Merge Person Information A31 Update Person Information A34 Merge Patient Information - Patient ID Only A35 Merge Patient Information - Account Number Only A36 Merge Patient Information - Patient ID and Account Number A40 Merge Patient – Patient Identifier List P01 Add/Update patient account P02 Purge patient account P03 Post detail financial transaction Z01 Local Physician Add/Update/Delete Z02 Local Insurance Add/Update/Delete R01 Unsolicited Transmission of an observation message R02 Query for Results of Observation R03 Query for Results of Observation

TABLE ID: 0004 PATIENT CLASS2

VALUE DESCRIPTION

I Inpatient O Outpatient

For mapping within MOSAIQ, the “Label” field must be “In” for Inpatient and “Out” for Outpatient.




Page 70

TABLE ID: 0005 ETHNIC GROUP2 VALUE DESCRIPTION

A Asian B Black C Caucasian H Hispanic N Native American O Other P Pacific Islander U Unknown

TABLE ID: 0006 RELIGION2

VALUE DESCRIPTION

A Atheist B Baptist C Catholic N Christian Scientist E Episcopalian H Hindu J Jewish D LDS (Mormon) L Lutheran M Methodist S Moslem O Other P Protestant U Unknown Z Nazarene

TABLE ID: 0007 ADMISSION TYPE1 TABLE ID: 0008 ACKNOWLEDGMENT CODE

VALUE DESCRIPTION

AA Application Accept AE Application Error AR Application Reject

TABLE ID: 0009 AMBULATORY STATUS1




Page 71

TABLE ID: 0010 PHYSICIAN ID MOSAIQ ESI substitutes this table for physician IDs that are entered elsewhere in the MOSAIQ system for ATTENDING, ADMITTING, REFERRING and CONSULTING DOCTORS.

TABLE ID: 0018 PATIENT TYPE1

TABLE ID: 0019 ANESTHESIA CODE1

TABLE ID: 0021 BAD DEBT AGENCY CODE1

TABLE ID: 0022 BILLING STATUS1

TABLE ID: 0023 ADMIT SOURCE1

TABLE ID: 0032 CHARGE / PRICE INDICATOR.1

TABLE ID: 0042 COMPANY PLAN CODE1 TABLE ID: 0044 CONTRACT CODE

TABLE ID: 0045 COURTESY CODE1

TABLE ID: 0046 CREDIT RATING1

TABLE ID: 0048 WHAT SUBJECT FILTER1

TABLE ID: 0051 DIAGNOSIS CODE2

TABLE ID: 0052 DIAGNOSIS TYPE2 TABLE ID: 0053 DIAGNOSIS CODING METHOD

VALUE DESCRIPTION

I9 ICD9 I10 ICD10 I3 ICDO3 O Others

TABLE ID: 0055 DRG CODE1

TABLE ID: 0056 DRG GROUPER REVIEW CODE1

TABLE ID: 0059 CONSENT CODE1

TABLE ID: 0061 CHECK DIGIT SCHEME1 TABLE ID: 0062 EVENT REASON

VALUE DESCRIPTION

01 Patient Request 02 Physician Order 03 Census Management




Page 72

TABLE ID: 0063 RELATIONSHIP2 This table is used by Next of Kin Relationship, Insured's Relation to Patient, and Guarantor Relationship.

VALUE DESCRIPTION

BR Brother DA Daughter FA Father MO Mother OT Other SE Self SI Sister SN Son SP Spouse

HU Husband WI Wife CH Child IN In-law FR Friend

TABLE ID: 0064 FINANCIAL CLASS1

TABLE ID: 0066 EMPLOYMENT STATUS1

TABLE ID: 0068 GUARANTOR TYPE1

TABLE ID: 0069 HOSPITAL SERVICE1 TABLE ID: 0072 INSURANCE PLAN ID MOSAIQ ESI substitutes this table for insurance plan IDs, which are entered elsewhere in the MOSAIQ system.

TABLE ID: 0073 INTEREST RATE CODE1 TABLE ID: 0076 MESSAGE TYPE

VALUE DESCRIPTION

ACK General acknowledgment message ADT ADT message BAR Add/Change billing account DFT Detail financial transaction ORF Query for results of observation QRY Query, original mode

TABLE ID: 0079 LOCATION2

TABLE ID: 0083 OUTLIER TYPE1

TABLE ID: 0086 INS. PLAN TYPE1

TABLE ID: 0087 PRE-ADMIT TESTING1




Page 73

TABLE ID: 0088 PROCEDURE CODE2

TABLE ID: 0089 PROCEDURE CODING METHOD2

TABLE ID: 0090 PROCEDURE TYPE2

TABLE ID: 0091 QUERY PRIORITY1

TABLE ID: 0092 RE-ADMISSION INDICATOR2

TABLE ID: 0099 VIP INDICATOR1

TABLE ID: 0102 DELAYED ACKNOWLEDGMENT TYPE2 TABLE ID: 0103 PROCESSING ID

VALUE DESCRIPTION

D Debugging P Production T Training

TABLE ID: 0104 VERSION CONTROL TABLE1 TABLE ID: 0106 QUERY FORMAT CODE

VALUE DESCRIPTION

R Response in record-oriented format

TABLE ID: 0107 DEFERRED RESPONSE TYPE1

TABLE ID: 0108 QUERY RESULTS LEVEL1

TABLE ID: 0110 TRANSFER TO BAD DEBT CODE1

TABLE ID: 0111 DELETE ACCOUNT CODE1

TABLE ID: 0112 DISCHARGED TO DISPOSITION1

TABLE ID: 0113 DISCHARGED TO LOCATION1

TABLE ID: 0114 DIET TYPE1

TABLE ID: 0115 SERVICING FACILITY1

TABLE ID: 0116 BED STATUS1 TABLE ID: 0117 ACCOUNT STATUS

TABLE ID: 0118 MAJOR DIAGNOSTIC CATEGORY1

TABLE ID: 0126 QUANTITY LIMITED REQUEST1

MOSAIQ 2.60 ESI Requirements Specification Appendix B. Examples



Page 74

10. Appendix B. Examples 10.1 HL7 (variable position, variable length) examples 10.1.1 Admit a Patient - Trigger Event A01:

All patient-related information is fictitious.

MSH|^~\&|STAN||RADONC||200201251123||ADT|MSG00001|P|2.3|<cr>

EVN|A01|199410251123||<cr>

PID|||PATID1234^5^M11||PATIENT^SAMPLEÂ^JR^MR.||19310615|M||C|

1066 N YOUR STREET^HOMETOWN^CA^99999-1234|SC|(555)555-5555|

(555)555-5555CX555||M||PATID12345001|5174389|

999999^CA|<cr>

NK1|PATIENTÔTHER^K|WIFE|<cr>

PV1|1|I|^100Â||||004xyz^JONES^SIDNEY^J.|||RAD||||ADM|A0|<cr>

Patient Mr. Sample A. Patient Jr. was admitted on January 25, 2002 at 11:23AM by Doctor Sidney J. Jones (#004xyz) at Radiation Oncology (RAD), he was assigned to room 100, bed A. The message was sent from system STAN to system RADONC on the same date as the admission but took place three minutes after the admit.

MOSAIQ 2.60 ESI Requirements Specification Appendix B. Examples



Page 75

10.1.2 Add and Update Patient Accounts - Trigger Event P01:

MSH|^~\&|RADONC||PATB||||BAR|MSG00010|P|2.3|<cr>

EVN|P01|200201250800<cr>

PID|||125976|PUBLIC^JOHN^Q||19471007|M||C|

8339 WAGON RD^ANYWHERE^CA^91111^""|SC|

(555)555-5555|||||125976011<cr>

DG1|001|I9|155.0|MAL NEO LIVER, PRIMARY|20020125|DG<cr>

GT1|001|PUBLIC^JOHN^Q|8339 WAGON RD^ ANYWHERE ^CA^91111^""|

||||||123454321<cr>

NK1|1|PUBLIC^WILLIAM^F|FATHER|522 MAIN ST^NOWHERE^ID^84321^""|

(208)746-1283<CR>

IN1|1|PRU001|A357|BCCA|||||132987<cr>

A patient is registered and notification is sent to the Patient Billing system (PATB). The patient's name is John Q. Public, a Male Caucasian, born on October 7, 1947, living at 8839 Wagon Rd, Anywhere, CA. Mr. Public's patient number is 125976 and his billing number is 125976011. Mr. Public has provided his father's name and address as next of kin. Mr. Public is insured under plan ID A357 with an insurance company known to both systems as BCCA. The coordinating Plan ID for the insurance company is PRU001. The Diagnosis segment contains the admitting diagnosis information that the patient was diagnosed on January 25, as having a malignancy of the Hepatobiliary System or Pancreas (ICD9 code 155.0).

MOSAIQ 2.60 ESI Requirements Specification Appendix C. HL7 to MOSAIQ Data Item Cross Reference



Page 76

11. Appendix C. HL7 to MOSAIQ Data Item Cross Reference 11.1 Purpose This appendix contains technical information pertaining to the External System Interface (ESI). The information compiled here was obtained from the HL7 technical reference as well as the Elekta Database. Only information pertinent to the mapping of data items between MOSAIQ and HL7 is contained in this appendix.

11.2 Conventions

SEQ Sequence number.

LEN Length.

TYPE HL7 Data Type (See the ESI Interface Requirements or HL7 Standard for elaboration).

R/O Required/Optional.

REP Data Item May Repeat.

TBL HL7 Table Number.

NAME HL7 data item name.

An Asterisk (*) appears next to HL7 data items and tables that are not currently used. If an HL7 data item is unused, it is implied that the associated table is also unused. “Mappable” describes a configurable HL7 to MOSAIQ data items assignment. For example, HL7 Patient ID - External can be assigned to PAT: PAT_IDB through PAT: PAT_IDF. HL7 to MOSAIQ data item relationships are generally more complex than they appear here. For example, a physician ID called ADM:ATTENDING_MD_ID maps to the HL7 attending physician ID, data type XCN. In order for the data to be filled in per HL7 standards, the ADM:ATTENDING_MD_ID value is used to find a matching record in STAFF using STF:STAFF_ID as a key. Once that value is found, a matching record in EXT_ID must be found using EID:Staff_ID as a key. The physician's name (STF:LAST_NAME, STF:FIRST_NAME) can then be attached to their coordinating external ID, EID:ID_Code and placed into an HL7 segment. Given these complex relationships, this document shall remain a resource for development only.




Page 77

11.3 AIL – Appointment Information – Location Resource The AIL segment contains information about location resources (meeting rooms, operating rooms, examination rooms, or other locations) that can be appointed. Resources included in a transaction using this segment are assumed to be controlled by an appointment on an appointment filler application.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME

MOSAIQ DB Mapping (Inbound)

MOSAIQ DB Mapping (Outbound)

MOSAIQ Application Mapping

1 4 SI R Set ID – AIL Constant value: 1 NA 2 1 ID C 020

6 Segment Action Code*

3 80 PL C Location Resource ID location ID: EID:Code where Ext_Type = ‘ESI’ for the location: SCH:Location and SCH:Inst_Id

location name:

SCH:Location ->Staff_ID->Staff:Last_Name Format: location ID^location name

location ID: EID:Code where Ext_Type = ‘ESI’ (Configurable) for the location: SCH:Location and SCH:Inst_Id

location name:

SCH:Location ->Staff_ID->Staff:Last_Name Format: location ID^location name * ID Mapping in OIM

Daily Master Schedule | Select Add | Appointment Slip | Location File | Directories | Location directory…| (Click Add) | Name File | Directories | Location Directory | (Highlight Location & Select Change) | Location Form | Select Edit IDs | Identification with Type = ESI and Department matching appointments’s department

4 200 CE R Location Type-Identifier-AIL

Queue location ID: EID:Code where Ext_Type = ‘ESI’ for the Queue location: Queue:Location and SCH:Inst_Id

Daily Master Schedule | Select Add | Appointment Slip | Queue|Location File | Directories | Location directory…| (Click Add) |




Page 78

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




Queue location name:

Queue:Location ->Staff_ID->Staff:Last_Name Format: location ID^location name

Name File | Directories | Location Directory | (Highlight Location & Select Change) | Location Form | Select Edit IDs | Identification with Type = ESI and Department matching appointments’s department

5 200 CE O Location Group*

6 26 TS C Start Date/Time Start time:

SCH.App_DtTm.

End time: Derived from start time plus duration

Format: ^^^200401091300^200401091330^^^^

Start time:

SCH.App_DtTm.

End time: Derived from start time plus duration

Format: ^^^200401091300^200401091330^^^^

Daily Master Schedule |( Select Add) | Appointment Slip | Date, Time and Duration

7 20 NM C Start Date/Time Offset*

8 200 CE C Start Date/Time Offset Units*

9 20 NM O Duration SCH:Duration_time in minutes

SCH:Duration_time in minutes

Daily Master Schedule | Select Add | Appointment Slip | Duration

10 200 CE O Duration Units M (for minutes)

M (for minutes)

NA

11 10 IS C 0279

Allow Substitution Code*




Page 79

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




12 200 CE C(R)

0278

Filler Status Code See field notes for SCH-25 (Inbound).

Constant value: Booked, Cancelled, Started, Complete, or No Show. See Field Notes.

NA – derived from user actions.

AIL Field Notes ID Mapping in OIM: When exporting information about a Staff or External Physician, Facility, Location or Payer, you can choose the “ID Type” to be exported. This can be configured within the “Mapping & Segments” tab in the INTERFACE PROPERTIES form.

12. Filler Status Code - See Field Notes for SCH-25




Page 80

12.1 AIP – Appointment Information – Personnel Resource The AIP segment contains information about the personnel types that can be scheduled. Personnel included in a transaction using this segment are assumed to be controlled by a schedule on a schedule filler application. Personnel not controlled by a schedule are not identified on a schedule request using this segment. The kinds of personnel described on this segment include any healthcare provider in the institution controlled by a schedule (for example: technicians, physicians, or nurses).

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 4 SI R Set ID - AIP 1 NA

2 3 ID C 0206

Segment Action code*

3

80 XCN C Y Personnel Resource ID ESI ID: EID:Code where Ext_Type = ‘ESI’ Based on SCH:Staff_Id and SCH:Inst_ID Staff Name: SCH:Staff_Id->STF:Last_Name, STF:First_Name, STF:Mdl_Initial Format: ESI ID^Lastname^Firstname^MiddleInitial

ESI ID: EID:Code where Ext_Type = ‘ESI’ (Configurable) Based on SCH:Staff_Id and SCH:Inst_ID Staff Name: SCH:Staff_Id->STF:Last_Name, STF:First_Name, STF:Mdl_Initial Format: ESI ID^Lastname^Firstname^MiddleInitial * ID Mapping in OIM

Daily Master Schedule | (Select Add) | Appointment Slip | Staff File | Directories | Staff Directory | (Highlight Staff & Select Change) | Staff Form | Select Edit IDs | Identification with Type = ESI and Department matching appointment’s department Name of Staff on the appointment

4 200 CE R Resource Role N/A SCH:Staff_ID-> STF:Type Format: ^Cardiologist

Daily Master Schedule | (Select Add) | Appointment Slip | Staff File | Directories | Staff




Page 81

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




Directory | (Highlight Staff & Select Change) | Staff Form | Type

5 200 CE O Resource Group*

6 26 TS C Start Date/Time SCH.App_DtTm. SCH.App_DtTm. Daily Master Schedule | (Select Add) | Appointment Slip | Date


8 200 CE C (R)

Start Date/Time Offset Units*





M (for minutes)

NA

11 10 IS C 0279

Allow Substitution Code*

12 200 CE C (R)

0278

Filler Status Code See field notes for SCH-25 (Inbound).



AIP Field Notes ID Mapping in OIM: When you export information about a Staff or External Physician, Facility, Location or Payer, you can select the “ID Type” to export. You can configure this within the “Mapping & Segments” tab in the INTERFACE PROPERTIES form.

12. Filler Status Code – See Field Notes for SCH-25




Page 82

12.2 AIS – Appointment Information - Service The AIS segment contains information about various kinds of services that can be scheduled. Services included in a transaction using this segment are assumed to be controlled by a schedule on a schedule filler application. Services not controlled by a schedule are not identified on a schedule request using this segment.

• SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 4 SI R Set ID – AIS 1 NA

2 3 ID C 0206 Segment Action Code*

3 250 CE R Universal Service Identifier SCH:Activity (a Hospital Code) See field Notes for SCH-7

SCH:Activity (a Hospital Code)

Daily Master Schedule | Appointment Slip | Activity

4 26 TS C Start Date/Time SCH.App_DtTm Format: 200401091300

SCH.App_DtTm Format: 200401091300

Daily Master Schedule | (Select Add) | Appointment Slip | Date, Time


6 250 CE C Start Date/Time Offset Units*





M (for minutes)

NA

9 10 IS C 0279 Allow Substitution Code*

10 250 CE C 0278 Filler Status Code See field notes for SCH-25 (Inbound).



11 250 CE O Y 0411 Placer Supplemental Service Information*




Page 83

• SEQ

LEN

TYPE

R/O

REP

TBL

NAME




12 250 CE O Y 0411 Filler Supplemental Service Information*

AIS Field Notes

10. Filler Status Code - See Field Notes for SCH-25




Page 84

12.3 AL1 – Patient Allergy Information Segment The AL1 segment contains patient allergy information of various types. Each AL1 segment describes a single patient allergy. On export, we only export Medication allergies.




Page 85

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 4 SI R Set ID - AL1 1 2 250 CE O 0127 Allergen Type

Code alg:AllergyType AG, FA, DA, MC, NKDA

alg:AllergyType->ProgID ->obd:Code odb:Code ->obd:Label Format: DA^Drug Allergy

eCHART | Allergies and Alerts Field - Type

3 250 CE R Allergen Code/Mnemonic/Description

alg:AllergyDesc Code: alg:drg_id-> drg:drug_code or drg: drug_code2 or drg: drug_code 3 or drg:medid or drg: gcnseqno Description: alg:drg_id-> drg:generic_name Format: code^description

eChart | Allergies and Alerts Field – Medication To configure mapping in OIM: Interface Properties | Mapping & Segments tab | Allergen Code (AL1-3)

4 250 CE O 0128 Allergy Severity Code

rxn:Severity

SV, MI, MO rxn:Severity Format: SV^Severe

eCHART | Allergies and Alerts Field - Severity

5 15 ST O Y 10063

Allergy Reaction Code

rxn:Reaction_OBD_ID

rxn:Reaction_OBD_ID

eCHART | Allergies and Alerts Field - Reaction

6 8 DT B Identification Date

alg:ID_Partial_DtTm

alg:ID_Partial_DtTm eCHART | Allergies and Alerts | Change




Page 86

AL1 Field Notes * This field is not used by MOSAIQ ESI 2. “Allergen Type Code”: The value is mapped using Table 0127 (Allergy Type) in ObsDef. The key column in ObsDef is Prog_ID, not OBD_ID. On

import we only accept “DA” (Drug Allergy). For any other value, we will not process the AL1 segment. 4. “Allergy Severity Code”: The value is mapped using Table 0128 (Allergy Severity) in ObsDef. On import we do not use Table 0128 and will only accept “MI” (Mild), “MO” (Moderate) and “SV” (Severe). We will ignore all other values, but will still

process the AL1 segment. Each Allergy Reaction code processed associated with the single severity that is processed from this Allergy Severity Code. On export we only export the highest severity across all reactions associated with the allergy. rxn:Severity refers to AllergyReaction.Severity. It holds the

Prog_ID value that will be used to look up the ObsDef record containing details associated with the Severity. 5. “Allergy Reaction Code”: On export this value is mapped using Table 10063 (Reaction Type) in ObsDef. On import we will process all occurrences of this field. If no match is found, the field will be ignored and the AL1 segment will still be processed. On export, we export all reactions. rxn:Reaction_OBD_ID holds the OBD_ID value that will be used to look up the details associated with the Reaction.




Page 87

12.4 BHS – Batch Header Segment The BHS segment defines the start of a batch.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 1 ST R N Batch Field Separator PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Field Separator

2 3 ST R N Batch Encoding Characters PRF:Preference_Str File | Import/Export | HL7 Code Export… Change pushbutton Tab – MSH Segment Fields – Component Separator, Repetition Char, Sub Component

3 15 ST O N Batch Sending Application PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Sending Application

4 20 ST O N Batch Sending Facility PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Sending Facility

5 15 ST O N Batch Receiving Application PRF:Preference_Str PRF:Preference_Str 6 20 ST O N Batch Receiving Facility PRF:Preference_Str File | Import/Export | HL7 Code

Export…




Page 88

SEQ

LEN

TYPE

R/O

REP

TBL

NAME


MOSAIQ Application Mapping Change Button Tab – MSH Segment Fields – Receiving Facility

7 19 TS O N Batch Creation Date / Time NA NA 8 40 ST O N Batch Security * 9 20 ST O N Batch Name/ID/Type PRF:Preference_Str File | Import/Export | HL7 Code

Export… Change Button Tab – Batch Option Fields – BHS Name ID

10 80 ST O N Batch Comment PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – Batch Option Fields – BHS Comment

11 20 ST O N Batch Control ID PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – Batch Option Fields – BHS ID Start, End

12 20 ST O N Reference Batch Control ID *

BHS Field Notes * This field is not used by MOSAIQ ESI.

1 – 6, 8.: These fields have the same definition as the corresponding field in the MSH segment. 7. “Batch creation date/time”: Date and time batch was created.




Page 89

9. “Batch name/ID/type”: This field can be used by the application processing the batch. It can have extra components if needed. On exports, a free text field can be assigned.

10. “Batch comment”: A comment field that is not further defined. On exports, a free text field can be assigned. 11. “Batch control ID”: This field can be used to uniquely identify a particular Batch. It can be echoed in the Ref batch control ID field if an answering batch

is needed. On exports a range of values can be assigned, if required. The entire range would be used before it was repeated.




Page 90

12.5 BTS – Batch Trailer Segment The BTS segment defines the end of a batch.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 10 ST O N Batch Message Count See below. NA 2 80 ST O N Batch Comment PRF:Preference_Str File | Import/Export | HL7 Code Export…

Change Button Tab – Batch Option Fields – BHS Comment

3 100 CM O N Batch Totals See below. NA

BTS Field Notes 1. “Batch message count”: A count of the individual messages contained within the batch. 2. “Batch comment”: A comment field. 3. “Batch totals”: As many types of totals as needed for the batch may be carried by this field as separate components. Three totals are exported:

• Total records exported.

• Total transaction quantity. Sum of CHG:Days_Units for each exported charge.

• Total dollars. Sum of CHG:Days_Units * X for each exported charge, where X =

♦ CPT:Tech_Charge (for Tech charge only) or

♦ CPT:Prof_Charge (for Prof charge only) or

♦ CPT:Tech_Charge + CPT:Prof_Charge (for both Tech and Prof charge)




Page 91

12.6 DG1 – Diagnosis Segment The DG1 segment contains patient diagnosis information of various types, for example, admitting, primary, etc. The DG1 segment is used to send multiple diagnoses. MOSAIQ ESI can send and receive up to four DG1 segments. For the Lab Orders Outbound interface, Interface Manager will send at most one DG1 segment relating to the specific order being exported. ESI Manager ADT Inbound can import up to 4 Diagnosis. IIM ADT Inbound can import up to 10 Diagnosis. On export, only “active” diagnoses (MED:Status_Enum = 0) will be exported. For Syndromic Surveillance on export, only “active” and “working” diagnoses will be exported. Beginning in 2014, but not later than October 1, exported HL7 messages containing diagnosis information should send ICD-10 codes, rather than ICD-9 codes. Based on settings established in the System Utilities menu, Department Setup menu, the user can activate the Transition Diagnosis Sequences to ICD-10 and set the date when the transition should begin. Under this system, if the user has previously mapped and saved a given ICD-9 code to its corresponding ICD-10 code *, then on or after the effective transition date, the mapped ICD-10 code will be sent. Otherwise the ICD-9 code will be sent. * To map codes, see the Diagnosis and Staging window and use the online option to activate the web service

In addition, concerning DG1 segments being imported to update the patient’s medical Record, the import process will also check the following:

• If the DG1 segment of the inbound HL7 message contains a valid ICD-9 code which is mapped in the database to a valid ICD-10 and Snomed code, the processing will update all three codes in the patients’ medical record.

• If the DG1 segment of the inbound HL7 message contains a valid ICD-10 code which is mapped to in the database to a valid Snomed code, then both the ICD-10 code and Snomed code will be updated in the patient’s medical record.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 4 SI R N Set ID - Diagnosis “1”, “2”, “3”, “4” Set ID is used to determine mapping to corresponding diagnosis field in database.

2 n/a ID R N 0053 Diagnosis Coding Method Literal used in conjuction with Diagnosis Code to find a unique entry in the topography table For Syndromic Surveillance this is empty

med:TPG_ID For Syndromic Surveillance this is empty

File | Libraries | Diagnosis Codes Pushbutton – Add or Change Form – Diagnosis Code Field – Diagnosis Type

3 60 CE O N 0051 Diagnosis Code Used in conjuction with Diagnosis Codeing Method to find a unique entry in the topography

For Charge Out or ADT or Syndromic Surveillance med:TPG_ID

eChart | Diagnoses and Interventions Pushbutton – Diagnosis




Page 92

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




table and stored in med:TPG_ID

or For Lab Orders Outbound: odx:tpg_id

Column - Diagnosis For Patient Problems: eChart | Patient Problems Column – Code or Form – Observation Orders Field – Diagnosis

4 40 ST O N Diagnosis Description Not Used med:TPG_ID=> tpg:description

File | Libraries | Topography Codes Pushbutton – Change Fields – Description

5 26 TS O N Diagnosis Date / Time Med:Dx_Partial_DtTm (Update of this field is supported in IIM ADT Inbound only.)

Med:Dx_Partial_DtTm

File | Demographics Tab – Admission Pushbutton – Input Diagnosis Pushbutton – Change (Form – Diagnosis and Staging) Tab - Staging Field – Initial Diagnosis

6 2 ID R N 0052 Diagnosis / Drg Type* Not Used No Mapping Available For Syndromic Surveillance: “F” –Final Active Diag “W” – Working Diagn

DG1 Field Notes * This field is not used by MOSAIQ ESI. 1. “Set ID”: A number to uniquely identify the individual diagnosis, used to accept a single admitting diagnosis from an external system.




Page 93

2. For inbound interfaces this field will be used if DG1-3.3 is not populated. For outbound interfaces, the diagnosis coding method will be exported here and in DG1-3.3.

3. “Diagnosis code”: The diagnosis code assigned. ♦ On export, the diagnosis coding method is exported along with the diagnosis code. ObsDef table 51 provides the mapping between the Diagnosis

Coding Method label and code for use by the outbound interfaces and ESI Manager Charge inbound. NOTE: For the HL7 Charge Export interface built within MOSAIQ, the diagnosis coding method is only included when IMPAC.INI keyword “ESI_ExportDiagnosesFormat” in the “Global” section of IMPAC.INI is set to 1.

♦ On import, the diagnosis code (DG1-3.1) and diagnosis coding method must match an entry in the Topog table to be accepted. For Diagnosis Coding Method we will first consider DG1-3.3. If it is empty we will use DG1-2. If it is also empty, we will use the default defined for the interface. Defaults are configurable in both ESI Manager and IIM ADT interface configuration. On export we will export both diagnosis code and coding method. The diagnosis coding method will be exported in both DG1-2 and DG1-3.3. ObsDef table 51 provides the mapping between the Diagnosis Coding Method label and code for use by the outbound interfaces and ESI Manager ADT/Charge inbound. For IIM inbound interfaces, the interface specific mapping tables provide mapping between the codes and labels.

♦ For import using ESI Manager ADT Inbound:

• Table 0051 can be used for mapping purposes.

• For matching on Oncology (194.0 – 239.9) diagnoses only the base (everything prior to the period, “.”) of the code is considered. For non-Oncology codes complete code matching is performed.

♦ For import using IIM ADT Inbound:

• Table 0051 cannot be used for mapping purposes. Instead, calculations can be configured in the IBD Configurator if necessary.

• Diagnoses code matching is performed on the entire code for both Oncology and Non-Oncology diagnoses. ♦ For each valid diagnosis code MOSAIQ accepts through the interface, a unique diagnosis record will be created in the Medical table. The initial

record state will indicate that the record was imported via an interface (State = “Imported”). If a matching Medical record exists already, MOSAIQ will not create a new record for that same diagnosis. If at least 1 valid diagnosis is passed in via the interface MOSAIQ will remove any existing Medical records with State = “Imported” if there is not a matching DG1 record. Prioritization, MED.Seq is based on order of DG1 records.

♦ For export of charges, MOSAIQ will only export diagnoses for records that have been affirmed (Diag_State = 3) and are current (MED.Inactive_Partial_DtTm IS NULL). MOSAIQ will export them in order based on MED.Seq.

♦ For export of ADT information, diagnoses will only be included for MED records that have been affirmed (Diag_State = 3) and are current (MED.Inactive_Partial_DtTm IS NULL). The diagnoses will be exported in order based on either MED.Seq.

♦ For export of Lab or Pharmacy orders, the diagnoses will be exported in order based on OrdersDx.Dx_Num.




Page 94

♦ Use of MED.TPG_ID or MED.ICD10_TPG_ID is based on MOSAIQ Department Setup. Within the “Clinical (General 2)” tab there is a checkbox labeled Transition Diagnosis To ICD10 and an accompanying date field. If this checkbox is checked and the current date is >= the date specified then we will first check MED.ICD10_TPG_ID. If it is set we will use it. Otherwise we will use MED.TPG_ID.




Page 95

12.7 ERR – Error Segment The ERR segment is used to add error comments to acknowledgment messages.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 80 ID R Y Error Code and Location See below. NA

ERR Field Notes 1. “Error code and location”: Used to identify an erroneous segment in another message and contains four components:

♦ Segment ID. ♦ SEQUENCE ID ♦ The field position. ♦ A code identifying the error.

For systems that do not use the MOSAIQ ESI encoding rules, the data item number will be used for the third component. Data Error Codes are discussed in Section 7, Errors on page 66.




Page 96

12.8 EVN – Event Type Segment The EVN segment is used to communicate necessary trigger event information to receiving applications. Valid event types are contained in HL7 table 0003 - Event type.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 3 ID R N 0003 Event Type Code NA NA NA 2 19 TS R N Date / Time of Event NA For event code P03:

CHG:Proc_DtTm or For event code A04: DST:Trigger_DtTm

Code Mgmt | Code Capture Tab – General Fields – To Date, Time

3 19 TS O N Date / Time of Planned Admit*

4 3 ID O N 0062 Event Reason Code NA NA NA 5 60 XCN O N 0188 Operator ID* 6 26 TS O N Event Occurred*

EVN Field Notes * This field is not used by MOSAIQ ESI.

1. “Event type code”: Codes correspond to the trigger events processed by MOSAIQ ESI. Refer to 2.1 for the event type codes MOSAIQ ESI supports. 2. “Date / time of event”: Most systems will default to the system date/time when the transaction was entered, but should also permit an override. 4. “Event reason code”: Values are 01 - patient request; 02 - physician order; 03 - census management.




Page 97

12.9 FHS – File Header Segment The FHS segment is used to head a file (group of batches). It is used in the HL7 Batch Protocol.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 1 ST R N File Field Separator PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Field Separator

2 4 ST R N File Encoding Characters PRF:Preference_Str File | Import/Export | HL7 Code Export… Change pushbutton Tab – MSH Segment Fields – Component Separator, Repetition Char, Sub Component

3 15 ST O N File Sending Application PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Sending Application

4 20 ST O N File Sending Facility PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Sending Facility

5 15 ST O N File Receiving Application PRF:Preference_Str PRF:Preference_Str

6 20 ST O N File Receiving Facility PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Receiving Facility

7 19 TS O N File Creation Date / Time NA NA 8 40 ST O N File Security *




Page 98

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



9 20 ST O N File Name/ID/Type PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – Batch Option Fields – FHS Name ID

10 80 ST O N File Comment PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – Batch Option Fields – FHS Comment

11 20 ST O N File Control ID PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – Batch Option Fields – FHS ID Start, End

12 20 ST O N Reference File Control ID *

FHS Field Notes 1 – 6, 8.: These fields have the same definition as the corresponding field in the MSH segment. 7. “Date/time of file creation”: This field has the same definition as the corresponding field in the MSH segment. 8. “File security”: This field has the same definition as the corresponding field in the MSH segment. 9. “File Name/ID/Type”: This should have the filename and file extension. On exports, either the filename and file extension will appear, or if required, a

free text field can be assigned. 10. “File header comment”: A free text field. On exports, a free text field can be assigned. 11. “File control ID”: This field is used to identify a particular file uniquely. It can be echoed in the Reference file control ID field of the FTS segment. On

exports, if required, a range of values can be assigned. The entire range would be used before it was repeated.




Page 99

12.10 FTS – File Trailer Segment The FTS segment defines the end of a file. It is used in the HL7 Batch Protocol.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 10 ST O N File Batch Count NA NA 2 80 ST O N File Trailer Comment PRF:Preference_Str File | Import/Export | HL7 Code

Export… Change Button Tab – Batch Option Fields – FHS Comment

FTS Field Notes 1. “File batch count”: This field contains the number of batches contained in the file. 2. “File trailer comment”: A free text field.




Page 100

12.11 FT1 – Financial Transaction Segment The FT1 segment contains the detail data necessary to post charges, payments, adjustments, etc. to patient accounting records.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 4 SI O N Set ID – Financial Transaction “1” 2 12 ST O N Transaction ID HL7 Code Export:

chg:chg_id (if chg:days_units >= 0) else chg:void_chg_id OIM Charge Export: If (chg:days_units >= 0) Then chg:chg_id If (chg:days_units < 0) Then If (chg:void_chg_id =null) Then chg:chg_id Else chg:void_chg_id

Code Mgmt | Code Capture Tab – General Fields – Days/Qty

3 10 ST O N Transaction Batch ID* 4 26 TS R N Transaction Date chg:proc_dttm chg:proc_dttm

NOTE: the time portion is exported for HL7 2.3 only. For OIM Charge Export: chg:from_dttm, chg:proc_dttm Format: If both are present, chg:from_dttm^chg:proc_dttm; otherwise,

Code Mgmt | Code Capture Tab – General Fields – To Date, Time For OIM Charge Export: Code Mgmt | Code Capture Tab – General Fields – From Date, To Date, Time




Page 101

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




chg:from_dttm or chg:proc_dttm, whichever is present.

5 26 TS O N Transaction Posting Date* 6 8 IS R N 0017 Transaction Type “Credit” or “Charge” “Credit” or “Charge”

(Configurable through mapping.)

Code Mgmt | Code Capture Tab – General Fields – Based on Days/Qty

7 80 CE R N 0096 Transaction Code chg:hsp_code

chg:hsp_code or cpt:cpt_code For OIM Charge Export: cpt:cpt_code, or cpt:hsp_code – hsp_code5

Code Mgmt | Code Capture Fields – Code For OIM Charge Export: File | Libraries | Procedures and Supplies… Pushbutton – Change Tab – Code Fields – ProcLabel1 – ProcLabel6

8 40 ST O N Transaction Description cpt:description Code Mgmt | Code Capture Fields – Text next to Code Dropdown

9 40 ST O N Transaction Description – Alt chg:notes chg:notes Code Mgmt | Code Capture Tab - General Fields – Billing Comment

10 6 NM O N Transaction Quantity chg:days_units (This is a required field.)

Absolute value of chg:days_units

Code Mgmt | Code Capture Tab – General Fields – Days/Qty

11 12 CP O N Transaction Amount – Extended chg:days_units * FT1-12 (Transaction Amount – Unit) If the result is 0.00, this field is left blank.




Page 102

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




12 12 CP O N Transaction Amount – Unit cpt:prof_ charge or cpt:tech_charge or cpt:tech_charge + cpt:prof_charge For OIM Charge Export: (chg:prof_chg or cpt:prof_ charge) or (chg:tech_chg or cpt:tech_charge) or ((chg:tech_chg or cpt:tech_charge) + (chg:prof_chg or cpt:prof_charge)) If the result is 0.00, this field is left blank.

File | Libraries | Procedures and Supplies… Pushbutton – Change Tab – Capture Schedule Fields – Pro Forma Prof Charge, Pro Forma Tech Charge For OIM Charge Export: As above, or Charge slip overrides: Code Mgmt | Code Capture Tab – Billing Overrides Fields – Tech Chg, Prof Chg

13 60 CE O N 0049 Department Code chg:Inst_ID (This is a required field.)

cpt:rsp_center or chx:dept_id or cfg:Inst_Abrv For HL7 Charge Export: chx:dept_id is a configuration setting. For OIM Charge Export: Option selected in the OIM interface definition. chx:dept_id is a user defined value

File | Libraries | Procedures and Supplies… Pushbutton – Change Tab – Capture Schedule Fields – Cost Center or Code Mgmt | Code Capture Fields – Dept For OIM Charge Export: Mapping & Segments tab, Department Code




Page 103

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




14 60 CE O N 0072 Insurance Plan ID chg:auth_num File | Insurance Pushbutton – Auths Form – Authorizations Column – Authorization Number

15 12 CP O N Insurance Amount* 16 12 PL O N 0079 Patient Location chg:rend_fac_id

* ID Mapping in OIM

chg:location_id (if IMPAC.INI keyword ESI_ExportLocationCode = 1) else chg:rend_fac_id For OIM chargeExport: Chg:rend_fac_id

Code Mgmt | Code Capture Tab – General Fields – Facility Or Code Mgmt | Code Capture Tab – General Fields – Location For OIM Charge Export: Code Mgmt | Code Capture Tab – General Fields – Facility

17 1 IS O N 0024 Fee Schedule* 18 2 IS O N 0018 Patient Type chg:IsInpatient chg:IsInpatient Code Mgmt | Code Capture

Tab – General Fields – Inpatient checkbox

19 60 CE O Y 0051 Diagnosis Code chg:TPG_ID1, chg:TPG_ID2, chg:TPG_ID3, chg:TPG_ID4

chg:TPG_ID1, chg:TPG_ID2, chg:TPG_ID3, chg:TPG_ID4 sorted with primary charge diagnosis first Primary charge is indicated in chg:pri_icd_code

Code Mgmt | Code Capture Tab – General Fields – Diagnosis Group Box 1, 2, 3, 4




Page 104

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




Diagnosis Method sent in second component. See field note for differences between HL7 Code Export and OIM

20 120 XCN R N 0084 Performed By Code chg:staff_id * ID Mapping in OIM

chg:staff_id Code Mgmt | Code Capture Tab – General Fields – Rendering Staff

21 120 XCN O N Ordered By Code* 22 12 CP O N Unit Cost cpt:cost

If the result is 0.00, this field is left blank.

File | Libraries | Procedures and Supplies… Pushbutton – Change Tab – Capture Schedule Fields – Pro Forma Cost

23 75 EI O N Filler Order Number* 24 120 XCN O N Entered By Code chg:edit_id Database only. 25 80 CE O N 0088 Procedure Code chg:modifier1

chg:modifier2 chg:modifier3 chg:modifier4

cpt:cpt_code chg:modifier1 chg:modifier2 chg:modifier3 chg:modifier4

Code Mgmt | Code Capture Fields – Code, Modifier 1, 2 and 3

26 80 CE O Y Procedure Code Modifiers chg:modifier1 chg:modifier2 chg:modifier3 chg:modifier4

chg:modifier1 chg:modifier2 chg:modifier3 chg:modifier4

Code Mgmt | Code Capture Fields – Modifier 1, 2 and 3

FT1 Field Notes * This field is not used by MOSAIQ ESI.

ID Mapping in OIM: When you export information about a Staff or External Physician, Facility, Location or Payer, you can select the “ID Type” to export. You can configure this within the “Mapping & Segments” tab in the INTERFACE PROPERTIES form.

6. “Transaction Type”:




Page 105

♦ Import: Used to determine whether to set Transaction Quantity (FT1-10) as positive or negative when importing data. If this value, or its mapped value, is not “Charge” or “Credit” then the charge is invalid and will not be imported.

♦ Export: Code that identifies the type of transaction; i.e., charge, credit, payment, etc. Refer to user-defined table 0017 - transaction type. ♦ Default value is Charge for outbound charge records.

7. “Transaction Code”: cpt:code can be provided as an alternative to chg:hsp_code. This is controlled through an option switch. For OIM Charge Export, the value is configurable on the “Mapping and Segments” tab, in the “Export Code (FT1-7)” row.

12. “Transaction Amount - Unit”: The value depends on both the billable filter (Tech, Prof, Both) selected during export and the billable status of the charge, CPT:BILLABLE.

13. “Department Code”

♦ chg:Inst_ID is set by matching the department abbreviation in FT1-13 to CFG:Inst_Abrv. ♦ cpt:rsp_center or chx:dept_id or chg:Inst_Abrv are controlled through user selection.

14. “Insurance Plan ID”: Only the second component is filled in.

19. On export, the diagnosis coding method is exported along with the diagnosis code. ObsDef table 51 provides the mapping between the Diagnosis Coding Method label and code for use by the outbound interfaces and ESI Manager Charge inbound. NOTE: For the HL7 Charge Export interface built within MOSAIQ, the diagnosis coding method is only included when IMPAC.INI keyword “ESI_ExportDiagnosesFormat” in the “Global” section of IMPAC.INI is set to 1.

19. On import, the diagnosis code (FT1-19.1) and diagnosis coding method (FT1-19.3) must match an entry in the Topography table to be accepted. These items correspond to the “Diagnosis Code” and “Diagnosis Type” controls within the DIAGNOSIS CODE form in MOSAIQ. If diagnosis coding method (FT1-19.3) is empty we will use the default defined for the interface. Defaults are configurable in both ESI Manager and IIM ADT interface configuration. ObsDef table 53 (Diagnosis Coding Method) provides the mapping between the Diagnosis Coding Method label and code for use by the outbound interfaces and ESI Manager ADT/Charge inbound. For IIM inbound interfaces, the interface specific mapping tables provide mapping between the codes and labels.

26. “Procedure Code Modifiers”: FT1-26 overrides FT1-25 for importing modifiers.

Charge Modifiers may appear in FT1-25 in the format "77761^^^m1m2m3m4^^MODIFIER" in which: ♦ 77761 = CPT Code (Cpt:cpt_code) ♦ m1 = Modifier 1 (Chg:modifier1) ♦ m2 = Modifier 2 (Chg:modifier2) ♦ m3 = Modifier 3 (Chg:modifier3)




Page 106

♦ m4 = Modifier 4 (Chg:modifier4) ♦ MODIFIER = Alternate ID Code




Page 107

12.12 FT1 – Financial Transaction Segment (IIM: ADT Inbound Interface) The FT1 segment contains the detail data necessary to post charges, payments, adjustments, etc. to patient accounting records.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 4 SI O N Set ID – Financial Transaction 2 12 ST O N Transaction ID Not displayed in application 3 10 ST O N Transaction Batch ID 4 26 TS R N Transaction Date BatchPay:Batch_DtTm Schedule | Daily Master |

Right Click drop down menu View Co-Payments… Window - Schedule Payments Pushbutton – Change Window – Collect Patient Payment Field – Date, Time

5 26 TS O N Transaction Posting Date 6 8 IS R N 0017 Transaction Type* BatchPay:Batch_Type = 1

(Co-Pay) Schedule | Daily Master | Right Click drop down menu View Co-Payments… Window - Schedule Payments Grid Column – Co-Pay

7 80 CE R N 0096 Transaction Code* BatchPay:Pay_Type

Schedule | Daily Master | Right Click drop down menu View Co-Payments… Window - Schedule Payments Pushbutton – Change Window – Collect Patient Payment Field – Payment Method

8 40 ST O N Transaction Description 9 40 ST O N Transaction Description – Alt 10 6 NM O N Transaction Quantity 11 12 CP O N Transaction Amount – Extended 12 12 CP O N Transaction Amount – Unit




Page 108

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



13 60 CE R N 0049 Department Code* BatchPay:Inst_ID Schedule | Daily Master | Right Click drop down menu View Co-Payments… Window - Schedule Payments Drop Down – Department

14 60 CE R N 0072 Insurance Plan ID* BatchPay:Payer_ID BatchPay:Copay_PP_ID

Schedule | Daily Master | Right Click drop down menu View Co-Payments… Window - Schedule Payments Pushbutton – Change Window – Collect Patient Payment Field – Insurance

15 12 CP O N Insurance Amount BatchPay:Amount Right Click drop down menu View Co-Payments… Window - Schedule Payments Pushbutton – Change Window – Collect Patient Payment Field – Amount

16 12 PL O N 0079 Patient Location 17 1 IS O N 0024 Fee Schedule 18 2 IS O N 0018 Patient Type 19 60 CE O N 0051 Diagnosis Code 20 120 XCN O N 0084 Performed By Code 21 120 XCN O N Ordered By Code 22 12 CP O N Unit Cost 23 75 EI O N Filler Order Number 24 120 XCN O N Entered By Code 25 80 CE O N 0088 Procedure Code 26 80 CE O Y Procedure Code Modifiers 27 250 CE O N Advanced Beneficiary Notice

Code




Page 109

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



28 250 CWE O N Medically Necessary Duplicate Procedure Reason.

29 250 CNE O N NDC Code 30 250 String O N Track number BatchPay:TrackNo Right Click drop down menu View Co-

Payments… Window - Schedule Payments Pushbutton – Change Window – Collect Patient Payment Field – Tracking Number

31 4 SI R N Transaction Reference Key BatchPay:Sch_ID Not displayed

FT1 Field Notes * This field is not used by MOSAIQ ESI.

6. “Transaction Type”: ♦ Import: This field will always be imported as a Co-pay type.

7. “Transaction Code”: If this value, is not one of the existing available values in the Payment Method window, the value is added as an entry in the Prompt table and mapped to the BatchPay table.

13. “Department Code”

♦ BatchPay:Inst_ID is set by matching the department for the associated appointment of the Sch_ID in field FT1-31.

14. “Insurance Plan ID”:

♦ The Payer for the given Co-Pay is identified by the ESIID code coming in this field. ♦ The most recent Pat_Pay record for the above Payer is associated with the BatchPay record as the CoPay_PP_ID

26. “Transaction Reference Key”: The Co-Pay/BatchPay record is associated with an Appointment by the value in this field. The Appointment is identified by matching this value to an active appointment Sch_Set_ID.




Page 110

12.13 GT1 – Guarantor Segment The GT1 segment contains guarantor (for example, the person or the organization with financial responsibility for payment of a patient account) data for patient and insurance billing applications. MOSAIQ ESI can send and receive only one GT1 segment.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 20 SI R N Set ID - Guarantor No mapping available “1” None 2 58 CX O Y Guarantor Number* 3 48 XPN R Y Guarantor Name pp:bil_fname,

pp:bil_lname, pp:bil_mdl_init

pp:bil_fname, pp:bil_lname, pp:bil_mdl_init or pat:last_name, pat:first_name, pat:middle_name

File | Insurance Change pushbutton Tab – Responsible Billing Party Fields – Last, First, MI or File | Demographics Tab – Name/IDs Fields – Last, First, MI

4 48 XPN O Y Guarantor Spouse Name* 5 106 XAD O Y Guarantor Address pp:bil_adr1,

pp:bil_adr2, pp:bil_city, pp:bil_state, pp:bil_postal, pp:bil_country

pp:bil_adr1, pp:bil_adr2, pp:bil_city, pp:bil_state, pp:bil_postal or adm:pat_adr1, adm:pat_adr2, adm:pat_city, adm:pat_state, adm:pat_postal,

File | Insurance Change pushbutton Tab – Responsible Billing Party Fields – 1, 2, City, State, Postal, Country or File | Demographics Tab – Home/Work Group Box – Patient’s Home Address/Phone Fields – 1, 2, City, State, Postal, Country

6 40 XTN O N Guarantor Ph. Num.- Home Format: Uses only component 1 of XTN.

pp:bil_home_phone, If GT1.10 <> “Self and

pp:bil_home_phone, pp:bil_home_phone_ex or

File | Insurance Change pushbutton Tab – Responsible Billing




Page 111

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




GT1.6.3 = “CP” pp.bil_cellphone

adm:pat_home_phone, adm:pat_home_phone_ex

Party Fields – Phone or File | Insurance Change pushbutton Tab – Employment Group Box – Home Address/Phone Fields – Phone

7 40 XTN O N Guarantor Ph.Num-Business Format: Uses only component 1 of XTN.

pp:bil_work_phone, pp:bil_work_phone_ex

pp:bil_work_phone, pp:bil_work_phone_ex or adm:pat_work_phone, adm:pat_work_phone_ex

File | Insurance Change pushbutton Tab – Responsible Billing Party Fields – Work, Ext or File | Demographics Tab – Home/Work Group – Patient’s Work Address/Phone Fields – Phone, Ext

8 26 TS O N Guarantor Date Of Birth pp:bil_birth_dttm

pp:bil_birth_dttm or pat:birth_dttm

File | Insurance Change pushbutton Tab – Responsible Billing Party Fields – Date of Birth or File | Demographics Tab – Personal Group – Personal Fields – Birth Date

9 10 IS O N 0001 Guarantor Sex pp:bil_gender

pp:bil_gender or adm:gender

File | Insurance Change pushbutton Tab – Responsible Billing Party




Page 112

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



MOSAIQ Application Mapping Fields – Gender or File | Demographics Tab – Personal Group – Personal Fields – Gender

10 2 IS O N 0068 Guarantor Type* 11 2 IS O N 0063 Guarantor Relationship pp:bil_relate pp:bil_relate File | Insurance

Change pushbutton Tab – Responsible Billing Party Fields – Patient’s Relationship to Policyholder

12 9 ST O N Guarantor Social Security pp:bil_ssn

pp:bil_ssn or pat:ss_number

File | Insurance Change pushbutton Tab – Responsible Billing Party Fields – SSN or File | Demographics Tab – Personal Group – Personal Fields – SSN

13 8 DT O N Guarantor Date – Begin pp:effective_dttm pp:effective_dttm File | Insurance Change pushbutton Tab – General Fields – Effective Date

14 8 DT O N Guarantor Date - End pp:expiration dttm pp:expiration dttm File | Insurance Change pushbutton Tab – General Fields – Expiration Date

15 2 NM O N Guarantor Priority pp:priority pp:priority File | Insurance Change pushbutton




Page 113

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



MOSAIQ Application Mapping Tab – General Fields – Billing Priority

16 130 XPN O Y Guarantor Employer Name pp:bil_employer

pp:bil_employer or adm:pat_employer

Insurance Employment Tab or File | Demographics Tab – Home/Work Group – Patient’s Home Address/Phone Fields – Employer

17 106 XAD O Y Guarantor Employer Address pp:emp_adr1, pp:emp_adr2, pp:emp_city, pp:emp_state, pp:emp_postal

pp:emp_adr1, pp:emp_adr2, pp:emp_city, pp:emp_state, pp:emp_postal or adm:emp_adr1, adm:emp_adr2, adm:emp_city, adm:emp_state, adm:emp_postal

File | Insurance Change pushbutton Tab – Employment Fields – 1, 2, City, State, Postal or File | Demographics Tab – Home/Work Group – Patient’s Home Address/Phone Fields – 1, 2, City, State, Postal

18 40 XTN O Y Guarantor Employ Phone # Format: Uses only component 1 of XTN.

pp:emp_phone pp:emp_phone, pp:emp_phone_ex or adm:emp_phone, adm:emp_phone_ex

File | Insurance Change pushbutton Tab – Employment Fields – Phone or File | Demographics Tab – Home/Work Group – Patient’s Home Address/Phone Fields - Phone

19 20 CX O Y Guarantor Employee ID Num* 20 2 IS O N 0066 Guarantor Employment Status*




Page 114

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




21 130 XON O Y Guarantor Organization Name* 22 1 ID O N 0136 Guarantor Billing Hold Flag* 23 80 CE O N Guarantor Credit Rating Code* 24 26 TS O N Guarantor Death Date And

Time*

25 1 ID O N 0136 Guarantor Death Flag* 26 80 CE O 0218 Guarantor Charge Adjustment

Code*

27 10 CP O Guarantor’s Household Annual Income*

28 3 NM O Guarantor’s Household Size* 29 20 CX O Y Guarantor’s Employer ID

Number*

30 1 IS O 0002 Guarantor’s Marital Status Code* 31 8 DT O Guarantor Effective Hire Date* 32 8 DT O Employment Stop Date* 33 2 IS O 0223 Living Dependency* 34 2 IS O 0009 Ambulatory Status* 35 4 IS O 0171 Citizenship* 36 60 CE O 0296 Primary Language* 37 2 IS O 0220 Living Arrangement* 38 80 CE O 0215 Publicity Indicator* 39 1 ID O 0136 Protection Indicator* 40 2 IS O 0231 Student Indicator* 41 3 IS O 0006 Religion* 42 48 XPN O Mother’s Maiden Name* 43 80 CE O 0212 Nationality* 44 3 IS O 0189 Ethnic Group* 45 48 XPN O Y Contact Person’s Name* 46 40 XTN O Y Contact Person’s Telephone

Number*

47 80 CE O 0222 Contact Reason* 48 2 IS O 0063 Contact Relationship*




Page 115

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




49 20 ST O Y Job Title If GT1.11 <> “Self” pp:bil_occupat

File | Insurance Change pushbutton Tab – Employment Fields – Occupation

49 20 ST O Job Title* 50 20 JCC O 0327/

0328 Job Code/Class*

51 130 XON O Y Guarantor Employer’s Organization Name*

52 2 IS O 0310 Handicap* 53 2 IS O 0311 Job Status* 54 50 FC O 0064 Guarantor’s Financial Class* 55 1 IS O 0005 Guarantor Race*

GT1 Field Notes * This field is not used by MOSAIQ ESI.

1. “Set ID – guarantor”: A number that uniquely identifies the transaction. MOSAIQ ESI imports only one GT1 segment per message. Subsequent GT1 segments will be ignored.

11. “Guarantor relationship”: Identifies the relationship between the guarantor and the patient (i.e. Parent, Child, etc.). See user-defined table 0063. If the relationship = “Self”, we will not import data from fields 3, 5, 6, 7, 8, 9, 12, 16, 17 or 18.

15. “Guarantor priority”: A code used to determine the order in which the guarantors will be responsible for the patient’s bill.

For GT1 fields 3, 5, 6, 7, 8, 9, 11, 12, 17, 18 the outbound database mapping is based on GT1-11 (Guarantor Relationship). When the relationship is “Self”, the database mapping looks to the Admin (ADM) and Patient (PAT) tables. When the relationship is not “Self”, the database mapping looks to the Pat_Pay (PP) table.




Page 116

GT1 Outbound Processing Details For outbound interfaces, one GT1 segment is built for a patient if the patient has a guarantor insurance record where the insurance is not expired and not voided. The record must pass these rules: ((filter_dttm >= pat_pay.effectvie_dttm) and (filter_dttm <= pat_pay.expiration_dttm) or

(filter_dttm >= pat_pay.effectvie_dttm) and (pat_pay.expiration_dttm is null)) and pat_pay.inactive <> 2 For Lab orders outbound, the filter_dttm is order.start_dttm For Pharmacy orders outbound: filter_dttm is order.start_dttm For ADT outbound: filter date is trigger_dttm




Page 117

12.14 IN1 – Insurance Segment The IN1 segment contains insurance policy coverage information necessary to produce properly pro-rated and patient and insurance bills. MOSAIQ ESI can send and receive up to five IN1 segments. IIM ADT Inbound can be configured to automatically insert Payer records if a matching record is not found.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 20 SI R N Set ID - Insurance No mapping available “1”, “2”, “3”, “4”, “5” None 2 20 IS R N 0072* Insurance Plan ID eid:id_code eid:id_code

* ID Mapping in OIM File | Directories | Payer Directory… Change pushbutton Edit IDs pushbutton Column – Identification (in which Type = ‘ESI’).

3 59 CX R Y Insurance Company ID NOTE: This field is optional for our use even though HL7 shows it as mandatory.

pay:miscid

pay:miscid File | Directories | Payer Directory… Change pushbutton Tab – General Field – Ext ID

4 45 ST O Y Insurance Company Name pay:payer_name

pay:payer_name File | Directories | Payer Directory… Change pushbutton Tab – General Field – Name

5 106 XAD O Y Insurance Company Address pay:adr1, pay:adr2, pay:city, pay:state, pay:postal

pay:adr1, pay:adr2, pay:city, pay:state, pay:postal

File | Directories | Payer Directory… Change pushbutton Tab – Contact Address/Phone Fields – 1, 2, City, State, Postal

6 48 XPN O N Insurance Co.Contact Pers pay:contact

File | Directories | Payer Directory… Change pushbutton Tab – Contact Address/Phone Field – Contact

7 40 XTN O Y Insurance Co Phone Number pay:pri_phone, pay:pri_phone, File | Directories | Payer Directory…




Page 118

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




pay:pri_phone_ex pay:pri_phone_ex Change pushbutton Tab – Contact Address/Phone Field – Primary

8 12 ST O N Group Number pp:group_no

pp:group_no File | Insurance Change pushbutton Tab – General Fields – Group

9 35 ST O Y Group Name* 10 12 ST O Y Insured's Group Emp. ID* 11 45 ST O Y Insured's Group Emp.Name* 12 8 DT O N Plan Effective Date pp:effective_dttm pp:effective_dttm File | Insurance

Change pushbutton Tab – General Fields – Effective Date

13 8 DT O N Plan Expiration Date pp:expiration_dttm pp:expiration_dttm File | Insurance Change pushbutton Tab – General Fields – Expiration Date

14 55 CM O N Authorization Information* 15 3 IS O N 0086 Plan Type* 16 48 XPN O N Name Of Insured pp:bil_lname,

pp:bil_fname, pp:bil_mdl_init

pp:bil_lname, pp:bil_fname, pp:bil_mdl_init or pat:last_name, pat:first_name, pat:middle_name

File | Insurance Change pushbutton Tab – Responsible Billing Party Fields – Last, First, MI or File | Demographics Tab – Name/IDs Fields – Last, First, MI

17 10 IS O N 0063 Insured's Relationship To Pat pp:bil_relate pp:bil_relate File | Insurance Change pushbutton Tab – Responsible Billing Party




Page 119

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



MOSAIQ Application Mapping Fields – Patient’s Relationship to Policyholder

18 26 TS O N Insured's Date Of Birth pp:bil_birth_dttm pp:bil_birth_dttm or pat:birth_dttm

File | Insurance Change pushbutton Tab – Responsible Billing Party Fields – Date of Birth or File | Demographics Tab – Personal Fields – Birth Date

19 106 XAD O N Insured’s Address pp:bil_adr1, pp:bil_adr2, pp:bil_city, pp:bil_postal, pp:bil_country

pp:bil_adr1, pp:bil_adr2, pp:bil_city, pp:bil_postal, pp:bil_country or adm:pat_adr1, adm:pat_adr2, adm:pat_city, adm:pat_state, adm:pat_postal, adm:pat_country

File | Insurance Change pushbutton Tab – Responsible Billing Party Fields – 1, 2, City, State, Postal, County or File | Demographics Tab – Home/Work Group Box – Patient’s Home Address/Phone Fields – 1, 2, City, State, Postal

20 2 IS O N Assignment Of Benefits* 21 2 IS O N Coordination Of Benefits* 22 2 ST O N Coord Of Ben. Priority pp:priority pp:priority File | Insurance

Change pushbutton Tab – General Fields – Billing Priority

23 2 ID O N Notice Of Admission Code pay:auth_req File | Directories | Payer Directory… Change pushbutton Tab – General




Page 120

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



MOSAIQ Application Mapping Field – Prior Authorization Required checkbox

24 8 DT O N Notice Of Admission Date* 25 2 ID O N 0094 Rpt Of Eligibility Code* 26 8 DT O N Rpt Of Eligibility Date* 27 2 IS O N 0093 Release Information Code* 28 15 ST O N Pre-Admit Cert.Code (Pac) pp:pr_auth_no pp:pr_auth_no File | Insurance

Change pushbutton Tab – General Fields – Primary Authorization

29 26 TS O N Verification Date pp:Verified_DtTm pp:Verified_DtTm File | Insurance Change pushbutton Tab – General Fields – Verified On

30 60 XCN O N Verification By pp:Verified_Staff_ID pp:Verified_Staff_ID * ID Mapping in OIM

File | Insurance Change pushbutton Tab – General Fields – Verified By

31 2 IS O N 0098 Type Of Agreement Code* 32 2 IS O N 0022 Billing Status* 33 4 NM O N Lifetime Reserve Days* 34 4 NM O N Delay Before L. R. Day* 35 8 IS O N 0042 Company Plan Code* 36 15 ST O N Policy Number pp:policy_no pp:policy_no File | Insurance

Change pushbutton Tab – General Fields – Policy Number

37 12 CP O N Policy Deductible pp:copay_amount pp:copay_amount File | Insurance Change pushbutton Tab – General Fields – Co-Pay




Page 121

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




38 12 CP O N Policy Limit - Amount* 39 4 NM O N Policy Limit - Days* 40 12 CP O N Room Rate - Semi-Private* 41 12 CP O N Room Rate - Private* 42 60 CE O N 0066 Insured's Employment Status* 43 1 IS O N 0001 Insured's Sex* 44 106 XAD O N Insured's Employer Address pp:emp_adr1,

pp:emp_adr2, pp:emp_city, pp:emp_state, pp:emp_postal or adm:emp_adr1, adm:emp_adr2, adm:emp_city, adm:emp_state, adm:emp_postal

File | Insurance Change pushbutton Tab – Employment Fields – 1, 2, City, State, Postal or File | Demographics Tab – Home/Work Group Box – Patient’s Work Address/Phone Fields – 1, 2, City, State, Postal

45 2 ST O N Verification Status* 46 8 IS O N 0072 Prior Insurance Plan ID* 47 2 IS O N 0309 Coverage Type* 48 2 IS O N 0310 Handicap*

49 12 CX O N Insured’s ID Number*

IN1 Field Notes * This field is not used by MOSAIQ ESI.


1. “Set ID - insurance”: Each account can have multiple insurance segments. The set number serves to uniquely identify each one. 2. “Insurance plan ID”: The code that uniquely identifies the insurance plan. User-defined table 0072 is unused in MOSAIQ.




Page 122

3. “Insurance Company ID”: This field is optionally imported for the Charge Inbound interface only (Event Code P03). 4. “Insurance Company Name”: This field is optionally imported for the Charge Inbound interface only (Event Code P03). 5. “Insurance Company Address”: This field is optionally imported for the Charge Inbound interface only (Event Code P03). 6. “Insurance Company Contact Person”: This field is optionally imported for the Charge Inbound interface only (Event Code P03).

17. “Insurance Relationship to Patient”: ”: Identifies the relationship between the guarantor and the patient (i.e. Parent, Child, etc.). See user-defined table 0063. If the relationship = “Self”, we will not import data from fields 16, 18 or 19.

37. For the OIM Outbound ADT, this field will have a value if a) there is a Co-Pay value available in the patient’s Insurance record, and b) “Skip Co-Pay” is not checked on the Appointment Slip (Schedule record) of the associated appointment. The associated appointment is the appointment whose booking caused the ADT Outbound message to be sent.

Eligibility Verified Date & User will be supported by both the import and export process. If the Verified Date is present in an imported record, the Eligibility Status within the patient payer record will be set to “Verified”; otherwise it will be set to “Unknown”.

NOTE 1: For IN1 fields IN1-16 (Name of Insured), IN1-18 (Insured’s Date of Birth), IN1-19 (Insured’s Address) and IN1-44 (Insured’s Employer Address) the outbound database mapping is based on IN1-17 (Insured’s Relationship to Patient). When the relationship is “Self”, the database mapping looks to the Admin (ADM) and Patient (PAT) tables. When the relationship is not “Self”, the database mapping looks to the Pat_Pay (PP) table. NOTE 2: To eliminate a single plan, a null value must be sent in IN1-3 and IN1-4. (IN1|1|ESI-ID1|””|””|) NOTE 3: To eliminate all plans, a null value must be sent in IN1-2 and IN1-3. (IN1|””|””|””)




Page 123

12.14.1 IN1 Processing Rules (Inbound Interface Manager (IIM) ADT Interface)

Two basic rules apply to processing of IN1 segments.

1. At most 5 IN1 segments will be received from the other system

The following terms will be used throughout the discussion of INI processing:

Term Description Payer The MOSAIQ database table that stores information about Insurance companies. Pat_Pay The MOSAIQ database table that stores the association details between the Patient and the Payer. A Patient can have

multiple Pat_Pay records with the same or different priorities. For a given priority, the Active records cannot have an overlap between their Effective – Expiration date ranges.

Payer_Type Within MOSAIQ there are many types of Payers. Each Pat_Pay record is assigned a Payer Type, The ADT interface supports the adding of Pat_Pay records with the following Payer Types:

1. General 2. Guarantor 3. Carve-Out

Except where specifically noted, IN1 processing is focused on Pat_Pay records with Payer_Type = General. We conditionally add Pat_Pay records with Payer_Type = Guarantor and Carve-Out under special circumstances documented in section 12.14.1.2 IN1 Special Cases (Inbound Interface Manager (IIM) ADT Interface).

Pat_Pay Status = Active Pat_Pay records for which no overlap of Effective – Expiration date range exists with other Pat_Pay records. Pat_Pay Status = Conflict When importing IN1 data, a conflict may exist between the IN1 data and existing Pat_Pay records. We will attempt to

resolve the conflict automatically. If it cannot be resolved, the Pat_Pay record(s) will be marked as Conflict. Pat_Pay Status = Void We also provide the ability to remove the association between a Patient and Payer. We accomplish this by marking the

Pat_Pay record as Void. Current Pat_Pay Records Current refers to Pat_Pay records with Payer_Type = General, Status = Active and Effective – Expiration Date range

including the current date.




Page 124

The IN1 segments within an ADT message are assumed to represent the current active set of Insurers for the patient. Based on this assumption we will compare the set of IN1 segments in the message against the Current Pat_Pay records associated with the patient. Any differences we identify will result in one or more of the following actions:

♦ Adding a new Pat_Pay record. ♦ Updating the expiration date of an existing Pat_Pay record. ♦ Marking one or more existing Pat_Pay as Conflict. ♦ Updating an existing Pat_Pay record.




Page 125

12.14.1.1 IN1 Processing Rules (Overview)

In general, IN1 processing is usually a simple process. However, there are numerous special conditions that we handle to support the manner in which Pat_Pay records are maintained within MOSAIQ. The following table outlines the steps for processing IN1 segments.

Step Short Description Detailed Description 1 Repeating IN1 limits Only the first 5 IN1 segments within the message will be processed. All others will be ignored. 2 IN1 Prioritization MOSAIQ supports priorities from 1 to 99. If the first 5 IN1 segments contain unique values for IN1-22 in the range of 1

to 99 we will use those values. Otherwise, we will reassign the priorities for those segments as 1 – 5 based on the order they appear in the message.

3 IN1 Validation IN1-12 (Plan Effective Date/Time) If IN1-12 is null, we will assign it the current date. IN1-13 (Plan Expiration Date/Time) If IN1-13 < IN1-12, no further processing will be done for this IN1 segment. In addition, no changes will be made to the patient’s existing Pat_Pay record(s) with the matching priority. IN1-2.1 (Insurance Plan ID – Identifier) IN1-2.1 uniquely identifies a matching Payer in the MOSAIQ database. If no match is found, we will conditionally attempt to add a Payer based on the “Auto Payer Insert” setting in the interface configuration. When inserting a Payer, IN1-4 is required. If we are not able to find a matching Payer and do not insert a new Payer automatically, no further processing will be done for this IN1 segment. In addition, no changes will be made to the patient’s existing Pat_Pay record(s) with the matching priority.




Page 126

Step Short Description Detailed Description 4 Set Expiration Processing

NOTE: Expiration refers to setting the Expiration Date of a Current Pat_Pay record to the current date – 1 day.

Set expiration processing will only be performed if the HL7 message contains at least one IN1 segment. Once steps 1 – 3 have completed, we will have a set of validated and prioritized IN1 segments for processing. The next step is to determine whether any of the patient’s Current Pat_Pay records should be expired because there is no corresponding IN1 segment. We will compare the set of IN1 segments to the set of Current Pat_Pay records for the patient to determine if there are any records to be marked as expired. Any Current record for which there is no IN1 segment with a matching priority and effective/expiration date range that includes the current date will be marked expired. NOTE: At least one IN1 segment must be included in the message for Set Expiration Processing to occur. If you wish to remove all Current Pat_Pay records, please see section 12.14.1.2 “IN1 Special Cases (Inbound Interface Manager (IIM) ADT Interface)”.

5 Priority Comparison processing

Each IN1 segment will be compared against the Current Pat_Pay record with matching priority. • If they are identical, processing is complete. • Otherwise, further analysis will be done to identify if additional action is required. The actions include:

1. Updating the matching Pat_Pay record. 2. Expiring the matching Pat_Pay record(s). 3. Inserting a new Pat_Pay record.

Further detail is provided in section 0 Priority Comparison Processing.

12.14.1.1.1 Repeating IN1 Limits

Only the first 5 IN1 segments within the message will be processed. Others will be ignored. The following table provides an example of repeating IN1 limit processing.

IN1 Segment Order IN1-2.1 Insurance Plan ID IN1-4 Insurance Company Name

Validation Details

1 INS-1 Insurance Co 1 Will be processed.




Page 127

2 INS-2 Insurance Co 2 Will be processed. 3 INS-3 Insurance Co 3 Will be processed. 4 INS-4 Insurance Co 4 Will be processed. 5 INS-5 Insurance Co 5 Will be processed. 6 INS-6 Insurance Co 6 Ignore. Only the first 5 IN1 segments will be processed. 7 INS-7 Insurance Co 7 Ignore. Only the first 5 IN1 segments will be processed.

12.14.1.1.2 IN1 Prioritization

MOSAIQ supports priorities from 1 to 99. If the first 5 IN1 segments contain unique values for IN1-22 in the range of 1 to 99 we will use those values. Otherwise, we will reassign the priorities for those segments as 1 – 5 based on the order they appear in the message. The following tables provide examples for IN1 prioritization. The “Assigned Priority” column indicates the priority that will be associated with each IN1 segment. Table 1: Assigned Priority is based on IN1-22 when each IN1 segment contains a unique value in the range of 1 – 99.

IN1 Segment Order IN1-2.1 Insurance Plan ID

IN1-4 Insurance Company Name

IN1-22 Priority Assigned Priority

1 INS-1 Insurance Co 1 1 1 2 INS-2 Insurance Co 2 3 3 3 INS-3 Insurance Co 3 4 4 4 INS-4 Insurance Co 4 5 5 5 INS-5 Insurance Co 5 2 2

Table 2: Assigned Priority is based on IN1 segment order when one or more of the IN1-22 values are null.




1 INS-1 Insurance Co 1 1 2 INS-2 Insurance Co 2 3 2 3 INS-3 Insurance Co 3 4 3 4 INS-4 Insurance Co 4 4 5 INS-5 Insurance Co 5 2 5




Page 128

Table 3: Assigned Priority is based on IN1 segment order when one or more of the IN1-22 values are not in the range of 1 – 99.




1 INS-1 Insurance Co 1 5 1 2 INS-2 Insurance Co 2 2 2 3 INS-3 Insurance Co 3 1 3 4 INS-4 Insurance Co 4 100 4 5 INS-5 Insurance Co 5 101 5

12.14.1.1.3 IN1 Validation

An IN1 segment must be validated before it can be processed. The fields to be validated are:

• IN1-12 (Plan Effective Date/Time). If this field is null we will assign it the current date.

• IN1-13 (Plan Expiration Date/Time). This field is valid except for the following conditions: o IN1-13 < IN1-12 (Plan Effective Date/Time)

• IN1-13 (Plan Expiration Date/Time). o IN1-13 < current date. (We will update the existing matching insurance.)

• IN1-2.1 (Insurance Plan ID – Identifier). This field is valid except for the following conditions: o No matching Payer based on IN1-2.1 and either:

IN1-4 is null or “Auto Payer Insert” is not checked in the interface configuration

The tables below show examples of the IN1 segments received in a message and the validation of these segments. Table 1: IN1-13 (Plan Expiration Date/Time) validation assuming the current date is February 2, 2009.

IN1 Segment

Order

IN1-2.1 Insurance Plan

ID


IN1-12 Effective Date

IN1-13 Expiration

Date

Validation Details

1 INS-1 Insurance Co 1 1/1/09 Null Valid 2 INS-2 Insurance Co 2 1/1/08 12/31/09 Valid




Page 129

IN1 Segment

Order


ID



IN1-13 Expiration

Date

Validation Details

3 INS-3 Insurance Co 3 1/1/09 6/1/08 Invalid. IN1-13 < IN1-12. 4 INS-4 Insurance Co 4 1/1/08 1/31/09 Valid. IN1-13 < current date of Feb 2, 2009.

NOTE: IN1-13 will be changed to 1/31/09 5 INS-5 Insurance Co 5 Null Null Valid.

NOTE: IN1-12 will be changed to 2/2/09.

Table 2: IN1-2.1 (Insurance Plan ID) validation (assuming ADT Interface setting “Auto Payer Insert” is checked)

IN1 Segment

Order


ID

IN1-4 Insurance Company

Name

Matching Insurer (Payer via Ext_ID lookup) Exists in

MOSAIQ DB

Validation Details

1 INS-1 Insurance Co 1 Yes Valid 2 INS-2 Yes Valid 3 INS-3 No Ignore this IN1 segment.

No matching Payer was found via Ext_ID lookup. New Payer record will not be inserted because IN1-4 is null.

4 INS-4 Insurance Co 4 No Valid No matching Payer was found via Ext_ID lookup. New Payer record will be inserted because “Auto Payer Insert” is checked.

Table 3: IN1-2.1 (Insurance Plan ID) validation (assuming ADT Interface setting “Auto Payer Insert” is not checked)

IN1 Segment

Order


ID


Name


MOSAIQ DB

Validation Details

1 INS-1 Insurance Co 1 Yes Valid




Page 130

IN1 Segment

Order


ID


Name


MOSAIQ DB

Validation Details

2 INS-2 Yes Valid 3 INS-3 No Ignore this IN1 segment.

No matching Insurer (Payer) because “Auto Payer Insert” is not checked. 4 INS-4 Insurance Co 4 No Ignore this IN1 segment.

No matching Insurer (Payer) because “Auto Payer Insert” is not checked.

12.14.1.1.4 Set Expiration Processing

Set expiration processing compares the set of Current Pat_Pay records to the set of IN1 segments. Any Current Pat_Pay record for which there is no IN1 segment with a matching priority and Effective-Expiration date range that includes the current date will be marked expired. At least one IN1 segment must be present to perform set expiration processing. NOTE: If an IN1 segment is invalid, any Current Pat_Pay record with that priority will remain unchanged. The following analysis assumes the current date is February 2, 2009. Table 1: Current Pat_Pay records before Set Expiration Processing

Priority Insurer Effective Date Expiration Date

1 INS-1 1/1/09 Null 2 INS-2 1/1/08 Null 3 INS-3 6/1/08 Null 4 INS-4 1/1/09 Null 5 INS-5 1/1/08 Null

Table 2: IN1 Segments

Priority IN1-2.1 Insurance Plan ID

IN1-12 Effective Date IN1-13 Expiration Date Details

1 INS-1 1/1/09 Null




Page 131

Priority IN1-2.1 Insurance Plan ID

IN1-12 Effective Date IN1-13 Expiration Date Details

3 INS-3 6/1/09 Null Effective Date > Current Date. 4 INS-4 1/1/09 Null 5 INS-5 1/1/08 12/31/08 Expiration Date < Current Date.

Table 3: Pat_Pay records after Set Expiration Processing

Priority Insurer Effective Date Expiration Date Details 1 INS-1 1/1/09 Null No change. 2 INS-2 1/1/08 2/1/09 No IN1 segment for priority = 2.

Set Expiration Date to current date – 1 day. 3 INS-3 6/1/08 Null No change. 4 INS-4 1/1/09 Null No change. 5 INS-5 1/1/08 12/31/08 The IN1 segment with matching priority will be updated.

12.14.1.1.5 Priority Comparison Processing

The following rules apply when comparing IN1 segments to Pat_Pay records:

• Only Pat_Pay records with Payer_Type = General will be part of the comparison set. • The initial comparison will be between the IN1 segment and the Current Pat_Pay record with matching priority. Subsequent comparisons may be

needed against all Active Pat_Pay records with matching priority. • Within an IN1 segment there are multiple fields that we import into Pat_Pay records. However, only certain fields are considered key fields. When

doing comparisons, any changes to the key fields for a given priority will cause a conflict with the Current Pat_Pay record. When we detect a conflict, we will attempt to resolve the conflict by expiring the older record and adding a new record. However, there may be times when the conflict cannot be automatically resolved. In such a case we will mark the older record as Conflict. If a change occurs to one of the non-key fields we will update the Current Pat_Pay record. These key fields include:

o IN1-2.1 (Insurance Plan ID) o IN1-8 (Group Number) o IN1-12 (Plan Effective Date). This field is only in conflict if it is < the Effective date of the Current Pat_Pay record. o IN1-36 (Policy Number)




Page 132

Within MOSAIQ a patient can have multiple Pat_Pay records with the same or different priorities. For a given priority, records cannot have an overlap between their Effective – Expiration date ranges. The following table shows a typical historical view of Active Pat_Pay records for a patient. Row # Priority Insurer Effective

Date Expiration

Date Details

1 1 INS-1 1/1/06 12/31/06 INS-1 was the patient’s primary insurer for 2006 2 1 INS-2 1/1/07 12/31/07 INS-2 was the patient’s primary insurer for 2007 3 1 INS-3 1/1/08 Null INS-3 is the patient’s primary insurer starting in 2008 and has no expiration date 4 5 2 INS-B 1/1/06 Null INS-3 is the patient’s secondary insurer starting in 2006 and has no expiration date

For each IN1 segment in the message the following steps will be performed.

♦ Step 1: Compare the IN1 segment to the Current Pat_Pay record with the matching priority. ♦ If no matching record exists, insert a new Pat_Pay record and processing is complete for the IN1 segment. ♦ If there is no overlap between the Pat_Payer and IN1 Effective-Expiration date ranges, insert a new Pat_Pay record and processing is complete

for the IN1 segment. ♦ If they are identical, no change is required and processing is complete for the IN1 segment. ♦ If any of the Key data is different goto Step 2. ♦ If only non-Key data has changed goto Step 3.

♦ Step 2: At this point we’ve identified a conflict that we will attempt to auto-resolve. The following actions will be performed: ♦ Insert a new Pat_Pay record with the IN1 contents. ♦ The new record will be compared to all Active records with matching priority. If there are any overlaps in the Effective – Expiration date range,

we will attempt to auto-resolve the conflict by resetting the Expiration Date of the older record. If auto-resolving isn’t possible, the record will be marked as Conflict.

♦ Processing is now complete for the IN1 segment. ♦ Step 3: At this point we’ve identified a change to non-Key data. The following actions will be performed:




Page 133

♦ Update the Current Pat_Pay record with the contents from the IN1 segment. NOTE: The update will not include IN1-12 (Effective Date) since the Current Pat_Pay record Effective Date <= IN1-12.

NOTE: Auto-resolving a conflict refers to changing the Expiration Date of an Active Pat_Pay record so there is no overlap of Effective – Expiration date ranges for Pat_Pay records for a particular patient for each priority. Auto-resolving is done since we do not always receive IN1 segments with Effective and Expiration dates. The following pages provide examples of the priority comparison processing. No example is provided for when the IN1 and Pat_Pay are identical since no database changes will take place. The examples assume the current date is February 2, 2009. 12.14.1.1.5.1 Example 1: New Insurer Overlaps with Date Range of Current Pat_Pay record (Auto-Resolve)

This example shows a typical scenario. A patient has multiple Active Pat_Pay records with Priority = 1 and non-overlapping date ranges. The patient’s primary insurer has changed at the start of a new year. A message with an IN1 segment for the new insurer is received with an Effective date = 1/1/09. While processing the IN1 segment we identify a conflict between Key data in the IN1 segment and the Current Pat_Pay record. We auto-resolve the Current Pat_Pay record by setting the Expiration Date to 12/31/08 (the new IN1 Effective Date – 1 day). We also insert a new Pat_Pay record based on the contents in the IN1 segment. Table 1 shows the IN1 segment data of interest. Table 2 shows the priority 1 Pat_Pay records for the patient before and after processing the message. Table 1: IN1 Segment with priority = 1

Priority IN1-2.1 Insurance Plan

ID


IN1-13 Expiration

Date

IN1 Other Mapped Data

Details

1 INS-3 1/1/09 Null C New priority 1 insurer starting 1/1/09.

Table 2: Pat_Pay records with priority = 1 Before / After

Before After Priority Insurer Effective

Date Expiration

Date Other Data

Priority Insurer Effective Date

Expiration Date

Other Data

Status Details

1 INS-1 Null 12/31/07 A 1 INS-1 Null 12/31/07 A No Conflict

No change

1 INS-2 1/1/08 Null or > current date

B 1 INS-2 1/1/08 12/31/08 B No Conflict

Conflict identified with IN1 segment. Auto-resolve




Page 134


Date Expiration

Date Other Data


Expiration Date

Other Data

Status Details

conflict by setting Expiration Date to new IN1 Effective Date – 1 day.

1 INS-3 1/1/09 Null C No Conflict

New record inserted.

NOTE: The Insurer changed in this example. However, the same processing occurs whether the Insurer changed or not. The key to this example is that the Effective date has changed.

12.14.1.1.5.2 Example 2: Update to Key data other than IN1-12 (Effective Date) – (Conflict)

This example shows a non-typical scenario. A patient has multiple Active Pat_Pay records with Priority = 1 and non-overlapping date ranges. Some Key data other than the Effective date in the patient’s primary insurer has changed. A message with an IN1 segment for the insurer is received. While processing the IN1 segment we identify a conflict between the Key data in the IN1 segment and the Current Pat_Pay record. We are not able to auto-resolve the conflict because the Effective date has not changed. Therefore, we mark the current Pat_Pay record as Conflict. We also insert a new Pat_Pay record based on the contents in the IN1 segment. Table 1 shows the IN1 segment data of interest. Table 2 shows the priority 1 Pat_Pay records for the patient before and after processing the message. Table 1: IN1 Segment with priority = 1


ID


IN1-13 Expiration

Date

IN1 Key Data

Details

1 INS-2 1/1/08 Null C Update to INS-2 Key data, but not IN1-12 (Effective Date).



Date Expiration

Date Key

Data Priority Insurer Effective

Date Expiration

Date Key

Data Status Details


No change




Page 135


Date Expiration

Date Key

Data Priority Insurer Effective

Date Expiration

Date Key

Data Status Details

1 INS-2 1/1/08 Null B 1 INS-2 1/1/08 B Conflict Conflict identified with IN1 segment. Auto-resolve not possible, because change was not to IN1-12.

1 INS-2 1/1/08 C No Conflict


NOTE: The Key data changed in this example. Key data for this example includes changes to any of the following:

• IN1-2.1 (Insurance Plan ID) • IN1-8 (Group Number) • IN1-36 (Policy Number)

The key to this example is that although there was a change, the Effective date has not changed. Therefore, no auto-resolving is possible.

12.14.1.1.5.3 Example 3: New Insurer Overlaps with Expiration Date of Multiple Pat_Pay records (Multiple Conflicts)

This example shows a non-typical scenario. A patient has multiple Active Pat_Pay records with Priority = 1, but with non-overlapping date ranges. The patient’s primary insurer has changed. A message with an IN1 segment for the new insurer is received with an Effective date = 1/1/06 (conflicts with multiple Pat_Pay records). While processing the IN1 segment we identify a conflict between the new IN1 data and multiple Pat_Pay records. We are not able to auto-resolve any Pat_Pay record because the IN1 Effective Date is prior to the Effective Date of the Pat_Pay records. Therefore, we mark each of the existing Pat_Pay records as Conflict. We also insert a new Pat_Pay record based on the contents in the IN1 segment. Table 1 shows the IN1 segment data of interest. Table 2 shows the priority 1 Pat_Pay records for the patient before and after processing the message.




Page 136

Table 1: IN1 Segment with priority = 1


ID


IN1-13 Expiration

Date

IN1 Other Mapped Data

Details

1 INS-3 1/1/06 Null C New priority 1 insurer starting 1/1/06.



Date Expiration

Date Other Data


Expiration Date

Other Data

Status Details

1 INS-1 Null 12/31/07 A 1 INS-1 Null 12/31/07 A Conflict Conflict identified with IN1 segment. Overlap in date range. Unable to auto-resolve conflict.

1 INS-2 1/1/08 Null B 1 INS-2 1/1/08 Null B Conflict Conflict identified with IN1 segment. Overlap in date range. Unable to auto-resolve conflict.

1 INS-3 1/1/06 Null C No Conflict





Page 137

12.14.1.1.5.4 Example 4: Update to non-Key data (No Conflict – Update Pat_Pay record)

This example shows another typical scenario. A patient has multiple Active Pat_Pay records with Priority = 1 and non-overlapping date ranges. Some non-Key data in the patient’s primary insurer has changed. A message with an IN1 segment for the insurer is received. While processing the IN1 segment we identify a difference between the non-Key data in the IN1 segment and the Current Pat_Pay record. Since this difference is only to non-Key data we simply update the Current Pat_Pay record with the data from the IN1 segment. Table 1 shows the IN1 segment data of interest. Table 2 shows the priority 1 Pat_Pay records for the patient before and after processing the message. Table 1: IN1 Segment with priority = 1


ID


IN1-13 Expiration

Date

IN1 Non-Key Data

Details

1 INS-2 1/1/08 Null C Update to INS-2 Key data, but not IN1-12 (Effective Date).



Date Expiration

Date Non-Key

Data


Expiration Date

Non-Key

Data

Status Details


No change

1 INS-2 1/1/08 Null B 1 INS-2 1/1/08 C No Conflict

Difference identified with non-Key data in IN1 segment. Update Current Pat_Pay record with new non-Key data in IN1 segment.

NOTE: Only the non-Key data changed in this example. Therefore, a new record was not inserted and there was no need to auto-resolve or mark an existing Pat_Pay record as Conflict.




Page 138

12.14.1.2 IN1 Special Cases (Inbound Interface Manager (IIM) ADT Interface)

The IN1 Processing Rules section identified the standard set of IN1 processing. This section covers special case handling and provides more details into certain aspects of IN1 processing. The following table provides details for each of the special cases.

Case Short Description Detailed Description 1 Expiring a single Current

Pat_Pay record

NOTE: Expiring refers to setting the Expiration Date to the current date – 1 day.

In addition to Set Expiration Processing defined in section 12.14.1.1.4, there is another way to explicitly expire a matching Current Pat_Pay record. Send in a message with an IN1 segment for the appropriate priority. Be sure that IN1-2.1 is the matching ID and that both IN1-3 and IN1-4 have the value ””. Here is an example: IN1||ESI-ID1|””|””|… NOTE: IN1 Prioritization is calculated as described in section 12.14.1.1.2.

2 Expiring all Current Pat_Pay records

If you wish to expire all Current Pat_Pay records you can send in a message with a single IN1 segment with IN1-2 and IN1-3 = ””. Here is an example: IN1||””|””… NOTE: This is following the means described in HL7 documentation for "delete all of the segments in this repeating group" in the snapshot mode. When present in this form, we expect this to be the only IN1 segment in the message. If other IN1 segments are present we will ignore them.

3 Creation of Guarantor If no Pat_Pay records exist for a Patient, when we first add a Pat_Pay record for an IN1 segment we will also add an additional Pat_Pay record to represent the patient’s Guarantor if an existing Payer in MOSAIQ is configured with “Use as Default Guarantor”.

NOTE: If a GT1 segment is present in the message then it will be used for populating the patient’s default guarantor record.

4 Creation of Carve-Out Payers

Primary Insurance records can have an associated CARVE-OUT Payer. When inserting a new Primary (Pat_Pay.priority = 1) Pat_Pay record we will also insert a new CARVE-OUT Pat_Pay record if the Payer associated with the Primary Pat_Pay record has an associated CARVE-OUT Payer.




Page 139

IN1 Processing Details (ESI:Manager ADT Processing) Prioritization of IN1 records is based first on IN1-22 (Coordination of Benefits Priority) and then on physical order of the IN1 records within the HL7 message. Except for the processing of HL7 event code P03 messages, the Insurance Company must exist in the MOSAIQ system prior to receipt of a Patient Accounting message. This can be accomplished by either using locally defined message Insurance Add/Update/Delete (Z02) or manual data entry. Data within the IN1 records will be added / updated to conform to the rules used to manually enter data in MOSAIQ as follows:

♦ Instead of importing (adding) records to the system in “snap-shot” mode, MOSAIQ attempts to update existing insurance records to match the snap-shot coming in by setting the effective/expiration dates as available in the imported data.

♦ Regardless of whether aCOUNT is installed or not, MOSAIQ brings the imported information in as the current information to the best of its ability. If conflicts exist, the incoming data comes in as the current information and all existing records that conflict with that new record will have their respective “Conflict” flag set.

♦ A conflict will be considered to have occurred if any record being imported could not be manually added to the system through the UI. ♦ If a “DELETE” message is received, look for a match with an existing record. If found check whether that record was used. If so, set the “Void” flag. If

not and the current date falls within the effective date range, delete the record. ♦ If a “DELETE ALL” message is received, look for all records which do not have the “Void” or “Conflict” flag set. For each record found that WAS used,

set the “Void” flag; otherwise if it was NOT used and the current date falls within the effective date range, delete the record.

IN1 Outbound Processing Details For outbound interfaces, one IN1 segment is built for each of the patient’s insurance records where the insurance is not expired and not voided. The records must pass these rules: ((filter_dttm >= pat_pay.effectvie_dttm) and (filter_dttm <= pat_pay.expiration_dttm) or

(filter_dttm >= pat_pay.effectvie_dttm) and (pat_pay.expiration_dttm is null)) and pat_pay.inactive <> 2 For Lab orders outbound, the filter_dttm is order.start_dttm For Pharmacy orders outbound: filter_dttm is order.start_dttm For ADT outbound: filter date is trigger_dttm




Page 140

12.15 MRG – Merge Segment The MRG segment provides information necessary to initiate the merging of patient data.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 20 CX R Y Prior Patient ID IDT:IDA or IDT:IDB

File | Demographics Tab – Name/IDs Fields – For import, either of the first two fields in the ID group box. For export, any of the six fields.

2 1 CX O Y Prior Alternate Patient ID MAPPABLE File | Demographics Tab – Name/IDs Fields – For import, any of the six fields in the ID group box except the first. For export, any of the six fields.

3 20 CX O N Prior Patient Account Number

MAPPABLE File | Demographics Tab – Name/IDs Fields – For import, any of the six fields in the ID group box except the first. For export, any of the six fields.

4 16 CX O N Prior Patient ID – External

MAPPABLE File | Demographics Tab – Name/IDs Fields – For import, any of the six fields in the ID group box except the first. For export, any of the six fields.

5 15 CX O N Prior Visit Number MAPPABLE File | Demographics Tab – Name/IDs Fields – For import, any of the six fields in the ID group box except the first. For export, any of the six fields.

6 20 CX O N Prior Alternate Visit ID * 7 48 XPN O N Prior Patient Name *

MRG Field Notes * This field is not used by MOSAIQ ESI. MAPPABLE: MOSAIQ maintains six patient ID fields, referred to as IDA, IDB, IDC, IDD, IDE and IDF. You can map these IDs to specific fields in the PID

and PV1 HL7 segments. In addition to these fields being mappable, MOSAIQ assigns effective date ranges to each set of IDs. For inbound interfaces, MOSAIQ creates a new set of IDs when changes are detected.




Page 141

12.16 MSA – Message Acknowledgment Segment The MSA segment contains information sent while acknowledging another message.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 2 ID R N 0008 Acknowledgment Code “AA” or “AE” or “AR”

NA

2 20 ST R N Message Control ID MSH-10 (HL7 mapping. See below.)

NA

3 80 ST O N Text Message See below. NA 4 15 NM O N Expected Sequence Number* 5 1 ID O N 0102 Delayed Acknowledgment Type*

MSA Field Notes * This field is not used by MOSAIQ ESI.

1. “Acknowledgment code”: Values are AA - Application Accept; AR - Application Reject; AE - Application Error. 2. “Message control ID”: This is the ID of the message sent by the sending system. It allows the sending system to associate this response with the message

for which it is intended. 3. “Text message”: An optional text field that further describes an error condition. This text may be printed in error logs or presented to an end user.




Page 142

12.17 MSH – Message Header Segment (Mapping for Outbound Interface Manager) The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME


Outbound Interface Manager Application Mapping

1 1 ST R N Field Separator edd:definition Interface | Properties Tab – Message Configuration Fields – Field Separator

2 4 ST R N Encoding Characters

edd:definition Interface | Properties Tab – Message Configuration Fields – Component Separator, Repetition Char, Escape Character and Sub Component

3 15 ST O N Sending Application

edd:definition Interface | Properties Tab – Message Configuration Fields – Sending Application

4 20 ST O N Sending Facility edd:definition Interface | Properties Tab – Message Configuration Fields – Sending Facility

5 15 ST O N Receiving Application

edd:definition Interface | Properties Tab – Message Configuration Fields – Receiving Application

6 30 ST O N Receiving Facility edd:definition Interface | Properties Tab – Message Configuration Fields – Receiving Facility

7 19 TS O N Date / Time Of Message

System Time

8 40 ST O N Security* 9 7 ID R N 0076 Message Type ORM^O01 for Lab Orders and

Pharmacy Orders ADT^A04 for ADT

N/A

10 20 ST R N Message Control ID

dst:message_control_id Interface Status Tab – Detailed Processing Column – Message Control ID




Page 143

SEQ

LEN

TYPE

R/O

REP

TBL

NAME


Outbound Interface Manager Application Mapping

11 1 ID R N 0103 Processing ID edd:definition Interface | Properties Tab – Message Configuration Fields – Processing ID

12 8 NM R N 0104 Version ID edd:definition Interface | Properties Tab – Message Configuration Fields – HL7 Version

13 15 NM O N Sequence Number* 14 180 ST O N Continuation

Pointer*

15 2 ID O N 0155 Accept Acknowledgment Type*

16 2 ID O N 0155 Application Acknowledgment Type*

17 2 ID O N Country Code*

18 6 ID O Y/3 0211 Character Set*

19 60 CE O N Principal Language Of Message*

MSH Field Notes * This field is not used by MOSAIQ ESI.

1. “Field separator”: This is the separator between the segment ID and the first real field, the 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. This field is configurable. Recommended value is "|".

2. “Encoding characters”: The four characters are the component separator, the repetition separator, the escape character, and the sub-component separator. This field is configurable. Recommended values are "^~\&".

3. “Sending application”: This field is available for interface with lower level protocols. This field is configurable. 4. “Sending facility”: Used to address one of several occurrences of the same application within the sending system. Aside from other consideration, the

Medicare Provider ID might be used with an appropriate sub-identifier in the second subfield. This field is entirely site-defined and configurable. 5. “Receiving application”: This field is available for interface with lower level protocols. This field is configurable.




Page 144

6. “Receiving facility”: Used to identify the receiving application among multiple identical incarnations of the application running on behalf of different organizations. This field is configurable.

7. “Date / time of message”: The date/time that the message was created. 9. “Message type”: Tells the receiving system the contents of the message, and hence the data segments to recognize, and the application to which to route

the message. Valid types are defined in subsequent sections of this document. 10. “Message control ID”: A number or other identifier that uniquely identifies the message. This value will be generated for outbound interfaces. 11. “Processing ID”: Values are P-Production; T-Training; D-Debugging. 12. “Version ID”: This field is configurable.




Page 145

12.18 MSH – Message Header Segment (Mapping for Inbound Interface Manager Lab Results Interface) The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 1 ST R N Field Separator 2 4 ST R N Encoding Characters 3.1 15 ST O N Sending

Application/NamespaceID

eii.sending_application obr.sending_application

N/A

3.2 20 ST O N Sending Application/UniversalID1

obr.sending_application_uid N/A

3.3 20 ST O N Sending Application/UniversalIDType1

obr.sending_application_auth N/A

4.1 50 ST O N Sending Facility/NamespaceID

eii.sending_facility obr.sending_ facility

N/A

4.2 20 ST O N Sending Facility/UniversalID1

obr.sending_ facility_uid N/A

4.3 20 ST O N Sending Facility/UniversalIDType1

obr.sending_ facility_auth N/A

5 15 ST O N Receiving Application *

6.1 30 ST O N Receiving Facility/NamespaceID

N/A – Used for lookup in ObsDef for HL7 Translation Code Mapping.

N/A

6.2 20 ST O N Receiving Facility /UniversalID1

obr.receiving_ facility_uid N/A

6.3 20 ST O N Receiving Facility /UniversalIDType1

obr.receiving_ facility_auth N/A

7 19 TS O N Date / Time Of Message *




Page 146

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



8 40 ST O N Security* 9 7 ID R N 0076 Message Type

10 20 ST R N Message Control ID EII. Message_Control_ID N/A 11 1 ID R N 0103 Processing ID * 12 8 NM R N 0104 Version ID * 13 15 NM O N Sequence Number* 14 180 ST O N Continuation

Pointer*




18 6 ID O Y/3 0211 Character Set*


MSH Field Notes * This field is not used by MOSAIQ ESI. 1 This field is available by default only in the inbound HL7 2.5 LRI template

1. “Field separator”: This is the separator between the segment ID and the first real field, the 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. This field is configurable. Recommended value is "|".

2. “Encoding characters”: The four characters are the component separator, the repetition separator, the escape character, and the sub-component separator. This field is configurable. Recommended values are "^~\&".

3. “Sending application”: This field is available for interface with lower level protocols. This field is configurable. 4. “Sending facility”: Used to address one of several occurrences of the same application within the sending system. Aside from other consideration, the

Medicare Provider ID might be used with an appropriate sub-identifier in the second subfield. This field is entirely site-defined and configurable.




Page 147

6. “Receiving facility”: Used to identify the receiving application among multiple identical incarnations of the application running on behalf of different organizations. This field is configurable.

7. “Date / time of message”: The date/time that the message was created. 9. “Message type”: Tells the receiving system the contents of the message, and hence the data segments to recognize, and the application to which to route

the message. Valid types are defined in subsequent sections of this document. 10. “Message control ID”: A number or other identifier that uniquely identifies the message. This value will be generated for outbound interfaces. 11. “Processing ID”: Values are P-Production; T-Training; D-Debugging. 12. “Version ID”: This field is configurable.




Page 148

12.19 MSH – Message Header Segment (Mapping for ESI Manager and Charge Export) The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 1 ST R N Field Separator No mapping available PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Field Separator


No mapping available PRF:Preference_Str File | Import/Export | HL7 Code Export… Change pushbutton Tab – MSH Segment Fields – Component Separator, Repetition Char, Sub Component


NA

PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Sending Application

4 20 ST O N Sending Facility NA PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Sending Facility


PRF:Preference_Str

PRF:Preference_Str For Import File | Import/Export | ESI Manager… ESI Cfg pushbutton Tab – Inbound Fields – Receiving Application For Export File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Receiving Application

6 30 ST O N Receiving Facility

PRF:Preference_Str

PRF:Preference_Str For Import File | Import/Export | ESI Manager…




Page 149

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



MOSAIQ Application Mapping ESI Cfg pushbutton Tab – Inbound Fields – Receiving Facility For Export File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Receiving Facility


No mapping available System Time

8 40 ST O N Security* 9 7 ID R N 0076 Message Type No mapping available “DFT” NA 10 20 ST R N Message

Control ID No mapping available PRF:Preference_Str NA

11 1 ID R N 0103 Processing ID PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Processing ID

12 8 NM R N 0104 Version ID No mapping available PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – HL7 Version

13 15 NM O N Sequence Number*

14 180 ST O N Continuation Pointer*






Page 150

SEQ

LEN

TYPE

R/O

REP

TBL

NAME





18 6 ID O Y/3 0211 Character Set N/A OIM: Interface configuration

Properties | Outbound File Tab | Encoding selection


MSH Field Notes * This field is not used by MOSAIQ ESI. 1. “Field separator”: This is the separator between the segment ID and the first real field, the 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 "|". 2. “Encoding characters”: The four characters are the component separator, the repetition separator, the escape character, and the sub-component separator. Recommended values are "^~\&". Configurable for outbound interfaces. 3. “Sending application”: This field is available for interface with lower level protocols. 4. “Sending facility”: Used to address one of several occurrences of the same application within the sending system. Aside from other consideration, the Medicare Provider ID might be used with an appropriate sub-identifier in the second subfield. Entirely site-defined. 5. “Receiving application”: This field is available for interface with lower level protocols. 6. “Receiving facility”: Used to identify the receiving application among multiple identical incarnations of the application running on behalf of different organizations. See comments regarding Sending facility. 7. “Date / time of message”: The date/time that the sending system created the message. 8. “Security”: The use of this field has not yet been specified. In the future this field will be used to implement security features. 9. “Message type”: Tells MOSAIQ ESI the contents of the message, and hence the data segments to recognize, and the application to which to route the message. Valid types are defined in subsequent sections of this document. 10. “Message control ID”: A number or other identifier that uniquely identifies the message. The MOSAIQ ESI will echo this ID back to the sending system in the Message Acknowledgment for inbound interfaces. This value will be generated for outbound interfaces. 11. “Processing ID”: Values are P-Production; T-Training; D-Debugging. 12. “Version ID”: Currently not supported for inbound interfaces. Configurable for outbound interfaces.




Page 151

18. If encoding name can be mapped to an HL7-expected value, it is mapped, otherwise, the encoding name is used.

Standard Encoding Name

HL7 Mapped value

us-ascii ASCII

iso-8859-1 8859/1

iso-8859-2 8859/2

iso-8859-3 8859/3

iso-8859-4 8859/4

iso-8859-5 8859/5

iso-8859-6 8859/6

iso-8859-7 8859/7

EUC-JP ISO IR87

utf-16 UNICODE

Any other Encoding Name Encoding Name




Page 152

12.20 MSH – Message Header Segment (OIM:Syndromic Surveillance Interface) The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 1 ST R N Field Separator PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Field Separator

2 4 ST R N Encoding Characters PRF:Preference_Str File | Import/Export | HL7 Code Export… Change pushbutton Tab – MSH Segment Fields – Component Separator, Repetition Char, Sub Component

3 15 ST O N Sending Application NA



5 15 ST O N Receiving Application PRF:Preference_Str


6 30 ST O N Receiving Facility PRF:Preference_Str PRF:Preference_Str For Import




Page 153

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




File | Import/Export | ESI Manager… ESI Cfg pushbutton Tab – Inbound Fields – Receiving Facility For Export File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Receiving Facility


System Time

8 40 ST O N Security* 9 7 ID R N 0076 Message Type “ADTÂ03ÂDT_A03”, or

“ADTÂ04ÂDT_A01” NA

10 20 ST R N Message Control ID PRF:Preference_Str NA 11 1 ID R N 0103 Processing ID PRF:Preference_Str File | Import/Export | HL7 Code Export…

Change Button Tab – MSH Segment Fields – Processing ID

12 8 NM R N 0104 Version ID “2.5.1” NA 13 15 NM O N Sequence Number* 14 180 ST O N Continuation Pointer* 15 2 ID O N 0155 Accept

Acknowledgment Type*



18 6 ID O Y/3 0211 Character Set N/A OIM: Interface Properties | Outbound File Tab | Encoding




Page 154

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




configuration “8859/1” selection


20 20 ID O N 0356 Alternate Character Set Handling Scheme

N/A

21 427 EI O Y Message Profile Identifier

N/A “PH_SS-NoAck^SS Sender^2.16.840.1.114222.4.10.3^ISO”

MSH Field Notes * This field is not used by MOSAIQ ESI. 1. “Field separator”: This is the separator between the segment ID and the first real field, the 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 "|". 2. “Encoding characters”: The four characters are the component separator, the repetition separator, the escape character, and the sub-component separator. Recommended values are "^~\&". Configurable for outbound interfaces. 3. “Sending application”: This field is available for interface with lower level protocols. 4. “Sending facility”: Used to address one of several occurrences of the same application within the sending system. Aside from other consideration, the Medicare Provider ID might be used with an appropriate sub-identifier in the second subfield. Entirely site-defined. 5. “Receiving application”: This field is available for interface with lower level protocols. 6. “Receiving facility”: Used to identify the receiving application among multiple identical incarnations of the application running on behalf of different organizations. See comments regarding Sending facility. 7. “Date / time of message”: The date/time that the sending system created the message. 8. “Security”: The use of this field has not yet been specified. In the future this field will be used to implement security features. 9. “Message type”: Tells MOSAIQ ESI the contents of the message, and hence the data segments to recognize, and the application to which to route the message. Valid types are defined in subsequent sections of this document. 10. “Message control ID”: A number or other identifier that uniquely identifies the message. The MOSAIQ ESI will echo this ID back to the sending system in the Message Acknowledgment for inbound interfaces. This value will be generated for outbound interfaces. 11. “Processing ID”: Values are P-Production; T-Training; D-Debugging.




Page 155

12. “Version ID”: Currently not supported for inbound interfaces. Configurable for outbound interfaces. 18. If encoding name can be mapped to an HL7-expected value, it is mapped, otherwise, the encoding name is used.




Page 156

12.21 MSH – Message Header Segment (OIM: Immunization Export Interface) The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 1 ST R N Field Separator No mapping available PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Field Separator


No mapping available PRF:Preference_Str File | Import/Export | HL7 Code Export… Change pushbutton Tab – MSH Segment Fields – Component Separator, Repetition Char, Sub Component


NA




PRF:Preference_Str


6 30 ST O N Receiving Facility

PRF:Preference_Str

PRF:Preference_Str For Import File | Import/Export | ESI Manager…




Page 157

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



MOSAIQ Application Mapping ESI Cfg pushbutton Tab – Inbound Fields – Receiving Facility For Export File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Receiving Facility


No mapping available System Time

8 40 ST O N Security* 9 7 ID R N 0076 Message Type No mapping available “VXU^V04^VXU_V04” NA

10 20 ST R N Message Control ID

No mapping available PRF:Preference_Str NA

11 1 ID R N 0103 Processing ID PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – Processing ID

12 8 NM R N 0104 Version ID No mapping available PRF:Preference_Str File | Import/Export | HL7 Code Export… Change Button Tab – MSH Segment Fields – HL7 Version

13 15 NM O N Sequence Number*

14 180 ST O N Continuation Pointer*

15 2 ID R N 0155 Accept Acknowledgment Type*

“AL”

16 2 ID R N 0155 Application Acknowledgment Type*

“NE”




Page 158

SEQ

LEN

TYPE

R/O

REP

TBL

NAME





18 6 ID O Y/3 0211 Character Set N/A OIM: Interface configuration

Properties | Outbound File Tab | Encoding selection


MSH Field Notes * This field is not used by MOSAIQ ESI. 1. “Field separator”: This is the separator between the segment ID and the first real field, the 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 "|". 2. “Encoding characters”: The four characters are the component separator, the repetition separator, the escape character, and the sub-component separator. Recommended values are "^~\&". Configurable for outbound interfaces. 3. “Sending application”: This field is available for interface with lower level protocols. 4. “Sending facility”: Used to address one of several occurrences of the same application within the sending system. Aside from other consideration, the Medicare Provider ID might be used with an appropriate sub-identifier in the second subfield. Entirely site-defined. 5. “Receiving application”: This field is available for interface with lower level protocols. 6. “Receiving facility”: Used to identify the receiving application among multiple identical incarnations of the application running on behalf of different organizations. See comments regarding Sending facility. 7. “Date / time of message”: The date/time that the sending system created the message. 8. “Security”: The use of this field has not yet been specified. In the future this field will be used to implement security features. 9. “Message type”: Tells MOSAIQ ESI the contents of the message, and hence the data segments to recognize, and the application to which to route the message. Valid types are defined in subsequent sections of this document. 10. “Message control ID”: A number or other identifier that uniquely identifies the message. The MOSAIQ ESI will echo this ID back to the sending system in the Message Acknowledgment for inbound interfaces. This value will be generated for outbound interfaces. 11. “Processing ID”: Values are P-Production; T-Training; D-Debugging. 12. “Version ID”: Currently not supported for inbound interfaces. Configurable for outbound interfaces. 18. If encoding name can be mapped to an HL7-expected value, it is mapped, otherwise, the encoding name is used.




Page 159

12.22 NK1 – Next of Kin Segment The NK1 segment contains information about the patient’s other related parties. MOSAIQ ESI accepts up to three NK1 segments within transaction messages.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 4 SI R N Set ID - Next Of Kin See field note 1 below: 1”, “2” 2 48 XPN O Y Next Of Kin Name See NK1 Field Notes. File | Demographics • for Set_ID = 1 adm:kin_fname,

adm;kin_lname adm:kin_fname, adm;kin_lname

Tab – Relative Fields – Last Name, First

• for Set_ID = 2 adm:emg_fname, adm:emg_lname

adm:emg_fname, adm:emg_lname

Tab – Emergency Fields – Last Name, First

• for Set_ID = 3 adm:pat_employer

Tab – Home/Work Fields – Employer

3 60 CE O N 0063 Next Of Kin Relationship File | Demographics • for Set_ID = 1 adm:kin_relate adm:kin_relate Tab – Relative

Fields – Relationship • for Set_ID = 2 adm:emg_relate adm:emg_relate Tab – Emergency

Fields – Relationship 4 106 XAD O N Next Of Kin – Address File | Demographics • for Set_ID = 1 adm:kin_adr1,

adm:kin_adr2, adm:kin_city, adm:kin_state, adm:kin_postal, adm:kin_country

adm:kin_adr1, adm:kin_adr2, adm:kin_city, adm:kin_state, adm:kin_postal, adm:kin_country

Tab – Relative Fields – 1, 2, City, State, Postal, Country

• for Set_ID = 2 adm:emg_adr1, adm:emg_adr2, adm:emg_city, adm:emg_state adm:emg_postal adm:kin_country

adm:emg_adr1, adm:emg_adr2, adm:emg_city, adm:emg_state adm:emg_postal adm:kin_country

Tab – Emergency Fields – 1, 2, City, State, Postal, Country




Page 160

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




• for Set_ID = 3 adm:emp_adr1, adm:emp_adr2, adm:emp_city, adm:emp_state adm:emp_postal adm:emp_country

Tab – Employer Fields – 1, 2, City, State, Postal, Country

5 40 XTN O Y Next Of Kin – Phone Number Format: Uses only component 1 of XTN.

File | Demographics

• for Set_ID = 1 adm:kin_home_phone adm:kin_Cellphone adm:Emg_Cellphone (See Field Note 5 below)

adm:kin_home_phone, adm:kin_phone_ex

Tab – Relative Group Box – Relative’s Home Address/Phone Fields – Phone

• for Set_ID = 2 adm:emg_home_phone adm:emg_home_phone, adm:emg_phone_ex

Tab – Emergency Fields – Phone

• for Set_ID = 3 adm:emp_phone Tab – Home/Work Fields – Phone

6 40 XTN O Y Business Phone Number Format: Uses only component 1 of XTN.

File | Demographics

• for Set_ID = 1 adm:kin_work_phone

adm:kin_work_phone adm:kin_work_phone_ex

Tab – Relative Group Box – Relative’s Home Address/Phone Fields – Work, Ext

• for Set_ID = 2 adm:emg_work_phone adm:emg_work_phone, adm:emg_work_phone_ex

Tab – Emergency Fields – Work, Ext

7 60 CE O N 0131 Contact Role See NK1 Field Notes. 8 8 DT O N Start Date*




Page 161

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




9 8 DT O N End Date* 10 60 ST O N Next Of Kin/Associated Parties Job

Title* IIM ADT: Adm.Pat_Occupat

File|Demographics Tab – Home/work Fields – Occupation (below)

11 20 CM O N Next Of Kin/Associated Parties Employee Name*

12 20 CX O N Next Of Kin/Associated Parties Employee Number*

13 60 XON O Y 0327/ 0328

Organization Name*

14 2 IS O N 0002 Marital Status* 15 1 IS O N 0001 Sex* 16 26 TS O N Date/Time of Birth* 17 2 IS O Y 0223 Living Dependency* 18 2 IS O Y 0009 Ambulatory Status* 19 4 IS O Y 0171 Citizenship* 20 60 CE O N 0296 Primary Language* 21 2 IS O N 0220 Living Arrangement* 22 1 IS O N 0215 Publicity Indicator* 23 1 ID O N 0136 Protection Indicator* 24 2 IS O N 0221 Student Indicator* 25 3 IS O N 0006 Religion* 26 48 XPN O N Mother’s Maiden Name* 27 80 CE O N 0212 Nationality* 28 48 IS O N 0189 Ethnic Group* 29 40 CE O Y 0222 Contact Reason* 30 106 XPN O Y Contact Person’s Name* 31 32 XTN O Y Contact Person’s Telephone Number* 32 2 XAD O Y Contact Person’s Address* 33 1 CX O Y Associated Party’s Identifiers 34 2 IS O N 0311 Job Status*




Page 162

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




35 1 IS O N 0005 Race* 36 2 IS O N 0295 Handicap* 37 16 ST O N Contact Person Social Security Number*

NK1 Field Notes * This field is not used by MOSAIQ ESI. 1. “Set ID - next of kin”: This field uniquely identifies the NK1 records for the purpose of adding, changing, or deleting records. If supported by a particular

message, MOSAIQ ESI accepts up to two NK1 segment within transaction messages. The first is accepted as the relative information. The second is accepted as emergency contact. The remainder are ignored.

5. If any of the repeating values of NK1.5.3 = “CP” the phone number is added as cell phone 7. “Contact Role”: This field is used by the IIM ADT Inbound interface to map to either “N” (Next of Kin) or “C” (Emergency Contact) or “E” (Employer).

When no contact roles are defined, the first NK1 segment will be assigned Contact Role = “N” and the second NK1 segment will be assigned Contact Role = “C”. When the contact role for the first segment maps to Next-of-kin (Relative) and the contact role for the second segment does not have a value, it will be assigned Contact Role = “C”. Similarly when the contact role for the first segment does not have a value and the contact role for the second segment maps to “C” ” (Emergency Contact), the first segment will be assigned Contact Role = “N”. When the contact role for the second segment maps to Next-of-kin (Relative) and the first segment does not have a contact role defined and the message does not contain an NK1 segment with Contact Role = “C” the first NK1 segment will be assigned Contact Role = “C”. Similarly, when the contact role for the first segment maps to (Emergency Contact) and the second segment does not have a contact role defined and the message does not contain an NK1 segment with Contact Role = “C” the second NK1 segment will be assigned Contact Role = “N”. When both NK1 segments have contact roles and they don’t map to Next-of-kin (Relative) or Emergency Contact, we will ignore both of them. When a message has multiple NK1 segments containing a contact role of ‘N’ (Next of Kin) or “C” (Emergency Contact) or “E” (Employer) we will use the first and ignore the rest.

10. If the third NK1 segment holding Employer Information is imported ONLY if an Employer NK1 segment when a Contact role of “E” is defined in the segment

ESI:ADT – Accepts the first NK1 segment as the relative information. The second is accepted as emergency contact. The remainder is ignored. IIM ADT Processing for deletes of NK1: One or more NK1 segments each must have “” (Double quotes) in LastName, Relationship and Address1 and either null or "" in all other mapped fields




Page 163

12.23 NK1 – Next of Kin Segment (OIM: Immunization Export Interface) The NK1 segment contains information about the patient’s other related parties. For the Immunization Export interface an NK1 segment will be created if either the Relative Home or Emergency Contact is defined as the patient’s guardian.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 4 SI R N Set ID - Next Of Kin 1 2 48 XPN O Y Next Of Kin Name See NK1 Field Notes. File | Demographics • for Relative Home adm:kin_fname,

adm;kin_lname adm:kin_fname, adm;kin_lname

Tab – Contact Grid Row – Relative Home Fields – Last Name, First

• for Emergency Contact adm:emg_fname, adm:emg_lname

adm:emg_fname, adm:emg_lname

Tab – Contact Grid Row – Emergency Contact Fields – Last Name, First

3 60 CE O N 0063 Next Of Kin Relationship File | Demographics • for Relative Home adm:kin_relate adm:kin_relate Tab – Contact

Grid Row – Relative Home Fields – Relationship

• for Emergency Contact adm:emg_relate adm:emg_relate Tab – Contact Grid Row – Emergency Contact Fields – Relationship

4 106 XAD O N Next Of Kin – Address File | Demographics • for Relative Home adm:kin_adr1,

adm:kin_adr2, adm:kin_city, adm:kin_state, adm:kin_postal, adm:kin_country

adm:kin_adr1, adm:kin_adr2, adm:kin_city, adm:kin_state, adm:kin_postal, adm:kin_country

Tab – Contact Grid Row – Relative Home Fields – 1, 2, City, State, Postal, Country

• for Emergency Contact adm:emg_adr1, adm:emg_adr2,

adm:emg_adr1, adm:emg_adr2,

Tab – Contact Grid Row – Emergency Contact




Page 164

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




adm:emg_city, adm:emg_state adm:emg_postal adm:kin_country

adm:emg_city, adm:emg_state adm:emg_postal adm:kin_country

Fields – 1, 2, City, State, Postal, Country

5 40 XTN O Y Next Of Kin – Phone Number Format: Uses only component 1 of XTN.

File | Demographics

• for Relative Home adm:kin_home_phone adm:kin_home_phone, adm:kin_phone_ex

Tab – Contact Grid Row – Relative Home Fields – Home Phone

• for Emergency Contact adm:emg_home_phone adm:emg_home_phone, adm:emg_phone_ex

Tab – Contact Grid Row – Emergency Contact Fields – Home Phone

NK1 Field Notes None




Page 165

12.24 NTE – Note Segment The NTE segment is a common format for sending notes and comments.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 4 SI O N Set ID - Nte 1 1 NA 2 8 ID O N 0105 Source Of Comment* 3 ST O Y Comment nte:notes

For Schedule Inbound: SCH:Note_ID -> NTE:Notes or SCH:Notes See Field Notes below. For Requisition Inbound: NTE:Notes See Field Notes below

nte:notes or document For Schedule Outbound: SCH:Note_ID -> NTE:Notes + SCH:Notes For Lab Orders Outbound, concatenate: ORC:Condition, OBR:Condition For OIM Charge Export: CHG:Note_ID -> NTE:Notes

Patient Notes For Schedule Outbound/Inbound: Daily Master Schedule | Appointment Slip | (Click Note) | Text box for Note concatenated with Daily Master Schedule | Appointment Slip | Comment For Lab Orders Outbound: Observation Orders (ORC) Form Field – Comment Observation Order (OBR) Form Field – Comment For Charge Export: Patient Code Summary |(Click Charge) | (Click Note) | Text box for Note

NTE Field Notes * This field is not used by MOSAIQ ESI.




Page 166

Multiple supported HL7 event codes use the NTE segment.

For ESI:Lab Results Inbound, the data in NTE-3 is used to construct a Notes record in the database.

For ESI:Doc Inbound, the data in NTE-3 is used to construct a document.

For ESI: Schedule Outbound, the data in NTE-3 is a concatenation of the Appointment Slip Notes with the Appointment Slip Comment

For IIM: Schedule Inbound, when the data in NTE-3 is greater than 60 characters, it is saved in the Appointment Slip Notes. If it is less than or equal to 60 characters, it is stored as an Appointment Slip Comment.

For ESI:Lab Orders Outbound, the data in NTE-3 is a concatenation of the comment on the Observation Orders form and the comment in the Observation Order dialog box. If the user enters a multi-line comment (by pressing the Enter key), the interface will replace the CRLF in the text box with 2 spaces. The Observation Orders form Comment and the Observation Order dialog box Comment are concatenated together with 4 spaces in between.

For OIM:Charge Export, the data in NTE-3 comes from the Note field on the charge slip.

NTE:Notes – This column stores data in RTF format. On import, data must be converted to RTF. On export to NTE-3, the data is converted from RTF to plain text.




Page 167

12.25 OBR – Observation Request Segment In the reporting of clinical data, the OBR serves as the report header. It identifies the observation set represented by the following atomic observations. It includes the relevant ordering information when that applies. It contains many of the attributes that usually apply to all of the included observations. MOSAIQ maintains a “Status” field in OBR and its initial value is set to “Unreviewed”.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 4 ST R N Set ID - Observation Request No mapping available

2 75 EI O N Placer Order Number/EntityIdentifier obr:Placer_Order_Number obr.Result_ORC_Set_ID

None

3 15 EI O N Filler Order Number/ EntityIdentifier obr:filler_order eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Filler Order

4 200 CE R N Universal Service ID*/ Text obr:panel_name eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation

Field – Panel

5 2 ID O N Priority*

6 26 TS O N Request Date/Time*

7 26 TS O N Observation Date/Time obr:obs_dttm eChart | Laboratory Fields – Date, Time

8 26 TS O N Observation End Date/Time obr:obs_end_dttm eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Obs End At

9 20 CQ O N Collection Volume obr:collect_vol, eChart | Laboratory




Page 168

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



obr:collect_units Add pushbutton Info pushbutton Tab – Observation Field – Collect Volume

10 60 XCN O Y Collector Identifier obr:collector eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Collector

11 1 ID O N 0065 Specimen Action Code obr:spec_action eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Specimen Action

12 60 CE O N Danger Code obr:danger_code eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Danger Code

13 300 CM O N Relevant Clinical Information*

14 26 TS O N Specimen Received Date/Time obr:rcvd_dttm eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Received At

15 300 CM O N 0070 Specimen Source obr:spec_source eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Specimen Source




Page 169

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



16 80 XCN O Y Ordering Provider obr:ord_provider eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Order Provider

17 40 XTN O Y/2 Order Callback Phone Number*

18 60 ST O N Placer Field 1*


20 60 ST O N Filler Field 1 +*


22 26 TS O N Results Rpt/Status Change - Date/Time obr:results_dttm eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Results At

23 40 CM O N Charge To Practice +*

24 10 ID O N Diagnostic Serv Sect ID*

25 1 ID O N Result Status + obr:results_sts eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Results Status

26 200 CM O N Parent Result +*

27 200 TQ O Y Quantity/Timing*

28 150 XCN O Y/5 Result Copies To obr:results_cc1, obr:results_cc2, obr:results_cc3,

Only in database




Page 170

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



obr:results_cc4, obr:results_cc5

29 150 CM O N Parent Number *

30 20 ID O N 0124 Transportation Mode obr:transport eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Transportation

31 300 CE O Y Reason For Study obr:reason Only in database

32 200 CM O N Principal Result Interpreter + obr:results_pi eChart | Laboratory Status pushbutton Info pushbutton Tab – Results Field – Principal Interpreter

33 200 CM O Y Assistant Result Interpreter +*

34 200 CM O Y Technician +*

35 200 CM O Y Transcriptionist +*

36 26 TS O N Scheduled Date/Time + obr:sch_dttm Only in database 37 4 NM O N Number Of Sample Containers*

38 60 CE O Y Transport Logistics Of Collected*

39 200 CE O Y Collector’s Comment*

40 60 CE O N Transport Arrangement Responsibility*

41 30 ID O N 0224 Transport Arranged*

42 1 ID O N 0225 Escort Required* 43 200 CE O Y Planned Patient Transport Comment*




Page 171

OBR Field Notes * This field is not used by MOSAIQ ESI.

3. “Filler Order Number”: The permanent identifier for and order and its associated observations.

4. “Universal Service ID”: The text in OBR-4.2 is mapped to the “Panel Name” field in MOSAIQ.

7. “Observation Date/Time” : The clinically relevant date and time of the observation.

8. “Observation End Date/Time” : The end date and time of a study or timed specimen collection.

9. “Collection Volume” : For laboratory tests, the collection volume is the volume of a specimen in the form <quantity (NM)> ^ <units (CE) >. The default unit is ML. Specifically the units should be expressed in the ISO standard abbreviations (ISO-2955, 1977). The units value is mapped to Table 10000 (Unit of Measure) in ObsDef

10. “Collection Identifier” : When a specimen is required for a study, this field identifies the person, department, or facility that collected the specimen. Either name or ID code, or both, may be present.

11. “Specimen Action Code” : The action to be taken with respect to the specimens that accompany or precede this order. Refer to table 0065 – Specimen Action Code for values.

12. “Danger Code”: Refer to table 10001.

14. “Specimen Received Date/Time”: For observations requiring a specimen, the specimen received date/time is the actual login time at the diagnostic service.

15. “Specimen Source”: The site where the specimen should be obtained or where the service should be performed in the form: <specimen source name or code (CE)> ^ <additives (TX)> ^ <freetext (TX)> ^ <body site (CE)> ^ <site modifier (CE)> ^ <collection method modifier code (CE)>.

16. “Ordering Provider”: The provider who ordered the test. Either the ID code or the name, or both, may be present in the form: <ID number (ST)> ^ <family name (ST)> ^ <given name (ST)> ^ <middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source table (IS)> ^ <assigning authority (HD)> ^ <name type code(ID)> ^ <identifier check digit (ST)> ^ <code identifying the check digit scheme employed (ID )> ^ <identifier type code (IS)> ^ <assigning facility (HD)>.

22. “Results Rpt/Status Charge – Date/Time”: The date/time when the results were reported or status changed.


25. “Result Status”: This is a conditional field that is required whenever the OBR is contained in a report message. If the status is that of the entire order, use ORC-15-order effective date/time and ORC-5-order status. If the status pertains to the order detail segment, use OBR-25-result status and OBR-22-results report/status change - date/time. If both are present, the OBR values override the ORC values. Refer to HL7 table 0123 - Result status for valid entries.

28. “Result copies to”: Identifies the people who are to receive copies of the results. Either the name or the ID may be present.




Page 172

30. “Transportation Mode”: Identifies how to transport a patient, when applicable. Refer to HL7 table 0124 – Transportation mode for valid codes. 31. “Reason for Study”: The code or test in the form <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^

<alternate text (ST)> ^ <name of alternate coding system (ST)> 32. “Principal Result Interpreter”: Identifies the physician or other clinician who interpreted the observation and is responsible for the report content.

36. “Scheduled Date/Time”: The date/time the filler scheduled an observation.




Page 173

12.26 OBR – Observation Request Segment (For Inbound Lab Results Interface HL7 2.5) In the reporting of clinical data, the OBR serves as the report header. It identifies the observation set represented by the following atomic observations. It includes the relevant ordering information when that applies. It contains many of the attributes that usually apply to all of the included observations. MOSAIQ maintains a “Status” field in OBR and its initial value is set to “Unreviewed”.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




2.1 20 EI/ST O N Placer Order Number/EntityIdentifier obr:placer_order_number obr.result_orc_set_id

None

2.2 20 EI/ST O N Placer Order Number/UniversalID1 obr:placerordernumber_uid None

2.3 20 EI/ST O N Placer Order Number/UniversalIDType1 obr:placerordernumber_auth None

3.1 20 EI/ST O N Filler Order Number/ EntityIdentifier1 obr:filler_order eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Filler Order

3.3 20 EI/ST O N Filler Order Number/ UniversalID1 obr:filler_order_uid None

3.4 20 EI/ST O N Filler Order Number/ UniversalIDType1 obr:filler_order_Auth None

4.1 20 CWE O N Universal Service ID/ Identifier1 obr:panel_code eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation

Field – Panel

4.2 200 CWE R N Universal Service ID*/ Text obr:panel_name eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation

Field – Panel




Page 174

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



4.4 200 CWE R N Universal Service ID/ AlternateIdentifier1 obr:loinccode eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation

Field – Panel

5 2 ID O N Priority*


7 26 TS O N Observation Date/Time obr:obs_dttm eChart | Laboratory Fields – Date, Time

8 26 TS O N Observation End Date/Time obr:obs_end_dttm eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Obs End At

9 20 CQ O N Collection Volume obr:collect_vol, obr:collect_units

eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Collect Volume

10 60 XCN O Y Collector Identifier obr:collector eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Collector

11 1 ID O N 0065 Specimen Action Code obr:spec_action eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Specimen Action




Page 175

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



12 60 CE O N Danger Code obr:danger_code eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Danger Code

13 300 CE O N RelevantClinicalInfo/Text1 obr:clinically_relevant_info eChart | Laboratory Right click Lab Result Detail Report

14 26 TS O N Specimen Received Date/Time obr:rcvd_dttm eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Received At

15 300 CM O N 0070 Specimen Source obr:spec_source eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Specimen Source

16 80 XCN O Y Ordering Provider obr:ord_provider eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Order Provider

16.9.1 20 ST O Y Ordering Provider/AssigningAuthority/ UniversalID1

ext_id:id_code mapped to code “STOID”

16.9.2 20 ID O Y Ordering Provider/AssigningAuthority/ UniversalIDType1

ext_id:id_code mapped to code “STAA”







Page 176

SEQ

LEN

TYPE

R/O

REP

TBL

NAME





22 26 TS O N Results Rpt/Status Change - Date/Time obr:results_dttm eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Results At

23 40 CM O N Charge To Practice +*

24 10 ID O N 74 Diagnostic Serv Sect ID obr: diag_svr_id eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Results At

25 1 ID O N Result Status + obr:results_sts eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Results Status



28 150 XCN O Y/5 Result Copies To obr:results_cc1, obr:results_cc2, obr:results_cc3, obr:results_cc4, obr:results_cc5

Only in database

29.2.1 50 EI/ST O N Parent Number /FillerAssignedIdentifier/EntityIdentifier1

obr:child_filler_order Database only

29.2.2 50 EI/ST O N Parent Number /FillerAssignedIdentifier/UniversalID1

obr: child_filler_order_uid Database only




Page 177

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



29.2.3 50 EI/ST O N Parent Number /FillerAssignedIdentifier/UniversalIDType1

obr: child_filler_order_auth Database only

30 20 ID O N 0124 Transportation Mode obr:transport eChart | Laboratory Add pushbutton Info pushbutton Tab – Observation Field – Transportation

31 300 CE O Y Reason For Study obr:reason Only in database

32 200 CM O N Principal Result Interpreter + obr:results_pi eChart | Laboratory Status pushbutton Info pushbutton Tab – Results Field – Principal Interpreter

33 200 CM O Y Assistant Result Interpreter +*



36 26 TS O N Scheduled Date/Time + obr:sch_dttm Only in database 37 4 NM O N Number Of Sample Containers*






OBR Field Notes




Page 178

* This field is not used by MOSAIQ ESI. 1 This field is available by default only in the inbound HL7 2.5 LRI template 5. “Filler Order Number”: The permanent identifier for and order and its associated observations.

6. “Universal Service ID”: The text in OBR-4.2 is mapped to the “Panel Name” field in MOSAIQ.

7. “Observation Date/Time” : The clinically relevant date and time of the observation.

13. “Observation End Date/Time” : The end date and time of a study or timed specimen collection.

14. “Collection Volume” : For laboratory tests, the collection volume is the volume of a specimen in the form <quantity (NM)> ^ <units (CE) >. The default unit is ML. Specifically the units should be expressed in the ISO standard abbreviations (ISO-2955, 1977). The units value is mapped to Table 10000 (Unit of Measure) in ObsDef

15. “Collection Identifier” : When a specimen is required for a study, this field identifies the person, department, or facility that collected the specimen. Either name or ID code, or both, may be present.

16. “Specimen Action Code” : The action to be taken with respect to the specimens that accompany or precede this order. Refer to table 0065 – Specimen Action Code for values.

17. “Danger Code”: Refer to table 10001.

17. “Specimen Received Date/Time”: For observations requiring a specimen, the specimen received date/time is the actual login time at the diagnostic service.

18. “Specimen Source”: The site where the specimen should be obtained or where the service should be performed in the form: <specimen source name or code (CE)> ^ <additives (TX)> ^ <freetext (TX)> ^ <body site (CE)> ^ <site modifier (CE)> ^ <collection method modifier code (CE)>.




26. “Result Status”: This is a conditional field that is required whenever the OBR is contained in a report message. If the status is that of the entire order, use ORC-15-order effective date/time and ORC-5-order status. If the status pertains to the order detail segment, use OBR-25-result status and OBR-22-results report/status change - date/time. If both are present, the OBR values override the ORC values. Refer to HL7 table 0123 - Result status for valid entries.

29. “Result copies to”: Identifies the people who are to receive copies of the results. Either the name or the ID may be present.




Page 179

31. “Transportation Mode”: Identifies how to transport a patient, when applicable. Refer to HL7 table 0124 – Transportation mode for valid codes. 31. “Reason for Study”: The code or test in the form <identifier (ST)> ^ <text (ST)> ^ <name of coding system (ST)> ^ <alternate identifier (ST)> ^

<alternate text (ST)> ^ <name of alternate coding system (ST)> 33. “Principal Result Interpreter”: Identifies the physician or other clinician who interpreted the observation and is responsible for the report content.

36. “Scheduled Date/Time”: The date/time the filler scheduled an observation.




Page 180

12.27 OBR – Observation Request Segment (For ESI:Doc Inbound Interfaces) The OBR serves as the report header when reporting clinical data. It identifies the observation set represented by the following atomic observations. It includes the relevant ordering information when that applies. It contains many of the attributes that usually apply to all of the included observations. The ESI:Doc Inbound interface only uses a small subset of data from this segment.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




2 75 EI O N Placer Order Number*

3 15 EI O N Filler Order Number eii.Filler_Order_Number N/A 4 200 CE R N Universal Service ID obj.doc_type eChart | Documents…

Column – Document Type 5 2 ID O N Priority*


7 26 TS O N Observation Date/Time obj.encounter_dttm obj.trans_dttm

eChart | Documents… Columns – Encounter, Transcribed

8 26 TS O N Observation End Date/Time * 9 20 CQ O N Collection Volume *

10 60 XCN O Y Collector Identifier * 11 1 ID O N 0065 Specimen Action Code * 12 60 CE O N Danger Code * 13 300 CM O N Relevant Clinical Information*

14 26 TS O N Specimen Received Date/Time * 15 300 CM O N 0070 Specimen Source * 16 80 XCN O Y Ordering Provider obj.dict_id or

obj.sanct_id eChart | Documents… Column – By (After column “Encounter” for obj.dict_id. After column “Approved” for obj.sanct_id.)




Page 181

SEQ

LEN

TYPE

R/O

REP

TBL

NAME








22 26 TS O N Results Rpt/Status Change - Date/Time * 23 40 CM O N Charge To Practice +*


25 1 ID O N Result Status No mapping to database. Valid values are “C”, “F.

None



28 150 XCN O Y/5 Result Copies To *


30 20 ID O N 0124 Transportation Mode *

31 300 CE O Y Reason For Study *

32 200 CM O N Principal Result Interpreter obj.dict_id or obj.sanct_id

eChart | Documents… Column – By (After column “Encounter” for obj.dict_id. After column “Approved” for obj.sanct_id.)

33 200 CM O Y Assistant Result Interpreter *

34 200 CM O Y Technician *

35 200 CM O Y Transcriptionist obj.trans_id eChart | Documents… Column – By




Page 182

SEQ

LEN

TYPE

R/O

REP

TBL

NAME


MOSAIQ Application Mapping (after column Transcribed)

36 26 TS O N Scheduled Date/Time * 37 4 NM O N Number Of Sample Containers*






OBR Field Notes * This field is not used by MOSAIQ ESI. 3. “Filler Order Number”: The permanent identifier for and order and its associated observations.

Only one of OBR-16, OBR-32 or PV1-7 may be mapped to obj.dict_ID. Only one of OBR-16, OBR-32 or PV1-7 may be mapped to obj.sanct_ID. For fields 16, 32, and 35, the ID is used to find a matching Staff record in MOSAIQ. If no match is found, a new Staff record is created if ID, first name and last name are present.




Page 183

12.28 OBR – Observation Request Segment (For OIM:Doc Outbound Interfaces) The OBR serves as the report header when reporting clinical data. It identifies the observation set represented by the following atomic observations. It includes the relevant ordering information when that applies. It contains many of the attributes that usually apply to all of the included observations. The OIM:Doc Outbound interface only uses a small subset of data from this segment.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




2 75 EI O N Placer Order Number Obj.obj_id

3 15 EI O N Filler Order Number obj.ESI_DocumentID N/A 4 200 CE R N Universal Service ID obj.doc_type eChart | Documents…

Column – Document Type 5 2 ID O N Priority*


7 26 TS O N Observation Date/Time obj.encounter_dttm obj.trans_dttm

eChart | Documents… Columns – Encounter, Transcribed

8 26 TS O N Observation End Date/Time * 9 20 CQ O N Collection Volume *

10 60 XCN O Y Collector Identifier * 11 1 ID O N 0065 Specimen Action Code * 12 60 CE O N Danger Code * 13 300 CM O N Relevant Clinical Information*

14 26 TS O N Specimen Received Date/Time * 15 300 CM O N 0070 Specimen Source * 16 80 XCN O Y Ordering Provider obj.dict_id or

obj.sanct_id eChart | Documents… Column – By (After column “Encounter” for obj.dict_id. After column “Approved” for obj.sanct_id.)




Page 184

SEQ

LEN

TYPE

R/O

REP

TBL

NAME










25 1 ID O N Result Status If Obj:Status_Enum = 7 (pending) Pending document – P If Obj:Status_Enum = 5 (approved) or 3 (completed) Approved or Completed document – F Correction to results - C Order canceled - X

None



28 150 XCN O Y Result Copies To Obj:CC1- CC12 Ext_ID:ID_Code ^ Staff:Last_Name ^ Staff:First_Name ^





Page 185

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



30 20 ID O N 0124 Transportation Mode The HL7 encoded Destination path and file name of the destination file. For the message is Embedded, this field is blank.


32 200 CM O N Principal Result Interpreter obj.dict_id or obj.sanct_id

eChart | Documents… Column – By (After column “Encounter” for obj.dict_id. After column “Approved” for obj.sanct_id.)

33 200 CM O Y Assistant Result Interpreter *

34 200 CM O Y Technician *

35 200 CM O Y Transcriptionist obj.trans_id eChart | Documents… Column – By (after column Transcribed)

36 26 TS O N Scheduled Date/Time * 37 4 NM O N Number Of Sample Containers*










Page 186

12.29 OBR – Observation Request Segment (OIM: Lab Order Outbound Interface) The Observation Request (OBR) segment is used to transmit information specific to an order for a diagnostic study or observation, physical exam, or assessment.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 4 ST O N Set ID - Observation Request “1”, “2”, “3”, etc. None

2 75 EI C N Placer Order Number orc:orc_set_id Form – Observation Orders Field – Order #

3 15 EI C N Filler Order Number*

4 200 CE R N Universal Service ID Mappable to one of the following: cpt:hsp_code, cpt:hsp_code2, cpt:hsp_code3, cpt:hsp_code4, cpt:hsp_code5, cpt:cpt_code Also included is cpt:short_desc

File | Libraries | Procedures and Supplies… View dropdown – Lab Change hbutton Fields – Hospital Code, Hospital Code 2, Hospital Code 3, Hospital Code 4, Hospital Code 5, Cpt Code

5 2 ID B N 10003 (Order Priority)

Priority orc:priority Form – Observation Orders Field – Priority

6 26 TS B N Request Date/Time orc:start_dttm Form – Observation Orders Fields – Start Date / Time

7 26 TS C N Observation Date/Time *

8 26 TS O N Observation End Date/Time * 9 20 CQ O N Collection Volume * 10 60 XCN O Y Collector Identifier * 11 1 ID O N 0065 Specimen Action Code *




Page 187

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



12 60 CE O N Danger Code *

13 300 CM O N Relevant Clinical Information*

14 26 TS O N Specimen Received Date/Time * 15 300 CM O N 0070 Specimen Source * 16 80 XCN O Y Ordering Provider orc:ord_provider

* ID Mapping in OIM Form – Observation Orders Fields – MD

17 40 XTN O Y/2 Order Callback Phone Number *







25 1 ID O N Result Status +* 26 200 CM O N Parent Result +*

27 200 TQ O Y Quantity/Timing orc:service_qty orc:start_dttm orc:end_dttm orc:priority Format: 1^^^20020112094500^200201120104500^S^^^^

Observation Orders form Fields – Start Date, Time, End Date, Time Priority NOTE: orc:service_qty is not displayed within MOSAIQ.




Page 188

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



28 150 XCN O Y/5 Result Copies To*

29 150 CM O N Parent Number*

30 20 ID O N 0124 Transportation Mode obr:transport Observation Order form Field – Transport


32 200 CM O N Principal Result Interpreter +* 33 200 CM O Y Assistant Result Interpreter +*



36 26 TS O N Scheduled Date/Time + 37 4 NM O N Number Of Sample Containers*









Page 189

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



44 250 CE O 0088 Procedure Code Mappable to one of the following: cpt:hsp_code, cpt:hsp_code2, cpt:hsp_code3, cpt:hsp_code4, cpt:hsp_code5, cpt:cpt_code, Null Also included is cpt:short_desc

File | Libraries | Procedures and Supplies… View dropdown – Lab Change pushbutton Fields – Hospital Code, Hospital Code 2, Hospital Code 3, Hospital Code 4, Hospital Code 5, Cpt Code

45 250 CE O Y 0340

Procedure Code Modifier *

46 250 CE O Y 0411

Placer Supplemental Service Information *

47 250 CE O Y 0411 Filler Supplemental Service Information *




30. “Transportation Mode”: Identifies how to transport a patient, when applicable. Refer to HL7 table 0124 – Transportation mode for valid codes.




Page 190

12.30 OBX – Observation / Result Segment (IIM:Lab Result Inbound Interface) The OBX segment is used to transmit a single observation or observation fragment. It represents the smallest indivisible unit of a report.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 10 SI O N Set ID – Observational Simple 2 2 ID O N Value Type1 obx:result_value_code 3 150 CE R N Observation Identifier obx:obd_id

obd:code, obd:label, obd:desc, obd.units and obx.loinccode

eChart | Laboratory Fields – column entries

4 20 ST C N Observation Sub-ID1 obx:sub_id 5 65535 ST O Y Observation Value obx:obs_string (lab results)

or obx:obs_choice (assessments) or obx.structured_numeric_value

eChart | Laboratory Fields – column entries (results)

6 60 CE O N Units obd:units obx.unit_of _measure

eChart | Laboratory Fields – column entries (1st column)

7 10 ST O N References Range obx:reference_range eChart | Laboratory Fields – column entries (results)

8 5 ID O Y/5 0078 Abnormal Flags obx:abnormal_flags eChart | Laboratory Fields – column entries (results)

9 6 NM O N Probability* 10 2 ID O Y Nature of Abnormal Test* 11 1 ID O N 0085 Observe Result Status obx:ResultStatus

Valid values are “C”, “D”, “F” and “P”.

eChart | Laboratory Fields – column entries (results)

12 20 TS O N Date Last Obs Normal Values* 13 26 ST O N User Defined Access Checks*




Page 191

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



14 200 TS O N Date/Time Of The Observation1 obx:observation_dtTm 15 60 CE O N Producer’s ID obx:FAC_ID eChart | Laboratory

Fields – column entries (results) 16 80 XCN O N Responsible Observer obx:LabTechnician eChart | Laboratory

Fields – column entries (results) 17 O Y Observation Method* 18 O Y EquipmentInstanceIdentifier* 19 O Y DateTimeOfTheAnalysis* 20 O Y ReservedForV26_1* 21 O Y ReservedForV26_2* 22 O Y Observation Method*

23.1 XON/ST

O N PerformingOrganizationName/OrganizationName1

fac:name

23.6.2

ST O N PerformingOrganizationName/AssigningAuthority/UniversalID 1

ext_id:id_code mapped to code “OOID”

23.10 ID O N PerformingOrganizationName/OrganizationName/ OrganizationIdentifier1

ext_id:id_code mapped to code “OAA”

24.1.1

XAD/SAD/ST

O N PerformingOrganizationAddress/StreetAddress/StreetOrMailingAddress1

fac:Adr1

24.2 ST O N PerformingOrganizationAddress/OtherDesignation1

fac:Adr2

24.3 ST O N PerformingOrganizationAddress/City1 fac:City 24.4 ST O N PerformingOrganizationAddress/StateOr

Province1 fac:State_Province

24.5 ST O N PerformingOrganizationAddress/ZipOrPostalCode1

Fac:Postal

24.6 ID O N PerformingOrganizationAddress/Country1

fac:country

25.1 XCN/FN/ST

O N PerformingOrganizationMedicalDirector/FamilyName/Surname1

fac:contact

25.9.1

ST O N PerformingOrganizationMedicalDirector/ AssigningAuthority/UniversalID1

ext_id:id_code mapped to code “STOID” 1




Page 192

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



25.9.2

ID O N PerformingOrganizationMedicalDirector/ AssigningAuthority/UniversalIDType1

ext_id:id_code mapped to code “STAA” 1

OBX Field Notes * This field is not used by MOSAIQ ESI. 1 This field is available by default only in the inbound HL7 2.5 LRI template 3. “Observation Identifier” is a code that maps to a procedure in MOSAIQ. This mapping must exist for the observation result to be added. See the ESI

Data Mapping Guide for details. If a matching lab test is not found, a new lab test will be created. OBX-3.1 and OBX-3.2 are required fields for adding a lab test.

5. “Observation Value”: The value observed by the observation producer. If within a single HL7 message multiple OBX records are present with the same Observation ID, the first the value in OBX-5 of the first OBX segment will be saved in OBX:Obs_String. For subsequent matching lab tests, the data in OBX-5 and accompanying NTE-3 data will be concatenated into one Notes record in MOSAIQ. NOTE: The concatenation of results only applies to lab results (data items). We also support the import of assessment results (table titles). For assessments, we use OBX-5 to look for a matching assessment result (table item) and save the value in OBX:Obs_Choice. If multiple, duplicate assessments are found within an OBR we ignore the duplicates and put out a warning in the interface log.

6. “Units”: Units will be used along with Observation Identifier for matching purposes. Both fields must match for success.

8. “Abnormal flags”: We will import the text in OBX-8. This field indicates the normalcy status of the result. MOSAIQ only supports display of one abnormal flag per result. MOSAIQ currently supports “special display” for the following values:

HL7 Flag Field Color / Symbol Description

L Yellow / L Below low normal H Yellow / H Above high normal LL Red / LL Below lower panic limits HH Red / HH Above upper panic limits < Black / < Below absolute low-off instrument scale > Black / > Above absolute high-off instrument scale




Page 193

11. “Observation Result Status”: In addition to the values defined above, we will accept and translate other values. “I”, “N”, “O”, “R” and “S” will be translated to “P”. “X” and “W” will be translated to “D”.




Page 194

12.31 OBX – Observation / Result Segment (IIM:Doc Inbound Interface) The OBX segment is used to transmit a single observation or observation fragment. It represents the smallest indivisible unit of a report.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 10 SI O N Set ID – Observational Simple 2 2 ID R N 0125 Value Type Used for filtering. See below N/A 3 150 CE R N Observation Identifier 4 20 ST C N Observation Sub-ID 5 65535 ST O Y Observation Value Used for creating document. N/A – contents go in document 6 60 CE O N Units *

7 10 ST O N References Range * 8 5 ID O Y/5 0078 Abnormal Flags *

9 6 NM O N Probability* 10 2 ID O Y Nature of Abnormal Test* 11 1 ID O N 0085 Observe Result Status* 12 20 TS O N Date Last Obs Normal Values* 13 26 ST O N User Defined Access Checks* 14 200 TS O N Date/Time Of The Observation * 15 60 CE O N Producer’s ID* 16 80 XCN O N Responsible Observer* 17 60 CE O Y Observation Method*

OBX Field Notes * This field is not used by MOSAIQ ESI. 2. “Value Type” identifies the type of data being transmitted. We will only import data where OBX-2 = TX, ST, FT, ED, or RP. If no OBX segments exist

with OBX-2 = TX, ST, FT, ED or RP, the message will be rejected.

5a. “Observation Value”: For an ORU^R01 and an MDM^T02 message, the OBX + NTE segments are repeating. Within the OBX segment, OBX-5 can repeat infinitely. Within the NTE segment, NTE-3 can repeat infinitely. The Doc Inbound Interface can support one level of repeating information. The interface can be configured to expect a single OBX segment with OBX-5 repeating infinitely or it can be configured to expect multiple OBX segments




Page 195

each with a single value in OBX-5. It cannot be configured to support multiple OBX segments each with a repeating OBX-5 field. The same restriction applies to the NTE segment. Note: MDM^T02 does not contain an NTE segment. The interface can be configured to support a single NTE with a repeating NTE-3 field or multiple NTE segments each with a single NTE-3 field but not both.

NOTE: The interface can also support the import of PDF and image files. See below for details:

PDF and Image Import Support

The IIM:Doc Inbound Interface supports the import of four types of image files: JPG, TIF, BMP and PDF. The files can be sent in two ways: 1) embedded in the message in Base64 encoding or 2) as a file pointer (that is, the file name and path is specified in the message). For image support, OBX-5 has a custom data type of ZCE described here.

OBX-5 modified for image support

SEQ

LEN

TYPE

R/O

REP

TBL

NAME

1 infinite HD O N Identifier 1.1 infinite String O N NamespaceID 1.2 infinite String O N UniversalID 1.3 Infinite String O N UniversalIDType 2 Infinite String O N Text 3 Infinite String O N NameOfCodingSystem 4 Infinite String O N Encoding 5 Infinite String O N Data 6 Infinite String O N NameOfAlternateCodingSystem

Embedded image If the image is embedded in the message then:

• OBX-2 is set to ‘ED’

• OBX-3 contains the file name.

• OBX-5.5 contains the Base64 (MIME) encoded file.




Page 196

Example: OBX|1|ED|file_name.pdf|1|PcmHl7Export&sosacorn.com&DNS^multipart^Octet-stream^Base64^/9j/4AAQSkZJ (the rest of the Base64 encoding). Reference Pointer If the message contains a reference pointer to the file then:

• OBX-2 is set to ‘RP’

• OBX-5.1.1 contains the path and name of the file (e.g. “\\server_name\direcory_name\file_name.pdf”)

• Alternately the server name and directory name (the path) can be stored as part of the interface configuration. If the interface is so configured, then OBX-5.1.1 only needs to contain the file name.

Example: OBX|1|RP||1|\\server_name\direcory_name\file_name.pdf ||||||F|

12.32 OBX – Observation / Result Segment (OIM:Doc Outbound Interface) The OBX segment is used to transmit a single observation or observation fragment. It represents the smallest indivisible unit of a report.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 10 SI O N Set ID – Observational Simple “1”, “2”, “3”, … 2 2 ID R N 0125 Value Type “TX” – Text Data (Display)

“ED” – Encapsulated Data “RP” – Reference Pointer “FT” – Formatted Text (Display)

N/A

3 150 CE R N Observation Identifier 4 20 ST C N Observation Sub-ID 5 65535 ST O Y Observation Value The HL7 encoded

Destination path and file name of the destination file. For the message is Embedded, this field is blank.

N/A – contents go in document




Page 197

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



6 60 CE O N Units *

7 10 ST O N References Range * 8 5 ID O Y/5 0078 Abnormal Flags *

9 6 NM O N Probability* 10 2 ID O Y Nature of Abnormal Test* 11 1 ID O N 0085 Observe Result Status* 12 20 TS O N Date Last Obs Normal Values* 13 26 ST O N User Defined Access Checks* 14 200 TS O N Date/Time Of The Observation * 15 60 CE O N Producer’s ID* 16 80 XCN O N Responsible Observer* 17 60 CE O Y Observation Method*

OBX Field Notes * This field is not used by MOSAIQ ESI. 2. “Value Type” identifies the type of data being transmitted..

5a. “Observation Value”: For an ORU^R01 and an MDM^T02 message. We do not support NTE segment. NOTE: The interface can also support the import of PDF and image files. See below for details:

PDF and Image Import Support

The IIM:Doc Inbound Interface supports the import of four types of image files: JPG, TIF, BMP and PDF. The files can be sent in two ways: 1) embedded in the message in Base64 encoding or 2) as a file pointer (that is, the file name and path is specified in the message). For image support, OBX-5 has a custom data type of ZCE described here.

OBX-5 modified for image support

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




Page 198

SEQ

LEN

TYPE

R/O

REP

TBL

NAME

1 infinite HD O N Identifier 1.1 infinite String O N NamespaceID 1.2 infinite String O N UniversalID 1.3 Infinite String O N UniversalIDType 2 Infinite String O N Text 3 Infinite String O N NameOfCodingSystem 4 Infinite String O N Encoding 5 Infinite String O N Data 6 Infinite String O N NameOfAlternateCodingSystem

Embedded image If the image is embedded in the message then:

• OBX-2 is set to ‘ED’

• OBX-3 contains the file name.

• OBX-5.5 contains the Base64 (MIME) encoded file. Example: OBX|1|ED|file_name.pdf|1|PcmHl7Export&sosacorn.com&DNS^multipart^Octet-stream^Base64^/9j/4AAQSkZJ…(the rest of the Base64 encoding).

Reference Pointer If the message contains a reference pointer to the file then:

• OBX-2 is set to ‘RP’

• OBX-5.1.1 contains the path and name of the file (e.g. “\\server_name\direcory_name\file_name.pdf”)

• Alternately the server name and directory name (the path) can be stored as part of the interface configuration. If the interface is so configured, then OBX-5.1.1 only needs to contain the file name.

Example: OBX|1|RP||1|\\server_name\direcory_name\file_name.pdf ||||||F|




Page 199

12.33 OBX – Observation / Result Segment (OIM:Pharmacy Outbound Interface) The OBX segment is used to transmit BSA (Body Surface Area) to a pharmacy system.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 10 SI O N Set ID – Observational Simple 1 None 2 2 ID R N 0125 Value Type NM None 3 150 CE R N Observation Identifier If BSA:

BSA^Body Surface If height/weight: obx.obd_id->obd.code, obx.obd_id->obd.Label Format: Code^Label

None

4 20 ST C N Observation Sub-ID* 5 65535 ST O Y Observation Value If BSA:

rxo:bsa If height/weight: If obx.obs_string is a valid number, obx.obs_string else obx.obs_float

eChart | Vital Signs Fields – column entries for bsa at the time the order was entered

6 60 CE O N Units BSA: m*2^m*2 Weight (kg): kg^kg Weight (lb): lb^lb Height (cm): cm^cm Height (in): in^in

None

7 10 ST O N References Range*




Page 200

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



8 5 ID O Y/5 0078 Abnormal Flags*

9 6 NM O N Probability* 10 2 ID O Y Nature of Abnormal Test* 11 1 ID O N 0085 Observe Result Status* 12 20 TS O N Date Last Obs Normal Values* 13 26 ST O N User Defined Access Checks* 14 200 TS O N Date/Time Of The Observation If BSA:

rxo.bsa.bsa_obx_id -> obx.obr_set_id -> obr.obs_dttm If height/weight: obx.obr_set_id->obr.obs_dttm

15 60 CE O N Producer’s ID* 16 80 XCN O N Responsible Observer* 17 60 CE O Y Observation Method*

OBX Field Notes * This field is not used by MOSAIQ ESI.




Page 201

12.34 OBX – Observation / Result Segment (OIM:Charge Export Interface) The OBX segment is used to transmit test results to a billing system when required for charges.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 10 SI O N Set ID – Observational Simple N None 2 2 ID R N 0125 Value Type NM None 3 150 CE R N Observation Identifier CHG:CHG_IDANSIMEA:MeasurementCateg

ory CHG:CHG_IDANSIMEA:MeasurementType Format: ANSIMEA:MeasurementCategory ^ ANSIMEA:MeasurementType

Code Mgmt | Code Capture Tab – Billing Overrides | Button – Test Results/Measurements | Add Fields – Category Code Mgmt | Code Capture Tab – Billing Overrides | Button – Test Results/Measurements | Add Fields – Measurement Type

4 20 ST C N Observation Sub-ID*

5 65535 ST O Y Observation Value CHG:CHG_IDANSIMEA:MeasurementValue

Code Mgmt | Code Capture Tab – Billing Overrides | Button – Test Results/Measurements | Add Fields – Measurement Value

6 60 CE O N Units* 7 10 ST O N References Range* 8 5 ID O Y/5 0078 Abnormal Flags*

9 6 NM O N Probability* 10 2 ID O Y Nature of Abnormal Test* 11 1 ID O N 0085 Observe Result Status* 12 20 TS O N Date Last Obs Normal Values* 13 26 ST O N User Defined Access Checks* 14 200 TS O N Date/Time Of The Observation* 15 60 CE O N Producer’s ID*




Page 202

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



16 80 XCN O N Responsible Observer* 17 60 CE O Y Observation Method*





Page 203

12.35 OBX – Observation / Result Segment (OIM: Immunization Export Interface) There are 5 uses of the OBX segment for the Immunization Export.

♦ OBX – Vaccine for Children (VFC) information ♦ OBX – Vaccine Information Statement (VIS) - Vaccine Type ♦ OBX – VIS – Publish date ♦ OBX – VIS – Presentation date ♦ OBX – Presumed Immunity

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 10 SI O N Set ID – Observational Simple 1 .. N None 2 2 ID R N 0125 Value Type If VFC: “CE”

If VIS – Vaccine type: “CE” If VIS – Publish date: “TS” If VIS – Presentation date: “TS” If Presumed Immunity: “CE”

None

3 150 CE R N Observation Identifier If VFC: 64994-7^Vaccine funding program eligibility category^LN ObsDef.Prog_ID = 8054

eChart | Clinician Worksheet

click button – MAR Sum

MAR View

click button – Verify

Vaccine Information Statement

VFC eligibility category




Page 204

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



3 150 CE R N Observation Identifier If VIS – Vaccine type: 30956-7^Vaccine type^LN

ObsDef.Prog_ID = 8057 – Vaccine Type 1

ObsDef.Prog_ID = 8060 – Vaccine Type 2

ObsDef.Prog_ID = 8063– Vaccine Type 3



MAR View



Vaccine type #1

Vaccine type #2

Vaccine type #3

3 150 CE R N Observation Identifier If VIS – Publish date: 29768-9^Date vaccine information statement published^LN ObsDef.Prog_ID = 8059 – VIS Published 1

ObsDef.Prog_ID = 8062 – VIS Published 2

ObsDef.Prog_ID = 8065 – VIS Published 3



MAR View



Date VIS published #1






Page 205

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



3 150 CE R N Observation Identifier If VIS – Presentation date: 29769-7^Date vaccine information statement presented^LN ObsDef.Prog_ID = 8058 – VIS Presented 1

ObsDef.Prog_ID = 8061 – VIS Presented 2

ObsDef.Prog_ID = 8064 – VIS Presented 3



MAR View



Date VIS presented #1



3 150 CE R N Observation Identifier If Presumed Immunity: 59784-9^Disease with presumed immunity^LN ObsDef.Prog_ID = 9099 - Presumed Immunity

eChart | Assessments

View – MU Stage 2 – 2014

click button - Change

MU Stage 2 – 2014 (form)

Disease with Presumed Immunity

*Evidence of Immunity

4 20 ST C N Observation Sub-ID If VFC: Set ID If VIS – Vaccine type: SetID If VIS – Publish date: Set ID of Vaccine type segment If VIS – Presentation date: Set ID of Vaccine type segment 1, 2, 3 etc.

None




Page 206

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



5 65535 ST O Y Observation Value If VFC: OPV.MappingCodeÔPV.MappingDescÔPT.MappingTypeName where OPT.MappingTypeName = “HL70064” Mapping via Observations Definitions



MAR View



VFC eligibility category

5 65535 ST O Y Observation Value If VIS – Vaccine Type: OPV.MappingCodeÔPV.MappingDescÔPT.MappingTypeName where OPT.MappingTypeName = “CVX” Mapping via Observations Definitions



MAR View



Vaccine type #1

Vaccine type #2

Vaccine type #3

5 65535 ST O Y Observation Value If VIS – Publish date: Observe.OBS_Float



MAR View









Page 207

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



5 65535 ST O Y Observation Value If VIS – Presentation date: Observe.OBS_Float



MAR View






5 65535 ST O Y Observation Value If Presumed Immunity: OPV.MappingCode^OPV.MappingDesc^OPT.MappingTypeName where OPT.MappingTypeName = “SNOMEDCT” Mapping via Observations Definitions

eChart | Assessments

View – MU Stage 2 – 2014

click button - Change

MU Stage 2 – 2014 (form)

Disease with Presumed Immunity

*Evidence of Immunity

6 60 CE O N Units* 7 10 ST O N References Range* 8 5 ID O Y/5 0078 Abnormal Flags* 9 6 NM O N Probability* 10 2 ID O Y Nature of Abnormal Test* 11 1 ID O N 0085 Observe Result Status “F” for Final None 12 20 TS O N Date Last Obs Normal Values* 13 26 ST O N User Defined Access Checks*




Page 208

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



14 200 TS O N Date/Time Of The Observation If VFC:

Vaccine Admin Date (Same as RXA): If RXO.Outside_Start_Partial_DtTm <> NULL, then RXO.Outside_Start_Partial_DtTm Else RXO.Outside_Stop_Partial_DtTm Otherwise: Empty



MAR View

Administered Dose | Start Date or Stop Date

15 60 CE O N Producer’s ID* 16 80 XCN O N Responsible Observer* 17 60 CE O Y Observation Method If VFC:

“VXC40^Eligibility captured at immunization level^CDCPHINVS” Otherwise: Empty

None





Page 209

12.36 OBX – Observation / Result Segment (OIM:Syndromic Surveillance Interface) The OBX segment is used to transmit Syndromic Surveillance Information when required.

12.36.1 OBX|1| - for Facility Information

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 10 SI O N Set ID – Observational Simple 1 None 2 2 ID R N 0125 Value Type CWE None 3 150 CE R N Observation Identifier Field 3.1 = “SS003” (from CDC)

Field 3.3 = “PHINQUESTION” (from CDC)

None None


5 65535 ST O Y Observation Value Field 5.1 = “261QU200X” (from NUCC) Field 5.2 = “Urgent Care” (from NUCC) Field 5.3 = “NUCC” The above may be as follows in production: Field 5.1 = “261QM2500X” (from NUCC) Field 5.2 = “Medical Specialty” (from NUCC) Field 5.3 = “NUCC”

None None


9 6 NM O N Probability* 10 2 ID O Y Nature of Abnormal Test* 11 1 ID O N 0085 Observe Result Status* “F” for Final




Page 210

12.36.2 OBX|2| - for Age

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 10 SI O N Set ID – Observational Simple 2 None 2 2 ID R N 0125 Value Type NM None 3 150 CE R N Observation Identifier Field 3.1 = “21612-7” (Age time pat reported LN)

Field 3.3 = “LN”

None None


5 65535 ST O Y Observation Value Field 5.1 = age in years (from UCUM) Field 5.3 = “UCUM”

Calculated as years from File | Demographics Tab – Personal Fields – Birth Date



12.36.3 OBX|3| - for Chief Complaint If a chief complaint has not been entered for the patient, this segment is left out.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 10 SI O N Set ID – Observational Simple 3 None 2 2 ID R N 0125 Value Type CWE None 3 150 CE R N Observation Identifier Field 3.1 = “8661-1” (Chief Complaint - LN)

Field 3.3 = “LN”

None None




Page 211

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




5 65535 ST O Y Observation Value Field 5.9 = text of Chief Complaint

eChart | Assessments | View (MU 2014 – Optional Use) | Visit information | Chief Complaint






Page 212

12.37 ORC – Common Order Segment (for Lab Orders) The ORC segment is used to transmit fields that are common to all orders (all types of services that are requested such as lab orders and pharmacy orders). The ORC segment is required in the Order (ORM) message. This section describes the ORC segment as it applies to Lab Orders.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 2 ID R 0119 Order Control For new orders – “NW” For canceled, held, voided or replaced orders – “CA”

NA

2 22 EI C Placer Order Number

orc:orc_set_id Form – Observation Orders or Pharmacy Orders Field – Order #

3 22 EI C Filler Order Number *

4.1 20 ST O Placer Group Number/ EntityIdentifier

obsreq. placer_group_number1

NA

4.3 20 ST O Placer Group Number/ UniversalID

obsreq. placer_group_number_uid1

NA

4.4 20 ID O Placer Group Number/ UniversalIDType

obsreq. placer_group_number_auth1

NA

5 2 ID O 0038 Order Status * 6 1 ID O 0121 Response Flag “N” NA 7 200 TQ O Quantity/Timing orc:service_qty

orc:repeat_pattern->obd_id -> obs:code orc:duration orc:duration_units->obd_id->obs:code orc:start_dttm

Form – Observation Orders form or Pharmacy Orders Fields – Start Date, Time, End Date, Time Priority




Page 213

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




orc:end_dttm orc:priority Format: 1^Q6H^X3D^20020112094500^200201120104500^S^^^^

For repeat pattern, duration, and duration units, see Field Notes below. NOTE: orc:service_qty is not displayed within MOSAIQ.

8 200 CM O Parent * 9 26 TS O Date/Time of

Transaction orc:edit_dttm Order history Fields- Audit date,

time 10 120 XCN O Y Entered By orc:edit_id

* ID Mapping in OIM Order history Fields- Audit user

11 120 XCN O Y Verified By * 12 120 XCN O Y Ordering Provider orc:ord_provider

* ID Mapping in OIM Form – Observation Orders or Pharmacy Orders Field – MD

13 80 PL O Enterer’s Location * 14 40 XTN O Y/2 Call Back Phone

Number *

15 26 TS O Order Effective Date/Time

orc:edit_dttm when Order Control = “CA” else null

Not displayed in MOSAIQ

16 200 CE O Order Control Code Reason

orc:control_reason Form - Observation Orders or Pharmacy Orders Pushbutton – Change Record Status form Field – Control Reason

17 60 CE O Entering Organization

orc:inst_id Form - Observation Orders or Pharmacy Orders Field – Department

18 60 CE O Entering Device *




Page 214

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




19 120 XCN O Y Action By orc:sanct_id * ID Mapping in OIM

Form - Observation Orders or Pharmacy Orders Status pushbutton Record Status form Field – “By” in Current Status groupbox.

20 40 CE O 0339 Advanced Beneficiary Notice Code *

21 60 XON O Y Ordering Facility Name *

22 106 XAD O Y Ordering Facility Address *

23 48 XTN O Y Ordering Facility Phone Number *

24 106 XAD O Y Ordering Provider Address *

25 250 CWE O N Order Status Modifier *

ORC Field Notes * This field is not used by MOSAIQ ESI. 1 This field is available by default only in the inbound HL7 2.5 LRI template


7. “Quantity/Timing”: This field determines the priority, quantity, frequency, and timing of an atomic service. A Start Date/Time or End Date/Time of 12am is a null. See description of Duration and Frequency below.

10. “Entered By”: This field contains the identity of the person who actually keyed the request into the application. 15. “Order Effective Date/Time”: If the order has changed, this field will contain the date and time of the change. Otherwise, this field will be null. 16. “Order Control Code Reason”: This field contains the explanation (in text form) of the reason for the order event.




Page 215

17. “Entering Organization”: This field identifies the organization that the enterer belonged to at the time he/she enters/maintains the order. The value placed in this field will contain the department abbreviation for the department associated with this order.

Duration and Frequency The Wave Setup screen is used to set up the pharmacy schedule (duration and frequency) that shows up in ORC-7:2 and ORC-7:3. ORC-7:2 is the frequency, and ORC-7:3 is the duration.

If no Wave is entered, ORC-7:2 will be Once and ORC-7:3 will be X1. This will also be the case whenever “Patient Administrable” is not checked. If “Patient Administrable” is not checked, the order is broken down into a series of “once per day, one time” orders.

Important: If a schedule is to be entered for the order, the Patient Administrable check box should always be selected BEFORE the Wave button is clicked. Otherwise, certain options may be offered on the Wave setup screen that don’t make sense and cannot be properly encoded in the HL7 message.

Duration

Enter in MOSAIQ Wave Setup Contents of ORC-7:3

End after a certain number of times

n Times Xn

End after a certain amount of time

n Minute(s) n Hour(s) n Day(s) n Week(s) n Month(s) n Year(s)

Mn Hn Dn Wn Ln Yn

End by a certain date date Dn

Frequency Options


Times per day Once according to pattern

Once or Q1D, or other, as indicated by patterns below **

Times per day BID BID Times per day TID TID




Page 216

Times per day QID QID Times per day, Times: n Times, Interval m

Hours *** This option is not available if Patient

Administrable is selected Times per day, Every: n Hours

n Minutes QnH QnM

Times per day, At:

AM PM Before Sleep Each Shift

QAM QPM QHS

QSHIFT Pattern, Daily Every day Q1D Pattern, Daily Every other day Q2D Pattern, Daily Every n days QnD Pattern, Weekly Every week Q1W Pattern, Weekly Every n weeks QnW Pattern, Weekly Every n weeks, on day

m (1=Mon, 2=Tue, … 7=Sun)

QnJm

Pattern, Monthly Every month Q1L Pattern, Monthly Every n months QnL Pattern, Continuous C Pattern, As Needed PRN

** If Duration is entered as “Stop after a certain number of times, 1 time” (X1) and Times per Day is “Once according to Pattern” and Pattern is “Daily, Every day”, then Frequency is Once, otherwise, frequency is Q1D, Q2D, or other pattern. *** This option does not show up on the Wave Setup if you check “Patient Administrable” before you click on the Wave button. This option should not be used when setting pharmacy order schedules.




Page 217

12.38 ORC – Common Order Segment (for Pharmacy Orders) The ORC segment is used to transmit fields that are common to all orders (all types of services that are requested such as lab orders and pharmacy orders). The ORC segment is required in the Order (ORM) message. This section describes the ORC segment as it applies to Pharmacy Orders.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 2 ID R 0119 Order Control For new orders – “NW” For canceled, held, voided or replaced orders – “CA”

N/A

2 22 EI C Placer Order Number MQ 1.60- Order Mapping orc:orc_set_id MQ 2.00+ Order Mapping orc:orc_set_id

MQ 1.60- Order Mapping Form – Pharmacy Order Field – Order # MQ 2.00+ Order Mapping Pharmacy Order Detail (POD) At the top of the Details Tab for the order, in parentheses (above the component tabs).

3 22 EI C Filler Order Number * 4 22 EI O Placer Group Number * 5 2 ID O 0038 Order Status * 6 1 ID O 0121 Response Flag “N” N/A 7 200 TQ O Quantity/Timing MQ 1.60- Order Mapping

orc:service_qty orc:repeat_count and orc:repeat_pattern->obd_id -> obs:code and orc.repeat_flags orc:duration_time and orc:duration_units->obd_id->obs:code

MQ 1.60- Order Mapping Form – Pharmacy Orders Fields – orc:service_qty is not displayed on the MOSAIQ UI. Defaults to 1. For frequency (repeat interval), and duration




Page 218

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



orc:start_dttm orc:end_dttm orc:priority Format: 1^Q6H^X3D^20020112094500^200201120104500^S MQ 2.00+ Order Mapping orc:service_qty orc:frequency_min and orc:repeat_count and orc:repeat_pattern->obd_id -> obs:code and orc.repeat_flags orc:duration_time and orc:duration_units->obd_id->obs:code orc:start_dttm orc:end_dttm orc:priority orc: pao_freq_adhoc Format:

mapping, see Field Notes below. Start Date, Time, End Date, Time, Priority MQ 2.00+ Order Mapping Pharmacy Order Detail (POD) Field – Ordering Dose orc:service_qty is not displayed on the MOSAIQ UI. Defaults to 1. For frequency, and duration, see Field Notes below. Start Date, Time End Date, Time Priority




Page 219

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1^Q6H^X3D^20020112094500^200201120104500^S^^Every 6 hours for three days

Frequency entered in text mode

8 200 CM O Parent * 9 26 TS O Date/Time of Transaction orc:edit_dttm Order history Fields- Audit

date, time 10 120 XCN O Y Entered By orc:edit_id Order history Fields- Audit

user 11 120 XCN O Y Verified By * 12 120 XCN O Y Ordering Provider orc:ord_provider Form – Observation Orders or

Pharmacy Orders Field – MD

13 80 PL O Enterer’s Location * 14 40 XTN O Y/2 Call Back Phone Number

*

15 26 TS O Order Effective Date/Time

orc:edit_dttm when Order Control = “CA” else null

Not displayed in MOSAIQ

16 200 CE O Order Control Code Reason

orc:control_reason Form - Observation Orders or Pharmacy Orders Pushbutton – Change Record Status form Field – Control Reason

17 60 CE O Entering Organization orc:inst_id Form - Observation Orders or Pharmacy Orders Field – Department

18 60 CE O Entering Device * 19 120 XCN O Y Action By orc:sanct_id Form - Observation Orders or

Pharmacy Orders Status pushbutton Record Status form Field – “By” in Current Status groupbox.




Page 220

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



20 40 CE O 0339 Advanced Beneficiary Notice Code *

21 60 XON O Y Ordering Facility Name * 22 106 XAD O Y Ordering Facility Address

*

23 48 XTN O Y Ordering Facility Phone Number *

24 106 XAD O Y Ordering Provider Address *

25 250 CWE O N Order Status Modifier *

ORC Field Notes * This field is not used by MOSAIQ ESI. 7. “Quantity/Timing”: This field determines the priority, quantity, frequency, and timing of an atomic service. A Start Date/Time or End Date/Time of

12am is a null. See description of Duration and Frequency below. 10. “Entered By”: This field contains the identity of the person who actually keyed the request into the application. 15. “Order Effective Date/Time”: If the order has changed, this field will contain the date and time of the change. Otherwise, this field will be null. 16. “Order Control Code Reason”: This field contains the explanation (in text form) of the reason for the order event. 17. “Entering Organization”: This field identifies the organization that the enterer belonged to at the time he/she enters/maintains the order. The value

placed in this field will contain the department abbreviation for the department associated with this order.

Frequency and Duration - For Orders made in MQ 1.60 or earlier The Wave Setup screen is used to set up the pharmacy schedule (duration and frequency) that shows up in ORC-7:2 and ORC-7:3. ORC-7:2 is the frequency, and ORC-7:3 is the duration.

If no Wave is entered, ORC-7:2 will be Once and ORC-7:3 will be X1. This will also be the case whenever “Patient Administrable” is not checked. If “Patient Administrable” is not checked, the order is broken down into a series of “once per day, one time” orders.

Important: If a schedule is to be entered for the order, the Patient Administrable check box should always be selected BEFORE the Wave button is clicked. Otherwise, certain options may be offered on the Wave setup screen that don’t make sense and cannot be properly encoded in the HL7 message.




Page 221

Frequency Options


Times per day Once according to pattern

Once or Q1D, or other, as indicated by patterns below **

Times per day BID BID Times per day TID TID Times per day QID QID Times per day, Times: n Times, Interval m

Hours *** This option is not available if Patient

Administrable is selected Times per day, Every: n Hours

n Minutes QnH QnM

Times per day, At:

AM PM Before Sleep Each Shift

QAM QPM QHS

QSHIFT Pattern, Daily Every day Q1D Pattern, Daily Every other day Q2D Pattern, Daily Every n days QnD Pattern, Weekly Every week Q1W Pattern, Weekly Every n weeks QnW Pattern, Weekly Every n weeks, on day

m (1=Mon, 2=Tue, … 7=Sun)

QnJm

Pattern, Monthly Every month Q1L Pattern, Monthly Every n months QnL Pattern, Continuous C Pattern, As Needed PRN




Page 222

Duration Options


End after a certain number of times

n Times Xn

End after a certain amount of time

n Minute(s) n Hour(s) n Day(s) n Week(s) n Month(s) n Year(s)

Mn Hn Dn Wn Ln Yn

End by a certain date date Dn ** If Duration is entered as “Stop after a certain number of times, 1 time” (X1) and Times per Day is “Once according to Pattern” and Pattern is “Daily, Every day”, then Frequency is Once, otherwise, frequency is Q1D, Q2D, or other pattern. *** This option does not show up on the Wave Setup if you check “Patient Administrable” before you click on the Wave button. This option should not be used when setting pharmacy order schedules.

Frequency and Duration - For orders made in MQ 2.00 or later The Frequency control on Pharmacy Order Detail (POD) is used to set up the pharmacy schedule (duration and frequency) that shows up in ORC-7:2 and ORC-7:3. ORC-7:2 is the frequency, and ORC-7:3 is the duration.

The Frequency defaults to Once. If it is not changed, ORC-7:2 will be Once and ORC-7:3 will be X1.

In pick mode, the Frequency control has the following format:

In this mode, there are five controls available, delineating the different portions of frequency/duration:




Page 223

The first control, a numeric selection, maps to Orders:Frequency_Min in the database. In the case of Order types 5 (In House Pick up) and 6 (external pick up) Orders:Frequency_Max could also be filled, otherwise Orders:Frequency_Min = Orders:Frequency_Max). The default is 1. Minimum value is 1. Maximum value is 10. The second control, a numeric selection, maps to Orders:Repeat_Count. The default is 1. Minimum value is 1. Maximum value is 366. The third control, a drop down, maps to Orders:Repeat_Pattern. This is calculated by the ObsDef:Prog_ID associated with each entry. The default is “once”, or Prog_ID = 4220. There are restrictions when the user changes the value on the second control. The fourth control, a numeric selection, maps to Orders:Duration_Time. The default is 1. Minimum value is 1. Maximum value is 366. The fifth control, a drop down, maps to Orders:Duration_Units. This is calculated by the Obs:Def:Prog_ID associated with each entry. The default is “times”, or Prog_ID = 3800. There are restrictions when the user changes the value on the fourth control.

Frequency Options

UI Label

N times

every n

units

HL7 Field ORC-7:2 Database

Field Frequency_Min Repeat_Count Repeat_Pattern

Possible Values

1 n minute(s) QnM

1 n hours(s) QnH

1 n > 1 day(s) QnD

1 n weeks(s) QnW

1 n month(s) QnL

1 n Monday(s) QnJ1

1 n Tuesday(s) QnJ2

1 n Wednesday(s) QnJ3

1 n Thursday(s) QnJ4

1 n Friday(s) QnJ5

1 n Saturday(s) QnJ6

1 n Sunday(s) QnJ7




Page 224

1 -- twice a day BID

1 -- three times a day TID

1 -- four times a day QID

1 -- morning(s) QAM

1 -- each shift QShift

1 -- before sleep QHS

1 -- evening(s) QPM

1 -- continuously C

1 1 day(s) Once

2 1 day(s) BID

3 1 day(s) TID

4 1 day(s) QID

N > 4 1 day(s) <N>ID e.g. 8 times a day is 8ID

N** n** once Once

N** -- twice a day BID

N** -- three times a day TID

N** -- four times a day QID

** These values should not be enterable on the UI. If values are entered, they will be ignored. If a range is entered in the Frequency control, the maximum of the range is stored in Orders.Frequency_Max in the database. This value is not currently used by the Pharmacy Order interface.




Page 225

Duration Options

UI Description

for n

units

HL7 Field ORC-7:2

Database Field

Duration_Time Duration_Units

Possible Values

n Time(s) Xn

n Minute(s) Mn

n Hour(s) Hn

n Day(s) Dn

n Week(s) Wn

n Month(s) Ln




Page 226

12.39 ORC – Common Order Segment (OIM: Immunization Export Interface) The ORC segment is used to transmit fields that are common to all orders. The ORC segment is required in the Vaccine (VXU) message. This section describes the ORC segment as it applies to Immunizations Export interface. There is one ORC segment for each immunization event in the patient’s record whether it is an administered or historical record.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 2 ID R 0119 Order Control “RE” N/A 2 22 EI RE Placer Order Number Immunization Admin:

ORC2:1 Obr:obr_set_id ORC2:2 Department Abbr. EDI_DST.Inst_ID Historical Immunization: <Empty>

Observation Identity

3 22 EI R Filler Order Number ORC 3:1 Obr:obr_set_id ORC3:2 Department Abbr. EDI_DST.Inst_ID

Observation Identity

4 EI O Placer Group Number * 5 ID O 0038 Order Status * 6 ID O 0121 Response Flag * 7 TQ X Quantity/Timing* 8 CM O Parent * 9 TS O Date/Time of

Transaction*




Page 227

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



10 120 XCN RE Entered By Immunization Admin: orc:edit_id => Ext_ID.ID_Code Historical Immunization: <Empty>

Order history Fields- Audit user. The ID Type to use is mappable in the Interface properties.

11 XCN O Y Verified By * 12 120 XCN RE Y Ordering Provider Immunization Admin:

orc:ord_provider => Ext_ID.ID_Code Historical Immunization: <Empty>

Form – Observation Orders or Pharmacy Orders Field – MD The ID Type to use is mappable in the Interface properties.

13 PL O Enterer’s Location * 14 XTN O Y/2 Call Back Phone Number

*

15 TS O Order Effective Date/Time *

16 CE O Order Control Code Reason *

17 CE O Entering Organization 18 CE O Entering Device * 19 XCN O Y Action By * 20 CE O 0339 Advanced Beneficiary

Notice Code *

21 XON O Y Ordering Facility Name * 22 XAD O Y Ordering Facility Address

*

23 XTN O Y Ordering Facility Phone Number *

24 XAD O Y Ordering Provider Address *




Page 228

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



25 CWE O Order Status Modifier * 26 CWE O Advanced Beneficiary

Notice Override Reason *

27 TS O Filler's Expected Availability Date/Time *

28 CWE O Confidentiality Code * 29 CWE O Order Type * 30 CNE O Enterer Authorization

Mode *

31 CWE O Parent Universal Service Identifier*

ORC Field Notes None




Page 229

12.40 PD1 – Patient Demographic Segment (OIM: Immunization Export Interface) The PD1 segment contains patient demographic information that may change from time to time. The three uses for an Immunization Message are indicating whether the person wants their data protected, whether the person wants to receive recall/reminder notices and the person’s current status in the registry. This segment can occur for either new immunizations or historical records. If neither the Publicity Code nor the Protection Indicator exists for the patient, the PD1 will be omitted. The most resent immunization recording containing this information is used for building the PD1.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 Living Dependency* 2 Living Arrangement* 3 Patient Primary Facility* 4 Patient Primary Care Provider

Name & ID No.*

5 Student Indicator* 6 Handicap* 7 Living Will Code* 8 Organ Donor Code* 9 Separate Bill* 10 Duplicate Patient* 11 60 CE RE 0215 Publicity Code OMV.Mapping_Code^OMV.Mapping_Desc^

HL70215 Prog_ID 8067 Reminder Indicator

12 1 ID RE 0136 Protection Indicator Obs:Obd_Id => Obd.Description ’Y’, ’N’ or [empty]

Prog_ID 8066 Protection Indicator




Page 230

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



13 26 TS R Protection Effective Date Vaccine Admin: If RXO.Outside_Start_Partial_DtTm <> NULL, then RXO.Outside_Start_Partial_DtTm Else RXO.Outside_Stop_Partial_DtTm Historical: OBR.Obs_DtTm



MAR View

Administered Dose | Start Date

eChart | Assessments View – MU Stage 2 – 2014 click button - Change MU Stage 2 – 2014 (form) Vaccine Hx Date of Vaccine Activity

14 XON O Place of Worship* 15 CE O Advance Directive Code* 16 1 ID R 0441 Immunization Registy Status ’A’ 17 26 TS R Immunization Registy Status

Effective Date Same as PD1- 13

18 26 TS R Publicity Code Effective Date Same as PD1- 13 19 IS O Military Branch* 20 IS O Military Rank/Grade* 21 IS O Military Status*

PD1 Field Notes *This field is not used by MOSAIQ ESI.




Page 231

12.41 PID – Patient Identification Segment The PID segment is used as the primary means of communicating patient identification information to / from MOSAIQ ESI. This segment contains permanent patient identifying and demographic information that, for the most part, is not likely to change frequently.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 4 SI O N Set ID Not Used “1” 2 16 CX O N Patient ID - External MAPPABLE

IIM ADT:Adm. User_Defined_Pro_ID1

MAPPABLE File | Demographics Tab – Name/IDs Fields – For import, any of the six fields in the ID group box except the first. For export, any of the six fields. To configure mapping in OIM: Interface Properties | Mapping & Segments tab | External (PID-2) To configure mapping in IIM/IBD: Message Field Mapping | Full Patient|Patient|UserDefinedField1 File | Demographics Tab – Attending Field - User Defined Label 1

3 16 CX R N Patient ID - Internal IDT:IDA or IDT:IDB

MAPPABLE File | Demographics Tab – Name/IDs Fields – For import, either of the first two fields in the ID group box. For export, any of the six fields. To configure mapping in OIM: Interface Properties | Mapping & Segments tab | Internal (PID-




Page 232

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



MOSAIQ Application Mapping 3)

3.4.2 20 CX R N Patient ID - AssigningAuthority/UniversalID1

obr. medical_record_number_uid

N/A

3.4.3 20 CX R N Patient ID - AssigningAuthority/UniversalIDType1

obr. medical_record_number_auth

N/A

4 12 CX O N Alternate Patient ID MAPPABLE IIM ADT:Adm. User_Defined_Pro_ID2

MAPPABLE File | Demographics Tab – Name/IDs Fields – For import, any of the six fields in the ID group box except the first. For export, any of the six fields. To configure mapping in OIM: Interface Properties | Mapping & Segments tab | Alternate Patient ID (PID-4) To configure mapping in IIM/IBD: Message Field Mapping | Full Patient|Patient|UserDefinedField2 File | Demographics Tab – Attending Field - User Defined Label 2

5 48 XPN R N Patient Name pat:last_name, pat:first_name, pat:middle_name, pat:suffix, pat:salutation IIM ADT Japan: pat:last_name_secondary, pat:first_name_secondary,

pat:last_name, pat:first_name, pat:middle_name, pat:suffix, pat:salutation

File | Demographics Tab – Name/IDs Tab - Name Fields – Salutation, Last, First, MI IIM ADT Japan: Tab - Name 2 Fields – Last, First, Middle




Page 233

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




pat:middle_name_secondary, pat:last_name_singlebyte, pat:first_name_singlebyte, pat:middle_name_singlebyte

Tab - Name 3 Fields – Last, First, Middle

6 48 XPN O N Mother's Maiden Name*

7 26 TS O N Date/Time of Birth pat:birth_dttm pat:birth_dttm File | Demographics Tab – Personal Fields – Birth Date

8 10 IS O N 0001 Sex adm:gender adm:gender File | Demographics Tab – Personal Fields – Gender

9 48 XPN O Y Patient Alias pat:alias_name pat:alias_name File | Demographics Tab – Name/IDs Fields – Other

10 10 IS CE

O Y 0005 Race Race:Pro_ID Race:Pro_ID File | Demographics Tab – Personal Fields – Race

11 106 XAD O N Patient Address adm:pat_adr1, adm:pat_adr2, adm:pat_city, adm:pat_state, adm:pat_postal, adm:pat_country

adm:pat_adr1, adm:pat_adr2, adm:pat_city, adm:pat_state, adm:pat_postal, adm:pat_country

File | Demographics Tab – Home/Work Fields – 1, 2, City, State, Postal, Country

12 4 IS O N 0289 County Code * adm:pat_county adm:pat_county 13 40 XTN O Y Phone Number -

Home adm:pat_home_phone If PID-13:3 = CP: Adm:pat_CellPhone

adm:pat_home_phone, adm:pat_home_phone_ex adm:pat_home_phone, adm:pat_home_phone_ex

File | Demographics Tab – Home/Work Fields – Phone, Cell Phone, Email




Page 234

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




If PID-13:3 = Internet: adm:pat_email

~ adm:pat_cellphone Format: 408/555-1212~408/555-2222^^CP

14 40 XTN O Y Phone Number - Business

adm:pat_work_phone, adm:pat_work_phone_ex

adm:pat_work_phone, adm:pat_work_phone_ex

File | Demographics Tab – Home/Work Fields – Phone (bottom), Ext

15 60 CE O N 0296 Language - Patient Admin.language_spoken_pro_id->Prompt.Text where PGroup = LANG

Admin.language_spoken_pro_id -> Prompt.Text where PGroup = LANG

File | Demographics Tab – Personal Field – Language

16 10 IS O N 0002 Marital Status adm:marital adm:marital File | Demographics Tab – Personal Fields – Marital Status

17 10 IS O N 0006 Religion adm:religion adm:religion File | Demographics Tab – Personal Fields – Religion

18 20 CX O N 0061 Patient Acct Number MAPPABLE MAPPABLE File | Demographics Tab – Name/IDs Fields – For import, any of the six fields in the ID group box except the first. For export, any of the six fields. To configure mapping in OIM: Interface Properties | Mapping & Segments tab | Account (PID-18)

19 16 ST O N Social Security Number

pat:ss_number

pat:ss_number

File | Demographics Tab – Personal




Page 235

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



MOSAIQ Application Mapping Fields – SSN

20 25 CM O N Driver Lic Num - Patient*

21 20 CX O N Mother’s Identifier* 22 4 IS O N Ethnic Group* adm:Ethnicity_PRO_ID adm:Ethnicity_PRO_ID 23 60 ST O N Birth Place adm:birth_place File | Demographics

Tab – Personal Fields – Birth Place

24 2 ID O N Multiple Birth Indicator*

25 2 NM O N Birth Order* IIM ADT:User_Defined_Info1 To configure mapping in IIM/IBD: Message Field Mapping | Full Patient|Patient|UserDefinedField3 File | Demographics Tab – Attending Field - User Defined Label 3

26 4 IS O Y Citizenship* IIM ADT:User_Defined_Info2 To configure mapping in IIM/IBD: Message Field Mapping | Full Patient|Patient|UserDefinedField4 File | Demographics Tab – Attending Field - User Defined Label 4

27 60 CE O N Veterans Military Status*

IIM ADT:User_Defined_Info3 To configure mapping in IIM/IBD: Message Field Mapping | Full Patient|Patient|UserDefinedField5 File | Demographics Tab – Attending Field - User Defined Label 5




Page 236

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




28 80 CE O N Nationality* IIM ADT:User_Defined_Info4 To configure mapping in IIM/IBD: Message Field Mapping | Full Patient|Patient|UserDefinedField6 File | Demographics Tab – Attending Field - User Defined Label 6

29 26 TS O N Patient Death Date & Time

adm:expired_dttm File | Demographics Tab – Admission Fields – Expired Date

30 1 ID O N Patient Death Indicator*

PID Field Notes * This field is not used by MOSAIQ ESI. 1 This field is available by default only in the inbound HL7 2.5 LRI template

Patients added via an interface are marked as active (Pat:Inactive = False). MAPPABLE: MOSAIQ maintains six patient ID fields referred to as IDA, IDB, IDC, IDD, IDE and IDF. IDA must be unique. IDB is optionally unique based on department configuration. IDC – IDF are not unique. For both inbound and outbound interfaces, configuration is available to map these IDs to specific fields in HL7 segments PID and PV1. The contents of IDA – IDF can be updated through the interface, but no history is maintained for these IDs. In addition to IDA – IDF, MOSAIQ can also store account number in the Accounts table in Accounts.AccountNo. At most one HL7 patient identifier can be mapped to Account Number. A patient can have multiple Account Numbers. Account Numbers can also have active and inactive date/times. These values are mapped to PV1-44 (Admit date/time) and PV1-45 (Discharge date/time).

1. “Set ID”: For those messages that permit multiple datasets about different patients, the SET ID field is used to identify the repetitions. MOSAIQ ESI supports only one dataset per HL7 message and updates based on PID-3 (Patient ID – Internal), not PID-1 (Set ID).

2. For Outbound Charge Export. If the user chooses to map the Account Number to this field, the Account Number comes from the associated Charge record. If there are multiple charges in a message (i.e. the charges are grouped), the Account Number in this field comes from the first charge in the message.




Page 237

3. “Patient ID - Internal”: Primary ID used by the facility to positively identify a patient when admitted, i.e., medical record number, billing number, etc. ESI Manager ADT Inbound automatically generates patient ID field IDA when the following conditions are true: ♦ ESI Configuration ID Mapping setting for IDA = “None” and IDB = “Internal”. ♦ Department Setup setting “Automatic Generation of Primary ID (IDA)” is checked. ♦ Department Setup setting “Require Unique Secondary ID (IDB)” is checked.

5. For IIM ADT Japan only: PID-5 repeats are used to send the patient’s name in several languages in any order. What language a repeat contains is determined by PID-5.8. ♦ The three languages that can appear in the PID-3 field are Kanji (PID5.8 = I), Katakana (PID5.8 = P), and ‘Romanized’ (PID5.8 = A). ♦ If the message contains repeats that do not have a matching PID-5.8 or blank repeat character these will be ignored. ♦ If the Secondary name field in the Patient Object is populated with dual byte KataKana characters and the SingleByte name fields do not contain a

value, the Romanization automatically ‘translates’ the KataKana characters into English readable names and is stored in the SingleByte name fields in the database.

8. “Sex”: Valid entries are M - Male; F - Female, U - Unknown. 10. For IIM and OIM HL7 interfaces only: PID-10 repeats are used to receive/send multiple races for persons of mixed race. The datatype used is “CE”. The

import and export are multi-step processes that require mapping to identify the final value for use in import or export. On import the coded in PID-10.1 is used to find a matching record in ObsDef where Tbl = 5. The matching ObsDef.Label is used to find a matching Prompt record where PGroup = ‘ADM4’. Prompt.Pro_ID is then saved in Race.Pro_ID. On export, the reverse is done. Race.Pro_ID is used to find a matching Prompt where PGroup = ‘ADM4’. Prompt.Text is used to find a matching ObsDef record for Tbl = 5 ObsDef.Code is exported in PID-10.1.

10. For ESI Manager ADT Inbound we will only attempt to import the first Race in the PID-9. The datatype used is “IS”. 10. For HL7 Charge Export we will only export the first Race (based on Record creation order (Race.Race_ID). The datataype used is CE. 18. For IIM ADT only: If value of PID-13.3 = “CP” the phone number is added as cell phone 15. For IIM ADT only: Mapped through Prompt.PRO_ID. If match for Prompt.Text is NOT found we add a new Prompt table record. 16. “Marital status”: Valid entries are M - Married; S - Single; D - Divorced; W - Widowed; A - Separated. 18. For Outbound Charge Export. If the user chooses to map the Account Number to this field, the Account Number comes from the associated Charge

record. If there are multiple charges in a message (i.e. the charges are grouped), the Account Number in this field comes from the first charge in the message.

18. For Lab Order Export. If the user chooses to map the Account Number to this field, the Account Number comes from the associated Orders record. 22. Ethnic Group is imported/exported for IIM and OIM HL7 interfaces only. The import and export are multi-step processes that require mapping to

identify the final value for use in import or export. On import the coded in PID-22.1 is used to find a matching record in ObsDef where Tbl = 189. The matching ObsDef.Label is used to find a matching Prompt record where PGroup = ‘ETH1’. Prompt.Pro_ID is then saved in Admin.Ethnicity_Pro_ID.




Page 238

On export, the reverse is done. Admin.Ethnicity_Pro_ID is used to find a matching Prompt where PGroup = ‘ETH1’. Prompt.Text is used to find a matching ObsDef record for Tbl = 189. ObsDef.Code is exported in PID-22.1.




Page 239

12.42 PID – Patient Identification Segment (OIM: Immunization Export Interface) The PID segment is used as the primary means of communicating patient identification information to / from MOSAIQ ESI. This segment contains permanent patient identifying and demographic information that, for the most part, is not likely to change frequently.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 4 SI O N Set ID “1” 2 16 CX O N Patient ID – External * 3 16 CX R N Patient ID - Internal First repetition – MAPPABLE

Second repetition – pat:SS_Number The resulting output will look like this: ID123^^^Assigning Authority^MR~123-45-6789^^^MAA^SS

File | Demographics Tab – Name/IDs Fields – Any of the six fields. Tab – Personal Field – SSN To configure mapping in OIM: Interface Properties | Mapping & Segments tab | Internal (PID-3)

4 12 CX O N Alternate Patient ID * 5 48 XPN R N Patient Name pat:last_name,

pat:first_name, pat:middle_name, pat:suffix, pat:salutation The 7th component will contain “L”.

File | Demographics Tab – Name/IDs Tab – Name Fields – Last, First, Middle, Suffix, Salutation




Page 240

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




Patient.MotherMaidenName Output format: Last^First Both first and last name are required or this field will be left empty. We will parse the name as follows: Last,First (Data prior to “,” is Last. After “,” is First. First Last (Date prior to “ ” is First. After “ ”“ is Last.

File | Demographics Tab – Personal Field – Mother Maiden Name

7 26 TS O N Date/Time of Birth pat:birth_dttm File | Demographics Tab – Personal Fields – Birth Date

8 10 IS O N 0001 Sex adm:gender File | Demographics Tab – Personal Fields – Gender

9 48 XPN O Y Patient Alias 10 10 IS

CE O Y 0005 Race Race:Pro_ID

mapping via ObsDef

File | Demographics Tab – Personal Fields – Race

11 106 XAD O N Patient Address adm:pat_adr1, adm:pat_adr2, adm:pat_city, adm:pat_state, adm:pat_postal, adm:pat_country adm:birth_state

File | Demographics Tab – Contact Grid Row – Patient Home Fields – 1, 2, City, State, Postal, Country

12 4 IS O N 0289 County Code * adm:pat_county




Page 241

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



13 40 XTN O Y Phone Number - Home adm:pat_home_phone, adm:pat_home_phone_ex ~ adm:pat_cell_phone, ~ adm:pat_cellphone Format: 408/555-1212~408/555-2222^^CP

File | Demographics Tab – Contact Grid Row – Patient Home Fields – Phone, Cell Phone, E-mail

14 40 XTN O Y Phone Number – Business *

15 60 CE O N 0296 Language – Patient *

16 10 IS O N 0002 Marital Status * 17 10 IS O N 0006 Religion * 18 20 CX O N 0061 Patient Acct Number * 19 16 ST O N Social Security Number

*


21 20 CX O N Mother’s Identifier* 22 4 IS O N 0189 Ethnic Group adm:Ethnicity_PRO_ID

mapping via ObsDef

File | Demographics Tab – Personal Fields – Ethnicity

23 60 ST O N Birth Place 24 2 ID O N Multiple Birth

Indicator Pat:MultipleBirth_PRO_ID File | Demographics

Tab – Personal Fields – Multiple Birth




Page 242

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



25 2 NM O N Birth Order Pat:MultipleBirthOrder File | Demographics Tab – Personal Fields – Multiple Birth Order

PID Field Notes * This field is not used by MOSAIQ ESI

MAPPABLE: MOSAIQ maintains six patient ID fields referred to as IDA, IDB, IDC, IDD, IDE and IDF. IDA must be unique. IDB is optionally unique based on department configuration. IDC – IDF are not unique. Configuration is available to map these IDs to specific fields in HL7 PID segment.

10. PID-10 repeats are used to send multiple races for persons of mixed race. The datatype used is “CE”. The export is a multi-step process that requires mapping to identify the final value for use in export. On export, Race.Pro_ID is used to find a matching Prompt where PGroup = ‘ADM4’. Prompt.Text is used to find a matching ObsDef record for Tbl = 5. ObsDef.Code is exported in PID-10.1.

22. The export is a multi-step process that requires mapping to identify the final value for use in import or export. On export, Admin.Ethnicity_Pro_ID is used to find a matching Prompt where PGroup = ‘ETH1’. Prompt.Text is used to find a matching ObsDef record for Tbl = 189. ObsDef.Code is exported in PID-22.1.




Page 243

12.43 ID – Patient Identification Segment (OIM:Syndromic Surveillance Interface) The PID segment is used as the primary means of communicating patient identification information to / from MOSAIQ ESI. This segment contains permanent patient identifying and demographic information that, for the most part, is not likely to change frequently.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 4 SI O N Set ID Not Used “1” 2 16 CX O N Patient ID - External Not Used 3 16 CX R N Patient ID - Internal MAPPABLE File | Demographics

Tab – Name/IDs Fields – For import, either of the first two fields in the ID group box. For export, any of the six fields. To configure mapping in OIM: Interface Properties | Mapping & Segments tab | Internal (PID-3)

4 12 CX O N Alternate Patient ID Not Used 5 48 XPN R N Patient Name N/A ^^^^^^^~^^^^^^S * N/A – Patient Name is

anonimized for this interface


Not Used

7 26 TS O N Date/Time of Birth Not Used pat:birth_dttm File | Demographics Tab – Personal Fields – Birth Date

8 10 IS O N 0001 Sex adm:gender File | Demographics Tab – Personal Fields – Gender




Page 244

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




9 48 XPN O Y Patient Alias Not Used 10 10 IS

CE O Y 0005 Race Outbound value will

be mapped to CDCREC – Race Code Values

File | Demographics Tab – Personal Fields – Race

11 106 XAD O N Patient Address adm:pat_postal, adm:pat_county

File | Demographics Tab – Home/Work Fields – 1, 2, City, State, Postal, Country,County

12 4 IS O N 0289 County Code Not used 13 40 XTN O Y Phone Number -

Home Not used

14 40 XTN O Y Phone Number - Business

Not used

15 60 CE O N 0296 Language - Patient Not used

16 10 IS O N 0002 Marital Status Not used 17 10 IS O N 0006 Religion Not used 18 20 CX O N 0061 Patient Acct Number Not used 19 16 ST O N Social Security

Number Not used


Not used

21 20 CX O N Mother’s Identifier* Not used 22 4 IS O N Ethnic Group* adm:Ethnicity_PRO_I

D Field is mappes to CDCREC Ethnicity Code Values

File | Demographics Tab – Personal Fields – Ethnicity

23 60 ST O N Birth Place Not used




Page 245

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




24 2 ID O N Multiple Birth Indicator*

Not used

25 2 NM O N Birth Order* Not used 26 4 IS O Y Citizenship* Not used 27 60 CE O N Veterans Military

Status* Not used

28 80 CE O N Nationality* Not used 29 26 TS O N Patient Death Date &

Time Not used

30 1 ID O N Patient Death Indicator*

Not used

PID Field Notes * This field is not used by MOSAIQ ESI. 1 This field is available by default only in the inbound HL7 2.5 LRI template

Patients added via an interface are marked as active (Pat:Inactive = False). MAPPABLE: MOSAIQ maintains six patient ID fields referred to as IDA, IDB, IDC, IDD, IDE and IDF. IDA must be unique. IDB is optionally unique based on department configuration. IDC – IDF are not unique. For both inbound and outbound interfaces, configuration is available to map these IDs to specific fields in HL7 segments PID and PV1. The contents of IDA – IDF can be updated through the interface, but no history is maintained for these IDs. In addition to IDA – IDF, MOSAIQ can also store account number in the Accounts table in Accounts.AccountNo. At most one HL7 patient identifier can be mapped to Account Number. A patient can have multiple Account Numbers. Account Numbers can also have active and inactive date/times. These values are mapped to PV1-44 (Admit date/time) and PV1-45 (Discharge date/time).

1. “Set ID”: For those messages that permit multiple datasets about different patients, the SET ID field is used to identify the repetitions. MOSAIQ ESI supports only one dataset per HL7 message and updates based on PID-3 (Patient ID – Internal), not PID-1 (Set ID).





Page 246

3. “Patient ID - Internal”: Primary ID used by the facility to positively identify a patient when admitted, i.e., medical record number, billing number, etc. ESI Manager ADT Inbound automatically generates patient ID field IDA when the following conditions are true: ♦ ESI Configuration ID Mapping setting for IDA = “None” and IDB = “Internal”. ♦ Department Setup setting “Automatic Generation of Primary ID (IDA)” is checked. ♦ Department Setup setting “Require Unique Secondary ID (IDB)” is checked.

5. For IIM ADT Japan only: PID-5 repeats are used to send the patient’s name in several languages in any order. What language a repeat contains is determined by PID-5.8. ♦ The three languages that can appear in the PID-3 field are Kanji (PID5.8 = I), Katakana (PID5.8 = P), and ‘Romanized’ (PID5.8 = A). ♦ If the message contains repeats that do not have a matching PID-5.8 or blank repeat character these will be ignored. ♦ If the Secondary name field in the Patient Object is populated with dual byte KataKana characters and the SingleByte name fields do not contain a

value, the Romanization automatically ‘translates’ the KataKana characters into English readable names and is stored in the SingleByte name fields in the database.

9. “Sex”: Valid entries are M - Male; F - Female, U - Unknown. 10. For IIM and OIM HL7 interfaces only: PID-10 repeats are used to receive/send multiple races for persons of mixed race. The datatype used is “CE”. The

import and export are multi-step processes that require mapping to identify the final value for use in import or export. On import the coded in PID-10.1 is used to find a matching record in ObsDef where Tbl = 5. The matching ObsDef.Label is used to find a matching Prompt record where PGroup = ‘ADM4’. Prompt.Pro_ID is then saved in Race.Pro_ID. On export, the reverse is done. Race.Pro_ID is used to find a matching Prompt where PGroup = ‘ADM4’. Prompt.Text is used to find a matching ObsDef record for Tbl = 5 ObsDef.Code is exported in PID-10.1.

10. For ESI Manager ADT Inbound we will only attempt to import the first Race in the PID-9. The datatype used is “IS”. 10. For HL7 Charge Export we will only export the first Race (based on Record creation order (Race.Race_ID). The datataype used is CE. 19. For IIM ADT only: If value of PID-13.3 = “CP” the phone number is added as cell phone 17. For IIM ADT only: Mapped through Prompt.PRO_ID. If match for Prompt.Text is NOT found we add a new Prompt table record. 18. “Marital status”: Valid entries are M - Married; S - Single; D - Divorced; W - Widowed; A - Separated. 18. For Outbound Charge Export. If the user chooses to map the Account Number to this field, the Account Number comes from the associated Charge

record. If there are multiple charges in a message (i.e. the charges are grouped), the Account Number in this field comes from the first charge in the message.

18. For Lab Order Export. If the user chooses to map the Account Number to this field, the Account Number comes from the associated Orders record. 22. Race and Ethnic Group are mapped to the following CDCREC PHVS code table values to retain PHIN Conformance.




Page 247

CDCREC PHVS Race Category Code Values Concept Code Concept Name 1002-5 American Indian or Alask Native 2028-9 Asian 2054-5 Black or African American 2076-8 Native Hawaiian or Other Pacific Islander 2131-1 Other Race 2106-3 White

CDCREC PHVS Ethnicity Category Code Values

Concept Code Concept Name 2135-2 Hispanic or Latino 2186-5 Not Hispanic or Latino




Page 248

12.44 PV1 – Patient Visit Segment The PV1 segment is used by ADT applications to communicate information on a visit specific basis. This segment is also sent in Schedule messages.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 4 SI O N Set ID - Patient Visit

2 3 IS R N 0004 Patient Class adm:IsInpatient IIM ADT:AccountStatus

adm:IsInpatient Charge Outbound: Chg:IsInpatient

File | Demographics Tab – Admission Fields – Inpatient checkbox Or Charge slip override IIM ADT: File | Demographics Button – Accounts Buttin – Add Field - Status

3 12 PL O N Assigned Patient Location

adm:nurse_unit, adm:room_num, adm:bed_num IIM ADT:Accountdomain.DomainName or Account.Comment

adm:nurse_unit, adm:room_num, adm:bed_num, Doc Outbound: config:Dept_Abrv

File | Demographics Tab – Admission Fields – Nurse Unit, Room, Bed IIM ADT: File | Demographics Button – Accounts Column – Domain or Column - Comment

4 2 IS O N 0007 Admission Type*

5 20 ST O N Pre-Admit Number*

6 12 PL O N 0079 Prior Patient Location*




Page 249

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




7 60 XCN O Y 0010* Attending Doctor

adm:attending_md_id or adm:stf_md2_id or adm:stf_md3_id or adm:stf_md4_id or adm:stf_md5_id or adm:stf_md6_id or adm:stf_md7_id

adm:attending_md_id or adm:stf_md2_id or adm:stf_md3_id or adm:stf_md4_id or adm:stf_md5_id or adm:stf_md6_id or adm:stf_md7_id * ID Mapping in OIM

File | Demographics Tab – Attending Fields – Attending Physician

8 60 XCN O N 0010* Referring Doctor adm:ref_md_id adm:ref_md_id or chg:referring_md_id (see note) * ID Mapping in OIM

File | Demographics Tab – Referral Fields – Referring Physician

9 60 XCN O Y 0010* Consulting Doctor adm:ref_md2_id, adm:ref_md3_id, adm:pri_md_id, adm:ref_from_fac_id

adm:ref_md2_id, adm:ref_md3_id, adm:pri_md_id, adm:ref_from_fac_id * ID Mapping in OIM

File | Demographics Tab – Referral Fields – Other MD 1, Other MD 2, Primary Physician, Referring Facility

10 3 ID O N 0069 Hospital Service*

11 12 PL O N 0079 Temporary Location*

12 2 IS O N 0087 Pre-Admit Test Indicator*

13 2 IS O N 0092 Re-Admission Indicator*

14 3 IS O N 0023 Admit Source*

15 2 IS O Y 0009 Ambulatory Status*

16 2 IS O N 0099 VIP Indicator Not Used Not Used Database only

17 60 XCN O Y 0010 Admitting Doctor adm:adm_md_id adm:adm_md_id * ID Mapping in OIM

File | Demographics Tab – Admission Fields – Admitting Physician




Page 250

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




18 2 IS O N 0018 Patient Type*

19 4 CX O N Visit Number ESI:ADT - MAPPABLE IIM:ADT (default) - Accounts.InterfaceVisitiNo

MAPPABLE NOTE: The patient IDs contain up to 20 characters. MOSAIQ exports the entire value, not just up to 4 characters.

File | Demographics Tab – Name/IDs Fields – For import, any of the six fields in the ID group box except the first. For export, any of the six fields. To configure mapping in OIM: Interface Properties | Mapping & Segments tab | Visit (PV1-19)

20 50 CM O Y 4 0064 Financial Class Fcl:class_name from Adm:fcl_id

File|Demographics|Billing| Financial class|

21 2 IS O N 0032 Charge Price Indicator*

22 2 IS O N 0045 Courtesy Code*

23 2 IS O N 0046 Credit Rating*

24 2 IS O Y 0044 Contract Code*

25 8 DT O Y Contract Effective Date*

26 12 NM O Y Contract Amount*

27 3 NM O Y Contract Period*

28 2 IS O N 0073 Interest Code*

29 1 IS O N 0110 Transfer To Bad Debt*

30 8 DT O N Transfer To Bad Debt Date*

31 10 ST O N 0021 Bad Debt Agency Code*

32 12 NM O N Bad Debt Transfer Amount*

33 12 NM O N Bad Debt Recovery Amount*




Page 251

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




34 1 IS O N 0111 Delete Account Indicator*

35 8 DT O N Delete Account Date*

36 2 IS O N 0112 Discharge Disposition

37 2 IS O N 0113 Discharged To Location*

38 2 IS O N 0114 Diet Type*

39 2 IS O N 0115 Servicing Facility PRF:Preference_Str or Not used for Lab Orders Outbound, Pharmacy Orders Outbound, and ADT Outbound

File | Import/Export | HL7 Code Export… Change Button Tab – Msg Configuration Codes – Dept ID Code or N/A for Lab Orders Outbound, Pharmacy Orders Outbound, and ADT Outbound

40 1 IS O N 0116 Bed Status*

41 2 IS O N 0117 Account Status adm:accnt_sts (for ESI Manager ADT Inbound only)

adm:accnt_sts File | Demographics Tab – Billing Fields – Account Status

42 12 IS O N 0079 Pending Location*

43 12 IS O N 0079 Prior Temporary Location*

44 19 TS O N Admit Date / Time adm:adm_dttm Option to ignore time is available.

adm:adm_dttm or Charge Outbound: Chg:HospitalStart_DtTm

File | Demographics Tab – Admission Fields – Admit/Registration Date, Admit/Registration Time Or Charge Outbound: Charge slip override




Page 252

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




45 19 TS O N Discharge Date / Time adm:discharge_dttm Option to ignore time is available.

adm:discharge_dttm or Charge Outbound: Chg:HospitalEnd_DtTm

File | Demographics Tab – Admission Fields – Discharge Date Or Charge Outbound: Charge slip override

46 12 NM O N Current Patient Balance*

47 12 NM O N Total Charges*

48 12 NM O N Total Adjustments*

49 12 NM O N Total Payments*

50 20 CX O N Alternate Visit ID MAPPABLE MAPPABLE File | Demographics Tab – Name/IDs Fields – Inbound: Any of the six fields in the ID group box except the first. Outbound: Any of the six IDs To configure mapping in OIM: Interface Properties | Mapping & Segments tab | Alternate Visit (PV1-50)

51 1 IS O N Visit Indicator*

52 60 XCN O Y Other Healthcare Provider*

PV1 Field Notes * This field is not used by MOSAIQ ESI.

MAPPABLE: MOSAIQ maintains six patient ID fields referred to as IDA, IDB, IDC, IDD, IDE and IDF. IDA must be unique. IDB is optionally unique based on department configuration. IDC – IDF are not unique. For both inbound and outbound interfaces, configuration is available to map these IDs to specific fields in HL7 segments PID and PV1. The contents of IDA – IDF can be updated through the interface, but no history is maintained for these IDs. In addition to IDA –




Page 253

IDF, MOSAIQ can also store account number in the Accounts table in Accounts.AccountNo. At most one HL7 patient identifier can be mapped to Account Number. A patient can have multiple Account Numbers. Account Numbers can also have active and inactive date/times. These values are mapped to PV1-44 (Admit date/time) and PV1-45 (Discharge date/time). ID Mapping in OIM: When you export information about a Staff or External Physician, Facility, Location or Payer, you can select the “ID Type” to export. You can configure this within the “Mapping & Segments” tab in the INTERFACE PROPERTIES form.

2 For OIM Charge Export. If there are multiple charges in a message (i.e. the charges are grouped), the first charge in the message will be used to populate this field.

8 For HL7 Charge Export the referring physician is populated from one of two places. If Charge.Referring_MD_ID is not null then it will be used to populate this field. Otherwise, Admin.Ref_MD_ID will be used.

8 For OIM Charge Export. Works the same as HL7 Charge Export above. If there are multiple charges in a message (i.e. the charges are grouped), the referring physician is populated from one of two places. If Charge.Referring_MD_ID is not null for the first charge in the message then it will be used to populate this field. Otherwise, Admin.Ref_MD_ID will be used.

19 If an Inbound ADT interface is configured to map one of the HL7 IDs to Account Number, PV1-19 is mapped to Accounts.InterfaceVisitNo.


39. The “Servicing Facility” field is configurable for outbound interfaces. The HL7 Charge Export interface exports the user-supplied value in the “Dept ID Code” field when the “Dept Code” field = Dept. This field is not exported when using the Lab Order Outbound interface.

44. The admit date / time is also used to populate Accounts.Active_DtTm when ID Mapping is configured to map to Account Number.

44. For OIM Charge Export. If there are multiple charges in a message (that is, the charges are grouped), the admit date / time in this field comes from the first charge in the message if Chg:HospitalStart_DtTm is not null.

45. The discharge date / time is also used to populate Accounts.Inactive_DtTm when ID Mapping is configured to map to Account Number.

45 For OIM Charge Export. If there are multiple charges in a message (that is, the charges are grouped), the discharge date / time in this field comes from the first charge in the message if Chg:HospitalEnd_DtTm is not null.

50. For OIM Charge Export. If the user chooses to map the Account Number to this field, the Account Number comes from the associated Charge record. If there are multiple charges in a message (that is, the charges are grouped), the Account Number in this field comes from the first charge in the message.




Page 254

12.45 PV1 – Patient Visit Segment (OIM:Syndromic Surveillance Interface) The PV1 segment is used by OIM Syndromic Surveillance interface to communicate information on a visit specific basis.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 4 SI O N Set ID - Patient Visit “1”

2 3 IS R N 0004 Patient Class adm:IsInpatient

File | Demographics Tab – Admission Fields – Inpatient checkbox Or Charge slip override IIM ADT: File | Demographics Button – Accounts Buttin – Add Field - Status

3 12 PL O N Assigned Patient Location

4 2 IS O N 0007 Admission Type*

5 20 ST O N Pre-Admit Number*

6 12 PL O N 0079 Prior Patient Location*

7 60 XCN O Y 0010* Attending Doctor

adm:attending_md_id or adm:stf_md2_id or adm:stf_md3_id or adm:stf_md4_id or adm:stf_md5_id or adm:stf_md6_id or adm:stf_md7_id * ID Mapping in OIM

File | Demographics Tab – Attending Fields – Attending Physician

8 60 XCN O Y 0010* Referring Doctor 9 60 XCN O Y 0010* Consulting Doctor 10 3 ID O N 0069 Hospital Service*

11 12 PL O N 0079 Temporary Location*




Page 255

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



12 2 IS O N 0087 Pre-Admit Test Indicator*

13 2 IS O N 0092 Re-Admission Indicator*

14 3 IS O N 0023 Admit Source*

15 2 IS O Y 0009 Ambulatory Status*

16 2 IS O N 0099 VIP Indicator

17 60 XCN O Y 0010 Admitting Doctor 18 2 IS O N 0018 Patient Type*

19 4 CX O N Visit Number MAPPABLE NOTE: The patient IDs contain up to 20 characters. MOSAIQ exports the first 15 characters of the ID field in the Syndromic Surveillance Interface

File | Demographics Tab – Name/IDs Fields – For import, any of the six fields in the ID group box except the first. For export, any of the six fields. To configure mapping in OIM: Interface Properties | Mapping & Segments tab | Visit (PV1-19)

20 50 CM O Y 4 0064 Financial Class

21 2 IS O N 0032 Charge Price Indicator*

22 2 IS O N 0045 Courtesy Code*

23 2 IS O N 0046 Credit Rating*

24 2 IS O Y 0044 Contract Code*

25 8 DT O Y Contract Effective Date*

26 12 NM O Y Contract Amount*

27 3 NM O Y Contract Period*

28 2 IS O N 0073 Interest Code*

29 1 IS O N 0110 Transfer To Bad Debt*




Page 256

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



30 8 DT O N Transfer To Bad Debt Date*

31 10 ST O N 0021 Bad Debt Agency Code*

32 12 NM O N Bad Debt Transfer Amount*

33 12 NM O N Bad Debt Recovery Amount*

34 1 IS O N 0111 Delete Account Indicator*

35 8 DT O N Delete Account Date*

36 2 IS O N 0112 Discharge Disposition In the Syndromic Surveillance A03 message, the value “01” – Patient Discharged to home will be present

37 2 IS O N 0113 Discharged To Location*

38 2 IS O N 0114 Diet Type*

39 2 IS O N 0115 Servicing Facility File | Import/Export | HL7 Code Export… Change Button Tab – Msg Configuration Codes – Dept ID Code or N/A for Lab Orders Outbound, Pharmacy Orders Outbound, and ADT Outbound

40 1 IS O N 0116 Bed Status*

41 2 IS O N 0117 Account Status adm:accnt_sts File | Demographics Tab – Billing Fields – Account Status




Page 257

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



42 12 IS O N 0079 Pending Location*

43 12 IS O N 0079 Prior Temporary Location*

44 19 TS O N Admit Date / Time adm:adm_dttm

File | Demographics Tab – Admission Fields – Admit/Registration Date, Admit/Registration Time Or Charge Outbound: Charge slip override

45 19 TS O N Discharge Date / Time adm:discharge_dttm

File | Demographics Tab – Admission Fields – Discharge Date Or Charge Outbound: Charge slip override

46 12 NM O N Current Patient Balance*

47 12 NM O N Total Charges*

48 12 NM O N Total Adjustments*

49 12 NM O N Total Payments*

50 20 CX O N Alternate Visit ID

51 1 IS O N Visit Indicator*

52 60 XCN O Y Other Healthcare Provider*




Page 258

12.46 QRD – Query Segment The QRD segment is used to define a query.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 19 TS R N Query Date/Time 2 1 ID R N 0106 Query Format Code 'R' NA 3 1 ID R N 0091 Query Priority 4 10 ST R N Query ID 5 1 ID O N 0107 Deferred Response Type 6 19 TS O N Deferred Response

Date/Time

7 5 CQ R N 0126 Quantity Limited Request 8 20 ST R Y Who Subject Filter IDT:IDA File | Demographics

Tab – Name/IDs Fields – First field in the ID group box

9 3 ID R Y 0048 What Subject Filter 10 20 ST R Y What Department Data

Code

11 20 ST O Y What Data Code Value Qual.

12 1 ID O N 0108 Query Results Level

QRD Field Notes * This field is not used by MOSAIQ ESI. 2. “Query format code”: Refer to user-defined table 0106 for valid entries. “R” (Response is in record-oriented format) is the only value currently accepted. 8. “Who subject filter”; Identifies the subject, or who the inquiry is about. This field is used for patient lookup only.




Page 259

12.47 RGS – Resource Group Segment The RGS segment is used to identify relationships between resources identified for an appointment event.

SEQ

LEN

TYP

E

R/O

REP

TBL

NAME




1 4 SI R Set ID – RGS 1

2 3 ID C Segment Action Code*

3 200 CE O Resource Group ID*

RGS Field Notes * This field is not used by MOSAIQ ESI.




Page 260

12.48 RXA – Pharmacy/Treatment Administration Segment (OIM: Immunization Export Interface) The RXA carries the administration data for Immunizations.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 4 NM R Give Sub-ID Counter ‘0’ N/A 2 4 NM R Administration Sub-ID Counter ‘1’ N/A 3 26 TS R Date/Time Start of Administration Vaccine Admin:

If RXO.Outside_Start_Partial_DtTm <> NULL, then RXO.Outside_Start_Partial_DtTm Else RXO.Outside_Stop_Partial_DtTm Historical: Prog_ID 8069 Observe.OBS_Float



MAR View

Administered Dose | Start Date

eChart | Assessments View – MU Stage 2 – 2014 click button - Change MU Stage 2 – 2014 (form) Vaccine Hx Date of Vaccination Activity

4 26 TS RE Date/Time End of Administration* Empty (Assumed to match Date/Time Start)

N/A

5 100 CE R 0292 Administered Code Vaccine Admin: Drug:MEDID => DrugCodeMapping:MEDID RXA-5.1: DrugCodeMapping:CVXCode RXA-5.2: DrugCodeMapping:CVXDescription RXA-5.3: ‘CVX’

File | Library | Medications Formulary | Click button - View Formulary Edit: <Formulary Name> Choose a Drug click button – View Drug Drug Edit: <Drug Name> Drug Codes




Page 261

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



Historical: Prog_ID 8069 OPV.MappingCode^OPV.MappingDesc^OPT.MappingTypeName

eChart | Assessments View – MU Stage 2 – 2014 click button - Change MU Stage 2 – 2014 (form) Vaccine Hx Vaccine

6 20 NM R Administered Amount Vaccine Admin: RXA.Adm_Amount Historical or not valued: 999



MAR View

Medication and Ordered Dose

7 60 CE C(R/

O) Administered Units Vaccine Admin:

RXA-7.1: RXA:Adm_Units => OBD:Label RXA-7.2: : RXA:Adm_Units => OBD:Description RXA-7.3: ‘ISO+’ If RXA-6 = 999 <Empty>



MAR View

Medication and Ordered Dose

8 60 CE O Administered Dosage Form 9 200 CE C(R/

O) NIP0

001 Administration Notes Vaccine Admin:

RXA-9.1: 00 RXA-9.2: New Immunization Record RXA-9.3: ’NIP0001’ Historical Record: Prog_ID 9100

N/A eChart | Assessments View – MU Stage 2 – 2014




Page 262

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



RXA-9.1:OBD:Label RXA-9.2:OBD:Description RXA-9.3: ’NIP0001’

click button - Change MU Stage 2 – 2014 (form) Vaccine Hx Immunization Notes

10 200 XCN RE Administering Provider Vaccine Admin: ESI ID: EID:Code where Ext_Type = ‘ESI’ (Configurable) Based on RXA:Staff_Id and ORC:Inst_ID Staff Name: SCH:Staff_Id->STF:Last_Name, STF:First_Name, STF:Mdl_Initial Format: ESI ID^Lastname^Firstname^MiddleInitial ID Mapping in OIM (see Note) Historical: <Empty>

File | Directories | Staff Directory | (Highlight Staff & Select Change) | Staff Form | Select Edit IDs | Identification with Type = ESI and Department matching order’s department Name of Staff on the appointment

11 200 LA2 RE Administered-at Location RXA-11.1: <Empty> RXA-11.2: <Empty> RXA-11.3: <Empty> RXA-11.4: ext_id:id_code mapped to code “OOID”

Outbound interface manager: Immunization Export Properties Department Setup tab Organization ID

12 20 ST O Administered Per (Time Unit) 13 20 NM O Administered Strength 14 60 CE O Administered Strength Units 15 20 ST C(R/

O) Substance Lot Number If RXA-9.1 is 00 New Immunization

ProgID 8051 Observe.Obs_String Else






Page 263

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



<Empty> MAR View


Vaccine

Lot number 16 26 TS C(RE

/O) Substance Expiration Date If RXA-15 (lot number) is valued

ProgID 8052 Observe.Obs_Float Else <Empty>



MAR View


Vaccine

Expiration Date 17 60 CE C(R/

O) 0227 Substance Manufacturer Name If RXA-9.1 is 00 New Immunization

ObsDef.ProgID = 8053 => RXA-17.1: OPV:MappingCode RXA-17.2: OPV:MappingDesc RXA-17.3: ‘MVX’ Else <Empty>



MAR View


Vaccine

Manufacturer 18 200 CE C(R/

X) NIP0

02 Substance Refusal Reason ObsDef.ProgID 9098 =>

OPV:DataTableItem_OBD_ID RXA-18.1: OPV:MappingCode RXA-18.2: OPV:MappingDesc RXA-18.3: ‘NIP002’ Else <Empty>

eChart | Assessments View – MU Stage 2 – 2014 click button - Change MU Stage 2 – 2014 (form) Vaccine Refusal Reason Substance Refusal Reason`

19 200 CE O Indication 20 2 ID RE 0322 Completion Status If RXA-18 is populated then ’RE’




Page 264

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



Else ’CP’ 21 2 ID RE 0323 Action Code-RXA Voided Immunization Action = Delete:

’D’ New Immunization Action = Add: ’A’


or eChart | Assessments

RXA Field Notes * This field is not used by MOSAIQ ESI.

11. RXA-11.4 is configurable within the OIM Interface Properties of a Immunization interface. The “Department Setup” tab provides data entry to configure the Organization Name and the Organization OID. Enter the desired OID to configure the output to RXA-11.4.




Page 265

12.49 RXC – Pharmacy/Treatment Component Order Segment If the drug or treatment ordered with the RXO segment is a compound drug OR an IV solution, AND there is not a coded value for OBR-4-universal service ID, which specifies the components (base and all additives), then the components (the base and additives) are specified by two or more RXC segments. The policy of the pharmacy or treatment application on substitutions at the RXC level is identical to that for the RXO level.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 1 ID R 0166 RX Component Type A N/A 2 250 CE R Component Code Code:

rxo:req_give_code -> drg:drug_code or drg:drug_code2 or drg:drug_code3 or drg:medid or drg:gcnseqno Description: rxo:req_give_code -> drg:generic_name where this is an additive to a base solution Format: 63^Oncovin Inj

Code: Medication formulary form Fields- Drug Code Drug Code2 Drug Code3 MEDID GCNSeqNo Description: Pharmacy Order (RXO) Form Field – Medication

3 20 NM R Component Amount MQ 1.60- Order Mapping rxo:req_disp_amt MQ 2.00+ Order Mapping rxo:ordering_dose_min

MQ 1.60- Order Mapping Pharmacy Order (RXO) Form Field – Calculated Dose MQ 2.00+ Order Mapping Pharmacy Order Detail (POD) Form Field – Ordering Dose

4 250 CE R Component Units MQ 1.60- Order Mapping rxo:req_disp_units -> obsdef:obd_id->

MQ 1.60- Order Mapping Pharmacy Order (RXO) Form Field – Calculated Units




Page 266

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



obs: code^code MQ 2.00+ Order Mapping rxo:ordering_dose_units_obd_id=> obsdef:obd_id=> obs:code^code Format: mg^mg

MQ 2.00+ Order Mapping Pharmacy Order Detail (POD) Field – Ordering Dose Units

5 20 NM O Component Strength MQ 1.60- Order Mapping Not Available MQ 2.00+ Order Mapping From FDB: rxo:req_give_code -> drg:drg_id->Ext_StrengthDesc (The value, not the units) If manually entered: rxo:req_give_code -> drg:drg_id->strength

MQ 1.60- Order Mapping Not Available MQ 2.00+ Order Mapping Pharmacy Order Detail (POD) Field – Strength

6 250 CE O Component Strength Units

MQ 1.60- Order Mapping Not Available MQ 2.00+ Order Mapping From FDB: rxo:req_give_code -> drg:drg_id->Ext_StrengthDesc (The units, not the value) If manually entered:





Page 267

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



rxo:req_give_code -> drg:drg_id->strengthunit_obd_id-> obsdef:obd_id-> obs: code^code Format: mL/kg^mL/kg

RXC Field Notes * This field is not used by MOSAIQ ESI.




Page 268

12.50 RXO – Pharmacy/Treatment Order Segment This is the “master” pharmacy/treatment order segment. It contains order data not specific to components or additives in a solution. It can be used for any type of pharmacy order, including inpatient (unit dose and compound unit dose), outpatient, IVs, and hyper alimentation IVs (nutritional IVs), as well as other non-pharmacy treatments; for example, respiratory therapy, oxygen, and many nursing treatments. In addition to the pharmaceutical/treatment information, this segment contains additional data such as provider and text comments. A quantity/timing field is not needed in the RXO segment. The ORC segment contains the requested ORC-7-quantity/timing of the original order which does not change as the order is encoded, dispensed, or administered.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 250 CE C Requested Give Code Medication Code: rxo:req_give_code -> drg:drug_code or drg:drug_code2 or drg:drug_code3 or drg:medid or drg: gcnseqno Medication Description: rxo:req_give_code -> drg:generic_name MQ 1.60- Order Mapping IV Solution Code: rxo:prs_id -> cpt:hsp_code or cpt:hsp_code2 or cpt: hsp_code3 or cpt: hsp_code4 or

Medication Code: Medication Formulary, Drug Edit Form Fields - Drug Codes #1 or #2 or #3 or MEDID or GCNSeqNO The actual drug code used depends on the selection chosen in OIM, interface definition, Mapping and Segments, Medication Code (RXO-1) Medication Description: Pharmacy Order (RXO) Form Field – Medication MQ 1.60- Order Mapping IV Solution Code: Procedures and Supplies -> Supply Code The actual supply code used depends on the selection chosen in OIM, interface definition, Mapping and Segments, IV Solution Code (RXO-1)




Page 269

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



cpt: hsp_code5 or cpt:cpt_code IV Solution Description: rxo:prs_id -> cpt: supply_short_desc MQ 2.00+ Order Mapping IV Solution Code: orc:solution_drg_id=> drg:drug_code or drg:drug_code2 or drg:drug_code3 or drg:medid or drg: gcnseqno IV Solution Description: orc:solution_drg_id=> drg:generic_name, drg:SolutionVol, drg:SolutionUnit_OBD_ID=> obd:Label Format: 63^1/2 NS 500 mL

IV Solution Description: Pharmacy Order (RXO) Form Field – New Solution -> Select Supply MQ 2.00+ Order Mapping IV Solution Code: Medication Formulary | Click Solutions button Fields - Drug Codes #1, #2, or #3 (MEDID and GCNSeqNO are filled in from FirstData Bank) The actual drug code used depends on the selection chosen in OIM, interface definition, Mapping and Segments, Medication Code (RXO-1) IV Solution Description: Pharmacy Order Detail (POD) Field – Solution

2 20 NM O Requested Give Amount – Minimum

MQ 1.60- Order Mapping rxo:req_disp_amt

MQ 1.60- Order Mapping Pharmacy Order (RXO) Form Field – Calculated Dose




Page 270

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



MQ 2.00+ Order Mapping rxo:ordering_dose_min

MQ 2.00+ Order Mapping Pharmacy Order Detail (POD) Field – Ordering Dose Min

3 20 NM O Requested Give Amount – Maximum

MQ 1.60- Order Mapping Not Available MQ 2.00+ Order Mapping rxo:ordering_dose_max

MQ 1.60- Order Mapping Not Available MQ 2.00+ Order Mapping Pharmacy Order Detail (POD) Field – Ordering Dose Max

4 250 CE C Requested Give Units MQ 1.60- Order Mapping rxo:req_disp_units -> obsdef:obd_id-> obs: code^code MQ 2.00+ Order Mapping rxo:ordering_dose_units_obd_id=> obsdef:obd_id=> obs:code^code Format: mg^mg

MQ 1.60- Order Mapping Pharmacy Order (RXO) Form Field – Calculated Units MQ 2.00+ Order Mapping Pharmacy Order (RXO) Form Field – Ordering Dose Units

5 250 CE C Requested Dosage Form

MQ 1.60- Order Mapping Not Available MQ 2.00+ Order Mapping rxo:req_give_code -> drg:drg_id->Ext_DoseFormDesc or if nothing there,

MQ 1.60- Order Mapping Not Available MQ 2.00+ Order Mapping Pharmacy Order Detail (POD) Field – Form




Page 271

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



rxo:req_give_code -> drg:drg_id->DoseForm_ obd_id -> obsdef:obd_id-> obs: code^code

6 250 CE O Y Provider's Pharmacy/Treatment Instructions*

7 250 CE O Y Provider's Administration Instructions

MQ 1.60- Order Mapping orc:condition, rxo:condition1, rxo:condition2… Format: ^Order conditions, drug 1 conditions, drug 2 conditions MQ 2.00+ Order Mapping orc.:Condition Format: ^Order conditions

MQ 1.60- Order Mapping Pharmacy Orders (ORC) Form Field – Condition Pharmacy Order (RXO) Form (one for each drug component) Field – Condition MQ 2.00+ Order Mapping Pharmacy Order Detail (POD) Field – Administration Instructions

8 200 CM O Deliver-To Location MQ 1.60- Order Mapping if low order bit of orc:Attributes is set, then “Patient Administrable” MQ 2.00+ Order Mapping if orc:order_type = 5 or 6 (In House Pick Up or External Pick Up), then “Patient Administrable”

MQ 1.60- Order Mapping Pharmacy Orders (ORC) Form Field – Patient Administrable MQ 2.00+ Order Mapping Pharmacy Order List (POL) Popup menu from Add Button

9 1 ID O 0161 Allow Substitutions N, G, T rxo:allow_subs

Pharmacy Order (RXO) Form Field – Substitutions

10 250 CE O Requested Dispense Code*




Page 272

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



11 20 NM O Requested Dispense Amount

MQ 1.60- Order Mapping rxo.DosesToDispense MQ 2.00+ Order Mapping rxo.DosesToDispense

MQ 1.60- Order Mapping Pharmacy Order (RXO) Form Field – Quantity MQ 2.00+ Order Mapping Pharmacy Order Detail (POD) Field – Quantity

12 250 CE O Requested Dispense Units

MQ 1.60- Order Mapping Not Available MQ 2.00+ Order Mapping rxo:DosesToDispenseUnits_obd_id -> obsdef:obd_id-> obs: code^code Format: tablets^tablets

MQ 1.60- Order Mapping Not Available MQ 2.00+ Order Mapping Pharmacy Order Detail (POD) Field – Quantity Units

13 3 NM O Number Of Refills rxo:refills Pharmacy Order (RXO) Form Field – Refill

14 250 XCN C Y Ordering Provider's DEA Number

DEA Number if controlled substance if drg:dea_class = controlled substance orc:ord_provider

Pharmacy Orders Form Field – MD

15 250 XCN C Y Pharmacist/Treatment Supplier's Verifier ID*

16 1 ID O 0136 Needs Human Review*

17 20 ST C Requested Give Per (Time Unit)

MQ 1.60- Order Mapping rxo:give_over

MQ 1.60- Order Mapping Pharmacy Order (RXO) Form Field – Give Over




Page 273

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



MQ 2.00+ Order Mapping orc:duration Format: Mn where n is an integer number of minutes

MQ 2.00+ Order Mapping Pharmacy Order Detail (POD) Field – Duration: days + hours + minutes

18 20 NM O Requested Give Strength

MQ 1.60- Order Mapping Not Available MQ 2.00+ Order Mapping From FDB: rxo:req_give_code -> drg:drg_id->Ext_StrengthDesc (the value, not the units) If manually entered: rxo:req_give_code -> drg:drg_id->strength


19 250 CE O Requested Give Strength Units

MQ 1.60- Order Mapping Not Available MQ 2.00+ Order Mapping From FDB: rxo:req_give_code -> drg:drg_id->Ext_StrengthDesc (the units, not the value) If manually entered: rxo:req_give_code -> drg:drg_id->strengthunit_obd_id-> obsdef:obd_id->





Page 274

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



obs: code^code 20 250 CE O Y Indication*

21 6 ST O Requested Give Rate

Amount MQ 1.60- Order Mapping rxo:rate1, rxo:rate2… Format: rate1, rate2… MQ 2.00+ Order Mapping orc:Rate Format: Rate

MQ 1.60- Order Mapping Pharmacy Order (RXO) Form (one for each drug component) Field – Rate MQ 2.00+ Order Mapping Pharmacy Order Detail (POD) Field – Rate

22 250 CE O Requested Give Rate Units*

RXO Field Notes * This field is not used by MOSAIQ ESI.

1. “Requested Give Code”: Uses Drug Codes #1 or #2 or #3 or MEDID or GCNSeqNO, depending on the Interface Mapping configuration of Field RXO-1 in OIM. 7. If there are any line breaks (CRLF or LF) in the comment, they are replaced with two spaces. 17. The HL7 standard allows any of the forms Dn or Hn or Mn (days, hours, or minutes) in this field. This interface always specifies the value in minutes (Mn). The value in

minutes is computed from the values entered in days, hours, and minutes.




Page 275

12.51 RXR – Pharmacy/Treatment Route Segment This segment is conditional on a route being specified with the order.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 250 CE R 0162 Route MQ 1.60- Order Mapping rxo:admin_route-> obs:label MQ 2.00+ Order Mapping orc:admin_route-> obs:label

MQ 1.60- Order Mapping Pharmacy Orders Form Field - Route MQ 2.00+ Order Mapping Pharmacy Order Detail (POD) Field - Route

2 250 CWE R/O 0163 Administration Site For Immunization Export: ObsDef.ProgID = 8050 => RXA-17.1: OPV:MappingCode RXA-17.2: OPV:MappingDesc RXA-17.3: ‘HL70163’ Otherwise: <Empty>



MAR View


Vaccine

Administration Site

3 250 CE O 0164 Administration Device*

4 250 CWE O 0165 Administration Method*

5 250 CE O Routing Instruction* 6 250 CWE O 0495 Administration Site

Modifier*

RXR Field Notes * This field is not used by MOSAIQ ESI.




Page 276

12.52 SCH – Appointment Activity Information The SCH segment contains general information about the appointment.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 50 ST O Placer Appointment ID SCH:ESI_AppointmentID SCH:ESI_AppointmentID N/A (comes in via Schedule Inbound interface from external system)

2 75 EI R Filler Appointment ID SCH:Sch_Set_ID SCH:Sch_Set_ID N/A 3 5 NM C Occurrence Number* 4 22 EI O Placer Group Number* 5 200 CE O Appointment ID* 6 200 CE R Event Reason Constant value:

AD^Add RE^Rescheduled MO^Modified CA^Cancelled or NS^Noshow See Field Notes.

NA – Derived from the actions the user takes

7 200 CE O 0276 Appointment Reason SCH:Activity (a Hospital Code) See Field Note 7.

SCH:Activity (a Hospital Code)

Daily Master Schedule | Appointment Slip | Activity

8 200 CE O 0277 Appointment Type N/A Constant value: Normal N/A 9 20 NM O Appointment Duration SCH:Duration_time

in minutes SCH:Duration_time in minutes


10 200 CE O Appointment Duration Units M (for minutes)

M (for minutes)

NA




Page 277

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




11 200 TQ R Y Appointment Timing Quantity

Start time: SCH.App_DtTm. End time: Derived from start time plus duration Format: ^^^200401091300^200401091330

Start time: SCH.App_DtTm. End time: Derived from start time plus duration Format: ^^^200401091300^200401091330

Daily Master Schedule | (Select Add) | Appointment Slip | Date, Time and Duration

12 48 XCN O Y Placer Contact Person ESI ID: EID:Code where Ext_Type = ‘ESI’ (Configurable) Based on SCH:Edit_Id and SCH:Inst_ID Staff Name: SCH:Edit_Id->STF:Last_Name, STF:First_Name, STF:Mdl_Initial Format: ESI ID^Lastname^Firstname^MiddleInitial * ID Mapping in OIM

ID of user entering appointment File | Directories | Staff Directory | (Highlight Staff & Select Change) | Staff Form | Select Edit IDs | Identification with Type = ESI and Department matching charge’s department Name of user entering appointment

13 40 XTN O Placer Contact Phone Number*

14 106 XAD O Y Placer Contact Address* 15 80 PL O Placer Contact Location* 16 38 XCN R Y Filler Contact Person Same as Field 12 Same as Field 12




Page 278

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




17 40 XTN O Filler Contact Phone Number*

18 106 XAD O Y Filler Contact Address* 19 80 PL O Filler Contact Location* 20 48 XCN R Y Entered by Person Same as Field 12 Same as Field 12 21 40 XTN O Y Entered by Phone Number SCH:Edit_Id

STF:Work_Phone, SCH:Edit_Id STF:Work_Phone_Ex

ID of user entering appointment File | Directories | Staff Directory | (Highlight Staff & Select Change) | Staff Form | Work Phone & Ext.

22 80 PL O Entered by Location SCH:Inst_ID CFG:Inst_Abrv

Dept of user entering appointment

23 75 EI O Parent Placer Appointment ID*

24 75 EI C Parent Filler Appointment ID SCH:Sch_Wave_ID when SCH:Wave_ID <> 0 else SCH:Sch_Set_ID (See Field Note 24)

NA

25 200 CE O 0278 Filler Status Code See Field Note 25a Constant value: Booked, Cancelled, Started, Complete, or No Show See Field Notes.





Page 279

SCH Field Notes ID Mapping in OIM: When you export information about a Staff or External Physician, Facility, Location or Payer, you can select the “ID Type” to export. You can configure this within the “Mapping & Segments” tab in the INTERFACE PROPERTIES form.

5. Event Reason

Event Reason Description

AD^Add A new appointment has been added

RE^Rescheduled An existing appointment has been rescheduled

MO^Modified An existing appointment has been modified.

CA^Cancelled An existing appointment has been cancelled.

NS^Noshow The patient did not show up for the appointment.

7. Appointment Reason (Inbound Interface)

♦ Activity – This field can be mapped to Appointment Reason (SCH.7.1) OR Universal Service Identifier AIS.3 in the IBD and is an optional field. MOSAIQ Activity value is based on the “Procedure code mapping” in the IBD Configurator. The Activity should be active and belong to the department specified in the interface or to ALL departments thereby making the procedure code global. If the Activity is mapped to AIS.3, ONLY the first of ‘n’ AIS Activity will be processed.

24. Parent Filler Appointment ID

When SCH:Wave_ID <> 0, it will be exported in SCH-24. When SCH:Wave_ID = 0, the value in SCH:Sec_Set_ID will be padded with zeros to form a 10 digit number. For example, if SCH:Wave_ID = 0 and SCH:Sch_Set_ID = 12345, SCH-24 will be set to “1234500000”.




Page 280

25. Filler Status Code (Outbound Interface)

Filler Status Code Description

Booked The indicated appointment is booked

Started The indicated appointment has begun and is currently in progress

Complete The indicated appointment has completed normally (was not discontinued, canceled, or deleted)

Cancelled The indicated appointment was stopped from occurring (canceled prior to starting)

No Show The patient did not show up for the appointment.

25a. Filler Status Code (Inbound Interface)

The below HL7 Filler Status Codes are mapped and imported into the MOSAIQ database.

HL7 Filler Status Code MOSAIQ Field mapping

<Null> Unresolved

Waitlist Unresolved

Booked Unresolved

Deleted Unresolved

Blocked Unresolved

Overbook Unresolved

Complete Unresolved




Page 281

HL7 Filler Status Code MOSAIQ Field mapping

Dc Break

No Show No Show

Started New Start

Cancelled Cancelled

B Break

N No Show

S New Start

X Cancelled

For a cancellation event S15, if there is an empty Filler Status Code (SCH.25 = “”) the Interface will auto Cancel the appointment.




Page 282

12.53 SPM – Specimen Segment (IIM:Lab Result Inbound Interface) The SPM information segment describes the characteristics of a single sample. The SPM segment carries information regarding the type of specimen, where and how it was collected, who collected it and some basic characteristics of the specimen.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 4 SI O N Set ID - TQ1

2 80 EIP O N SpecimenID*

2 EIP O N SpecimenParentIDs*

4 80 CWE_CRE

R N Specimen Type1 obr.specimen_type eChart | Laboratory Right click Lab Result Detail Report

5 CWE O N SpecimenTypeModifier*

6 CWE O N SpecimenAdditives*

7 CWE O N SpecimenCollectionMethod*

8 CWE O N SpecimenSourceSite*

9 CWE O N SpecimenSourceSiteModifier*

10 CWE O N SpecimenCollectionSite*

11 CWE O N SpecimenRole*

12 CQ O N SpecimenCollectionAmount*

13 NM O N GroupedSpecimenCount*

14 ST O N SpecimenDescription*

15 CWE O N SpecimenHandlingCode*

16 CWE O N SpecimenRiskCode*

17 TS RE N Specimen Collection Date/Time 1

obr.specimen_collection_dttm eChart | Laboratory Right click Lab Result Detail Report

18 TS O N SpecimenReceivedDateTime




Page 283

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




*

19 TS O N SpecimenExpirationDateTime*

20 ID O N SpecimenAvailability*

21 CWE O N Specimen Reject Reason1 obr.specimen_reject_reason eChart | Laboratory Right click Lab Result Detail Report

22 CWE O N SpecimenQuality*

23 CWE O N SpecimenAppropriateness*

24 CWE O N Specimen Condition1 Obr.spec_condition eChart | Laboratory Right click Lab Result Detail Report

SPM Field Notes * This field is not used by MOSAIQ ESI. 1 This field is available by default only in the inbound HL7 2.5 LRI template




Page 284

12.54 TQ1 – Timing Quantity Segment (IIM:Lab Result Inbound Interface) The TQ1 segment is used to specify the timing of events and actions such as those that occur in order management and scheduling systems.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 4 SI R N Set ID - TQ1

2 20 CQ O N Quantity*

3 20 RPT O N RepeatPattern*

4 20 TM O N ExplicitTime *

5 20 CQ O N RelativeTimeandUnits *

6 20 CQ O N ServiceDuration *

7 7 TS_3 RE N Start Date/Time1 TQ1.7.1 eChart | Laboratory Right click Lab Result Detail Report

8 8 TS_3 RE N End Date/Time1 TQ1.8.1 eChart | Laboratory

Right click

Lab Result Detail Report

TQ1 Field Notes * This field is not used by MOSAIQ ESI. 1 This field is available by default only in the inbound HL7 2.5 LRI template.




Page 285

12.55 TXA – Transcription document header segment (IIM:Doc Import and OIM:Doc Export) The TXA segment is used to transmit information about a document to External systems. The TXA segment contains information specific to a transcribed document but does not include the text of the document.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 4 SI O N Set ID – Observational Simple

No mapping available “1” None

2 30 ST R N 0270 Document Type obj.doctype obj.doctype eChart | Documents… Column – Document Type

3 20 ST O N 0191 Document Content Presentation *

“TX” None

4 26 TS R N Activity Date obj.encounter_dttm obj.encounter_dttm Format: “YYYYMMDDhhmmss”

eChart | Documents… Column – Encounter

5 250 XCN C Y Primary Activity Provider Code/Name *

6 26 TS O N Origination Date/Time Object:Create_DtTm Format: “YYYYMMDDhhmmss”

7 26 TS C N Transcription Date/Time obj.trans_dttm obj.trans_dttm Format: “YYYYMMDDhhmmss”

eChart | Documents… Column – Transcribed

8 26 TS O N Edit Date/Time Object:Edit_DtTm Format: “YYYYMMDDhhmmss”

9 250 XCN O Y Originator Code/Name obj.dict_id or obj.sanct_id

obj.Dict_ID Ext_ID:ID_Code ^ Staff:Last_Name ^ Staff:First_Name ^ Staff:Mdl_Initial

eChart | Documents… Column – By (After column “Encounter” for obj.dict_id. After column “Approved” for




Page 286

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



MOSAIQ Application Mapping obj.sanct_id)

10 250 XCN O Y Assigned Document Authenticator

obj.sanct_id obj.sanct_id eChart | Documents… Column – By (After column “Approved” for obj.sanct_id)

11 250 XCN C Y Transcriptionist Code/Name

Obj.trans_id obj.Trans_ID Ext_ID:ID_Code ^ Staff:Last_Name ^ Staff:First_Name ^ Staff:Mdl_Initial

eChart | Documents… Column – By (after column Transcribed)

12 400 EI R N Unique Document Number eii.Filler_Order_Number Obj:Obj_ID. 1st element of EI data type.

N/A

13 400 EI C N Parent Document Number *

14 22 EI O N Placer Order Number * 15 400 EI O N Filler Order Number obj.ESI_DocumentID N/A 16 400 ST O N Unique Document File

Name The HL7 encoded

Destination path and file name of the destination file. For the message is Embedded, this field is blank.

N/A

17 400 ST R N Document Completion Status

Obj.Status_Enum “CM” = Completed “CL” = Closed “AU” = Aproved Empty = Void

18 400 ST O N 0272 Document Confidentiality Status *

19 400 ST O N 0273 Document Availability Status

Obj.Status_Enum “CA” = Void




Page 287

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




(Deleted/Canceled) “AV” = Completed, Closed and Approved (Available)

20 400 ST O N 0275 Document Storage Status * 21 30 ST C N Document Change Reason

*

22 250 PTS C Y Authentication Person, Time * Stamp

obj:sanct_ID Ext_ID:ID_Code ^ Staff:Last_Name ^ Staff:First_Name ^ obj:sanct_DtTm Format: “YYYYMMDDhhmmss” Note: The timestamp is the 15th component of this PPN data type field.

23 250 XCN O Y Distributed Copies (Code and Name of Recipients)

Obj:CC1- CC12 Ext_ID:ID_Code ^ Staff:Last_Name ^ Staff:First_Name ^

TXA Field Notes * This field is not used by MOSAIQ ESI. 12. “Unique Document Number”: The permanent identifier for an order and its associated document




Page 290

SEQ

LEN

TYPE

R/O

REP

TBL

NAME


MOSAIQ Application Mapping (Select Code & Select Change) | Procedure Code Form | Code Tab | ProcLabel6

14 10 ST O N Public/private indicator CHG:PRS_IDCPT:Rsp_Center Code Mgmt | Code Capture | Code File | Libraries | Procedures and Supplies (Select Code & Select Change) | Procedure Code Form | Capture/Schedule Tab | Cost Center

15 15 ST O N NDC Chg:NDCOverride Code Mgmt | Code Capture Tab – Billing Overrides Field – NDC

16 12 CP O N Unit Price CHG:CHG_IDANSICTP:UnitPrice Code Mgmt | Code Capture Tab – Billing Overrides | Button – Drug Pricing Field – Unit Price

17 6 NM O N Unit Quanity CHG:CHG_ID ANSICTP:UnitQuantity

Code Mgmt | Code Capture Tab – Billing Overrides | Button – Drug Pricing Field – Unit Quantity

18 2 ST O N Unit Measurement CHG:CHG_ID ANSICTP:UnitMeasurement

Code Mgmt | Code Capture Tab – Billing Overrides | Button – Drug Pricing Field – Unit Measurement

19 30 ST O N Proc Label 1 Chg:Inst_ID CPTConfig:ProcedureLabel1

File | System Utilities | Department Setup… (Select Department) Tab – Administrative | Button – Procedure Label Config Fields – Procedure Label 1




File | System Utilities | Department Setup… (Select Department)




Page 291

SEQ

LEN

TYPE

R/O

REP

TBL

NAME


MOSAIQ Application Mapping Tab – Administrative | Button – Procedure Label Config Fields – Procedure Label 3







25 20 ST O N Appointment ID Chg:SCH_ID SCH:Sch_Set_ID

This value isn’t displayed within MOSAIQ. However, the Procedure DateTime and Activity are visible in both the Code Capture form (next to the Appt drop-down) and in the Code Capture Summary form (Appointment column in the grid)

26 60 XCN O N Other Staff Chg:Other_Staff_ID * ID Mapping in OIM

Code Mgmt | Code Capture Field: Other Staff

27 60 XCN O N Charge Capture User Chg:Create_ID * ID Mapping in OIM

Code Mgmt | Code Capture | <F9> File Edit History Group Box: Created Field: By Staff

28 26 TS O N Charge Create Date/Time Chg:Create_DtTm Code Mgmt | Code Capture | <F9> File Edit History Group Box: Created Field: On Date, At Time




Page 292

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



29 20 ST O N External Appointment ID Chg:SCH_ID SCH:ESI_AppointmentID

This value isn’t displayed within MOSAIQ. However, the Procedure DateTime and Activity are visible in both the Code Capture form (next to the Appt drop-down) and in the Code Capture Summary form (Appointment column in the grid)

ZCH Field Notes ID Mapping in OIM: When you export information about a Staff or External Physician, Facility, Location or Payer, you can select the “ID Type” to export. You can configure this within the “Mapping & Segments” tab in the INTERFACE PROPERTIES form.




Page 293

12.57 ZCP – Proprietary course segment

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




1 2 ST R N Course PatCPlan:Course

eChart | Diagnoses and Interventions… | (Click Add Care Plan) | Patient Care Plan Field: Course

2 20 ST O N Intent PatCPlan.Tx_Intent eChart | Diagnoses and Interventions… | (Click Add Care Plan) | Patient Care Plan Field: Intent

3 8

DS O N Start date PatCPlan.Ef_DtTm eChart | Diagnoses and Interventions… | (Click Add Care Plan) | Patient Care Plan Field: Start Date

4 60 XCN O N Assigning MD PatCPlan.MD_ID eChart | Diagnoses and Interventions… | (Click Add Care Plan) | Patient Care Plan Field: Assigning MD

ZCP Field Notes 1. None




Page 295

SEQ

LEN

TYPE

R/O

REP

TBL

NAME




7 10 ST O N Stage, clinical MED: Stage_Group

eChart | Diagnoses and Interventions… | (Click Add Diagnosis) | (Click Add) | Diagnosis and Staging Field: Clinical – Stage

8 60 CE O N Staged By

TNMStage:Edit_ID

eChart | Diagnoses and Interventions… | (Click Add Diagnosis) | (Click Add) | Diagnosis and Staging Field: Clinical – Staged by Will default to Staff name in interface configuration if not present in the message

9 60 CE O N Morphology code and description

MED:Histology

eChart | Diagnoses and Interventions… | (Click Add Diagnosis) | (Click Add) | Diagnosis and Staging Field: Morphology

10 10 ST O N Type MED:Diag_Class

eChart | Diagnoses and Interventions… | (Click Add Diagnosis) | (Click Add) | Diagnosis and Staging Field: Type

11 20 ST O N Category MED:Category

eChart | Diagnoses and Interventions… | (Click Add Diagnosis) | (Click Add) | Diagnosis and Staging Field: Category

ZDX Field Notes 2. None




Page 296

12.59 ZIL – Insurance Local Segment The ZIL segment contains the information required to add, update or delete payers. This segment is a local segment for use with message type ZIN event code Z02 only.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME

MOSAIQ DB Mapping (Inbound Only)


1 2 ID R N Insurance Action Code [A/U/D]

2 6 ST R N Insurance Company ID NOTE: This field is optional for our use even though HL7 shows it as mandatory.

pay:miscid File | Directories | Payer Directory… Change pushbutton Tab – General Field – Ext ID

3 8 ID R N Insurance Plan ID eid:id_code File | Directories | Payer Directory… Change pushbutton Edit IDs pushbutton Field – Identification column value when Type column value = ‘ESI’

4 20 ST O N Insurance ID Number pay:HCFA_PayerID File | Directories | Payer Directory… Change pushbutton Tab – General Field – ID No.

5 40 ST R N Insurance Company Name

pay:payer_name Payer Information. General Tab. Name.

6 106 AD O N Insurance Company Address

pay:adr1, pay:adr2, pay:city, pay:state_province, pay:postal, pay:country

File | Directories | Payer Directory… Change pushbutton Tab – Contact Address/Phone Fields – 1, 2, City, State, Postal, Country.

7 30 PN O N Insurance Company Contact Person

pay:contact File | Directories | Payer Directory… Change pushbutton Tab – Contact Address/Phone Field – Contact

8 40 TN O Y 3 Insurance Company pay:pri_phone, pay:pri_phone_ex, File | Directories | Payer Directory…




Page 297

SEQ

LEN

TYPE

R/O

REP

TBL

NAME

MOSAIQ DB Mapping (Inbound Only)


Phone Number pay:sec_phone, pay:sec_phone_ex, pay:fax

Change pushbutton Tab – Contact Address/Phone Field – Primary, x, Secondary, x, Fax

9 10 ST O N Accounting Type pay:acc_type File | Directories | Payer Directory… Change pushbutton Tab – Billing Field – Accounting Type

10 10 ST O N Bill Type * 11 1 ST O N Authorization Required pay:auth_req File | Directories | Payer Directory…

Change pushbutton Tab – General Field – Prior Authorization Required.

ZIL Field Notes * This field is not used by MOSAIQ ESI. 1. “Insurance action code”: The code used to identify the action to be performed by this message. Valid codes are: A (Add), U (Update), and D (Delete). 2. “Insurance Company ID”: The program or plan id of the insurance company. 3. “Insurance Plan ID”: This code serves to uniquely identify the insurance plan via the interface. This ID serves as the ESI Coordinating ID for this Payer

and is also used to identify the payer within the INI segment (IN1-2). 4. “Insurance ID Number”: Another code that serves to uniquely identify the insurance company. Can be used for an ID assigned to the facility by the

insurance company. 9. “Accounting type”: The accounting method used by the payer. 10. “Bill type”: The type of bill to send.

11. “Authorization required”: Based on the type of insurance, some coverages require an authorization number or code be obtained prior to all non-emergency admissions and within 48 hours of an emergency admission. Y - Authorization Required; N - No Authorization Required.




Page 298

12.60 ZPH – Physician Identification Local Segment The ZPH segment contains the information required to add, update or delete Staff and External Physicians. This segment is a local segment for use with message type ZPA event code Z01 only.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 2 ID R N Doctor Action Code [A/U/D]

“A” or “U” or “D”

2 2 ID R N Staff / External [S/E] “S” or “E” 3 60 XCN R N 0010

* Doctor

• External eid:id_code, eid:ext_type = “ESI”, ext:last_name, ext:first_name

File | Directories | External Directory… Change pushbutton Tab – Work Fields – Last Name, First Name, Mdl Initial Edit IDs pushbutton. Field – Identification (for eid:id_code)

• Staff eid:id_code, eid:ext_type = “ESI” stf:last_name, stf:first_name, stf:mdl_initial

File | Directories | Staff Directory… Change pushbutton Tab – Work Fields – Last Name, First Name, Mdl Initial Edit IDs pushbutton. Field – Identification (for eid:id_code)

4 20 ID O N Provider Number eid:id_code eid:ext_type = “MEDICARE”

File | Directories | Staff Directory… or File | Directories | External Directory… Change pushbutton Edit IDs pushbutton. Field – Identification (for eid:id_code)

5 20 ID O N Provider Number Other eid:id_code eid:ext_type = “MEDICAID”

File | Directories | Staff Directory… or File | Directories | External Directory… Change pushbutton Edit IDs pushbutton.




Page 299

SEQ

LEN

TYPE

R/O

REP

TBL

NAME


MOSAIQ Application Mapping Field – Identification (for eid:id_code)

6 20 ID O N License Number eid:id_code, eid_ext_type = “ST LICENSE”


7 20 ID O N Universal ID eid:id_code, eid:ext_type = “UPIN”


8 9 ID O N Tax ID Number eid:id_code, eid:ext_type = “TAX ID”


9 106 XAD O N Doctor Address • External ext:adr1, ext:adr2,

ext:city, ext:state_province, ext:postal, ext:country

File | Directories | External Directory… Change pushbutton Fields – 1, 2, City, State, Postal, Country

• Staff stf:adr1, stf:adr2, stf:city, stf:state_province, stf:postal, stf:country

File | Directories | Staff Directory… Change pushbutton Fields – 1, 2, City, State, Postal

10 40 XTN O Y Phone Number – Home Format: Uses only component 1 of XTN. • External ext:home_phone,

ext:home_phone_ex File | Directories | External Directory… Change pushbutton Fields – Home Phone, ext only in database

• Staff stf:home_phone, stf:home_phone_ex

File | Directories | Staff Directory… Change pushbutton Fields – Home Phone, ext only in database

11 40 XTN O Y 3 Phone Number – Business

Format: Uses only component 1 of XTN.




Page 300

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



• External ext:work_phone, ext:work_ext, ext:pager_no, ext:fax_no

File | Directories | External Directory… Change pushbutton Fields – Work Phone, Ext, Pager, Fax

• Staff stf:work_phone, stf:work_ext, stf:pager_no, sft:fax

File | Directories | Staff Directory… Change pushbutton Fields – Work Phone, Ext, Pager, Fax

ZPH Field Notes 1. “Doctor action code”: The code used to identify the action to be performed by this message. Valid codes are: A (Add), U (Update), and D (Delete). 2. “Staff / External”: The code used to identify whether the physician is staff or external. Valid codes are S (Staff) and E (External). 3. “Doctor”: In the form physician id^name. Both physician ID and physician name must be present. NOTE: The “id” component (often referred to as the

ESI Coordinating ID) is used to uniquely identify the physician. No secondary searching is performed to identify the physician.




Page 301

12.61 ZPR – Protocol Information The ZPR segment contains protocol information associated with a medication order.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 60 ST O N Protocol name orders.cpl_id->cplan.cplan_name

2 20 ST O N Regimen name orders.cpl_id ->cplan.regimen

3 6 NM O N Protocol number of cycles orders.cpl_id ->cplan.cycles

4 6 NM O N Protocol cycle length days orders.cpl_id ->cplan.cycle_number

5 6 NM O N Cycle number orders.cycle_number

6 6 NM O N Day number orders.cycle_day

ZPR Field Notes 1. None




Page 302

12.62 ZPT – Proprietary patient segment

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 20 ST O N User Defined Data 1 Label: Chg:Inst_IDConfig:User_Defined_Label1 Value: Admin:User_Defined_Pro_Id_1Prompt:Text Format: Label^Value

Label: File | System Utilities | Department Setup… (Select Department) Tab – Misc. Configuration Fields – User Defined Label 1 Value: Patient demographics | Attending | User Defined Label 1

2 20 ST O N User Defined Data 2 Label: Chg:Inst_IDConfig:User_Defined_Label2 Value: Admin:User_Defined_Pro_Id_2Prompt:Text Format: Label^Value

Label: File | System Utilities | Department Setup…(Select Department) Tab – Misc. Configuration Fields – User Defined Label 2 Value: Patient demographics | Attending | User Defined Label 2

3 20 ST O N User Defined Data 3 Label: Chg:Inst_IDConfig:User_Defined_Label3 Value: Admin:User_Defined_Info1 Format: Label^ Value


4 20 ST O N User Defined Data 4 Label: Chg:Inst_IDConfig:User_Defined_Label4

Label: File | System Utilities | Department




Page 303

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



Value: Admin: User_Defined_Info2 Format: Label^Value

Setup…(Select Department) Tab – Misc. Configuration Fields – User Defined Label 4 Value: Patient demographics | Attending | User Defined Label 4

5 20 ST O N User Defined Data 5 Label: Chg:Inst_IDConfig:User_Defined_Label5 Value: Admin: User_Defined_Info3 Format: Label^Value


6 20 ST O N User Defined Data 6 Label: Chg:Inst_IDConfig:User_Defined_Label6 Value: Admin: User_Defined_Info4 Format: Label^Value


7 20 ST O N Trace Status Ident:Trace_Status File | Demographics Tab – Name/IDs Group – IDs Field – Trace Status




Page 306

12.64 ZTX – Proprietary treatment segment The ZTX segment is currently exported with the HL7 DFT message when configured in the charge export configuration parameters. It includes the patient treatment data for the captured charge.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 2 ST O N Treatment Status Abbreviation For Sch_ID related to Charge of interest: CHG.SCH_ID SCH.SCH_ID SSM.ScheduleStatusID SS. StatusAbbreviation

Appointment: Daily Master Schedule | Appointment Slip | Status Capture Charge from Appointment: Daily Master Schedule | (Select an Appointment) | (Right Click) | Capture Only… | (Enter Charge Info)

2 10 ST O N Treatment Status Short Description For Sch_ID related to Charge of interest: CHG.SCH_ID SCH.SCH_ID SSM.ScheduleStatusID SS. StatusShortDesc


3 30 ST O N Treatment Status Long Description For Sch_ID related to Charge of interest: CHG.SCH_ID SCH.SCH_ID SSM.ScheduleStatusID SS. StatusLongDesc


4 20 ST O N Prescription Site Name For Sch_ID related to Charge of interest: CHG.SCH_ID DSS.SCH_ID DSS.Site_Name

eChart | Diagnosis and Interventions Tab – Radiation Folder – Rad Rx: (Site Name) Change pushbutton Field –Rx Site




Page 307

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



5 20 ST O N Course number DSS.Course eChart | Diagnosis and Interventions Tab – Radiation Folder – Rad Rx: (Site Name) Change pushbutton Field –Course

6 20 CQ O N Prescribed fractional dose + unit of measure

DSS. RxFxUniformDoseIncGray Unit of measure : Config.DoseUnits(0 cGray,1 Gray) NOTE: If the prescribed fractional dose is not uniform (DSS. IsRxFxDoseUniform=0 ), the field is not populated.

eChart | Diagnosis and Interventions Tab – Radiation Folder – Rad Rx: Change Pushbutton Upper Pane - Column: Fractions, Field: Dose NOTE: If the prescribed fractional dose is not uniform, it is displayed as ‘var’ in Mosaiq to indicate it is variable.

7 20 CQ O N Prescribed total dose + unit of measure

DSS. RxTotalDoseIncGray Unit of measure : Config.DoseUnits(0 cGray,1 Gray)

eChart | Diagnosis and Interventions Tab – Radiation Folder – Rad Rx: Change Pushbutton Upper Pane - Column: RxDose, Field: Rx

8 20 NM O N Actual fractions delivered to the prescription site

DSS. ActualFractions eChart | Diagnosis and Interventions Tab – Radiation Folder – Rad Rx: Change Pushbutton Upper Pane - Column: Fractions, Field: Act

9 60 ST O N Prescription site pattern comment DSS.Frac_Pattern eChart | Diagnosis and Interventions Tab – Radiation Folder – Rad Rx: Change Pushbutton Field: Pattern NOTE: This is the free text field over the ‘Comment’ field in the Radiation Prescription window.




Page 308

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



10 20 CQ O N Actual session delivered dose + unit of measure

DSS. SessionActualDoseIncGray Unit of measure : Config.DoseUnits(0 cGray,1 Gray) E.g. 90^cGray

eChart | Radiotherapy Treatment Column: treated Rx site Column: Dly

11 20 CQ O N Actual total dose + unit of measure DSS. ActualTotalDoseIncGray Unit of measure : Config.DoseUnits(0 cGray,1 Gray) E.g 1485^cGray

eChart | Diagnosis and Interventions Tab – Radiation Folder Rad Rx: Change Pushbutton Upper Pane - Column: RxDose, Field: Act

12 20 ST O N Prescribed technique DSS.Technique eChart | Diagnosis and Interventions Tab – Radiation Folder – Rad Rx: Change Pushbutton Lower Pane- Field: Technique

13 CQ O N Prescribed biologic fractional dose + unit of measure

DSS. RxFxUniformDoseInCcGE Unit of measure : BioEffDose.BEDUnits_Enum (1 CGE, 2 CcGE NOTE: If the prescribed fractional dose is not uniform (DSS. IsRxFxDoseUniform=0 ), the field is not populated.

eChart | Diagnosis and Interventions Tab – Radiation Folder – RAD RX (Sitename, Fractions) Change Pushbutton Upper Pane - Column: Fractions, Field: BED NOTE: If the prescribed fractional dose is not uniform, it is displayed as ‘var’ in Mosaiq to indicate it is variable.

14 20 CQ O N Prescribed biologic total dose + unit of measure

DSS. RxTotalDoseInCcGE Unit of measure : BioEffDose.BEDUnits_Enum (1 CGE, 2 CcGE E.g. 300.00^CGE

eChart | Diagnosis and Interventions Tab – Radiation Folder – Rad Rx: Change Pushbutton Upper Pane - Column: RxDose, Field: RxBED




Page 309

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



15 20 CQ O N Actual session biologic dose + unit of measure

DSS. SessionActualDoseInCcGE Unit of measure : BioEffDose.BEDUnits_Enum (1 CGE, 2 CcGE E.g. 5.50^CGE

eChart | Radiotherapy Treatment Column: treated Rx site Column: Dly

16 20 CQ O N Actual total biologic dose + unit of measure

DSS. ActualTotalDoseInCcGE Unit of measure : BioEffDose.BEDUnits_Enum (1 CGE, 2 CcGE

eChart | Diagnosis and Interventions Tab – Radiation Folder – Rad Rx: Change Pushbutton Upper Pane - Column: RxDose, Field: Act BED

17 6 NM O N Elapsed days DSS.ElapsedDays eChart | Diagnosis and Interventions Right Mouse Click – Dose Site Summary…. Field: Days

18 26 TS O N Start date DSS.Start_DtTm eChart | Diagnosis and Interventions Tab – Radiation Right mouse Click- Dose Site Summary… Field: StartTx

19 26 TS O N Last date DSS.Last_DtTm eChart | Diagnosis and Interventions Tab – Radiation Right mouse Click- Dose Site Summary… Field LastTx

20 20 NM O N Prescribed number of fractions DSS. RxFractions eChart | Diagnosis and Interventions Tab – Radiation Folder – Rad Rx: Change Pushbutton Upper Pane - Column: Fractions, Field: Rx




Page 310

ZTX Field Notes Field 1 Treatment Status Abbreviation – In Charge Export, the treatment status is taken from the appointment status associated with the charge, if any. Fields 6- 7 - If MOSAIQ is configured to display Gray, dose values in cGray will be converted to Gray. Fields 11-12 If MOSAIQ is configured to display Gray, dose values in cGray will be converted to Gray. Fields 14-17 If MOSAIQ is configured to display CGE, dose values in CcGE will be converted to CGE. Fields are populated only if only if Biologic Equivalent Dose (BED) is applicable for the Site




Page 311

12.65 ZXO - Proprietary Pharmacy/Treatment Order Extensions This proprietary Z segment provides the Dose Basis information for Pharmacy Orders.

SEQ

LEN

TYPE

R/O

REP

TBL

NAME



1 20 NM C Dose Basis MQ 1.60- Order Mapping rxo:req_give_min MQ 2.00+ Order Mapping rxo:req_give_min

MQ 1.60- Order Mapping Pharmacy Order (RXO) Form Field – Dose Basis MQ 2.00+ Order Mapping Pharmacy Order Detail (POD) Field – Dose Basis

2 250 CE C Dose Basis Units MQ 1.60- Order Mapping rxo:req_give_units -> obsdef:obd_id-> obs: code^code MQ 2.00+ Order Mapping rxo:req_give_units -> obsdef:obd_id-> obs: code^code Format: mL/kg^mL/kg

MQ 1.60- Order Mapping Pharmacy Order (RXO) Form Field – Dose Basis Units MQ 2.00+ Order Mapping Pharmacy Order Detail (POD) Field – Dose Basis Units

ZXO Field Notes (None)

MOSAIQ™

Manufacturer

Elekta Business Area Software Systems

IMPAC Medical Systems, Inc.

100 Mathilda Place

5th Floor

Sunnyvale, CA 94086

USA

European Union Authorized

Representative

Elekta Limited

Linac House, Fleming Way

Crawley, West Sussex

RH10 9RR,

United Kingdom

Phone: +44 129 365 4242

Fax: +44 1293 471347

www.elekta.com Human Care Makes the Future Possible Corporate Head Office: Regional Sales, Marketing, and

Service:

Elekta AB (publ)

Box 7593, SE-103 93 Stockholm, Sweden

Tel +46 8 587 254 00

Fax +46 8 587 255 00

[email protected]

North America

Atlanta, USA

Tel +1 770 300 9725

Fax +1 770 448 6338

[email protected]

Europe, Latin America,

Africa, Middle East & India

Tel +44 1293 544 422

Fax +44 1293 654 321

[email protected]

Asia Pacific

Tel +852-2891 2208

Fax +852-2575 7133

[email protected]