Attachment_J-20_ACCFS1107_SAIC.pdf

SAIC GSA Doc. GS-ACCFS-1107

26 Nov 2012

INTERFACE CONTROL DOCUMENT

INTEGRATED CLINICAL DATABASE BASELINE (ICDB)

Submitted in Response to:

GSA Contract GS00Q09BGD0048

Delivery Order GST0311DS8011

AHLTA & CHCS Critical Fixes and Support (ACCFS)

Deliverable Item 16

For:

GSA Region 3

5113 Leesburg Pike Suite 701

Falls Church, VA 22041

Alvaro Rodriguez, DHIMS Director of Clinical Documentation, (703) 681-8861

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

By:

Science Applications International Corporation

Health Solutions Business Unit

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 released versions of this document. The old paragraph designates the paragraph number and title where the information existed in the previous document. The summary description explains the changes made and any new sections. The reference data will specify the Delivery Order Number, project, release, and date of that submittal. This document supersedes all previous versions of this Interface Control Document.

Issue Old Paragraph Summary Description Reference Data

1.0 Original Submittal. Interface Control Document

for HL7 Interfaces, SAIC

GSA Doc. GS-ICDB-1000, 12 Nov 2001, General Services

Administration Contract No.

GS-35F-4461G

TASK ORDER 0703BG0905

2.0 3.2.1

HL7 Messages updated and added to Section

3.2.1

Integrated Clinical Database

Baseline Version 2.0 For

CHCS, Interface Control

Document, SAIC GSA Doc.

GS-ICDB-1000, 05 Jan 2005, General Services

Administration Contract No.

GS-35F-4461G, Task Order

FA5730017T6 , ICDB

Support

3.2.2 19 new Flat files added with File format and sample to Section 3.2.1

Requirements updated in Section 3.2.2

HL7 Messages Segments and Fields updated and added to Section 3.2.2

3.0

3.2.2

3.2.2-3.3.3

3.2.3.56 and 3.2.3.65

3.2.3.61

1/30/2012: Updated test data format to conform to current policy.

Changed ICD9 to ICD, Added I0 for ICD10 for

Coding Methodology Sequence for DG1 and

PR1 segments.

Updated text to reflect that either ICD-9 or

ICD-10 code will be sent.

Added note for ICD MFN, code could be ICD-9 or ICD-10 code.

Submitted in Response to:

GSA Contract

GS00Q09BGD0048

Delivery Order

GST0311DS8011

AHLTA & CHCS Critical

Fixes and Support (ACCFS)

Deliverable Item 012 for AHLTA/CHCS Critical

Fixes – Objective 4

CHCS ICD-10

4.0 3.2.3.26 ACCFS Obj 4 Ph 3 800 SSA SSN update:

In support of the AHLTA/CHCS Critical Fixes and Support (ACCFS) Objective 4 Phase 3

CHCS 800 SSA SSN project, two new repeating sequences are added to the existing

HL7 messages Patient Identification (PID) segment.

Submitted in Response to:

GSA Contract

GS00Q09BGD0048

Delivery Order

GST0311DS8011

AHLTA & CHCS Critical

Fixes and Support (ACCFS)

Deliverable Item 016 for AHLTA/CHCS Critical

Fixes – Objective 4

CHCS Pt_ID_Enh_Rel3, GS-

ACCFS-1107, 26 Nov 2012 iii

Table of Contents

SECTION 1.0 SCOPE

1.1 SYSTEM IDENTIFICATION

1.1.1 CHCS

1.1.2 ICDB

1.2 DOCUMENT OVERVIEW

1.3 APPLICABLE DOCUMENTS

SECTION 2.0 CONCEPT OF OPERATIONS

2.1 SYSTEM OVERVIEWS

2.1.1 CHCS Overview

2.1.2 ICDB Overview

2.2 FUNCTIONAL ALLOCATION

2.3 INTERFACE TRANSACTIONS

2.3.1 HL7 Transactions

2.4 DATA TRANSFER

2.5 SECURITY AND INTEGRITY

SECTION 3.0 MESSAGE SPECIFICATIONS

3.1 HL7 MESSAGE REQUIREMENTS

3.1.1 Unsolicited Update Messages Sent by CHCS to ICDB

3.1.2 Unsolicited Master File Notification Messages

3.2 HL7 MESSAGE DEFINITIONS

3.2.1 Requirements for Messages and Segments

3.2.2 Data Extraction Files (Flat Files)

3.2.3 Requirements for Segments and Fields

3.2.4 Data Type Requirements

SECTION 4.0 COMMUNICATION REQUIREMENTS FOR HL7 INTERFACES

4.1 INTERFACE INITIATION

4.2 FLOW CONTROL

4.3 ERROR MANAGEMENT

4.4 SECURITY FEATURES

SECTION 5.0 VERIFICATION

LIST OF FIGURES

FIGURE 4.3-1. ACKNOWLEDGEMENTS

LIST OF TABLES

TABLE 4.2-1. MSH SEGMENT

TABLE 5-1. VERIFICATION MATRIX

Section 1.0 Scope

This Interface Control Document (ICD) specifies the interface between the Composite Health Care System (CHCS) and the

Integrated Clinical Data Base (ICDB).

1.1 System Identification

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

1.1.1 CHCS

CHCS is an automated information system that supports health care administration and delivery at Department of Defense

(DoD) Medical Treatment Facilities (MTFs) throughout the world. It is developed by the Science Applications

International Corporation in support of:

Health Solutions Business Unit

5203 Leesburg Pike, Suite 1300

Falls Church, VA 22041

The interface specified in this ICD will be implemented in CHCS Version 4.63.

1.1.2 ICDB

ICDB provides a central standardized database of data from independent systems. For day-to-day patient care, ICDB’s supports clinicians through its integrated, single-system view of relevant patient data accessible at the point of healthcare delivery. Single sign-on, single window access to volumes of data from multiple systems—a DoD first. ICDB supports not only single patient views but also “on the fly” population views of clinical information for targeted outreach of patients with urgent needs—those with chronic illness or overdue preventive services. This ability has fundamentally altered the

AF process of healthcare delivery by providing the tools that support the enterprise transition from episodic care to an emphasis on outreach and intervention BEFORE illness and injury occur. This makes the ICDB a catalyst for promoting the Air Force initiative of Primary Care Optimization by delivering actionable data to the point of care to provide early identification and proactive intervention through scheduling of exams and tests.

The ICDB is currently active at most Department of Defense (DoD) sites and is baselined into the Composite Health Care

System (CHCS).

1.2 Document Overview

The purpose of this ICD is to specify interface requirements 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 Scope

Section 2.0 Concept of Operations

Section 3.0 Message Specifications

Section 4.0 Communication Requirements

Section 5.0 Verification

1.3 Applicable Documents

The following documents are applicable to the extent referenced in this specification

(1) DoD Privacy Program DOD 5400.11-R.

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

(3) Health Level Seven (HL7) Standard, Version 2.2, December 1, 1994

Section 2.0 Concept of Operations

The operational objective of the interface between CHCS and ICDB is to support business process changes in the Military

Health Services system (MHSS) and create an integrated clinical database receiving inputs from CHCS and other systems.

2.1 System Overviews

The following paragraphs describe the functionality and architecture of the participating systems. They briefly summarize each system, placing special emphasis on functionality related to the interface and identify key hardware and software components of each system.

2.1.1 CHCS Overview

CHCS is an automated medical information system that supports health care administration and delivery at DoD 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 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.

CHCS is implemented in a terminal/host architecture. Each site consists of a multi-node cluster of HP/Itanium servers with a storage subsystem. Sites generally dedicate one node to background processing (printing, external interfaces, etc.) and allocate the remaining nodes to user functionality. The standard user interface is via a terminal emulator. The local area network (LAN) connecting users to the host cluster is not dedicated to CHCS traffic. CHCS supports interfaces to a variety of external systems. An individual CHCS site may support one or more MTFs. Communication between CHCS sites is via electronic mail. Direct exchange of data base information between CHCS sites is not supported.

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

2.1.2 ICDB Overview

The ICDB is a system which acquires, stores, displays, and communicates CHCS patient demographic data, laboratory result, radiology result, patient appointment information, pharmacy, telephone consult, and referral orders and result information.

2.2 Functional Allocation

A unidirectional interface will be developed on a Composite Health Care System (CHCS) Version 4.63 baseline, sending

Patient Demographic, Radiology Result (reports and amendments), laboratory result, patient appointment information, pharmacy, telephone consult, and referral orders and result information messages from CHCS to the ICDB. Master File

Notifications will also be included.

2.3 Interface Transactions

CHCS will send information to ICDB via messages formatted in accordance with HL7 version 2.2.

2.3.1 HL7 Transactions

The following events on CHCS will trigger unsolicited update messages:

(1) Demographic Information is created or altered.

(2) A new patient is added on CHCS.

(3) A duplicate patient is merged.

(4) A patient is admitted to the hospital.

(5) Patient admission data is updated.

(6) Admission is canceled.

(7) A patient is discharged from the hospital.

(8) Patient discharge data is updated.

(9) Discharge is canceled.

(10) A patient is transferred to a different ward in the hospital.

(11) Patient transfer data is updated.

(12) A patient transfer is canceled.

(13) Final certification (verification) of an amended Radiology report.

(14) Radiology report is certified (verified).

(15) Unverified radiology report is released.

(16) A radiology exam reaches the REPORT ONLY status.

(17) A radiology exam reaches the EXAM ONLY status.

(18) A previously booked appointment is canceled.

(19) A previously booked appointment is rescheduled as a new appointment after being canceled.

(20) A patient is checked in for a previously booked appointment.

(21) A schedule slot is booked for an appointment.

(22) Any file supporting the Master File Notification Message is created or altered.

(23) Final verification of a certified Lab Anatomical Pathology result is performed.

(24) Final verification of an amended Lab Microbiology result is performed.

(25) Final verification of an amended Lab Clinical Chemistry result is performed.

(26) Final verification of a Lab Blood Bank result is performed.

(27) A pharmacy prescription is created.

(28) A pharmacy prescription is modified or changed.

(29) A nightly scheduled job triggers custom telephone consult messages.

(30) A Consult Result is verified.

(31) A Completed Consult Result is appended.

(32) An Unscheduled Consult Result is forwarded.

(33) A Consult Result is administratively closed either manually or through the CHCS scheduled option.

(34) An hourly scheduled job triggers custom MCP Referral messages.

Paragraph 3.1, Message Requirements, specifies the individual messages sent from CHCS.

Paragraph 3.2 defines the format and content of each message.

2.4 Data Transfer

CHCS and ICDB exchange data via HL7 messages which are transmitted as triggering events occur. Computer connectivity between CHCS and ICDB is via a perpetual TCP/IP connection. Two TCP sockets on each system provide communications between the two systems. Within the context of each TCP socket, ICDB is the server to which multiple

CHCS sites may connect as a client. Lower level connectivity is provided via HL7 Minimal Lower Layer Protocol.

Communication requirements are itemized in Section 4.0.

2.5 Security and Integrity

The interface between CHCS and ICDB 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, ICDB data falls within the content of the Exemption

Number 6 of the Department of Defense Freedom of Information Act (FOIA) Program, DoD 5400.7-R. Both the DoD

Privacy and FOIA programs mandate adequate data protection.

Unauthorized creation, disclosure, modification, or destruction of this data could cause potential harm to patient health and privacy. The CHCS/ICDB 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 ICDB is C2, Controlled Access protection. The C2 level of protection also satisfies DoD requirements for protecting unclassified sensitive systems.

Section 3.0 Message Specifications

CHCS and ICDB communicate via messages conforming to the Health Level 7 (HL7) Message Standard version 2.2, 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 between CHCS and ICDB.

3.1 HL7 Message Requirements specifies which triggers cause which messages to be sent to which systems.

3.2 HL7 Message Definitions specifies the format and content of the messages required in Paragraph

3.1.

3.1 HL7 Message Requirements

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 data base. 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 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.

The messages specified within this ICD are a subset of the HL7 messages supported by CHCS

3.1.1 Unsolicited Update Messages Sent by CHCS to ICDB

The following requirements specify the HL7 messages that are sent from CHCS to ICDB. The format and content of these messages is defined in paragraph 3.2. The use of Accept Acknowledgement messages is defined in paragraph 4.3, Error

Management. Application Acknowledgement messages are not used within this interface. Master File Notification

Messages are specified in paragraph 3.1.2.

Requirements:

(1) On trigger, Demographic Information is created or altered, CHCS shall send HL DG UPDATE

PERSON MESSAGE message.

(1) On trigger, Add new person, CHCS shall send the HL DG ADD PERSON MESSAGE message.

(2) On trigger, Duplicate patient merged, CHCS shall send the HL DG PATIENT MERGE message.

(3) On trigger, Patient is admitted to the hospital, CHCS shall send the HL DG ADMIT PATIENT message.

(4) On trigger, Patient admission data is updated, CHCS shall send the HL DG UPDATE PATIENT message.

(5) On trigger, Admission is canceled, CHCS shall send the HL DG CANCEL ADMIT message.

(6) On trigger, Patient is discharged from the hospital, CHCS shall send the HL DG DISCHARGE

PATIENT message.

(7) On trigger, Patient discharge data is updated, CHCS shall send the HL DG UPDATE PATIENT message.

(8) On trigger, Discharge is canceled, CHCS shall send the HL DG CANCEL DISCHARGE message.

(9) On trigger, Patient is transferred to a different ward in the hospital, CHCS shall send the HL DG

TRANSFER PATIENT message.

(10) On trigger, Patient transfer data is updated, CHCS shall send the HL DG UPDATE PATIENT message.

(11) On trigger, Transfer is canceled, CHCS shall send the HL DG CANCEL TRANSFER message.

(12) On trigger, Final certification (verification) of an amended Radiology report, CHCS shall send the HL

RAD RESULT message.

(13) On trigger, Radiology report is certified (verified), CHCS shall send the HL RAD RESULT message.

(14) On trigger, Unverified Radiology report is released, CHCS shall send the HL RAD RESULT message.

(15) On trigger, Radiology Exam reaches the REPORT ONLY status, CHCS shall send the HL RAD

RESULT message.

(16) On trigger, Patient arrives in Radiology for an exam, CHCS shall send the HL RAD RESULT message.

(17) On trigger, Radiology exam appointment is created or altered, CHCS shall send the HL RAD RESULT message.

(18) On trigger, A previously booked appointment is canceled, CHCS shall send the HL PAS

APPOINMENT MESSAGE message.

(19) On trigger, A previously booked appointment is rescheduled as a new appointment after being canceled, CHCS shall send the HL PAS APPOINMENT MESSAGE message.

(20) On trigger, A patient is checked in for a previously booked appointment, CHCS shall send the HL PAS

APPOINMENT MESSAGE message.

(21) On trigger, A schedule slot is booked for an appointment, CHCS shall send the HL PAS

APPOINMENT MESSAGE message.

3.1.2 Unsolicited Master File Notification Messages

CHCS maintains a set of common reference files that are shared with several external systems. As entries within these files are created or altered, via the File Manager (FileMan), CHCS uses Master File Notification (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 exchanged between CHCS and ICDB.

Requirements:

(1) On trigger, from the following files any Record is Created or Altered, CHCS shall send a HL MASTER

FILE NOTIFICATION message:

FILE# FILE NAME

3 USER

3.1 TITLE

4 MEDICAL TREATMENT FACILITY

5 GEOGRAPHIC LOCATION

5.8002 ZIP CODE

6 PROVIDER

7 PROVIDER CLASS

10 RACE

11 MARITAL STATUS

13 RELIGION

23 BRANCH OF SERVICE

40.8 MEDICAL CENTER DIVISION

42 WARD LOCATION

42.1 SOURCE OF ADMISSION

42.2 DISCHARGE TYPE

44 HOSPITAL LOCATION

44.5 APPOINTMENT TYPE

45.7 DEPARTMENT AND SERVICE

50 DRUG

51.2 MEDICATION ROUTE

59.2 OUTPATIENT SITE

60 LAB TEST

71 RADIOLOGY PROCEDURES

72 EXAMINATION STATUS

72.1 RADIOLOGY REPEAT REASON

75 RAD SPECIAL INTEREST CODE

77.2 PROCEDURE.ROOM SPECIFICATIONS

78.3 RESULT CATEGORY

78.4 FILM

78.6 RADIOLOGY ROOM

79.2 IMAGING TYPE

80 ICD DIAGNOSIS

80.1 ICD OPERATION/PROCEDURE

108.1 ANCILLARY PROCEDURE

8064 INSURANCE CO FILE

8100 PROVIDER SPECIALTY

8103 DMIS ID CODES

8104 MILITARY GRADE RANK

8110 FAMILY MEMBER PREFIX

8111 UNIT SHIP ID

8119 MEPRS CODES

8140 RELATIONSHIP

8146 LANGUAGE IDENTITY

8151 CPT/HCPCS

8156 PATIENT CATEGORY

8162 MFN RETURN CODE

8253.01 PSAFDB ADIMMSTR ADIMTBL ADIMMONO

8253.03 PSAFDB DAC MONO INDEX CITE

8254.01 ALLERGIES SELECTIONS

8410 DIET

8514 APPOINTMENT STATUS

8526 DENTAL SCHEDULING RESOURCE

8561 MCP ASSIGNMENT REASON

8566 MCP FACILITY TYPE

8568 PROFESSIONAL CATEGORY

8573 MCP AGREEMENT TYPE

8907.5 DEERS SPONSOR STATUS

3.2 HL7 Message Definitions

The following paragraphs define the segments and data elements that comprise the above specified messages:

3.2.1 Requirements for Messages and Segments specifies the segments included in each message in

Paragraph 3.1.

3.2.2 Requirements for Segments and Fields specifies the fields included in each segment in

Paragraph 3.2.1.

3.2.3 Requirements for Data Types defines the data types used in the fields specified in Paragraph

3.2.2.

3.2.1 Requirements for Messages and Segments

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 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. This paragraph specifies the segments to be included in each message specified in paragraph 3.1.

Each message is defined in special notation that lists the segment 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.

Whenever braces or brackets enclose more than one segment ID a special stylistic convention is used to help the reader understand the hierarchy of repetition. For example, the first segment ID appears on the same line as the brace, two columns to the right. The subsequent segment IDs appear under the first. The closing brace appears on a line of its own in the same column as the opening brace. This convention is an optional convenience to the user. If there is conflict between its use and the braces that appear in a message schematic, the braces define the actual grouping of segments that is permitted. The following message specifications identify the segments included in each of the requirements stated above.

Messages are arranged in alphabetical order.

3.2.1.1 ADT/A01: HL DG ADMIT PATIENT

Segment Segment Name

MSH Message Header

EVN Event Type

PID Patient Identification

[ NK1 ] Next of Kin

PV1 Patient Visit

[ DG1 ] Admission Diagnosis

[ PR1 ] Admission Procedures 1

[ PR1 ] Admission Procedures 2

[ {IN1} ] Insurance Information

[ {IN2} ] Insurance Additional Information.

[ ZP1 ] CIS Additional Patient Information

3.2.1.2 ADT/A02: HL DG TRANSFER PATIENT

EVN Event Type

PID Patient Identification

PV1 Patient Visit

3.2.1.3 ADT/A03: HL DG DISCHARGE PATIENT

EVN Event Type

PID Patient Identification

3.2.1.4 ADT/A08: HL DG UPDATE PATIENT

EVN Event Type

PID Patient Identification

[ NK1 ] Next of Kin

PV1 Patient Visit Information

[ DG1 ] Admission Diagnosis

[ PR1 ] Admission Procedures 1

[ PR1 ] Admission Procedures 2

[ {IN1} ] Insurance Information

[ {IN2} ] Insurance Additional Information

[ ZP1 ] CIS Additional Patient Information.

3.2.1.5 ADT/A11: HL DG CANCEL ADMIT

EVN Event Type

PID Patient Identification

3.2.1.6 ADT/A12: HL DG CANCEL TRANSFER

EVN Event Type

PID Patient Identification

3.2.1.7 ADT/A13: HL DG CANCEL DISCHARGE

EVN Event Type

PID Patient Identification

3.2.1.8 ADT/A28: HL DG ADD PERSON MESSAGE

EVN Event Type

PID Patient Identification

[ NK1 ] Next of Kin

PV1 Patient Visit

[ {IN1} ] Insurance Information

[ {IN2} ] Insurance Information - Additional Info.

ZPI Additional Patient Information

ZPS Sponsor Identification

3.2.1.9 ADT/A31: HL DG UPDATE PERSON MESSAGE

EVN Event Type

PID Patient Identification

[ NK1 ] Next of Kin

PV1 Patient Visit Information Used for LAB-Mail-In Registration

[ {IN1} ] Insurance Information

[ {IN2} ] Insurance Additional Information.

ZPI Additional Patient Information

ZP1 CIS Additional Patient Information

ZPS Sponsor Information

3.2.1.10 ADT/A31: HL DG MERGE PATIENT

EVN Event Type

PID Patient Identification

MRG Patient Merge

ZPI Additional Patient Information

ZP1 CIS Additional Patient Information

3.2.1.11 MFN/M01: HL MASTER FILE NOTIFICATION

MFI Master File Identification

MFE Master File Entry

[ ZM1 ] Rad Procedure Master File

[ ZML ] Hospital Location Master File

[ { STF } ] Staff Identification

[ ZMP ] Provider Additional Info Master File

[ { ZMU } ] User Master File

[ { ZMG } ] Geographic Location Master File

[ ZMZ ] Zip Code Master File

[ ZMD ] Drug Master File

[ ZMM ] MEPRS Code Master File

[ ZN1 ] Ward Location Master File

[ { ZN2 } ] Ward Multiple Room Info Master File

[ ZND ] Allergies Selections Master File

[ ZMC ] Provider Class Master File

[ ZMS ] Department and Services Master File

[ ZM3 ] Medical Center Division Master File

[ ZM6 ] DMIS ID Master File

[ ZM4 ] Ancillary Procedures Master File

[ ZNS ] Title

[ ZM9 ] Diet Master File

[ ZMI ] Insurance Master File

[ ZM5 ] Unit Ship ID Master File

[ ZMB ] Provider Specialty Master File

[ ZMF ] MTF Master File

[ { ZMH } ] Hospital Location Appointment Type Master File

[ ZMJ ] ICD Operations/Procedures

[ ZM8 ] Family Member Prefix Master File

[ ZNA ] PSAFDB ADIMMSTR ADIMTBL ADIMMONO Master File

[ { ZNC } ] PSAFDB ADIMMON Master File

[ ZM7 ] User Allowable Division

[ ZMY ] Return Codes Master File

[ ZNF ] PSAFDB DAC MONO INDEX CITE Master File

[ { ZNG } ] PSAFDB DAC MONO INDEX CITE CAUTION Master File

[ ZNH ] PSAFDB DAC MONO INDEX CITE SECTION Master File

[ { ZNI } ] PSAFDB DAC MONO INDEX CITE CITATION Master File

[ ZNK ] PSAFDB DAC MONO INDEX CITE NAV

[ ZMQ ] ICD Diagnosis Master File

[ { ZMV } ] ICD Diagnosis - Additional Info

[ ZMK ] CPT/HCPCS Master File

[ { ZN9 } ] CPT/HCPCS Modifiers Master File

[ ZME ] Appointment Type Code

[ ZNE ] Professional Category

[ ZMR ] Medication Route

3.2.1.12 ORU/R01: HL RAD RESULT

PID Patient Identifier

ORC Common Order

OBR Observation Request

OBX Observation Result Code

{ OBX } Observation Result Report Text

ZRR Additional Result Information

[ { OBX Observation Result Amended Result Code

{ OBX } Observation Result Amended Report Text

ZRR Additional Amended Result Information

ZRE Radiology Encounter

[ {ZRD} ] Radiology Teaching Codes

[ {ZRL} ] Radiology Special Interest Codes

[ {ZL1} ] CPT Workload Information

[ {ZPX} ] Additional Patient Information

3.2.1.13 SCH/S01: HL PAS APPOINTMENT MESSAGE

EVN Event Type

SCH Schedule Activity Information

[ { SCH } ] Schedule Activity Information

[ { NTE } ] Notes and Comments

PID Patient Identification

[ PV1 ] Patient Visit

[ { DG1 }] Diagnosis

[ { NTE } ] Notes and Comments

[ AIP ] Appointment Information - Personnel Resource

[ NTE ] Notes and Comments

[ AIP ] Appointment Information - Personnel Resource

[ ORC ] Common Order - Appointment and Scheduling

[ { PR1 } ] Procedures

[ PV2 ] Patient Visit - Additional Information

[ { PR1 } ] Procedures

[ ZOR ] Custom Appointment/Managed Care

[ PV2 ] Patient Visit - Additional Information

[ ZOR ] Custom Appointment/Managed Care

[ ZSC ] PAS Custom Appointment/Scheduling

3.2.1.14 ORU/R01 HL LAB AP RESULTS MESSAGE

PID Patient Identification

ORC Common Order

OBR Order Details

{OBX} Anatomic Pathology Result

{[ZL1]} CPT Workload Data

3.2.1.15 ORU/LAB HL LAB BB RESULTS MESSAGE

MSH HL Message Header Out

PID HL DG Patient Identification Patient

ORC HL LAB Common Order - Out

OBR HL LAB BB Obser Req

{OBX} HL LAB BB Test

[ { NTE } HL LAB BB Result Comment

[ { NTE } ] HL LAB Method Interpretation

[ { ZOB } ] HL LAB BB Unit Status

[ { ZL1 } ] HL LAB CPT Workload Data

ZPX HL CP ZPX Xtra Pat Info

3.2.1.16 ORU/R01 HL LAB CH RESULTS MESSAGE

PID Patient Identification

ORC Common Order

OBR Order Details

{OBX Clinical Chemistry Test Result

{[NTE]} Result Comments and Interpretations

{[ZL1]} CPT Workload Data

3.2.1.17 ORU/R01 HL LAB MI RESULTS MESSAGE

PID Patient Identification

ORC Common Order

OBR Order Details

[{OBX Bacteriology Test Result

[{OBX Organism

[{OBX}] Antibiotics

[{OBX}] Gram Stain Result

[{OBX}] Sterility Control Result

[{OBX}] Sterility Result

[{OBX Mycobacterium Test

[{OBX}] Mycobacterium Test Result

[{OBX Organism

[{OBX}] Antibiotics

[{OBX}] Acid Fast Stain Result

[{OBX Mycology Test

[{OBX}] Mycology Test Result

[{OBX}] Fungus/Yeast Result

[{OBX}] Smear/Prep Result

[{OBX Parasitology Test

[{OBX}] Stool Result

[{OBX}] Parasite and Stage Results

[{OBX Virology Test

[{OBX}] Virology Test Result

[{OBX}] Virus

[{ZL1}] CPT Workload Data

3.2.1.18 ORU/R01 KW ICDB CONSULT RESULT

MSH HL MESSAGE HEADER OUT

PID HL DG PATIENT IDENTIFICATION

[{ZCN}] KW OR CONSULT (ICDB)

[{NTE}] KW OR CONSULT NOTE (ICDB)

[{ZCA}] KW OR CONSULT ACTIVITY (ICDB)

[{ZCA}] KW OR CONSULT APPEND PARENT (ICDB)

[{ZCA}] KW OR CONSULT APPEND (ICDB)

3.2.1.19 ORU/R01 KW ICDB TELEPHONE CONSULT

MSH HL MESSAGE HEADER OUT

PID HL DG PATIENT IDENTIFICATION

[{ZTC}] KW TELEPHONE CONSULT (ICDB)

[{ZCN}] KW TCON CLERK ENTRY (ICDB)

[{ZCN}] KW TCON CLERK/PREV PROVIDER NOTES (ICDB)

[{ZCN}] KW TCON PROVIDER NOTES (ICDB)

ZPX HL CP ZPX XTRA PAT INFO

3.2.1.20 RDS/R01 KW ICDB PSO PHARMACY ACTION

MSH MESSAGE HEADER

PID HL DG PATIENT

ORC HL PSO COMMON

RXE HL PSO PHARMACY ENCODED ORDER

RXD HL PSO PHARMACY DISPENSE

ZKW KW PSO ZKW CUSTOM PRESCRIPTION (ICDB)

3.2.1.21 RDS/R01 KW ICDB PSO PHARMACY DISPENSE

MSH MESSAGE HEADER

PID HL DG PATIENT

ORC HL PSO COMMON

RXO HL PSO PHARMACY PRESCRIPTION ORDER

RXE HL PSO PHARMACY ENCODED ORDER

RXD HL PSO PHARMACY DISPENSE

ZOR HL PSO ZOR CUSTOM ORDER

ZKW KW PSO ZKW CUSTOM PRESCRIPTION (ICDB)

3.2.1.22 ZPM/Z30 KW ICDB MCP REFERRAL

MSH MESSAGE HEADER

PID HL DG PATIENT

ZPR HL CP ZPR REFERRAL

ZCI KW CP ZCI REFERRAL INFO (ICDB)

DG1 HL CP DG1 DIAGNOSIS

PR1 HP CP PR1 PROCEDURES

NTE HL CP NTE NOTES AND COMMENTS

ZRR KW CP ZRR REFERRAL REASON (ICDB)

ZCM KW CP ZCM REVIEW MULT

ZCC KW CP ZCC REVIEW COMMENT (ICDB)

3.2.2 Data Extraction Files (Flat Files)

NOTE: DBA inactive entries may be generated for this data extraction. “*” (an asterisk) is used as an end of file marker.

3.2.2.1 Flat File - KWICDB_ACCAREA.DAT

The format of this custom flat file KWICDB_ACCAREA.DAT is being provided by the following example, illustrating one record created when the file is actually generated.

BB^BLOOD BANK^BLOOD BANK

3.2.2.2 Flat File - KWICDB_ADMTYP.DAT

The format of this custom flat file KWICDB_ADMTYP.DAT is being provided by the following example, illustrating one

1^0^ERA^ER, DIRECT TO MILITARY MTF^A^

3.2.2.3 Flat File - KWICDB_ALLSEL.DAT

The format of this custom flat file KWICDB_ALLSEL.DAT is being provided by the following example, illustrating one

1000^PENICILLINS

3.2.2.4 Flat File - KWICDB_ANCPROC.DAT (CBIS)

Flat file layout:

.; AncProcID^AncProc Name^Clinic^Schedule Type^Special Procedure Type^

.; Not Orderable

The format of this custom flat file KWICDB_ANCPROC.DAT is being provided by the following example, illustrating one

24^OCCUPATIONAL THERAPY CONSULT^^SCHEDULED^CONSULTS^

3.2.2.5 Flat File - KWICDB_ANTIOBIOTIC.DAT

The format of this custom flat file KWICDB_ANTIBIOTIC.DAT is being provided by the following example, illustrating one record created when the file is actually generated.

4^Ak^AMIKACIN

3.2.2.6 Flat File - KWICDB_APPTSTAT.DAT

The format of this custom flat file KWICDB_APPTSTAT.DAT is being provided by the following example, illustrating

1^PENDING

3.2.2.7 Flat File - KWICDB_APPTTYP.DAT

The format of this custom flat file KWICDB_APPTTYP.DAT is being provided by the following example, illustrating one

1^RAD*^RAD APPOINTMENT^F^I

3.2.2.8 Flat File - KWICDB_BLDTYP.DAT (CBIS)

Flat file layout:

.; Blood Product Type ID^Code^Description^Autologous Donation

The format of this custom flat file KWICDB_BLDTYP.DAT is being provided by the following example, illustrating one

2^3BX^WHOLE BLOOD, AUTOLOGOUS^1^I^01-Dec-1999

Flat

3.2.2.9 Flat File - KWICDB_CLNSITE.DAT (CBIS)

Flat file layout:

S KW6=$G(^ORD(101.1,1,6))

S KWRAD=$P(KW6,U,8)

S KWLAB=$P(KW6,U,9)

S KWANC=$P(KW6,U,10)

; 5 = RAD order type; 4 = LAB order type; 8 = ANC order type

W 5_U_KWRAD,!

W 4_U_KWLAB,!

W 8_U_KWANC,!

The format of this custom flat file KWICDB_CLNSITE.DAT is being provided by the following example, illustrating one

5^5

4^30

8^15

3.2.2.10 Flat File - KWICDB_COLLSAMP.DAT (CBIS)

Flat file Layout:

.; Collection Sample ID^Collection Sample Name^Default Specimen

.; (Topography Field ID)^Tube Top Color

The format of this custom flat file KWICDB_COLLSAMP.DAT is being provided by the following example, illustrating

999^BLOOD,AUTOLOGOUS^8831^RED

3.2.2.11 Flat File - KWICDB_COMINT.DAT

The format of this custom flat file KWICDB_COMINT.DAT is being provided by the following example, illustrating one

1^COM^NOTIFY COMMANDER^A^

3.2.2.12 Flat File - KWICDB_CPT.DAT

The format of this custom flat file KWICDB_CPT.DAT is being provided by the following example, illustrating one record created when the file is actually generated.

1^99999^ANESTH, TESTER^ANESTHESIA FOR PROCEDURES ON TESTER

LUDING BIOPSY^A^01-Dec-1985

3.2.2.13 Flat File - KWICDB_DISTYP.DAT

The format of this custom flat file KWICDB_DISTYP.DAT is being provided by the following example, illustrating one

.5^53^^CANCELLED ADMISSION^A^01-Dec-1999

3.2.2.14 Flat File - KWICDB_DIV.DAT

The format of this custom flat file KWICDB_DIV.DAT is being provided by the following example, illustrating one record

1^INTERNAL TEST DIV^FDIV^0120^7056^INTERNAL TEST^8^A^

3.2.2.15 Flat File - KWICDB_DRG.DAT

The format of this custom flat file KWICDB_DRG.DAT is being provided by the following example, illustrating one

1^999^ACUTE ADJ REACT & DISTURB OF PSYCHOSCIAL DYSFUNCT^.6505

3.2.2.16 Flat File - KWICDB_DRUG.DAT

The format of this custom flat file KWICDB_DRUG.DAT is being provided by the following example, illustrating one

1^INTERNAL TEST^0^99999-99-9999^9^PO^TAB^28:08.92^ANALGESIC/ANTIPYRETICS

,NON-SALICYLATE

3.2.2.17 Flat File - KWICDB_DRUGRT.DAT (CBIS)

.; Drug Name-Route ID^Drug Route Name^Drug Route Desc

The format of this custom flat file KWICDB_DRUGRT.DAT is being provided by the following example, illustrating one

1^MISC^MISCELLANEOUS

3.2.2.18 Flat File - KWICDB_ETIOLOGY.DAT

The format of this custom flat file KWICDB_ETIOLOGY.DAT is being provided by the following example, illustrating

1^ESCHERICHIA COLI^BACTERIUM

3.2.2.19 Flat File - KWICDB_FORM.DAT (CBIS)

..; Drug ID^Formulary Name^IP/OP Indicator^Non-Formulary^Max Quantity^

..; Max Days Supply^Max Refills Allowed^Dispense Complete Container^

..; Default Expiration^Default Quantity^Default Sig^Continuable^

..; Replenish On Request^Default Schedule Type^Order Duration^

..; Inactive Date

The format of this custom flat file KWICDB_FORM.DAT is being provided by the following example, illustrating one

999^INTERNAL TEST GROUP^^0^^100^5^^180^^CUT TO SIZE OF AFFECTED AREA, AND APPLY AS

DIRECTED^^^^^

466^OFG1^B^0^^^^^365^^^^^^^

467^INTERNAL TEST GROUP^B^0^^^^^365^^^^^^99^01-DEC-1999

3.2.2.20 Flat File - KWICDB_GEOLOC.DAT

The format of this custom flat file KWICDB_GEOLOC.DAT is being provided by the following example, illustrating one

ALABAMA^AL^A^01-DEC-1999

3.2.2.21 Flat File - KWICDB_HCDP.DAT (CBIS)

; Code^Text

The format of this custom flat file KWICDB_HCDP.DAT is being provided by the following example, illustrating one

999^TRICARE DENTAL PLAN INDIVIDUAL COVERAGE FOR NON-MOBILIZATION-ASSET INDIVIDUAL

READY RESERVE (IRR) FAMILY MEMBERS

3.2.2.22 Flat File - KWICDB_HOSAPPT.DAT (CBIS)

..; Hospital Location ID^Appointment Type ID

The format of this custom flat file KWICDB_HOSAPPT.DAT is being provided by the following example, illustrating one

99999^553

3.2.2.23 Flat File - KWICDB_HOSPROV.DAT (CBIS)

..; Hospital Location ID^Provider ID

The format of this custom flat file KWICDB_HOSPROV.DAT is being provided by the following example, illustrating one

9999^2871

3.2.2.24 Flat File - KWICDB_HOSLOC.DAT

The format of this custom flat file KWICDB_HOSLOC.DAT is being provided by the following example, illustrating one

.5^QUARTERS^^WARD^^^^^A^

3.2.2.25 Flat File - KWICDB_ICD0.DAT

The format of this custom flat file KWICDB_ICD0.DAT is being provided by the following example, illustrating one record created when the file is actually generated. Data is from the ICD Operation/Procedure file, which contains both ICD-

9 and ICD-10 procedure codes.

1^10.1^OTHER INCISION OF CONJUNCTIVA^CONJUNCTIVA INCISION NEC^A^01-DEC-1999

3.2.2.26 Flat File - KWICDB_ICD9.DAT

The format of this custom flat file KWICDB_ICD9.DAT is being provided by the following example, illustrating one record created when the file is actually generated. Data is from the ICD Diagnosis file, which contains both ICD-9 and

ICD-10 diagnosis codes.

1^100.81^LEPTOSPIRAL MENINGITIS (ASEPTIC)^LEPTOSPIRAL MENINGITIS^A^01-DEC-1999

3.2.2.27 Flat File - KWICDB_INJURY.DAT (CBIS)

Flat file layout:

; Cause of Injury IEN^Code^Name^Category^

; DBA Inactive Flag^Deactivation Date

The format of this custom flat file KWICDB_INJURY.DAT is being provided by the following example, illustrating one

2^001^AIR ACCIDENT, FIXED-WING MILITARY, TAXIING,TAKEOFF,LANDING ON CARRIER^I^A^

3.2.2.28 Flat File - KWICDB_LABDIV.DAT (CBIS)

; Lab Division ID^Phlebotomy Collection Time

The format of this custom flat file KWICDB_LABDIV.DAT is being provided by the following example, illustrating one

1^0900

3.2.2.29 Flat File - KWICDB_LABTEST.DAT

The format of this custom flat file KWICDB_LABTEST.DAT is being provided by the following example, illustrating one

1^WHITE BLOOD CELLS 0801^SINGLE^CH^^NO

3.2.2.30 Flat File - KWICDB_LABTESTPANEL.DAT

The format of this custom flat file KWICDB_LABTESTPANEL.DAT is being provided by the following example, illustrating one record created when the file is actually generated.

268^175

3.2.2.31 Flat File - KWICDB_LABTESTCOLL.DAT (CBIS)

Flat file layout:

..; Lab Test ID^Collection Sample ID^

..; Order Entry Note 1_Order Entry Note 2

The format of this custom flat file KWICDB_LABTESTCOLL.DAT is being provided by the following example, 9999^18^THIS IS AN ORDER ENTRY NOTE 1THIS IS AN ORDER ENTRY NOTE 2

3.2.2.32 Flat File - KWICDB_LABTESTCPT.DAT (CBIS)

; Lab Test IEN^CPT Code

The format of this custom flat file KWICDB_LABTESTCPT.DAT is being provided by the following example, illustrating

155^88104

3.2.2.33 Flat File - KWICDB_LABTESTSYN.DAT (CBIS)

Flat File layout:

..; Lab Test ID^Synonym

The format of this custom flat file KWICDB_LABTESTSYN.DAT is being provided by the following example, illustrating

3461^GERMAN MEASLES SPECIFIC ANTIBODY IGG

3.2.2.34 Flat File - KWICDB_MARITAL.DAT

The format of this custom flat file KWICDB_MARITAL.DAT is being provided by the following example, illustrating one

A^ANNULLED^A^

3.2.2.35 Flat File - KWICDB_MEDIELIG.DAT

The format of this custom flat file KWICDB_MEDIELIG.DAT is being provided by the following example, illustrating

E^Eligible (over 65)

3.2.2.36 Flat File - KWICDB_MEPRS.DAT

The format of this custom flat file KWICDB_MEPRS.DAT is being provided by the following example, illustrating one

73^AAA^INTERNAL MEDICINE^INPATIENT^INTERNAL MEDICINE SERVICE^^A^01-DEC-1999

3.2.2.37 Flat File - KWICDB_NEDPATPCM.DAT

The format of this custom flat file KWICDB_NEDPATPCM.DAT is being provided by the following example, illustrating

90^^dd-mon-yyyy^dd-mon-yyyy^0553

3.2.2.38 Flat File - KWICDB_OPSITE.DAT (CBIS)

The format of this custom flat file KWICDB_OPSITE.DAT is being provided by the following example, illustrating one

1^FI OP PHARMACY1^8^1^FA

3.2.2.39 Flat File - KWICDB_OPSITELOC.DAT

.; Outpatient Site ID^Hospital Location ID

The format of this custom flat file KWICDB_OPSITELOC.DAT is being provided by the following example, illustrating

1^1601

3.2.2.40 Flat File - KWICDB_PATALLERGY.DAT

The format of this custom flat file KWICDB_PATALLERGY.DAT is being provided by the following example, 1^4003

3.2.2.41 Flat File - KWICDB_PATCAT.DAT

The format of this custom flat file KWICDB_PATCAT.DAT is being provided by the following example, illustrating one

1^A11^USA ACTIVE DUTY^ACTIVE DUTY^I^dd-mon-yyyy

3.2.2.42 Flat File - KWICDB_PATENC.DAT

The format of this custom flat file KWICDB_PATENC.DAT is being provided by the following example, illustrating one

1^A11^USA ACTIVE DUTY^ACTIVE DUTY^I^dd-mon-yyyy

3.2.2.43 Flat File - KWICDB_PROV.DAT

The format of this custom flat file KWICDB_PROV.DAT is being provided by the following example, illustrating one

2^TEST,FIRSTtNAME^999999999^TEST^1^MEDICAL CORPS^1024^COLONEL^MEDICINE

DEPARTMENT^^999999^AUDIOLOGIST^A^

3.2.2.44 Flat File - KWICDB_RACE.DAT

The format of this custom flat file KWICDB_RACE.DAT is being provided by the following example, illustrating one

C^WHITE^A^

3.2.2.45 Flat File - KWICDB_RADPROC.DAT

The format of this custom flat file KWICDB_RADPROC.DAT is being provided by the following example, illustrating one

1^CHEST, PA^0010^R^RADIOLOGY^A

3.2.2.46 Flat File - KWICDB_RADPROCGRP.DAT

The format of this custom flat file KWICDB_RADPROCGRP.DAT is being provided by the following example, 248^246

3.2.2.47 Flat File - KWICDB_RADPROCSYN.DAT (CBIS)

; Rad Proc ID^Synonym

The format of this custom flat file KWICDB_RADPROCSYN.DAT is being provided by the following example, 1^L-CHEST

3.2.2.48 Flat File - KWICDB_RECIPE.DAT (CBIS)

Flat file layout:

.; IV Recipe ID^Recipe Name^IV Type^Multiple Bottle^Days^

.; Rate^Schedule^Solution(DrugID)^Volume^Drug ID^Amount^Unit

The format of this custom flat file KWICDB_RECIPE.DAT is being provided by the following example, illustrating one

999^GARYS IV FLUIDS^CONTINUOUS-SINGLE BOTTLE^^3^100^^2179^1000^427^20^ML

3.2.2.49 Flat File - KWICDB_RECBOT.DAT (CBIS)

Flat file layout:

. ..; IV Recipe ID^Bottle ID^Bottle Solution ID^Bottle Volume^

...; Additive ID^Additive ID^Additive Amount^Additive Unit

The format of this custom flat file KWICDB_RECBOT.DAT is being provided by the following example, illustrating one

999^2^4697^1000^2^4871^30^MMOL

3.2.2.50 Flat File - KWICDB_RELATIONSHIP.DAT

The format of this custom flat file KWICDB_RELATIONSHIP.DAT is being provided by the following example, 1^W^WIFE OF PATIENT^A^

3.2.2.51 Flat File - KWICDB_RESCAT.DAT

The format of this custom flat file KWICDB_RESCAT.DAT is being provided by the following example, illustrating one

1^NORMAL

3.2.2.52 Flat File - KWICDB_TOP.DAT (CBIS)

.; Topography ID^Topography Name

The format of this custom flat file KWICDB_TOP.DAT is being provided by the following example, illustrating one record

9999^SUPERIOR LEFT PULMONARY VEIN, APICOPOSTERIOR BRANCH

3.2.2.53 Flat File - KWICDB_UNIT.DAT

The format of this custom flat file KWICDB_UNIT.DAT is being provided by the following example, illustrating one

9999^INTERNAL TEST ADDRESS^WPF599^ARMY^25^99999^I^01-DEC-1999

3.2.2.54 Flat File - KWICDB_USER.DAT

The format of this custom flat file KWICDB_USER.DAT is being provided by the following example, illustrating one

.5^POSTMASTER^^

3.2.3 Requirements for Segments and Fields

A segment is a logical grouping of data fields. An HL7 data field is an ASCII character string. Fields of a segment a 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 R/O RP# Description FILE # FIELD # FIELD NAME

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 Maximum 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. Those used by

CHCS are defined in paragraph 3.2.3.

R/O - Optionality Whether the field is required, optional, or conditional in a segment. The designations are:

R - required

O - optional

N - not used (this is not an HL7 standard designation)

C - Conditional on the trigger event or on some other field(s)

RP/# - Repetition Whether the data field may repeat. Each occurrence may contain the number of characters specified by the field's maximum length. The designations are:

N - no repetition

Y - the field may repeat an indefinite or site determined number of times

# - Integer number of times the field may repeat

Description A high-level description of the contents of the field.

File # CHCS source file number for the contents of the field.

Field # CHCS source field number for the contents of the field.

Field Name CHCS source field name for the contents of the field.

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

3.2.3.1 AIP Appointment Information - Personnel Resources

SEQ ELEMENT NAME LEN DT RE

Q

RP# DESCRIPTION FILE # FIELD

FIELD NAME

1 Resource ID 80 CN No No ID number and name of the person requested or scheduled for an appointment. Required for scheduling messages. CHCS reference file: STF

44.2 3 PROVIDER

2 Resource Role 15 CE No No Role of the personnel requested/scheduled for an appointment. Required for management info messages.

3 Start Date/Time Offset 20 CQ No No Used when resource is required for the appointment at a different time than the appointment start date/time.

Expressed as an offset from the appointment start date/time.

4 Duration 20 CQ No No Used when resource is required for a different amount of time than the appointment's overall duration

5 Allow Substitution Code 10 ID No No Indicates whether the identified personnel resource can be replaced with an equivalent substitute personnel resource by the filler application. HL7 2.3 Reference Table 0279. CONFIRM = Contact Placer Contact Person before substitution of this resource; N

6 Filler Status Code 80 CE No Yes Appointment status. Required for scheduling messages CHCS reference file: APS CHCS Reference File: APS

44.2 7 APPOINTMENT

STATUS

3.2.3.2 DG1 Admission Diagnosis

SEQ ELEMENT NAME LEN DT RE

Q

RP# DESCRIPTION FILE # FIELD

FIELD NAME

1 Set ID - Diagnosis 4 SI Yes No Sequence Number (1-9999) that uniquely identifies the individual transaction to add, delete or update the diagnosis.

2 Diagnosis Coding Method

3 ID Yes No Coding Methodology. Values for CHCS:

I9, I0, C4 (Events A01, A08 and ZZ8 only).

I9=ICD-9 for disposition date prior to 01

October 2013.

I0=ICD-10 for disposition date of 01

October 2013 or later.

99=local

3 Diagnosis Code 80 CE Yes No Code. CHCS reference file: ICD (contains ICD-9 and ICD-10), CPT

311.12 0.01 DIAGNOSIS

If DG1-2 has I9, then ICD-9 code set.

If DG1-2 has I0, then ICD-10 code.

ICD-10 codes are not sent with decimals or spaces.

8554.0

0.01 PROVISIONAL

DIAGNOSIS

4 Diagnosis Description 80 ST No No Description of the diagnosis.

Required for scheduling messages. If DG1-2=I9, this is the text of the Diagnosis at Admission (ICD9 Description). If DG1-2=I0, this is the text of the Diagnosis at Admission (ICD10 Description). If DG1-2=99, this is the Diagnosis Free Text.

2.95 0.06

80 3 DIAGNOSIS

80 10 DESCRIPTION

5 Diagnosis Date/Time 26 TS No No Date/Time of diagnosis. Used only for scheduling messages.

6 Diagnosis/DRG Type 1 ID No No Type of diagnosis. Values for CHCS:

1=Admission P = Provisional; <null> = Appointment

7 Major Diagnostic Category

60 CE No No Refer to user-defined table, Major Diagnostic Category. Used only for

8 Diagnostic Related Group

4 ID No No DRG for the Transaction. Used only for scheduling messages.

9 DRG Approval Indicator

2 ID No No Indicates if the DRG has been approved by a reviewing entity. Used only for scheduling messages.

10 DRG Grouper Review Code

2 ID No No Indicates that grouper results have been reviewed and approved. Used only for scheduling messages.

11 Outlier Type 60 CE No No Type of outlier that has been paid;

Refer to user-defined Table, Outlier Type. Used only for scheduling messages.

12 Outlier Days 3 NM No No Number of days approved as outlierpayment. Used only for

13 Outlier Cost 12 NM Yes No Amount of money approved as payment. Used only for scheduling messages.

14 Grouper Version and Type

4 ST No No Grouper version and type. Used only for scheduling messages.

15 Diagnosis/DRG Priority 2 NM No No Number identifying the significance or priority of Diagnosis or DRG Code.

Used only for scheduling messages.

16 Diagnosing Clinician 60 CN No No Individual responsible for generating diagnosis information. Used only for

3.2.3.3 ERR Error

SEQ ELEMENT NAME

LE

N

DT R/

O

RP/

DESCRIPTION FILE

FIELD

FIELD LOCATION

1 Error Code and Location

80 CM Ye s

No Components: <segment id> \ <sequence> \ <field position> \ <code identifying error>

Note: code identifying error is a CE in the form of code&text&99ERR

3.2.3.4 EVN Event Type

SEQ ELEMENT NAME LEN DT R/O RP/

DESCRIPTION FILE # FIELD

FIELD NAME

1 Event Type Code 3 ID Yes No A01 = Admit a patient A02 = Transfer a patient A03 = Discharge a patient A08 = Update Admit, Transfer, or Discharge A11 = Cancel admit A12 = Cancel transfer A13 = Cancel discharge A28 = Add a person A30 = Merge patient information A31 = Update person information S15 = appointment cancellation S13 =…