medicity proaccess 7 adt product specification (4)

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

4 2013-2014 Medicity, Inc - Proprietary & Confidential

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

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 dddd). 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 post-validator.

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 application-layer.

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:

If a field is a Medicity required field, the post-validators will test that the field has a non-empty 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.

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



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.


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


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.



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 R

7.2 Last Name R

7.3 First Name O

7.4 Middle Name O

7.5 Prefix O

7.6 Suffix O

7.7 Degree N

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 Identifier in Medicity

Ex. |^Smith^John^A^Jr Medicity will configure the database parser to accept FREETEXT as the free-text provider ID.

Example: FREETEXT^Smith^John^A^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.



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



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:

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 SWAP

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



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 MOVEACCOUNT

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



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:

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 R R Required by Medicity

EVN Event Type Not supported

PID Patient Identification R R Required by Medicity



[PD1] Additional Demographics

[ { NK1 } ] Next of Kin

PV1 Patient Visit O C Required by Medicity in visit-level messages like the A01. Not required in person-level messages like the A31.

[PV2] Additional Patient Visit

[ { AL1 } ] Allergy Information

[ { DG1 } ] Diagnosis Information

[ { PR1 } ] Procedures

[ { GT1 } ] Guarantor

[

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



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




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



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

Segment Segment Name Comments

MSH Message Header

EVN Event Type

PID Patient Identification

[ PD1 ] Additional Demographics

PV1 Patient Visit

PID Patient (2) Identification



[ PD1 ] Additional Demographics (2) HL7 2.4 - New segment

PV1 Patient (2) Visit

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


MSH Message Header Required by Medicity

EVN Event Type

PID Patient Identification Required by Medicity


{ [ NK1 ] } Next of Kin



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



EVN Event Type




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


5.1.15.1 Update Person Information (A31) Message Structure

Message

Event TYPE: ADT

Event CODE: A31



EVN Event Type




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.



5.1.16.1 Merge Patient Internal ID (A40) Message Structure

Message

Event TYPE: ADT

Event CODE: A40



EVN Event Type

{



MRG Merge Information Required by Medicity

}

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 account-patient 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.

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 A08 (update patient information) event be used in addition.

If either the source or destination patient does not exist, the record will be created.



5.1.17.1 Merge Account Patient Account Number (A41) Message Structure

Message

Event TYPE: ADT

Event CODE: A41



EVN Event Type

{




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

The fields included when this message is sent should be the fields pertinent to communicate this event. 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



5.1.18.1 Move Account Information Patient Account Number (A44) Message Structure

Message

Event TYPE: ADT

Event CODE: A44



EVN Event Type

{


[ PD1 ] Additional Demographics Required by Medicity in move transactions for security considerations.


}



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.



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 R Field separator.

Value required is | ASCII(124)

02 Encoding Character R 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 R Medicity requires that this be a unique value per contributing system, per-facility.

04 Sending Facility R Medicity expects the ancillaries to contain the same MSH:4 value as the ADT feed, if applicable.

05 Receive Application R Medicity will hard-code this field to Medicity.

06 Receiving Facility N

07 Date/Time of Message R System date and time the message was formatted in the sending system.

08 Security N

09 Message Type R Specific HL7 message type and event triggering the message.

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

09.2 Event R See Chapter 5 - ADT Trigger Events for allowable ADT event triggers.

10 Message Control ID R Initiator generated. Should be but is not always



MSH Seq Name R/O Comments

unique. Medicity will replace the received value with a unique Medicity identifier (aka thread ID).

11 Processing ID O Acceptable values:

P = Production

11.1 Processing ID O

11.2 Mode O

12 Version ID R HL7 version. Medicity currently transforms HL7 that is received to version 2.3. Medicity can accept HL7 version 2.1 2.5.

13 Sequence Number N

14 Continuation Number N

15 Accept ACK Type N

16 Application ACK Type N

17 Country Code N

18 Character Set N

19 Language of Message N

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 R/O Comments

01 Acknowledge Code R 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 R Echo MSH segment control ID (MSH:10) of message being acknowledged.

03 Text Message N

04 Expected Sequence Number N

05 Delayed ACK Type N

06 Error Condition N

Original Message:

MSH|^~\&|ABCADT|ABC|Medicity||19960214134522||ADT^A01|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



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 Comments

01 Event Type Code N

02 Date/Time of Event N

03 Date/Time Planned Event N

04 Event Reason Code N

05 Operator ID N

06 Event Occurred N

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 R/O Comments

01 Set ID - PID R

02 External Patient ID O See Chapter 4 - Medicity Business Rules and Guidelines.

02.1 Patient ID O This may be a criteria in the Medicity Community Patient Matching (CMPI), but only between facilities whose External MRN share the same OID.

02.2 Check Digit N

02.3 Check Digit Scheme N

02.4 Assigning Authoring N This is implied to be the parent of the organization identified the MSH:4.

02.5 Identifier Type N This can vary, but generally is implied to be a cross-facility identifier. Sometimes called an Enterprise or External Identifier.

02.6 Assigning Facility N See Chapter 4 - Medicity Business Rules and Guidelines.

03 Internal Patient ID R 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.




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 R

03.2 Check Digit N

03.3 Check Digit Scheme N This is implied to be the same as MSH:4.

03.4 Assigning Authoring N This is a Medical Record Number.

03.5 Identifier Type N

03.6 Assigning Facility N See Chapter 4 - Medicity Business Rules and Guidelines.

04 Alternate Patient ID O

04.1 Patient ID O

04.2 Check Digit N

04.3 Check Digit Scheme N This is implied to be the same as MSH:4.

04.4 Assigning Authoring N While other identifiers can be stored here, only one identifier type may be stored here.


04.6 Assigning Facility N This is a criteria in the Medicity Enterprise Patient Matching (EMPI) and Community Patient Matching (CMPI).


05 Patient Name R EMPI matches on the exact name.

05.1 Last Name R CMPI matches on the sound of the name.

05.2 First Name O CMPI matches on the middle initial.

05.3 Middle Name O

05.4 Suffix O

05.5 Prefix O

05.6 Degree N

06 Mothers Maiden Name O This is a criteria in the Medicity Enterprise Patient Matching (EMPI) and Community Patient Matching (CMPI).

07 Date of Birth R See Codeset: CS_GENDER

This is a criteria in the Medicity Enterprise Patient Matching (EMPI) and Community Patient Matching (CMPI).

08 Sex R Unfortunately, Medicity does not yet support repetitions in this field.

09 Patient Alias O

09.1 Last Name O

09.2 First Name O

09.3 Middle Name O

09.4 Suffix O




09.5 Prefix O

09.6 Degree N See Codeset: CS_RACE


10 Race O This is a criteria in the Medicity Community Patient Matching (CMPI).

11 Patient Address O Unfortunately, Medicity does not yet support repetitions in this field.

11.1 Address Line 1 O


11.3 City O

11.4 State O

11.5 ZIP Code O

11.6 Country N

11.7 Type N

11.8 Other Geographic Designation N

11.9 County/Parish N

11.10 Census Tract N

12 County Code N 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 O 18 character limit - Suggested format: (999) 999-9999

14 Business Phone Number O See Codeset: CS_LANGUAGE

15 Language Patient O See Codeset: CS_MARITAL_STATUS

16 Marital Status O See Codeset: CS_RELIGION

17 Religion O See Chapter 4 - Medicity Business Rules and Guidelines.

18 Patient Account Number C This is a criteria in the Medicity Enterprise Patient Matching (EMPI)

18.1 Patient Account Number C

18.2 Check Digit N


18.4 Assigning Authority N


18.6 Assigning Facility N 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-99-9999.

This is a criteria in the Medicity Enterprise




Patient Matching (EMPI) and Community Patient Matching (CMPI). Formatting does not impact its matching.

19 SSN Patient O

20 Drivers License Number N

21 Mothers Identifier N 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 O 100 character limit

23 Birth Place O Acceptable values:

Y = Yes

N = No

24 Multiple Birth Indicator O

25 Birth Order O See Codeset: CS_CITIZENSHIP

26 Citizenship O

27 Veterans Military Status N See Codeset: CS_NATIONALITY

28 Nationality O Date/time at which the death occurred.

29 Patient Death Date/Time O Acceptable values:

Y = the patient is deceased

N = the patient is not deceased

30 Patient Death Indicator O

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 Comments

01 Living Dependency N

02 Living Arrangement N

03 Primary Care Facility N

04 Primary Care Provider O Medicity will not accept repeating fields for PD1:4 only a single occurrence is allowed.

04.1 Primary Care Provider ID R If PD1:4 is sent, 4.1 and 4.2 are required.

04.2 Last Name R

04.3 First Name O

04.4 Middle Name O

04.5 Suffix O

04.6 Prefix O

04.7 Degree N



04.8 Source Table N


04.10 Name Type N

04.11 Check Digit N



05 Student Indicator O See Codeset: CS_STUDENT

06 Handicap N

07 Living Will O See Codeset: CS_LIVING_WILL

08 Organ Donor N

09 Separate Bill N

10 Duplicate Patient N

11 Privacy Type N

12 Protection Indicator O See Codeset: CS_PROTECTION_IND See Medicity Business Rules and Guidelines below.

13 Protection Indicator Effective Date/Time

C 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 PD1 Medicity Business Rules and Guidelines

Protection Indicator

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.



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 Comments

01 Prior Patient Identifier List C Required for A40 and A44 messages.

02 Prior Alternate Patient ID N

03 Prior Patient Account Number

C Required for A41 and A44 messages.

04 Prior Patient ID N

05 Prior Visit Number N

06 Prior Alternate Visit ID N

07 Prior Patient Name N

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 Comments

01 Set ID - NK1 R

02 Next of Kin Name R

02.1 Last Name R

02.2 First Name O

02.3 Middle Name O

02.4 Suffix O

02.5 Prefix O

02.6 Degree N

03 Next of Kin Relationship to Patient

R See Codeset: CS_REL_TO_PERSON

04 Next of Kin Address O






04.3 City O

04.4 State O See: Medicity Base Codeset

04.5 ZIP Code O

04.6 Country O

04.7 Type N

04.8 Other Geographic N

04.9 County/Parish N

04.10 Census Tract N

05 Next of Kin Phone Number O 18 character limit - Suggested format: (999) 999-9999

06 Next of Kin Employer Phone Number

O 18 character limit - Suggested format: (999) 999-9999

07 Contact Role N

08 Start Date N

09 End Date N

10 Next of Kin Job Title O

11 Next of Kin Job Code/Class N

11.1 Job Code N

11.2 Job Class N

12 Next of Kin Employee Number O

13 Organization Name N

14 Marital Status O See Codeset: CS_MARITAL_STATUS

15 Sex O See Codeset: CS_GENDER

16 Date of Birth O

17 Living Dependency N

18 Ambulatory Status N

19 Citizenship O See Codeset: CS_CITIZENSHIP

20 Primary Language O See Codeset: CS_LANGUAGE

21 Living Arrangement N

22 Privacy Type N

23 Protection Indicator O See Codeset: CS_PROTECTION_IND See Medicity Business Rules and Guidelines below.

24 Student Indicator O See Codeset: CS_STUDENT

25 Religion N

26 Mothers Maiden Name O

27 Nationality O See Codeset: CS_NATIONALITY

28 Ethnic Group N

29 Contact Reason N




30 Contact Person Name N

31 Contact Phone N

32 Contact Address N

33 NK1 Identifiers O List of components if present.

34 Job Status O

35 Race O See Codeset: CS_RACE

36 Handicap N

37 Contact Person Social Security Number

O

38 Next of Kin Birth Place O

39 VIP Indicator O See Codeset: CS_VIP_IND See Medicity Business Rules and Guidelines below.

6.2.2.1 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).



6.2.3 The PV1 Segment - Patient Visit

The PV1 segment provides visit or encounter specific information.

Segment Layout

PV1 Seq Name R/O Comments

01 Set ID - PV1 R Starts at 1; increments by 1.

02 Patient Class R See Codeset: CS_ENCOUNTER_CLASS

Required by Medicity to determine IP/OP status.

03 Patient Location O

03.1 Point of Service Location O

03.2 Patient Room O

03.3 Patient Bed O

03.4 Facility ID O

03.5 Bed Status N

03.6 Location Type N

03.7 Building O

03.8 Floor N

04 Admission Type O See Codeset: CS_ADMIT_TYPE

05 Pre-admit Number N

06 Prior Patient Location N

07 Attending Doctor O Medicity will not accept repeating fields for PV1:7 only a single occurrence is allowed.

The value in this field can be used to determine result delivery routing to an end user.

07.1 Attending Doctor ID R If PV1:7 is sent, 7.1 and 7.2 are required.

07.2 Last Name R

07.3 First Name O

07.4 Middle Name O

07.5 Suffix O

07.6 Prefix O

07.7 Degree N

07.8 Source Table N


07.10 Name Type N

07.11 Check Digit N



08 Referring Doctor O Medicity will not accept repeating fields for PV1:8 only a single occurrence is allowed.


08.1 Referring Doctor ID R If PV1:8 is sent, 8.1 and 8.2 are required.




08.2 Last Name R

08.3 First Name O

08.4 Middle Name O

08.5 Suffix O

08.6 Prefix O

08.7 Degree N

08.8 Source Table N


08.10 Name Type N

08.11 Check Digit N



09 Consulting Doctor O The value in this field can be used to determine result delivery routing to an end user.

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.1 Consulting Doctor ID R If PV1:9 is sent, 9.1 and 9.2 are required.

09.2 Last Name R

09.3 First Name O

09.4 Middle Name O

09.5 Suffix O

09.6 Prefix O

09.7 Degree N

09.8 Source Table N


09.10 Name Type N

09.11 Check Digit N



10 Hospital Service O See Codeset: CS_ADMIT_SERVICE

11 Temporary Location N

12 Pre-admit Test Indicator N

13 Re-admission Indicator N

14 Admission Source O See Codeset: CS_ADMIT_SOURCE

15 Ambulatory Status N

16 VIP Indicator O See Codeset: CS_VIP_IND

See below for the PV1 Business Rules and Guidelines.




17 Admitting Doctor O Medicity will not accept repeating fields for PV1:17 only a single occurrence is allowed.


17.1 Admitting Doctor ID R If PV1:17 is sent, 17.1 and 17.2 are required.

17.2 Last Name R

17.3 First Name O

17.4 Middle Name O

17.5 Suffix O

17.6 Prefix O

17.7 Degree N

17.8 Source Table N


17.10 Name Type N

17.11 Check Digit N



18 Patient Type O See Codeset: CS_ENCOUNTER_TYPE

19 Visit Number O 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 O See Codeset: CS_FINANCIAL_CLASS

21 Charge Price Indicator N

22 Courtesy Code N

23 Credit Rating N

24 Contract Code N

25 Contract Effective Date N

26 Contract Amount N

27 Contract Period N

28 Interest Code N

29 Transfer to Bad Debt Code N

30 Transfer to Bad Debt Date N

31 Bad Debt Agency Code N

32 Bad Debt Transfer Amount N

33 Bad Debt Recover Amount N

34 Delete Account Indicator N

35 Delete Account Date N

36 Discharge Disposition O See Codeset: CS_DISCHARGE_DISPOSITION

37 Discharge To Location N

37.1 Code N




37.2 Description N

38 Diet Type N

39 Servicing Facility O See Codeset: CS_SERVICING_FACILITY

40 Bed Status N

41 Account Status N

42 Pending Location N

43 Prior Temporary Location N

44 Admit Date/Time R Must always be populated in visit-level ADT messages.

45 Discharge Date/Time C 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 N

47 Total Charges N

48 Total Adjustment N

49 Total Payments N

50 Alternate Visit ID N

51 Visit Indicator N

52 Other Healthcare Providers N

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



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.


01 Prior Pending Locations N

02 Accommodation Code O See Codeset: CS_ACCOMODATION

03 Admit Reason O

03.1 Admit Reason Code N

03.2 Admit Reason Text O

04 Transfer Reason N

04.1 Transfer Reason Code N

04.2 Transfer Reason Text N

05 Patient Valuables N

06 Patient Valuables Location N

07 Visit User Code N

08 Expected Admit Date N

09 Expected Discharge Date N

10 Estimated Length of Inpatient Stay

N

11 Actual Length of Inpatient Stay

N

12 Visit Description N

13 Referral Source Code N

14 Previous Service Date N

15 Employment Illness Related Indicator

N

16 Purge Status Code N

17 Purge Status Date N

18 Special Program Code N

19 Retention Indicator N

20 Expected Number of Insurance Plans

N

21 Visit Publicity Code N

22 Visit Protection Indicator O See Codeset: CS_PROTECTION_IND

6.2.4.1 PV2 Medicity Business Rules and Guidelines





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 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 Comments

01 Set ID - AL1 R Required if an AL1 segment is sent.

02 Allergy Type R

03 Allergy Code R

03.1 Identifier O

03.2 Description R

03.3 Name of Coding System O

04 Allergy Severity O See Codeset: CS_ALLERGY_SEVERITY_CODE

05 Allergy Reaction O See Codeset: CS_ALLERGY_REACTION_CODE

06 Identification Date O

Medicity Business Rules and Guidelines

When allergies are sent the entire inclusive list of allergies for this encounter must be sent.



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

DG1 Seq Name R/O Comments

01 Set ID - DG1 R

02 Diagnosis Coding Method R See Codeset: CS_DIAGNOSIS_CODE_METHOD

Medicity requires that DG1:2 and DG1:3.3 match.

03 Diagnosis Code C Can be blank for a free-text diagnosis, but must be populated if a coded diagnosis.

03.1 Identifier R Must be populated with a code

03.2 Description R Must be populated with a description.

03.3 Name of Coding System R Medicity requires that DG1:2 and DG1:3.3 match.

04 Diagnosis Description C See Diagnosis Coding Method RULES for terms of usage.

05 Diagnosis Date and Time R Allowed blank for backwards compatibility.

06 Diagnosis Type R See Codeset: CS_DIAGNOSIS_TYPE

07 Major Diagnostic Category (MDB) N

08 Diagnostic Related Group N

09 DRG Approval Indicator N

10 DRG Group Review Code N

11 Outlier Type N

12 Outlier Days N

13 Outlier Cost N

14 Grouper Version and Type N

15 Diagnosis Priority R Allowed blank for backwards compatibility.

Acceptable values: 0 = Not included in diagnosis ranking 1 = The primary diagnosis 2 = For ranked secondary diagnoses

16 Diagnosing Clinician N

17 Diagnosis Classification N



18 Confidential Indicator R See Codeset: CS_PROTECTION_IND

19 Attestation Date/Time N

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 co

medicity proaccess 7 adt product specification (4)

Documents

property of medicity

trademark of medicity

medicity business rules

patient matching

insured matching

registered trademarks

document purpose

document scope