18.15.1 Financial Management (99.1.2)

18.16 PATIENT ACCOUNTING MESSAGE SET (6.3)

The patient accounting message set provides for the entry and manipulation of information on billing accounts, charges, payments, adjustments, insurance, and other related patient billing and accounts receivable information.

This Standard includes all of the data defined in the National Uniform Billing Field Specifications. We have excluded state-specific coding and suggest that, where required, it be implemented in site-specific "Z" segments. State-specific fields may be included in the Standard at a later time. In addition, no attempt has been made to define data that have traditionally been required for the financial responsibility ("proration") of charges. This requirement is unique to a billing system and not a part of an interface.

We recognize that a wide variety of billing and accounts receivable systems exist today. Therefore, in an effort to accommodate the needs of the most comprehensive systems, we have defined an extensive set of transaction segments.

18.17 TRIGGER EVENTS AND MESSAGE DEFINITIONS (6.4)

The triggering events that follow are served by Detail Financial Transaction (DFT), Add/Change Billing Account (BAR), and General Acknowledgment (ACK) messages.

Each trigger event is documented below, along with the applicable form of the message exchange. The notation used to describe the sequence, optionality, and repetition of segments is described in Chapter 2, "Format for Defining Abstract Messages."

18.17.1 BAR/ACK - Add Patient Account (Event P01) (6.4.1)

Data are sent from some application (usually a Registration or an ADT system, for example) to the patient accounting or financial system to establish an account for a patient's billing/accounts receivable record. Many of the segments associated with this event are optional. This optionality allows those systems needing these fields to set up transactions that fulfill their requirements and yet satisfy the HL7 requirements.

When an account's start and end dates span a period greater than any particular visit, the P01 (add account) event should be used to transmit the opening of an account. The A01 (admit/visit notification) event can notify systems of the creation of an account as well as notify them of a patient's arrival in the healthcare facility. In order to create a new account without notifying systems of a patient's arrival, use the P01 trigger event.

From Standard Version 2.3 onward, the P01 event should only be used to add a new account that did not exist before, not to update an existing account. The new P05 (update account) event should be used to update an existing account. The new P06 (end account) event should be used to close an account. With the P01 event, EVN-2 - Recorded Date/Time should contain the account start date.

The error segment will indicate the fields that caused a transaction to be rejected.

18.17.2 BAR/ACK - Purge Patient Accounts (Event P02) (6.4.2)

Generally, the elimination of all billing/accounts receivable records will be an internal function controlled, for example, by the patient accounting or financial system. However, on occasion, there will be a need to correct an account, or a series of accounts, that may require that a notice of account deletion be sent from another sub-system and processed, for example, by the patient accounting or financial system. Although a series of accounts may be purged within this one event, we recommend that only one PID segment be sent per event.

The error segment indicates the fields that caused a transaction to be rejected.

18.17.3 DFT/ACK - Post Detail Financial Transactions (Event P03) (6.4.3)

The Detail Financial Transaction (DFT) message is used to describe a financial transaction transmitted between systems, that is, to the billing system for ancillary charges, ADT to billing system for patient deposits, etc.

Use case for Post Detail Financial Transaction with related Order:

This information can originate in many ways. For instance, a detailed financial transaction for an ancillary charge is sent to a billing system that also tracks the transaction(s) in relation to their order via placer order number or wishes to post these transactions with the additional order information. Therefore a service reaches a state where a detailed financial transaction is created and interfaced to other systems along with optional associated order information. If the message contains multiple transactions for the same order, such as a test service and venipuncture charge on the same order, the ordering information is entered in the Order segment construct that precedes the FT1 segments. If a message contains multiple transactions for disparate orders for the same account each FT1 segment construct may contain the order related information specific to that transaction within the message.

If the common order information is sent, the Order Control Code should reflect the current state of the common order and is not intended to initiate any order related triggers on the receiving application. For example if observations are included along with common order information the order control code would indicate 'RE' as observations to follow.

If common order information is sent related to the entire message or a specific financial transaction, the required Order Control Code should reflect the current state of the common order and is not intended to initiate any order related triggers on the receiving application. For example if observations are included along with common order information the order control code would indicate 'RE' as observations to follow.

If order detail information is sent related to the entire message or a specific financial transaction, the required fields for that detail segment must accompany that information.

Note: The ROL segment is optionally included after the PD1 to transmit information for patient level primary care providers, after the PV2 for additional information on the physicians whose information is sent there (i.e., Attending Doctor, Referring Doctor, Consulting Doctor), and within the insurance construct to transmit information for insurance level primary care providers.

Note: There is an information overlap between the FT1, DG1 and PR1 segments. If diagnosis information is sent in an FT1 segment, it should be consistent with the information contained in any DG1 segments present within its hierarchy. Since the procedure code field within the FT1 does not repeat, if procedure information is sent on an FT1 it is recommended that the single occurrence of the code in FT1 equates to the primary procedure (PR1-14 - Procedure Priority code value 1).

Note: The extra set of DG1/DRG/GT1/IN1/IN2/IN3/ROL segments added in V2.4 have been withdrawn as a technical correction

The error segment indicates the fields that caused a transaction to be rejected.

18.17.4 QRY/DSR - Generate Bills And Accounts Receivable Statements (Event P04) (6.4.4)

Retained for backwards compatibility only in version 2.4 and later; refer to Chapter 5, "Queries", section 5.4.  The original mode query and the QRD/QRF segments have been replaced.

18.17.5 BAR/ACK - Update Account (Event P05) (6.4.5)

The P05 event is sent when an existing account is being updated. From version 2.3 onward, the P01 (add account) event should no longer be used for updating an existing account, but only for creating a new account. With the addition of P10 (transmit ambulatory payment classification [APC] groups) in version 2.4, it is expected that the P05 (update account) will be used to send inpatient coding information and the P10 (transmit ambulatory payment classification [APC] groups) will be used to send outpatient coding information.

The error segment indicates the fields that caused a transaction to be rejected.

18.17.6 BAR/ACK - End Account (event P06) (6.4.6)

The P06 event is a notification that the account is no longer open, that is, no new charges can accrue to this account. This notification is not related to whether or not the account is paid in full. EVN-2 - Recorded Date/Time must contain the account end date.

The error segment indicates the fields that caused a transaction to be rejected.

Note: P07-P09 have been defined by the Orders/Observations Technical Committee as product experience messages. Refer to Chapter 7.

18.17.7 BAR/ACK - Transmit Ambulatory Payment Classification (APC) Groups (Event P10) (6.4.7)

The P10 event is used to communicate Ambulatory Payment Classification (APC) grouping. The grouping can be estimated or actual, based on the APC status indictor in GP1-1. This information is mandated in the USA by the Centers for Medicare and Medicaid Services (CMS) for reimbursement of outpatient services. The PID and PV1 segments are included for identification purposes only. When other patient or visit related fields change, use the A08 (update patient information) event.

The error segment indicates the fields that caused a transaction to be rejected.

18.17.8 DFT/ACK - Post Detail Financial Transactions - Expanded (Event P11) (6.4.8)

The Detail Financial Transaction (DFT) - Expanded message is used to describe a financial transaction transmitted between systems, that is, to the billing system for ancillary charges, ADT to billing system for patient deposits, etc. It serves the same function as the Post Detail Financial Transactions (event P03) message, but also supports the use cases described below.

Use case for adding the INx and GT1 segments inside the FT1 repetition:

If the insurance and/or the guarantor information is specific to a certain financial transaction of a patient and differs from the patient's regular insurance and/or guarantor, you may use the INx and GT1 segments related to the FT1 segment. If being used, the information supersedes the information on the patient level.

Example: Before being employed by a company, a pre-employment physical is required. The cost of the examinations is paid by the company, and not by the person's private health insurance. One of the physicians examining the person is an eye doctor. For efficiency reasons, the person made an appointment for these examinations on the same day as he already had an appointment with his eye doctor in the same hospital. The costs for this eye doctor appointment are being paid by the patient's private health insurance. Both financial transactions for the same patient/person could be sent in the same message. To bill the examination for the future-employer to that organization, you need to use the GT1 segment that is related to the FT1.

Note: The ROL segment is optionally included after the PD1 to transmit information for patient level primary care providers, after the PV2 for additional information on the physicians whose information is sent there (i.e., Attending Doctor, Referring Doctor, Consulting Doctor), and within the insurance construct to transmit information for insurance level primary care providers.

Note: There is an information overlap between the FT1, DG1 and PR1 segments. If diagnosis information is sent in an FT1 segment, it should be consistent with the information contained in any DG1 segments present within its hierarchy. Since the procedure code field within the FT1 does not repeat, if procedure information is sent on an FT1 it is recommended that the single occurrence of the code in FT1 equates to the primary procedure (PR1-14 - Procedure Priority code value 1).

The error segment indicates the fields that caused a transaction to be rejected.

18.17.9 BAR/ACK - Update Diagnosis/Procedure (Event P12) (6.4.9)

The P12 event is used to communicate diagnosis and/or procedures in update mode. The newly created fields in DG1 and PR1, i.e., identifiers and action codes, must be populated to indicate which change should be applied. When other patient or visit related fields change, use the A08 (update patient information) event.

The error segment indicates the fields that caused a transaction to be rejected.

18.18 EXAMPLE TRANSACTIONS (6.6)

18.18.1 Create a patient billing/accounts receivable record (6.6.1)

MSH|^~\&|PATA|01|PATB|01|19930908135031||BAR^P01^BAR_P01|641|P|2.8|000000000000001|

EVN|P01|19930908135030||

PID|1||8064993^^^PATA1^MR^A~6045681^^^PATA1^BN^A~123456789ABC^^^US^NI~123456789^^^USSSA^SS||EVERYWOMAN^EVE^J^^^||19471007|F||1|22220018 HOMESTREET^^HOUSTON^TX^77030^USA|HAR||||S||6045681

GT1|001||JOHNSON^SAM^J||1111 HEALTHCARE DRIVE^^BALTIMORE^MD^

21234^USA|||||||193-22-1876

NK1|001|BETTERHALF^BORIS|F|2222 HOME STREET^^CUMBERLAND^MD

^28765^US|(301)555-2134

IN1|001|A357|1234|BCMD|||||132987

A patient has been registered by the ADT system (PATA) and notification is sent to the Patient Billing system (PATB). The patient's name is Eve J. Everywoman, a female Caucasian, born on October 7, 1947. Living at 1234 Homestreet, Houston, TX.

Ms. Everywoman's medical record number is 8064993 and her billing number is 6045681. Her national identifier is 123456789ABC. Her social security number, assigned by the U.S. Social Security Administration, is 123456789. Ms. Everywoman has provided her father's name and address for next of kin. Ms. Smith is insured under plan ID A357 with an insurance company known to both systems as BCMD, with a company ID of 1234.

18.18.2 Post a charge to a patient's account (6.6.2)

MSH|^~\&|PATA|01|PATB|01|19930908135031||DFT^P03^DFT_P03|641|P|2.8|000000000000001|

EVN|P03|19930908135030||

PID||0008064993^^^ENT^PE|0008064993^^^PAT^MR||0006045681^^^PATA^AN|EVERYWOMEN^EVE^J^^^|19471007|F||1|2222 HOMESTREET^^HOUSTON^TX^77030^USA|HAR||||S||6045681^^^PATA^AN

FT1|1|||19950715|19950716|CG|B1238^BIOPSY-SKIN^SYSTEMA|||1|||ONC|A357||||||P8765^KILDARE^BEN

A patient has been registered by the ADT system (PATA) and notification is sent to the Patient Billing system (PATB). The patient's name is Eve J. Everywoman, a female Caucasian, born on October 7, 1947. Living at 1234 Homestreet, Houston, TX.

Ms. Everywoman's patient number is 8064993 and her billing number is 6045681. This transaction is posting a charge for a skin biopsy to her account.

18.18.3 Update patient accounts - update UB1 information (6.6.3)

MSH|^~\&|UREV||PATB||19930906135030||BAR^P05^BAR_P05|MSG0018|P|2.8

EVN|P05|19930908135030

PID|||125976||EVERYMAN^ADAM^J|||||||||||||125976011

UB1|1|1|5|3|1||39|||01^500.00|||1|19880501|19880507|10^19880501

Utilization review sends data for Patient Billing to the Patient Accounting system. The patient's insurance program has a 1-pint deductible for blood; the patient received five pints of blood, and three pints were replaced, with one pint not yet replaced.

The patient has been assigned to a medically necessary private room (UB condition code 39). The hospital's most common semi-private rate is $500.00 (UB value code 01.)

The services provided for the period 05/01/88 through 05/07/88 are fully approved (PSRO/UR Approval Code 1). The patient's hospitalization is the result of an auto accident (UB occurrence code 01.)

18.18.4 Update patient accounts - update diagnosis and DRG information (6.6.4)

MSH|^~\&|UREV||PATB||19930908135030||BAR^P05^BAR_P05|MSG0018|P|2.8

EVN|P05|19930908135030

PID|||125976||EVERYMAN^ADAM^J|||||||||||||125976011

DG1|001|I9|1550|MAL NEO LIVER, PRIMARY|19880501103005|F

DRG|203|19880501103010|Y||D|5

The DG1 segment contains the information that the patient was diagnosed on May 1 as having a malignancy of the hepatobiliary system or pancreas (ICD9 code 1550). In the DRG segment, the patient has been assigned a Diagnostic Related Group (DRG) of 203 (corresponding to the ICD9 code of 1550). Also, the patient has been approved for an additional five days (five-day outlier).