02 Appendix H_CHCS Interface Control Document.pdf

28 Sep 2017

INTERFACE CONTROL DOCUMENT (ICD)

COMPOSITE HEALTH CARE SYSTEM (CHCS) INTERFACE

WITH EXTERNAL RADIOLOGY/DICTATION SYSTEMS

Defense Health Agency AHLTA/CHCS Sustainment Support

For:

Solution Delivery Division (SDD) Electronic Health Record (EHR) Core Program Management Office (PMO)

5109 Leesburg Pike, Suite 701 Falls Church, VA 22041

DHA Doc. DH-SUSTSPT-1004 28 Sep2017 i

Table of Contents

Table of Contents ............................................................................................................. i

Document History ............................................................. Error! Bookmark not defined.

1 PURPOSE

1.1 Overview

1.2 System Identification

1.2.1 CHCS

1.2.2 External radiology systems

1.3 Document Overview

1.4 Applicable Documents

2 Concept of Operations

2.1 Functional Allocation

2.2 Interface Transactions

2.3 Data Transfer

2.4 Security and Integrity

3 Message Specifications

3.1 HL7 Message Requirements

3.1.1 Unsolicited Update Messages Sent by CHCS to External Systems

3.1.2 Unsolicited Master File Notification (MFN) Messages to External Systems 9

3.1.3 Unsolicited Radiology Messages Received by CHCS from External Systems 10

3.2 HL7 Message Definitions

3.2.1 Segment and Field Definitions

3.2.2 Data Type Definitions

3.3 CHCS Messages to External Systems

3.3.1 ADT/A01 - HL DG ADMIT PATIENT

3.3.2 ADT/A02 - HL DG TRANSFER PATIENT

3.3.3 ADT/A03 - HL DG DISCHARGE PATIENT

ii

3.3.4 ADT/A08 - HL DG UPDATE PATIENT

3.3.5 ADT/A11 - HL DG CANCEL ADMIT

3.3.6 ADT/A12 - HL DG CANCEL TRANSFER

3.3.7 ADT/A13 - HL DG CANCEL DISCHARGE

3.3.8 ADT/A28 - HL DG ADD PERSON MESSAGE

3.3.9 ADT/A30 - HL DG MERGE PATIENT

3.3.10 ADT/A31 - HL DG UPDATE PERSON MESSAGE

3.3.11 MFN/M01 - HL MASTER FILE NOTIFICATION

3.3.12 ORM/O01 – HL OR RAD ORDER TSK

3.3.13 ORU/R01 – HL RAD ARRIVAL

3.3.14 ORU/R01 – HL RAD ENCOUNTER

3.3.15 ORU/R01 - HL RAD RESULT

3.3.16 ZPX^^^^^148\0124\99DMI^^^

3.3.17 ORU/R01 – HL RAD SCHEDULE

3.3.18 ORU/R01 – HL RAD SPECIAL INT – TEACHING

3.3.19 SCH/S01 - HL PAS APPOINTMENT MESSAGE

3.4 External System messages to CHCS

3.5 Message Format Definition

3.5.1 Radiology Order Messages

3.5.2 Radiology Exam Query (QRY/R02)

3.5.3 Radiology Exam Query Response (ORF/R04)

3.5.4 Radiology Exam Status Updates (ORU/R01)

3.5.5 Radiology Scheduling Messages (ORU/R01)

3.5.6 Radiology Results (ORU/R01)

3.5.7 Patient Update/Merge Messages

3.5.8 Patient Appointment Scheduling (PAS) Messages

3.6 Segments and Fields

3.6.1 AIP Appointment Information – Personnel Resources

3.6.2 AL1 Allergy Information

3.6.3 DG1 Admission Diagnosis

iii

3.6.4 DSC Continuation Pointer

3.6.5 ERR Error

3.6.6 EVN Event Type

3.6.7 IN1 Insurance Information

3.6.8 IN2 Additional Insurance Information

3.6.9 MFE Master File Entry

3.6.10 MFI Master File Identification

3.6.11 MRG Patient Merge Information

3.6.12 MSA Message General Acknowledgement

3.6.13 MSH Message Header

3.6.14 NK1 Next of Kin

3.6.15 NTE Notes and Comments

3.6.16 OBR Observation Request

3.6.17 OBX Observation Result

3.6.18 ORC Common Order

3.6.19 PID Patient Identification

3.6.20 PR1 Procedures

3.6.21 PV1 Patient Visit Information

3.6.22 PV2 Additional Patient Visit Information

3.6.23 SCH Schedule Appointment Information

3.6.24 STF Staff Identification

3.6.25 QRD Query Definition

3.6.26 QRF Query Filter

3.6.27 ZIN OHI Information

3.6.28 ZL1 Rad CPT Workload Data

3.6.29 ZM1 Rad Procedure Information

3.6.30 ZM7 User’s Allowable Divisions

3.6.31 ZMB Provider Specialty

3.6.32 ZMH MFN Hospital Location Appointment Type

3.6.33 ZMK MFN CPT/HCPCS

iv

3.6.34 ZML MFN Hospital Location

3.6.35 ZMP MFN Additional Provider Info

3.6.36 ZMU MFN USER

3.6.37 ZN9 CPT/HCPCS MODIFIERS

3.6.38 ZNN Radiology Room

3.6.39 ZNR Radiology Procedure Synonym

3.6.40 ZOO Custom Override Warning

3.6.41 ZOR Custom Clinical

3.6.42 ZOW Order Warning

3.6.43 ZPE Patient Care Manager (PCM) Information

3.6.44 ZP1 CIS Additional Patient Information

3.6.45 ZPI Additional Patient Information

3.6.46 ZPS Sponsor

3.6.47 ZPX HL CP ZPX XTRA PAT INFO

3.6.48 ZRA Arrival Information

3.6.49 ZRC Rad Appointment Cancellation Reason

3.6.50 ZRD Rad Result Teaching Code

3.6.51 ZRE Radiology Encounter Information

3.6.52 ZRF Radiology Film

3.6.53 ZRL Special Interest Codes

3.6.54 ZRR Additional Rad Result Information

3.6.55 ZRS Additional Rad Schedule Information

3.6.56 ZRT Radiology Repeat Reason

3.6.57 ZSC PAS Custom Appointment/Scheduling

4 Communication Requirements

4.1 Interface Initiation

4.2 Flow Control

4.3 External systems to CHCS for Radiology Resulting

4.4 Error Management

4.5 Security Features

v

APPENDIX A Master File Notification (MFN) samples

APPENDIX B. Acronyms

APPENDIX C EXTERNAL SYSTEM TABLE

List of Figures Figure 2-1 Bi directional Message Flow Between CHCS and the External System

1 PURPOSE

This Defense Health Clinical Systems (DHCS) Interface Control Document (ICD) specifies the interface between the Composite Health Care System (CHCS) and external radiology systems. The purpose of this ICD is to clearly communicate all possible inputs and outputs from the system for all potential actions whether they are internal to the system or transparent to system users. This ICD is created during the Planning and Design Phases of the project. Its intended audience is the project manager, project team, development team, and stakeholders interested in interfacing with the system. This ICD helps ensure compatibility between system segments and components.

1.1 Overview

CHCS transmits Health Level 7 (HL7) messages to external systems to include: patient demographics, radiology orders, scheduling messages as well as radiology messages after the patient has ‘Arrived’ for the exam until a radiology result is completed/amended. CHCS also transmits Master File Notifications (MFNs) for User, Provider, Hospital Location, Radiology Procedure, and Result codes.

CHCS also provides the capability to process messages received from an external system to include radiology orders, queries for a specific exam number, radiology exam status updates, special interest codes and teaching codes, updates to patient registration data, radiology scheduling, patient appointments and radiology reports/amendments.

1.2 System Identification

This section identifies the systems participating in the interface, the contractors developing the systems, and the responsible Government Project Office.

1.2.1 CHCS

CHCS is an automated medical information system that supports health care administration and delivery at Department of Defense (DoD) Military Treatment Facilities (MTFs). These MTFs include hospitals, outlying medical clinics and selected outlying dental clinics. CHCS provides integrated information services to support patient care. The Patient Administration (PAD) Subsystem of CHCS provides registration, admission, discharge, and transfer functions. Medical record coding and bed management are also supported. Clinical, Pharmacy, Radiology and Laboratory subsystems provide order entry, order management and results reporting functionality.

The Generic Interface System (GIS) provides transaction-orientated information transfer and format processing to create, manage, and interpret HL7 messages flowing between CHCS and external systems.

1.2.2 External radiology systems

External radiology systems support the resulting of radiology exams. Such systems include the Digital Imaging Network – Picture Archiving Communication System (DIN- PACS) which are radiology imaging systems designed to acquire, transmit, display, and manage diagnostic imaging studies as well as systems that provide dictation services.

Note: Refer to the ICD CHCS-Dictaphone for specification related to messages triggered to PowerScribe from CHCS.

1.3 Document Overview

The purpose of this ICD is to define interface specifications to be met by the participating systems. It describes the concept of operations for the interface, defines the message structure and protocols which govern the interchange of data, and identifies the communication paths along which the data is expected to flow. The document is organized as follows:

Section 1.0 Purpose

Section 2.0 Concept of Operations

Section 3.0 Message Specifications

Section 4.0 Communication Requirements

Section 5.0 Verification

1.4 Applicable Documents

The following documents are applicable to the extent referenced in this document.

1. DoD Privacy Program, DoD 5400.11-R

2. DoD Freedom of Information Act (FOIA) Program, DoD 5440.7-R

3. DoD Directive 5200.28, Security Requirements for Automated Information Systems (AIS), 21 March 1988.

4. HL7 Standard, version 2.2, December 1, 1994, http://www.hl7.org/.

5. Simple Objects Access Protocol (SOAP) 1.1, W3C Note 08 May 2000, http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

6. Hypertext Transfer Protocol (HTTP) 1.0 and 1.1, W3C specification, http://www.w3c.org/Protocols/

7. MHS Automated Information System (AIS) Security Policy Manual, Version 1.0, April 1996

8. Consolidated Army/Navy/Air Force Requirements for a DIN-PACS/CHCS Bi-directional Interface January 15, 2002 http://www.hl7.org/ http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ http://www.w3c.org/Protocols/

9. Updated as Northrop Grumman/ Science Applications International Corporation (SAIC) Master Subcontract Agreement #S2834-01 CHCS Enhancements PO # 39747H, National Provider Identifier (NPI) Project 501200, Deliverable Item 4, D2-SP99-1000A 13 Oct 2006

10. AHLTA/CHCS Critical Fixes-Objective 4 Interface Control Document, CHCS Interface with Powerscribe (Dictaphone), SAIC GSA Doc. GS-ACCFS-3163, 02 Aug 2013

11. ACCFS Objective 4 CHCS RAD Enhancements Release Notes; Leidos GSA Doc. GS-ACCFS-6077 dated 14 Oct 2013

12. ACCFS Objective 4 CHCS RAD Enhancements Install Guide; Leidos GSA Doc.

GS-ACCFS-5030 dated 14 Oct 2013

13. Objective 4 RAD Enhancements Phase 3 Requirements Traceability Matrix (RTM), SAIC GSA Doc. GS-ACCFS-3161, 10 Jun 2013

14. AHLTA/CHCS Critical Fixes – Objective 4 Software Requirements Specification (SRS), Composite Health Care System (CHCS) Radiology Enhancements, Leidos GSA Doc. GS-ACCFS-3149, 14 Oct 2013

15. AHLTA/CHCS Critical Fixes-Objective 4 Software Design Document (SDD), CHCS Radiology Enhancements, Leidos GSA Doc. GS-ACCFS-3163, 14 Oct

2 Concept of Operations CHCS transmits HL7 v2.2 patient demographics, radiology orders, scheduling messages as well as radiology messages after the patient has ‘Arrived’ for the exam until a radiology result is completed/amended to external radiology systems. CHCS MFNs for User, Provider, Hospital Location, Radiology Procedure, and Result Category are also transmitted to the external system(s).

CHCS will process messages received from external radiology systems for radiology orders, exam status updates, queries for a specific exam number, radiology scheduling, patient appointments, as well as patient update and merge messages and radiology results as defined in the following sections. Figure 2-1 shows the bi directional message flow between CHCS and the External System

CHCS-External Radiology System Messaging

CHCS

DIN-PACS

Reg Updates (A31) Reg Merge (A30)

ORU/R01

Rad Messages

Exam Scheduling Exam Updates

Results

ORM/O01

Rad Orders

MFNs SCH

PAS

QRY/R02

ORF/R04

Exam Query & Response

Figure 2-1 Bi directional Message Flow Between CHCS and the External System.

2.1 Functional Allocation

A bi-directional interface will support the transmission of CHCS Patient Demographic, Radiology Order, Clinic and Radiology Schedule, Radiology 'Arrival', Radiology

'Encounter' and Radiology Result (reports and amendments) messages to the external system as well as the receipt of Radiology orders, exam status updates, queries for a specific exam number, radiology scheduling and patient appointment messages as well as results/amendments. CHCS MFNs for User, Provider, Hospital Location, Radiology Procedure, and Result Category will also be transmitted to the external system.

2.2 Interface Transactions

These systems will use two communication standards, Digital Imaging and Communications in Medicine (DICOM) and HL7 Version 2.2 or 2.3. CHCS will send master file data, patient data, radiology order, and exam and result information to radiology systems via messages formatted in accordance with HL7 version 2.2. The external system will send radiology result information to CHCS via messages formatted in accordance with HL7 version 2.2 or 2.3.

2.3 Data Transfer

This section specifies the communication requirements necessary to establish and maintain communications between CHCS and the external system. It includes requirements to be satisfied by CHCS, and by the external system when sending or receiving a message.

The interface between CHCS and the external system is established via a TCP/IP connection. Two TCP sockets provide bi-directional communications between the two systems. Systems may be configured with additional sockets as needed to support message traffic. When messages are sent from CHCS to the external system, the external system will be the server to which the CHCS will connect as a client. And when messages are sent from the external system to CHCS, CHCS will be the server to which the external system will connect as a client.

2.4 Security and Integrity

The interface between CHCS and external systems is used to send and receive sensitive but unclassified (SBU) information such as social security numbers and individual medical data. The data from the interface is subject to the provisions of the Privacy Act of 1974 and DoD Privacy Program, DoD 5400.11-R. Additionally, external data falls within the content of the Exemption Number 6 of the FOIA Program, DoD 5400.7-R. Both the DoD Privacy and FOIA programs mandate adequate data protection. The data from the interface is subject to P.L. 104-191, “Health Insurance Portability and Accountability Act of 1996 (HIPAA).”

Unauthorized creation, disclosure, modification, or destruction of this data could cause potential harm to patient health and privacy. The CHCS and the radiology reporting system interface must include safeguards that ensure its data is accurate, complete, and available when needed, to facilitate timely and appropriate patient care. Privacy Act and other sensitive information sent across the interface must also be protected against unauthorized disclosure to protect the privacy of the individuals on whom the information is maintained. The minimum security class determined by both CHCS and the external system is Mission Assurance Category (MAC) II. The MAC II level of protection also satisfies DoD requirements for protecting unclassified sensitive systems.

3 Message Specifications

3.1 HL7 Message Requirements

HL7 Message Requirements specify the triggers that cause each type of message to be sent and the system to which it is sent.

CHCS and the external system communicate via messages conforming to the HL7 Message Standard version 2.2 or 2.3, which provides a general framework for communications. This Interface Control Document explicitly specifies the required content of each message and the circumstances under which it is sent. The following paragraphs specify requirements for the exchange of HL7 messages.

The HL7 Standard is based on the assumption that a real world event, or trigger event, creates the need for data to flow among systems. For example, the trigger event "a patient is admitted" may require data about that patient to be sent to a number of other systems. When the information transfer is initiated by the application system that experiences the triggering event, the transaction is termed an unsolicited update.

A different data exchange occurs when one system sends a query to another. For example, a system may receive an order for a patient who does not exist in the receiving system's database. The receiving system may send a message with the patient's ID number requesting the patient data needed to process the order. This requesting transaction is a query, as distinguished from the unsolicited update. The information that flows between the systems is contained in the response. The response itself is not acknowledged with a third message.

The general concept of operations for both the unsolicited update and the query messages consists of a simple exchange of messages between a pair of systems: the unsolicited update and its acknowledgement, or the query and response. The following sections describe the underlying rules and requirements that are relevant to both the unsolicited update message interface and the query/response interface.

3.1.1 Unsolicited Update Messages Sent by CHCS to External

Systems

The following requirements specify the HL7 messages that are sent from CHCS to the radiology system. The format and content of these messages is defined in paragraph

3.2. Master File Notification Messages are specified in paragraph 3.1.2.

1. On trigger, CHCS shall send an HL DG ADMIT PATIENT (ADT/A01) message when a patient is admitted to the hospital.

2. On trigger, CHCS shall send an HL DG TRANSFER PATIENT (ADT/A02) message when a patient is transferred to a different ward in the hospital.

3. On trigger, CHCS shall send an HL DG DISCHARGE PATIENT (ADT/A03) message when the patient is discharged.

4. On trigger, CHCS shall send an HL DG UPDATE PATIENT (ADT/A08) message when the:

a. Patient Admission data is updated

b. Patient Transfer data is updated

c. Patient Discharge data is updated

d. Demographic Information is updated.

5. On trigger, CHCS shall send an HL DG CANCEL ADMIT (ADT/A11) message when the patient’s admission is cancelled.

6. On trigger, CHCS shall send an HL DG CANCEL TRANSFER (ADT/A12) message when the patient’s transfer order is cancelled.

7. On trigger, CHCS shall send an HL DG CANCEL DISCHARGE (ADT/A13) message when the patient’s discharge order is cancelled.

8. On trigger, CHCS shall send an HL DG ADD PERSON (ADT/A28) message when a new person is added.

9. On trigger, CHCS shall send an HL DG MERGE PATIENT (ADT/A30) message when duplicate patients are merged.

10. On trigger, CHCS shall send an HL DG UPDATE PERSON (ADT/A31) message when a person’s demographics are updated.

11. On trigger, CHCS shall send an HL OR RAD ORDER TSK (ORM/O01) message when a Radiology task is updated.

12. On trigger, CHCS shall send an HL RAD SCHEDULE (ORU/R01) message when the radiology procedure is:

a. Scheduled

b. Modified

c. Cancelled.

13. On trigger, CHCS shall send an HL RAD ARRIVAL (ORU/R01) message when the patient has arrived for the exam.

14. On trigger, CHCS shall send an HL RAD ENCOUNTER (ORU/R01) message when the exam status changes to:

a. Examined

b. Incomplete

c. Aborted

d. Exam Only.

15. On trigger, CHCS shall send an HL RAD RESULT (ORU/R01) message for:

a. Verified Radiology results

b. Amended Radiology results

c. Unverified Radiology report is released

d. Radiology exam reaches the Report Only status.

16. On trigger, CHCS shall send an HL RAD SPECIAL INT – TEACHING (ORU/R01) message when SPECIAL INTEREST or TEACHING codes are:

a. Added to a radiology exam report

b. Removed from a radiology exam report.

17. On trigger, CHCS shall send an HL PAS APPOINTMENT MESSAGE (SCH/S01) when:

a. An appointment is booked

b. A patient is checked in for an appointment

c. The appointment is cancelled

d. When the appointment is rescheduled as a new appointment after being cancelled.

**Configuration note: Schedule messages will be triggered if the Appointment Type for the Clinic has the setting for ‘Pull Radiology Record’ set to ‘Yes’.

APPOINTMENT TYPE: ACUT SD HCP PROFILE -- CONTINUATION

DURATION: 30 STATUS: ACTIVE

WORKLOAD TYPE: NON-COUNT REFERRAL REQUIRED: YES

PULL PATIENT RECORD: YES PULL RADIOLOGY RECORD: Yes

PRODUCE ENCOUNTER FORMS: YES SEND REMINDER NOTICE: YES

TOTAL # OF OVERBOOKS: MAX # OF OVERBOOKS PER SLOT:

INSTRUCTIONS:

Select BOOKING AUTHORITY:

Select APPT CHANGE AUTHORITY:

Select OVERBOOK AUTHORITY:

3.1.2 Unsolicited Master File Notification (MFN) Messages to External Systems

CHCS maintains a set of common reference files which are shared with several external systems. When a record in one of these files has been created or altered CHCS uses MFN messages to broadcast the changes. An alteration is defined as an update, deletion, deactivation or reactivation. The following requirements specify the HL7 MFN messages to be triggered.

Requirements:

1. On trigger, CHCS shall send the HL MASTER FILE NOTIFICATION MESSAGE (MFN/M01) when new entries and updates to existing entries for the following:

a. User

b. Result Category

c. Hospital Location

d. Provider

e. Radiology Procedures

f. Clinical Procedural Terminology (CPT)

g. Exam Status

h. Rad Repeat Reason

i. Special Interest Code

j. Film

k. Room

l. Imaging Type.

3.1.3 Unsolicited Radiology Messages Received by CHCS from

External Systems

This section will describe the requirements to support inbound processing of messages from the external system to CHCS to include:

1. HL RAD RESULTS - PACS

2. HL DG MERGE PATIENT - IN (PACS)

3. HL DG UPDATE PERSON - IN (PACS)

4. HL OR RAD ORDER ACK - PACS

5. HL OR RAD ORDER IN - PACS

6. HL PAS APPOINTMENT - IN

7. HL RAD APPL ACK - PACS

8. HL RAD EXAM QUERY IN

CHCS will respond to the HL RAD EXAM QUERY IN with HL RAD QUERY

RESPONSE OUT.

3.1.3.1 Radiology Result Requirements

The following requirements specify the v2.2 or 2.3 HL7 messages that are sent from the radiology reporting system (DIN-PACS or dictation system) to CHCS. The format and content of these messages is defined in paragraph 3.2.

Vendor ID Technical Requirements – Radiology Results

RAD_3.1.2.1 CHCS shall process a Radiology Result message received from an external system for a preliminary radiology report. [BAS782]

RAD_3.1.2.2 CHCS shall process a Radiology Result message received from an external system for a finalized radiology report. [BAS783]

RAD_3.1.2.3 CHCS shall process a Radiology Result message received from an external system for an amended radiology report. [BAS784]

RAD_3.1.2.4 CHCS shall respond with an application acknowledgement message to the external system when the Radiology Result is submitted successfully.

[BAS785]

RAD_3.1.2.5 CHCS shall respond with an application error message to the external system when the Radiology Result is not submitted successfully. [BAS786]

RAD_3.1.2.6 CHCS shall provide the capability to overwrite an existing Radiology Report in Preliminary status when a finalize radiology report is received from an external system. [BAS787]

RAD_3.1.2.7 CHCS shall process a transcribed report received from an external system.

[BAS790]

RAD_3.1.2.8 CHCS shall provide the capability to overwrite an existing 'Transcribed' radiology report upon receipt of a subsequent report from an external system Radiologist. [BAS791]

RAD_3.1.2.9 CHCS shall allow an authorized radiology provider to enter an amendment in CHCS for a radiology result that originated from an external system.

[BAS792]

RAD_3.1.2.10 CHCS shall be able to accept a completed radiology report amendment received from an external system for a radiology result that originated in

CHCS. [BAS793]

Note: PowerScribe cannot accept an Application Error (AE) or Application Accept (AA) message from CHCS. They can only acknowledge the Commit Ack (CA) sent from CHCS upon receipt of the ORU message.

3.1.3.2 Radiology Order Requirements

Functional description: CHCS shall process radiology messages received from an external system when:

1. A new radiology order is created

2. A radiology order is modified

3. A radiology order is cancelled.

Vendor ID Technical Requirements – Radiology Orders

6.3.2.18.13 CHCS shall provide the capability to support the processing of a message received from an external system for a new radiology order [BAS809].

6.3.2.18.14 CHCS shall provide the capability to support the processing of a message received from an external system for a radiology order that has been modified

[BAS810].

6.3.2.18.15 CHCS shall provide the capability to support the processing of a message received for a radiology order that has been cancelled [BAS811].

Assumptions:

1. CHCS will store the external system’s order number.

Vendor ID Technical Requirements – Exam Status Updates

6.3.2.18.16 CHCS shall provide the capability to support the processing of a radiology encounter message received from an external system for an exam status of Examined [BAS812].

6.3.2.18.17 CHCS shall provide the capability to support the processing of a radiology encounter message received from an external system for an exam status of Incomplete [BAS813].

6.3.2.18.18 CHCS shall provide the capability to support the processing of a radiology encounter message received from an external system for an exam status of Aborted [BAS814].

Vendor ID Technical Requirements – Exam Status Updates

6.3.2.18.19 CHCS shall provide the capability to support the processing of a radiology encounter message received from an external system for an exam status of Exam Only [BAS815].

6.3.2.18.20 CHCS shall provide the capability to support the processing of a radiology encounter message received from an external system for an exam status of Arrived [BAS816].

6.3.2.18.21 CHCS shall provide the capability to support the processing of a radiology encounter message received from an external system for an exam status of Ordered [BAS818].

6.3.2.18.22 CHCS shall provide the capability to support the processing of a radiology encounter message received from an external system for an exam status of Report Only [BAS819].

6.3.2.18.23 CHCS shall provide the capability for an external system to query for a radiology exam number for a specified patient [BAS172].

2. The external system will update their database upon receipt of new CHCS order requests or requests to modify or cancel the radiology order to allow for synchronization between CHCS and the external system.

3. The CHCS application acknowledgement (AA) will contain the CHCS order number and the external order number.

4. CHCS will only activate orders entered by a Nurse Class or Health Care Provider (HCP) class user from an external system. CHCS will reject orders if placed by a Clerk class user.

5. If an order message is received for a patient that is not registered on CHCS, the message will be rejected. The patient will not be registered as a result of receiving an order message.

3.1.3.3 Radiology Exam Status Update Requirements

Functional Description: CHCS shall provide the capability to process radiology exam status update messages from external systems for a status of:

1. Aborted

2. Arrived

3. Examined

4. Exam Only

5. Incomplete

6. Ordered

7. Report Only.

CHCS shall provide the capability for the external system to query for an exam number.

3.1.3.4 Radiology Scheduling Requirements

Functional Description: CHCS shall provide the capability to process radiology schedule messages received from an external system when the procedure is:

1. Scheduled

2. Modified

3. Cancelled.

Vendor ID Technical Requirements – Radiology Scheduling

6.3.2.18.24 CHCS shall provide the capability to support the processing of a radiology schedule message received from an external system for a procedure status of Scheduled [BAS820].

6.3.2.18.25 CHCS shall provide the capability to support the processing of a radiology schedule message received from an external system for a modification to the scheduled procedure [BAS821].

6.3.2.18.26 CHCS shall provide the capability to support the processing of a radiology schedule message received from an external system for the appointment cancellation of a scheduled exam [BAS822].

6.3.2.18.48 CHCS shall provide the capability to set a flag for "External Appointing only" in the Radiology room profile. [BAS172]

6.3.2.18.49 CHCS shall provide the capability to exclude Radiology rooms defined as "External scheduling only" from CHCS scheduling [BAS172]

6.3.2.18.50 CHCS shall provide the capability to exclude Radiology rooms define as "External scheduling only" from CHCS schedule maintenance. [BAS172]

1. Radiology Scheduling will be managed either from the Ext System or CHCS.

Synchronization issues may occur if radiology scheduling occurs in both systems.

2. An active CHCS order must exist before a Radiology exam can be scheduled.

3. When the external system is performing radiology scheduling then the external system will be responsible for:

a. Appointment Conflict management

b. Any End of day duties

c. Cross division scheduling

d. Radiology scheduling reports.

4. If an incoming patient Radiology appointment is in direct conflict or in close proximity with an existing appointment on CHCS, CHCS will allow the Radiology appointment to be stored.

Business Rules:

1. CHCS File and Table configuration is required to set the Rad Room to ‘EXTERNAL SCHED ONLY’ if External Scheduling is used.

2. If ‘EXTERNAL SCHED ONLY’ is set to YES then:

a. CHCS Radiology Room schedule maintenance is not required to process schedule messages from the External System.

b. Exams can be scheduled from an external system to Radiology Rooms not assigned to the exam.

2. If ‘EXTERNAL SCHED ONLY’ is left blank and the External System sends an appointment request for a Radiology Room, CHCS will allow the appointment to be scheduled if existing CHCS Business Rules are met to include the following:

a. The Radiology procedure must be assigned to the CHCS Radiology room.

b. Radiology schedules must be built and maintained in CHCS for the

Radiology room.

c. An open appointment slot must exist in CHCS for the requested date/time.

3.1.3.5 Special Interest/Teaching Codes Requirements

Functional Description: CHCS shall provide the capability to process messages received from an external system when special interest/teaching codes are added or removed from a radiology exam report.

DOORS ID Functional Requirements – Special Interest/Teaching Codes

BAS794 CHCS shall process a radiology special interest/teaching code message received from an external system when special interest or teaching codes are added to a radiology exam report.

BAS795 CHCS shall process a radiology special interest/teaching code message received from an external system when special interest or teaching codes are removed from a radiology exam report.

The following technical requirements are derived from the functional requirements.

Vendor ID Technical Requirements – Special Interest/Teaching Codes

6.3.2.18.7 CHCS shall provide the capability to support the processing of special interest codes associated with a Radiology Result message received from an external system [BAS794].

6.3.2.18.8 CHCS shall provide the capability to support the processing of teaching code(s) associated with a Radiology Result message received from an external system [BAS794].

6.3.2.18.9 CHCS shall provide the capability to remove special interest codes associated with a Radiology Result message received from an external system

[BAS795].

6.3.2.18.10 CHCS shall provide the capability to remove teaching codes associated with a Radiology Result message received from an external system [BAS795].

1. The external system’s Special Interest file will be in synch with CHCS.

2. Teaching codes sent from the external system must match the CHCS Teaching code description to be added or deleted.

3.1.3.6 Patient Update & Merge Requirements

Functional Description: CHCS shall provide the capability to process messages received from an external system when:

1. The duplicate patients are merged (ADT/A30)

2. The person’s demographics are updated (ADT/A31)

Vendor ID Technical Requirements – Patient Update & Merge

6.3.2.18.11 CHCS shall provide the capability to support the processing of a merge patient message from an external system when duplicate patients are merged

[BAS807].

6.3.2.18.12 CHCS shall provide the capability to support the processing of an update person message from an external system when the person’s demographics are updated [BAS808].

1. CHCS will ignore a merge patient message from an external system when neither or both the duplicate patient and correct patient are not found on CHCS.

2. CHCS will generate a duplicate patient bulletin when both the duplicate and correct patient are found on CHCS.

3. CHCS will continue to follow the existing manual patient merge process.

4. CHCS does not support an unmerge patient capability. Unmerging of patients merged in error will require Tier 3 support to resolve.

5. CHCS will not process person updates for demographic fields that are synchronized between CHCS and Defense Enrollment Eligibility Reporting System (DEERS).

6. The external system will include a date/time stamp for address updates.

7. CHCS will not process address updates unless the date/time stamp is more recent than the CHCS update.

3.1.3.7 Patient Appointment Scheduling (PAS) Requirements

The RAD Enhancements project contains four requirements to support external system appointing for clinics outside the radiology department. In conversations, the external system representatives have said that they sometimes work closely with other clinics (for example, cardiology) where it is appropriate to set appointments for both radiology and another clinic in close proximity or as a sequence of events.

To fully support these four requirements, additional work must be done on CHCS.

In broad terms, this includes adding a new Location Type (E = External Booking) to the set of codes defined in the Hospital Location file to indicate the scheduling and appointing will be handled by an off board system and then referencing that location type for typical appointing functionality such as end of day processing, cancellation and no-show processing, wait list processing, and multiple reports.

Vendor ID Technical Requirements – Patient Appointment Scheduling

6.3.2.18.27 CHCS shall provide the capability to support the processing of an appointment message received from an external system when an appointment is booked [BAS823]

6.3.2.18.28 CHCS shall provide the capability to support the processing of an appointment message received from an external system when an appointment is checked in for an appointment [BAS824]

6.3.2.18.29 CHCS shall provide the capability to support the processing of an appointment message received from an external system when an appointment is cancelled [BAS825]

6.3.2.18.30 CHCS shall provide the capability to support the processing of an appointment message received from an external system when an appointment is rescheduled as a new appointment after being cancelled

[BAS826]

6.3.2.18.31 CHCS shall provide the capability to support the processing of an appointment message received from an external system when an appointment is marked as “left without being seen” [BAS172]

6.3.2.18.32 CHCS shall provide the capability to support the processing of an appointment message received from an external system when an appointment is marked as a “no show” [BAS172]

Assumptions:

1. Messages will be received in real time and not as an end of day batch.

2. The external system will receive Master File Notifications for the Clinic and will use the necessary identifying data elements (at a minimum, clinic name, division, DMIS ID, and internal entry number [IEN]) in incoming messages.

3. The external system will receive Master File Notifications for the Provider and will use the necessary identifying data elements (at a minimum, provider name and electronic data interchange person identifier [edi_pn]) in incoming messages.

4. Either the external system or CHCS will be responsible for the appointments and scheduling in a clinic; there will be no effort made to synchronize schedule slots available for booking between the two systems. This will include Emergency Room visits and Unscheduled Visits (Walk in, Sick Call, T-Con).

5. Off board systems will not send schedule slot data to CHCS for maintenance.

6. End of Day Processing will be performed by the external system, as needed.

7. The access to care standards will be supported. For example, patients with an acute care need should be seen within 24 hours. The ATC standards are presented in Section 6.7.7 of the AHLTA/CHCS Critical Fixes-Objective 4 Software Design Document (SDD), CHCS Radiology Enhancements dated 10 Jun 2013.

8. If a clinic or a provider within the clinic becomes unavailable after the appointment has been booked, it will be up to the off board to notify the patient and reschedule the appointment. (CHCS Notify Patient software module cannot be run for off board system data.)

9. If an appointment message is received for a patient that is not registered on CHCS, the message will be rejected. The patient will not be registered as a result of receiving an appointment message.

10. If a cancelled appointment message is received, and there is no booked appointment in the CHCS database, the cancelled appointment will still be accepted and recorded in the patient appointment file. If the cancelled appointment does not have a clinic defined and there is no existing appointment on CHCS to match with, the cancelled appointment will be rejected.

11. Access To Care Reporting will not be available on CHCS for clinics whose booking occurs on the external system as there will be no way to measure the availability of the slots to which the patient could have been booked.

12. Wait List Management will not be available for clinics with external system appointing.

13. Appointment Utilization will not be available for clinics with external system appointing.

14. Workload Reporting will be done via existing CHCS functionality. CHCS will use the appointment status data provided by the external system to determine workload. Data will be cascaded to other off board systems as appropriate as part of normal CHCS operations.

15. If workload cannot be derived because some clinic data is still in a delinquent end of day status, that information will be communicated to the external system for resolution. This will be handled as a manual business practice.

16. If an incoming patient appointment is in direct conflict or in close proximity with an existing appointment on CHCS, CHCS will allow the appointment to be stored.

PCM booking is out of scope for this project and will be maintained on the CHCS platform.

17. Referral booking is out of scope for this project

18. The external system will establish a protocol to determine patient eligibility.

19. CHCS will accept incoming PAS appointments for patients across all divisions. It is assumed that the user booking the appointment has the authority to do so.

20. CHCS will include appointments to clinics whose appointments were set by external booking facilities in the Audiocare reporting software designed to notify patients of appointments.

21. TRICARE online (TOL) users will not be able to book to clinics with external clinic appointing. CHCS will not have searchable slots to book for those clinics.

Business Rules:

1. The standard appointment statuses Pending, Kept, Cancelled, Left Without

Being Seen (LWOBS) and No-Show will be supported by the external system.

2. The standard appointment types will be supported by the external system. At a maximum, these will include Acute (ACUT), APV, Established (EST), Group (GRP), Open Access Appt (OPAC), Primary Care Manager (PCM), Procedure (PROC), Routine (ROUT), Specialty (SPEC), and Wellness (WELL), Telephone Consult (T-CON) and Emergency Room (EROOM). As appropriate to external clinic business, a subset of these appointment types may be used. Appointment types not included in the CHCS Appointment Type file will not be used.

3. On CHCS, the Provider Network File and Table will not include external system booking hospital locations as Places of Care; Providers will not be maintained in Groups for external system booking hospital locations.

4. AHLTA users will not be able to schedule appointments to clinics with external clinic appointing, however walk in appointments will be supported

3.2 HL7 Message Definitions

A message is the atomic unit of data transferred between systems. It consists of a group of segments in a defined sequence. Each message has a message type that defines its purpose. For example the Admission Discharge and Transfer (ADT) message type is used to transmit portions of a patient's ADT data from one system to another. A three-character code contained within each message identifies its type. All message types and trigger event codes beginning with the letter "Z" are reserved for locally defined (custom) messages. No such codes are defined within the HL7 Standard.

Each message is defined in special notation that lists the segment identifiers (IDs) in the sequence they would appear in the message. Braces and brackets are used to indicate that individual segments or groups of segments are optional or may repeat.

Braces { } The enclosed group of segments may repeat one or more times

Brackets [ ] The enclosed group of segments is optional

If a group of segments is optional and may also repeat it should be enclosed in both brackets and braces. Note that [{...}] and {[...]} are equivalent.

The following message specifications identify the segments included in each of the requirements stated above. Messages are arranged in alphabetical order.

3.2.1 Segment and Field Definitions

A segment is a logical grouping of data fields. An HL7 data field is an American Standard Code for Information Interchange (ASCII) character string. Fields of a segment may be required or optional. They may occur only once in a segment or they may be allowed to repeat.

Each segment is given a name. For example, the ADT message may contain the following segments: Message Header (MSH), Event Type (EVN), Patient ID (PID), and Patient Visit (PV1).

• Each segment is identified by a unique three-character code known as the Segment ID.

• All segment ID codes beginning with "Z" are reserved for locally defined (custom) segments. No such codes are defined within the HL7 Standard.

All messages originating from CHCS are fully populated with data. This also is true for update messages. If only one field in a message is actually being updated, the rest of the fields in the message still are populated. This paragraph contains segment attribute tables describing the data fields in each segment and the characteristics of their usage.

Segment Attribute Table Format

Seq Element Name Len DT Req RP# Description

Seq - Position (sequence within the segment): Ordinal position of the data field within the segment. This number is used to refer to the data field in the text comments that follow the segment definition table.

Element Name: Globally unique descriptive name for the field.

Len - Maximum Length: Max number of characters that one occurrence of the data field may occupy. The maximum length is not of conceptual importance in the abstract message or the HL7 coding rules. However, in general practice the maximum length is often negotiated on an interface-specific basis. It is calculated to include the component and sub-component separators. Because the maximum length is that of a single occurrence, the repetition separator is not included in calculating the maximum length.

DT - Data Type: Restrictions on the contents of the data field. There are a number of data types defined by HL7 as defined in Section 3.2.2.

Req – Required: Whether the field is required. (R = Required; O = Optional)

RP#- Repetition: Whether the data field may repeat. (Yes or No)

Description: High-level description of the contents of the field.

Omitting an optional field is not equivalent to a null value in that field. CHCS will follow the HL7 convention of representing null values as double quotes (“”) for required fields, but not optional fields except as noted in the Segment Attribute Tables.

3.2.2 Data Type Definitions

CHCS uses the backslash (\) as the component delimiter (as specified in the Encoding Characters in the MSH segment) for all outbound messages. For simplicity, the "\" is used throughout this document as the component delimiter. For inbound messages, each system will parse on the component delimiter specified by the Encoding Characters in the MSH segment. In this document, angle brackets (< >) enclose the components of the data type to indicate that a value is to be inserted at that point and is not included in the data type.

AD - Address <street address> \ <other designation> \ <city> \ <state or province> \ <zip> \ <country> \ <type> \ <other geographic designator>

CHCS may populate the State field with geographic locations other than states or provinces. CHCS will accept two letter codes for State name, but will send full geographic location names. Zip may be either five or nine digits (this is a deviation from the HL7 Standard). If null, Country is United States. All components are ST data type (Street Address and Other Designations). Fields may include encoding characters such as |, ~, or &.

CE - Coded Element

Transmits a code and associated text. Six components arranged in two groups.

<identifier> \ <text> \ <name of coding system> \ <alternate identifier> \ <alternate text> \ <name of alternate coding system>

Where Identifier is a sequence of characters (the code) that uniquely identifies the item being referenced in text. Text provides the name or description of the item in question.

May include encoding characters such as |, ~, or &. Name of coding system provides a unique identifier for the coding system. This component identifies the coding scheme used in the identifier component. The combination of the identifier and name of coding system components establishes a unique reference for the data item.

CK - Composite ID with check digit <ID number (NM)> \ <check digit (NM)> \ <check digit scheme (ST)>\ <assigning facility ID

(ST)>

Check digit and check digit scheme are not implemented. The Assigning Facility ID equates to the CHCS MTF code.

CM - Composite

A field that is a combination of other data fields. Each portion is a component. (Specific components are defined within the field description.)

CN - Composite ID

Composite ID number & name. Prefix and degree components are not used.

<ID Number> \ <family name> \ <given name> \ <middle initial or name> \ <suffix> \ \ \ <source table>

CQ - Composite Quantity

Composite Quantity with units. Default units may be defined within specifications by field.

<quantity> \ <units>

DT - Date

YYYYMMDD

Eight (8) digits where YYYY = year; MM = month; and DD = day. Imprecise Dates are indicated by DD = 00 and MMDD = 0000. Valid imprecise dates are YYYY0000 and

YYYYMM00.

ID - Coded value.

Formatting same as ST but drawn from a table of legal values such as rank, religion or gender.

MO - Money <quantity> \ <denomination>

If null, denomination is US dollars.

NM - Numeric

Optional leading sign (+ or -). Optional decimal point. No non-numeric American Standard Code for Information Interchange (ASCII)

PN - Person Name <family name> \ <given name> \ <middle initial or name> \ <suffix> \ <prefix> \ <degree>

Maximum Length = 48 characters including component separators.

SI - Sequence ID

Positive integer in form of an NM field.

ST - String Data.

Left justified. Trailing blanks optional. Displayable ASCII characters. May contain encoding characters such as \, |, ~, or &.

TM - Time

HHMM[SS]

Where HH = hour; MM = minute; and SS = second. Seconds are optional. Midnight may be represented as either 2400[00] or 0000[00] -- this is a deviation from the HL7 Standard. Times from 000001 through 000059 may transform to 000100 by the receiving application.

TN - Telephone number.

CHCS does not export data in the TN data type. Outgoing telephone numbers are transmitted as ST data types. Incoming "TN" data is interpreted as a ST data types and stored verbatim.

TQ - Quantity/Timing

Used for ORC-7 and OBR-27 segments. Describes when and how frequently a service should be performed. The TQ data type is explained in Section 4.4 of the HL7 2.2 standard.

<quantity> \ <interval> \ <duration> \ <start date/time> \ <end date/time> \ <priority> \ <condition> \ <text> \ <conjunction> \ <order sequencing>

The quantity/timing field has ten components:

Seq Len Fmt Opt Component Name

1 3 NM O Quantity

2 60 CM R Interval

3 10 CM O Duration

4 14 TS R Start date/time

Seq Len Fmt Opt Component Name

5 14 TS R End date/time

6 2 CE O Priority

7 60 ST O Condition

8 60 ID O Text description

9 10 CM O Secondary timing or conjunction component

10 10 CM O Order sequencing

Quantity This component specifies the number of tablets, capsules, etc. of the drug to administer at each scheduled time. If omitted, the assumed quantity is 1.

Interval provides the frequency and administration times with three subcomponents in format:

<unexpanded times>&<administration times>&<frequency>

Example: QID&0600-1200-1800-2400 or &0800&QD

The Duration component indicates how long the service should continue after it is started. The default is INDEF (do indefinitely). This component is coded as follows:

Value Description

S<number> Order is active for <number> Seconds

M<number> Order is active for <number> Minutes

H<number> Order is active for <number> Hours

D<number> Order is active for <number> Days

W<number> Order is active for <number> Weeks

L<number> Order is active for <number> Months

X<number> Order is active for the interval specified <number> in the order

T<number> Order is active at the interval and amount stated until a total of <number> dosage is accumulated. Units are defined in the Quantity component

INDEF Order is active indefinitely

Start Date/Time and End Date/Time provide the start and expiration date/time of order in Time Stamp (TS) format

The Priority of the order is chosen from the following values:

S = STAT,

R = Routine, T = Notify/Routine, A = As Soon As Possible (ASAP), P = Preop

Additional Text for the order is in ST format

The Condition, Conjunction and Order Sequencing components are not used.

TS - Time Stamp:

<Date/Time> \ <degree of precision>

The Date/Time is in the format YYYYMMDD[HHMM[SS]]. Imprecise Date/Time may be explicitly declared by using the optional second component, inferred from the field length or inferred from zero values. An Imprecise Date is indicated by DD = 00 or MM = 00. If provided, HHMMSS in imprecise dates must be 000000.

The optional Degree of Precision is chosen from the following values Y = year, L = month, D = day, H = hour, M = minute and S = second.

Midnight may be represented as YYYYMMDD240000 or YYYYMMDD000000.

3.3 CHCS Messages to External Systems

NOTE: No Protected Health Information (PHI) / Personal Identifying Information (PII) appears in any of the sample HL7 messages in this document.

3.3.1 ADT/A01 - HL DG ADMIT PATIENT

Segme…