Account

Introduction

Scope and Usage

The Account resource acts as a central record against which charges, payments, and adjustments are applied. It contains information about which parties are responsible for payment of the account.

While the Account does conceptually have a balance, expressing that balance directly as a resource property is challenging due to the complexity of pricing contracts. An operation to retrieve the current balance of an account is in consideration as future work.

Boundaries and Relationships

The Account itself does not include information about the charges, payments or adjustments, but rather those resources, such as ChargeItem point to the account to which they apply. Payment and adjustment resources have not yet been developed.

Background and Context

The Account resource can be considered a "bucket" to which ChargeItem resources are linked. These charges are processed by a billing system, which determines the responsible parties for the balance of the account. The billing system then submits claims or sends statements to the appropriate parties. Once payment is received, an adjustment is applied to the Account. The internal calculation of balances and allocation of responsibility is expected to be internal to the billing systems. Only the inputs and outputs of the billing process is communicated in the relevant financial FHIR resources.

Notes

Notes

Perpetual and Episodic Accounts

There may be two types of accounts that are used to track billing activities with medical systems:

• Episodic Account: An account that collects the charges for a specific set of services offered over a limited time period. For example, a hospital account might contain all charges related to a given admission, including any inpatient appointments, and possibly re-admissions, of the billing for those re-admissions should be grouped with the initial admission for the purpose of claim submission.
  Episodic Accounts often exist for the duration of a relatively short billing cycle (for example, a month, or possibly a quarter). One a given billing cycle ends, the associated Episodic Account would close, and a new account would open for the next billing cycle. A patient that is admitted for 6 months, where the billing cycle is monthly, would have 6 episodic accounts each covering one month.
  Episodic Accounts are intended to be communicated using the Account.covers property.
• Perpetual Account A long running account that accumulates charges and payments associated with a specific beneficiary. This account is often open for as long as the beneficiary has a relationship with the healthcare organization. It may be linked to an EpisodeOfCare. A beneficiary may have different perpetual accounts. For example, one for charges related to car crash (i.e., third party liability). One associated with charges related to a research study the patient is participating in. And one for their general personal/family care, which would be covered by their normal insurance.
  Perpetual Accounts are intended to be communicated using the Encounter.account or EpisodeOfCare.account properties.

References to Patient

Accounts might reference a different Patient resource instance than is referenced by clinical resources if the demographics for the Account differ from the demographics that are most appropriate for clinical purposes. For example, the demographics on Account might need to exactly match what the insurance company has on file in order for claims to be processed efficiently. But the demographics the insurance company have might not reflect the demographics that are appropriate for coordinating clinical care. When two (or more) Patient resource instances are used, they should be linked using Patient.link with a type of seealso.

StructureDefinition

Elements (Simplified)

• Account [0..*]: - Tracks balance, charges, for patient or cost center
• Account.identifier [0..*]: Identifier Account number
• Account.status [1..1]: code required:account-status active | inactive | entered-in-error | on-hold | unknown
• Account.billingStatus [0..1]: CodeableConcept example:account-billing-status Tracks the lifecycle of the account through the billing process
• Account.type [0..1]: CodeableConcept example:account-type E.g. patient, expense, depreciation
• Account.name [0..1]: string Human-readable label
• Account.subject [0..*]: [Reference(Patient](/Reference(Patient), Device, Practitioner, PractitionerRole, Location, HealthcareService, Organization)) The entity that caused the expenses
• Account.servicePeriod [0..1]: Period Transaction window
• Account.covers [0..*]: [Reference(Encounter](/Reference(Encounter), EpisodeOfCare)) Episodic account covering these encounters/episodes of care
• Account.coverage [0..*]: BackboneElement The party(s) that are responsible for covering the payment of this account, and what order should they be applied to the account
• Account.coverage.coverage [1..1]: Reference(Coverage) The party(s), such as insurances, that may contribute to the payment of this account
• Account.coverage.priority [0..1]: positiveInt The priority of the coverage in the context of this account
• Account.owner [0..1]: Reference(Organization) Entity managing the Account
• Account.description [0..1]: markdown Explanation of purpose/use
• Account.guarantor [0..*]: BackboneElement The parties ultimately responsible for balancing the Account
• Account.guarantor.party [0..1]: [Reference(Patient](/Reference(Patient), RelatedPerson, Organization)) Responsible entity
• Account.guarantor.onHold [0..1]: boolean Credit or other hold applied
• Account.guarantor.period [0..1]: Period Guarantee account during
• Account.guarantor.account [0..1]: Reference(Account) A specific Account for the guarantor
• Account.guarantor.responsibility [0..1]: Quantity(SimpleQuantity) Responsible %'age of charges
• Account.guarantor.limit [0..1]: Money Responsible financial limit
• Account.guarantor.rank [0..1]: positiveInt Rank order of guarator
• Account.diagnosis [0..*]: BackboneElement The list of diagnoses relevant to this account
• Account.diagnosis.sequence [0..1]: positiveInt Ranking of the diagnosis (for each type)
• Account.diagnosis.condition [1..1]: CodeableReference example:condition-code The diagnosis relevant to the account
• Account.diagnosis.dateOfDiagnosis [0..1]: dateTime Date of the diagnosis (when coded diagnosis)
• Account.diagnosis.type [0..*]: CodeableConcept preferred:encounter-diagnosis-use Type that this diagnosis has relevant to the account (e.g. admission, billing, discharge …)
• Account.diagnosis.onAdmission [0..1]: boolean Diagnosis present on Admission
• Account.diagnosis.packageCode [0..*]: CodeableConcept Package Code specific for billing
• Account.procedure [0..*]: BackboneElement The list of procedures relevant to this account
• Account.procedure.sequence [0..1]: positiveInt Ranking of the procedure (for each type)
• Account.procedure.code [1..1]: CodeableReference example:procedure-code The procedure relevant to the account
• Account.procedure.dateOfService [0..1]: dateTime Date of the procedure (when coded procedure)
• Account.procedure.type [0..*]: CodeableConcept How this procedure value should be used in charging the account
• Account.procedure.packageCode [0..*]: CodeableConcept Package Code specific for billing
• Account.procedure.device [0..*]: Reference(Device) Any devices that were associated with the procedure
• Account.parent [0..1]: Reference(Account) Reference to an associated parent Account
• Account.currency [0..1]: CodeableConcept required:currencies The base or default currency
• Account.balance [0..*]: BackboneElement Calculated account balance(s)
• Account.balance.aggregate [0..1]: CodeableConcept extensible:account-aggregate Who is expected to pay this part of the balance
• Account.balance.term [0..1]: CodeableConcept extensible:account-balance-term current | 30 | 60 | 90 | 120
• Account.balance.estimate [0..1]: boolean Estimated balance
• Account.balance.amount [1..1]: Money Calculated amount
• Account.calculatedAt [0..1]: instant Time the balance amount was calculated

Mappings

• Account Mappings — 23 mapping entries

Resource Packs

list-Account-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://hl7.org/fhir ../../publish/List.xsd">
  <id value="Account-packs"/>
  <status value="current"/>
  <mode value="working"/>
</List>

Search Parameters

• identifier — token — Account number — Account.identifier
• name — string — Human-readable label — Account.name
• owner — reference — Entity managing the Account — Account.owner
• patient — reference — The entity that caused the expenses — Account.subject.where(resolve() is Patient)
• period — date — Transaction window — Account.servicePeriod
• status — token — active | inactive | entered-in-error | on-hold | unknown — Account.status
• subject — reference — The entity that caused the expenses — Account.subject
• guarantor — reference — The parties ultimately responsible for balancing the Account — Account.guarantor.party
• type — token — E.g. patient, expense, depreciation — Account.type
• guarantor-account — reference — Account to use for the guarantor — Account.guarantor.account

Full Search Parameters

Examples

• account-example — account-example
• account-example-with-guarantor — account-example-with-guarantor
• account-examples-header — account-examples-header
• ewg — account-example-with-guarantor — Example with a Guarantor
• example — account-example — General Account example

Full Examples

Mapping Exceptions

account-fivews-mapping-exceptions.xml

Unmapped Elements

• FiveWs.recorded — Unknown
• FiveWs.author — Unknown
• FiveWs.actor — Unknown
• FiveWs.cause — Unknown
• FiveWs.version — Unknown
• FiveWs.witness — Not relevant for this resource
• FiveWs.where — Unknown
• FiveWs.context — Unknown
• FiveWs.init — Not relevant for this resource
• FiveWs.why — Unknown
• FiveWs.source — Not relevant for this resource
• FiveWs.who — Unknown
• FiveWs.grade — Not relevant for this resource
• FiveWs.planned — Not relevant for this resource