Medicity ProAccess 7 ADT Product Specification

Medicity ProAccess 6.x and 7.
x
ADT Product Specification
HL7 2.3
03/06/2014
Medicity, Inc. has prepared this document for use by Medicity, Inc. personnel, licensees, and
customers. The information contained herein is the property of Medicity, Inc. and shall not be copied,
photocopied, translated, or reduced to any electronic or machine readable form, either in whole or in
part, without prior written approval from Medicity, Inc.
2014 by Medicity, Inc. All Rights Reserved. Printed in the USA.
Trademarks and registered names:
ProAccess is a trademark of Medicity, Inc.
All other trademarks or registered trademarks are the property of their respective owners.
Medicity, Inc.
257 E. 200 S.
Salt Lake City, UT 84111
Phone 801.322.4444 Fax 801.322.4413
www.medicity.com
Medicity ProAccess ADT Product Specification
Table of Contents
1 Introduction ................................................................................................................................7
1.1 Document Purpose .................................................................................................................. 7
1.2 Document Scope ..................................................................................................................... 7
1.3 Referenced Documents ........................................................................................................... 7
2 Communications ........................................................................................................................8
2.1 Minimal Lower Level Protocol .................................................................................................. 8
3 Medicity Business Rules and Guidelines...................................................................................9

3.1.1 Validation Philosophy .................................................................................................... 9
3.1.1.1 Pre-validation .......................................................................................................... 9
3.1.1.2 Post-validation ........................................................................................................ 9
3.1.2 Patient Matching .......................................................................................................... 10
3.1.2.1 Patient Identifiers configured for this interface ....................................................... 10
3.1.2.2 Add/Update Setting ............................................................................................... 10
3.1.1 Encounter or Visit Matching ......................................................................................... 11
3.1.2 Guarantor, Next of Kin, and Insured Matching ............................................................. 11
3.1.3 Physician Matching ...................................................................................................... 11
3.1.3.1 Physician Matching Business Rules: ..................................................................... 11
3.1.3.2 Physician Matching Common Issues: .................................................................... 11
3.1.3.3 Physician Free-text matching ................................................................................ 12
3.2 Nexus Metadata to be captured for this Interface ................................................................... 12
4 ADT Trigger Events .................................................................................................................14

5 Message Structure Definition...................................................................................................16
5.1 Messages .............................................................................................................................. 16
5.1.1 Admit a Patient (A01) .................................................................................................. 16
5.1.1.1 Admit a Patient (A01) Message Structure ............................................................. 16
5.1.2 Transfer a Patient (A02) .............................................................................................. 17
5.1.2.1 Transfer a Patient (A02) Message Structure ......................................................... 17
5.1.3 Discharge a Patient (A03)............................................................................................ 18
5.1.3.1 Discharge a Patient (A03) Message Structure....................................................... 18
5.1.4 Register a Patient (A04) .............................................................................................. 18
2013-2014 Medicity, Inc - Proprietary & Confidential
5.1.4.1 Register a Patient (A04) Message Structure ......................................................... 18

5.1.5 Pre-Admit a Patient (A05) ............................................................................................ 18
5.1.5.1 Pre-Admit a Patient (A05) Message Structure ....................................................... 18
5.1.6 Transfer Outpatient to Inpatient (A06) and Transfer Inpatient to Outpatient (A07) ....... 18
5.1.6.1 Transfer Outpatient to Inpatient (A06) and Transfer Inpatient to Outpatient (A07)
Message Structure ............................................................................................................. 18
5.1.7 Update Patient Information (A08) ................................................................................ 19
5.1.7.1 Update Patient Information (A08) Message Structure ........................................... 19
5.1.8 Cancel Patient Admit (A11) ......................................................................................... 19
5.1.8.1 Cancel Patient Admit (A11) Message Structure .................................................... 19
5.1.9 Cancel Transfer (A12) ................................................................................................. 19
5.1.9.1 Cancel Transfer (A12) Message Structure ............................................................ 20
5.1.10 Pending Admit (A14) ................................................................................................... 20
5.1.10.1 Pending Admit (A14) Message Structure ............................................................. 20
5.1.11 Swap Patients (A17) .................................................................................................... 20
5.1.11.1 Swap Patients (A17) Message Structure ............................................................. 20
5.1.12 Leave of Absence - Leaving (A21) and Leave of Absence - Returning (A22)............... 21
5.1.12.1 Leave of Absence - Leaving (A21) and Leave of Absence - Returning (A22)
Message Structure ............................................................................................................. 21
5.1.13 Add Person Information (A28) ..................................................................................... 21
5.1.13.1 Add Person Information (A28) Message Structure ............................................... 21
5.1.14 Delete Person Information (A29) ................................................................................. 22
5.1.14.1 Delete Person Information (A29) Message Structure ........................................... 22
5.1.15 Update Person Information (A31) ................................................................................ 22
5.1.15.1 Update Person Information (A31) Message Structure.......................................... 23
5.1.16 Merge Patient Internal ID (A40) ................................................................................ 23
5.1.16.1 Merge Patient Internal ID (A40) Message Structure.......................................... 24
5.1.17 Merge Account - Patient Account Number (A41) ......................................................... 24
5.1.17.1 Merge Account Patient Account Number (A41) Message Structure .................. 25
5.1.18 Move Account Information Patient Account Number (A44) ....................................... 25
5.1.18.1 Move Account Information Patient Account Number (A44) Message Structure . 26
6 HL7 Segment Layouts .............................................................................................................27

6.1 Control Segments .................................................................................................................. 28
6.1.1 The MSH Segment - Message Header ........................................................................ 28
6.1.2 The MSA Segment - Message Acknowledgment Segment .......................................... 29
6.2 ADT Segments ...................................................................................................................... 30

6.2.1 The EVN Segment Event Type (Ignored).................................................................. 30
6.2.2 The PID Segment - Patient Identification ..................................................................... 30
6.2.3 The PD1 Segment - Patient Demographic Segment .................................................... 33
6.2.3.1 PD1 Medicity Business Rules and Guidelines ....................................................... 34
6.2.1 The MRG Segment - Merge Patient Information .......................................................... 35
6.2.2 The NK1 Segment - Next of Kin................................................................................... 35
6.2.2.1 NK1 Medicity Business Rules and Guidelines ....................................................... 37
6.2.3 The PV1 Segment - Patient Visit ................................................................................. 38
6.2.3.1 PV1 Medicity Business Rules and Guidelines ....................................................... 41
6.2.4 The PV2 Segment - Additional Patient Visit Information .............................................. 42
6.2.4.1 PV2 Medicity Business Rules and Guidelines ....................................................... 42
6.2.5 The AL1 Segment - Patient Allergy Information ........................................................... 43
6.2.6 The DG1 Segment - Diagnosis .................................................................................... 44
6.2.6.1 DG1 Medicity Business Rules and Guidelines....................................................... 45
6.2.7 The PR1 Segment - Procedures .................................................................................. 45
6.2.8 The GT1 Segment - Guarantor .................................................................................... 49
6.2.8.1 GT1 Medicity Business Rules and Guidelines ....................................................... 52
6.2.9 The IN1 Segment - Insurance Information ................................................................... 53
6.2.10 The IN2 Segment - Insurance Additional Info .............................................................. 55
6.2.10.1 IN2 Medicity Business Rules and Guidelines ....................................................... 57
6.2.11 The ACC Segment - Accident Information ................................................................... 58
1 Introduction
The Medicity ADT Inbound interface supports the receipt of HL7 ADT messages. This document defines
and describes the HL7 event codes and messages that Medicity ADT Inbound will accept. This document
also describes how the Medicity ADT Inbound interface will process each event.
This document contains the following chapters:
Chapter 1: Introduction Includes the purpose and scope of the document and a list of related
documents that can help you understand the subject matter.
Chapter 2: Communications Details the generalized interaction and exchange of data according to
MLLP.
Chapter 3: Medicity Business Rules and Guidelines Describes Medicity specific business rules and
guidelines.
Chapter 4: ADT Trigger Events Describes the supported HL7 trigger events for given HL7 ADT
message types.
Chapter 5: Message Structure Definition Identifies the message structure.
Chapter 6: HL7 Segment Layouts Defines HL7 data segments supported in an ADT interface from a
non-Medicity system to ProAccess.
1.1 Document Purpose

This document is designed to document the products known business rules for ADT interfaces. This is
not a client-specific document.
1.2 Document Scope
This document is not intended to be a compendium of knowledge regarding system interfaces or

HL7 specifications.
For background information on HL7 Interface standards, see HL7.org.
1.3 Referenced Documents

This document is not intended to be a complete ADT or HL7 technical reference document. The following
documents can be a valuable resource in helping to understand the details of these items.
HIE Architecture Overview Diagram (Visio)
Client ADT to Medicity ADT Inbound Specification
HL7 2.x CH 3 Patient Administration
ProAccess CodeSet Spreadsheet
EMPI Patient Matching Specification
CMPI Patient Matching Documentation
2 Communications
2.1 Minimal Lower Level Protocol
Medicity will not use data validation mechanisms, such as checksums, often required with less reliable
connections.
The generalized interaction and exchange of data proceeds as follows:
1. The initiating system (i.e. the system with data to send) constructs an HL7 message and transmits the
message via an established connection to the receiving system.
2. The receiving system performs basic checks on the incoming message (ensures an HL7 wrapper
<SB>dddd<EB><CR>). These edits are negotiable, but typically includes checking for the presence
of required segments and possibly fields within segments. These basic checks focus on message
structure validity and do NOT include data validation (e.g., a valid patient number).
3. If the message passes the basic checks in step 2, the receiver commits the message to safe storage.
4. The receiver sends an acknowledgement MSA segment to the initiating system. The receiving system
sends the message on to the application layer, and the initiating system is free to send the next
message once the acknowledgement is received by the sending system.
5. In the event that the sending system does not receive an acknowledgement, Medicity expects the
sending system interface to automatically issue a TCP/IP Close Port Command, then recycle the
interface to a Connect To state. Medicity recommends that the sending system not setup an automatic
retry of sending the message prior to recycling the interface and be configured to recycle the interface
after not receiving an ACK.
6. Medicity recommends setting a maximum ACK timeout value of 5-10 seconds on the sending system.
3 Medicity Business Rules and

Guidelines
3.1.1 Validation Philosophy
The following is the design philosophy for pre and post-validation:
The Medicity required naming conventions defined for R/O fields will be used in the postvalidator.
The goal of the pre-validators is to ensure that the minimum required dataset is available for the
transformer to perform its transformations.
The goal of the post-validators is to ensure that the minimum required dataset is available in an
incoming message to meet all downstream requirements of the database-layer and applicationlayer.
If a message does not pass the validation rules, the message is de-queued for further attention
from the Applicable Support Team.
Validation Options Business Rules:
3.1.1.1
If a field is a Medicity required field, the post-validators will test that the field has a nonempty string value.
If more complex data validation is required (ex: Data is within a specified range of
values), the validation criteria are to be defined within the comments section of the
segment/field/component row of the data element table.
If conditional data validation is required (ex: Field X must be populated if Field Y

populated), the validation criteria are to be defined within the comments section of the
segment/field/component row of the data element table.
Pre-validation
If Medicity requires a field but the value for that field is sent in a different location, then Medicity will
generally apply pre-validation that that specific value is sent. This ensures that any error messages are
applicable to the received message.
3.1.1.2
Post-validation
Post-validation requirements may not be altered except by a Product Enhancement. Normally when a
requirement cannot be met by a client the requirement will be met by a transformation (i.e. default value)
or by a client change (i.e. revision to send the missing required value).
3.1.2 Patient Matching

Medicity performs EMPI matching within the scope of the given Facility or Clinical Account. Medicity
expects the MRN and account number format to be consistent between sending systems within a hospital
organization.
Patient Matching for each client interface will be referenced in a client specific Patient Matching
document.
3.1.2.1
Patient Identifiers configured for this interface
A client may store up to four of patient identifiers. The most commonly used identifiers are Internal
Patient Identifier and Patient Account Identifier.
Note: Within ProAccess, Internal Patient ID is considered the MRN. External Patient Identifier is used
as an EMPI patient identifier.
Note: Medicity matches identifiers by string and not by number. Medicity interprets 01234 and 1234
as two separate identifiers. It is important that data senders send idenifiers in the same format across all
feeds.
Identifier
Identifier in Medicity
Internal Patient Identifier
PID:3
External Patient Identifier
PID:2
Alternate Patient Identifier
PID:4
Patient Account Identifier
PID:18
3.1.2.2
Add/Update Setting
Typically, as the sole system of authority, the ADT system is the only feed that can both add and update
patient demographic data. The exception is for Reference Lab or Outreach Community Services for
which no ADT feed exists because the ancillary becomes the system of authority.
ProAccess has the capability of handling the creation/update of a patient record in the following ways:
Add/Update:
If the patient identified in an inbound message does not currently exist within this
ProAccess Organization, a new patient record will be added.
If the patient identified in an inbound message does currently exist within this
ProAccess Organization, the patient record will be updated with the patient
demographics within the inbound message.
Add Only:
If the patient identified in an inbound message does not currently exist within this
ProAccess Organization, a new patient record will be added.
If the patient identified in an inbound message does currently exist within this
ProAccess Organization, the patient record will not be updated with the patient
demographics within the inbound message.
Medicity does not require that the patient record exist before it receives a Lab Result.
If a result is received before the patient records exist, the patients record will be created based on
the demographics in the first received result. After that, any result that matches to the patient will not
update the patient demographics.
10
3.1.1 Encounter or Visit Matching

An ADT System sends a patient account number to which charges, payments, etc., are recorded. This is
required on all account-based events. The Medicity ProAccess system prefers to use the patient account
number (PID:18) to uniquely match all encounters. If a data sender uses the Visit Identifier (PV1:19) then
Medicity will copy that value to PID:18. This ensures all downstream systems can find the account/visit
identifier in the same place.
Identifier
Patient Account Identifier
PID:18
Visit Identifier
PV1:19
The values in the table above should only reflect the values to be used in this interface. If the visit
identifier is not used, the row should be grayed out.
3.1.2 Guarantor, Next of Kin, and Insured Matching

Guarantor, Next of Kin, and Insured will use free text matching on Name, Gender, DOB, and other
demographics or identifiers as received. Matching is performed only within the scope of the encounter on
that patient. Some downstream systems, such as Payors, may have their own requirement to receive the
discrete person identifier number.
Note: Formatting indicates whether the identifier is left-padded with zeros, alpha, or not at all. While
length is indicative of length, the length will vary when an identifier is not left-padded with zero. (i.e.
00999).
Identifier
Guarantor Number
GT1:2
Insureds ID Number
IN1:49
Next of Kin Identifier
NK1:33
3.1.3 Physician Matching

An ADT System always sends a unique identifier for physicians for all related positions to patients and
patients encounters. When a physician identifier is received that is not pre-built in the PersonnelRef table
the physician will be added. The physician ID can be a numeric, alpha, or alphanumeric format.
3.1.3.1
Physician Matching Business Rules:
If a physician ID is sent, Medicity will match on the ID. If there is no match by ID then Medicity will
create the physician record with the provided ID and name.
If a physician ID is not sent, Medicity attempts to match based on free text matching an agreed
upon free text physician ID and name.
Both ID and last name must be provided. If both are not provided, there will be impacts to
provider to patient relationships, result delivery, etc.
3.1.3.2
Physician Matching Common Issues:
If an ID is provided without a provider name, Medicity will write the ID to the provider table with
the name of Unknown Physician.
11
This feature will allow a relationship to be established between a provider ID and a patient/result.
Clients will often default a provider ID to a default provider ID if the provider is not known. This
default value must be included in this specification.
Format of physician ID needs to be standardized. If system A sends 0123 and system B sends
123 for the same provider, the data sender shall normalize the provider ID format between
systems.
The ID format must be consistent or made consistent across the ADT and all other interfaces.
Provider ID
Format
Attending Provider ID (PV1:7.1)
99999
A1234
MNEMONIC
7.1
Provider ID
7.2
Last Name
7.3
First Name
7.4
Middle Name
7.5
Prefix
7.6
Suffix
7.7
Degree
Note: Medicity expects that all Provider IDs will match the format of the Attending
Provider ID as described above.
Note: Medicity does not currently support the degree field.
3.1.3.3
Physician Free-text matching
If a physician record is created in freetext mode (we receive a provider name without an ID) Medicity will
create a freetext provider ID by setting the Provider ID to the unique string of FREETEXT.
Unless there is a need for an alternative, the free-text provider ID should always be FREETEXT. For
historical reasons the database parser can tailor this per contributing system but in the interests of
providing a common value to downstream systems, Medicity will now always use FREETEXT as the
default value.
Free-Text Physician Identifier
Ex. |^Smith^JohnÂ^Jr
Medicity will configure the database parser to accept

FREETEXT as the free-text provider ID.
Example: FREETEXT^Smith^JohnÂ^Jr
3.2 Nexus Metadata to be captured for this

Interface
Metadata is used on the Nexus engine for transaction searching purposes. Nexus is already configured to
provide a set of searchable items. The list of standard Metadata items and any custom items are listed
below. To ensure optimal performance, custom metadata elements are not available without approval
from the Medicity Product Management Team.
12
Metadata item to be captured:
Identified in Medicity after message transformation
SendingApplicationID
MSH:3
MessageControlID
MSH:10
Event
MSH:9.2
PatientID
PID:3
AlternatePatientID
PID:4
PatientLastName
PID:5.1
PatientMiddleName
PID:5.3
PatientFirstName
PID:5.2
PatientAccountNo
PID:18
13
4 ADT Trigger Events

Support for unsupported triggers depends on whether or not Medicity supports an equivalent trigger. For
example, if a client sends A38 (Cancel Pre-admit), Medicity can map that to the supported A11 (Cancel
admit). Triggers that are not supported or not equivalent should be filtered out by the sending system (i.e.
A37 Unlink Patient Information).
Medicity support the following HL7 trigger events for the HL7 ADT message type:
14
ADT Trigger Event
Event Code
Medicity
Supported
Database Parser
Method
Admit a Patient
A01
Yes
ADMIT
Transfer a Patient
A02
Yes
TRANSFER
Discharge a Patient
A03
Yes
DISCHARGE
Register a Patient
A04
Yes
REGISTER
Pre-admit a Patient
A05
Yes
PREADMIT
Transfer Outpatient to Inpatient
A06
Yes
TRANSOUTTOIN
Transfer Inpatient to Outpatient
A07
Yes
TRANSINTOOUT
Update Patient Information
A08
Yes
UPDATEPATIENT
Patient departing - tracking
A09
No
Patient arriving - tracking
A10
No
Cancel Admit
A11
Yes
CANCELADMIT
Cancel transfer
A12
Yes
TRANSFER
Cancel Discharge
A13
Yes
CANCELDISCHARGE
Pending Admit
A14
Yes
UPDATEPATIENT
Pending transfer
A15
No
Pending discharge
A16
No
Swap a Patient
A17
Yes
Merge patient information
A18
No
Patient query
A19
No
Bed status update
A20
No
Leave of Absence Leaving
A21
Yes
UPDATEADMIT
Leave of Absence Returning
A22
Yes
UPDATEADMIT
Delete a patient record
A23
No
Link patient information
A24
No
Cancel pending discharge
A25
No
Cancel pending transfer
A26
No
Cancel pending admit
A27
No
Add person information
A28
Yes
ADDPERSON
Delete person information
A29
Yes
DELETEPATIENT
Merge person information
A30
No
SWAP
ADT Trigger Event
Event Code
Medicity
Supported
Database Parser
Method
Update person information
A31
Yes
UPDATEPERSON
Cancel patient arriving - tracking
A32
No
Cancel patient departing - tracking
A33
No
Merge patient information - patient ID

only
A34
No
Merge patient information - account

number only
A35
No
Merge patient information - patient ID

and account number
A36
No
Unlink patient information
A37
No
Cancel pre-admit
A38
No
Merge person - external ID
A39
No
Merge patient - internal ID
A40
Yes
MERGEPATIENT
Merge account - patient account

number
A41
Yes
MERGEACCOUNT
Merge visit - visit number
A42
No
Move patient information - internal ID
A43
No
Move account information - patient

account number
A44
Yes
Move visit information - visit number
A45
No
Change external ID
A46
No
Change internal ID
A47
No
Change alternate patient ID
A48
No
Change patient account number
A49
No
Change visit number
A50
No
Change alternate visit ID
A51
No
MOVEACCOUNT
15
5 Message Structure Definition

This chapter includes information on defining messages and processing messages.
5.1 Messages
The following sections describe HL7 messages and segments and describe of the structure of those
messages.
5.1.1 Admit a Patient (A01)

The Medicity ADT Inbound interface will accept admissions of all patient types through the interface. The
Medicity ADT Inbound interface will process A01 messages with the following configurable choice of
procedures. All segments grayed out were discussed but not used. The below indicates if a segment is
required by Medicity. If required, then by agreement either sending source has to send the required
segment or Medicity can supply a default.
The Medicity ADT Database Parser will use the listed options and message structure for the following
events: A01, A02, A03, A04, A05, A06, A07, A08, A11, A12, A14, A21, and A22:
5.1.1.1
Admit a Patient (A01) Message Structure
Message
Event TYPE: ADT
Event CODE: A01
Notes:
16
The cardinal order of the segments below shall be followed as defined in the table below.
Medicity requires the segments to be sent in this specific order.
Any Medicity-optional segments not sent by the data provider should be grayed out in the table
below.
If additional segments are requested by the client, a formal product change request must be
submitted and will be considered for a future product release.
If a client sends a Z segment that contains data that needs to be mapped to a supported
segment, it must be listed in the table below. Custom mapping between the Z segment and the
supporting segment will be defined in the custom processing of the segment that will receive the
Z segment data.
If a client sends a Z segment that Medicity can ignore in its entirety, the segment should be listed
in the table below and grayed out with a comment that Medicity will not support this segment.
Segment
Segment Name
Pre-validator
Post-validator
Comments
MSH
Message Header
Required by Medicity
EVN
Event Type
PID
Patient Identification
Not supported
R
[PD1]
Additional
Demographics
[ { NK1 } ]
Next of Kin
PV1
Patient Visit
[PV2]
Additional Patient
Visit
[ { AL1 } ]
Allergy Information
[ { DG1 } ]
Diagnosis
Information
[ { PR1 } ]
Procedures
[ { GT1 } ]
Guarantor
Required by Medicity in
visit-level messages
like the A01. Not
required in person-level
messages like the A31.
[
{ IN1
Insurance
Information
[ IN2] }
Insurance
Additional Info
]
[ACC]
Accident Information
Repeating Segments processing:

The segments which repeat in HL7 messages Patient Administration (ADT)/Financial Information
messages (AL1, DG1, GT1, IN1, IN2, and NK1) present a problem if the requirement is to update only
part of the information previously sent. Prior to Version 2.3 of the Standard, all such repeating segments
had to be sent again in the update, because there was no way to indicate which ones changed and which
ones did not. For example, if two DG1 segments were sent originally (containing a primary and secondary
diagnosis), and then if a tertiary diagnoses needed to be sent, the sending system had to send all
diagnoses which were currently valid, that is, three DG1 segments (containing primary, secondary and
tertiary diagnosis). This way of doing things is referred to as the snapshot mode. In this mode,
everything (all repeating segments) must be sent with every subsequent message in the series of
messages. Medicity will honor only the snapshot mode of updating these segment groups.
5.1.2 Transfer a Patient (A02)

The Medicity ADT Inbound interface will process the A02 transfer message to change the facility, nurse
unit, room, and bed for patients assigned to a room and the bed. The inbound interface will process A02
messages with the following configurable choice of events.
5.1.2.1
Transfer a Patient (A02) Message Structure
Message
Same as the Admit a Patient (A01) message.
17
5.1.3
Discharge a Patient (A03)
Medicity ADT Parser will process the A03 discharge message to update the discharge date and time for
any encounter type. Discharge transactions will be sent by the ADT System for all encounter types.
The Medicity ADT Parser server will not null location codes on the encounter row.
5.1.3.1
Discharge a Patient (A03) Message Structure
Message
5.1.4 Register a Patient (A04)

The Medicity ADT Inbound interface will accept A04 Patient Registrations through this interface. Medicity
recommends that the A04 message apply to non-inpatient populations including emergency room,
outpatient, and any non-inpatient registrations.
5.1.4.1
Register a Patient (A04) Message Structure
Message
5.1.5 Pre-Admit a Patient (A05)

The Medicity ADT Inbound interface will accept and process pre-admissions or pre-registrations from an
external system using the A05 message.
The ADT System will send the Admit Date and Time with a future date for the Admit.
5.1.5.1
Pre-Admit a Patient (A05) Message Structure
Message
5.1.6 Transfer Outpatient to Inpatient (A06) and Transfer

Inpatient to Outpatient (A07)
The Medicity ADT Inbound interface can accept HL7 Transfer Outpatient to Inpatient and Transfer
Inpatient to Outpatient events.
5.1.6.1
Transfer Outpatient to Inpatient (A06) and Transfer Inpatient to

Outpatient (A07) Message Structure
Message
18
5.1.7 Update Patient Information (A08)

The Medicity ADT Inbound interface will accept update message (A08) to modify patient demographic
and encounter information.
ProAccess interface processing considers changes to Patient Types as update events. Patient location
transfers can be processed as update events allowing the ProAccess interface programs to transfer
patients using an update transaction if the Patient Management system cannot send the A02 transfer
event.
If an Update transaction is transmitted and there is no existing person row or encounter row, a
configurable interface parameter will determine if the Medicity ADT Parser server will add the person or
encounter information to the database.
ProAccess interface processing requires that optional segments be transmitted for an update only when a
change to a field in that segment has occurred. However, if one data element in an optional segment
changes, Medicity requires that the sending system value all fields (changed and unchanged) in the
optional segment.
5.1.7.1
Update Patient Information (A08) Message Structure
Message
5.1.8 Cancel Patient Admit (A11)

Cancel Patient Admit (A11) messages will use the same message structure as defined for Patient Arriving
(A01).
The Medicity ADT Parser will process a Cancel Admit (A11) as an update to change the encounter from
an inpatient back to a pre admit or outpatient as defined in the PV1 segment. The Medicity ADT Parser
requires the message to contain data values expected at the end of Cancel Admit processing. The
Medicity ADT Parser will update but not inactivate the encounter. The Medicity ADT Parser will not
automatically null any specific encounter fields; instead, the Medicity ADT Parser expects the sending
system to send the HL7 null to erase unwanted dates or coded data elements.
The ADT System will send the admit date and time back to the future date and time rendering the
encounter as a Pre-registration.
5.1.8.1
Cancel Patient Admit (A11) Message Structure
Message
5.1.9 Cancel Transfer (A12)

Cancel Patient Transfer (A12) messages will use the same message structure as defined for Patient
Arriving (A01).
The Medicity ADT Parser will process a Cancel Patient Transfer (A12) as an update to change the
encounter from an inpatient back to a pre admit or outpatient as defined in the PV1 segment. The
Medicity ADT Parser requires the message to contain data values expected at the end of Cancel Admit
processing. The Medicity ADT Parser will update but not inactivate the encounter. The Medicity ADT
19
Parser will not automatically null any specific encounter fields; instead, the Medicity ADT Parser expects
the sending system to send the HL7 null to erase unwanted dates or coded data elements.
The ADT System will send the admit date and time back to the future date and time rendering the
encounter as a Pre-registration.
5.1.9.1
Cancel Transfer (A12) Message Structure
Message
5.1.10 Pending Admit (A14)

The Medicity ADT Inbound interface will accept and process pre-admissions or pre-registrations from an
external system using the A14 message
The ADT System will send the Admit Date and Time with a future date for the Admit.
5.1.10.1 Pending Admit (A14) Message Structure

Message
5.1.11 Swap Patients (A17)

The Medicity ADT Parser will accept and process a swap transfer message for two patients assigned to a
room and bed.
See 5.1.2 Transfer a Patient (A02) for processing logic and constraints associated with room and bed
transfers.
If the patient management system is unable to send the swap event, the Medicity ADT Parser can accept
and process multiple A02 transfer messages.
5.1.11.1 Swap Patients (A17) Message Structure

Message
Event TYPE: ADT
Event CODE: A17
20
Segment
Segment Name
MSH
Message Header
EVN
Event Type
PID
[ PD1 ]
Additional Demographics
PV1
Patient Visit
PID
Patient (2) Identification
Comments
[ PD1 ]
Additional Demographics (2)
PV1
Patient (2) Visit
HL7 2.4 - New segment
5.1.12 Leave of Absence - Leaving (A21) and Leave of Absence Returning (A22)
Medicity ADT Parser processes the Leave of Absence Leaving (A21) and Leave of Absence Return (A22)
as an A08 Patient Update.
5.1.12.1 Leave of Absence - Leaving (A21) and Leave of Absence Returning (A22) Message Structure
Message
5.1.13 Add Person Information (A28)

The purpose of the A28 ADT trigger events is to allow sites with multiple systems and respective master
patient databases to communicate activity related to a person regardless of whether that person is
currently a patient on each system. Each system has an interest in the database activity of the others in
order to maintain data integrity across an institution. Though they are defined within the ADT message
set, these messages differ in that they are not patient-specific. To a certain registry, the person may be a
person of interest, a potential future patient, or a potential guarantor. For example, these events can be
used to maintain an MPI (master patient index), a cancer registry, members of a managed care plan, an
HIV database, etc.
These events should not replace the use of the A01 (admit/visit notification), A03 (discharge/end visit),
A04 (register a patient), A08 (update patient information), etc., events. They are not intended to be used
for notification of real-time Patient Administration events. These events are primarily for demographic
data, but optional historical non-demographic data may be sent as well.
The Medicity database parser will treat an A28 the same as any ADT event if the patient record did not
exist. Some systems include encounter-level data in their A28 messages. The Medicity database parser
will ignore these portions of the messages.
5.1.13.1 Add Person Information (A28) Message Structure

Message
Event TYPE: ADT
Event CODE: A28
Segment
Segment Name
Comments
MSH
Message Header
EVN
Event Type
PID
[ PD1 ]
{ [ NK1 ] }
Next of Kin
21
5.1.14 Delete Person Information (A29)

The purpose of the A29 ADT trigger events is to allow sites with multiple systems and respective master
HIV database, etc.
The A29 ADT trigger event will only delete a person if no encounter data exists for that person. Only
persons existing in the CDR and MPI from an A28 ADT trigger or an A31 ADT trigger will be affected by
an A29. An A29 received for a patient that has encounter data will be ignored.
5.1.14.1 Delete Person Information (A29) Message Structure

Message
Event TYPE: ADT
Event CODE: A29
Segment
Segment Name
Comments
MSH
Message Header
EVN
Event Type
PID
[ PD1 ]
{ [ NK1 ] }
Next of Kin
5.1.15 Update Person Information (A31)

The purpose of the A31 ADT trigger event is to allow sites with multiple systems and respective master
HIV database, etc.
22
5.1.15.1 Update Person Information (A31) Message Structure

Message
Event TYPE: ADT
Event CODE: A31
Segment
Segment Name
Comments
MSH
Message Header
EVN
Event Type
PID
[ PD1 ]
{ [ NK1 ] }
Next of Kin
5.1.16 Merge Patient Internal ID (A40)

The A40 merge event is performed at the patient identifier list level when two PID:3 - Patient Identifier
List identifiers have been merged into one.
The purpose of an A40 event is to signal a merge of records for a patient that was incorrectly filed under
two different identifiers. The incorrect source identifier identified in the MRG segment (MRG:1 - Prior
Patient Identifier List) is to be merged with the required correct target identifier of the same identifier
type code component identified in the PID segment (PID:3 - Patient (MRN) Identifier List). The incorrect
source identifier would then logically never be referenced in future transactions. It is noted that some
systems may still physically keep this incorrect identifier for audit trail purposes or other reasons
associated with database index implementation requirements.
The identifiers involved in identifying the patients may or may not have accounts/encounters, which may
or may not have visits. An A40 (merge patient-patient identifier list) event is intended for merging patient
records without merging other subordinate identifiers. Any other subordinate identifiers that were
previously associated with the incorrect source identifier are now associated with the correct target
identifier. Specification of these other subordinate identifiers is not required.
This event and the message syntax do, however, allow for the specification of any other new subordinate
identifiers (in addition to the PID:3 - Patient Identifier List identifier). For those environments that may
require changes to these other subordinate identifiers because of the A40 (merge patient-patient identifier
list) event, it is required that the old and new identifiers be a tightly coupled pair.
The fields included when this message is sent should be the fields pertinent to communicate this event.
When other fields change, it is recommended that the A31 (update person information) event be used for
person level updates and A08 (update patient information) event for patient level updates.
23
5.1.16.1 Merge Patient Internal ID (A40) Message Structure

Message
Event TYPE: ADT
Event CODE: A40
Segment
Segment Name
MSH
Message Header
EVN
Event Type
Comments
{
PID
[ PD1 ]
MRG
Merge Information
5.1.17 Merge Account - Patient Account Number (A41)

The A41 merge event is performed at the account/encounter identifier level when two PID:18 - Patient
Account Number identifiers have been merged into one. The account/encounters are always for the
same patient.
An A41 event is used to signal a merge of records when an account/encounter was incorrectly filed under
two different account/encounter numbers. The incorrect source patient account number identified in the
MRG segment (MRG:3 - Prior Patient Account Number) is to be merged with the correct target patient
account number identified in the PID segment (PID:18 - Patient Account Number). The incorrect source
patient account number would then logically never be referenced in future transactions. It is noted that
some systems may still physically keep this incorrect identifier for audit trail purposes or other reasons
associated with database index implementation requirements.
The patient account/encounter numbers involved may or may not have visits. An A41 (merge accountpatient account number) is intended for merging account/encounter records without merging other
subordinate identifiers. Any other subordinate identifiers previously associated with the incorrect source
account number are now associated with the required correct target account number. Specification of
these other subordinate identifiers is not required.
This event and the message syntax do, however, allow for the specification of any other new subordinate
identifiers (in addition to the PID:18 - Patient Account Number identifier). For those environments that
may require changes to these other subordinate identifiers because of this A41 (merge account-patient
account number) event, it is required that the old and new identifiers be a tightly coupled pair.
Each superior identifier associated with this account/encounter identifier level should have the same
value in both the PID and MRG segments.
When other fields change, it is recommended that the A08 (update patient information) event be used in
addition.
If either the source or destination patient does not exist, the record will be created.
24
5.1.17.1 Merge Account Patient Account Number (A41) Message

Structure
Message
Event TYPE: ADT
Event CODE: A41
Segment
Segment Name
Comments
MSH
Message Header
EVN
Event Type
{
PID
[ PD1 ]
MRG
Merge Information
[PV1]
Visit Information
5.1.18 Move Account Information Patient Account Number

(A44)
The A44 move event is performed at the account/encounter identifier level. That is, a PID:18 - Patient
Account Number associated with one PID:3 - Patient (MRN) Identifier List has been moved to another
patient identifier list.
The purpose of an A44 event is used to signal a move of records identified by the MRG:3 - Prior Patient
Account Number from the incorrect source patient identifier list identified in the MRG segment (MRG:1 Prior Patient Identifier List) to the correct target patient identifier list identified in the PID segment (PID:3
Patient (MRN) Identifier List).
The account/encounter number involved in identifying the account/encounter to be moved (MRG:3 - Prior
Patient Account Number) may or may not have visits. In any case, all subordinate data sets associated
with the account/encounter number in MRG:3 - Prior Patient Account Number are moved along with the
account/encounter number, from the incorrect source ID (MRG:1 - Prior Patient Identifier List) to the
correct target ID (PID:3 - Patient (MRN) Identifier List).
No identifiers subordinate to the account/encounter number (visit number, alternate visit ID) are valued in
this message.
This event and the message syntax do, however, allow for the specification of a new identifier (PID:18
Patient Account Number), which may be application and/or implementation-specific and therefore require
site negotiation.
All of the identifiers superior to the account/encounter number should be valued in both the MRG
segment and the PID segment. In this message, the PID:3 - Patient (MRN) Identifier List is superior to
the account/encounter number.
When demographic data in other fields change, it is recommended that the A08 (update patient
information) event be used in conjunction with this message. However, all PID data associated with the
account number are treated as updated information
25
5.1.18.1 Move Account Information Patient Account Number (A44)

Message Structure
Message
Event TYPE: ADT
Event CODE: A44
Segment
Segment Name
MSH
Message Header
EVN
Event Type
Comments
{
PID
[ PD1 ]
Required by Medicity in move

transactions for security
considerations.
MRG
Merge Information
26
6 HL7 Segment Layouts

This chapter defines HL7 data segments supported in an ADT interface from a non-Medicity system to
ProAccess.
The Segment Definition Tables are populated as follows:
HL7 Segment Layouts - Column Heading Explanation

Heading
Contents
Values
Seq
HL7 Field Sequence
Begins with 01 for each segment.
Name
HL7 Field Name
Defined by HL7.
R/O
Field/Component
Required by ProAccess
R - Medicity required field

N - Not supported by Medicity
C - Conditional
O - Optional
R - Client Required
N - Client Not Supported
C - Client Conditional
O - Client Optional
Rules regarding graying out rows
R - Always white
N - Always gray
C - Can grey
O - Can grey
R - Always white
N - Can grey
C - Always white
O - Always white
Business Rules
When client downstream system has a requirement
to have a Medicity Optional field as required,
maintain Medicity notation and add a '-' and add the
client 'R' notation
When a field is conditional, the conditions must be
defined in the comments section of the data element
When a Conditional or Optional field is grayed out by
the spec writer, the reason why must be defined in
the comments section.
Comment
ProAccess Field Usage

Comments
Note: Rows displayed in gray were reviewed but will not be used in this interface.
If a field is marked as not supported by Medicity, an application enhancement would be required to add
the additional data and would need to be a part of a sanctioned product release.
27
If a field is marked as required by Medicity and cannot be provided by the data provider, a formal HL7
configuration discussion must take place between Medicity and the client as adverse effects will be
encountered within the product if required data cannot be provided.
6.1
Control Segments
6.1.1 The MSH Segment - Message Header

The MSH segment defines the characteristics of the message. The sending and receiving applications
are identified. The encoding characters used as delimiters for the message are also indicated. The MSH
message type is used to indicate the type of message being transmitted.
In the MSH of the ACK response, the values of the Sending Application, Sending Facility, Receiving
Application, and Receiving Facility will be the reverse of the values in the original message.
Note: The entry in the R/O column is Post-validator.
Segment Layout
MSH Seq
Name
R/O
Comments
01
Field separator
Field separator.
Value required is | ASCII(124)
02
Encoding Character
Used to separate data field components, repeating

data elements, and text control characters. Must be
printable characters that will never be included in
transmitted data.
Required values:
Pos 1: Component Separator ^ - ASCII(94)
Pos 2: Repetition Separator ~ - ASCII(126)
Pos 3: Escape \ - ASCII(92)
Pos 4: Sub-component & - ASCII(38).
03
Sending Application
Medicity requires that this be a unique value per

contributing system, per-facility.
04
Sending Facility
Medicity expects the ancillaries to contain the same

MSH:4 value as the ADT feed, if applicable.
05
Receive Application
Medicity will hard-code this field to Medicity.
06
Receiving Facility
07
Date/Time of Message
08
Security
09
Message Type
Specific HL7 message type and event triggering the

message.
09.1
Type
Value must = ADT and must be sent by the source

system.
09.2
Event
See Chapter 5 - ADT Trigger Events for allowable ADT

event triggers.
Initiator generated. Should be but is not always
10
28
System date and time the message was formatted in

the sending system.
Message Control ID
MSH Seq
Name
11
Processing ID
R/O
11.1
Processing ID
11.2
Mode
12
Version ID
13
Sequence Number
14
Continuation Number
15
Accept ACK Type
16
Application ACK Type
17
Country Code
18
Character Set
19
Language of Message
Comments
unique. Medicity will replace the received value with a
unique Medicity identifier (aka thread ID).
Acceptable values:
P = Production
HL7 version. Medicity currently transforms HL7 that is

received to version 2.3. Medicity can accept HL7
version 2.1 2.5.
6.1.2 The MSA Segment - Message Acknowledgment Segment

The MSA segment is returned as part of MSH, MSA pair in the ACK message type.
Segment Layout
MSA Seq
Name
01
Acknowledge Code
R/O
R
Comments
Acceptable values:
AA = ACK = message stored
AE = NACK = message rejected due to content
issue.
AR = NACK = message rejected due to internal
system error.
See HL7 CH 2 for more information on this topic.
02
Message Control ID
03
Text Message
04
Expected Sequence Number
05
Delayed ACK Type
06
Error Condition
Echo MSH segment control ID (MSH:10) of

message being acknowledged.
Original Message:
MSH|^~\&|ABCADT|ABC|Medicity||19960214134522||ADTÂ01|A13345.78|P|2.3
Acknowledgement (Immediate Original Processing Rules):

MSH|^~\&|Medicity|ABC|ABCADT||19960214134522||ACK|A13345.78|P|2.3
MSA|AA|A13345.78
29
6.2 ADT Segments

6.2.1 The EVN Segment Event Type (Ignored)
This segment is not used for Medicity ADT messages. The EVN segments communicate the event
trigger information to the receiving application.
Segment Layout
EVN Seq
Name
R/O
01
Event Type Code
02
Date/Time of Event
03
Date/Time Planned Event
04
Event Reason Code
05
Operator ID
06
Event Occurred
Comments
6.2.2 The PID Segment - Patient Identification

The PID segment identifies the person and usually the encounter associated with the message. Patient
demographic information is also provided. ProAccess requires at least one primary Patient or Person
Identifier.
Segment Layout
PID Seq
Name
01
Set ID - PID
02
External Patient ID
See Chapter 4 - Medicity Business Rules and

Guidelines.
Comments
This may be a criteria in the Medicity

Community Patient Matching (CMPI), but only
between facilities whose External MRN share
the same OID.
02.1
Patient ID
02.2
Check Digit
02.3
Check Digit Scheme
02.4
Assigning Authoring
This is implied to be the parent of the

organization identified the MSH:4.
02.5
Identifier Type
This can vary, but generally is implied to be a

cross-facility identifier. Sometimes called an
Enterprise or External Identifier.
02.6
Assigning Facility

Guidelines.
This is Medicitys MRN. What is in this field is

displayed as the MRN in the application.
Medicity must receive this from the data
contributor. Its format must match the format
received in the ADT feed.
03
30
R/O
Internal Patient ID
PID Seq
Name
R/O
Comments
Unfortunately, Medicity does not yet support
repetitions in this field.
This is a criteria in the Medicity Enterprise
Patient Matching (EMPI).
03.1
Patient ID
03.2
Check Digit
03.3
Check Digit Scheme
This is implied to be the same as MSH:4.
03.4
Assigning Authoring
This is a Medical Record Number.
03.5
Identifier Type
03.6
Assigning Facility
Alternate Patient ID
04

Guidelines.
04.1
Patient ID
04.2
Check Digit
04.3
Check Digit Scheme
This is implied to be the same as MSH:4.
04.4
Assigning Authoring
While other identifiers can be stored here, only

one identifier type may be stored here.
04.5
Identifier Type
04.6
Assigning Facility

Patient Matching (EMPI) and Community
Patient Matching (CMPI).
Patient Name
EMPI matches on the exact name.
05.1
Last Name
CMPI matches on the sound of the name.
05.2
First Name
CMPI matches on the middle initial.
05.3
Middle Name
05.4
Suffix
05.5
Prefix
05.6
Degree
05
06
Mothers Maiden Name

07
Date of Birth
See Codeset: CS_GENDER

08
Sex

09
Patient Alias
09.1
Last Name
09.2
First Name
09.3
Middle Name
09.4
Suffix
31
PID Seq
32
Name
R/O
Comments
09.5
Prefix
09.6
Degree
See Codeset: CS_RACE

10
Race
This is a criteria in the Medicity Community

11
Patient Address

11.1
Address Line 1
11.2
Address Line 2
11.3
City
11.4
State
11.5
ZIP Code
11.6
Country
11.7
Type
11.8
Other Geographic Designation
11.9
County/Parish
11.10
Census Tract
12
County Code
18 character limit - Suggested format: (999)

999-9999
This is a criteria in the Medicity Community
Patient Matching (CMPI). Formatting does not
impact its matching.
13
Home Phone Number

999-9999
14
Business Phone Number
See Codeset: CS_LANGUAGE
15
Language Patient
See Codeset: CS_MARITAL_STATUS
16
Marital Status
See Codeset: CS_RELIGION
17
Religion

Guidelines.
18
Patient Account Number

Patient Matching (EMPI)
18.1
Patient Account Number
18.2
Check Digit
18.3
Check Digit Scheme
18.4
Assigning Authority
18.5
Identifier Type
18.6
Assigning Facility
Can be last 4 digits, but all nine are

recommended for matching. Display can be
masked so no digits, only the last 4, or all are
displayed.
12 character limit - Suggested format 999-999999.
PID Seq
Name
R/O
Comments
Patient Matching (CMPI). Formatting does not
impact its matching.
19
SSN Patient
20
Drivers License Number
21
Mothers Identifier
See Codeset: CS_ETHNIC_GROUP

While the client can express it as granularly as
they like, only the top-level CDC values are
commonly seen: Is Hispanic or Is not
Hispanic.
22
Ethnic Group
100 character limit
23
Birth Place
Acceptable values:
Y = Yes
N = No
24
Multiple Birth Indicator
25
Birth Order
26
Citizenship
27
Veterans Military Status
See Codeset: CS_NATIONALITY
28
Nationality
Date/time at which the death occurred.
29
Patient Death Date/Time
Acceptable values:
Y = the patient is deceased
N = the patient is not deceased
30
Patient Death Indicator
See Codeset: CS_CITIZENSHIP
6.2.3 The PD1 Segment - Patient Demographic Segment

The HL7 2.5 PD1 patient demographic segment contains likely-to-change patient demographic information. The
PD1 segment is optional and follows the PID segment in any ADT message for any ADT event trigger code.
Segment Layout
PD1 Seq
Name
R/O
01
Living Dependency
02
Living Arrangement
03
Primary Care Facility
04
Primary Care Provider
Medicity will not accept repeating fields for PD1:4

only a single occurrence is allowed.
If PD1:4 is sent, 4.1 and 4.2 are required.
04.1
Primary Care Provider ID
04.2
Last Name
04.3
First Name
04.4
Middle Name
04.5
Suffix
04.6
Prefix
04.7
Degree
Comments
33
04.8
Source Table
04.9
Assigning Authority
04.10
Name Type
04.11
Check Digit
04.12
Check Digit Scheme
04.13
Identifier Type
05
Student Indicator
06
Handicap
07
Living Will
08
Organ Donor
09
Separate Bill
10
Duplicate Patient
11
Privacy Type
12
Protection Indicator
See Codeset: CS_PROTECTION_IND See Medicity

Business Rules and Guidelines below.
13
Effective Date/Time
This field indicates the effective date/time for PD1:12.

Note: The time part of this field is required. A date
is not sufficient because the time must change when
the Protection Indicator changes
See Medicity Business Rules and Guidelines below.
6.2.3.1
See Codeset: CS_STUDENT

See Codeset: CS_LIVING_WILL
PD1 Medicity Business Rules and Guidelines
Definitions include:
HIPAA OPT-IN
HIPAA OPT-OUT
Subdefinitions include:
Y^Yes (means protected)
N^No (means not protected)
Medicity will use this field to allow the upstream ADT system of authority to indicate the consent status of
a patient within the HIE. Medicity will use this field to allow the upstream ADT system of authority to
indicate the patients OPT-IN or OPT-OUT setting. The Codeset will use the definition values of "HIPAA
OPT-IN" and "HIPAA OPT-OUT".
The standard Codeset value for Opt-In is OI and OO for Opt-Out. Medicity highly recommends the use
of these two codes because they are the defined HL7 2.6 standard values. Medicity can support other
Codeset values on a per-implementation basis, but does not recommend this.
The Subdefinition is required for the HIPAA defined codes.
The Subdefinition is required for legacy clients (using PA 5) that are populating PD1:12 with their VIP
indicator values.
34
The Subdefinition will determine if the values with no definition of HIPAA OPT-IN/OUT are protected or
not at the data source level
Protection Indicator Effective Date/Time
To ensure a value is set Medicity commonly uses the following rules. If appropriate, custom processing
may be defined below in the custom processing section.
Look at PD1:12. If valued, and the value has a Definition of HIPAA OPT-IN or HIPAA OPT-OUT,
PD1:13 MUST be populated.
6.2.1 The MRG Segment - Merge Patient Information

The MRG segment contains the incorrect patient identifier and the incorrect patient account number.
MRG Seq
Name
R/O
01
Prior Patient Identifier List
02
Prior Alternate Patient ID
03
Prior Patient Account

Number
04
Prior Patient ID
05
Prior Visit Number
06
Prior Alternate Visit ID
07
Prior Patient Name
Comments
Required for A40 and A44 messages.
Required for A41 and A44 messages.
6.2.2 The NK1 Segment - Next of Kin

The NK1 segment contains information about the patients other related parties. Medicity displays the
Next of Kin under the label Emergency Contact.
Segment Layout
NK1 Seq
Name
R/O
01
Set ID - NK1
02
Next of Kin Name
02.1
Last Name
02.2
First Name
02.3
Middle Name
02.4
Suffix
02.5
Prefix
02.6
Degree
03
Next of Kin Relationship to

Patient
04
Next of Kin Address
Comments
See Codeset: CS_REL_TO_PERSON
35
NK1 Seq
36
Name
R/O
04.1
Address Line 1
04.2
Address Line 2
04.3
City
04.4
State
04.5
ZIP Code
04.6
Country
04.7
Type
04.8
Other Geographic
04.9
County/Parish
04.10
Census Tract
Comments
See: Medicity Base Codeset
05
Next of Kin Phone Number

999-9999
06
Next of Kin Employer Phone

Number

999-9999
07
Contact Role
08
Start Date
09
End Date
10
Next of Kin Job Title
11
Next of Kin Job Code/Class
11.1
Job Code
11.2
Job Class
12
Next of Kin Employee Number
13
Organization Name
14
Marital Status
15
Sex
16
Date of Birth
17
Living Dependency
18
Ambulatory Status
19
Citizenship
20
Primary Language
21
Living Arrangement
22
Privacy Type
23
See Codeset: CS_PROTECTION_IND See

Medicity Business Rules and Guidelines below.
24
Student Indicator
25
Religion
26
Mothers Maiden Name
27
Nationality
28
Ethnic Group
29
Contact Reason
NK1 Seq
Name
30
Contact Person Name
31
Contact Phone
32
Contact Address
33
NK1 Identifiers
34
Job Status
35
Race
36
Handicap
37
Contact Person Social Security

Number
38
Next of Kin Birth Place
39
VIP Indicator
6.2.2.1
R/O
Comments
List of components if present.

See Codeset: CS_VIP_IND See Medicity

Business Rules and Guidelines below.
NK1 Medicity Business Rules and Guidelines
The sending system must include all NK1 segments for this encounter. The Medicity ADT Parser will
update NK1 segments as a unit.
Example: Transaction 1 for same patient & encounter is sent with 2 NK1 segments. Transaction 2 for
same patient & encounter is sent with 1 NK1 segment. Only the NK1 segment sent in the second
transaction is preserved as HL7 does not support the discrete removal of NK1 entries.
Definitions include:
HIPAA OPT-IN
HIPAA OPT-OUT
Y^Yes (means confidential)
N^No (means not confidential)
Medicity will use this field to allow the upstream ADT system of authority to indicate the protection
indicator confidentiality status of a provided insurance at the encounter level. The Subdefinition for the
codeset will determine if the specified diagnosis for the encounter is now confidential (not viewable) or
notconfidential (viewable).
37
6.2.3 The PV1 Segment - Patient Visit

The PV1 segment provides visit or encounter specific information.
Segment Layout
PV1 Seq
Name
01
Set ID - PV1
Starts at 1; increments by 1.
02
Patient Class
See Codeset: CS_ENCOUNTER_CLASS

Required by Medicity to determine IP/OP status.
03
Patient Location
03.1
Point of Service Location
03.2
Patient Room
03.3
Patient Bed
03.4
Facility ID
03.5
Bed Status
03.6
Location Type
03.7
Building
03.8
Floor
Comments
04
Admission Type
05
Pre-admit Number
06
Prior Patient Location
07
Attending Doctor
Medicity will not accept repeating fields for PV1:7

The value in this field can be used to determine
result delivery routing to an end user.
See Codeset: CS_ADMIT_TYPE
If PV1:7 is sent, 7.1 and 7.2 are required.
07.1
Attending Doctor ID
07.2
Last Name
07.3
First Name
07.4
Middle Name
07.5
Suffix
07.6
Prefix
07.7
Degree
07.8
Source Table
07.9
Assigning Authority
07.10
Name Type
07.11
Check Digit
07.12
Check Digit Scheme
07.13
Identifier Type
Referring Doctor
Medicity will not accept repeating fields for PV1:8

08
08.1
38
R/O
Referring Doctor ID
PV1 Seq
Name
R/O
Comments
08.2
Last Name
08.3
First Name
08.4
Middle Name
08.5
Suffix
08.6
Prefix
08.7
Degree
08.8
Source Table
08.9
Assigning Authority
08.10
Name Type
08.11
Check Digit
08.12
Check Digit Scheme
08.13
Identifier Type
Consulting Doctor

Medicity will accept repeating fields for PV1:9.
Each repetition must be for a different person.
There is no max limit on repetitions.
There should be no blank repetitions between
valid repetitions.
09
09.1
Consulting Doctor ID
09.2
Last Name
09.3
First Name
09.4
Middle Name
09.5
Suffix
09.6
Prefix
09.7
Degree
09.8
Source Table
09.9
Assigning Authority
09.10
Name Type
09.11
Check Digit
09.12
Check Digit Scheme
09.13
Identifier Type
10
Hospital Service
11
Temporary Location
12
Pre-admit Test Indicator
13
Re-admission Indicator
14
Admission Source
15
Ambulatory Status
16
VIP Indicator
See Codeset: CS_ADMIT_SERVICE
See Codeset: CS_ADMIT_SOURCE

See Codeset: CS_VIP_IND
See below for the PV1 Business Rules and
Guidelines.
39
PV1 Seq
Name
17
Admitting Doctor
Comments
Medicity will not accept repeating fields for

PV1:17 only a single occurrence is allowed.
17.1
Admitting Doctor ID
17.2
Last Name
17.3
First Name
17.4
Middle Name
17.5
Suffix
17.6
Prefix
17.7
Degree
17.8
Source Table
17.9
Assigning Authority
17.10
Name Type
17.11
Check Digit
17.12
Check Digit Scheme
17.13
Identifier Type
18
Patient Type
See Codeset: CS_ENCOUNTER_TYPE
19
Visit Number
See Section 3.1.3 Encounter or Visit Matching

If this field contains the same visit identifier as the
ADT, then Medicity will also store it in PID:18.
20
Financial Class
See Codeset: CS_FINANCIAL_CLASS
21
Charge Price Indicator
22
Courtesy Code
23
Credit Rating
24
Contract Code
25
Contract Effective Date
26
Contract Amount
27
Contract Period
28
Interest Code
29
Transfer to Bad Debt Code
30
Transfer to Bad Debt Date
31
Bad Debt Agency Code
32
Bad Debt Transfer Amount
33
Bad Debt Recover Amount
34
Delete Account Indicator
35
Delete Account Date
36
Discharge Disposition
37
Discharge To Location
37.1
40
R/O
Code
See Codeset: CS_DISCHARGE_DISPOSITION
PV1 Seq
Name
37.2
Description
R/O
Comments
38
Diet Type
39
Servicing Facility
40
Bed Status
41
Account Status
42
Pending Location
43
Prior Temporary Location
44
Admit Date/Time
Must always be populated in visit-level ADT

messages.
45
Discharge Date/Time
Once the patient has be discharged subsequent

transactions after a discharge should have the
discharge date and time. Only an ADT Cancel
Discharge (A13) message can nullify this field
once a value has been received.
46
Current Patient Balance
47
Total Charges
48
Total Adjustment
49
Total Payments
50
Alternate Visit ID
51
Visit Indicator
52
Other Healthcare Providers
6.2.3.1
See Codeset: CS_SERVICING_FACILITY
PV1 Medicity Business Rules and Guidelines
VIP Indicator
N^Normal
V^Very Restricted
R^Restricted
Medicity will use this field to allow the upstream ADT system of authority to indicate the VIP indicator
status for down stream delivery of results. Within the scope of the HIE, the organization sending VIP
indicator must consider what its intended purpose of this field is.
Is VIP indicator being used to protect the patient within the scope of the organization only?
i. If so, PV1:16 may be copied to PV2:22 which Medicity uses to protect patients at the data
source level.
Is VIP indicator being used to protect the patient within the scope of the HIE as a whole?
i. If so, PV1:16 may be copied to PD1:12 which Medicity uses to protect patients at the HIE
level. See the Protection indicator business rules in section 6.2.3.
41
6.2.4 The PV2 Segment - Additional Patient Visit Information

The PV2 segment provides additional visit or encounter specific information.
Segment Layout
This segment is optional. If the segment is used, the required fields are listed below. If not used, all
fields must be grayed out.
PV2 Seq
Name
R/O
01
Prior Pending Locations
02
Accommodation Code
03
Admit Reason
03.1
Admit Reason Code
03.2
Admit Reason Text
04
Transfer Reason
Comments
See Codeset: CS_ACCOMODATION
04.1
Transfer Reason Code
04.2
Transfer Reason Text
05
Patient Valuables
06
Patient Valuables Location
07
Visit User Code
08
Expected Admit Date
09
Expected Discharge Date
10
Estimated Length of Inpatient

Stay
11
Actual Length of Inpatient

Stay
12
Visit Description
13
Referral Source Code
14
Previous Service Date
15
Employment Illness Related

Indicator
16
Purge Status Code
17
Purge Status Date
18
Special Program Code
19
Retention Indicator
20
Expected Number of
Insurance Plans
21
Visit Publicity Code
22
Visit Protection Indicator
6.2.4.1
PV2 Medicity Business Rules and Guidelines
See Codeset: CS_PROTECTION_IND
42
Medicity will use this field to allow the upstream ADT system of authority to indicate the protection status
of a patient at the data source level. A subdefinition of Y will make a patient not viewable from the
specific data source for users who do not have access to protected data.
6.2.5 The AL1 Segment - Patient Allergy Information

The AL1segment provides transmission of allergies that pertain to information gathered by admissions for
this encounter.
Medicity Product Group must define what we will and will not do when it comes to the processing and
display of allergy information. Currently we store the allergy information by encounter.
Medicity stores allergies at the encounter level but only displays the allergies attached to the most
current encounter.
For some systems we get all allergies sent every time.
For some systems we only get allergy updates and need to maintain all allergies that were ever
sent.
An agreement needs to be made with the client on how we should process their allergy data.
Segment Layout
This segment is optional. If the segment is used, the required fields are listed below. If not used, all
fields must be grayed out.
AL1 Seq
Name
R/O
01
Set ID - AL1
02
Allergy Type
03
Allergy Code
03.1
Identifier
03.2
Description
03.3
Name of Coding System
Comments
Required if an AL1 segment is sent.
04
Allergy Severity
See Codeset: CS_ALLERGY_SEVERITY_CODE
05
Allergy Reaction
See Codeset: CS_ALLERGY_REACTION_CODE
06
Identification Date
Medicity Business Rules and Guidelines

When allergies are sent the entire inclusive list of allergies for this encounter must be sent.
43
6.2.6 The DG1 Segment - Diagnosis

The DG1 segment contains patient diagnosis information of various types. See DG1 Medicity Business
Rules and Guidelines below for more details.
Segment Layout
44
DG1 Seq
Name
R/O
Comments
01
Set ID - DG1
02
Diagnosis Coding Method
See Codeset:
CS_DIAGNOSIS_CODE_METHOD
Medicity requires that DG1:2 and DG1:3.3
match.
03
Diagnosis Code
Can be blank for a free-text diagnosis, but must

be populated if a coded diagnosis.
03.1
Identifier
Must be populated with a code
03.2
Description
Must be populated with a description.
03.3
Name of Coding System
Medicity requires that DG1:2 and DG1:3.3

match.
04
Diagnosis Description
See Diagnosis Coding Method RULES for

terms of usage.
05
Diagnosis Date and Time
Allowed blank for backwards compatibility.
06
Diagnosis Type
See Codeset: CS_DIAGNOSIS_TYPE
07
Major Diagnostic Category (MDB)
08
Diagnostic Related Group
09
DRG Approval Indicator
10
DRG Group Review Code
11
Outlier Type
12
Outlier Days
13
Outlier Cost
14
Grouper Version and Type
15
Diagnosis Priority
16
Diagnosing Clinician
17
Diagnosis Classification
Allowed blank for backwards compatibility.

Acceptable values:
0 = Not included in diagnosis ranking
1 = The primary diagnosis
2 = For ranked secondary diagnoses
See Codeset: CS_PROTECTION_IND
18
Confidential Indicator
19
Attestation Date/Time
6.2.6.1
DG1 Medicity Business Rules and Guidelines
The HL7 Standard does not provide a reliable way to identify and update a particular instance of
repeating segments. Consequently, the Medicity ADT Parser will use Set ID Diagnosis (DG1:1) only to
represent the sequencing of DG1 segments within a message. The sending system must include all
diagnoses for a given type (e.g., all finals). Medicity ADT Parser will update all diagnoses of this type as a
unit. Medicity ADT Parser will automatically delete (inactivate) extra instances in the ProAccess database
not included in the HL7 message.
There are specific rules surrounding DG1:2, DG1:3, and DG1:4 requirements.
If the Diagnosis Coding Method (DG1:2) is FT (for FreeText), the Diagnosis Code (DG1:3) may
be used if all three components are populated. If all three components in DG1:3 are not or cannot
be populated, the Diagnosis Description (DG1:4) is required.
Examples of supported DG1:2, DG1:3, and DG1:4 formatting when DG1:2 is FT:
DG1|1|FT|1Âbdominal Pain^FT||
DG1|1|FT||Abdominal Pain||
If the Diagnosis Coding Method is I9 or I10, then Diagnosis Code (DG1:3) must contain a CE
Data Type. This means the ID (DG1:3.1), Description (DG1:3.2), and Name of Coding System
(DG1:3.3) must be populated in their respective DG1:3 components. When DG1:3.1 and
DG1:3.2 are sent DG1:3.3 is a required field and must be populated with the code method (I9 or
I10).
Examples of supported DG1:2, DG1:3 formatting when DG1:2 is I9 or I10:
DG1|1|I9|995.91^SepsisÎ9||
DG1:2 can only contain I9, I10, or FT
DG1:3.3 can only contain I9, I10, or FT
6.2.7 The PR1 Segment - Procedures

The PR1 segment contains information relative to various types of procedures that can be performed on a
patient.
PR1 Seq
Name
R/O
01
Set ID - PR1
Set ID begins at 1 and increments by 1.
02
Procedure Coding
Use PR1:3.3.
Comments
45
Method
03
46
Procedure Code
03.1
Identifier
03.2
Text
03.3
Name of Coding
System
03.4
Alternate Identifier
03.5
Alternate Text
03.6
Name of Alternate
Coding System
04
Procedure Description
05
Procedure Date/Time
06
Procedure Functional
Type
07
Procedure Minutes
08
Anesthesiologist
Must be populated by the sending system.
Use PR1:3.2.
Acceptable values:
A = Anesthesia
P = Procedure for treatment (therapeutic, including
operations)
I = Invasive Procedure not classified elsewhere (i.e.
IV catheter)
D = Diagnostic procedure
08.1
Identifier
If PR1:8 is sent, 8.1, 8.2 and .8.3 are required.
08.2
Last Name
08.3
First Name
08.4
Middle Name
08.5
Prefix
08.6
Suffix
08.7
Degree
08.8
Source Table
08.9
Assigning Authority
08.9.1
Namespace ID
The namespace ID contains the sending facilitys

ID of the placing application. A given institution or
group of intercommunicating institutions should
establish a unique list of facilities that may be
potential placers and fillers and assign unique
sending facility IDs.
08.9.2
Universal ID
Used when the HIE has defined the OID

requirements
08.9.3
Universal ID Type
Value is ISO when a universal ID is in scope.
08.10
Name Type Code
08.11
Identifier Check Digit
08.12
Check Digit Scheme
08.13
Identifier Type Code
Acceptable values:
DEA = Drug Enforcement Administration
Registration Number
DN = Doctor Number
MD = Medical License Number
NP = Nurse Practitioner Number
NPI = National Provider Identifier
PA = Physician Assistant Number
PRN = Provider Number
RN = Registered Nurse Number
UPIN = Medicare/CMS Universal physician
Identification number
RPH = Pharmacist License Number
SL = State License
Codeset User defined
09
Anesthesia Code
10
Anesthesia Minutes
11
Surgeon
11.1
Identifier
11.2
Last Name
11.3
First Name
11.4
Middle Name
11.5
Prefix
11.6
Suffix
11.7
Degree
11.8
Source Table
11.9
Assigning Authority
11.9.1
Namespace ID

11.9.2
Universal ID

requirements.
11.9.3
Universal ID Type
11.10
Name Type Code
11.11
11.12
Check Digit Scheme
11.13
Procedure Practitioner
12
12.1
Identifier
12.2
Last Name
If PR1:11 is sent, 11.1, 11.2 and 11.3 are required.
See PR1:8.13 for acceptable values.

If PR1:12 is sent, 12.1, 12.2 and 12.3 are required.
47
12.3
First Name
12.4
Middle Name
12.5
Prefix
12.6
Suffix
12.7
Degree
12.8
Source Table
12.9
Assigning Authority
12.9.1
Namespace ID

12.9.2
Universal ID

requirements.
12.9.3
Universal ID Type
12.10
Name Type Code
12.11
12.12
Check Digit Scheme
12.13
13
Consent Code
13.1
Identifier
13.2
Text
13.3
Name of Coding
System
13.4
13.5
Alternate Text
13.6
Name of Alternate
Coding System
14
Procedure Priority
See PR1:8.13 for acceptable values.
When the same procedure is performed multiple

times.
Acceptable values:
0 = the admitting procedure
1 = the primary procedure
2 and higher = for ranked secondary procedures
15
48
Associated Diagnosis
Code
15.1
Identifier
15.2
Text
15.3
Name of Coding
System
15.4
15.5
Alternate Text
O
15.6
16
Name of Alternate
Coding System
Procedure Code
Modifier
O
O
16.1
Identifier
16.2
Text
16.3
Name of Coding
System
16.4
16.5
Alternate Text
16.6
Name of Alternate
Coding System
17
Procedure DRG Type
18
Tissue Type Code
18.1
Identifier
18.2
Text
18.3
Name of Coding
System
18.4
18.5
Alternate Text
18.6
Name of Alternate
Coding System
19
Procedure Identifier
Optional in HL7 2.5 but is required in C32 for

Procedures Data. When not sent by a client one
can be constructed from the set id + "-" + PR1:3.1.
19.1
Entity Identifier
This field contains a value that uniquely identifies a

single procedure for an encounter.
19.2
Namespace ID
19.3
Universal ID

requirements.
19.4
Universal ID Type
Procedure Action Code
Codeset - Maintenance Control on Procedures
20
If not valued then assumed to be update.

The following codes are from the HL7 table 0206
and are the same as what is in TXA:21.
Acceptable values:
A = Add
U = Update
D = Delete
6.2.8 The GT1 Segment - Guarantor
49
The GT1 segment contains guarantor (person or organization with financial responsibility for payment of a
patient account) data for patient and insurance billing applications. All pre-validators shall be configured
to check for client required fields. All post-validators shall be configured to check for all Medicity required
fields.
50
GT1 Seq
Name
R/O
01
Set ID - GT1
Set ID begins at 1 and increments by 1.
02
Guarantor Number
See Modes for updating via repeating

segments at the beginning of this section for
information regarding GT1, NK1 and IN1
matching.
03
Guarantor Name
03.1
Last Name
03.2
First Name
03.3
Middle Name
03.4
Prefix
03.5
Suffix
03.6
Degree
04
Guarantor Spouse Name
05
Guarantor Address
05.1
Address Line 1
05.2
Address Line 2
05.3
City
05.4
State
05.5
ZIP
05.6
Country
05.7
Type
05.8
Other Geographic
05.9
County/Parish
Comments
06
Guarantor Phone Number Home

999-9999
07
Guarantor Phone Number

Business

999-9999
08
Guarantor Date of Birth
09
Guarantor Sex
10
Guarantor Type
11
Guarantor Relationship
12
Guarantor SSN
13
Guarantor Date Begin
14
Guarantor Date End
15
Guarantor Priority
16
Guarantor Employer Name
17
Guarantor Employer Address

GT1 Seq
Name
R/O
17.1
Address Line 1
17.2
Address Line 2
17.3
City
17.4
State
17.5
ZIP
17.6
Country
17.7
Type
17.8
Other Geographic
17.9
County/Parish
18
Guarantor Employer Phone
19
Guarantor Employee ID Number
20
Guarantor Employment Status
21
Guarantor Organization
21.1
Organization Name
21.2
Organization Name Type Code
21.3
ID Number
21.4
Check Digit
21.5
Check Digit Scheme
21.6
Assigning Authority
21.7
21.8
Assigning Facility
Comments

999-9999
22
Guarantor Billing Hold Flag
23
Guarantor Credit Rating Code
24
Guarantor Death Date/Time
25
Guarantor Death Indicator
26
Guarantor Charge Adjustment Code
27
Guarantor House Annual Income
28
Guarantor Household Size
29
Guarantor Employer ID Number
30
Guarantor Marital Status Code
31
Guarantor Hire Effective Date
32
Employment Stop Date
33
Living Dependency
34
Ambulatory Status
35
Citizenship
36
Primary Language
37
Living Arrangement
38
Privacy Type
51
GT1 Seq
Name
R/O
39

40
Student Indicator
41
Religion
42
Mothers Maiden Name
43
Nationality
44
Ethnic Group
45
Contact Person Name
46
Contact Person Phone
47
Contact Reason
48
Contact Relationship
49
Job Title
50
Job Code
50.1
Job Code
50.2
Job Class
51
Guarantor Employer Organization

Name
52
Handicap
53
Job Status
54
Guarantor Financial Class
54.1
Financial Class
54.2
Effective Date
55
Guarantor Race
56
Guarantor Birth Place
57
VIP Indicator
6.2.8.1
Comments
GT1 Medicity Business Rules and Guidelines
The Medicity ADT Parser will accept multiple instances of the GT1 segment. The sending system must
send all instances for this encounter.
52
6.2.9 The IN1 Segment - Insurance Information

The IN1 segment contains insurance policy coverage information necessary to produce pro-rated patient
and insurance bills.
Segment Layout
IN1 Seq
Name
R/O
01
Set ID - IN1
02
Insurance Plan ID
03
Insurance Company ID
03.1
ID
03.2
Code Identifying the Check Digit

Scheme Employed
03.3
Assigning Authority
03.4
03.5
Assigning Facility
04
Insurance Company Name
05
Insurance Company Address
05.1
Street Address
05.2
Other Designation
05.3
City
05.4
State or Province
05.5
ZIP or Postal Code
05.6
Address Type
05.7
Other Geographic Designation
05.8
Country/Parish Code
05.9
Census Tract
06
Insurance Comp Contact Person
07
Insurance Company Phone Number
08
Group Number
09
Group Name
10
Insureds Group Employer ID
11
Insureds Group Employer Name
12
Plan Effective Date/Time
13
Plan Expiration Date
14
Authorization Information
14.1
Authorization Number
14.2
Date
14.3
Source
Comments
Set ID begins at 1 and increments by 1
Medicity maintains a master insurance

company table where Insurance Company
ID is used as the primary key.

999-9999
53
IN1 Seq
Name
R/O
15
Plan Type
16
Name of Insured
16.1
Last Name
16.2
First Name
16.3
Middle Name
16.4
Prefix
16.5
Suffix
16.6
Degree
17
Insureds Relationship to Patient
18
Insureds Date of Birth
19
Insureds Address
19.1
Address Line 1
19.2
Address Line 2
19.3
City
19.4
State
19.5
ZIP
19.6
Country
19.7
Type
19.8
Other Geographic
19.9
County/Parish
20
Assignment of Benefits
21
Coordination of Benefits
22
Coordination of Benefits Priority
Comments
If IN1:16 is sent, 16.1 and 16.2 are required
This is an optional data element to

determine the primary, secondary and
tertiary insurance.
If this field is blank, ProAccess displays the
insurance in the order it was received.
Medicity will only evaluate numeric values of
1, 2 or 3 in this field.
54
23
Notice of Admission Code
24
Notice of Admission Date
25
Report of Eligibility Code
26
Report of Eligibility Date
27
Release Information Code
28
Pre-admit Certification (PAC)
29
Verification Date/Time
30
Verification By
31
Type of Agreement Code
32
Billing Status
IN1 Seq
Name
R/O
33
Lifetime Reserve Days
34
Delay Before Life Reserve Day
35
Company Plan Code
36
Policy Number
37
Policy Deductible
38
Policy Limit Maximum Amount
39
Policy Limit Maximum Days
40
Room Rate Semi-Private
41
Room Rate Private
42
Insureds Employment Status
43
Insureds Sex
44
Insureds Employer Address
45
Verification Status
46
Prior Insurance Plan ID
47
Coverage Type
48
Handicap
49
Insureds ID Number
50
Signature Code
51
Signature Code Date
52
Insureds Birth Place
53
VIP Indicator
Comments
6.2.10 The IN2 Segment - Insurance Additional Info

The IN2 segment contains additional insurance policy coverage and benefit information necessary for
billing and reimbursement. Fields used by this segment are defined by HICFA or other regulatory
agencies.
Segment Layout
IN2 Seq
Name
R/O
01
Insureds Employee ID
02
Insureds SSN
03
Insureds Employer ID and Name
03.1
Employer ID
03.2
Employer Name
04
Employer Information Data
05
Mail Claim Party
06
Medicare Health Insurance Card

Number
07
Medicaid Case Name
Comments
If IN2:3 is sent, 3.1 and 3.2 are required.
55
IN2 Seq
Name
08
Medicaid Case Number
09
Champus Sponsor Name
10
Champus ID Number
11
Dependent of Champus Recipient
12
Champus Organization
13
Champus Station
14
Champus Service
15
Champus Rank/Grade
16
Champus Status
17
Champus Retire Date
18
Champus Non-Avail Cert on File
19
Baby Coverage
20
Combine Baby Bill
21
Blood Deductible
22
Special Coverage Approval Number
23
Special Coverage Approval Title
24
Non-Covered Insurance Code
25
Payor ID
26
Payor Sub ID
27
Eligibility Source
28
Room Coverage Type/Amount
28.1
Room Type
28.2
Amount Type
28.3
Coverage Amount
Policy Type/Amount
29
56
R/O
29.1
Policy Type
29.2
Amount Class
29.3
Amount
Comments
30
Daily Deductible
31
Living Dependency
32
Ambulatory Status
33
Citizenship
34
Primary Language
35
Living Arrangement
36
Privacy Type
37

below.
38
Student Indicator

IN2 Seq
Name
R/O
Comments
39
Religion
40
Mothers Maiden Name
41
Nationality
42
Ethnic Group
43
Marital Status
44
Insured Employment Start
45
Insured Employment Stop
46
Job Title
47
Job
48
Job Status
49
Employer Contact Person
50
Employer Contact Phone
51
Employer Contact Reason
52
Insured Contact Person
53
Insured Contact Phone
54
Insured Contact Reason
55
Relationship to Patient Start Date
56
Relationship to Patient Stop Date
57
Insurance Company Contact Reason
58
Insurance Company Contact Phone
59
Policy Scope
60
Policy Source
61
Patient Member Number
62
Guarantor Relation to Insured
63
Insured Home Phone Number

999-9999
64
Insured Employer Phone Number

999-9999
65
Military Handicapped Program Code
66
Suspend Flag
67
Copay Limit Flag
68
Stop Loss Limit Flag
69
Insured Organization Name and ID
70
Insured Employer Organization

Name/ID
71
Race
72
Patient Relationship to Insured

6.2.10.1 IN2 Medicity Business Rules and Guidelines
57
6.2.11 The ACC Segment - Accident Information

The ACC segment contains patient accident information.
Segment Layout
58
ACC Seq
Name
R/O
01
Accident Date/Time
02
Accident Code
03
Accident Location
04
Auto Accident State
05
Accident Job Related Indicator
06
Accident Death Indicator
07
Entered By
08
Accident Description
09
Brought In By
10
Police Notified Indicator
11
Accident Address
Comments
See Codeset: CS_ACCIDENT_CODE
59

Medicity ProAccess 7 ADT Product Specification

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Medicity ProAccess 7 ADT Product Specification

Загружено:

Авторское право:

Доступные форматы

Medicity ProAccess 6.x and 7.

Medicity ProAccess ADT Product Specification

3 Medicity Business Rules and Guidelines...................................................................................9

4 ADT Trigger Events .................................................................................................................14

2013-2014 Medicity, Inc - Proprietary & Confidential

Medicity ProAccess ADT Product Specification

5.1.4.1 Register a Patient (A04) Message Structure ......................................................... 18

6 HL7 Segment Layouts .............................................................................................................27

Medicity ProAccess ADT Product Specification

6.2 ADT Segments ...................................................................................................................... 30

2013-2014 Medicity, Inc - Proprietary & Confidential

Medicity ProAccess ADT Product Specification

1.1 Document Purpose

1.2 Document Scope

This document is not intended to be a compendium of knowledge regarding system interfaces or

For background information on HL7 Interface standards, see HL7.org.

1.3 Referenced Documents

HIE Architecture Overview Diagram (Visio)

Client ADT to Medicity ADT Inbound Specification

HL7 2.x CH 3 Patient Administration

ProAccess CodeSet Spreadsheet

EMPI Patient Matching Specification

CMPI Patient Matching Documentation

2013-2014 Medicity, Inc - Proprietary & Confidential

Medicity ProAccess ADT Product Specification

2013-2014 Medicity, Inc - Proprietary & Confidential

Medicity ProAccess ADT Product Specification

3 Medicity Business Rules and

Validation Options Business Rules:

If conditional data validation is required (ex: Field X must be populated if Field Y

2013-2014 Medicity, Inc - Proprietary & Confidential

Medicity ProAccess ADT Product Specification

3.1.2 Patient Matching

Patient Identifiers configured for this interface

Internal Patient Identifier

External Patient Identifier

Alternate Patient Identifier

Patient Account Identifier

2013-2014 Medicity, Inc - Proprietary & Confidential

Medicity ProAccess ADT Product Specification

3.1.1 Encounter or Visit Matching

Patient Account Identifier

3.1.2 Guarantor, Next of Kin, and Insured Matching

Next of Kin Identifier

3.1.3 Physician Matching

Physician Matching Business Rules:

Physician Matching Common Issues:

2013-2014 Medicity, Inc - Proprietary & Confidential

Medicity ProAccess ADT Product Specification

Attending Provider ID (PV1:7.1)

Physician Free-text matching

Medicity will configure the database parser to accept

3.2 Nexus Metadata to be captured for this

2013-2014 Medicity, Inc - Proprietary & Confidential

Medicity ProAccess ADT Product Specification

Metadata item to be captured:

Identified in Medicity after message transformation

2013-2014 Medicity, Inc - Proprietary & Confidential

Medicity ProAccess ADT Product Specification

4 ADT Trigger Events

ADT Trigger Event

Transfer Outpatient to Inpatient

Transfer Inpatient to Outpatient