Procedure Template - Quia



Title: Generic HL7 Interface Specifications

Number: AI 02G

Revision: 1

Effective Date: 7/8/02

Page: 1 of 79 |[pic] | |

1. Purpose:

This procedure contains the Generic HL7 Interface Specifications document.

2. Scope:

The Generic HL7 Interface Specifications document is used for new interface installations. Interface analysts, senior programmers, and programmer/analysts will utilize this document.

3. Procedure:

1. The first page must be removed before this document is sent to an external client. Remove the first page and save to your desktop.

2. The interface specification follows this page.

[pic]

Misys Generic HL7

Interface Specification

Site Code: Misys use only: Site ID:

Site Name: Projects:

Site Location: Analyst: Interface Numbers:

Lab Contacts: MIS Contacts:

System Manager: Name:

E-mail: E-mail:

Phone: Phone:

Fax: Fax:

HIS Vendor Information: HUB/Engine Information:

Vendor Name: HUB Name:

Product Name/Version: Contact Name:

Contact Name: E-mail:

E-mail: Phone:

Phone:

Misys Implementation Consultant/BVC Consultant (if applicable):

***Please indicate interfaces to be installed (indicate all that apply):

ADT Order Entry

Result Reporting: Segmented (ORU) Formatted (UDM) Both (ORU+UDM)

Result Inquiry

Billing: Electronic batch or FTP

Stand alone or Piggy back on results interface

***Please note that if we will be implementing ADT and OE interfaces, we expect that both the ADT and OE transactions will be sent on one physical connection. Be aware that if you choose to send ADT and OE to separate ports, Misys has no control over orders processing before ADT. Therefore, if orders arrive before ADT, the orders will not file and an error message will be produced.

If installing only an orders (inbound) interface, it may affect your existing results (outbound) interface. For example, HIS order number format may need to be changed on the result interface to accommodate the order number of the new order interface.

It is the responsibility of the client to research the possible impact of a new orders interface on the existing results interface. Modifications to the existing results interface may result in additional fees. Please indicate if the orders interface should be added to your current ADT or whether it should stand alone (see warning above).

In addition, installing only a results (outbound) interface may affect your current order (inbound) interface. For example, lab generated orders may be sent on the new result interface and order number update may need to be activated or deactivated on the current order interface.

It is the responsibility of the client to research the possible impact of a new results interface on the existing orders interface. Modifications to the existing orders interface may result in additional fees.

On which Misys Laboratory Information System (LIS) software version will these interfaces be installed? _______________

This code should be shipped to the test area named _____________ on the _____________ CPU.

Date specs completed: _______________

Scheduled Live date: _______________

You will need an overlay in the test area that was cut no later than 6 months prior to the start date of this project. This overlay must be moved live prior to this interface going live.

What is the cut date of the overlay in the test area? _______________

If older than 6 months, when is the new overlay scheduled to be put in the test area? _______________

When is the anticipated date this overlay will be moved to the live area? _______________

Communication Protocol (indicate one):

TCP/IP RS232 Other (specify)

[pic] Application Interfacing Department

Interface Implementation Client Requirements

Summary

In an effort to provide the most efficient and effective implementation schedule possible, the Application Interfacing Department has developed a list of requirements to help facilitate the process. These requirements were developed as a result of our extensive experience in the clinical information system integration environment and represent items that typically cause delays in the process. Client adherence to these requirements is crucial to the success of the implementation process, since resources are allocated at specified milestones in the process, and any deviation from the associated schedule will jeopardize the resource allocation.

Requirements

1. An overlay must have been installed in the test area within the last six months of the project start date and the overlay needs to be moved live prior to the project. It is the responsibility of the site to arrange to have the overlay scheduled and to coordinate the overlay live date with the interface(s) live date. Please contact software distribution for assistance.

2. All vendor systems and associated software/hardware, e.g. modems, phone lines, terminal servers must be installed and ignition tested before communication testing with the Misys system can begin. Communication protocols/methods will be defined in the specification negotiations and will not be changed after code has been delivered.

3. Dedicated resources must be available to assist with the testing of all hardware and software components associated with the interface installation. These resources should be experienced in the domain relative to their assignment, and have the authorization to integrate system enhancements if necessary. In addition, these resources should also be defined prior to the beginning of the specification negotiation process and will require coverage during absences.

4. A well defined test plan must be used to validate the new interface. Misys will provide a generic test plan, when available, for the Laboratory Information System (LIS); however, you will need to refine the plan to include site-specific workflow considerations for your organization.

5. Be aware that if this interface is replacing an existing customized interface and the same customization is desired on the new interface, it must be negotiated with your interface analyst and additional fees will be charged.

Process Delays

Should there be delays related to the availability of hardware, software, personnel, or inactivity consistent with the milestone schedule, Misys reserves the right to reschedule the project for a later date. If the project is idle for a period of three weeks, the project will be placed on hold and rescheduling will be necessary. Depending on the delay, a new overlay may be needed before the project can resume. It should be noted that with the current work in progress it may be 35-120 days before we will be able to resume activity.

In addition, if the interface installation exceeds a 6-month period, from the date it was started, Misys reserves the right to invoice you for the interface(s). If my organization cancels the interface order(s) after Misys has started work on the interface installation, my organization will be invoiced for the work Misys completed prior to the cancellation.

Foreword

The following specifications were designed to be detail oriented and should encompass all common HL7 transaction types. A copy of this document, completed to the best of your ability, must be returned to your assigned Misys Interface Analyst in order to begin the specification negotiation process. In order to complete the specs, you will need to consult with your HIS vendor and/or Interface Engine representative. In order to assist them, copies of this document may be distributed as needed. Please review this document and answer as many questions as possible. After your initial review, your Interface Analyst will contact you to set up a series of conference calls to re-examine and finalize this document. Accurate completion of this document is imperative for it will be used to code your interface(s).

At the end of specification negotiation, you will be required to sign-off on the completed specifications for each interface being installed. The following page is provided for this purpose. The sign-off indicates that the completed specifications are what the Misys Healthcare Systems Application Interfacing department should use to code your interface(s). Any issues that arise after the specification sign-off is complete will be addressed on an individual basis and may compromise a scheduled live date and/or incur additional fees for resolution.

Application Interface Specification

and Schedule Approval

The Misys Interface Analyst and I have negotiated the Application Interface Specification document. I understand that these specifications will be followed precisely by the Misys programmer when developing and installing the interface code. By signing below, I am assuring that the specifications have been completed according to the requirements of the Misys Misys Lab system and the other vendor. In addition, I understand that any changes to the interface specification may result in additional fees and may impact the interface schedule.

I have reviewed the schedule and milestone dates and agree to the proposed schedule. I understand that failure to adhere to this schedule may adversely affect the interface live date. Misys reserves the right to reschedule the interface installation for a later date if the agreed upon schedule is not followed.

If I have an overlay scheduled, or have an overlay in the test area, I understand that the overlay must be moved to the production area prior to the interface live date. Should my last overlay be older than 6 months, Misys will evaluate and determine if an overlay is necessary. If an overlay is needed this interface installation will be put on hold until the overlay is installed in the test area.

I understand if this interface installation project exceeds a 6 month period from the date it was started, Misys reserves the right to invoice my organization for the cost of the interface. I also understand that if my organization cancels the interface order after Misys has started work on the interface installation, my organization will be invoiced for the work Misys completed prior to the cancellation.

______________________________________ _____________________

Site Name Site Code

______________________________________ _____________________

Site Representative, Title Date

______________________________________ _____________________

Other System Representative, Title Date

______________________________________ _____________________

Misys Representative, Title Date

Please fax this page with your signatures to: (520) 733-6630

Application Interfacing Specification Document

The following pages present information and require answers related to communications, ADT and Order Entry inbound from your HIS to the Misys LIS, and outbound transactions from Misys to your HIS.

-----------------------------------------------------------------------------------

1. CPU Hardware

a. Is your site using multiple CPUs for the lab system? YES NO

b. If yes, indicate your CPU configuration:

|FlexiLink (A-B link) |

|Flexi 3-R (A-C link) |

|A-B-C link |

Note: If using multiple CPU’s, you must have a procedure to switch IP addresses during a degrade

(downtime of primary CPU)

2. Multiple Facilities

a. Will transactions for more than one hospital id be going through these interfaces?

YES NO

b. If yes, the HID should be included in the PID;3.4 for all transactions.

Will you accommodate this? YES NO N/A

c. If no, what method will you use to indicate the facility id?

d. Will you send the numeric HID or the mnemonic code for the HID?

numeric mnemonic N/A

e. List all of the HIDs (hospital IDs) that will be included in these interfaces:

|HID number |HID code |Hospital/facility name |

| | | |

| | | |

| | | |

| | | |

| | | |

| | | |

| | | |

| | | |

| | | |

| | | |

| | | |

NOTE: For MULHOS sites, a separate processor will be set up for each hospital.

This requires that HMA maintenance be defined for each hospital.

3. TCP/IP Communications

a. TCP/IP communications is a real-time process using Berkeley sockets. For all transactions, the receiving system (server) establishes a service and the sending system (client) attaches to it. For example, for the ADT/OE interface, Misys will establish the service on its machine and the HIS/HUB will connect to it. The reverse is true for the results interface. Please verify the client/server relationship for each interface by completing the table below. Insert Misys in one box and HIS or HUB in the other box for each interface:

| |ADT/OE |RR/Billing |other |

|Client | | | |

|Server | | | |

b. List the IP addresses of both the HIS or HUB and Lab CPUs and the socket numbers for the Lab machine that will be used for your interfaces:

HIS/HUB CPU address =

LAB CPU address =

|Lab Production | |Lab Test | |

|Inbound socket | |Inbound socket | |

|(ADT/OE) | |(ADT/OE) | |

|Outbound socket | |Outbound socket | |

|(RR/Billing) | |(RR/Billing) | |

|other (specify) | | | |

NOTE: The sockets must be assigned numbers that are higher than 2048. The numbers can be

assigned by the programmers who test the interface when testing begins.

4. Transaction Framing

The following questions apply to the communication envelope for all transactions both inbound and outbound. Unless otherwise specified, the same transaction framing will be expected for both inbound and outbound transactions and message acknowledgments. The characters listed in below represent ASCII characters.

a. What character(s) will be immediately before the MSH segment?

NONE Other (specify)

b. What character will indicate the end of each HL7 segment?

Other (specify)

c. What character(s) will indicate the end of the HL7 message?

Other (specify)

5. Acknowledgments (ACK/NAK)

The receiving system (server) must return an acknowledgment to the sending system (client) for every message that is received. Once the client has received the acknowledgment, it may then send the next message. For example, when the HIS/HUB system sends an ADT transaction to Misys, Misys will return an acknowledgment to the HIS/HUB for that message on the same logical socket where it was received. The HIS/HUB can then send the next inbound transaction to Misys.

Acknowledgments can be either positive (ACK) or negative (NAK). For all ACK/NAK messages, the HL7 segments MSH and MSA must be returned. The MSA;1 is valued with “AA” or “CA” for ACK and with “AE” or “CE” for NAK. With TCP/IP communications, NAK situations are rarely encountered.

The fields listed are required for all acknowledgments and must be valued as described in the tables below. The values of fields MSH;3, MSH;10-12 and MSA;1 are negotiable:

MSH Segment – acknowledgment message

|Seq# |HL7 |Brief Description |ACK from HIS ( Misys |ACK from Misys ( HIS |

| |element | | | |

|1 |Field Separator || || || |

|2 |Encoding Characters |component delimiter (^) | | |

| | |repeat delimiter (~) |^~\& |^~\& |

| | |escape character (\) | | |

| | |subcomponent delimiter (&) | | |

|3 |Sending Application | | | |

|4 |Sending Facility | | | |

|5 |Receiving Application |If Sending Application is valued by the client | | |

| | |in the inbound message, this sequence echoes | | |

| | |back that value here. | | |

|6 |Receiving Facility |If Sending Facility valued by client in the | | |

| | |inbound message, this field echoes back that | | |

| | |value here. | | |

MSH segment – acknowledgment message continued

|Seq# |HL7 |Brief Description |ACK from HIS ( Misys |ACK from Misys ( HIS |

| |element | | | |

|7 |Date & Time of message |CCYYMMDDHHMMSS |CCYYMMDDHHMMSS |CCYYMMDDHHMMSS |

|8 |Security |Not Valued |Not Used |Not Used |

|9 |Message |Valued with ACK | | |

| |Type |for all acknowledgments whether positive or |ACK |ACK |

| | |negative | | |

| | |Specify whether your HIS will value this field| |CCYYDDDnnnnnnn where DDD is a |

|10 |Message Control ID |and the format used. | |true Julian date and nnnnnnn is a |

| | | | |sequence number for the day. |

|11 |Processing ID |T for Training, P for Production or D for | | |

| | |Debug. Please specify which two will be used. | | |

|12 |Version ID |HL7 version (2.1 or 2.2) | | |

|13 |Sequence Number |Misys does not use sequence number protocol |Not Used |Not Used |

MSA Segment

|Seq # |HL7 |Brief Description |ACK from HIS ( Misys |ACK from Misys ( HIS |

| |element | | | |

|1 |Acknowledgment code |Indicates whether positive (ACK) or negative | | |

| | |(NAK) acknowledgment. | | |

|2 |Message control ID |If used, the number sent in MSH;10 of the | | |

| | |inbound message is echoed back to the client in| | |

| | |this sequence. | | |

|3 |Text Message |Misys may value this but only if returning a | | |

| | |NAK and only under certain error conditions. A| | |

| | |description of the error may be included here | | |

| | |for troubleshooting purposes | | |

|4 |Expected Sequence |Misys does not use sequence number protocol. |Not Used |Not Used |

6. ADT Interface Inbound Trigger Events

Misys supports the following HL7 ADT trigger events. Please complete the table by entering Y for those trigger events that will be sent by the HIS and an N for the triggers that will not be sent.

The patient number (AKA hospital number, medical record number) is a required field for all triggers.

|HL7 (v2.2) |Functionality |Sent by HIS/ |Comments or Action |

|Triggers | |HUB? | |

|A01 |Admit Inpatient | |Required: patient name, account number or external id, patient location, |

| | | |admit date |

|A02 |Transfer in or outpatient | |Required: account number or external id, patient location |

|A03 |Discharge in or outpatient | |Required: account number or external id, patient location, discharge date |

|A04 |Register outpatient or outside| |Required: patient name, account number or external id, patient location, |

| |patient | |admit date |

|A05 |Preadmit patient | |Required: patient name, account number or external ID, admit date. If a |

| | | |location is not received in the A05, site must decide if it should default |

| | | |to inpatient or outpatient location type. If the location is defined as |

| | | |inpatient in Misys, a patient room is required. |

|A06 |Transfer outpatient to | |Required: account number or external id, location |

| |inpatient | | |

|A07 |Transfer inpatient to | |Required: account number or external id, location |

| |outpatient | | |

|A08 |Demographic update | |Required: account number or external id, patient location |

|A11 |Cancel admit | |Treated as a discharge (A03) |

|A13 |Cancel discharge | |Required: account number or external id |

|A17 |Swap patients | |Required: account number or external id, location |

| | | |Treated as two transfers (A02) |

|A23 |Delete a patient record | |Required: external episode ID (episode #). Generally applies to TDS only. |

| | | |Close episode flag (Active event flag). No new orders will be sent to HIS |

| | | |but results for pending tests will still be sent. |

|A28 | Add person information | |Required: patient name. |

| | | |Only patient demographic info, no episodes/events for a |

| | | |preadmit/preregistration. No patient location is sent in the A28. |

|A29 |Delete person information | |Required: external patient number. Generally applies to TDS only. HIS |

| | | |Active flag (episode purge flag) |

| | | |No further transactions will be sent to HIS for this patient episode. |

|A31 |Update person information | |Update to demographic information only, no episode/event information |

| | | |updated. |

|A34 |Merge patient information | |Required: new and old patient number |

| | | |merges performed at patient ID (medical record number) level only |

|A35 |Merge account information | |Required: old and new account number |

| | | |merge performed for 2 account numbers within a single medical record number |

The Misys supported trigger events are listed above. In the table below, please list any additional ADT trigger events that you will send or any triggers that should be used differently from what is described in the table on the previous page. Describe in detail.

|HL7 Trigger |Functionality |Comments or Actions |

| | | |

| | | |

| | | |

| | | |

| | | |

| | | |

7. Admits/Registrations

a. When a patient is admitted (A01) or registered (A04), will you send just the single HL7 trigger or will that trigger be immediately followed by another transaction such as an A08?

Example: some HIS systems’ standard practice is to send an A05 followed by an A01 or A04 and then an A08.

b. If you will be sending more than one transaction to admit or register all patients, list the exact sequence of events and discuss the details with your Misys Interface Analyst.

8. Preadmit Patients

a. What trigger event will be sent for preadmit patients?

b. If Misys does not receive a location for preadmits, do you want an inpatient or an outpatient episode to be created? (N/A if sending A28 for preadmits)

NOTE: If the location is defined in Misys as an inpatient location, a room is required. If the location is defined in Misys as an outpatient location, only the location is required but a room may be sent.

9. Observation Patients

Observation patients are usually considered outpatients that occupy a bed for monitoring or therapeutic purposes. They are sometimes known as “23-hour stay” patients.

a. What HL7 trigger event will the HIS send to register these patients?

b. If a location is not sent, do you want them treated as inpatients or as outpatients?

NOTE: The MA12 event type for the patient location will be used to classify patients for Reports. Inpatient locations will not qualify for Event Reports.

10. Outside Patients

a. Will your HIS send outside patients? YES NO

b. If yes, what will the patient number that is sent look like? Please give an example.

11. Patient Transfers

a. When an inpatient changes rooms, what type of HL7 trigger event will be sent?

A02 A17 A08

b. When two patients swap rooms, what trigger event will be sent?

A17 two A02 transactions

c. When an outpatient changes locations, what type of HL7 trigger event will be sent?

A02 A17 A08

d. Do any other fields besides patient location need to be updated in a transfer transaction? If yes, list each field. YES NO

e. Should a transfer transaction ever create a new event or episode? YES NO

12. Patient Changes

a. Should a new episode/event ever be created with an A08 trigger or should an existing one be updated?

Note: An A08 will only change information on a patient already in the Misys LIS. An error will be generated if Misys receives an A08 on a patient not in the lab system.

b. What trigger is sent to change a patient’s account number? Do you expect a new lab episode/event to be created?

13. Patient Account Inactivation/Delete (generally applies to TDS only)

a. Does your HIS ever inactivate or close an account number or episode? YES NO

b. If yes, will this be sent across the interface? YES NO N/A

c. If yes, what trigger event will be sent?

c. Should the lab continue to send outbound transactions to the HIS for these accounts? Which ones?

e. Does your HIS ever delete or purge an account number or episode? YES NO

f. If yes, will this deletion be sent across the interface? YES NO N/A

g. If yes, what trigger event will be sent?

h. Which outbound transactions should be sent and which should be blocked for the HIS deleted accounts?

14. CoPath

a. If you have an existing ADT interface from Misys Lab to CoPath, will the new ADT interface that is being installed need to send any Special Registration fields to CoPath? YES or NO

b. If YES, what Special Registration fields will need to pass to CoPath?

HL7 Segments

The Misys LIS uses the following HL7 segments for the types of inbound transactions indicated. The segments are listed in order of appearance for each transaction type. Required segments are listed in boldface. Optional segments are listed in [ ]. Misys accepts repeating segments for those segments listed in { }. Keep in mind that a segment can be both optional and repeating. Misys does not accept OBX segments for ADT transactions.

|ADT Transactions |Order Entry Transactions |

|MSH |MSH |

|PID |PID |

|PV1 |PV1 |

|{[DG1]} |ORC |

|{[NTE]} |OBR |

|MRG (required only for triggers A34,A35) |{[DG1]} |

| |{[NTE]} |

|Response to Lab Initiated Orders |{[OBX]} |

|MSH | |

|PID |Cancel Order |

|PV1 |MSH |

|ORC |PID |

|OBR |PV1 |

| |ORC |

|Physician Maintenance |OBR |

|MSH | |

|MFI | |

|MFE | |

|STF | |

|PRA | |

Any additional HL7 segment not listed above can be sent. Since these additional segments contain information that is not normally used in Misys, we will use them only if negotiated appropriately. If your site requires use of any segments not listed above, complete the table below and at the end of the inbound section of this document (Other segments). You may also have to fill out a form called “Special AD/RE Specifications”. This form is available from your Implementation Consultant or Interface Analyst.

|Segment name |How should this segment be used by the lab system/why is this segment needed? |

| | |

| | |

| | |

| | |

Each supported segment and their fields are listed on the following pages. Required fields are highlighted in gray, Optional, Special and Not Supported fields are white. The HIS may send any and all fields if desired. However, if a field is listed as optional or special, it will not be used or stored by Misys unless appropriately negotiated. For special fields, additional programming will be required to display the information in the lab system. If you mark any special fields as to be stored by Misys, you may have to complete a “Special AD/RE Specifications” form. This form will be used to complete the additional programming.

Complete the table for each segment by entering a Y or an N in the appropriate column. For every optional or special field marked as Y, describe how the information will be used in the lab. If you require the use of any additional segments, please complete the table at the end of the inbound section of this document for each of these segments.

R = Required field Field must be sent in every transaction unless otherwise specified.

O = Optional field Field may be used by Misys and displayed in the laboratory as

appropriate.

S = Special (REG) Special programming required for Misys to store/display this field. Use of any

special fields must be negotiated. Ten reg fields are included in the cost of the interface, but must be listed on the completed spec and implemented at the time of the interface install. Reg fields added during testing or after live, or usage of more than 10 reg fields will require additional fees. Modifications to other interfaces required to pass these special reg fields will require additional fees.

NS = Not Supported Field not supported by Misys.

MSH Segment

|Seq# |HL7 |Brief Description |R/O/S/NS |Should Field |Comments |

| |element | | |be stored by | |

| | | |(see key) |Misys? | |

|1 |Field Separator || |R |Y | |

|2 |Encoding Characters |component delimiter (^) | | | |

| | |repeat delimiter (~) |R |Y | |

| | |escape character (\) | | | |

| | |subcomponent delimiter (&) | | | |

|3 |Sending Application | |O | | |

|4 |Sending Facility |The patient’s HID may be sent in this field but|O | | |

| | |is also required in PID;3.4. | | | |

|5 |Receiving Application | |O | | |

|6 |Receiving Facility | |O | | |

|7 |Date & Time of message |CCYYMMDDHHMM |R |Y | |

|8 |Security | |NS |NS |Not supported |

MSH Segment - continued

|Seq# |HL7 |Brief Description |R/O/S/ NS |Should |Comments |

| |element | | |Field be | |

| | | | |stored by | |

| | | | |Misys? | |

|9 |Message |Contains message type and trigger event. |R |Y | |

| |Type | | | | |

| | |ADT example: ADT^A01 | | | |

| | | | | | |

| | |Order Entry triggers: | | | |

| | |ORM^O01 (New order from HIS) | | | |

| | |ORR^O02 or ORM^O01(Order # assigned by the HIS)| | | |

| | |ORM^O01 (Cancel request from HIS) | | | |

| | | | | | |

| | |Physician Transactions: | | | |

| | |MFN^M02 | | | |

|10 |Message Control ID |If used, this sequence is valued with a number |O | | |

| | |that is unique to that message. The receiving | | | |

| | |system will echo this value in the MSA message.| | | |

|11 |Processing ID |T for Training or P for Production |R |Y | |

|12 |Version ID |HL7 version (2.1 or 2.2) |R |Y | |

|13 |Sequence Number | |NS |NS |Not supported |

|14 |Continuation pointer | |NS |NS |Not supported |

PID Segment

|Seq # |HL7 |Brief Description |R/O/S/ NS |Should |Comments |

| |element | | |Field be | |

| | | | |stored by | |

| | | | |Misys? | |

|1 |Set ID | |NS |NS |Not supported |

|2 |Patient ID | |S/O | | |

| |(external ID) | | | | |

|3 |Patient ID |The 1st component of this sequence is always valued |R |Y |1st component is required. |

| |(internal ID) |and is the Misys patient number (usually the medical | | | |

| | |rec #). | | |If using Misys LIS MULHOS software, |

| | | | | |the 4th component is also required. |

| | |An HIS patient id (not med rec #) can be sent in the | | | |

| | |2nd component. | | |Required for all transactions. |

| | | | | | |

| | |An HIS episode # can be sent in the 3rd component. | | | |

| | | | | | |

| | |If a hospital ID is required (Mulhos), it is placed | | | |

| | |in the 4th component of this sequence. Example: | | | |

| | |nnnnnnn^^^N | | | |

|4 |Alternate Patient ID |Could be HMO ID |O | | |

|5 |Patient Name |Required for ADT trigger events. The sequence is to |R |Y |Misys doesn’t store components 4-6 |

| | |be formatted as follows: | | |(suffix, title, degree) |

| | |Component one family name | | | |

| | |Component two given name | | |Required field for the following ADT |

| | |Component three middle initial or name | | |triggers: A01, A04, A05, A28 |

| | | | | | |

| | |Example: SMITH^JOHN^D | | | |

|6 |Mother’s maiden name |Patient Real Name (secret name) can be sent in this |O or S | | |

| | |field, no special programming required. If you want | | | |

| | |to use this field as the actual mother’s maiden | | | |

| | |name, then special programming will be required. | | | |

|7 |Date of birth |Required for ADT trigger events. The date format is |R |Y | |

| | |CCYYMMDD | | | |

|8 |Sex |Required for ADT trigger events. If there is no |R |Y | |

| | |value sent by the HIS, the LIS will default with a | | | |

| | |“U”. | | | |

|9 |Patient alias |Used as the Misys AKA name. |O | | |

|10 |Race | |S | | |

|11 |Patient address |Component 1=address line 1 |S | | |

| | |Component 2=address line 2 | | | |

| | |Component 3=city | | | |

| | |Component 4=state | | | |

| | |Component 5=zip code | | | |

|Seq# |HL7 |Brief Description |R/O/S/ NS |Should |Comments |

| |element | | |Field be | |

| | | | |stored by | |

| | | | |Misys? | |

|12 |County code | |S | | |

|13 |Phone number | |S | | |

| |(home) | | | | |

|14 |Phone number | |S | | |

| |(business) | | | | |

|15 |Language | |S | | |

|16 |Marital status | |S | | |

|17 |Religion | |S | | |

|18 |Patient account number |Required for ADT trigger events if patient management|R |Y |Required field for the following ADT |

| | |rules use account number. This sequence contains the| | |triggers: A01, A02, A03, A04, A05, |

| | |account or billing number of the patient. When sent | | |A06, A07, A08, A13, A17, A35 |

| | |in the PID in the ADT interface, it is the billing | | | |

| | |number at the patient level. When sent in the PID in| | | |

| | |the order entry interface, it is the billing number | | | |

| | |at the order level. | | | |

|19 |Social Security number | |O | | |

|20 |Driver license number | |S | | |

| | | | | | |

15. Patient Number

a. The patient’s facility id (HID) must be sent in PID;3.4 (internal ID). Will you accommodate this?

YES NO

b. How many characters will the HIS/HUB send for patient number?

c. Will it ever include leading zeroes? YES NO

d. Should leading zeroes be stripped (done via site parameter)? YES NO N/A

Note: Be sure site parameters for patient number length and verification pattern

are set accordingly.

e. Will the patient number include any other characters such as punctuation or spaces that will have to be stripped out by the interface?

YES NO

f. If yes, please specify.

g. Will the patient number include a check digit?

YES NO

h. Please provide an example of a patient number.

16. Patient Name Fields

NOTE: All patient name fields must be sent in the HL7 format (last^first^middle)

a. Will you use patient alias (PID;9)? (AKA name) YES NO

b. Will you use patient real name? (secret or celebrity name) YES NO

c. If yes, in what segment and field will you send it? PID;6 Other (specify)

d. Will the patient name fields be all uppercase letters or a mixture of upper and lowercases?

NOTE: The interface uses the same criteria for valid name formats as the LIS. Please review these formats with your Implementation Consultant or Interface Analyst.

17. Birthdate

Birthdate must be sent in HL7 format (CCYYMMDD)

a. Will the patient birthdate ever be null? YES NO

b. If the patient has an unknown birthdate, what value will you send in the birthdate field?

NOTE: If the birthdate is sent as null or as an invalid date, the interface will default the

birthdate to all zeroes.

18. Social Security Number

a. Will the HIS send the patient’s social security number? YES NO

b. If yes, indicate how it should display in the Lab (ie include spaces, hyphens?).

Note: Be sure site parameter for Text and pattern match for alternate patient ID # 1 are set accordingly.

PV1 Segment

|Seq# |HL7 |Brief Description |Required/Option|Should Field |Comments |

| |element | |al/ Special |be stored by | |

| | | | |Misys? | |

|1 |Set ID | |NS |NS |Not supported |

| |Patient ID | | | | |

|2 |Patient class |Used to designate a patient event type |O | |See footnote 1 below[1] |

|3 |Assigned pt. |Inpatients = nursing unit^room^bed |R |Y |Outpatient locations are usually sent as |

| |location |Outpatients = loc^null^null | | |loc^null^null. However the room and bed |

| | |Observation = nurse unit^room^bed | | |can be valued if desired. |

| | | | | |Required field for the following ADT |

| | | | | |triggers: A01, A02, A03, A04, A06, A07, |

| | | | | |A08, A17 |

|4 |Admission type | |NS |NS |Not supported |

|5 |Preadmit number | |NS |NS |Not supported |

|6 |Prior patient location |same format as seq 3, Assigned patient |NS |NS |Not supported |

| | |location | | | |

|7 |Attending doctor |Misys supports two physicians at the patient |O | |See footnote 2 below[2] |

| | |level. | | | |

|8 |Referring doctor |Misys supports two physicians at the patient |O | |See footnote 2 below |

| | |level | | | |

|9 |Consulting |Misys supports two physicians at the patient |O | |See footnote 2 below |

| |doctor |level | | | |

|10 |Hospital Service | |S | | |

|11 |Temporary location |Home chart location can be sent in this |O | | |

| | |field. | | | |

|12 |Preadmit indicator | |NS |NS |Not supported |

|13 |Readmission indicator | |NS |NS |Not supported |

|14 |Admit | |NS |NS |Not supported |

| |source | | | | |

|15 |Ambulatory status | |NS |NS |Not supported |

|16 |VIP | |S | | |

| |indicator | | | | |

|17 |Admitting doctor |Misys supports two physicians at the patient |O | |See footnote 2 below |

| | |level | | | |

|18 |patient type |Could be used for event type (instead of |O | |See footnote 1 below |

| | |PV1;2) or for HMO facility ID. | | |. |

PV1 Segment continued

|Seq# |HL7 |Brief Description |R/O/S/ NS |Should |Comments |

| |element | | |Field be | |

| | | | |stored by | |

| | | | |Misys? | |

|19 |Visit number |Episode, stay, encounter number |O | | |

|20 |Financial class |Primary financial class assigned to the |R/O | |Required if using Medicaid Compliance |

| | |patient for reimbursement. | | |Pack[3] |

|21 |Charge price indicator |Determines which price schedule to use for |NS |NS |Not supported |

| | |room/bed charges. | | | |

|22 |Courtesy code |Code for special courtesies. |NS |NS |Not supported |

|23 |Credit rating |Past credit experience |NS |NS |Not supported |

|24 |Contract code |Type of contract and guarantor |NS |NS |Not supported |

|25 |Contract effective date |Start date of contract |NS |NS |Not supported |

|26 |Contract amount | |NS |NS |Not supported |

|27 |Contract period |Contract duration |NS |NS |Not supported |

|28 |Interest code |Amount of interest charged. |NS |NS |Not supported |

|29 |Transfer to bad debt |Indicates account transferred to bad debt. |NS |NS |Not supported |

| |code | | | | |

|30 |Transfer to bad debt |Date from 29 |NS |NS |Not supported |

| |date | | | | |

|31 |Bad debt agency code |Collection Agency |NS |NS |Not supported |

|32 |Bad debt transfer amount|Dollar amount of bad debt |NS |NS |Not supported |

|33 |Bad debt recovery amount|Dollar amount of bad debt recovery |NS |NS |Not supported |

|34 |Delete account indicator|Reason account was deleted from file |NS |NS |Not supported |

|35 |Delete account date |Date from 34 |NS |NS |Not supported |

|36 |Discharge disposition |Disposition of discharge (home, expired) |NS |NS |Not supported |

|37 |Discharge to location |Facility patient discharged to |NS |NS |Not supported |

PV1 Segment continued

|Seq# |HL7 |Brief Description |R/O/S/ |Should |Comments |

| |element | |NS |Field be | |

| | | | |stored by | |

| | | | |Misys? | |

|38 |Diet type |Special diet |NS |NS |Not supported |

|39 |Servicing facility |Facility with which this visit is associated. |O | |This field may be used for client ID. |

|40 |Bed status | |NS |NS |Not supported |

|41 |Account status | |NS |NS |Not supported |

|42 |Pending location |Nursing station or room where patient may be |NS |NS |Not supported |

| | |moved. | | | |

| |Prior temporary location| |NS |NS |Not supported |

|43 | | | | | |

|44 |Admit |Date patient admitted or date episode started. |R |Y |Required field for the following ADT |

| |date/time |CCYYMMDD. The time is not used. Required for | | |triggers: A01, A04, A05 |

| | |trigger events A01 and A04 only. | | | |

|45 |Discharge date/time |Required for trigger events A03,A07 and A11 |R |Y |Required field for the following ADT |

| | |only. The date is stored but not the time. | | |trigger: A03 |

|46 |Current patient balance |Visit balance due |NS |NS |Not supported |

|47 |Total charges |Total visit charges |NS |NS |Not supported |

|48 |Total adjustments |Total adjustments for visit |NS |NS |Not supported |

|49 |Total payments |Total payments for visit. |NS |NS |Not supported |

19. Account, Episode, Visit Number or External ID

This is the number that will be used to determine lab episodes.

a. What will be sent that should be used to determine lab episodes?

Account number HIS episode number

HIS Visit number other (specify)

b. In what field will this number be sent?

PID;2 PID;3.3 PID;18 PV1;19 other (specify)

c. Are there any additional fields that should also be used to determine lab episodes or events? If yes, list them and explain.

d. Besides the above number, is there an additional number(s) that the lab must store for return to the HIS on outbound transactions?

YES NO

e. If yes, what number is this and in which field will it be sent?

f. Should this additional number display on any lab screens? YES NO N/A

g. How many characters will be sent for patient account number?

h. Will it include leading zeroes? YES NO

i. If yes, should the interface strip leading zeroes? YES NO N/A

j. If the interface will strip zeroes on account number, must they be padded back for outbound

transactions? YES NO N/A

Note: Be sure site parameter for account number length is set accordingly.

k. Will the account number include a check digit?

YES NO

l. Please provide an example of an account number.

20. Event Type

a. Will your HIS send a field that the interface should use as the lab event type? YES NO

b. If yes, in what field will the event type be sent?

PV1;2 PV1;18 Other (specify) N/A

NOTE: The HIS must provide a list of all possible values to the lab so that they can be defined or translated on the lab system. If event type is not sent, a default event type must be defined in MA26.

21. Patient Location/Room

a. Will the patient location be sent in PV1;3 (assigned patient location) for all patient types including outpatients?

YES NO

b. If no, please specify where the location will be sent for each patient type.

c. The patient location must be sent in the HL7 format (loc^room^bed). With this in mind, describe how the room/bed should be built in the lab system (ie: room-bed, room bed, roombed, locroom-bed, etc.). Please give an example of what will be sent in PV1;3 and how that corresponding location/room appears in MA12.

d. Within each HID, are all patient room/bed and clinic designations unique? YES NO

NOTE: For inpatient locations, a room must be sent. For outpatients, only a location is required but

a room may be sent if desired. If the HIS locations do not exactly match the lab definitions,

an ADT location translation table is available.

22. Physicians (ADT transactions only)

a. Does the HIS send a default physician code for non-staff physicians? YES NO

b. If no, how are non-staff physicians sent?

c. If yes, is this code the same as the unknown physician on the lab side? YES NO

d. If the code is not the same on both systems, do you want the HIS physician code translated by the

interface to the lab code or do you want an error message produced every time the non-staff

physician code is received?

e. If you would like it translated, list both the code that will be sent and the lab code.

23. Discharge Transactions

a. Will you send a discharge for all patient types including outpatients? YES NO

b. If yes, should the interface process or block discharges on outpatients?

PROCESS BLOCK N/A

c. If the interface should block outpatient discharges, what field will indicate the patient type?

24. HMO ID

This is the patient’s membership number in their HMO.

a. Does the HIS send an HMO ID? YES NO

b. If yes, in what field will it be sent?

25. HMO Facility ID

This is the identification code of a specific HMO facility or clinic within an HMO organization. This is the main location where a member’s chart resides even though the patient may visit multiple clinics or facilities of the HMO.

a. Will your HIS send an HMO facility ID? YES NO

b. In what field will the HMO facility ID be sent?

PV1;18 Other (specify) N/A

26. Home Chart Location

Home Chart Location is the facility where the patient’s medical record chart is kept though they may be seen at other locations/clinics.

a. Will the HIS send a Home Chart Location? YES NO

b. Where will the Home Chart Location be sent?

Z-segment Other (specify) N/A

c. If a Z-segment will be used, you must specify the segment and all its fields in the tables provided

at the end of the inbound section of this document (Other segments).

DG1 Segment

|Seq # |HL7 |Brief Description |R/O/S/ NS |Should |Comments |

| |element | | |Field be | |

| | | | |stored by | |

| | | | |Misys? | |

|1 |Set ID diagnosis | |NS |NS |Not supported |

|2 |Diagnosis coding method | |NS |NS |Not supported |

|3 |Diagnosis code |Diagnosis code entered in the patient |O | | |

| | |registration system. This code is validated in| | | |

| | |Misys. | | | |

|4 |Diagnosis |Free-text diagnosis entered in the patient |O | | |

| |description |registration system. | | | |

|5 |Diagnosis date/time | |NS |NS |Not supported |

|6 |Diagnosis/ | Possible values are A for Admit diagnosis or |O | |Used for trigger event A08 only. If |

| |diagnosis related group |D for Discharge diagnosis. | | |this field is not valued on a DG1 sent |

| |(DRG) type | | | |with trigger A08, then the diagnosis |

| | | | | |will be used to update the admitting |

| | | | | |diagnosis. |

|7 |Major diagnosis category| |NS |NS |Not supported |

|8 |DRG | |NS |NS |Not supported |

|9 |DRG approval indicator | |NS |NS |Not supported |

|10 |DRG grouper review code | |NS |NS |Not supported |

|11 |Outlier type | |NS |NS |Not supported |

|12 |Outlier days | |NS |NS |Not supported |

|13 |Outlier group | |NS |NS |Not supported |

|14 |Grouper version and type| |NS |NS |Not supported |

27. Patient Diagnosis

a. Will you always send patient diagnosis in segment DG1? YES NO

b. If no, what other segment and field will be used and under what circumstances?

c. Will the HIS send repeating DG1 segments? YES NO

d. Will the HIS send codes, text or both? CODE TEXT BOTH

NOTE: If both codes and text are sent in the same DG1 segment, the text must be a description of the code as defined in MA8.

If the text in the DG1;4 segment is not the description of the code that is in DG1;3 it must be sent in a separate DG1 segment, preferably in piece 3.

Be sure to set your site parameter to accept text, codes or both as appropriate.

e. Will you send discharge diagnosis with discharge transactions? YES NO

f. Will you send diagnosis for patients after they have been discharged? YES NO

g. If yes, what trigger event will be sent?

NOTE: If diagnosis type (DG1;6)is not included in the A08, the diagnosis will be applied to the admitting diagnosis as a default. Possible types are A (admitting) and D (discharge).

MRG Segment

|Seq# |HL7 |Brief Description |R/O/S/ NS |Should |Comments |

| |element | | |Field be | |

| | | | |stored by | |

| | | | |Misys? | |

|1 |Prior patient ID |The non-surviving patient number, which is some|R |Y | |

| |(internal) |times known as the “from patient number”. The | | | |

| | |“to patient number” exists in PID;3 (internal | | | |

| | |ID) of the PID immediately preceding the MRG | | | |

| | |segment. | | | |

|2 |Prior alternate patient | |NS |NS |Not supported |

| |ID | | | | |

|3 |Prior patient account |The non-surviving account number. The |R |Y |Required for trigger event A35 only. |

| |number |surviving account number exists in PID;18 | | |Account number merges merge two account |

| | |(account number) immediately preceding the MRG | | |numbers within a single medical record |

| | |segment. | | |number only. |

28. Merges

If patient merges are sent, the interface can either process them or block them. If the interface is to process merges, please be aware that for medical record number merges, all critical field demographics (name, birthdate, sex and ABO/Rh) must be identical for the patients being merged or the merge will be rejected.

NOTE: Other types of merges are allowed in Misys Lab but only these two types will be done on the interface.

a. Misys expects trigger event A34 for medical record number merges. Will you accommodate this? YES NO

b. If no, what trigger will be sent for medical record number merges?

c. Should the interface process these transactions or block them and print a message for the lab to handle manually?

PROCESS BLOCK

d. Will the HIS send A35 to merge accounts/episodes within the same patient number? YES NO

e. If no, will a different trigger be sent? Which one?

f. Should these account/episode merges be processed or blocked and a message printed for lab to handle manually?

PROCESSED BLOCKED N/A

ORC Segment – Common Order (inbound orders to Misys)

|Seq# |HL7 |Brief Description |R/O/S/ NS |Should |Comments |

| |element | | |Field be | |

| | | | |stored by | |

| | | | |Misys? | |

|1 |Order Control |This sequence designates the type of order message |R |Y | |

| | |that is being sent. | | | |

| | | | | | |

| | |NW – New order generated by HIS and sent to LIS | | | |

| | | | | | |

| | |NA – Placer number assigned in response to LIS | | | |

| | |generated order. | | | |

| | | | | | |

| | |CA - Cancel order request from HIS | | | |

|2 |Placer number |Placer number is extracted from OBR segment. See |NS |NS |Not supported. Placer is extracted |

| | |OBR;2 | | |from OBR;2. |

|3 |Filler number |Filler number is used for the outbound interface |NS |NS |Not supported |

| | |only. | | | |

|4 |Placer group number | |NS |NS |Not supported |

|5 |Order Status | |NS |NS |Not supported |

|6 |Response flag | |NS |NS |Not supported |

|7 |Timing/Quantity |OBR;27 is used for priority/timing. |NS |NS |Not supported |

|8 |Parent | |NS |NS |Not supported |

|9 |Date/time of transaction|Date/time of transaction is expected in the MSH;7. |NS |NS |Not supported |

|10 |Entered by | |S | | |

|11 |Verified by | |NS |NS |Not supported |

|12 |Ordering provider |OBR;16 is used for Ordering Physician. |NS |NS |Not supported |

|13 |Enterer’s location |Contains the ordering location, if valued by the HIS.|O | | |

|14 |Call back phone number | |NS |NS |Not supported |

|15 |Effective date/time of | |NS |NS |Not supported |

| |order | | | | |

|16 |Order control code |If the order control code is CA, this sequence |O | |. |

| |reason |contains the cancel reason. The format is | | | |

| | |code^translation. If the reason is sent as free | | | |

| | |text, it should be valued in the second component and| | | |

| | |the first component left null. | | | |

29. ORC;16

Please indicate whether code or description should be extracted.

30. Order Entry Control Codes

a. Order control codes are sent in the ORC segment, piece 1. The following control codes are supported for inbound transactions. Please complete the table by entering Y or N in the appropriate column for each order control code.

|HL7 order control |Functionality |Sent by HIS/|Comments or Actions |

|code | |HUB? | |

|NW |New Order | |Sent for all HIS generated orders. The trigger event is sent |

| | | |in MSH;9 as ORM^O01 |

|NA |Order number assigned | |Sent in response to a lab generated order if the HIS requires |

| | | |“placer number update” (SN message) for the lab order. |

|CA |Cancel order request | |Sent for HIS initiated cancels. The trigger event is ORM^O01 |

b. If using order control NA, indicate the message type and trigger event you will send in the MSH;9:

ORR^O02 ORM^O01 ORM^O02 Other (specify)

c. The Misys supported order control codes are listed above. In the table below, list any

additional OE control codes that you will send or any control codes that should be used differently from what is described in the table above. Describe in detail.

|Order Control Code |Functionality |Comments or Actions |

| | | |

| | | |

| | | |

| | | |

| | | |

| | | |

31. Ordering Location

The ordering location will not affect the patient’s actual location and will not display in the lab. If sent, the lab can use the ordering location for label printing purposes only. In order for the ordering location to be used for label printing, the value received must be a valid MA12 location.

a. Will the HIS send an ordering location in ORC;13? YES NO

b. If yes, is this a terminal id or an actual location in the hospital?

OBR Segment – Observation Request

|Seq# |HL7 |Brief Description |R/O/S/ NS |Should |Comments |

| |element | | |Field be | |

| | | | |stored by | |

| | | | |Misys? | |

|1 |Set ID | |NS |NS |Not supported |

|2 |Placer number |HIS placer number. The format varies. The |R |Y |. |

| | |value is stored as sent by the HIS and is | | | |

| | |returned by the LIS in all related messages. | | | |

| | |The LIS needs to know the exact format sent by | | | |

| | |the HIS. | | | |

|3 |Filler number |HIS order number is expected in OBR;2. OBR;3 |NS |NS |Not supported |

| | |should be left unvalued | | | |

|4 |Universal service |The order code. The HIS order code or the |R |Y |HMA order code translation table must be |

| |identifier |Misys order code may be sent. | | |built if HIS codes are sent. |

| | | | | | |

| | |123^SODIUM | | | |

| | |NA^SODIUM | | | |

|5 |Priority |Priority is taken from OBR;27 |NS |NS |Not supported |

|6 |Requested date/time |See OBR;7, Observation date/time |NS |NS |Not supported |

|7 |Observation date/time |The requested collection date/time of the order|O | | |

| | |as sent from the HIS. The LIS values this | | | |

| | |sequence for outgoing messages with the actual | | | |

| | |collect time once the specimen has been marked | | | |

| | |as received. | | | |

|8 |Observation end |Frequency or standing orders are not supported.|NS |NS |Not supported |

| |date/time | | | | |

|9 |Collection volume | |NS |NS |Not supported |

|10 |Collector identifier | |S | | |

|11 |Specimen action code |The collecting department that is used by the |R |Y | |

| | |LIS interface logic to distinguish between lab | | | |

| | |collectible specimens and nursing collectible | | | |

| | |specimens usually designated with an L or N | | | |

| | |respectively. | | | |

|12 |Danger code |Can be used as an order comment if desired. |O | | |

|13 |Relevant clinical |Can be used as an order comment if desired. |O | | |

| |information | | | | |

OBR segment – continued

|Seq# |HL7 |Brief Description |R/O/S/ NS |Should |Comments |

| |element | | |Field be | |

| | | | |stored by | |

| | | | |Misys? | |

| |Specimen received date/time |The date/time the specimen was received in |NS |NS |Not supported for inbound orders. Used on |

|14 | |the lab. Valued on outbound transactions | | |the outbound interface only. |

| | |only and only when the specimen has already | | | |

| | |been marked as received in the lab. | | | |

|15 |Specimen source |This is the specimen type code (STYP code) |O | |Note: the value sent for STYP (non-micro) |

| | |for non-micro. | | |can be translated. |

| | | | | | |

| | |The culture site (SDES) is sent in an OBX | | |The value sent for SDES cannot be |

| | |segment for micro. SDES is explained later | | |translated. |

| | |in this section. | | | |

|16 |Ordering provider |Ordering physician code |O | | |

|17 |Order call back phone number| |NS |NS |Not supported |

|18 |Placer’s field #1 | |S | | |

|19 |Placer’s field #2 | |S | | |

|20 |Filler’s field #1 | |O/R* | |*Required for messages with NA order |

| | |. | | |control code-must be populated with Misys |

| | | | | |accession number. |

|21 |Filler’s field #2 | |S | | |

|22 |Results report status change| |NS |NS |Not supported |

| |date/time | | | | |

|23 |Charge to practice | |NS |NS |Not supported |

|24 |Diagnostic service section |Performing MA5 Lab dept. (ex. C, H, BB,MC) |NS |NS |Not supported. Used on the outbound |

| |ID | | | |interface only. |

|25 |Results status | |NS |NS |Not supported. Used on the outbound |

| | | | | |interface only. |

|26 |Linked results | |NS |NS |Not supported. Used on the outbound |

| | | | | |interface only. |

|27 |Quantity/timing |Priority (STAT,ASAP,etc) is extracted from |O | | |

| | |the 6th component of this field. The other | | | |

| | |components are not used. | | | |

|28 |Result copies to |Up to 3 copy to physicians may be entered |O | | |

|29 |Parent number | |NS |NS |Not supported |

|30 |Transportation mode | |NS |NS |Not supported |

OBR segment – continued

|Seq # |HL7 |Brief Description |R/O/S/ NS |Should |Comments |

| |element | | |Field be | |

| | | | |stored by | |

| | | | |Misys? | |

|31 |Reason for study |Could be used as ordering diagnosis or order |S | | |

| | |comment | | | |

|32 |Principal result | |NS |NS |Not supported |

| |interpreter | | | | |

|33 |Assistant result | |NS |NS |Not supported |

| |interpreter | | | | |

|34 |Technician | |NS |NS |Not supported |

|35 |Transcriptionist | |NS |NS |Not supported |

|36 |Scheduled date/time | |NS |NS |Not supported |

32. OBR;4

a. Please specify if the HIS order code or the LIS order code will be sent. HIS LIS

b. If this interface is replacing and existing OE interface, will order number format change? YES NO

c. If yes, give an example of the HIS order number format

d. Should zeros be stripped? YES NO

33. Collection Date/Time

a. Misys expects the specimen collection date and time in OBR;7. Will you accommodate this?

YES NO

b. If no, please indicate where the collection date and time will be sent.

c. Will the collect date/time field ever be null? YES NO

NOTE: If yes, rescheduling maintenance must be set up in function HMA.

d. How does the HIS indicate midnight?

34. Collection Flag/Specimen Action Code

a. Misys expects the collect department flag in OBR;11. A code of L indicates Lab to collect orders and N indicates Nurse to collect orders . Can your HIS/HUB send these two flags? YES NO

b. Will any other collect flags ever be sent? YES NO

c. If yes, list each and if they should indicate Lab or Nurse to collect.

d. If the interface receives a null OBR;11, should it treat those orders as Nurse or Lab to collect?

35. Specimen Types--Non-Micro

a. Misys expects the specimen type for non-microbiology orders in OBR;15. Will you accommodate this?

YES NO

b. Will the HIS send a specimen type with every non-micro order including orders for blood

tests?

YES NO

c. The laboratory usually does not want to see this specimen type. Should the blood specimen type

display in your lab?

YES NO

d. If no, please list all of the codes the HIS will send that the interface should block from lab

displays.

NOTE: There is a translation table in the lab for specimen type codes. This translation works for

non-micro stypes only. The value sent for test SDES cannot be translated. If the value for

SDES is not recognized by the LIS, it will be used as a free text result.

36. Priorities

a. Misys expects the ordering priority in OBR;27.6. Will you accommodate this? YES NO

b. If no, where will the ordering priority be sent?

c. Will the HIS send a priority with all orders including routine orders? YES NO

d. Most labs do not wish to see the routine priorities. Do you want to see them in your lab?

YES NO

e. If no, please list all the priority codes that should be blocked from lab displays.

NOTE: There is a translation table available in the lab for priority codes.

37. Multiple Orders

NOTE: Multiple order codes on a patient for the same collect date/time and specimen type, may be sent in a separate message or multiple ORC/OBR pairs within a single message. If multiple orders are sent in one message, the ORC/OBR must be in pairs. Misys cannot accept one ORC with multiple OBRs.

NTE Segment

|Seq# |HL7 |Brief Description |R/O/S/ NS |Should |Comments |

| |element | | |Field be | |

| | | | |stored by | |

| | | | |Misys? | |

|1 |Set ID | |NS |NS |Not supported |

|2 |Source of comment | |NS |NS |Not supported |

|3 |Comments |This sequence will contain the comment code |O | | |

| | |entered in the HIS. This code is validated in | | | |

| | |the LIS. For ADT transactions, coded comments | | | |

| | |are allowed but free text comments are not | | | |

| | |allowed. Both coded and free text comments are| | | |

| | |allowed with order transactions. | | | |

38. Order Comments

a. How will your HIS send order comments? Will they be sent in an NTE segment or in the OBR segment?

b. If there is more than one comment for an order code, will there be a separate NTE for each or one segment containing all comments?

NOTE: NTE Order comments must be sent following the OBR segment for each order code to which they apply. If more than one order comment is sent, the interface will display each as a separate comment with a hyphen and semicolon between each.

OBX Segment - Order Entry—used for orders only—no ADT

|Seq# |HL7 |Brief Description |R/O/S/ NS |Should |Comments |

| |element | | |Field be | |

| | | | |stored by | |

| | | | |Misys? | |

|1 |Set ID | |NS |NS |Not supported |

|2 |Value type |The LIS does not validate this field in the |NS |NS |Not supported |

| | |order entry interface. When a tech accepts | | | |

| | |results in any LIS result entry function, these| | | |

| | |prompt test results are returned to the HIS in | | | |

| | |a result transaction along with the newly | | | |

| | |accepted results. | | | |

|3 |Observation identifier |Contains the code of the individual test being |R |Y | |

| | |resulted. Common examples in the LIS are: | | | |

| | | | | | |

| | |Height---Data in this sequence is used in the | | | |

| | |calculation of specific results, for example | | | |

| | |creatinine clearance. | | | |

| | | | | | |

| | |Weight---same as height. | | | |

| | | | | | |

| | |SDES----Defines the culture body site for | | | |

| | |microbiology orders | | | |

| | | | | | |

| | |SREQ---Conveys any special requirements | | | |

| | |regarding the culture to microbiology | | | |

| | |personnel. | | | |

| | | | | | |

| | |%UO---Conveys the number of units the ordering | | | |

| | |physician requests for blood bank orders. | | | |

| | | | | | |

| | |%PI----Specific instructions the physician may | | | |

| | |have for filling blood bank orders. | | | |

|4 |Observation sub-ID | |NS |NS |Not supported |

|5 |Observation results |The actual results of the test identified in |R |Y |NOTE: If the value received is not |

| | |sequence 3, the observation identifier. If not| | |recognized by the LIS, then it will be |

| | |resulted when placing the order, the test must | | |used as a free text result. |

| | |be resulted manually in the LIS. | | | |

|6 |Units |Not supported for the inbound interface. |NS |NS |Not supported |

|7 |Reference range |Not supported for the inbound interface. |NS |NS |Not supported |

OBX Segment - Order Entry continued

|Seq# |HL7 |Brief Description |R/O/S/ NS |Should |Comments |

| |element | | |Field be | |

| | | | |stored by | |

| | | | |Misys? | |

|8 |Abnormal flags |Not supported for the inbound interface. |NS |NS |Not supported |

|9 |Probability | |NS |NS |Not supported |

|10 |Nature of abnormal tests| |NS |NS |Not supported |

|11 |Observation results |Not supported for the inbound interface. |NS |NS |Not supported |

| |status | | | | |

|12 |Date last OBS normal | |NS |NS |Not supported |

| |values | | | | |

|13 |User defined access | |NS |NS |Not supported |

| |checks | | | | |

|14 |Date/Time of observation|The time the result was entered into the lab |NS |NS |Not supported |

| | |system will be sent in this field. | | | |

|15 |Producer’s ID |Resulting lab location |NS |NS |Not supported |

|16 |Responsible observer |The tech code of the technologist entering this|NS |NS |Not supported |

| | |result will be sent in this field. | | | |

39. Defaulted Results/Prompt Tests with Order

If the HIS has the ability to send results with orders (RESOE), the interface can use this information to “default” the results for certain tests. This feature is used when the laboratory needs specific information to complete the requested order.

For example, if a creatinine clearance is ordered, the laboratory needs the patient’s height and weight to calculate the clearance. The lab sets up the creatinine clearance as a panel or battery that contains a test called height and one called weight. If the HIS sends the height and weight information in the order message, the interface can actually use the information to result the two tests for the laboratory. This way, the lab does not have to call the floor to obtain the information nor do they have to result those two tests manually in the lab system.

To use this feature, the results for these tests should generally be sent in OBX segments within the ORM initiated by the HIS. Some HIS systems cannot send OBX segments within the ORM messages. Instead of the OBX, these systems may use the OBR segment for RESOE tests. Whichever method is used, there must be a separate OBX segment or OBR field per test result. For example, in the case of height and weight for creatinine clearance, there would be 2 OBX segments in the order message. The OBX;3 contains the test name and OBX;5 contains the actual result of the test. An example follows:

MSH|^~\&|OADD||DADD||19961114163737||ORM^O01|3|P|2.1|

PID|||3237893||EDWARDS^ROBIN^I||19480520|M|

PV1||I|ICU^ICU-1|

ORC|NW|

OBR||4223||CRCL^CREATININE CLEARANCE|||199611151400|||||||||||||||||C|||^^^^^R||||||||

OBX|1|NM|HT^HEIGHT(INCH)|1|70|IN|||||F||

OBX|2|NM|WT^WEIGHT (LBS)|1|150|LB|||||F||

This same kind of idea can be used for other orders as well. Some common RESOE items are: %UO (# of Blood Bank units ordered), time of last dose for certain drugs, and SDES (specimen description) and SREQ (special requests) for microbiology cultures.

Indicate below how your HIS will send RESOE.

a. Will your HIS send RESOE in OBX segments, in the OBR segment or some in each? OBX only OBR only Some in OBX and some in OBR

NOTE: If OBR fields will be used for any tests, a separate OBR field must be used for each.

b. If OBR will be used for any RESOE tests, please list all of those tests and in which OBR field each will be sent.

NOTE: For all tests, the interface will attempt to translate any non-numeric RESOE

result value sent (in OBX;5 or an OBR field) to a value defined in HMA Comment Code

translations. If no translation is found there, the interface will look in MA4. If an exact

match is found there, it will be used. If no match is found in MA4 either, then the value

will be used as a free text result.

The above statement includes the test SDES. The result value sent (in OBX;5 or

OBR;15) for SDES will not be translated in HMA Specimen Type/Grouping Code

translations.

40. Physician Maintenance

There is no translation table for physicians in the Misys LIS. Because of this, the physician codes sent by the HIS must exactly match the physician codes that are defined in the laboratory. This is true for physicians sent in both ADT and Order transactions. To keep the physician dictionaries in sync on both sides of the interface, you may wish to perform physician definitions and maintenance across the ADT interface.

NOTE: Outside physicians cannot be sent across the interface. For MULHOS sites, if the physician practices in more than one hospital, we must receive a transaction for each hospital specifying the HID each time. The facility ID (HID) must be sent in the MSH;4 for physician transactions.

a. How will you perform your initial physician load?

Via ADT interface

Manual entry in MA13

FTP

Note: There is an additional charge to load physicians via FTP. Please

notify Application Interfacing and contact marketing for a quote if you wish to load

your physicians via FTP.

b. After the initial download, will the HIS send physician maintenance across the interface?

YES NO

MFN Message Structure - Master File Notification

The MFN segments are used for physician maintenance only.

MFI Segment - Master File Identification Segment

|Seq# |HL7 |Brief Description |R/O/S/ NS |Field |Comments |

| |element | | |stored by | |

| | | | |Misys? | |

|1 |Master File Identifier |A CE field that identifies a standard HL7 |NS |NS |Not supported |

| | |master file. | | | |

|2 |Master files application|Defines application responsible for maintaining|NS |NS |Not supported |

| |identifier |the file. | | | |

|3 |File level event code. |Defines file level event code |NS |NS |Not supported |

|4 |Entered date/time |Time stamp for file-level event on originating |NS |NS |Not supported |

| | |system | | | |

|5 |Effective date/time |Date and time originating system expects event |NS |NS |Not supported |

| | |to be completed on receiving system. | | | |

|6 |Response level code. |Application response level defined for a given |NS |NS |Not supported |

| | |Master File Message at MFE segment level (seq | | | |

| | |#1) | | | |

NOTE: The MFI segment may be sent, but is not required as none of the fields

within that segment will be used/stored by the lab system.

MFE Segment - Master File Entry Segment

|Seq# |HL7 |Brief Description |R/O/S/NS |Field |Comments |

| |element | | |stored by | |

| | | | |Misys? | |

|1 |Record level event code |Defines whether this transaction is to add |NS |NS |Not a required field as the status |

| | |(MAD), delete (MDL), deactivate (MDC), | | |(active or inactive) is obtained from |

| | |reactivate (MAC)or update (MUP)the master file | | |the STF;7. NOTE: Physician deletions |

| | |record. | | |are not allowed on the Misys system. If|

| | | | | |no longer in use, a physician code must |

| | | | | |be deactivated. |

|2 |MFN Control ID |An identifier that uniquely identifies this |NS |NS |Not supported |

| | |change. Only used if the MFI response level | | | |

| | |code is any value other than NE. | | | |

|3 |Effective date/time |Date and time originating system expects event |NS |NS |Not supported |

| | |to be completed on receiving system | | | |

|4 |Primary key value |Physician identification code. This code |R |Y | |

| | |uniquely identifies the individual physician. | | | |

STF Segment - Staff Identification Segment

|Seq# |HL7 |Brief Description |R/O/S/ NS |Field |Comments |

| |element | | |stored by | |

| | | | |Misys? | |

|1 |Primary key |Must Match MFE-4 |NS |NS |Not supported. Physician code extracted |

| | | | | |from MFE;4. |

|2 |Staff ID Code |The physician mnemonic may be sent in this |O |Y |Generally used for TDS sites only. |

| | |field. The corresponding site parameter must | | | |

| | |be enabled. | | | |

|3 |Staff Name |The physician’s name is formatted as follows: |R |Y | |

| | |Component one last name | | | |

| | |Component two first name | | | |

| | |Component three middle name or initial | | | |

| | |Components 4-6 not used. | | | |

|4 |Staff Type |Only inside (I) physicians are added via the |NS |NS |All physicians received in the MFN |

| | |interface. | | |segments are assumed to be inside |

| | | | | |physicians. |

|5 |Sex |Staff persons sex |NS |NS |Physician’s sex is not stored on the Misys|

| | | | | |system. |

|6 |Date of Birth |Staff persons date of birth |NS |NS |Physician’s date of birth is not stored on|

| | | | | |the Misys system. |

|7 |Active/Inactive |Current status |R |Y |A= Active |

| | | | | |I= Inactive |

|8 |Department |This is the primary MA12 location associated |O |Y |The site parameter must be activated to |

| | |with this physician. | | |allow this field. |

|9 |Service |This is an MA 4 code that indicates physician |O |Y | |

| | |service | | | |

|10 |Phone |12 characters are stored in the database for |O |Y |component 1=primary phone |

| | |each phone number and may display in Misys. | | |component 2=secondary phone |

| | |Area code is not required. Hyphens may be | | |component 3=alternate phone |

| | |sent. | | |component 4=FAX phone |

| | | | | |component 5=modem phone |

| | | | | |component 6=beeper number |

|11 |Address |Physician office address. Prints on patient |O |Y |component 1=street address |

| | |and maintenance reports. | | |component 2=city,state |

| | | | | |component 3=zipcode |

|12 |Activation Date |Date of activation |NS |NS |Not supported |

|13 |Inactivation Date |Date of inactivation |NS |NS |Not supported |

|14 |Backup Person |Contains the name(s) of the Physician’s backup |O | |provides another contact person. |

| | |personnel. | | |component 1=Contact 1 name |

| | | | | |component 2=Contact 2 name |

|15 |E-mail address | |NS |NS |Not supported |

|16 |Preferred method of |One letter code that indicates which method to |NS |NS |Not supported |

| |contact |use for contact. | | | |

PRA Segment - Practitioner Detail Segment

|Seq# |HL7 |Brief Description |R/O/S/ NS |Field |Comments |

| |element | | |stored by | |

| | | | |Misys? | |

|1 |Primary key |Must Match MFE-4 |NS |NS |Not supported. Physician code extracted |

| | | | | |from MFE;4. |

|2 |Practitioner Group |Name/code of group practitioner belongs to.. |NS |NS |Not supported |

|3 |Practitioner Category |Category of practitioner. |NS |NS |Not supported. |

| | |(MD,DO) | | | |

|4 |Provider billing |How provider services are billed |NS |NS |Not supported |

|5 |Specialty |Physician’s specialty. Must be a valid MA4 |O |Y | |

| | |code. | | | |

|6 |Practitioner ID Numbers |License numbers and other ID numbers |O |Y |1st component= UPIN |

| | | | | |2nd component=Secondary id |

| | | | | |3rd component=Tertiary id |

|7 |Privileges |Institutional privileges |NS |NS |Not supported |

Other Segments

For any additional segments listed as needed by Misys, please complete the following table. It is only necessary to list the fields that will be used. Attach additional pages if necessary.

Segment name _____________

|Seq# |HL7 |Brief Description |R/O/S/ NS |Should Field|Comments |

| |element | | |be stored by| |

| | | | |Misys? | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

| | | | | | |

Outbound Transactions

The Results Reporting Interface is an interface that sends several types of messages outbound from Misys to the receiving system. The types of messages are as follows:

Result messages (either ORU or UDM)

Order messages for lab generated orders

Status messages to indicate specimen received in lab

Cancel messages for lab generated cancels

Response to HIS initiated cancels

All of these outbound messages will be sent to the receiving system on one physical interface. If you need any of these messages sent to the HIS on separate interface lines, please notify Misys Application Interfacing.

Misys will implement either a UDM message type results interface or an ORU message type results interface. Both interface types will not be implemented unless two results interfaces are purchased from Misys.

A UDM message is a formatted or user ready message. It contains the actual data to be displayed as sent for the end user of the receiving system.

An ORU message is a segmented, discreet, or computer ready message. An ORU message is not meant to mirror or simulate a UDM message nor any internal inquiry function or report of the sending or receiving systems. It is solely the responsibility of the receiving system to perform all formatting of data needed for viewing by its end user.

Please be aware that no NTE segments will be sent in an ORU message. The receiving system must code to expect more than one OBX per resulted test. The receiving system should be able to detect the existence of an individual test code by the observation identifier (OBX;3) and associate all results in multiple OBX segments to that test code using the observation sub-id numbers (OBX;4).

NOTE: Example transactions are provided at the end of this document. Please review them carefully because it is what will be sent unless otherwise negotiated.

41. Outbound Message Types

a. Please indicate the message types that your HIS expects to receive from Misys:

ORDERS STATUSES CANCELS RESULTS

b. Are there any additional messages that your HIS expects? If so, list them and

explain in detail.

c. Will you implement ORU or UDM results or have you purchased both types of

interfaces?

ORU UDM BOTH

d. What lab modules have you purchased?

Misys Laboratory Blood Bank Microbiology

Misys Anatomic Pathology CoPath Anatomic Pathology

e. For which modules listed above do you expect transactions to be sent to the HIS on

this outbound interface?

f. If you have an existing Results interface from CoPath to Misys Lab, will the CoPath results need to cross the new Results interface to the other system? YES NO

g. If Yes, will Lab Initiated Orders (LIO) be used on this interface? YES NO

HL7 Segments

The Misys LIS uses the following HL7 segments for the types of outbound transactions indicated. The segments are listed in order of appearance for each transaction type. Repeating segments are listed in { }. Optional segments are listed in [ ].

|LIS Initiated Order Transactions |Specimen Received Status Messages |

|MSH |MSH |

|PID |PID |

|PV1 |PV1 |

|ORC |ORC |

|OBR |OBR |

|LIS Initiated Cancels |Response to HIS Initiated Cancels |

|MSH |MSH |

|PID |PID |

|PV1 |PV1 |

|ORC |ORC |

|OBR |OBR |

| | |

| | |

|Result Transactions (ORU) | |

|MSH |Result Transactions (UDM) |

|PID |MSH |

|PV1 |URD |

|ORC |{DSP} |

|OBR | |

|{OBX} | |

|[DSC] | |

Note: Misys does not send NTE segments in outbound messages.

Each HL7 segment and their fields are listed below. The fields valued by Misys on outbound transactions are highlighted in gray. Fields not normally valued are white. If the HIS requires a field listed as not valued, please indicate that it is needed by the HIS and why. Misys may then value the field but only if the information is available to the LIS and it is appropriately negotiated. Complete the table for each segment by entering a Y or an N in the appropriate column. Every white field marked as Y must be discussed with Misys. Length column indicates length of field usually sent by Misys. These can be changed to fit the needs of the receiving system.

Y = Field valued Field will be sent in every outbound transaction unless otherwise specified. It is assumed that the receiving system will ignore the fields it does not need.

O = Optional field Field may be valued by Misys and sent to the HIS as appropriate.

S = Special (REG) Special programming required for Misys to value this field. These fields can only be valued if the information is currently stored in the lab system. Use of any special fields must be negotiated.

NS = Not Supported Field not supported by Misys.

MSH Segment

|Seq # |HL7 |Brief Description |Valued by |Needed by HIS?|Length |Comments |

| |Element | |Misys? | | | |

|1 |Field Separator || |Y | | | |

|2 |Encoding Characters|component delimiter (^) | | | | |

| | |repeat delimiter (~) |Y | | | |

| | |escape character (\) | | | | |

| | |subcomponent delimiter (&) | | | | |

|3 |Sending Application|“OADD” will be sent unless otherwise negotiated|Y | |15 | |

|4 |Sending Facility |This field will not be valued unless otherwise |O | | | |

| | |negotiated | | | | |

|5 |Receiving |“DADD” will be sent unless otherwise negotiated|Y | |15 | |

| |Application | | | | | |

|6 |Receiving Facility |This field will not be valued unless otherwise |O | | | |

| | |negotiated | | | | |

|7 |Date & Time of |CCYYMMDDHHMMSS |Y | |14 | |

| |Message | | | | | |

|8 |Security | |NS |NS | |Not supported |

MSH Segment - continued

|Seq # |HL7 |Brief Description |Valued by |Needed by HIS?|Length |Comments |

| |Element | |Misys? | | | |

|9 |Message |Contains message type and trigger event. |Y | |7^7 | |

| |Type |Format is : | | | | |

| | | | | | | |

| | |New order from LIS: ORM^O01 | | | | |

| | |Cancel from LIS: ORM^O01 | | | | |

| | |Response to HIS cancel: ORM^O01 | | | | |

| | |Status message: ORM^O01 | | | | |

| | |Result message: ORU^R01 or | | | | |

| | |UDM^R03 depending on the type of result | | | | |

| | |interface | | | | |

|10 |Message control ID |If used, this sequence is valued with a number |Y | |20 |Format is: |

| | |that is unique to that message. The receiving | | | |CCYYDDDnnnnnnn where |

| | |system will echo this value in the MSA message.| | | |DDD is a true Julian |

| | | | | | |date and nnnnnnn is a |

| | | | | | |sequence number for the|

| | | | | | |day |

|11 |Processing ID |T for Training or P for Production |Y | |1 | |

|12 |Version ID |HL7 version (2.1 or 2.2) |Y | |3 | |

|13 |Sequence number | |NS |NS | |Not supported |

|14 |Continuation | |O | | | |

| |pointer | | | | | |

PID Segment

|Seq # |HL7 |Brief Description |Valued by |Needed by HIS?|Length |Comments |

| |Element | |Misys? | | | |

|1 |Set ID | |NS |NS | |Not supported |

|2 |Patient ID |Permanent patient identifier (other than |S | | | |

| |(external ID) |medical record number) from the patient | | | | |

| | |registration system | | | | |

|3 |Patient ID |The first component of this sequence is always |Y | |16^^^5 |Hospital ID will be |

| |(internal ID) |valued and is the Misys patient number. | | | |included if using Misys|

| | |Usually this is the patient’s medical record | | | |MULHOS software |

| | |number. If a hospital ID is required (as with | | | | |

| | |Mulhos), it is valued in the 4th component of | | | | |

| | |this sequence. Example: nnnnnnn^^^N | | | | |

|4 |Alternate patient |HMO ID |S | | | |

| |ID | | | | | |

|5 |Patient name |The sequence will be formatted as follows: |Y | |48^48^48 |Misys doesn’t store |

| | |Component one family name | | | |components 4-6 (suffix,|

| | |Component two given name initial | | | |title, degree) |

| | |Component three middle name | | | | |

| | | | | | | |

| | |Example: SMITH^JOHN^D | | | | |

|6 |Mother’s maiden | |S | | | |

| |name | | | | | |

|7 |Date of birth |The date format is YYYYMMDD |Y | |8 | |

|8 |Sex |If sex is not known, the LIS will default with |Y | |1 | |

| | |a “U” | | | | |

|9 |Patient alias |Sent only if stored on lab system |Y | |48^48^48 | |

|10 |Race | |S | | | |

|11 |Patient address | |S | | | |

| | | | | | | |

| | | | | | | |

| | | | | | | |

| | | | | | | |

| | | | | | | |

PID Segment

|Seq # |HL7 |Brief Description |Valued by |Needed by HIS?|Length |Comments |

| |Element | |Misys? | | | |

|12 |County code | |S | | | |

|13 |Phone number | |S | | | |

| |(home) | | | | | |

|14 |Phone number | |S | | | |

| |(business) | | | | | |

|15 |Language | |S | | | |

|16 |Marital status | |S | | | |

|17 |Religion | |S | | | |

|18 |Patient account | |Y | |12 | |

| |number | | | | | |

|19 |Social Security |Sent only if stored on lab system |Y | |9 | |

| |number | | | | | |

|20 |Driver license | |S | | | |

| |number | | | | | |

PV1 Segment

|Seq# |HL7 |Brief Description |Valued by |Needed by HIS?|Length |Comments |

| |element | |Misys? | | | |

|1 |Set ID | |NS |NS | |Not supported |

| |Patient ID | | | | | |

|2 |Patient class |Indicates the Misys event type |Y | |4 |Misys event type will be sent|

| | | | | | |in this field. |

|3 |Assigned patient |Misys does not store the bed field separately; |Y | |6^2 |Outpatient locations are |

| |location |it is included in the room field. Sent as: | | | |usually sent as loc^null. |

| | |Inpatients = nursing unit^room | | | |However the room may be |

| | |Outpatients = loc^ | | | |valued. |

| | |Observation = nurse unit^room | | | | |

|4 |Admission type | |NS |NS | |Not supported |

|5 |Preadmit number | |NS |NS | |Not supported |

|6 |Prior patient location | |NS |NS | |Not supported |

|7 |Attending doctor |Physician 1 |Y | |8^20^20 |Sent as: code^last |

| | | | | | |name^first name |

|8 |Referring doctor |Physician 2 |Y | |8^20^20 |Sent as: code^last |

| | | | | | |name^first name |

|9 |Consulting | |NS |NS | |Not supported |

| |doctor | | | | | |

|10 |Hospital Service | |NS |NS | |Not supported |

|11 |Temporary location | |NS |NS | |Not supported |

|12 |Preadmit indicator | |NS |NS | |Not supported |

|13 |Readmission indicator | |NS |NS | |Not supported |

|14 |Admit | |NS |NS | |Not supported |

| |source | | | | | |

|15 |Ambulatory status | |NS |NS | |Not supported |

|16 |VIP | |NS |NS | |Not supported |

| |indicator | | | | | |

|17 |Admitting doctor | |NS |NS | |Not supported |

|18 |patient type | |Y | |4 |Misys event type will be sent|

| | | | | | |in this field. |

PV1 Segment continued

|Seq# |HL7 |Brief Description |R/O/S/NS |Needed by HIS?|Length |Comments |

| |element | | | | | |

|19 |Visit number |Episode, stay, encounter number |NS |NS | |Not supported |

|20 |Financial class |Primary financial class assigned to the patient|NS |NS | |Not supported |

| | |for reimbursement. | | | | |

|21 |Charge price indicator |Determines which price schedule to use for |NS |NS | |Not supported |

| | |room/bed charges. | | | | |

|22 |Courtesy code |Code for special courtesies. |NS |NS | |Not supported |

|23 |Credit rating |Past credit experience |NS |NS | |Not supported |

|24 |Contract code |Type of contract and guarantor |NS |NS | |Not supported |

|25 |Contract effective date |Start date of contract |NS |NS | |Not supported |

|26 |Contract amount | |NS |NS | |Not supported |

|27 |Contract period |Contract duration |NS |NS | |Not supported |

|28 |Interest code |Amount of interest charged. |NS |NS | |Not supported |

|29 |Transfer to bad debt |Indicates account transferred to bad debt. |NS |NS | |Not supported |

| |code | | | | | |

|30 |Transfer to bad debt |Date from 29 |NS |NS | |Not supported |

| |date | | | | | |

|31 |Bad debt agency code |Collection Agency |NS |NS | |Not supported |

|32 |Bad debt transfer amount|Dollar amount of bad debt |NS |NS | |Not supported |

|33 |Bad debt recovery amount|Dollar amount of bad debt recovery |NS |NS | |Not supported |

|34 |Delete account indicator|Reason account was deleted from file |NS |NS | |Not supported |

|35 |Delete account date |Date from 34 |NS |NS | |Not supported |

|36 |Discharge disposition |Disposition of discharge (home, expired) |NS |NS | |Not supported |

|37 |Discharge to location |Facility patient discharged to |NS |NS | |Not supported |

PV1 Segment continued

|Seq# |HL7 |Brief Description |R/O/S/NS |Needed by HIS?|Length |Comments |

| |element | | | | | |

|38 |Diet type |Special diet |NS |NS | |Not supported |

|39 |Servicing facility |Facility with which this visit is associated. |NS |NS | |Not supported |

|40 |Bed status | |NS |NS | |Not supported |

|41 |Account status | |NS |NS | |Not supported |

|42 |Pending location |Nursing station or room where paient may be |NS |NS | |Not supported |

| | |moved. | | | | |

| |Prior temporary location| |NS |NS | |Not supported |

|43 | | | | | | |

|44 |Admit | |Y | |12 | |

| |date/time | | | | | |

|45 |Discharge date/time |Sent only if the patient has been discharged on|Y | |12 | |

| | |the lab system. | | | | |

|46 |Current patient balance |Visit balance due |NS |NS | |Not supported |

|47 |Total charges |Total visit charges |NS |NS | |Not supported |

|48 |Total adjustments |Total adjustments for visit |NS |NS | |Not supported |

|49 |Total payments |Total payments for visit. |NS |NS | |Not supported |

ORC Segment - Common Order

|Seq# |HL7 |Brief Description |Valued by |Needed by HIS?|Length |Comments |

| |element | |Misys? | | | |

|1 |Order Control |This sequence designates the type of message |Y | |2 |Depending on whether you |

| | |that is being sent. | | | |choose SN or NW for lab |

| | | | | | |generated orders, the |

| | |NW - New order generated by LIS when HIS | | | |placer and filler fields |

| | |accepts the LIS order number | | | |will be valued accordingly |

| | | | | | |in each outbound |

| | |SN - New order generated by LIS when HIS | | | |transaction type. |

| | |returns its own placer number to the LIS in | | | | |

| | |response to the order | | | | |

| | | | | | | |

| | |SC - Status update. Indicates specimen has | | | | |

| | |been received in lab. | | | | |

| | | | | | | |

| | |OC - Cancel generated by the LIS | | | | |

| | | | | | | |

| | |RE - Result transaction | | | | |

|2 |Placer number |This field is not valued on lab initiated order|Y | |75 |Placer is sent in both the |

| | |transactions. If order number update is in | | | |ORC;2 and the OBR;2. |

| | |place (SN and NA order controls), the HIS | | | | |

| | |placer number will be sent in this field on | | | | |

| | |outbound status, cancel and result | | | | |

| | |transactions. If order number update is not in| | | | |

| | |place, this field will be left unvalued for all| | | | |

| | |outbound transactions. | | | | |

|3 |Filler number |Lab “A number” sent on all lab initiated order |Y | |10 |Filler number sent in both |

| | |transactions. If order number update is in | | | |the ORC;3 and the OBR;3. |

| | |place, this field will be blank on status, | | | | |

| | |result and cancel messages as the HIS placer | | | |This field is for LIS order|

| | |number will be sent in the placer field for | | | |number. The LIS accession |

| | |those transactions. “A number” sent in this | | | |number is sent in OBR;20. |

| | |field on status and result transactions if | | | | |

| | |order number update (SN and NA order controls) | | | | |

| | |is not in place. | | | | |

ORC Segment - continued

|Seq # |HL7 |Brief Description |Valued by |Needed by |Length |Comments |

| |element | |Misys? |HIS? | | |

|4 |Placer group number | |NS |NS | |Not supported |

|5 |Order Status |Status at the order level is valued in OBR;25 |NS |NS | |Not supported |

|6 |Response flag | |NS |NS | |Not supported |

|7 |Timing/Quantity |OBR;27 is used for priority/timing. |NS |NS | |Not supported |

|8 |Parent | |NS |NS | |Not supported |

|9 |Date/time of transaction|Date/time of message is valued in the MSH |NS |NS | |Not supported |

| | |segment. See MSH;7 | | | | |

|10 |Entered by | |NS |NS | |Not supported |

|11 |Verified by |This field cannot be populated in result |NS |NS | |Not supported |

| | |messages; the resulting tech is stored at the | | | | |

| | |OBX level only. | | | | |

|12 |Ordering provider |Ordering Physician also sent in OBR;16. |Y | |8^20^20 |Sent as: code^last name^first |

| | | | | | |name |

|13 |Enterer’s location |Contains the ordering location, if valued by |Y | |8 | |

| | |the HIS. This sequence contains LAB for all | | | | |

| | |LIS generated order messages. | | | | |

|14 |Call back phone number | |NS |NS | |Not supported |

|15 |Effective date/time of | |NS |NS | |Not supported |

| |order | | | | | |

|16 |Order control code |If the order control code is OC, this sequence |Y | | |Valued only for LIS initiated |

| |reason |contains the cancel reason. The format is | | | |cancels. |

| | |code^translation. If the reason is free text, | | | | |

| | |it will be valued in the second component and | | | | |

| | |the first component left null. | | | | |

42. ORC;1 Indicate whether you require SN or NW for lab generated orders. If you require SN, we will assume that a message with NA will be returned to Misys as a response to the SN.

OBR Segment - Observation Request

|Seq# |HL7 |Brief Description |Valued by |Needed by HIS?|Length |Comments |

| |element | |Misys? | | | |

|1 |Set ID | |NS |NS | |Not supported |

|2 |Placer number |This field is not valued on lab initiated order|Y | |75 |Placer is sent in both the |

| | |transactions. If order number update is in | | | |ORC;2 and the OBR;2. |

| | |place (SN and NA order controls), the HIS | | | | |

| | |placer number will be sent in this field on | | | | |

| | |outbound status, cancel and result | | | | |

| | |transactions. If order number update is not in| | | | |

| | |place, this field will be left unvalued for all| | | | |

| | |outbound transactions. | | | | |

|3 |Filler number |Lab “A number” sent on all lab initiated order |Y | |10 |Filler number sent in both |

| | |transactions. If order number update is in | | | |the ORC;3 and the OBR;3. |

| | |place, this field will be blank on status, | | | | |

| | |result and cancel messages as the HIS placer | | | |This field is for LIS order|

| | |number will be sent in the placer field for | | | |number. The LIS accession |

| | |those transactions. “A number” sent in this | | | |number is sent in OBR;20. |

| | |field on status and result transactions if | | | | |

| | |order number update (SN and NA order controls) | | | | |

| | |is not in place. | | | | |

|4 |Universal service |The order code will be sent. |Y | |6^20 |code^description |

| |identifier | | | | | |

|5 |Priority |Priority is sent in OBR;27 |NS |NS | |Not supported. See |

| | | | | | |OBR;27.6 |

|6 |Requested date/time |See OBR;7, Observation date/time |NS |NS | |Not supported |

|7 |Observation date/time |The actual collection date/time of the order as|Y | |14 |CCYYMMDDHHMMSS |

| | |stored in the LIS. This value could possibly | | | |The seconds are always sent|

| | |differ from the original requested time sent by| | | |as 00. |

| | |the HIS in the inbound order message. | | | | |

|8 |Observation end | |NS |NS | |Not supported |

| |date/time | | | | | |

|9 |Collection volume | |NS |NS | |Not supported |

|10 |Collector identifier |Will be populated with the tech code of the |Y | |30 | |

| | |phlebotomist who collected the specimen. | | | | |

OBR Segment - continued

|Seq # |HL7 |Brief Description |Valued by |Needed by |Length |Comments |

| |element | |Misys? |HIS? | | |

|11 |Specimen action code | |NS |NS | |Not supported for the outbound |

| | | | | | |interface. |

|12 |Danger code | |NS |NS | |Not supported |

|13 |Relevant clinical | |NS |NS | |Not supported |

| |information | | | | | |

|14 |Specimen received |The date/time the specimen was received in the |Y | |20 | |

| |date/time |lab | | | | |

|15 |Specimen source |For non-micro: Valued only if the order was |Y | |6^30 |Sent as: code^description |

| | |“styped” in the lab. | | | |This piece sent for result |

| | | | | | |transactions only. |

| | |For micro: The specimen source is valued in | | | | |

| | |both the OBR;15 and in an OBX segment for test | | | | |

| | |SDES. | | | | |

|16 |Ordering provider |Ordering physician also sent in ORC;12. |Y | |8^20^20 |Sent as: code^last name^first |

| | | | | | |name |

|17 |Order call back phone | |NS |NS | |Not supported |

| |number | | | | | |

|18 |Placer’s field #1 | |S | | | |

|19 |Placer’s field #2 | |S | | | |

|20 |Filler’s field #1 |LIS accession number sent in this field for all|Y | |8 |This is the LIS accession number,|

| | |outbound transactions. Format is one alpha | | | |not the LIS filler number. |

| | |followed by up to 5 numerics. | | | | |

|21 |Filler’s field #2 | |S | | | |

|22 |Results report status |The time of result is sent in the individual |NS |NS | |Not supported |

| |change date/time |OBX and cannot be sent in the OBR. | | | | |

|23 |Charge to practice | |NS |NS | |Not supported |

|24 |Diagnostic service section|Performing MA5 Lab dept. (ex. C, H, BB,MC) |Y | |10 | |

| |ID | | | | | |

|25 |Results status |Result status at the order code level. Valued |Y | |1 |The result status in OBR;25 |

| | |with “P” for microbiology preliminary results. | | | |refers to the order code level |

| | |Field is left blank if a non-micro order code | | | |only. The individual test result|

| | |is incomplete. Valued with “F” if entire order| | | |status is reported in OBX;11 A |

| | |code (micro or non-micro) is complete. | | | |Applies to result messages only. |

OBR Segment - continued

|Seq # |HL7 |Brief Description |Valued by |Needed by HIS?|Length |Comments |

| |element | |Misys | | | |

|26 |Linked results |If “send part” is in place for packages, BB or |Y | |200 |Valued only if “send part”|

| | |MC, this field will be valued as follows: | | | |is in place. |

| | |component one will contain the original parent | | | | |

| | |order code and component two will contain the | | | | |

| | |child order code. | | | | |

|27 |Quantity/timing |Priority is sent in the 6th component of this |Y | |^^^^^6 | |

| | |sequence. The other components of this field | | | | |

| | |are not populated in the outbound interface. | | | | |

|28 |Result copies to |Copy to physicians will be sent only if stored |Y | |15^24 |Sent as: |

| | |with this order in the LIS. | | | |code^name~code^name~code^n|

| | | | | | |ame |

|29 |Parent number | |NS |NS | |Not supported |

|30 |Transportation mode | |NS |NS | |Not supported |

|31 |Reason for study | |NS |NS | |Not supported |

|32 |Principal result | |NS |NS | |Not supported |

| |interpreter | | | | | |

|33 |Assistant result | |NS |NS | |Not supported |

| |interpreter | | | | | |

|34 |Technician | |NS |NS | |Not supported |

|35 |Transcriptionist | |NS |NS | |Not supported |

|36 |Scheduled date/time | |NS |NS | |Not supported |

43. Outbound Order Code Translations

a. OBR;4 will be valued with both a code and the full name of the procedure (battery). The code will be in OBR;4.1 and the name in OBR;4.2. Should OBR;4.1 contain the Misys code or the HIS code?

HIS code Misys code

b. If you expect the HIS code in OBR;4.1, the interface will obtain the code from an existing translation table. Is this table the same for both inbound and outbound transactions or is a different set of translations required for each?

Same Different

OBX Segment – ORU results only

NOTE: OBX segments are sent only in ORU result transactions. If not implementing the ORU style interface, skip to page 64.

|Seq# |HL7 |Brief Description |Valued by |Needed by HIS?|Length |Comments |

| |element | |Misys? | | | |

|1 |Set ID |LIS values this with a sequential number which |Y | |3 | |

| | |increments when the observation identifier | | | | |

| | |(OBX;3) changes. The number in this field | | | | |

| | |cannot be used as a positional marker for a | | | | |

| | |specific test code. | | | | |

|2 |Data Value type |LIS sends data value types NM (numeric), ST |Y | |2 | |

| | |(short text string), FT (formatted free text), | | | | |

| | |CE (coded element). | | | | |

|3 |Observation identifier |Contains the code of the individual test being |Y | |6^30 | |

| | |resulted. The value of this field will be the | | | | |

| | |LIS test code unless otherwise negotiated. | | | | |

|4 |Observation sub-ID |Shows the relationship of this OBX to the test |Y | |3 | |

| | |in OBX;3. The value of this field should be | | | | |

| | |used as a key to the correct parsing of the | | | | |

| | |result pieces for display on the receiving | | | | |

| | |system. | | | | |

|5 |Observation results |The actual results of the test identified in |Y | | |LIS initiated orders do |

| | |sequence 3. | | | |not send results to the |

| | | | | | |HIS in the ORM message. |

|6 |Units |If a unit of measure is defined in the LIS, |Y | |20 |NOTE: Only the first OBX |

| | |that value will be sent in this field. | | | |for a test will have |

| | | | | | |values for OBX;6-8 and |

| | | | | | |OBX;11. |

|7 |Reference range |If a normal or reference range is defined in |Y | |60 |NOTE: Only the first OBX |

| | |the LIS, that value will be sent in this field.| | | |for a test will have |

| | |May include non-numeric normals such as POS or | | | |values for OBX;6-8 and |

| | |NEG. | | | |OBX;11. |

|8 |Abnormal flags |If the result has failed any LIS quality |Y | |10 |NOTE: Only the first OBX |

| | |assurance checks, all applicable HL7 flags will| | | |for a test will have |

| | |be sent, separated by the component separator | | | |values for OBX;6-8 and |

| | |(^). | | | |OBX;11. |

|9 |Probability | |NS |NS | |Not supported |

|10 |Nature of abnormal tests| |NS |NS | |Not supported |

OBX Segment - continued

|Seq# |HL7 |Brief Description |Valued by |Needed by HIS?|Length |Comments |

| |element | |Misys? | | | |

|11 |Observation results |This is the result status at the test level. |Y | |1 |NOTE: Only the first OBX for |

| |status |If a test is complete, the value is “F”. If a | | | |a test will have values for |

| | |test has been corrected from a previously | | | |OBX;6-8 and OBX;11. |

| | |reported value, the value will be “C”. If the | | | | |

| | |test is still pending, the value will be “I”. | | | | |

|12 |Date last OBS normal | |NS |NS | |Not supported |

| |values | | | | | |

|13 |User defined access | |NS |NS | |Not supported |

| |checks | | | | | |

|14 |Date/Time of observation|The time the result was entered into the lab |Y | |12 | |

| | |system will be sent in this field. | | | | |

|15 |Producer’s ID |Resulting lab location |Y | |20 | |

|16 |Responsible observer |The tech code of the technologist entering this|Y | |24 |Sent as: code^name |

| | |result will be sent in this field. | | | | |

44. Pending Tests

When results for a partially resulted battery are sent, an OBX will be sent for each test in the battery including those tests that are still unresulted. What text should be sent in OBX;5 for those tests?

PEND PENDING a set of double quote Other specify)

marks (“”)

45. OBX;2 (Data Value Type)

Misys values the OBX;2 with the following data types. Indicate which values your HIS expects. If your HIS cannot support any of the data types listed, list an alternate value for each data type.

|Value |Data type |HIS expects? |Comments/Alternate Value |

| | |Y/N | |

|NM |Numeric | |NM will be sent for the first OBX only and only if the result value of |

| | | |that OBX is numeric (including decimals). |

|CE |Coded Entry | |If the result was entered in lab as a coded value, the data type will be |

| | | |CE. However, only the actual text will be sent in the OBX;5. |

|ST |String Data | |Sent when result contains a +, sign. ST also used for tests %AAN,|

| | | |%UN and %RN and when composed text is entered in lab. |

|FT |Free Text | |Sent when free text is entered in lab. If the text exceeds 80 characters,|

| | | |another OBX will be generated for the remaining characters. |

46. Text Data

Text data can potentially be sent in a result for any laboratory section (Gen Lab, Micro, Blood Bank and Anatomic Pathology). The actual text entered in the lab will be placed in the OBX;5. If there is >1 line of text, each displayable line will be sent in a separate OBX segment.

a. Does your HIS have a limit to the length of text it can accept in a single OBX;5?

YES NO

b. If YES, what is that limit?

c. If the text is longer than the limit, how should the result be transmitted to the HIS?

d. Is there a limit as to the total number of OBX segments the HIS can accept per test?

YES NO

e. If YES, what is that limit?

f. If the result exceeds this limit, how should it be sent to the HIS?

47. OBX;3 (Observation identifier)

a. OBX;3 will be valued with both a code and the full name of the test. The code will be in OBX;3.1 and the name in OBX;3.2. Should OBX;3.1 contain the HIS code or the Misys code?

HIS CODE Misys CODE

b. If you expect the HIS code in OBX;3.1, the interface will obtain the code from an existing translation table. Is this table the same for both inbound and outbound transactions or is a different set of translations required for each?

SAME DIFFERENT

DSC Segment—Continuation Pointer Segment

|Seq # |HL7 element |Brief Description |Valued by |Needed by HIS? |Length |Comments |

| | | |Misys? | | | |

|1 |Continuation |Continuation pointer |O | | | |

| |Pointer | | | | | |

NOTE: The URD and DSP segments are used only for the UDM result transactions. If you are not implementing a UDM interface, please ignore the URD and DSP segment tables and questions.

URD Segment - Results/update definition (UDM interfaces only)

|Seq# |HL7 |Brief Description |Valued by |Needed by |Comments |

| |element | |Misys? |HIS? | |

|1 |R/U date/time |The LIS will value this sequence with the |Y | | |

| | |date/time it formats the result. | | | |

|2 |Report Priority |The LIS will value this sequence with “S” for |Y | | |

| | |stat order priority or “R” for all other order | | | |

| | |priorities. | | | |

|3 |R/U who subject |The first component is always valued and is the|Y | | |

| |definition |Misys patient number. If a hospital ID is | | | |

| | |required, it is in the 4th component of this | | | |

| | |sequence. | | | |

|4 |R/U what subject |The LIS will value this sequence with “RES” |Y | | |

| |definition |(for results) and will send the actual results | | | |

| | |in a display-oriented format (DSP segments). | | | |

|5 |R/U what department code|LIS will value the 1st component with universal|Y | | |

| | |service identifier (order code), the 2nd | | | |

| | |component with the test description, the 3rd | | | |

| | |component with the placer number and the 4th | | | |

| | |component with the filler number. | | | |

|6 |R/U display print |LIS will value the 1st component with the |Y | | |

| |locations |patient’s location and the 2nd component with | | | |

| | |the ordering location. | | | |

|7 |R/U results level | |NS |NS |Not supported |

DSP Segment - Display data (UDM interfaces only)

|Seq# |HL7 |Brief Description |Valued by |Needed by |Comments |

| |element | |Misys? |HIS? | |

|1 |Set ID (display data) | |NS |NS |Not supported |

| |Display level | |NS |NS |Not supported |

|2 | | | | | |

|3 |Data line |The 1st two DSP segments will contain patient |Y | | |

| | |and order data. The 3rd DSP will contain the | | | |

| | |first actual line of results as it should be | | | |

| | |displayed or printed in the HIS. The 4th DSP | | | |

| | |will contain the second actual line of results | | | |

| | |and so on. It is the responsibility of the HIS| | | |

| | |to tell the LIS how many characters per line | | | |

| | |and the maximum number of data lines that can | | | |

| | |be supported. | | | |

|4 |Logical break point | |NS |NS |Not supported |

|5 |Result ID | |NS |NS |Not supported |

48. UDM Interfaces

a. What is the maximum allowable characters per line (DSP;3) that your HIS can support?

b. What is the maximum number of DSP segments that your HIS can support?

49. Send Part vs Send All

The LIS can implement “send part” or “send all” for microbiology, blood bank and package results for both ORU and UDM style interfaces.

For microbiology results, if set to “send all”, then all of the results (culture and susceptibilities) are sent in one transaction. Every time a susceptibility is added to the culture, a single transaction is sent that includes the culture results and all susceptibilities.

If set to “send part”, the culture will be sent in one transaction and each susceptibility will be sent in its own transaction. If an additional susceptibility is added, a transaction will be sent for that susceptibility only (the culture and previous susceptibilities are not re-sent).

For Blood Bank results, if set to “send all”, then all of the results (crossmatch results and unit information) are sent in one transaction. If an additional unit is added, a single transaction is sent that includes the crossmatch results and all units. If set to “send part”, the crossmatch results will be sent in one transaction and results for each unit of blood will be sent in its own transaction. If an additional unit is added, a transaction will be sent for that unit only (the crossmatch and previous units are not re-sent).

For packages, if set to “send all”, then results for all the batteries will be sent together in one transaction. If set to “send part”, the results for each battery in the package will be sent in separate transactions and results for the previously resulted battery will not be re-sent.

NOTE: Neither setting will delay the reporting of any results. Results are sent for

“all” or “part” as soon as they are available.

a. For Microbiology, should the LIS implement “send part” or “send all”?

Send Part Send All

b. For Blood Bank, should the LIS implement “send part” or “send all”?

Send Part Send All

c. For Packages, should the LIS implement “send part” or “send all”?

Send Part Send All

50. ORU result transaction Examples:

The following examples show the Misys LIS lab inquiry screen display followed by an example of the result transaction. These transactions show how the result will be sent across the interface using the ORU format:

Example 1:

Misys LIS Inquiry Display

POTASSIUM *6.5 [3.6-4.9] meQ/L

HEMOLYZED

RESULT CHECKED

Interface Transaction

MSH|^~\&|OADD||DADD||19980928161101||ORU^R01|19982840000001|P|2.2|

PID|||3237983^^^1||SMITH^ROBERT L^||19480520|M|^^|||||||||999|322423287|

PV1||IP|ICU^ICU-1||||3L^HOWARD^CURLEY|^||||||||||IP||||||||||||||||||||||||||199712180000||

ORC|RE|842||||||||||4L^HOWARD^SHEMP|||

OBR||842||K^POTASSIUM|||199809280200|||||||199809280222|^|4L^HOWARD^SHEMP||||F440||||C|F|K^K|^^^^^R|1L^FINE^LARRY^~^~^|||||||

OBX|1|NM|K^POTASSIUM|1|6.5|meQ/L|3.6-4.9|H^HH|||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|1|CE|K^POTASSIUM|2|HEMOLYZED|||||||||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|1|CE|K^POTASSIUM|3|RESULT CHECKED|||||||||199809281532|R^ROUTINE LAB|21^TECH^JOE|

Example 2:

Misys LIS Inquiry Display

POTASSIUM *6.5 [3.6-4.9] meQ/L

(NOTE)

Specimen was grossly hemolyzed. Dr. Robert Smith was notified but he

requested that the test be run anyway.

I ran the test and got a very high result. Result called to Dr. Smith.

Interface Transaction

MSH|^~\&|OADD||DADD||19980928161101||ORU^R01|19982840000002|P|2.2|

PID|||3237983^^^1||SMITH^ROBERT L^||19480520|M|^^|||||||||999|322423287|

PV1||IP|ICU^ICU-1||||3L^HOWARD^CURLEY^|^||||||||||IP||||||||||||||||||||||||||199712180000||

ORC|RE||A00041|||||||||4L^HOWARD^SHEMP^|||

OBR|||A00041|K^POTASSIUM|||199809280200|||||||199809280222|^|4L^HOWARD^SHEMP^||||F442||||C|F|K^K|^^^^^R|1L^FINE^LARRY^~^~^|||||||

OBX|1|NM|K^POTASSIUM|1|6.5|meQ/L|3.6-4.9|H^HH|||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|1|ST|K^POTASSIUM|2|(NOTE)|||||||||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|1|ST|K^POTASSIUM|3|Specimen was grossly hemolyzed. Dr. Robert Smith notified but he|||||||||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|1|ST|K^POTASSIUM|4|requested that the test be run anyway.|||||||||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|1|ST|K^POTASSIUM|5|””|||||||||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|1|ST|K^POTASSIUM|6|I ran the test and got a very high result. Result called to Dr. Smith.|||||||||199809281532|R^ROUTINE LAB|21^TECH^JOE|

Example 3, Microbiology:

Misys LIS Inquiry Display

WOUND CULTURE

SPECIMEN DESCRIPTION PLEURAL

SPECIAL REQUESTS NONE

GRAM SMEAR 2+ GRAM NEGATIVE RODS

FEW WBC'S SEEN

CULTURE RESULTS 3+ ESCHERICHIA COLI

2+ STREPTOCOCCI, NON HEMOLYTIC

REPORT STATUS FINAL 09281998

SUSCEPTIBILITY

ORGANISM 3+ ESCHERICHIA COLI

METHOD KIRBY BAUER

CEPHALOTHIN SUSCEPTIBLE

TETRACYCLINE RESISTANT

GENTAMICIN INTERMEDIATE

KANAMYCIN SUSCEPTIBLE

Interface Transaction, “Send All”

MSH|^~\&|OADD||DADD||19980928161101||ORU^R01|19982840000003|P|2.2|

PID|||3237983^^^1||SMITH^ROBERT L^||19480520|M|^^|||||||||999|322423287|

PV1||IP|ICU^ICU-1||||3L^HOWARD^CURLY^|^||||||||||IP||||||||||||||||||||||||||199712180000||

ORC|RE|849||||||||||4L^HOWARD^SHEMP^|||

OBR||849||WDC^WOUND CULTURE|||199809280200|||||||199809280222|PLEU^PLEURAL FLUID|4L^HOWARD^SHEMP^||||F442||||MC^MB|F||^^^^^R|1L^FINE^LARRY^~^~^|||||||

OBX|1|CE|SDES^SPECIMEN DESCRIPTION|1|PLEURAL FLUID||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|2|CE|SREQ^SPECIAL REQUESTS|1|NONE||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|3|CE|GS^GRAM SMEAR|1|2+ GRAM NEGATIVE RODS||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|3|CE|GS^GRAM SMEAR|2|FEW WBC’S SEEN|||||||||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|4|CE|CULT^CULTURE RESULTS|1|3+ ESCHERICHIA COLI||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|4|CE|CULT^CULTURE RESULTS|2|2+ STREPTOCOCCI, NON HEMOLYTIC|||||||||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|5|ST|RPT^REPORT STATUS|1|FINAL 10091998||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|6|CE|ORG^ORGANISM|1|3+ ESCHERICHIA COLI||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|7|CE|MTYP^METHOD|1|KIRBY BAUER||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|8|CE|CEPH^CEPHALOTHIN|1|SUSCEPTIBLE||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|9|CE|TET^TETRACYCLINE|1|RESISTANT||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|10|CE|GM^GENTAMICIN|1|INTERMEDIATE||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

Example 3 continued

Interface Transactions “Send Part”

MSH|^~\&|OADD||DADD||19980928161101||ORU^R01|19982840000003|P|2.2|

PID|||3237983^^^1||SMITH^ROBERT L^||19480520|M|^^|||||||||999|322423287|

PV1||IP|ICU^ICU-1||||3L^HOWARD^CURLY^|^||||||||||IP||||||||||||||||||||||||||199712180000||

ORC|RE|849||||||||||4L^HOWARD^SHEMP^|||

OBR||849||WDC^WOUND CULTURE|||199809280200|||||||199809280222|PLEU^PLEURAL FLUID|4L^HOWARD^SHEMP^||||F442||||MC^MB|F||^^^^^R|1L^FINE^LARRY^~^~^|||||||

OBX|1|CE|SDES^SPECIMEN DESCRIPTION|1|PLEURAL FLUID||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|2|CE|SREQ^SPECIAL REQUESTS|1|NONE||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|3|CE|GS^GRAM SMEAR|1|2+ GRAM NEGATIVE RODS||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|3|CE|GS^GRAM SMEAR|2|FEW WBC’S SEEN|||||||||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|4|CE|CULT^CULTURE RESULTS|1|3+ ESCHERICHIA COLI||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|4|CE|CULT^CULTURE RESULTS|2|2+ STREPTOCOCCI, NON HEMOLYTIC|||||||||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|5|ST|RPT^REPORT STATUS|1|FINAL 10091998||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

MSH|^~\&|OADD||DADD||19980928161101||ORU^R01|19982840000003|P|2.2|

PID|||3237983^^^1||SMITH^ROBERT L^||19480520|M|^^|||||||||999|322423287|

PV1||IP|ICU^ICU-1||||3L^HOWARD^CURLY^|^||||||||||IP||||||||||||||||||||||||||199712180000||

ORC|RE|849||||||||||4L^HOWARD^SHEMP^|||

OBR||849||ZZ00^SUSCEPTIBILITY|||199809280200|||||||199809280222|PLEU^PLEURAL FLUID|4L^HOWARD^SHEMP^||||F442||||MC^MB|F|WDC^3+ ESCHERICHIA COLI|^^^^^R|1L^FINE^LARRY^~^~^|||||||

OBX|6|CE|ORG^ORGANISM|1|3+ ESCHERICHIA COLI||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|7|CE|MTYP^METHOD|1|KIRBY BAUER||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|8|CE|CEPH^CEPHALOTHIN|1|SUSCEPTIBLE||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|9|CE|TET^TETRACYCLINE|1|RESISTANT||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

OBX|10|CE|GM^GENTAMICIN|1|INTERMEDIATE||||||F|||199809281532|R^ROUTINE LAB|21^TECH^JOE|

Example 4, Blood Bank:

Misys LIS Inquiry Display

CROSSMATCH

RED CELL GROUP

2

R543

ABO/RH(D) A POSITIVE

ANTIBODY NEGATIVE

Crossmatch Exp 10041998

PHYSICIAN'S INSTRUCT PLEASE TRANSFUSE WITH BLOOD

WARMER AND USE RIGHT ARM

Allocated Unit

UNIT NUMBER H3456

COMPONENT TYPE AUTOLOGOUS WB

STATUS OF UNIT ALLOCATED

TRANSFUSION STATUS OK TO TRANSFUSE

CROSSMATCH RESULT COMPATIBLE

Allocated Unit

UNIT NUMBER J3456

COMPONENT TYPE PACKED RED BLOOD CELLS

STATUS OF UNIT ALLOCATED

TRANSFUSION STATUS OK TO TRANSFUSE

CROSSMATCH RESULT COMPATIBLE

UNIT TAG COMMENT USE A FILTER

Interface Transaction “send all”

MSH|^~\&|OADD||DADD||19981005092603||ORU^R01|19982860000007|P|2.2|

PID|||1933^^^1||RUBBLE^BETTY^||19600515|F|^^|||||||||2840|291223033|

PV1||IP|ICU^100||||^|^||||||||||IP||||||||||||||||||||||||||199809040000||

ORC|RE|352||||||||||^|||

OBR||352||XM^CROSSMATCH|||199810011319|||||||100910011400|^|||||S17||||BB|||^^^^^R|^~^~^|||||||

OBX|1|CE|%ABR^ABO/RH(D)|1|A||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|1|CE|%ABR^ABO/RH(D)|2|POSITIVE|||||||||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|2|CE|%AS^ANTIBODY|1|NEGATIVE||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|3|ST|%EXX^Crossmatch Exp|1|10041998||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|4|FT|%PI^PHYSICIAN'S INSTRUCTIONS|1|PLEASE TRANSFUSE WITH BLOOD WARMER AND USE RIGHT ARM||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|5|ST|%UN^UNIT NUMBER|1|H3456||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|6|CE|%CT^COMPONENT TYPE|1|AUTOLOGOUS WB||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|7|CE|%ST^STATUS OF UNIT|1|ALLOCATED||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|8|CE|%TS^TRANSFUSION STATUS|1|OK TO TRANSFUSE||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|9|CE|%XM^CROSSMATCH RESULT|1|COMPATIBLE||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|10|ST|%UN^UNIT NUMBER|1|J3456||||||F||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|11|CE|%CT^COMPONENT TYPE|1|PACKED RED BLOOD CELLS||||||F||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|12|CE|%ST^STATUS OF UNIT|1|ALLOCATED||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|13|CE|%TS^TRANSFUSION STATUS|1|OK TO TRANSFUSE||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|14|CE|%XM^CROSSMATCH RESULT|1|COMPATIBLE||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|15|FT|%CM^UNIT TAG COMMENT|1|USE A FILTER||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

Interface Transactions “send part”

MSH|^~\&|OADD||DADD||19981005092603||ORU^R01|19982860000007|P|2.2|

PID|||1933^^^1||RUBBLE^BETTY^||19600515|F|^^|||||||||2840|291223033|

PV1||IP|ICU^100||||^|^||||||||||IP||||||||||||||||||||||||||199809040000||

ORC|RE|352||||||||||^|||

OBR||352||XM^CROSSMATCH|||199810011319|||||||100910011400|^|||||S17||||BB|||^^^^^R|^~^~^|||||||

OBX|1|CE|%ABR^ABO/RH(D)|1|A||||||F||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|1|CE|%ABR^ABO/RH(D)|2|POSITIVE||||||F||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|2|CE|%AS^ANTIBODY|1|NEGATIVE||||||F||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|3|ST|%EXX^Crossmatch Exp|1|10/04/1998||||||F||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|4|FT|%PI^PHYSICIAN'S INSTRUCTIONS|1|PLEASE TRANSFUSE WITH BLOOD WARMER AND USE RIGHT ARM||||||F||199810011412|R^ROUTINE LAB|21^TECH^JOE|

MSH|^~\&|OADD||DADD||19981005092603||ORU^R01|19982860000007|P|2.2|

PID|||1933^^^1||RUBBLE^BETTY^||19600515|F|^^|||||||||2840|291223033|

PV1||IP|ICU^100||||^|^||||||||||IP||||||||||||||||||||||||||199809040000||

ORC|RE|352||||||||||^|||

OBR||352||ZY000^Allocated unit|||199810011319|||||||100910011400|^|||||S17||||BB||XM^ZY000|^^^^^R|^|||||

||

OBX|1|ST|%UN^UNIT NUMBER|1|H3456||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|2|CE|%CT^COMPONENT TYPE|1|AUTOLOGOUS WB||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|3|CE|%ST^STATUS OF UNIT|1|ALLOCATED||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|4|CE|%TS^TRANSFUSION STATUS|1|OK TO TRANSFUSE||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|5|CE|%XM^CROSSMATCH RESULT|1|COMPATIBLE||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

MSH|^~\&|OADD||DADD||19981005092603||ORU^R01|19982860000007|P|2.2|

PID|||1933^^^1||RUBBLE^BETTY^||19600515|F|^^|||||||||2840|291223033|

PV1||IP|ICU^100||||^|^||||||||||IP||||||||||||||||||||||||||199809040000||

ORC|RE|352||||||||||^|||

OBR||352||ZY001^Allocated unit|||199810011319|||||||100910011400|^|||||S17||||BB||XM^ZY001|^^^^^R|^|||||

||

OBX|1|ST|%UN^UNIT NUMBER|1|J3456||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|2|CE|%CT^COMPONENT TYPE|1|AUTOLOGOUS WB||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|3|CE|%ST^STATUS OF UNIT|1|ALLOCATED||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|4|CE|%TS^TRANSFUSION STATUS|1|OK TO TRANSFUSE||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|

OBX|5|CE|%XM^CROSSMATCH RESULT|1|COMPATIBLE||||||F|||199810011412|R^ROUTINE LAB|21^TECH^JOE|OBX|6|FT|%CM^UNIT TAG COMMENT|1|USE A FILTER||||||F||199810011412|R^ROUTINE LAB|21^TECH^JOE|

51.UDM result transaction Examples:

The following examples show the Misys LIS lab inquiry screen display followed by an example of the result transaction. These transactions show how the result will be sent across the interface using the UDM format:

Example 1:

Misys LIS Inquiry Display

POTASSIUM *6.5 [3.6-4.5] meQ/L

SPECIMEN HEMOLYZED

RESULT CHECKED

Interface Transaction

MSH|^~\&|LIS|001|HIS|001|199812230914| |UDM^R03|1|P|2.1|

URD|199812230914| |3237983^3237983^3237983^|RES|876^K^POTASSIUM|UNK0~UNK01~^|T|

DSP | | |Pat: SMITH,ROBERT (000003237983) Age/Sex: 50 M Loc: UNK0-00 (UNK0)

DSP | | |

DSP | | |H579 COLL: 12/17/98 11:00 REC: 12/17/98 13:50 PHYS: HOWARD,SHEMP

DSP | | | POTASSIUM

DSP | | | POTASSIUM C6.5 (3.2-4.5) MMOL/L

DSP | | | SPECIMEN HEMOLYZED

DSP | | | RESULT CHECKED

Example 2:

Misys LIS Inquiry Display

POTASSIUM *6.5 [3.6-4.5] meQ/L

(NOTE)

Specimen was grossly hemolyzed. Dr. Robert Smith was notified but he

requested that the test be run anyway.

I ran the test and got a very high result. Result called to Dr. Smith.

Interface Transaction

MSH|^~\&|LIS|001|HIS|001|199812281058| |UDM^R03|1|P|2.1|

URD|199812281058| |3237983^3237983^3237983^|RES|876^K^POTASSIUM|UNK0~UNK01~^|T|

DSP | | |Pat: SMITH,ROBERT (000003237983) Age/Sex: 50 M Loc: UNK0-00 (UNK0)

DSP | | |

DSP | | |H580 COLL: 12/17/98 13:00 REC: 12/17/98 13:50 PHYS: HOWA RD,SHEMP

DSP | | | POTASSIUM

DSP | | | POTASSIUM C6.5 (3.2-4.5) MMOL/L

DSP | | | (NOTE)

DSP | | |Specimen was grossly hemolyzed. Dr. Robert Smith was notified but he

DSP | | |requested that the test be run anyway.

DSP | | |

DSP | | |I ran the test and got a very high result. Result called to Dr. Smith.

Microbiology Example:

Misys LIS Inquiry Display

WOUND CULTURE

SPECIMEN DESCRIPTION PLEURAL

SPECIAL REQUESTS NONE

GRAM SMEAR 2+ GRAM NEGATIVE RODS

FEW WBC'S SEEN

CULTURE RESULTS 3+ ESCHERICHIA COLI

2+ STREPTOCOCCI, NON HEMOLYTIC

REPORT STATUS FINAL 09281998

SUSCEPTIBILITY

ORGANISM 3+ ESCHERICHIA COLI

METHOD KIRBY BAUER

CEPHALOTHIN SUSCEPTIBLE

TETRACYCLINE RESISTANT

GENTAMICIN INTERMEDIATE

KANAMYCIN SUSCEPTIBLE

Send All:

MSH|^~\&|LIS|001|HIS|001|199812231053||UDM^R03|1|P|2.1|

URD|199812231053| |3237984^^^|RES|A1234567^WDC^WOUND CULTURE|ICU~ICU-1~^|T|

DSP | | |Pat: EVANS,ROBERT (3237983) Age/Sex: 50 M Loc: ICU-1 (ICU )

DSP | | |

DSP | | | W864 COLL: 12/16/98 02:00 REC: 12/16/98 02:30 PHYS: HOWARD,SHEMP

DSP | | | WOUND CULTURE

DSP | | | SPECIMEN DESCRIPT PLEURAL

DSP | | | SPECIAL REQUESTS NONE

DSP | | | GRAM SMEAR 2+ GRAM NEGATIVE RODS

DSP | | | FEW WBC'S SEEN

DSP | | | CULTURE RESULTS 3+ ESCHERICHIA COLI

DSP | | | 2+ STREPTOCOCCI, NON HEMOLYTIC

DSP | | | REPORT STATUS FINAL 121698

DSP | | | SUSCEPTIBILITY

DSP | | | ORGANISM 3+ ESCHERICHIA COLI

DSP | | | METHOD KIRBY BAUER

DSP | | | CEPHALOTHIN SUSCEPTIBLE

DSP | | | TETRACYCLINE RESISTANT

DSP | | | GENTAMICIN INTERMEDIATE

DSP | | | KANAMYCIN SUSCEPTIBLE

Send Part:

MSH|^~\&|LIS|001|HIS|001|199812231053||UDM^R03|1|P|2.1|

URD|199812231053| |3237984^^^|RES|A1234567^WDC^WOUND CULTURE|ICU~ICU-1~^|T|

DSP | | |Pat: EVANS,ROBERT (3237983) Age/Sex: 50 M Loc: ICU-1 (ICU )

DSP | | |

DSP | | | W864 COLL: 12/16/98 02:00 REC: 12/16/98 02:30 PHYS: HOWARD,SHEMP

DSP | | | WOUND CULTURE

DSP | | | SPECIMEN DESCRIPT PLEURAL

DSP | | | SPECIAL REQUESTS NONE

DSP | | | GRAM SMEAR 2+ GRAM NEGATIVE RODS

DSP | | | FEW WBC'S SEEN

DSP | | | CULTURE RESULTS 3+ ESCHERICHIA COLI

DSP | | | 2+ STREPTOCOCCI, NON HEMOLYTIC

DSP | | | REPORT STATUS FINAL 121698

MSH|^~\&|LIS|001|HIS|001|199812231053||UDM^R03|1|P|2.1|

URD|199812231053| |3237984^^^|RES|A1234567^ZZ00^SUSCEPTIBILITY|ICU~ICU-1~^|T|

DSP | | |Pat: EVANS,ROBERT (3237983) Age/Sex: 50 M Loc: ICU-1 (ICU )

DSP | | |

DSP | | | W864 COLL: 12/16/98 02:00 REC: 12/16/98 02:30 PHYS: HOWARD,SHEMP

DSP | | | SUSCEPTIBILITY

DSP | | | ORGANISM 3+ ESCHERICHIA COLI

DSP | | | METHOD KIRBY BAUER

DSP | | | CEPHALOTHIN SUSCEPTIBLE

DSP | | | TETRACYCLINE RESISTANT

DSP | | | GENTAMICIN INTERMEDIATE

DSP | | | KANAMYCIN SUSCEPTIBLE

-----------------------

[1] Fields PV1;2 and PV1;18 are optional fields. However Misys strongly encourages the HIS to send a value in one of these two fields that can be used as the lab event type.

[2] There are 4 fields available in the HL7 ADT message for physicians. Although none of these are required fields, if sent, Misys can store a maximum of 2 physicians. Please indicate which should be used as physician 1 and which should be used as physician 2 in ADT transactions.

[3] Has the Medicaid compliance pack been purchased? If yes, can the HIS send the ABN flag? If yes, where will it be sent?

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download