ediverse Explore the platform

Spotlight PEPPOL BIS Billing 3.0 The EU e-invoicing mandate is here — France Sept 2026, Belgium Jan 2026, Germany 2025.

Account — The patient financial account

Before the invoice, there is the account. Account models that financial container — hospital stay, ambulatory file, therapeutic program — onto which ChargeItems and Invoices are progressively posted.

Purpose

Account is the financial pivot of the patient record. It aggregates entries (ChargeItem), coverages (Coverage) ordered by priority, financial guarantor and the Organization owning the accounting file.

In the US, this is the hospital account or visit account, unique encounter identifier for billing. In France, Account maps to the IFA (Identifiant Facture Aval) of a stay, linked to one or more RUM.

Key fields

FieldTypeCardinalityRole
identifierIdentifier[]0..*External identifiers (hospital account number).
statuscode1..1Mandatory. active | inactive | entered-in-error | on-hold | unknown.
billingStatusCodeableConcept0..1Billing state (open, carecomplete-notbilled, billing...).
typeCodeableConcept0..1Account type (patient billing, retail...).
namestring0..1Account name.
subjectReference(Patient | Device | Practitioner | PractitionerRole | Location | HealthcareService | Organization)[]0..*Account subject(s).
servicePeriodPeriod0..1Period covered by the account.
coverageBackboneElement[]0..*Applicable coverages with priority.
ownerReference(Organization)0..1Owning Organization (the hospital).
descriptionmarkdown0..1Free description.
guarantorBackboneElement[]0..*Financial guarantor(s).
guarantor.partyReference(Patient | RelatedPerson | Organization)1..1Guarantor.
guarantor.onHoldboolean0..1Guarantor on hold.
diagnosisBackboneElement[]0..*Diagnoses attached to the account (R5).
procedureBackboneElement[]0..*Attached procedures (R5).
relatedAccountBackboneElement[]0..*Related accounts (parent, refunded...).
currencyCodeableConcept0..1Currency (R5).
balanceBackboneElement[]0..*Current balance (R5).

JSON example

Peter Chalmers's account for the HACC program, H1 2026 period, covered by Coverage/example, guarantor the patient himself:

json account-example.json
{
  "resourceType": "Account",
  "id": "example",
  "identifier": [{
    "system": "urn:oid:0.1.2.3.4.5.6.7",
    "value": "654321"
  }],
  "status": "active",
  "billingStatus": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/billingstatus",
      "code": "open"
    }]
  },
  "type": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
      "code": "PBILLACCT",
      "display": "patient billing account"
    }]
  },
  "name": "HACC Funded Billing for Peter James Chalmers",
  "subject": [{ "reference": "Patient/example" }],
  "servicePeriod": {
    "start": "2026-01-01",
    "end": "2026-06-30"
  },
  "coverage": [{
    "coverage": { "reference": "Coverage/example" },
    "priority": 1
  }],
  "owner": { "reference": "Organization/hl7" },
  "description": "Hospital charges",
  "guarantor": [{
    "party": { "reference": "Patient/example" },
    "onHold": false
  }]
}

Common pitfalls

  • Coverage not ordered by priority — priority 1 (primary insurance) MUST be explicit; without it, billing sequencing is ambiguous.
  • Account without owner — without owner, the receiver doesn't know whom to pay.
  • Account without guarantor — for non-covered items, a guarantor is mandatory (typically the patient).
  • Confusing Account / Coverage / Invoice — Coverage is the insurance policy, Account the container, Invoice the issued bill.
  • Multiple Accounts for a single encounter — typically OK when some care is non-covered. Link via relatedAccount.
  • Coverage — insurance policy.
  • ChargeItem — entry posted on the account.
  • Invoice — bill issued on the account.
  • Claim — insurance claim derived from the account.
  • Encounter — typically linked clinical encounter.