HL7 BAR Messages: Add/Change Billing Account

HL7 BAR messages establish and update the billing account that ties a patient's encounter to the accounts-receivable system. A BAR message is sent from a registration or patient-administration source to the patient-accounting or financial system to open an account, update it, end it, or purge it. This page explains what a BAR message represents, the trigger events it carries in HL7 v2.5.1, every segment the message can contain and what each one holds, and how a BAR account relates to FHIR. Sample content is constructed for illustration with fictional identifiers.

What a BAR message represents

A BAR message — BAR stands for Add/Change Billing Account — communicates a change to a patient's billing account. The most common is BAR^P01, which adds a new account: data are sent from a source application, usually a registration or ADT system, to the patient-accounting or financial system to establish an account for a patient's billing and accounts-receivable record. From v2.3 onward the P01 event is used only to add an account that did not exist before; updates to an existing account are sent with BAR^P05.

The sender is typically the registration or patient-administration system, and the receiver is the financial or patient-accounting system. Many of the segments in a BAR message are optional, which lets each system populate only the fields it needs while still satisfying the base standard. Because the account it opens is what charges later post against, BAR is the financial counterpart to the clinical-administrative ADT feed: ADT establishes who the patient is and where they are, and BAR establishes the account those activities will be billed to.

When a BAR message is sent

A BAR message is sent when a billing account changes state. An account is opened at or near registration, may be updated as coding and coverage are added, and is ended when no further charges can accrue to it. With the P01 event, EVN-2 — Recorded Date/Time — should contain the account start date rather than the time the message was built.

Trigger events

HL7 v2.5.1 defines the following BAR trigger events:

BAR^P01 – Add patient account. Establishes a new billing/accounts-receivable record for a patient.
BAR^P02 – Purge patient accounts. Removes billing records from the system.
BAR^P05 – Update account. Sends changes to an existing account; from v2.3 it replaced P01 for updates.
BAR^P06 – End account. Notifies that the account is no longer open and no new charges can accrue to it.
BAR^P10 – Transmit ambulatory payment classification (APC) groups. Communicates APC grouping information for outpatient reimbursement.

Each BAR message is acknowledged with the corresponding ACK^P0x message. The event in MSH-9 drives the receiver's handling — whether it creates an account, updates one, closes one, or purges one.

Integration topology

The diagram shows the registration or ADT source emitting an account event through the integration engine to the financial system.

{{diagram: registration/ADT system → BAR message → integration engine → patient accounting / financial system}}

Typical senders: registration system, patient-administration / ADT system.

Typical receivers: patient-accounting system, financial / billing system.

Direction: unidirectional notification from the source that opens the encounter to the system that bills against it.

Segments in a BAR message

The segments below are those of the BAR^P01 add-account message in v2.5.1, the richest of the BAR structures. The message opens with header and event segments, identifies the patient, then carries a repeating VISIT group — the visit, its diagnoses, a repeating PROCEDURE group, the guarantor and next-of-kin, a repeating INSURANCE group, and accident and uniform-billing data. Cardinality follows HL7 notation: [X] optional, {X} repeating, [{X}] optional and repeating; a bare code is required. Each segment code links to its canonical field-by-field reference.

Segment	Description
`MSH`	Message Header. Opens every BAR message. It names the sending and receiving applications and facilities, stamps the creation time, declares the trigger event in `MSH-9` (for example `BAR^P01`), carries the message control id in `MSH-10`, and pins the HL7 version. Receivers route on `MSH-9` and deduplicate on `MSH-10`.
`[SFT]`	Software Segment. Identifies the software product behind the sender — vendor, product, and version. Optional.
`EVN`	Event Type. States which trigger event fired and when. For `BAR^P01`, `EVN-2` — Recorded Date/Time — should contain the account start date.
`PID`	Patient Identification. Identifies the patient the account belongs to — the identifier list in `PID-3`, the name in `PID-5`, birth date in `PID-7`, and sex in `PID-8`.
`[PD1]`	Patient Additional Demographic. Supplements `PID` with data such as the patient's primary-care facility. Optional.
`[{ROL}]`	Role. Names practitioners tied to the patient for this event, with the span of each assignment. Optional and repeating.
`{` VISIT begin	The visit group repeats once per visit billed to the account.
`[PV1]`	Patient Visit. The visit the account covers — patient class in `PV1-2`, assigned location in `PV1-3`, attending provider in `PV1-7`, and hospital service. Optional within the group.
`[PV2]`	Patient Visit Additional. Companion to `PV1` with admit reason and expected dates. Optional.
`[{ROL}]`	Role. Practitioners tied to the visit. Optional and repeating.
`[{DB1}]`	Disability. Patient disabilities with type and effective dates. Optional and repeating.
`[{OBX}]`	Observation/Result. Account- or visit-time observations. Optional and repeating.
`[{AL1}]`	Allergy Information. Patient allergies carried with the account. Optional and repeating.
`[{DG1}]`	Diagnosis. Diagnoses coded for the visit, with diagnosis priority and onset date — central to how the encounter is billed and grouped. Optional and repeating.
`[DRG]`	Diagnosis-Related Group. Assigns a DRG to the visit for inpatient case-mix and reimbursement. Optional.
`[{` PROCEDURE begin	The procedure group repeats once per coded procedure. Optional.
`[PR1]`	Procedures. A procedure performed during the visit, with its code, date, and any modifier.
`[{ROL}]`	Role. Practitioners tied to the procedure. Optional and repeating.
`}` PROCEDURE end
`[{GT1}]`	Guarantor. The party with financial responsibility for the account — the guarantor identifier in `GT1-2`, the name in `GT1-3`, and the relationship to the patient in `GT1-11`. Optional and repeating, since an account can carry more than one guarantor.
`[{NK1}]`	Next of Kin / Associated Parties. Relatives and associated parties, with relationship and contact details. Optional and repeating.
`[{` INSURANCE begin	The insurance group repeats once per coverage; multiple groups establish primary, secondary, and tertiary order. Optional.
`[IN1]`	Insurance. One coverage — payer, plan, policy and group number, and subscriber relationship.
`[IN2]`	Insurance Additional Information. Further subscriber and certification detail for the coverage. Optional.
`[{IN3}]`	Insurance Additional Information, Certification. Certification and pre-authorization detail. Optional and repeating.
`[{ROL}]`	Role. Practitioners tied to the coverage. Optional and repeating.
`}` INSURANCE end
`[ACC]`	Accident. Accident detail when the encounter follows an injury — the accident date and time in `ACC-1`, the accident code in `ACC-2`, and the accident location in `ACC-3`. Optional.
`[UB1]` / `[UB2]`	Uniform Billing Data. Institutional-billing data for the UB form — condition, occurrence, and value codes. Optional.
`}` VISIT end

[ ] = optional, { } = repeating

The VISIT group from PV1 through UB2 repeats once per visit, so a single BAR^P01 can open an account spanning more than one visit. The shorter BAR structures reuse this skeleton: BAR^P02 (purge) and BAR^P06 (end account) carry only MSH, [SFT], EVN, and a patient group with PID and visit detail. The canonical segment pages carry the full field-by-field detail.

Sample BAR^P01 message

Note. Constructed for illustration. Patient identifiers, account numbers, dates, and names are fictional.

MSH|^~&|REGISTRATION|MERCYGEN|BILLING|MERCYGEN|202006150900||BAR^P01^BAR_P01|MSG00021|P|2.5.1
EVN|P01|202006150900
PID|1||MR12345^^^MERCYGEN^MR||DOE^JOHN^Q||19800101|M
PV1|1|I|3WEST^301^A||||1234^SMITH^JANE^A^^^MD|||MED||||ADM|A0|||1234^SMITH^JANE^A^^^MD|S|ACCT99887^^^MERCYGEN^AN
DG1|1|ICD-10|R51.9^Headache, unspecified^I10|HEADACHE|202006150900|A
GT1|1|GTR5001|DOE^JOHN^Q||100 MAIN ST^^SPRINGFIELD^IL^62704|(555)555-0100||||SEL
IN1|1|PLAN001|HMO123^HEALTHCO HMO|HEALTHCO||||GRP9001||||20200101||||DOE^JOHN^Q|SEL

What this sample shows

The BAR^P01 in MSH-9 marks the opening of a billing account, and the matching P01 in EVN carries the account start date. PID carries the medical record number MR12345. PV1 places the patient as an inpatient (I) with an attending provider and the account number ACCT99887. The DG1 carries a coded diagnosis that drives how the encounter is billed. GT1 names the guarantor (GT1-2 identifier GTR5001, the name in GT1-3, and a self relationship in GT1-11), and IN1 carries the insurance coverage — payer HEALTHCO HMO, group GRP9001, and the subscriber.

Working with BAR messages

Read the event from MSH-9

Switch on MSH-9 to route. BAR^P01 opens an account, BAR^P05 updates one, BAR^P06 ends one, and BAR^P02 purges records. The event determines whether the receiver creates, amends, closes, or removes an account, so it drives the handling more than the message type alone.

Idempotency and deduplication

Use MSH-10, the message control id, as the deduplication key, and treat the account number — carried in the patient-account field of PV1 — as the business key for the account. BAR feeds are replayed after outages, and treating a repeated control id as a duplicate prevents a replayed P01 from opening a second account for the same encounter.

BAR works alongside ADT and the charge feed

A billing account does not stand alone. ADT establishes the patient and visit, BAR opens and maintains the account those activities bill to, and detailed financial transactions post against the account later. Reconcile the account opened by BAR^P01 against the visit identifiers carried in the matching ADT feed rather than treating the two streams as independent.

Add versus update

From v2.3 onward, BAR^P01 adds only a new account and BAR^P05 carries updates to an existing one. Applying a P01 as an update — or a P05 as a fresh insert — risks duplicate or orphaned accounts; route the two events to distinct create and update paths.

Vendor variance. Most segments in a BAR message are optional, so systems differ widely in which they populate — some send full diagnosis, guarantor, and insurance detail on the account, others send little beyond PID and PV1 and rely on a separate coverage feed. Confirm a partner's field usage against their interface specification rather than assuming the base standard.

FHIR equivalent

Conceptually, a BAR billing account corresponds to the FHIR Account resource, with the patient as a Patient resource, the coverages built from the insurance segments as Coverage resources, and, for a messaging exchange, a MessageHeader at the head of a Bundle.

There is, however, no published mapping to lean on. The HL7 v2-to-FHIR Implementation Guide publishes no message map for any BAR trigger event — its message maps cover a subset of other message types, and BAR is not among them. A FHIR Account produced from a BAR message is therefore mapped manually: the account and guarantor are derived from the patient, visit, and GT1 data, and the coverage is built from the IN1 insurance segments. Because the IG publishes no ConceptMap for this message, treat any such mapping as a local design decision rather than a standard.

Common pitfalls

Pitfall. Treating BAR^P01 and BAR^P05 as interchangeable. P01 adds a new account and P05 updates an existing one; conflating them creates duplicate or orphaned accounts.

Pitfall. Ignoring EVN-2. For P01 it carries the account start date, not the message build time; reading it as a generic timestamp misdates the account.

Pitfall. Assuming a fixed date-time precision. Some senders stamp dates as YYYYMMDD and others as a full timestamp with an offset; do not assume a timezone — normalize on ingest.

How Vorro handles BAR messages

Vorro ingests the BAR feed over MLLP or another transport, deduplicates on MSH-10, routes by the trigger event in MSH-9, and applies each event to the financial destination in the format it expects — opening an account on P01, updating it on P05, closing it on P06, and purging on P02. Vorro reads the account, guarantor, diagnosis, and coverage from the PV1, GT1, DG1, and IN1 segments, and, where a FHIR destination is configured, maps the account to an Account resource with Coverage — composed manually, since the v2-to-FHIR Implementation Guide publishes no map for this message.

DFT — the detailed financial transaction that posts charges against the account a BAR message opens.
ADT — the admission/discharge/transfer feed that establishes the patient and visit the account bills against.
ORM — orders placed during the encounter that generate the charges later billed to the account.

Sources

HL7 v2-to-FHIR IG — message maps index — confirms no message map for any BAR trigger event
HL7 v2-to-FHIR IG — segment maps index
HL7 v2.5.1 standard, Chapter 6 (Financial Management) — hl7.eu mirror — BAR trigger events and BAR_P01/P02/P06 message structures
HL7 v2 BAR_P01 message structure (hl7.eu refactored)
HL7 v2 BAR_P05 message structure (hl7.eu refactored)
HL7 v2 BAR_P06 message structure (hl7.eu refactored)
HL7 v2 GT1 segment definition (hl7.eu refactored)
HL7 v2 ACC segment definition (hl7.eu refactored) </content>

</invoke>

← Back to HL7 v2 Guide