Tech Note HeartSuite™ CVIS 3.1 HL7 Specification · The HeartSuite CVIS HL7 Inbound Server is...

85000-0764B

Tech Note

HeartSuite™ CVIS 3.1HL7 Specification1. IntroductionThe HeartSuite CVIS HL7 Inbound Server is used to populate the HeartSuite CVIS database with patient information from clinical and administrative hospital information systems. Through its support of ADT, MDM, MFN, ORM, ORU and SIU message types, the interface provides the following services to HeartSuite CVIS:

• Primary source of patient demographic, visit, event, and order data. This eliminates redundant data entry of patient data and decreases the possibility of data entry error (ADT, MDM, ORM, ORU, and SIU).

• Update of patient and visit data. Data received via HL7 cannot be updated using the HeartSuite CVIS application. This eliminates the possibility of data mismatch between HeartSuite CVIS and the hospital's ADT system.

• Source of patient clinic result information. A summary of clinical results from other clinical information systems can be associated with a patient record in HeartSuite CVIS (MDM and ORU messages).

• Post text reports to the HeartSuite CVIS document repository (MDM and ORU messages).

• Update of physician rolodex data (MFN messages).

The HeartSuite CVIS HL7 Outbound HL7 Server is used to send ORM^O01 order messages (scheduled procedures) to interested receiving systems (i.e. VERICIS/EchoIMS). It is also used to send ORU^R01 or MDM^T02 reports messages that are created in HeartSuite CVIS.

2. Networking Requirements

2.1. MLLP Transport Protocol

All inbound and outbound HL7 messages transferred between HeartSuite CVIS HL7 and a HIS is done via TCP/IP socket based communications with the message in the following HL7 MLLP data protocol form: <SB><HL7 Data><EB>

where:

<SB> is the start block. It is a single ACSII 11 (x0B) character.

<HL7 Data> is the HL7 message flatwire consisting of HL7 segments. Each segment must be terminated by an ASCII 13 (x0D) character.

<EB> is the end block. It is a two character sequence; ASCII 28 (x1C) followed by ASCII 13 (x0D).

Confidentiality Statement

© 2000-2006 Emageon Inc. 1200 Corporate Drive, Suite 200, Birmingham, AL 35242 | Support: 888-EMAGEON.The information contained herein is confidential and is the sole property of Emageon Inc. None of the information may be reproduced, copied, and/or re-distributed electronically, manually, or otherwise to any person without advance written permission from Emageon, except as may be expressly authorized bycontracts or other agreements between Emageon and its customer. Emageon is a registered trademark and Enterprise Visual Medical System (EVMS) is atrademark of Emageon Inc. Other trademarks or service marks referred to herein are the property of their respective owners.

2.2. Network Connection and Transport Protocols

The standard HeartSuite CVIS HL7 Inbound Server expects the following networking capabilities from a HIS that sends it HL7 messages:

• The physical network layer is Ethernet.

• The HL7 messages will be transmitted using MLLP over TCP/IP. Batch HL7 is not supported.

• The HIS will connect to a configurable port at an IP address that has been selected by the hospital's network and/or IS departments. Multiple inbound connections to this port are supported. Multiple ports are not supported.

• The HIS will accept an HL7 ACK acknowledgement message in response to the messages sent to HeartSuite CVIS.

• The HIS will buffer messages in the event that the connection to the HeartSuite CVIS HL7 Inbound Server goes down. The buffered messages will be sent once the connection has been re-established.

• The HIS will listen on a port at a specific IP address to receive unsolicited order and/or report messages from HeartSuite CVIS HL7 Outbound Server.

• The HIS will send acknowledgement messages with the HL7 ACK message type in response to the unsolicited order and/or report messages sent from HeartSuite CVIS HL7 Outbound Server.

2.3. Messaging Data Flow

The HeartSuite CVIS HL7 Inbound Server is capable of handling data flow that is unsolicited and unidirectional. As a server, the standard HeartSuite CVIS HL7 Inbound Server accepts unsolicited messages sent by the HIS. The HeartSuite CVIS HL7 Inbound Server, in turn, replies with an HL7 acknowledgement message of type ACK.

The HeartSuite CVIS HL7 Inbound Server transfers and processes HL7 messages with the following conditions:

• Original acknowledgement rules apply.

• Non-deferred reply is used.

• Segments are not continued across messages.

• Messages are not batched.

Messages transferred between HeartSuite CVIS and the HIS are sent individually (segments do not span more than one HL7 message), and are acknowledged individually.

On startup, the HeartSuite CVIS HL7 Inbound Server waits for a TCP/IP connection request initiated by a HIS. When the HIS is required to send a message, and there is no existing connection, it must connect to the HeartSuite CVIS HL7 Inbound Server, and request a connection. Upon acceptance of the requested connection, the HIS transfers the message data and keeps the connection open until an acknowledgement from the HeartSuite CVIS HL7 Inbound Server is received. After this message transfer and acknowledgement cycle, the HIS can keep the connection open for further message transfers, or disconnect from the HeartSuite CVIS HL7 Inbound Server until another message transfer is required. At that time, another request for connection by the HIS is required and the same sequence of events is executed.

On startup, the HeartSuite CVIS HL7 Outbound Server will attempt to connect to the HIS when data is available for transfer to the HIS. After the message is sent, the HeartSuite CVIS HL7 Outbound Server will wait a configurable amount of time for an acknowledgement to be returned. If an acknowledgement is not returned, the HeartSuite CVIS HL7 Outbound Server will attempt to resend the message again after 2 seconds, 4 seconds, 8 seconds, 16 seconds, up to a 30-second maximum. If there is no acknowledgement received after 4 attempts, then an email notification is sent to the system administrator (if emailing is configured). Since the order of HL7 messages is important, the HeartSuite CVIS HL7 Outbound Server will resend the message at 30-second intervals indefinitely until either an acknowledgement is received or the Message Sender service is stopped.

Tech Note: HeartSuite CVIS 3.1 HL7 Specification

Proprietary and Confidential | 85000-0764B of 69

2.4. Message Acknowledgement from HeartSuite CVIS HL7 Inbound Server

The HeartSuite CVIS HL7 Inbound Server acknowledges a message after it has queued the message in its database message queue table. The acknowledgement must be sent on the same TCP/IP connection on which the inbound message was sent.

The acknowledgement message returned from HeartSuite CVIS conforms to the following message grammar: MSH MSA

The message type returned for all acknowledgements is ACK. MSA-1 will be 'AA'. The HeartSuite CVIS HL7 Inbound Server echoes the originating message's message control ID in MSA-2. If an unsupported message is received, an acknowledgement message having type 'ACK', code 'AA' is returned with Message type not supported in the Text Message field MSA-3.

Enhanced acknowledgement is not supported.

2.5. Acknowledgement from HIS

The acknowledgement message returned from the HIS consists of the MSH and MSA segments. The message type returned for all acknowledgements is ACK. The HIS echoes the originating message's message control ID in MSA-2. The ERR segment is not used.

MSH Segment

Description Notes

MSH-1 Field Separator '|'

MSH-2 Encoding Characters '^~\&'

MSH-3 Sending Application 'HeartSuiteCVIS'

MSH-7 Date/Time of Message Date from MSH-7 of incoming message

MSH-9 Message type 'ACK'

MSH-10 Message control ID Unique identifier to relate response to initial message.

MSH-11 Processing ID 'P'

MSH-12 Version ID '2.3'

MSA Segment

Description Notes

MSA-1 Acknowledgement Code 'AA'

MSA-2 Message Control ID ID taken from Message Control ID field (MSH-10) of incoming message.

MSA-3 Text Message 'Message Received'

MSA-4 Expected Sequence Number 0

MSH Segment

Description Notes

MSH-1 Field Separator '|'

MSH-2 Encoding Characters '^~\&'

MSH-7 Date/Time of Message Date/time

MSH-9 Message type 'ACK'

MSH-10 Message control ID Unique identifier.



3. Supported Messages

3.1. Inbound - Supported Message Types

The standard HeartSuite CVIS HL7 Inbound Server supports the following HL7 messages:

ADTÂ01 - Admit patient

ADTÂ02 - Transfer patient

ADTÂ03 - Discharge patient

ADTÂ04 - Register patient

ADTÂ05 - Pre-admit a patient

ADTÂ06 - Outpatient to inpatient

ADTÂ07 - Inpatient to outpatient

ADTÂ08 - Update patient information

ADTÂ09 - Patient departing

ADTÂ10 - Patient arriving

ADTÂ11 - Cancel admit

ADTÂ12 - Cancel transfer

ADTÂ13 - Cancel discharge

ADTÂ17 - Swap patients

ADTÂ18 - Merge patient information

ADTÂ23 - Delete patient record

ADTÂ28 - Add person information

ADTÂ31 - Update person information

ADTÂ32 - Cancel patient arriving

ADTÂ33 - Cancel patient departing

ADTÂ35 - Merge patient information: Account number only

ADTÂ38 - Cancel pre-admit

MSH-11 Processing ID 'P'

MSH-12 Version ID '2.3'

MSA Segment

Description Notes

MSA-1 Acknowledgement Code Status from HIS

MSA-2 Message Control ID ID taken from Message Control ID field (MSH-10) of incoming message.

MSA-3 Text Message

MSH Segment

Description Notes



ADTÂ40 - Merge person - internal ID

MDM^T02 - Original document notification and content.

MDM^T08 - Document edit notification and content

MDM^T10 - Document replacement notification and content

MDM^T11 - Document cancel notification

MFN^M02 - Master file - staff practitioner. Used to update the HeartSuite CVIS physician rolodex.

ORMÔ01 - New order (NW); Cancel order (CA); Order status notification (SC)

ORU^R01 - Result message. The interface can generate text documents from OBX-5 data in OBX segments that have OBX-2 ='FT' or 'TX'. This interface can also process structured data in CardioAccess ORU messages and ORU messages from Echo reporting systems that conform to the generic echo ORU interface specification in this document.

SIU^S12 - Notification of new appointment

SIU^S13 - Notification of appointment rescheduling

SIU^S14 - Notification of appointment modification

SIU^S15 - Notification of appointment cancellation

SIU^S17 - Notification of appointment deletion

SIU^S20 - Notification of cancellation of service/resource on appointment

SIU^S26 - Notification that patient did not show up for appointment

If possible, the HIS or interface engine should filter out HL7 message types not listed above in order to minimize the number of messages the HeartSuite CVIS HL7 Inbound Server has to receive, process, and ultimately discard because the message was an unsupported message type.

Supported message segments for each of these message types are listed in Inbound - Supported Message Grammars on page 5. Details of each message type and associated segments can be found in Inbound - Supported HL7 Segments and Fields on page 19.

3.2. Inbound - Supported Message Grammars

The standard HeartSuite CVIS HL7 Inbound Server will handle reception of the following HL7 messages and segments. Please note that only the segments listed in bold are utilized by HeartSuite CVIS. Italicized segments may be included in messages sent to HeartSuite CVIS, but the data in them will be ignored during message processing.

NOTES:

1. Segments listed in bold must exist for the supported message type.

2. Segments listed in normal face text are optional, but if present, the data will be processed and saved in HeartSuite CVIS.

3. Data in segments listed in italics are optional. If they are present, the data will be ignored.

Message Type

Event Types Supported Grammar

ADT A01, A02, A03, A04, A05, A06, A07, A08, A09, A10, A11, A12, A13, Â28, A31, A32, A33, A38

MSH EVN PID [PD1] [MRG] [{NK1}] PV1 PV2 [{DB1}] [{OBX}] [{AL1}] [{DG1}] [DRG] [{PR1}] [{ROL}] [{GT1}] [{IN1}] [{IN2}] [{IN3}] [ACC] [UB1] [UB2]

ADT A17 MSH EVN PID [PD1] PV1 [PV2] [{DB1}] [{OBX}] PID [PD1] PV1 [PV2] [{DB1}] [{OBX}]

ADT A23 MSH EVN PID [PD1] PV1 [PV2] [{DB1}] [{OBX}]

ADT A35 MSH EVN PID [PD1] MRG



3.3. Outbound - Supported Message Types

The standard HeartSuite CVIS HL7 Outbound Server supports the following HL7 messages:

MDM^T02 - Report

ORM^O01 - New order (NW); Cancel order (CA)

ORU^R01 - Report

Supported message segments are listed in Outbound - Supported Message Grammars on page 6. Details of each message type and associated segments are addressed below in Outbound - Supported HL7 Segments and Fields on page 44.

3.4. Outbound - Supported Message Grammars

The standard HeartSuite CVIS HL7 Outbound Server will send the following HL7 messages and segments. Please note that the segments listed in bold are sent by HeartSuite CVIS.

MDM T02, T08, T10, T11 MSH [EVN] [PID] [PV1[ [TXA] [{OBX}]

MFN M02 MSH MFI MFE STF PRA

ORM O01 MSH [{NTE}] PID [PD1] [{NTE}] [PV1] [PV2] [IN1] [IN2] [IN3] [GT1] [{AL1}] ORC [OBR] [{NTE}] [{DG1}] [{OBX}] [{NTE}]

ORU R01 MSH PID [PV1] OBR {OBX}

SIU S12, S13, S14, S15, S17, S20, S26 MSH SCH [{NTE}] PID [PV1] [RGS] AIS AIL [AIP]

Message Type


MDM T02 MSH EVN PID PV1 TXA {OBX}

ORM O01 ('new order' and 'cancel order') MSH PID PV1 ORC OBR

ORU R01 MSH PID PV1 OBR {OBX} [DSC]

Message Type




4. Data Requirements

4.1. Inbound - ADT and SIU Message Filtering and Patient Classification

The HIS must provide data in ADT and SIU HL7 messages to allow HeartSuite CVIS to classify a patient visit into one of the following four categories.

1. Cardiology inpatients. These visits will appear on the Visit Details and Inpatient Census screens. The HeartSuite CVIS HL7 Inbound Server will process the patient demographic, visit, contacts, and insurance data in these messages.

2. Non-cardiology inpatients. These visits do not appear on the Inpatient Census screen. They will appear on the Inpatient Consult selection screen. They are also visible on the patient's Visit Details page. The HeartSuite CVIS HL7 Inbound Server will process the patient demographic, visit, contacts, and insurance data in these messages.

3. Cardiology outpatients. These visits will appear on the Visit Details and the Outpatient Daily Schedule screens. The HeartSuite CVIS HL7 Inbound Server will process the patient demographic, visit, contacts, and insurance data in these messages.

4. Non-cardiology outpatients. Visit data for these outpatient visits are not saved in HeartSuite CVIS. The HeartSuite CVIS HL7 Inbound Server will only process the patient demographic data in these messages.

To distinguish ADT message outpatient visits from inpatient visits, the HeartSuite CVIS HL7 Inbound Server uses the data in PV1-2 Patient Class. The customer must provide the list of values sent in this field that are associated with inpatient and outpatient messages. For example, a site may send a value of 'I' to represent inpatients, and 'O' to represent outpatients. All SIU messages are assumed to represent outpatient visits.

To distinguish ADT message Cardiology inpatients from non-Cardiology inpatients, the HeartSuite CVIS HL7 Inbound Server uses data in PV1-10 Hospital Service. The customer must provide a list of values for this field that indicate that the message is for a Cardiology inpatient. The Cardiology PV1-10 values must be inserted into the HeartSuite CVIS cf_lov table using an lov_name column value of 'ADT_CRD_HOSP_SERV_CD'.

The HeartSuite CVIS HL7 Inbound Server uses ADT message data in PV1-39 Servicing Facility to distinguish Cardiology outpatients from non-Cardiology outpatients. The customer must provide a list of values for this field that can be used to indicate that the message is for a Cardiology outpatient visit. The Cardiology PV1-39 values must be inserted into the HeartSuite CVIS cf_lov table using an lov_name column value of 'ADT_CARD_CLINIC_CODE'.

In SIU messages, AIS-3.1 Universal Service ID is used to identify cardiology outpatient visits. The customer must provide a list of values for this field that are associated with cardiology outpatient visits. The Cardiology Universal Service ID AIS-3.1 values must be inserted into the HeartSuite CVIS cf_univ_serv table. This table is used to map Universal Service IDs to a corresponding HeartSuite CVIS event type.

4.2. Inbound - MFN Physician Rolodex Update Processing

The HeartSuite CVIS HL7 Inbound Server uses MFN^M02 messages to update data in the HeartSuite CVIS physician rolodex. The interface only supports a single physician master file record per MFN message. Even though the HL7 standard allows for multiple physician records in repeating MFE segments, the HeartSuite CVIS HL7 Inbound Server does not support this. Only one physician rolodex record will be updated or added per MFN message.

MFN messages sent to the interface must contain the entire physician record, not only the field(s) being updated. This is necessary because the fields have no unique identifiers, so the interface cannot be sure which field(s) to update. For example, the Phone (STF-10) element allows for repeats, but does not require the sending application to include a unique identifier for each repeated element. If a physician has four associated phone numbers, but the MFN message only contains one, the interface does not know which phone record in the HeartSuite CVIS database to update. Thus, all four phone numbers must be included in the message, even though only one has changed.

The MFN interface business logic uses the physician ID number in STF-2 to uniquely identify physicians in the HeartSuite CVIS physician rolodex record. The value sent in the field must be the same value that is used to identify physicians in ADT, MDM, ORM, ORU and SIU messages.

The MFN interface must be configured with the MFN field values that can be used to identify a physician as a member of the HeartSuite CVIS staff physician group. STF-8.2 (Department) and PRA-2.2 (Practitioner group) are used for this identification. The STF-8.2 values associated with the staff role are inserted into the cf_lov MFN_CARD_STAFF_INST and MFN_CARD_STAFF_SPEC lov_name records respectively. The interface supports repeats of the STF-8 field. The department values associated with the staff role can appear in any STF-8 repeat position, and will be saved as the department to which the physician belongs. The physician rolodex only allows a physician to belong to a single department. If the physician belongs to multiple hospital departments, and one of them is not a staff role department, the interface will save the first instance



of STF-8 as the physician's department. If one of the departments is a staff role department, then the interface will save that one as the physician's department.

Other limitations of the MFN interface are:

• The MFI segment specifies one of two file-level events: UPD (update) and REP (replace) in MFI-3. The HeartSuite CVIS HL7 Inbound Server only supports the UPD event.

• The MFE segment specifies one of five record-level events: MAD (add), MUP (update), MDC (deactivate), MAC (activate), and MDL (delete) in MFE-1. The HeartSuite CVIS HL7 Inbound Server only supports the MAD and MUP event types.

• Up to eight phone numbers in repeats of the STF-10 fields are supported (the HeartSuite CVIS database will only store eight phone numbers per physician). Extra repeats will be ignored. STF-10.3 is used to identify the telecommunication equipment type. Supported types are 'PH' (office telephone), 'FX' (fax), 'CP' (cell phone), and 'BP' (beeper).

• Repeats of STF-11 (Address) are not supported. The HeartSuite CVIS physician rolodex only supports one address per physician.

Acknowledgement of MFN messages will be in the form of an ACK (general acknowledgement) message, with an acknowledgement code of AA. The MFK (Master File Acknowledgement) acknowledgement message is not supported.

An example of a supported MFN^M02 message is included in Sample MFN^M02 Message from HIS on page 67.

4.3. Inbound - MDM Medical Document Management Processing

Medical Document Management (MDM) messages are used to transmit new or updated documents through an HL7 interface. They can also be used to transmit information on the status of a document. They are mainly used for documents that are created from a transcription process. The HeartSuite CVIS HL7 Inbound Server will support the processing of documents sent in a single MDM message. Documents sent in multiple MDM messages using the HL7 DSC continuation segment will not be supported. Information describing the document is sent in a TXA segment. Document content is sent in OBX observation segments.

The main purpose of the MDM message is to create and update document text files in the HeartSuite CVIS document repository. In order to add these documents to HeartSuite CVIS, the HeartSuite CVIS HL7 Inbound Server will use message data to associate the documents with HeartSuite CVIS patient, visit, and event records. If an existing record does not exist, the message data will be used to create new patient and event records. Matching event records will be updated. Matching patient records will not be updated. New events will be created as child records of the patient's HeartSuite CVIS dummy visit.

A new text file and the associated HeartSuite CVIS document management database record will be created for each T02, T08, and T10 MDM message received by the interface. Edited documents sent in T08 and T10 messages will replace the previous version of the document in the HeartSuite CVIS document repository. Old versions of the document are not retained. A T11 message will result in the deletion of the associated document in HeartSuite CVIS document repository.



4.3.1. Text Report Data Handling

The MDM Interface will support the processing of ASCII text documents sent in multiple OBX segments. Each segment must contain one line of text in OBX-5.1. An end-of-line character must not be included at the end of the OBX-5.1 field. The HeartSuite CVIS HL7 Inbound Server will add a new line character to the end of the text in each field when reconstructing the text document. Only text in OBX segments that have OBX-2 = 'TX' or 'FT' will be used to create the text document.

The following example illustrates how the contents of an MDM message's OBX-5.1 fields will be processed to create an ASCII text document:

MDM message flatwire:

MSH|…PID|…PV1|…TXA|…OBX|…|TX|…|…|Clinic Report|OBX|…|TX|…|…|September 17, 2005|OBX|…|TX|…|…||OBX|…|TX|…|…|12345678901234567890123456789012345678901234567890123456789012345678901234567890|

Generated ASCII text document:

Clinic Report<nl>September 17, 2005<nl><nl>12345678901234567890123456789012345678901234567890123456789012345678901234567890<nl>

NOTE: <nl> represents the position of the ASCII new line character

4.3.2. Message Filtering

HeartSuite CVIS HL7 Inbound Server will only process messages for cardiology visits. Since the MDM sending system may send HL7 messages for non-cardiology hospital visits also, the HeartSuite CVIS HL7 Inbound Server can be configured so that it will only process messages that have an OBX-3.1 value that is in a configurable list of cardiology OBX-3.1 observation identifiers.

4.4. Inbound - ORM Order Processing

The HeartSuite CVIS HL7 Inbound Server is capable of processing new order (ORC-1='NW'), cancel order (ORC-1='CA'), and order status change (ORC-1='SC') ORM messages. The data in these messages will be used to create and modify HeartSuite CVIS Orders. The HeartSuite CVIS HL7 Inbound Server only supports one order per ORM message. If a message contains more than one order (i.e. messages that contain multiple ORC segments), only the first order will be processed.

Users can schedule the orders received through the HeartSuite CVIS HL7 Inbound Server to create patient events in HeartSuite CVIS. Additionally, if enabled, the HeartSuite CVIS HL7 Outbound Server will send the scheduled order (i.e. Event) to interested systems.

4.5. Inbound - ORU Clinical Results Processing

The HeartSuite CVIS HL7 Inbound Server supports the processing of ORU clinic results. The data in the message will be used to update or create HeartSuite CVIS Events. Text reports sent in OBX-5.1 in OBX segments that have OBX-2 = 'FT' pr 'TX' will be used to create text reports in the HeartSuite CVIS document repository. The interface also supports the processing of structured surgery and cath data sent in CardioAccess ORU messages. It can also process echo structured data in ORU messages that conform to the generic Echo ORU interface specification described later in this document. Encoded binary file data and file pointers are not supported.

The HeartSuite CVIS HL7 Inbound Server will only process ORU messages for completed procedures. The Inbound HL7 Server will queue ORU messages for uncompleted and completed procedures, but the HeartSuite CVIS HL7 business logic will only process them if the date in OBR-7 (Observation date/time) is less than or equal to the current date.

The HeartSuite CVIS HL7 Inbound business logic that is used to process ORU messages requires data in the MSH, PID, and OBR segments in order to successfully process the event data in the message. MSH-3 (sending system) must contain a value used to identify the system sending the ORU messages. Implementers must use this value to manually create a cf_app_systems table record. This table is used to map MSH-3 values to the HeartSuite CVIS MRN type values that are needed when creating a HeartSuite CVIS 'temporary' Patient record from ORU message



data. Temporary Patient records are only created if a matching ADT Patient record cannot be found. Patient MRN in PID-3 and patient name in PID-5 are used to identify existing patient records in HeartSuite CVIS. If a match cannot be made, the MRN, name, and the MRN type that is mapped to the MSH-3 value are used to create a HeartSuite CVIS 'temporary' Patient record. The Universal Service ID in OBR-4.1 is used to map the clinical result procedure type to a HeartSuite event type. OBR-4.1 values and their mapping to a HeartSuite CVIS event type must be added to the cf_univ_serv table during implementation. If HeartSuite CVIS is sending order ORM messages to the ORU sending system, the ORU message should contain a HeartSuite CVIS event_id in OBR-2. This value is used to search for a matching event in HeartSuite CVIS. If this search fails, the value in OBR-3 is used to find a matching external_id value in the HeartSuite CVIS Event database table. If this search fails, then the date in OBR-6 (primary) or OBR-7 (if no value in OBR-6) is used to find an Event with the same planned start date value and has the same modality. The modality is determined by taking the OBR-4.1 universal service ID value, mapping it to a HeartSuite CVIS event type, and then checking which HL7 modality event type group it belongs to. If an event cannot be found, the interface will create a new event. The event will be created against a HeartSuite CVIS Visit that has an account_num value that matches the value in PID-18. If a matching visit cannot be found, the new event will be associated with the patient's 'dummy' visit. Complete HL7 data requirements for HeartSuite CVIS ORU message interfaces can be found in ORU^R01 Message on page 17 and ORU^R01 Message on page 36.

After identifying the HeartSuite CVIS Patient, Visit, and Event with which to associate the ORU message data, the HeartSuite CVIS HL7 Inbound Server will process the data in the message's OBX segments. The interface will process OBX segments containing text report documents and structured data from CardioAccess and compatible echo reporting systems.

4.5.1. OBX Segment Text Report Processing

The HeartSuite CVIS HL7 Inbound Server can extract text reports contained in an ORU message's OBX segments to create a text report document in the HeartSuite CVIS document repository. The document will be associated with the HeartSuite CVIS Patient and Event identified during the processing of the message's PID and OBR segment data. The text used to create the documents must be located in OBX segments with OBX-2 (Value type) equal to 'TX' or 'FT'. The text data used to create the document must be located in OBX-5.1 (Observation value). The text may be in multiple OBX segments or in a single OBX segment. If multiple OBX segments are used, each line of text must be in its own OBX segment and must not include the end of line character. If the report is contained in a single OBX segment, the text must include the end of line characters (.br). There is no limitation to the size of text report documents. However, the maximum data length is 4000 characters per OBX-5 field.

Reports must be sent in a single ORU message because the HeartSuite CVIS HL7 Inbound Server does not support the HL7 DSC continuation segment. The ordering of the OBX segments is important for unstructured text data. The interface will reconstruct the text document in the order that the OBX-5 fields appear in the message. Repeating fields in OBX-5 are not supported.

The following example illustrates how OBX segment 'TX' data is used to create a text document:

ORU Message:

MSH|…PID|…PV1|…OBR|…OBX|1|TX|…|…|EchoIMS Echo Report|OBX|2|TX|…|…|September 17, 2004|OBX|3|TX|…|…||OBX|4|TX|…|…|12345678901234567890123456789012345678901234567890123456789012345678901234567890|

Generated text report document:

EchoIMS Echo Report<CR>September 17, 2004<CR><CR>12345678901234567890123456789012345678901234567890123456789012345678901234567890<CR>

NOTE: <CR> represents the position of a line break character

If an ORU message contains OBX segments with OBX-2 equal to 'TX' or 'FT', but the text in OBX-5 is not suitable to create a text document, then these OBX segments should not be sent in the message. Alternatively, changing OBX-2 to a value other than 'FT' or 'TX' will also suppress the generation of text documents from OBX segment data.



4.5.2. CardioAccess OBX Segment Structured Data Handling

The HeartSuite CVIS HL7 Inbound Server supports processing of OBX segment structured data in ORU^R01 messages from the CardioAccess surgical results application. The CardioAccess OBX segment data is used to populate the HeartSuite CVIS application database with patient surgery and cath procedure results data. The list of OBX segment Observation Identifiers supported in this ORU interface implementation is shown in Table 1. An example of a CardioAccess ORU^R01 message is included in Sample Inbound Messages on page 67.

Table 1 Supported CardioAccess OBX-3 Observation Identifiers

OBX-3 Observation Identifier NotesMapping of OBX-5 Value to HeartSuite

CVIS Database Table Column

Additional Diagnosis and ICD-9 Cf_lov_diag.icd9_cd

Cf_lov_diag.diag_desc

Additional Procedures and CPT Cf_lov_proc.cpt_cd

Cf_lov_proc.proc_desc

Alias Name

Antenatal Diagnosis?(Y/N) Cf_surg_detls.antenatal_diag_flag

Aortic cross-clamp time Cf_surg_detls.aortic_cc_time

BSA BSA is a calculated field in HeartSuite CVIS

Case category Used to distinguish cath and surgery events Cf_surg_detls.case_category

Cf_cath_detls.case_category

CaseNumber The unique identifier of the event in CardioAccess

Cf_surg_detls.surg_no

Cf_cath_detls.cath_no

Circulatory arrest time Cf_surg_detls.surg_arrest_time

Clinical note Cf_surg_detls.clinical_note

Complication and Complication Code Cf_lov_diag.icd9_cd


CPB time Cf_surg_detls.cpb_time

Date of Event Only used if Event Start is missing Cf_event.plan_start_date

Event End Cf_events.act_end_date

Event Start Cf_events.act_start_date

Cf_Events.plan_start_date

Fluoro Dose Cf_cath_detls.fluro_dose

Fluoro Time Cf_cath_detls.fluro_time

General Preoperative Risk Factors Cf_surg_risk_factors.risk_factor

Height Cf_patient_vitals.height

Mortality assigned to this operation Cf_surg_detls.mortality_assigned_flag



Non-cardiac Abnormalities Cf_surg_abnormalities.abnormality

Number of prior open Cardiothoracic Operations

Cf_surg_detls.prior_octo_num

Number of prior total Cardiothoracic Operations

Cf_surg_detls.prior_cto_num

Operative Mortality(Y/N) Cf_surg_detls.op_mortality_flag

Cf_cath_detls.op_mortality_flag

Postoperative note Cf_surg_detls.postop_note

Preoperative note Cf_surg_detls.preop_note

Primary Diagnosis and ICD-9 Cf_lov_diag.icd9_cd


Primary Procedure and CPT Cf_lov_proc.cpt_cd


Procedure note Cf_surg_detls.procedure_note

Pump used(Y/N) Cf_surg_detls.pump_flag

Re-operation after this operation in this admission?

Cf_surg_detls.planned_reop_flag

Re-operation during this admission? Cf_surg_detls.reop_flag

Surgeon Cf_lov_phys

Surgery Location

TEE(Y/N) Cf_surg_detls.tee_flag

Cf_cath_detls.tee_flag

Time surgery commenced Cf_cath_detls.strt_time

Time surgery completed Cf_cath_detls.end_time

Weight Cf_patient_vitals.weight

Table 1 Supported CardioAccess OBX-3 Observation Identifiers (Continued)

OBX-3 Observation Identifier NotesMapping of OBX-5 Value to HeartSuite




4.5.3. Echo OBX Segment Structured Data Handling

The HeartSuite CVIS HL7 Inbound Server can process OBX segment structured data from echo reporting systems if the data labels in OBX-3 conform to the specification defined in the tables below. The data will be used to populate the HeartSuite CVIS echo details, procedure, diagnosis, and patient vitals application database tables. Data elements are identified by OBX-3 Observation identifiers. Data values must be located in OBX-5 (Observation value), and must be less than 4000 characters long. The ordering of the OBX segments is not important. OBX segments that contain unsupported OBX-3 Observation identifiers will be ignored by the interface.

Table 2 Supported Echo OBX-3 Observation Identifiers

OBX-3 Observation Identifier OBX-5 Data FormatMapping of OBX-5 Value to HeartSuite


Primary Diagnosis ICD9 Code^Diagnosis Description Cf_lov_diag.icd9_cd


Referral Diagnosis ICD9 Code^Diagnosis Description Cf_lov_diag.icd9_cd


Cf_echo_detls.referral_diagnosis

Procedure 1 CPT Code^Procedure Description Cf_lov_proc.cpt_cd






Height Number (in cm) Cf_patient_vitals.height

Weight Number (in kg) Cf_patient_vitals.weight

Study Type Fetal, Pediatric, Adult, Stress, or Sedated Cf_echo_detls.echo_study_type_id

Gestational Age Number (in weeks) Cf_echo_detls.gestational_age

Due Date YYYYMMDD Cf_echo_detls.due_date



4.6. Inbound - HL7 Fields Required by the HeartSuite CVIS Application

This section describes the other HL7 data that the HeartSuite CVIS application requires. It does not list the MSH segment fields that are required by the interface engine. MSH segment requirements can be found in Inbound - Supported HL7 Segments and Fields on page 19.

4.6.1. ADT Messages (excluding A17, A23, and A35)

HL7 Field Name

HeartSuite CVIS Data Description Notes

MSH-3 HL7 sending system Use this value to create a cf_app_systems record that has its hl7_sending_app_name column set to this value. This record should have its mrn_type set to the HeartSuite CVIS hospital MRN type.

EVN-3 Visit planned start date, Event planned start date

Must include a time component.

Format: YYYYMMDDHHMM

PV1-44 will be used if there is no value in this field.

PID-3 Patient MRN Used to identify a patient in HeartSuite CVIS. Leading zeros are significant.

PID-5.1 Patient last name

PID5.2 Patient first name

PID-18 Visit Account Number Used to identify a patient visit in HeartSuite CVIS.

PV1-2 Patient class (for visit), Event type The site must provide a list of all possible values and the associated descriptions for this field. The list will be used to populate the CF_LOV_EVENT_TYPE lookup table.

PV1-3 Visit location PV2-23 will be used if there is no value in this field.

PV1-10 Hospital service code This field and PV1-39 are used to identify Cardiology messages. See Inbound - ADT and SIU Message Filtering and Patient Classification on page 7 for details. The site must provide a list of the codes that identify Cardiology related visits.

PV1-7.1 Visit Attending Physician The site must provide a list of the Cardiology department physicians that includes the values that will be sent in PV1-7.1, 7.2, 7.3, and 7.4. This value may be used to determine if a message should be processed by the HeartSuite CVIS HL7 Inbound Server.

PV1-18 Visit type The site must provide a list of all the possible values and the associated code descriptions. This list is used to populate the CF_LOV_VISIT_TYPE lookup table.

PV1-39 Servicing facility Required for outpatient visit messages. This field and PV1-10 are used to identify outpatient Cardiology messages. See Inbound - ADT and SIU Message Filtering and Patient Classification on page 7 for details. The site must provide a list of the codes that identify Cardiology related visits.

PV2-3 Reason for visit



4.6.2. ADTÂ17 (Swap patients)

4.6.3. ADTÂ23 (Delete a patient record)

4.6.4. ADTÂ35 (Account number merge)

PV2-23 Event location

PV2-24 Visit status, Event status The site must provide a list of all the possible values for this field and the associated descriptions. The list is used to populate the CF_LOV_EVENT_STATUS and CF_LOV_VISIT_STATUS lookup tables. The values sent in SIU SCH-25.1 are also used to populate these lookup tables.

HL7 Field Name





PV1-3 Visit location

HL7 Field Name





HL7 Field Name





MRG-3 Prior Visit Account Number The unique identifier for a patient visit in HeartSuite CVIS. This is the visit that will be deleted. Its events will be moved to the visit identified by PID-18.

HL7 Field Name




4.6.5. MDM Message

4.6.6. MFN^M02 Message

HL7 Field Name


MSH-3 HL7 sending application During implementation, the cf_app_systems table must be configured to include a record corresponding to the value sent in this field (the MSH-3 value is put in the hl7_sending_app_name column). The mrn_type should be set to the desired value for temporary patient records created during the processing of the sending system's MDM messages.

PID-3 Patient MRN Used to identify a patient in HeartSuite CVIS. Leading zeros are significant. Messages with non-numeric MRNs will not be processed.


PID-5.2 Patient first name

TXA-4 Activity date/time This is not the document signature date/time.

TXA-12 Unique document number

TXA-13 Parent document number Identifies the previous version of the document. TXA-12 will be uses if TXA-13 is not present in the message.

OBX-2 Value type

OBX-3 Observation identifier Used to identify the document as one that should be processed by HeartSuite CVIS.

OBX-5 Observation data Document text.

HL7 Field Name


MSH-3 HL7 sending system Use this value to create a cf_app_systems record that has its hl7_sending_app_name column set to this value.

MFI-1 Master file identifier Identifies type of master file: ‘PRA’ or ‘STF’.

MFI-3 File-level event code Only ‘UPD’ is supported.

MFI-6 Response level code Only ‘AL’ is supported.

MFE-1 Record-level event code Only ‘MAD’ (add record to master file) and ‘MUP’ (update record in master file) are supported.

MFE-4 Primary key value - MFE Uniquely identifies the record of the master file to be changed (as defined by the record-level event code).

STF-1 Primary key value - STF Must match the MFE-4 primary key value.

STF-2 Physician ID Number (idx_id_num) Used to uniquely identify a physician in HeartSuite CVIS

STF-3.1 Physician last name

STF-3.2 Physician first name



4.6.7. ORM Message

4.6.8. ORU^R01 Message

STF-8.2 Department STF-8.2 and PRA-2.2 are used to determine if the physician is a member of the HeartSuite CVIS staff physician group.

PRA-1 Primary key value - PRA Must match the MFE-4 primary key value.

PRA-2.2 Institution code STF-8.2 and PRA-2.2 are used to determine if the physician is a member of the HeartSuite CVIS staff physician group.

HL7 Field Name


MSH-3 HL7 sending application During implementation, the cf_app_systems table must be configured to include a record corresponding to the value sent in this field (the MSH-3 value is put in the hl7_sending_app_name column). The mrn_type should be set to the desired value for temporary patient records created during the processing of the sending system's ORM messages.





ORC-1 Order control NW, CA, and SC are supported.

ORC-2 Placer Order Number This field and MSH-3 are used to uniquely identify an order in HeartSuite CVIS. May also be sent in OBR-2.

OBR-4 Universal service ID Used to map the procedure to a HeartSuite CVIS Event type when users schedule an event based on the order.

HL7 Field Name


MSH-3 HL7 sending application During implementation, the cf_app_systems table must be configured to include a record corresponding to the value sent in this field (the MSH-3 value is put in the hl7_sending_app_name column). The mrn_type should be set to the desired value for temporary patient records created during the processing of the sending system's ORU messages.



PID5.2 Patient first name

OBR-3 Order filler number Used to identify an event in HeartSuite CVIS

HL7 Field Name




4.6.9. SIU Messages

OBR-4.1 Universal Service ID The site must provide a list of all the possible Cardiology department values for this field and how they should map to HeartSuite CVIS event types. The list is used to populate the cf_univ_serv table.

Messages that include values that are not in this list will not be processed by the HeartSuite CVIS HL7 Inbound Server. See Inbound - ADT and SIU Message Filtering and Patient Classification on page 7 for details.

OBR-7 or OBR-6

Observation date/time The date and time the procedure was performed. If there is no value in OBR-7, then the value in OBR-6 will be used.

OBR-25 Status/Correction Flag This field is only required for messages containing text reports (OBX-2='TX'). 'F' is used in the initial (not amended) report. If the message is for an amended report, then this field will have value of 'C',

OBX-2 Value type Only 'ST' (for structured data) and 'TX' (for text reports) value types are supported.

OBX 3 Observation identifier This is a unique identifier of the structured data. Only required if OBX-2 value type is 'ST'

OBX-5 Observation value Structured data value or report text.

HL7 Field Name


MSH-3 HL7 sending application During implementation, the cf_app_systems table must be configured to include a record corresponding to the value sent in this field (the MSH-3 value is put in the hl7_sending_app_name column). The mrn_type should be set to the desired value for patient records created during the processing of the sending system's SIU messages.

SCH-1.1 Placer appointment ID - entity identifier Unique identifier for a patient visit.

SCH-7.1 Reason for visit

SCH-11.4 Visit planned start date, Event planned start date



AIS-4 will be used if there is no value in this field.

SCH-25.1 Visit status, Event status The site must provide a list of all the possible values for this field and the associated descriptions. The list is used to populate the CF_LOV_EVENT_STATUS and CF_LOV_VISIT_STATUS lookup tables. The values sent in ADT PV2-24 are also used to populate these lookup tables.

PID-3 Patient MRN The unique identifier for a patient in HeartSuite CVIS. Leading zeros are significant.



HL7 Field Name




4.7. Inbound - Supported HL7 Segments and Fields

The HeartSuite CVIS HL7 Inbound Server will accept, parse, and process the (MLLP based) HL7 messages defined in the following tables. IMPORTANT NOTES REGARDING THE TABLES:

1. Bold face text indicates the field data must exist. Otherwise, the message is not processed.

2. Normal face text indicates the fields are optional in the HeartSuite CVIS HL7 Inbound Server.

3. Fields not listed in the following tables are ignored.

4. If data can be stored in the HeartSuite CVIS database, the table and field are noted in the last column.

5. Only the data for the first physician in optionally repeating physician HL7 fields will be saved in HeartSuite CVIS. For example, a PV1 segment could list three attending physicians in PV1-7, but only the first one will be saved in HeartSuite CVIS.

6. When fields that have been previously populated are subsequently designated to have NULL values, two double quotation marks (HL7's 'present but null' indicator) are required to exist in the field. If the double quotation marks are not provided in the HL7 messages, the data will not be removed from the system.

4.7.1. ADT Messages


AIS-3 Event type The site must provide a list of all the possible Cardiology department values for this field and how they should map to HeartSuite CVIS event types. The list is used to populate the cf_univ_serv table.

Messages that include values that are not in this list will not be processed by the HeartSuite CVIS HL7 Inbound Server. See Inbound - ADT and SIU Message Filtering and Patient Classification on page 7 for details.

AIL-3 Visit location, Event location

MSH Segment

Description NotesHeartSuite CVIS Database Table

Column

MSH-1 Field Separator '|' NA

MSH-2 Encoding Characters '^~\&' NA

MSH-3 Sending Application Cf_app_systems must contain a record that has a matching hl7_sending_app_name value.

NA

MSH-4 Sending Facility Identifier NA

MSH-5 Receiving Application NA

MSH-7 Date/Time of Message Current date/time.



Example: 200407271509

NA

HL7 Field Name




MSH-9 Message type See Inbound - Supported Message Types on page 4 for the list of supported ADT messaged types.

NA

MSH-10 Message control ID HIS generated; unique identifier. NA

MSH-11 Processing ID 'P' NA

MSH-12 Version ID '2.3' NA

EVN Segment


Column

EVN-1 Event Type Code

EVN-3 Date/Time Planned Event Must include a time component.


Example: 200407271509

The value in PV1-44 admit date will be used if a value is not present in EVN-3

CF_EVENTS: Plan_Start_Date

PID Segment Description NotesHeartSuite CVIS Database Table

Column

PID-1 Set ID Used to group each patient's PID and PV1 segments in an ADT^A17 Swap Patients message. The Set ID for the first patient should be '1', for the second patient, '2'. Required for ADT^A17 messages.

PID-3 Patient ID Used to identify a patient in HeartSuite CVIS. Leading zeros are significant.

CF_PATIENTS: MRN

PID-5.1 Patient Name - Last name CF_PATIENTS: Last_Name

PID-5.2 Patient Name - First name CF_PATIENTS: First_Name

PID-5.3 Patient Name - Middle name CF_PATIENTS: Middle_Name

PID-5.4 Patient Name - Suffix CF_PATIENTS: Name_Suffix

PID-7 Patient Date of Birth CF_PATIENTS: DOB

PID-8 Patient Sex CF_PATIENTS: Sex

PID-9.1 Patient Alias CF_PATIENTS: Previous_Name

PID-10 Race CF_PATIENTS: Race

PID-11.1 Patient Address - Street Address CF_PATIENTS: Addr1

MSH Segment


Column



PID-11.2 Patient Address - Other Designation CF_PATIENTS: Addr2

PID-11.3 City CF_PATIENTS: City

PID-11.4 Patient Address - State Or Province CF_PATIENTS: State_Prov

CF_PATIENTS:Cnty_Prsh_Cd

PID-11.5 Patient Address - Zip or Postal Code CF_PATIENTS: Zip_Post_Code

PID-11.6 Patient Address - Country CF_PATIENTS: Cntry_Code

PID-11.9 Patient Address - County Parish Code CF_PATIENTS:Cnty_Prsh_Cd

PID-13 Phone Number - Home CF_PATIENTS: Phn_Num_Home

PID-15 Primary Language CF_PATIENTS: Lang

PID-16 Marital Status CF_PATIENTS: Marital_Stat

PID-17 Religion CF_PATIENTS: Religion

PID-18 Patient Acct. Number Used to identify a patient visit in HeartSuite CVIS

CF_VISITS: Account_Num

PID-19 Social Security Number CF_PATIENTS: Patient_SSN

PID-29 Patient Death Date and Time CF_PATIENT_AUTOPSY: Deceased_Date

PID-30 Patient Death Indicator CF_PATIENTS: Patient_Status

NK1 Segment


Column

NK1-1 Next of Kin Set ID HeartSuite CVIS NK Contact type CF_CONTACTS: Contact_Type_Seq

NK1-2.1 Next of Kin Name - Family Name CF_CONTACTS: Last_Name

NK1-2.2 Next of Kin Name - Given Name CF_CONTACTS: First_Name

NK1-2.3 Next of Kin Name - Middle Initial or Name CF_CONTACTS: Middle_Name

NK1-2.4 Next of Kin Name - Suffix CF_CONTACTS: Name_Suffix

NK1-2.6 Next of Kin Name - Degree CF_CONTACTS: Name_Degree

NK1-3 Next of Kin Relationship CF_CONTACTS: Relation_Type

NK1-4.1 Next of Kin Address - Street Address CF_CONTACTS: Addr1

NK1-4.2 Next of Kin Address - Other Designation CF_CONTACTS: Addr2

NK1-4.3 Next of Kin Address - City CF_CONTACTS: City

NK1-4.4 Next of Kin Address - State or Province CF_CONTACTS: State_Prov


Column



NK1-4.5 Next of Kin Address - Zip or Postal Code CF_CONTACTS: Zip_Post_Cd

NK1-4.6 Next of Kin Address - Country CF_CONTACTS: Cntry_Cd

NK1-4.9 Next of Kin Address -County/Parish Code CF_CONTACTS: Cnty_Prsh_Cd

NK1-5 Next of Kin Phone Number CF_CONTACTS: Phn_Num_Home

NK1-6 Next of Kin Business Phone Number CF_CONTACTS: Phn_Num_Bus

NK1-7 Next of Kin Contact Role

NK1-10 Next of Kin / Associated Parties Job Title CF_CONTACTS: Job_Title

NK1-13.1 Next of Kin Organization Name CF_CONTACTS: Employer_Name

NK1-15 Next of Kin Sex CF_CONTACTS: Sex

NK1-16 Next of Kin Date/Time Of Birth CF_CONTACTS: DOB

NK1-37 Contact Person Social Security Number CF_CONTACTS: SSN

PV1 Segment Description NotesHeartSuite CVIS Database Table

Column

PV1-1 Set ID Used to group each patient's PID and PV1 segments in an ADT^A17 Swap Patients message. The Set ID for the first patient should be '1', for the second patient, '2'. Required for ADT^A17 messages.

PV1-2 Patient Class The site must provide a list of all possible values and the associated descriptions for this field.

CF_VISITS: Patient_Class

CF_EVENTS: Patient_Class

CF_EVENTS: Event_Type_ID

PV1-3.1 POC/Nursing Unit HeartSuite CVIS Visit Location.

The value in PV2-23.1 will be used if no value is specified for this field.

The site must provide a list of all the possible values for this field and PV1-23.1 , along with the associated descriptions. The list is used to populate the CF_LOV_LOCNS lookup table.

CF_LOV_LOCN: locn_cd

CF_LOV_LOCN: locn_desc

CF_VISITS: Locn_PtOfCare

PV1-3.2 Room CF_VISITS: Locn_Room

PV1-3.3 Bed CF_VISITS: Locn_Bed

NK1 Segment


Column



PV1-7.1 Attending Doctor ID HeartSuite CVIS Visit attending physician.

The site must provide a list of Cardiology department physicians that includes the values that will be sent in PV1-7.1, 7.2, 7.3, and 7.4.

This value may be used to determine if a message should be processed by the HeartSuite CVIS HL7 Inbound Server.

CF_LOV_PHYS: Idx_Id_Num

May be used to determine CF_VISITS: Car_Vis_Flag

PV1-7.2 Attending Doctor Last Name CF_LOV_PHYS: Last_Name

PV1-7.3 Attending Doctor First Name CF_LOV_PHYS: First_Name

PV1-7.4 Attending Doctor Middle Name CF_LOV_PHYS: Middle_Name

PV1-8.1 Referring Doctor ID HeartSuite CVIS Visit referring physician


PV1-8.2 Referring Doctor Last Name CF_LOV_PHYS: Last_Name

PV1-8.3 Referring Doctor First Name CF_LOV_PHYS: First_Name

PV1-8.4 Referring Doctor Middle Name CF_LOV_PHYS: Middle_Name

PV1-9.1 Consulting Doctor ID HeartSuite CVIS Visit consulting physician


PV1-9.2 Consulting Doctor Last Name CF_LOV_PHYS: Last_Name

PV1-9.3 Consulting Doctor First Name CF_LOV_PHYS: First_Name

PV1-9.4 Consulting Doctor Middle Name CF_LOV_PHYS: Middle_Name

PV1-10 Hospital Service This field is used to identify inpatient Cardiology messages. The site must provide a list of the codes that identify inpatient Cardiology related visits.

CF_VISITS: Hosp_Service

Used to determine

CF_PATIENTS: Car_Pt_Flag,and

CF_VISITS: Car_Vis_Flag

PV1-17.1 Admitting Doctor ID HeartSuite CVIS Visit admitting physician


PV1-17.2 Admitting Doctor Last Name CF_LOV_PHYS: Last_Name

PV1-17.3 Admitting Doctor First Name CF_LOV_PHYS: First_Name

PV1-17.4 Admitting Doctor Middle Name CF_LOV_PHYS: Middle_Name

PV1-20.1 Financial Class CF_VISITS: Fin_Class


Column



PV1-18 Patient Type The site must provide a list of all the possible values and the associated code descriptions. This list is used to populate the CF_LOV_VISIT_TYPE lookup table.

CF_VISITS: Visit_Type_ID

PV1-19 Visit Number

PV1-39 Servicing Facility Required for outpatient visit messages. This field is used to identify outpatient Cardiology messages. The site must provide a list of the codes that identify outpatient Cardiology related visits.

Used to calculate

CF_VISITS: Car_Vis_Flag

PV1-41 Account Status

PV1- 44 Admit Date/Time Must include a time component.


Example: 200407271509

Required only if EVN-3 (Date/time planned event) is not specified.

CF_VISITS: Plan_Start_Date

CF_VISITS: Act_Start_Date


CF_EVENTS: Act_Start_Date

PV1-45 Discharge Date/Time CF_VISITS: Act_End_Date

CF_EVENTS: Act_End_Date


Column

PV2-3 Admit Reason CF_VISITS: Reas_For_Visit

CF_EVENTS: Reas_For_Event -


Column



PV2-23.1 Clinic Organization Name - Organization Name

HeartSuite CVIS Event Location and HeartSuite CVIS Visit Location.

This is used if there is no value in PV1-3.1.

The site must provide a list of all the possible values for this field and PV1-3.1, along with the associated descriptions. The list is used to populate the CF_LOV_LOCN lookup table.



PV2-24 Patient Status Code The site must provide a list of all the possible values for this field and the associated descriptions. The list is used to populate the CF_LOV_EVENT_STATUS and CF_LOV_VISIT_STATUS lookup tables. The values sent in SIU SCH-25.1 are also used to populate these lookup tables.

CF_EVENTS: event_status_id

CF_VISITS: visit_status_id

GT1 Segment


Column

GT1-3.1 Guarantor Name - Family Name HeartSuite CVIS GT Contact type CF_CONTACTS: Last_Name

GT1-3.2 Guarantor Name - Given Name CF_CONTACTS: First_Name

GT1-3.3 Guarantor Name - Middle Initial or Name CF_CONTACTS: Middle_Name

GT1-3.4 Guarantor Name - Suffix CF_CONTACTS: Name_Suffix

GT1-3.6 Guarantor Name - Degree CF_CONTACTS: Name_Degree

GT1-5.1 Guarantor Address - Street Address CF_CONTACTS: Addr1

GT1-5.2 Guarantor Address - Other Designation CF_CONTACTS: Addr2

GT1-5.3 Guarantor Address - City CF_CONTACTS: City

GT1-5.4 Guarantor Address - State or Province CF_CONTACTS: State_Prov

GT1-5.5 Guarantor Address - Zip or Postal Code CF_CONTACTS: Zip_Post_Cd

GT1-5.6 Guarantor Address - Country CF_CONTACTS: Cntry_Cd

GT1-5.9 Guarantor Address -County/Parish Code CF_CONTACTS: Cnty_Prsh_Cd

GT1-6 Guarantor Ph Num-Home CF_CONTACTS: Phn_Num_Home

GT1-7 Guarantor Ph Num-Business CF_CONTACTS: Phn_Num_Bus

GT1-8 Guarantor Date/Time Of Birth CF_CONTACTS: DOB


Column



GT1-9 Guarantor Sex CF_CONTACTS: Sex

GT1-11 Guarantor Relationship CF_CONTACTS: Relation_Type

GT1-12 Guarantor SSN CF_CONTACTS: SSN

GT1-16.1 Guarantor Employer Name - Family Name CF_CONTACTS: Employer_Name

GT1-18 Guarantor Employer Phone Number CF_CONTACTS: Employer_Phn_Num

GT1-36 Guarantor Primary Language CF_CONTACTS: Lang

GT1-49 Guarantor Job Title CF_CONTACTS: Job_Title

IN1 Segment Description NotesHeartSuite CVIS Database Table

Column

IN1-1 Insurance Company Set ID Used to group the IN1 and IN2 segments

IN1-5.1 Insurance Company Address - Street Address

HeartSuite CVIS IN Contact type CF_CONTACTS: Addr1

IN1-5.2 Insurance Company Address - Other Designation

CF_CONTACTS: Addr2

IN1-5.3 Insurance Company Address - City CF_CONTACTS: City

IN1-5.4 Insurance Company Address - State or Province

CF_CONTACTS: State_Prov

IN1-5.5 Insurance Company Address - Zip or Postal Code

CF_CONTACTS: Zip_Post_Cd

IN1-5.6 Insurance Company Address - Country CF_CONTACTS: Cntry_Cd

IN1-5.9 Insurance Company Address -County/Parish Code

CF_CONTACTS: Cnty_Prsh_Cd

IN1-16.1 Name Of Insured - Family Name CF_CONTACTS: Last_Name

IN1-16.2 Name Of Insured - Given Name CF_CONTACTS: First_Name

IN1-16.3 Name Of Insured - Middle Initial or Name CF_CONTACTS: Middle_Name

IN1-16.4 Name Of Insured - Suffix CF_CONTACTS: Name_Suffix

IN1-16.6 Name Of Insured - Degree CF_CONTACTS: Name_Degree

IN1-17 Insured's Relationship To Patient CF_CONTACTS: Relation_Type

IN1-18 Insured's Date Of Birth CF_CONTACTS: DOB

IN1-22 Coord Of Ben. Priority CF_CONTACTS: Contact_Type_Seq

GT1 Segment


Column



4.7.2. MDM^T02, T08, T10, T11Message

IN2 Segment Description NotesHeartSuite CVIS Database Table

Column

IN2-1 Insured's Employee ID Used to group the IN1 and IN2 segments. The value in this field must be the same as the matching IN1 segment's IN1-1 (Set ID) field.

It must not contain an employee ID.

IN2-2 Insured's Social Security Number CF_CONTACTS: SSN

IN2-63 Insured's Phone Number - Home CF_CONTACTS: Phn_Num_Home

MRG Segment


Column

MRG-3 Prior Patient Account Number Identifies the HeartSuite CVIS visit that is to be merged into the visit identified by PID-18

Segment Field


Column

MSH-1 Field Separator '|' Not Applicable (n/a)



NA





NA

MSH-9 Message type MDM T02, T08, T10, and T11 are supported.

NA

MSH-10 Message control ID Unique message identifier. NA





Segment Field


Column

PID-3 Patient ID The unique external identifier for a patient in HeartSuite CVIS

CF_PATIENTS: MRN






PID-18 Patient Acct. Number The unique identifier for a patient visit. If it is not present, then the HeartSuite CVIS order will be created against the patient's HeartSuite CVIS dummy visit.


Segment Field


Column

TXA-2 Document type Dm_documents: trans_doc_type

TXA-3 Document content presentation

TXA-4 Activity date/time CF_EVENTS:plan_start_date

TXA-5 Primary activity provider code/name Dm_documents: prim_prov_cd

TXA-6 Origination date/time Dm_documents: origin_date

TXA-7 Transcription date/time Dm_documents: trans_date

TXA-8 Edit date/time Dm_documents: edit_date

TXA-9 Originator code/name

TXA-10 Assigned document authenticator

TXA-11 Transcription code/name

TXA-12 Unique document number Dm_documents: ext_doc_name

TXA-13 Parent document number Dm_documents: ext_parent_doc_id

TXA-14 Placer order number

TXA-15 Filler order number

TXA-16 Unique document file name

TXA-17 Document completion status Dm_documents: doc_compl_status

TXA-18 Document confidentiality status Dm_documents: doc_conf_status



TXA-19 Document availability status Dm_documents: doc_avail_status

TXA-20 Document storage status Dm_documents: doc_strge_status

TXA-21 Document change reason Dm_documents: doc_change_reason

TXA-22 Authentication person, time stamp

TXA-23 Distributed copies

Segment Field


Column

OBX-2 Value Type Only text in OBX segments that have OBX-2 equal to 'TX' or 'FT' will be used to create text documents

OBX-3 Observation Identifiers

OBX-5 Observation Data One line of the document's ASCII text. The linefeed terminator must not be included.

Note: Special characters defined by HL7 that may be in the body of the text report are converted to the defined HL7 version 2.3 escape sequences.

The following are used:

| mapped to \F\

^ mapped to \S\

& mapped to \T\

~ mapped to \R\

\ mapped to \E\

(HL7 2.3.1 Section: 2.9.1 Formatting Codes)

The message's repeating OBX-5 fields will be concatenated together and saved in an ASCII text file in the HeartSuite CVIS document repository as a report or amended. The file name will be stored in dm_other.doc_name. The directory name will be stored in dm_other.doc_location.

Segment Field


Column



4.7.3. MFN^M02 Message

MSH Segment


Column




NA


MSH-5 Receiving Application 'HS-CVIS' NA

MSH-7 Date/Time of Message Current date/time (example: 200509261020)

NA

MSH-9 Message type 'MFN^M02' NA

MSH-10 Message control ID Unique message ID generated by sending system.

NA



MFI Segment Description NotesHeartSuite CVIS Database Table

Column

MFI-1 Master File Identifier Identifies type of master file:

'PRA' or 'STF'

NA

MFI-3 File-Level Event Code Only 'UPD' is supported NA

MFI-6 Response Level Code 1a

a. HeartSuite CVIS will always provide an acknowledgement for each message it receives (as denoted by 'AL' in the MFI-6 field). An acknowledgement will be sent for a success or failure.

Only 'AL' is supported NA

MFE Segment


Column

MFE-1 Record-Level Event Code Only 'MAD' (add record to master file) and 'MUP' (update record in master file) are supported

NA

MFE-4 Primary Key Value - MFE Uniquely identifies the record of the master file to be changed (as defined by the record-level event code)

NA



STF Segment Description NotesHeartSuite CVIS Database Table

Column

STF-1 Primary Key Value - STF Must match MFE-4 primary key value

NA

STF-2 Staff ID Code Uniquely identifies a physician in HeartSuite CVIS

cf_lov_phys:idx_id_num

STF-3.1 Family Name cf_lov_phys:Last_Name

STF-3.2 Given Name cf_lov_phys:First_Name

STF-3.3 Middle Initial or Name cf_lov_phys:Middle_Name

STF-3.4 Suffix cf_lov_phys:Suffix

STF-7 Active/Inactive Flag cf_lov_phys:MDStatus

STF-8.2 Department Multiple departments in repeating fields are supported.

STF-8.2 and PRA-2.2 are used to determine if the physician is a member of the HeartSuite CVIS staff physician group.

cf_lov_phys:Deptcf_lov_phys:Staff_Flag

STF-10 Phone This is a repeating field, with a component (STF-10.3) for indicating the telecommunication equipment type. Supported types are 'PH' (office telephone), 'FX' (fax), 'CP' (cell phone), and 'BP' (beeper).

cf_phn_contacts:Phn_Numcf_phn_contacts.Phn_Num_Type

STF-11.1 Street Multiple addresses (repeats of STF-11) are not supported.

cf_phys_addr: addr1

STF-11.3 City Multiple addresses (repeats of STF-11) are not supported.

cf_phys_addr: city

STF-11.4 State or Province Multiple addresses (repeats of STF-11) are not supported.

cf_phys_addr: state_prov

STF-11.5 Zip Multiple addresses (repeats of STF-11) are not supported.

cf_phys_addr: zip_post_cd

STF-15 E-Mail Address Multiple email addresses (repeats of STF-15) are not supported.

cf_lov_phys:Email



4.7.4. ORM^O01 Message

PRA Segment


Column

PRA-1 Primary Key Value - PRA Must match the MFE-4 primary key value

NA

PRA-2.2 Practitioner Group Institution (i.e. hospital name or practice).

STF-8.2 and PRA-2.2 are used to determine if the physician is a member of the HeartSuite CVIS staff physician group.

cf_phys_addr:Phys_Addr_Grp_Namecf_lov_phys:Staff_Flag

Segment Field


Column



MSH-3 Sending Application During implementation, the cf_app_systems table must be configured to include a record corresponding to the value sent in this field (the MSH-3 value is put in the hl7_sending_app_name column). The mrn_type should be set to the desired value for patient records created during the processing of the sending system's ORM messages.

During implementation, the cf_app_systems table must be configured to include a record corresponding to the value sent in this field (the MSH-3 value is put in the hl7_sending_app_name column)





MSH-9 Message type Only ORM^O01 is supported. NA

MSH-10 Message control ID Unique message identifier. NA



Segment Field


Column

PID-3 Patient ID The unique identifier for a patient in HeartSuite CVIS

CF_PATIENTS: MRN






PID-7 Patient Date of Birth Not a required field in EchoIMS CF_PATIENTS: DOB


PID-18 Patient Acct. Number The unique identifier for a patient visit. If it is not present, then the HeartSuite CVIS order will be created against the patient's HeartSuite CVIS dummy visit.


Segment Field


Column

PV1-2 Patient Class CF_VISITS: Patient_Class

PV1-3.1 POC/Nursing Unit HeartSuite CVIS Visit Location. CF_VISITS: locn_ptofcare



PV1-3.2 Room CF_VISITS: locn_room



PV1-3.3 Bed CF_VISITS: locn_bed

PV1-10 Hospital service CF_VISITS: hosp_service

PV1-44 Admit date/time CF_VISITS: plan_start_date

Segment Field


Column

AL1-2 Allergy Type AL1-2 values are also added to the cf_lov table (lov_cd='ALLERGEN_TYPE')

CF_PATIENT_ALLERGIES: allergen_type

CF_LOV: lov_cd

AL1-3 Allergy Code CF_PATIENT_ALLERGIES: allergen_desc

CF_LOV: lov_desc

AL1-4 Allergy Severity CF_PATIENT_ALLERGIES: allergen_severity

Segment Field


Column



AL1-5 Allergy Reaction CF_PATIENT_ALLERGIES: allergen_reaction

AL1-6 Onset Date CF_PATIENT_ALLERGIES: onset_date

Segment Field


Column

ORC-1 Order Control Supported values are 'NW', 'SC', and 'CA'

CF_ORDERS: status_id

(calculated based on the values in ORC-1 and ORC-5)

ORC-2 Placer Order Number This field and MSH-3 are used to uniquely identify an order in HeartSuite CVIS. May also be sent in OBR-2.

CF_ORDERS: order_placer_num

ORC-3 Filler Order Number May also be send in OBR-3 CF_ORDERS: order_filler_num

ORC-4 Placer Group Number CF_ORDERS: order_group_num

ORC-5 Order Status Supported values are 'CM' (completed) and 'CA' (cancelled).

Also used with ORC-1 to calculate cf_orders. status_id

CF_ORDERS: status_id

(calculated based on the values in ORC-1 and ORC-5)

ORC-7.4 Quantity/Timing CF_ORDERS: req_date_time

ORC-7.6 Priority CF_ORDERS: priority

ORC-9 Date/Time of Transaction CF_ORDERS: entered_date_time

ORC-10.1 Entered By Id The cf_order_staff order_staff_type_id column value for 'Entered By' staff records is 1.

CF_ORDER_STAFF: sending_app_id

ORC-10.2 Entered By Family Name CF_ORDER_STAFF: last_name

ORC-10.3 Entered By Given Name CF_ORDER_STAFF: first_name

ORC-10.7 Entered By Degree CF_ORDER_STAFF: deg_role

ORC-11.1 Verified By Id The cf_order_staff order_staff_type_id column value for 'Verified By' staff records is 3.


ORC-11.2 Verified By Family Name CF_ORDER_STAFF: last_name

ORC-11.3 Verified By Given Name CF_ORDER_STAFF: first_name

ORC-11.7 Verified By Degree CF_ORDER_STAFF: deg_role

Segment Field


Column



ORC-12.1 Ordered By Id The cf_order_staff order_staff_type_id column value for 'Ordered By' staff records is 2.


ORC-12.2 Ordered By Family Name CF_ORDER_STAFF: last_name

ORC-12.3 Ordered By Given Name CF_ORDER_STAFF: first_name

ORC-12.7 Ordered By Degree CF_ORDER_STAFF: deg_role

Segment Field


Column

OBR-2 Placer Order Number ORC-2 is the preferred location for this data.Placer order number and MSH-3 are used to uniquely identify an order in HeartSuite CVIS.

CF_ORDERS: order_placer_num

OBR-3 Filler Order Number ORC-3 is the preferred location for this data.

CF_ORDERS: order_filler_num

OBR-4.1 Universal Service ID During implementation, map all possible combinations of MSH-3 and OBR-4.1 values to HeartSuite CVIS event types in the cf_univ_serv table.

The HeartSuite CVIS application will use the mapping when creating events from orders.

CF_UNIV_SERV: univ_serv_id

OBR-4.2 Universal Service Id Text CF_UNIV_SERV: univ_serv_ text

OBR-6 Requested Date/Time CF_ORDERS: req_date_time

OBR-30 Transport Method CF_ORDERS: transport_method

Segment Field


Column

NTE-3 Order Notes If the message contains multiple NTE segments, then the NTE-3 values will be concatenated together. The maximum supported length of the concatenated string is 4000 characters.

CF_ORDERS: order_note

Segment Field


Column

OBX-1 Set Id CF_ORDER_TEXT: order_text_seq

OBX-3.1 Observation Identifier CF_ORDER_TEXT: order_text_cd

Segment Field


Column




NOTE: This is a description of a subset of data that HeartSuite CVIS will use in an ORU^R01 message containing structured (OBX-2 = 'ST') and text report (OBX-2='TX') data. The complete specification will be dependent on the clinical modality and the type of data being sent in the message. The specification will need to be customized for each implementation.

OBX-3.2 Observation Label Text CF_ORDER_TEXT: order_label_text

OBX-5 Observation Value Maximum supported length is 4000 characters.

CF_ORDER_TEXT: order_text_value

MSH Segment


Column



MSH-3 Sending Application During implementation, the cf_app_systems table must be configured to include a record corresponding to the value sent in this field (the MSH-3 value is put in the hl7_sending_app_name column). The mrn_type should be set to the desired value for patient records created during the processing of the sending system's ORU messages.

NA



MSH-7 Date/Time of Message Current date/time (example: 200509261020)

NA

MSH-9 Message type 'ORU^R01' - Result Message NA





Column


CF_PATIENTS: MRN



Segment Field


Column






PID-18 Visit account number This must be an ADT visit account number. The value is used to search for a matching cf_visits record (account_num column) if the interface is creating a new event. If a match cannot be found, the event will be created against the patient's dummy visit. The interface will not use this value to create a visit record.

PID-29 Patient Death Date and Time Example: 200407271509

The time component is optional.

CF_PATIENTS: Patient_Status

CF_PATIENT_AUTOPSY: Deceased_Date


Column

PV1-2 Patient Class CF_EVENTS:Patient_Class

PV1-3 Location Point of Care

PV1-4 Admission Type

PV1-19 Visit number ID CardioAccess ORU message only CF_SURG_DETLS: Ca_Visit_Num

PV1-45 Discharge Date and Time CardioAccess ORU message only. The CHOP interface gets this data from an OBX segment

CF_SURG_DETLS: Discharge_Date


Column



OBR Segment


Column

OBR-2 Placer Order Number If the sending system receives orders from HeartSuite CVIS, then the OBR-2 value from the ORM message should be put here. It is used to search for a cf_events record that has a matching event_id.

OBR-3 Filler Number Used to search for a cf_events record created by a previous ORU message sent by the sending system. The interface searches for a matching value in external_id. The cf_events record must also have the app_id value associated with the MSH-3 value in the cf_app_systems table.

OBR-4.1 Universal Service ID - Charge (Procedure) Code,

The values that can be sent in this field must be mapped to HeartSuite CVIS event types (i.e. surgery, echo, etc…) in the cf_univ_serv table. If modality specific business logic needs to be run, make sure that the event type is included in one of the following HL7 modality event type groups:

• HL7_ECHO

• HL7_CATH

• HL7_MRI

• HL7_SURG

OBR-4.2 Universal Service ID - Procedure Description

Text description of the OBR-4.1 value

OBR-6 Requested Date/Time Only used if there is no value in OBR-7

Cf_events: plan_start_date

Cf_events: act_start_date

Cf_events: act_end_date

OBR-7 Ordering Physician ID Used to search for a matching event if the OBR-3 search fails.

Cf_lov_phys: idx_id_num

OBR-16.1 Ordering Physician ID HeartSuite CVIS Event Ordering Physician


OBR-16.2 Ordering Physician last name Cf_lov_phys: last_name

OBR-16.3 Ordering Physician first name Cf_lov_phys: first_name

OBR-16.4 Ordering Physician middle name/initial Cf_lov_phys: middle_name



OBR-25 Status/Correction Flag If the message contains a text report (OBX-2='TX'), then this is a required field. 'F' is used in the initial (not amended) report. If the message is for an amended report, then this field will have value of 'C',

NA

OBR-32.1.1 Prin. Results Interpreter ID HeartSuite CVIS Event Confirming Physician


OBR-32.1.2 Prin. Results Interpreter last name Cf_lov_phys: last_name

OBR-32.1.3 Prin. Results Interpreter first name Cf_lov_phys: first_name

OBR-32.1.4 Prin. Results Interpreter middle name/initial Cf_lov_phys: middle_name

OBX Segment


Column

OBX-2 Value type 'TX' or 'FT' to generate text reports from OBX-5.1 data

NA

OBX-3 Observation Identifier Not required in text report (OBX-2='TX') segments.

See CardioAccess OBX Segment Structured Data Handling on page 11 and Echo OBX Segment Structured Data Handling on page 13 for supported values in this field for the processing of structured data in OBX-5.

NA

OBX-5 Observation Value For text reports, the OBX-5 values (in segments where OBX-2='TX' or 'FT') will be concatenated together to create a text document that will be saved in the HeartSuite CVIS document repository.

See CardioAccess OBX Segment Structured Data Handling on page 11 and Echo OBX Segment Structured Data Handling on page 13 for supported values in this field.

For structured data, the destination depends on the Observation Identifier (OBX-3) , the Universal Service ID (OBR-4), and the sending system (MSH-3) values .

For text reports, the OBX-5 values (in segments where OBX-2='TX') will be concatenated together to create a text document that will be saved in the HeartSuite CVIS document repository.

OBX-6 Units

OBR Segment


Column



4.7.6. SIU Messages

MSH Segment


Column



MSH-3 Sending Application During implementation, the cf_app_systems table must be configured to include a record corresponding to the value sent in this field (the MSH-3 value is put in the hl7_sending_app_name column). The mrn_type should be set to the desired value for patient records created during the processing of the sending system's SIU messages

NA






Example: 200407271509

NA

MSH-9 Message type See Inbound - Supported Message Types on page 4 for the list of supported SIU messaged types




SCH Segment


Column

SCH-1.1 Placer Appointment ID - Entity Identifier Unique identifier for a patient visit CF_VISITS: Account_Num

SCH-7.1 Appointment Reason - Identifier CF_VISITS: Reas_For_Visit

CF_EVENTS: Reas_For_Event

SCH-8.1 Appointment Type - Identifier CF_VISITS:Vis_Pt_Status

SCH-9 Appointment Duration CF_EVENTS: Plan_Duration



SCH-11.4 Appointment Timing Quantity - Start Date/Time



Example: 200407271509

If no value is specified, then the value in AIS-4 will be used.

CF_VISITS: Plan_Start_Date

CF_VISITS: Act_Start_Date


CF_EVENTS: Act_Start_Date

SCH-25.1 Filler Status Code The site must provide a list of all the possible values for this field and the associated descriptions. The list is used to populate the CF_LOV_EVENT_STATUS and CF_LOV_VISIT_STATUS lookup tables. The values sent in ADT PV2-24 are also used to populate these lookup tables.

CF_VISITS: Visit_Status_ID

CF_EVENTS: Event_Status_ID

NTE Segment


Column

NTE-3 Comment CF_VISITS: Visit_Note

CF_EVENTS: Event_Note


Column


CF_PATIENTS: MRN




PID-5.4 Patient Name - Suffix CF_PATIENTS: Name_Suffix



PID-9.1 Patient Alias CF_PATIENTS: Previous_Name

PID-10 Race CF_PATIENTS: Race

PID-11.1 Patient Address - Street Address CF_PATIENTS: Addr1

PID-11.2 Patient Address - Other Designation CF_PATIENTS: Addr2

PID-11.3 City CF_PATIENTS: City

PID-11.4 Patient Address - State Or Province CF_PATIENTS: State_Prov

SCH Segment


Column



PID-11.5 Patient Address - Zip or Postal Code CF_PATIENTS: Zip_Post_Code

PID-11.6 Patient Address - Country CF_PATIENTS: Cntry_Code

PID-11.9 Patient Address - County Parish Code CF_PATIENTS:Cnty_Prsh_Cd

PID-13 Phone Number - Home CF_PATIENTS: Phn_Num_Home

PID-15 Primary Language CF_PATIENTS: Lang

PID-16 Marital Status CF_PATIENTS: Marital_Stat

PID-17 Religion CF_PATIENTS: Religion

PID-18 Patient Acct. Number Used to identify a patient visit in HeartSuite CVIS


PID-19 Social Security Number CF_PATIENTS: Patient_SSN

PID-29 Patient Death Date and Time CF_PATIENT_AUTOPSY: Deceased_Date

PID-30 Patient Death Indicator CF_PATIENTS: Patient_Status


Column

PV1-7.1 Attending Doctor ID HeartSuite CVIS Visit attending physician.


PV1-7.2 Attending Doctor Last Name CF_LOV_PHYS: Last_Name

PV1-7.3 Attending Doctor First Name CF_LOV_PHYS: First_Name

PV1-7.4 Attending Doctor Middle Name CF_LOV_PHYS: Middle_Name

PV1-8.1 Referring Doctor ID HeartSuite CVIS Visit referring physician


PV1-8.2 Referring Doctor Last Name CF_LOV_PHYS: Last_Name

PV1-8.3 Referring Doctor First Name CF_LOV_PHYS: First_Name

PV1-8.4 Referring Doctor Middle Name CF_LOV_PHYS: Middle_Name

PV1-19 Visit Number


Column



AIS Segment Description NotesHeartSuite CVIS Database Table

Column

AIS-3.1 Universal Service ID - Identifier The site must provide a list of all the possible outpatient Cardiology department values for this field and how they should map to HeartSuite CVIS event types. The list is used to populate the cf_univ_serv Table.

Messages that include values that are not in this list will not be processed by the HeartSuite CVIS HL7 Inbound Server.

CF_EVENTS: Event_Type_ID - (AIS 3.1 is used to find the equivalent HeartSuite CVIS event type in the CF_LOV_EVENT_TYPE_MAP table)

CF_VISITS: Car_Vis_Flag (if AIS-3.1 is a Cardiology value, then car_vis_flag is set to 1)

CF_VISITS: Hosp_Service

AIS-3.2 Universal Service ID - Text

AIS-4 Start Date/Time Must include a time component.


Example: 200407271509

If no value is specified in SCH-11.4, then this value will be used.


AIL Segment Description NotesHeartSuite CVIS Database Table

Column

AIL-3.1 Location Resource ID - Point of Care HeartSuite CVIS Visit Location

The site should provide a list of all the possible pairs of AIL3.1 and 3.2. This list is used to populate the CF_LOV_LOCN lookup table.

CF_VISITS: Locn_PtOfCare

CF_EVENTS: Locn_ID

CF_LOV_LOCN: Locn_cd

AIL-3.2 Location Resource ID - Room HeartSuite CVIS Visit Location

The site should provide a list of all the possible pairs of AIL3.1 and 3.2. This list is used to populate the CF_LOV_LOCN lookup table.

CF_VISITS: Locn_Room

CF_EVENTS: Locn_ID

CF_LOV_LOCN: Locn_desc

AIL-3.3 Location Resource ID - Bed CF_VISITS: Locn_Bed

AIP Segment Description NotesHeartSuite CVIS Database Table

Column

AIP-3.1 Personnel Resource ID - ID number HeartSuite CVIS Event clinic physician


AIP-3.2 Personnel Resource ID - Family Name CF_LOV_PHYS: Last_Name

AIP-3.3 Personnel Resource ID - Given Name CF_LOV_PHYS: First_Name

AIP-3.4 Personnel Resource ID - Middle Name CF_LOV_PHYS: Middle_Name



4.8. Outbound - Supported HL7 Segments and Fields

The HeartSuite CVIS HL7 Outbound Server will send HL7 messages defined in the following tables. IMPORTANT NOTES REGARDING THE TABLES:

1. Bold face text indicates the field data must exist. Otherwise, the message is not generated. Note that required fields are configurable. The required fields listed below are the default required fields.

2. Normal face text indicates the fields are optional in the message.

3. Fields not listed in the following tables are ignored.

4.8.1. MDM^T02 Message

NOTE: For each configured receiving system, HeartSuite CVIS sends either MDM^T02 or ORU^R01 but not both. To send both message types to the exact same receiving system (IP address and port), the receiving system must be configured twice, the first for sending ORU^R01 and the second for sending MDM^T02.

MSH Segment


Column

MSH-1 Field Separator Subscriber specific. Default is '|' N/A

MSH-2 Encoding Characters Subscriber specific. Default is '^~\&'

N/A

MSH-3.1 Sending Application 'HS-CVIS' N/A

MSH-4 Sending Facility 'HS-CVIS' N/A

MSH-5.1 Receiving Application Subscriber specific N/A

MSH-6 Receiving Facility Subscriber specific N/A

MSH-7 Date/Time of Message Current date/time. Date format:

YYYYMMDDHHMMSS.

MSH-9 Message Type 'MDM^T02' N/A

MSH-10 Message Control ID System generated. Unique identifier.

N/A

MSH-11 Processing ID 'P' N/A

MSH-12 Version ID '2.3' N/A

EVN Segment


Column

EVN-1 Event Type Code Same as the value in MSH-9.2 - 'T02'

N/A

EVN-2 Recorded Date/Time Same as the value in MSH-7 - Date and time theHL7 message was generated.

N/A




Column

PID-3.1 Patient ID (Internal ID) Required by HL723SPEC CF_PATIENTS:MRN

PID-5.1 Patient Name - family name Required by HL723SPEC CF_PATIENTS:LAST_NAME

PID-5.2 Patient Name - given name Required by HL723SPEC CF_PATIENTS:FIRST_NAME

PID-5.3 Patient Name - middle initial or name CF_PATIENTS:MIDDLE_NAME

PID-5.4 Patient Name - suffix CF_PATIENTS:NAME_SUFFIX

PID-6.1 Mother's Maiden Name CF_PATIENTS:MTHR_MAIDEN_NAME

PID-7 Date/Time of Birth Date format:

YYYYMMDDHHMMSS.

CF_PATIENTS:DOB

PID-8 Sex CF_PATIENTS:SEX

PID-9.1 Patient Alias CF_PATIENTS:PREVIOUS_NAME

PID-10 Race CF_PATIENTS:RACE

PID-11.1 Patient Address - street address CF_PATIENTS:ADDR1

PID-11.2 Patient Address - other designation CF_PATIENTS:ADDR2

PID-11.3 Patient Address - city CF_PATIENTS:CITY

PID-11.4 Patient Address - state or province CF_PATIENTS:STATE_PROV

PID-11.5 Patient Address - zip or postal code CF_PATIENTS:ZIP_POST_CODE

PID-11.6 Patient Address -country CF_PATIENTS:CNTRY_CODE

PID-11.9 Patient Address - county/parish code CF_PATIENTS:CNTY_PRSH_CD

PID-13.1 Phone Number - Home CF_PATIENTS:PHN_NUM_HOME

PID-14.1 Phone Number - Business CF_PATIENTS:PHN_NUM_BUS

PID-15.1 Primary Language CF_PATIENTS: LANG

PID-16 Marital Status CF_PATIENTS:MARITAL_STAT

PID-17 Religion CF_PATIENTS: RELIGION

PID-18.1 Patient Account Number CF_VISITS:ACCOUNT_NUM

PID-19 SSN Number - Patient CF_PATIENTS:PATIENT_SSN




Column

PV1-2 Patient Class Required by HL723SPEC

HeartSuite CVIS values in

CF_LOV:

I Inpatient

O Outpatient

Valid HL723SPEC values:

E Emergency

I Inpatient

O Outpatient

P Preadmit

R Recurring Patient

B Obstetrics

CF_VISITS:PATIENT_CLASS

PV1-3.1 Assigned Patient Location - Point of Care CF_VISITS:LOCN_PTOFCARE

PV1-3.2 Assigned Patient Location - Room CF_VISITS:LOCN_ROOM

PV1-3.3 Assigned Patient Location - Bed CF_VISITS:LOCN_BED

PV1-4 Admission Type Subscriber specific N/A

PV1-7.1 Attending doctor - ID number If the event has an associated attending doctor, then it is used. If there is no attending doctor associated to the event, then the visit is checked for an associated attending doctor. If one exists, then it is used. Otherwise the value in this field is null.

CF_LOV_PHYS:IDX_ID_NUM

PV1-7.2 Attending doctor - family name If the event has an associated attending doctor, then it is used. If there is no attending doctor associated to the event, then the visit is checked for an associated attending doctor. If one exists, then it is used. Otherwise the value in this field is null.

CF_LOV_PHYS:LAST_NAME

PV1-7.3 Attending doctor - given name If the event has an associated attending doctor, then it is used. If there is no attending doctor associated to the event, then the visit is checked for an associated attending doctor. If one exists, then it is used. Otherwise the value in this field is null.

CF_LOV_PHYS:FIRST_NAME



PV1-7.4 Attending doctor - middle initial or name If the event has an associated attending doctor, then it is used. If there is no attending doctor associated to the event, then the visit is checked for an associated attending doctor. If one exists, then it is used. Otherwise the value in this field is null.

CF_LOV_PHYS:MIDDLE_NAME

PV1-8.1 Referring doctor - ID number If the event has an associated referring doctor, then it is used. If there is no referring doctor associated to the event, then the visit is checked for an associated referring doctor. If one exists, then it is used. Otherwise the value in this field is null.


PV1-8.2 Referring doctor - family name If the event has an associated referring doctor, then it is used. If there is no referring doctor associated to the event, then the visit is checked for an associated referring doctor. If one exists, then it is used. Otherwise the value in this field is null.


PV1-8.3 Referring doctor - given name If the event has an associated referring doctor, then it is used. If there is no referring doctor associated to the event, then the visit is checked for an associated referring doctor. If one exists, then it is used. Otherwise the value in this field is null.


PV1-8.4 Referring doctor - middle initial or name If the event has an associated referring doctor, then it is used. If there is no referring doctor associated to the event, then the visit is checked for an associated referring doctor. If one exists, then it is used. Otherwise the value in this field is null.



Column



PV1-9.1 Consulting doctor - ID number If the event has an associated consulting doctor, then it is used. If there is no consulting doctor associated to the event, then the visit is checked for an associated consulting doctor. If one exists, then it is used. Otherwise the value in this field is null.


PV1-9.2 Consulting doctor - family name If the event has an associated consulting doctor, then it is used. If there is no consulting doctor associated to the event, then the visit is checked for an associated consulting doctor. If one exists, then it is used. Otherwise the value in this field is null.


PV1-9.3 Consulting doctor - given name If the event has an associated consulting doctor, then it is used. If there is no consulting doctor associated to the event, then the visit is checked for an associated consulting doctor. If one exists, then it is used. Otherwise the value in this field is null.


PV1-9.4 Consulting doctor - middle initial or name If the event has an associated consulting doctor, then it is used. If there is no consulting doctor associated to the event, then the visit is checked for an associated consulting doctor. If one exists, then it is used. Otherwise the value in this field is null.


PV1-17.1 Admitting doctor - ID number If the event has an associated admitting doctor, then it is used. If there is no admitting doctor associated to the event, then the visit is checked for an associated admitting doctor. If one exists, then it is used. Otherwise the value in this field is null.



Column



PV1-17.2 Admitting doctor - family name If the event has an associated admitting doctor, then it is used. If there is no admitting doctor associated to the event, then the visit is checked for an associated admitting doctor. If one exists, then it is used. Otherwise the value in this field is null.


PV1-17.3 Admitting doctor - given name If the event has an associated admitting doctor, then it is used. If there is no admitting doctor associated to the event, then the visit is checked for an associated admitting doctor. If one exists, then it is used. Otherwise the value in this field is null.


PV1-17.4 Admitting doctor - middle initial or name If the event has an associated admitting doctor, then it is used. If there is no admitting doctor associated to the event, then the visit is checked for an associated admitting doctor. If one exists, then it is used. Otherwise the value in this field is null.


PV1-19.1 Visit Number CF_VISITS:ACCOUNT_NUM

PV1-44 Admit Date/Time Date format:

YYYYMMDDHHMMSS.

CF_VISITS:ACT_START_DATE

PV1-45 Discharge Date/Time Date format:

YYYYMMDDHHMMSS.

CF_VISITS:ACT_END_DATE

TXA Segment


Column

TXA-1 Set ID-TXA Subscriber specific N/A

TXA-2 Document Type CF_LOV_EVENT_TYPE:EVENT_TYPE_CD + CF_LOV_DOC_TYPE:DOC_TYPE_CD

TXA-3 Document Content Presentation Subscriber specific N/A

TXA-4 Activity Date/Time CF_EVENTS:ACTUAL_START_DATE

TXA-12.1 Unique Document Number - Entity Identifier

DM_DOCUMENTS:DOC_ID


Column



TXA-12.2 Unique Document Number - Namespace ID

'HeartSuite CVIS' N/A

TXA-13 Parent Document Number DM_DOCUMENTS:PARENT_DOC_ID

TXA-14 Placer Order Number If there is no order associated with the event, then the event id will be used. Otherwise, the value will come from the orders table.

CF_ORDERS:ORDER_PLACER_NUM

or

CF_EVENTS:EVENT_ID

TXA-17 Document Completion Status Subscriber specific N/A

TXA-22.1 Authentication Person, Time Stamp - ID number

DM_DOC_USER_LINK WHERE DOC_USER_LINK_TYPE_ID = 1

Join

CF_USER_ATTRIBUTES

Join


TXA-22.2 Authentication Person, Time Stamp - family name


Join

CF_USER_ATTRIBUTES

Join


TXA-22.3 Authentication Person, Time Stamp - given name


Join

CF_USER_ATTRIBUTES

Join


TXA-22.3 Authentication Person, Time Stamp - middle initial or name


Join

CF_USER_ATTRIBUTES

Join


TXA-22.15 Authentication Person, Time Stamp - date/time action performed

DM_DOC_USER_LINK:DOC_DATE

TXA Segment


Column



The OBX segment encapsulates the entire text of the verified report or supports a reference pointer. HeartSuite CVIS HL7 Outbound supports three options for the encapsulated report:

1. One OBX segment containing the whole report.

2. One OBX segment per line.

3. Configurable number of bytes per OBX segment.

4.8.2. ORM^O01 Message

OBX Segment


Column

OBX-1 Set ID The number of the OBX segment. N/A

OBX-2 Value Type Subscriber Specific (TX, FT, or RP are supported)

N/A

OBX-5 Observation Data For encapsulated documents, the content of the document from DOC_BFILE will be located in this field. For referenced documents, the DOC_ID will be located in this field.

DM_DOCUMENTS:DOC_BFILE or DM_DOCUMENTS:DOC_ID

OBX-11 Observation Status Subscriber specific N/A

MSH Segment


Column

MSH-1 Field Separator Subscriber specific. Default is '|', Required by HL723SPEC

N/A

MSH-2 Encoding Characters Subscriber specific. Default is '^~\&', Required by HL723SPEC

N/A






YYYYMMDDHHMMSS.

N/A

MSH-9 Message Type 'ORM^O01', Required by HL723SPEC

N/A

MSH-10 Message Control ID System generated. Unique identifier. Required by HL723SPEC

N/A

MSH-11 Processing ID 'P', Required by HL723SPEC N/A

MSH-12 Version ID '2.3', Required by HL723SPEC N/A




Column








YYYYMMDDHHMMSS.

CF_PATIENTS:DOB





















Column



CF_LOV:

I Inpatient

O Outpatient


E Emergency

I Inpatient

O Outpatient

P Preadmit

R Recurring Patient

B Obstetrics

























Column











YYYYMMDDHHMMSS.



YYYYMMDDHHMMSS.


ORC Segment


Column

ORC-1 Order control Required by HL723SPEC

Valid values: 'NW' or 'CA'

N/A


Column



OBR Segment


Column

OBR-2.1 Placer Order Number If there is no order associated with the event, then the event id will be used. Otherwise, the value will come from the orders table.


or

CF_EVENTS:EVENT_ID

OBR-3.1 Filler Order Number If there is no order associated with the event, then the event id will be used. Otherwise, the value will come from the orders table. However, the value in the orders table may actually be the event id.

CF_ORDERS:ORDER_FILLER_NUM

or

CF_EVENTS:EVENT_ID

OBR-4.1 Universal Service ID - identifier Required by HL723SPEC

If there is no order associated with the event, then the event type id will be used. Otherwise, the value will come from the universal service table record that is related to the order.

CF_UNIV_SERV:UNIV_SERV_ID

or

CF_LOV_EVENT_TYPE:EVENT_TYPE_ID

OBR-4.2 Universal Service ID - text Required by HL723SPEC

If there is no order associated with the event, then the event type code will be used. Otherwise, the value will come from the universal service table record that is related to the order.

CF_UNIV_SERV: UNIV_SERV_TEXT

or

CF_LOV_EVENT_TYPE:EVENT_TYPE_CD

OBR-6 Requested Date/Time Scheduled date for procedure. Date format:

YYYYMMDDHHMMSS.

CF_EVENTS:PLAN_START_DATE

OBR-7 Observation Date/Time Date format:

YYYYMMDDHHMMSS.

CF_EVENTS:ACTUAL_START_DATE

OBR-8 Observation End Date/Time Date format:

YYYYMMDDHHMMSS.

CF_EVENTS:ACTUAL_END_DATE

OBR-16.1 Ordering doctor - ID If the event has an associated ordering doctor, then it is used. Otherwise the value in this field is null.


OBR-16.2 Ordering doctor - family name If the event has an associated ordering doctor, then it is used. Otherwise the value in this field is null.





NOTE: For each configured receiving system, HeartSuite CVIS sends either MDM^T02 or ORU^R01 but not both. To send both message types to the exact same receiving system (IP address and port), the receiving system must be configured twice, the first for sending ORU^R01 and the second for sending MDM^T02.

OBR-16.3 Ordering doctor - given name If the event has an associated ordering doctor, then it is used. Otherwise the value in this field is null.


OBR-16.4 Ordering doctor - middle initial or name If the event has an associated ordering doctor, then it is used. Otherwise the value in this field is null.


OBR-31.2 Reason For Study CF_EVENTS:REAS_FOR_EVENT

MSH Segment


Column

MSH-1 Field Separator Subscriber specific. Default is '|' N/A

MSH-2 Encoding Characters Subscriber specific. Default is '^~\&'

N/A






YYYYMMDDHHMMSS.

N/A

MSH-9 Message Type 'ORU^R01' N/A

MSH-10 Message Control ID System generated. Unique identifier.

N/A

MSH-11 Processing ID 'P' N/A

MSH-12 Version ID '2.3' N/A


Column




OBR Segment


Column







YYYYMMDDHHMMSS.

CF_PATIENTS:DOB



















Column




Column



CF_LOV:

I Inpatient

O Outpatient


E Emergency

I Inpatient

O Outpatient

P Preadmit

R Recurring Patient

B Obstetrics

























Column











YYYYMMDDHHMMSS.



YYYYMMDDHHMMSS.


OBR Segment


Column

OBR-2.1 Placer Order Number If there is no order associated with the event, then the event id will be used. Otherwise, the value will come from the orders table.


or

CF_EVENT:EVENT_ID

OBR-3.1 Filler Order Number If there is no order associated with the event, then the event id will be used. Otherwise, the value will come from the orders table. However, the value in the orders table may actually be the event id.

CF_ORDERS:ORDER_FILLER_NUM

or

CF_EVENT:EVENT_ID


Column



OBR-4.1 Universal Service ID - identifier Required by HL723SPEC

If there is no order associated with the event, then the event type id will be used. Otherwise, the value will come from the universal service table record that is related to the order.

CF_UNIV_SERV:UNIV_SERV_ID

or

CF_LOV_EVENT_TYPE:EVENT_TYPE_ID

OBR-4.2 Universal Service ID - text Required by HL723SPEC

If there is no order associated with the event, then the event type code will be used. Otherwise, the value will come from the universal service table record that is related to the order.

CF_UNIV_SERV: UNIV_SERV_TEXT

or

CF_LOV_EVENT_TYPE:EVENT_TYPE_CD

OBR-6 Requested Date/Time Date format:

YYYYMMDDHHMMSS.

CF_EVENTS:PLAN_START_DATE

OBR-7 Observation Date/Time Date format:

YYYYMMDDHHMMSS.

CF_EVENTS:ACTUAL_START_DATE

OBR-8 Observation End Date/Time Date format:

YYYYMMDDHHMMSS.

CF_EVENTS:ACTUAL_END_DATE

OBR-16.1 Ordering doctor - ID If the event has an associated ordering doctor, then it is used. Otherwise the value in this field is null.


OBR-16.2 Ordering doctor - family name If the event has an associated ordering doctor, then it is used. Otherwise the value in this field is null.


OBR-16.3 Ordering doctor - given name If the event has an associated ordering doctor, then it is used. Otherwise the value in this field is null.


OBR-16.4 Ordering doctor - middle initial or name If the event has an associated ordering doctor, then it is used. Otherwise the value in this field is null.


OBR-20 Filler Field 1 The unique document ID. DM_DOCUMENTS:DOC_ID

OBR-21 Filler Field 2 For amended reports, the unique document ID of the original document. Null if the document has not been amended.

DM_DOCUMENTS:PARENT_DOC_ID

OBR Segment


Column



OBR-22 Results Report/Status Change - Date/Time CF_DOC_PHYS_LINK:APPROVAL_DATE

OBR-25 Result Status Used to determine whether or not it is the first time the result has been uploaded.

If the result message is a subsequent result, then this field will have value of 'C', otherwise this field will have a value of 'F' signaling the initial report.

DM_DOCUMENTS:PARENT_DOC_ID

OBR-31 Reason For Study CF_EVENTS:REAS_FOR_EVENT

OBR-32.1.1 Prin. Results Interpreter - ID DM_DOC_USER_LINK WHERE DOC_USER_LINK_TYPE_ID = 1

Join

CF_USER_ATTRIBUTES

Join


OBR-32.1.2 Prin. Results Interpreter - family name DM_DOC_USER_LINK WHERE DOC_USER_LINK_TYPE_ID = 1

Join

CF_USER_ATTRIBUTES

Join


OBR-32.1.3 Prin. Results Interpreter - given name DM_DOC_USER_LINK WHERE DOC_USER_LINK_TYPE_ID = 1

Join

CF_USER_ATTRIBUTES

Join


OBR-32.1.4 Prin. Results Interpreter - middle initial or name


Join

CF_USER_ATTRIBUTES

Join


OBR Segment


Column



The OBX segment encapsulates the entire text of the verified report or supports a reference pointer. HeartSuite CVIS HL7 Outbound supports three options for the encapsulated report:

1. One OBX segment containing the whole report.

2. One OBX segment per line.

3. Configurable number of bytes per OBX segment.

The DSC segment is used when a report message is broken into multiple ORU^R01 messages in support of a HIS that may restrict the number of OBX per ORU^R01 message.

OBX Segment


Column

OBX-1 Set ID The number of the OBX segment. N/A

OBX-2 Value Type Subscriber Specific (TX, FT, or RP are supported)

N/A

OBX-5 Observation Data For encapsulated documents, the content of the document from DOC_BFILE will be located in this field. For referenced documents, the DOC_ID will be located in this field.

DM_DOCUMENTS:DOC_BFILE or DM_DOCUMENTS:DOC_ID

OBX-11 Observation Status Subscriber Specific N/A

DSC Segment


Column

DSC-1 Continuation Pointer N/A



5. Sample Inbound Messages

5.1. Sample MDM Message from HISMSH|^~\&|HIS|FACILITY1|CVIS|FACILITY1|20060217103355||MDM^T02|1236733|D^T|2.3.1|1025029|PID|||10000006||pedtestâmy||20040303|F|||^^^^ÛSA|||x|TXA|001|PR|TX|20060217|AA|20060217102800||||||0100000065702637680PED CARDIO TEST|||0100000065702637680PED CARDIO TEST|PED CARDIO TEST|AU|U|AV|AC|OBX|001|ST|PED CARDIO TEST||Date: 02/17/06 : 10:28am|OBX|002|ST|PED CARDIO TEST||Title: PED CARDIO TEST|OBX|003|ST|PED CARDIO TEST|OBX|004|ST|PED CARDIO TEST|OBX|005|ST|PED CARDIO TEST||I am creating a signing a note.|OBX|006|ST|PED CARDIO TEST|OBX|007|ST|PED CARDIO TEST|OBX|008|ST|PED CARDIO TEST||# SIGNED BY Any Person (AA) 02/17/2006 10:28AM|OBX|009|ST|PED CARDIO TEST|OBX|010|ST|PED CARDIO TEST|

5.2. Sample MFN^M02 Message from HISMSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M02|MSGID002|P|2.3.1|||AL|NEMFI|0004^DOCTOR^HL7||UPD|||ALMFE|MAD|U2246|199110011230|PMF98123789182^^PLWSTF|PMF98123789182^^PLW|U2246^^^PLW~111223333^^ÛSSSA^SS|CARDIOLOGIST^DOCTOR^J^JR^DR^M.D.|P|M|19511004|A|ÎCU|^MED|(123)111-1234X345~(123)222-3334(123)333-1345X789|123 SOMEWHERE ST^SUITE 200^SEATTLE^WA^92345^H~123 ANYWHERE AVE W^^SEATTLE, WA^92345Ô |19890125^HOSPITAL&HOSPITAL CENTER&L01||PMF88123453334|[email protected]|BPRA|PMF98123789182^^PLW|^CARDIOLOGIST FAMILY PRACTICE|ST|I|OB/GYN^STATE BOARD OF OBSTETRICS AND GYNECOLOGY^C^19790123|123321ÛPIN~123321^CTYÂBC~112233^TAX~1133221^DEA~11332255^MDD^CA|ADMIT&&ADT^MED&&L2^19941231~DISCH&&ADT^MED&&L2^19941231|

5.3. Sample ORU^R01 (Structure Data) Message from CardioAccess

The following is a sample of a supported inbound ORU message with OBX segments containing structured data.. The message was generated and sent by the CardioAccess surgery results application. The HeartSuite CVIS HL7 Inbound Server uses the data in OBX-5 fields to populate application data fields related to patient surgery events.

MSH|^~\&|CARDIOACCESS||CVIS||200508261004361446||ORU^R01|MSGID200507261004364446|P|2.3|||||||English PID|1||2297211||Smith^Tina||20040105|M||||||||||2297211||||||||||| PV1|14032|I|||||||||||||||||101425781||||||||||||||||||||Children's Hospital of Columbus|||||20021217|20021121 OBR|||FON200508261004361246|CPB||||||||||||||||||||SURGERY|F|||||||^Flanders^Chris||^Flanders^Chris OBX|1|ST|CaseNumber||1246||||||F OBX|2|TS|Date of Event||20041217||||||F OBX|3|ST|BSA||0.314|Meters squared|||||F OBX|4|TS|Event Start||200412170914||||||F OBX|5|TS|Time surgery commenced||200412170924||||||F OBX|6|TS|Time surgery completed||200412171345||||||F OBX|7|TS|Event End||200412171600||||||F OBX|8|ST|Antenatal Diagnosis?(Y/N)||N||||||F OBX|9|ST|General Preoperative Risk Factors||None||||||F OBX|11|ST|Non-cardiac Abnormalities||None||||||F OBX|13|SI|Preoperative note||TOF/PA s/p RMBTS, s/p Central shunt, s/p RVOT stent placement. ||||||F OBX|14|SI|Number of prior total Cardiothoracic Operations||4||||||F OBX|15|SI|Number of prior open Cardiothoracic Operations||3||||||F OBX|16|ST|Case category||CPB||||||F OBX|17|ST|Pump used(Y/N)||Y||||||F OBX|18|ST|Weight||6.7|Kg|||||F OBX|19|ST|Height||76|Cm|||||F OBX|20|ST|Surgeon||~Grant~Carol||||||F OBX|21|SI|CPB time||182||||||F OBX|22|SI|Aortic cross-clamp time||117|min|||||F OBX|23|SI|Circulatory arrest time||0|min|||||F OBX|24|ST|Re-operation during this admission?||No||||||F OBX|25|ST|Re-operation after this operation in this admission?||No||||||F OBX|26|ST|Surgery Location||OR||||||F OBX|27|ST|TEE(Y/N)||Y||||||F OBX|28|ST|Postoperative note||Limited labs drawn-all done ISTATExtubated in OR and reintubated after 1 hr. d/t decreased resp. effort. Bloody secretions suctioned from lungs.||||||F OBX|29|ST|Operative Mortality(Y/N)||N||||||F OBX|30|ST|Mortality assigned to this operation||N||||||F



5.4. Sample ORU^R01 (Text Report) Message from EchoIMS

The following is a sample of a supported inbound ORU message that contains a plain text report embedded in multiple OBX segments. The message was generated and sent by the EchoIMS echo reporting application. The HeartSuite CVIS HL7 Inbound Server can extract the text data from the message's OBX-5 fields to create an echo report document in the HeartSuite CVIS document repository.

MSH|^~\&|ECHOIMS|ECHOIMS|ECHOIMS1||20040907163005||ORU^R01|1944263951|P|2.3 PID|||987654321||Smith^Joe^A||19560625|M||W|129 West Avenue^^Hartland^WI^53029||2625551212|2625674444||||32145 PV1||O|5th Floor||||||||||||||||00002 OBR|||21|1646^TEE|||200408301000|||||||||200^zaheer^omer|||||||||F||||||Severe Chest Pain|100&Tech&Vmi OBX|1|TX||1|Patient Name: Smith, Joe||||||F OBX|2|TX||1|Chart Number: 987654321||||||F OBX|3|TX||1|Date of Appt: Monday, August 30, 2004||||||F OBX|4|TX||1|Adult Echocardiogram Report||||||F OBX|5|TX||1|Age: 48y/2m/5d DOB: 25-Jun-1956 Sex: Male BSA (m 2): 0.98 ||||||F OBX|6|TX||1|Referral diagnosis: no diag Person requesting test: SpiderMan 2 ||||||F OBX|7|TX||1|Sonographer: SpiderMan 2 Reason for test: Severe Chest Pain ||||||F OBX|8|TX||1|Patient location: 5th Floor Tape #: 44 ||||||F OBX|9|TX||1|Measures:||||||F OBX|10|TX||1| ||||||F OBX|11|TX||1|Body:||||||F OBX|12|TX||1| ||||||F OBX|13|TX||1|Name Value Units ||||||F OBX|14|TX||1|Height ||||||F OBX|15|TX||1| 66 cm ||||||F OBX|16|TX||1|Weight ||||||F OBX|17|TX||1| 44 kg ||||||F OBX|18|TX||1|BSA ||||||F OBX|19|TX||1| 0.98 m 2 ||||||F OBX|20|TX||1| ||||||F OBX|21|TX||1|2D:||||||F OBX|22|TX||1| ||||||F OBX|23|TX||1|Name Value Units ||||||F OBX|24|TX||1|LVED(EDV) ||||||F OBX|25|TX||1| 1.00 ml ||||||F OBX|26|TX||1|LVES(ESV) ||||||F OBX|27|TX||1| 2.00 ml ||||||F OBX|28|TX||1|EF ||||||F OBX|29|TX||1| 50.00 % ||||||F OBX|30|TX||1|Aortic Arch ||||||F OBX|31|TX||1| 4.00 cm ||||||F OBX|32|TX||1|Aortic Root ||||||F OBX|33|TX||1| 5.00 cm ||||||F OBX|34|TX||1|Ascending Ao Diameter ||||||F OBX|35|TX||1| 6.00 cm ||||||F OBX|36|TX||1|Mitral Valve Area ||||||F OBX|37|TX||1| 7.00 cm 2 ||||||F OBX|38|TX||1|Left Atrial Area ||||||F OBX|39|TX||1| 8.00 ||||||F OBX|40|TX||1|Left Atrial Index ||||||F OBX|41|TX||1| 9.00 ||||||F OBX|42|TX||1|Right Atrial Area ||||||F OBX|43|TX||1| 1.00 ||||||F OBX|44|TX||1|Right Atrial Index ||||||F OBX|45|TX||1| 2.00 ||||||F OBX|46|TX||1|IVC Diameter ||||||F OBX|47|TX||1| 3.00 cm ||||||F OBX|48|TX||1|LVOT Diameter (LAX) ||||||F OBX|49|TX||1| 4.00 cm ||||||F OBX|50|TX||1|Findings:||||||F OBX|51|TX||1| ||||||F OBX|52|TX||1|LV Systolic Function:||||||F OBX|53|TX||1| ||||||F OBX|54|TX||1|>> Akinetic antero-lateral wall motion||||||F OBX|55|TX||1|>> Akinetic basal sept wall||||||F OBX|56|TX||1|>> Akinetic Basal antero-septal wall||||||F OBX|57|TX||1|>> Akinetic basal inferior wall motion||||||F OBX|58|TX||1|No comment for u.||||||F OBX|59|TX||1| ||||||F OBX|60|TX||1|>> Normal Basal infero-lateral wall motion||||||F OBX|61|TX||1| ||||||F OBX|62|TX||1|Ventricle:||||||F OBX|63|TX||1| ||||||F OBX|64|TX||1|>> Right ventricular tumor||||||F OBX|65|TX||1|There is nop comment. 1- one. 2- two. 3- three. Dfsdkfjskl.||||||F OBX|66|TX||1| ||||||F OBX|67|TX||1| ||||||F OBX|68|TX||1|Summary:||||||F OBX|69|TX||1|These are my comments:||||||F OBX|70|TX||1| 1- A.||||||F OBX|71|TX||1| 2- B.||||||F OBX|72|TX||1| 3- C.||||||F OBX|73|TX||1|Reader's Name: Vmi Tech||||||F OBX|74|TX||1|Date/time of reading: Fri, Sep 3 2004 - 1:43:10 PM||||||F OBX|75|TX||1|Report created at 4:43:53 PM on Tuesday, September 07, 2004||||||F OBX|76|TX||1|Report Number: Test_Report||||||F



6. Sample Outbound Messages

6.1. Sample ORMÔ01 Message from HeartSuite CVISMSH|^~\&|HS-CVIS^""^""|HS-CVIS^""^""|Vericis||20060918151426||ORMÔ01|06091815142632173215|P|2.3| PID|||500000005||KiddÔne^Middle^MR|MOTHER MAIDEN NAME|19830915000000|F|PREVIOUS NAME|WH|2823 CLARIDGE STREETÔther^Lawnside^NJ^1234567890ÛSA^^^CountyParish||(111)111-1111|(999)999-9999|ENG|1|CHR|1000000005|123456879012345| PV1||I|10th Floor^room^bed|PEDIATRIC|||700001ÂTTENDINGLASTÂTTENDINGFIRSTÂ|700000^REFERRINGLAST^REFERRINGFIRST^R|700003^CONSULTINGLAST^CONSULTINGFIRST^C||||||||700002ÂDMITTINGLASTÂDMITTINGFIRSTÂ||1000000005|||||||||||||||||||||||||20060918090000|20060918160000| ORC|NW| OBR||1022897|1022897|1644^Routine||20060918090000|20060918090000|20060918100000||||||||700004ÔRDERINGLASTÔRDERINGFIRSTÔ||US|||||||||||||^reason for ROUTINE ECHO|

6.2. Sample MDM^T02 Message from HeartSuite CVISMSH|^~\&|HS-CVIS^""^""|HS-CVIS^""^""|ICIS||20060918163539||MDM^T02|06091816353921519752|P|2.3| EVN|T02|20060918163539| PID|||500000005||KiddÔne^Middle^MR|MOTHER MAIDEN NAME|19830915000000|F|PREVIOUS NAME|WH|2823 CLARIDGE STREETÔther^Lawnside^NJ^1234567890ÛSA^^^CountyParish||(111)111-1111|(999)999-9999|ENG|1|CHR|1000000005|123456879012345| PV1||I|10th Floor^room^bed||||700001ÂTTENDINGLASTÂTTENDINGFIRSTÂ|700000^REFERRINGLAST^REFERRINGFIRST^R|700003^CONSULTINGLAST^CONSULTINGFIRST^C||||||||700002ÂDMITTINGLASTÂDMITTINGFIRSTÂ||1000000005|||||||||||||||||||||||||20060918090000|20060918160000| TXA|1|ECHOR REPORT|AP|20060918090000||||||||545774^HeartSuite CVIS||1022904|||AU|||||700005ÂPPROVINGLASTÂPPROVINGFIRSTÂ^^^^^^^^^^^20060918163528| OBX|1|RP|||545774||||||F|

6.3. Sample ORU^R01 Message from HeartSuite CVISMSH|^~\&|HS-CVIS^""^""|HS-CVIS^""^""|ICIS||20060918163243||ORU^R01|06091816324321530656|P|2.3| PID|||500000005||KiddÔne^Middle^MR|MOTHER MAIDEN NAME|19830915000000|F|PREVIOUS NAME|WH|2823 CLARIDGE STREETÔther^Lawnside^NJ^1234567890ÛSA^^^CountyParish||(111)111-1111|(999)999-9999|ENG|1|CHR|1000000005|123456879012345| PV1||I|10th Floor^room^bed||||700001ÂTTENDINGLASTÂTTENDINGFIRSTÂ|700000^REFERRINGLAST^REFERRINGFIRST^R|700003^CONSULTINGLAST^CONSULTINGFIRST^C||||||||700002ÂDMITTINGLASTÂDMITTINGFIRSTÂ||1000000005|||||||||||||||||||||||||20060918090000|20060918160000| OBR||1022903|1022903|1575ÊCHOR||20060918090000|20060918090000|20060918100000||||||||700004ÔRDERINGLASTÔRDERINGFIRSTÔ||||545773|""|20060918163228|||F||||||^reason for ROUTINE ECHO|700005&APPROVINGLAST&APPROVINGFIRST&A| OBX|1|RP|||545773||||||F|



Tech Note HeartSuite™ CVIS 3.1 HL7 Specification · The HeartSuite CVIS HL7 Inbound Server is...

Documents

Transcript of Tech Note HeartSuite™ CVIS 3.1 HL7 Specification · The HeartSuite CVIS HL7 Inbound Server is...