ACCFS1125_Item_16_ICD_Obj4_CHCS-Radiology_20131031.pdf

Leidos GSA Doc. GS-ACCFS-1125 31 Oct 2013

INTERFACE CONTROL DOCUMENT (ICD)

Composite Health Care System (CHCS) Interface with External Radiology/Dictation Systems

Submitted in Response to:

GSA Contract GS00Q09BGD0048 Delivery Order GST0311DS8011

AHLTA & CHCS Critical Fixes and Support (ACCFS) Deliverable Item 16

For:

Electronic Health Record (EHR) Core Program Management Office (PMO)

Ms. Lorri A. Bovain, DoD, ACCFS (Gov) Product Line Manager 5109 Leesburg Pike, Sky 6, Suite 508 Room 49 Falls Church, VA 22041

703-882-3853 Ibrahiim Kent, GSA Contract Officer’s Representative (COR), (703) 605-9539

By:

Leidos

Health Solutions Group 5203 Leesburg Pike, Suite 1300

Falls Church, VA 22041 Karla Klussendorf, Program Manager, Phone: (703) 575-5935

Dawn Cisneros, Product Manager, Phone: (858) 826-5049 ii

Record of Changes

This record is maintained throughout the life of the document and summarizes the changes between approved versions of this document. Each new version of the document submitted for approval receives a sequential revision number. The old paragraph will designate the paragraph number and title where the information existed in the previous document if applicable. The revision comments will contain an explanation of the changes made and any new paragraph number and title if needed.

Revision

No.

Old Paragraph Revision Comments

-- D/SIDDOMS Contract DASW01-98-D-0032

Delivery Order 0032, FY99 CHCS Special Projects, Deliverable Item 01

D2-SP99-1000, 10 Jan 2000.

(Deliverable originally required under DO 023, CHCS/DIN-PACS Unidirectional Interface Phase I Completion, Deliverable Item 02, Interface Control Document).

A 3.2.2.59 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 Summary of changes:

Modification to MFN 01 ZMP Segment to include NPI Fields.

Added NPI field numbers (#8153 and 8154) from Provider file.

B 3.2.1.13

3.2.1.14

3.2.2

3.2.2.33

Appendix B

Section 5 Verification

DO 0018 Federal Health Information Exchange (FHIE)-Bi Directional Health Information Exchange (BHIE) Legacy Support, D2-SP99-1000B, 02 Aug 2010.

Summary of changes:

3.2.1.13: Added the ZPI segment to the Rad Order Task message to include the patient’s Defense Eligibility Enrollment Record System (DEERS) Electronic Data Interchange – Patient Number (EDIPN).

3.2.1.14: Added the NTE to include the Reason for exam in the Rad Arrival message as well as the patient’s EDIPN.

Note: A vendor requesting the above changes will need to request CHCS-SS_35186-4630-1.0

3.2.2: Removed CHCS specific file, field and Data Dictionary (DD) location information from all Segment tables.

Consolidated tables as needed.

3.2.2.33: Modified ZMP to include NPI values

Appendix B: Acronym page added

Section 5 Verification removed from document

C Updates in red

2.1 Updated Functional Allocation

2.2 Updated Interface Transactions

3.1 Updated HL7 Requirements

3.1.2 New inbound result

requirements

ACCFS1101_Item 16_Obj4_CHCS-Radiology-ICD; GSA Contract GS00Q09BGD0048, Delivery Order GST0311DS8011 AHLTA & CHCS Critical Fixes and Support (ACCFS) Aug 19 2011

Summary of changes: Replaced DIN-PACS with Radiology reporting systems or external systems to include dictation systems.

iii

Revision No.

Old Paragraph Revision Comments

3.2.1.1 New inbound message

structure

3.2.2.15 Updated OBR

3.2.2.16 Updated OBX

3.2.2.51 Updated ZRR

4.3 New radiology reporting

system to CHCS Radiology Resulting

D Updates to sections:

3.1.2 Updated requirements

3.2.4.9 Updated OBR segment

4.3 New radiology reporting

system to CHCS Radiology Resulting

ACCFS1101_Item 16_Obj4_CHCS-Radiology-ICD; GSA Contract GS00Q09BGD0048, Delivery Order GST0311DS8011 AHLTA & CHCS Critical Fixes and Support (ACCFS) Oct 2011

Summary of changes: Replaced DIN-PACS with Radiology reporting systems or external systems to include dictation systems.

E 1.1.2 Edits to the section

3.1.2 Added new section

3.1.3 Added BAS requirements

3.2.1 Deleted sample messages

3.2.1.1 Added Rad Ack

3.2.3 Moved Data type ahead of

the segment definitions

3.2.4.16 Updated OBX segment

4.3 Updated section

ACCFS1101_Item 16_Obj4_CHCS-Radiology-ICD; GSA Contract GS00Q09BGD0048, Delivery Order GST0311DS8011 AHLTA & CHCS Critical Fixes and Support (ACCFS) Dec 2011

F 02/03/2012:

Section 3.2.4.3 and 3.2.4.19 Added value ‘I0’ for Sequence 2.

Updated Sequence 3.

GSA Contract GS00Q09BGD0048 Delivery Order GST0311DS8011 AHLTA & CHCS Critical Fixes and Support (ACCFS), ICD-10 Project, Deliverable Item 16, GS-ACCFS-1101, 01 Feb

G 04/25/2012:

The ICD-10 project only updated that portion of the Interface Control Document that was impacted by this project. Parts of this ICD may be out-of-date.

If the mandated ICD-10 implementation date is extended beyond 01 October 2013, the ICD- 9 codes will be inactivated on the implementation date and the ICD- 10 codes will become active on that same date

Section 3.2.4.3: Clarified Sequence 2 for the implementation date. Clarified description for

GSA Contract GS00Q09BGD0048 Delivery Order GST0311DS8011 AHLTA & CHCS Critical Fixes and Support (ACCFS), ICD-10 Project, Deliverable Item 16, GS-ACCFS-1101, 01 Feb iv

Revision No.

Old Paragraph Revision Comments

Sequence 3 and 4.

Section 3.2.4.19: Clarified Sequence 2 for the implementation date. Clarified Sequence 3.

H Section 3.1.1: Added clarification for file and table required to trigger the SCH message.

Section 3.2.1 Removed ZPX from A08; Removed AL1 from A31

ACCFS1101_Item 16_Obj4_CHCS-Radiology-ICD; GSA Contract GS00Q09BGD0048, Delivery Order GST0311DS8011 AHLTA & CHCS Critical Fixes and Support (ACCFS) June 2012

I Added Exam Query/Response sections; added incoming SCH, ADT A30/A31 descriptions

GSA Contract GS00Q09BGD0048 Delivery Order GST0311DS8011 AHLTA & CHCS Critical Fixes and Support (ACCFS), Radiology Enhancements, Deliverable Item 16, SAIC GSA Doc.

GS-ACCFS-1125, 12 Oct 2012

J Update to Exam Query/Response

Update to table 3.4.5 Message type change to meet HL7 standards Corrected to correspond to outgoing message specification

GSA Contract GS00Q09BGD0048 Delivery Order GST0311DS8011 AHLTA & CHCS Critical Fixes and Support (ACCFS), Radiology Enhancements, Deliverable Item 16, SAIC GSA Doc.

GS-ACCFS-1125, 20 Nov 2012

K Updates to Section 1.4, Section 2.1 and Figure 2-1; Section 3.1.3.2 Assumptions; Section 3.1.3.4 Assumptions and Business Rules;

3.1.3.7, Assumptions and Business Rules.

Updates to Sections 3.2.2; 3.3; 3.4 (Added sample messages); 3.5.

Added Appendix C – Ext Sys table

GSA Contract GS00Q09BGD0048 Delivery Order GST0311DS8011 AHLTA & CHCS Critical Fixes and Support (ACCFS) Deliverable Item 16 for AHLTA & CHCS Critical Fixes and Support (ACCFS) – Objective 4 CHCS RAD Enhancements, GS- ACCFS-1125, 10 Jun 2013

L Section 1.4 References updated

Section 3.4.1.3 – Added Order Warning Descriptions

Section 3.1.3.7 – Removed reference to Minutes of Service;

moved AHLTA assumption to business rule

GSA Contract GS00Q09BGD0048 Delivery Order GST0311DS8011 AHLTA & CHCS Critical Fixes and Support (ACCFS) Deliverable Item 16 for AHLTA & CHCS Critical Fixes and Support (ACCFS) – Objective 4 CHCS RAD Enhancements, GS- ACCFS-1125, 19 Aug 2013

M Section 3.1.3.4, 3.1.3.7 – Clarified conflict management assumptions

Find and replaced DHIMS with

DHCS

GSA Contract GS00Q09BGD0048 Delivery Order GST0311DS8011 AHLTA & CHCS Critical Fixes and Support (ACCFS) Deliverable Item 16 for AHLTA & CHCS Critical Fixes and Support (ACCFS) – Objective 4 CHCS RAD Enhancements, GS- ACCFS-1125, 20 Sep 2013

N Updates to Section 3.1.3 and 3.4:

Listed the new inbound transaction types

GSA Contract GS00Q09BGD0048 Delivery Order GST0311DS8011 AHLTA & CHCS Critical Fixes and Support (ACCFS) Deliverable Item 16 for AHLTA & CHCS Critical Fixes and Support (ACCFS) – Objective 4 CHCS RAD Enhancements, GS- ACCFS-1125, 14 Oct 2013 v

Revision No.

Old Paragraph Revision Comments

O Updated Section 2.4 GSA Contract GS00Q09BGD0048 Delivery Order GST0311DS8011 AHLTA & CHCS Critical Fixes and Support (ACCFS) Deliverable Item 16 for AHLTA & CHCS Critical Fixes and Support (ACCFS) – Objective 4 CHCS RAD Enhancements, GS- ACCFS-1125, 31 Oct 2013 vi

Table of Contents Section Page

1. PURPOSE 1

1.1. OVERVIEW 1

1.2. SYSTEM IDENTIFICATION 1

1.2.1 CHCS

1.2.2 External radiology systems

1.3. DOCUMENT OVERVIEW 1

1.4. APPLICABLE DOCUMENTS 2

2. CONCEPT OF OPERATIONS 2

2.1. FUNCTIONAL ALLOCATION 3

2.2. INTERFACE TRANSACTIONS 3

2.3. DATA TRANSFER 3

2.4. SECURITY AND INTEGRITY 4

3. MESSAGE SPECIFICATIONS 4

3.1. HL7 MESSAGE REQUIREMENTS 4

3.1.1 Unsolicited Update Messages Sent by CHCS to External Systems

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

3.1.3 Unsolicited Radiology Messages Received by CHCS from External Systems

3.2. HL7 MESSAGE DEFINITIONS 14

3.2.1 Segment and Field Definitions

3.2.2 Data Type Definitions

3.3. CHCS MESSAGES TO EXTERNAL SYSTEMS 19

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

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 ORU/R01 – HL RAD SCHEDULE

3.3.17 ORU/R01 – HL RAD SPECIAL INT – TEACHING

3.3.18 SCH/S01 - HL PAS APPOINTMENT MESSAGE

3.4. EXTERNAL SYSTEM MESSAGES TO CHCS 26

3.4.1 Radiology Order Messages

3.4.2 Radiology Exam Query (QRY/R02)

3.4.3 Radiology Exam Query Response (ORF/R04)

3.4.4 Radiology Exam Status Updates (ORU/R01)

3.4.5 Radiology Scheduling Messages (ORU/R01)

3.4.6 Radiology Results (ORU/R01)

3.4.7 Patient Update/Merge Messages

3.4.8 Patient Appointment Scheduling (PAS) Messages

3.5 SEGMENTS AND FIELDS 59

3.5.1 AIP Appointment Information – Personnel Resources

3.5.2 AL1 Allergy Information

3.5.3 DG1 Admission Diagnosis

3.5.4 DSC Continuation Pointer

vii

3.5.5 ERR Error

3.5.6 EVN Event Type

3.5.7 IN1 Insurance Information

3.5.8 IN2 Additional Insurance Information

3.5.9 MFE Master File Entry

3.5.10 MFI Master File Identification

3.5.11 MRG Patient Merge Information

3.5.12 MSA Message General Acknowledgement

3.5.13 MSH Message Header

3.5.14 NK1 Next of Kin

3.5.15 NTE Notes and Comments

3.5.16 OBR Observation Request

3.5.17 OBX Observation Result

3.5.18 ORC Common Order

3.5.19 PID Patient Identification

3.5.20 PR1 Procedures

3.5.21 PV1 Patient Visit Information

3.5.22 PV2 Additional Patient Visit Information

3.5.23 SCH Schedule Appointment Information

3.5.24 STF Staff Identification

3.5.25 QRD Query Definition

3.5.26 QRF Query Filter

3.5.27 ZIN OHI Information

3.5.28 ZL1 Rad CPT Workload Data

3.5.29 ZM1 Rad Procedure Information

3.5.30 ZM7 User’s Allowable Divisions

3.5.31 ZMB Provider Specialty

3.5.32 ZMH MFN Hospital Location Appointment Type

3.5.33 ZMK MFN CPT/HCPCS

3.5.34 ZML MFN Hospital Location

3.5.35 ZMP MFN Additional Provider Info

3.5.36 ZMU MFN USER

3.5.37 ZN9 CPT/HCPCS MODIFIERS

3.5.38 ZNN Radiology Room

3.5.39 ZNR Radiology Procedure Synonym

3.5.40 ZOO Custom Override Warning

3.5.41 ZOR Custom Clinical

3.5.42 ZOW Order Warning

3.5.43 ZPE Patient Care Manager (PCM) Information

3.5.44 ZP1 CIS Additional Patient Information

3.5.45 ZPI Additional Patient Information

3.5.46 ZPS Sponsor

3.5.47 ZPX HL CP ZPX XTRA PAT INFO

3.5.48 ZRA Arrival Information

3.5.49 ZRC Rad Appointment Cancellation Reason

3.5.50 ZRD Rad Result Teaching Code

3.5.51 ZRE Radiology Encounter Information

3.5.52 ZRF Radiology Film

3.5.53 ZRL Special Interest Codes

3.5.54 ZRR Additional Rad Result Information

3.5.55 ZRS Additional Rad Schedule Information

3.5.56 ZRT Radiology Repeat Reason

3.5.57 ZSC PAS Custom Appointment/Scheduling

4 COMMUNICATION REQUIREMENTS 86

4.1 INTERFACE INITIATION 86

4.2 FLOW CONTROL 87

4.3 EXTERNAL SYSTEMS TO CHCS FOR RADIOLOGY RESULTING 88

viii

4.4 ERROR MANAGEMENT 90

4.5 SECURITY FEATURES 91

APPENDIX A. MASTER FILE NOTIFICATION (MFN) SAMPLES 92

APPENDIX B. ACRONYMS 94

APPENDIX C. EXTERNAL SYSTEM TABLE 97

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

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 2013

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.

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 specifies which triggers cause which messages to be sent to which systems.

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]

Vendor ID Technical Requirements – Radiology Results 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) orApplication 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.

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.

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].

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

Vendor ID Technical Requirements – Exam Status Updates 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].

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.

3. 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]

Vendor ID Technical Requirements – Patient Appointment Scheduling

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.