FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

8.13 Resource Account - Content

Patient Administration icon Work GroupMaturity Level: 2 Trial UseSecurity Category: Patient Compartments: Device, Patient, Practitioner

A financial tool for tracking value accrued for a particular purpose. In the healthcare field, used to track charges for a patient, cost centers, etc.

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.

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.

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.

Structure

NameFlagsCard.TypeDescription & Constraintsdoco
.. Account TU DomainResource Tracks balance, charges, for patient or cost center

Elements defined in Ancestors: id, meta, implicitRules, language, text, contained, extension, modifierExtension
... identifier Σ 0..* Identifier Account number

... status ?!Σ 1..1 code active | inactive | entered-in-error | on-hold | unknown
Binding: Account Status (Required)
... billingStatus Σ 0..1 CodeableConcept Tracks the lifecycle of the account through the billing process
Binding: Example Account Billing Statuses (Example)
... name Σ 0..1 string Human-readable label
... subject Σ 0..* Reference(Patient | Device | Practitioner | PractitionerRole | Location | HealthcareService | Organization) The entity that caused the expenses

... servicePeriod Σ 0..1 Period Transaction window
... covers Σ 0..* Reference(Encounter | EpisodeOfCare) Episodic account covering these encounters/episodes of care

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

.... coverage Σ 1..1 Reference(Coverage) The party(s), such as insurances, that may contribute to the payment of this account
.... priority Σ 0..1 positiveInt The priority of the coverage in the context of this account
... owner Σ 0..1 Reference(Organization) Entity managing the Account
... description Σ 0..1 markdown Explanation of purpose/use
... guarantor 0..* BackboneElement The parties ultimately responsible for balancing the Account

.... party 1..1 Reference(Patient | RelatedPerson | Organization) Responsible entity
.... onHold 0..1 boolean Credit or other hold applied
.... period 0..1 Period Guarantee account during
... diagnosis ΣCTU 0..* BackboneElement The list of diagnoses relevant to this account
+ Rule: The dateOfDiagnosis is not valid when using a reference to a diagnosis

.... sequence 0..1 positiveInt Ranking of the diagnosis (for each type)
.... condition ΣC 1..1 CodeableReference(Condition) The diagnosis relevant to the account
Binding: Condition/Problem/Diagnosis Codes (Example)
.... dateOfDiagnosis C 0..1 dateTime Date of the diagnosis (when coded diagnosis)
.... type 0..* CodeableConcept Type that this diagnosis has relevant to the account (e.g. admission, billing, discharge …)
Binding: Encounter Diagnosis Use (Preferred)

.... onAdmission 0..1 boolean Diagnosis present on Admission
.... packageCode 0..* CodeableConcept Package Code specific for billing
Binding: diagnosis-package-code (Example)

... procedure ΣCTU 0..* BackboneElement The list of procedures relevant to this account
+ Rule: The dateOfService is not valid when using a reference to a procedure

.... sequence 0..1 positiveInt Ranking of the procedure (for each type)
.... code ΣC 1..1 CodeableReference(Procedure) The procedure relevant to the account
Binding: Procedure Codes (SNOMED CT) (Example)
.... dateOfService C 0..1 dateTime Date of the procedure (when coded procedure)
.... type 0..* CodeableConcept How this procedure value should be used in charging the account
Binding: procedure-type (Example)

.... packageCode 0..* CodeableConcept Package Code specific for billing
Binding: procedure-package-code (Example)

.... device Σ 0..* Reference(Device) Any devices that were associated with the procedure

... relatedAccount 0..* BackboneElement Other associated accounts related to this account

.... relationship 0..1 CodeableConcept Relationship of the associated Account
Binding: Account Relationship (Example)
.... account 1..1 Reference(Account) Reference to an associated Account
... currency 0..1 CodeableConcept The base or default currency
Binding: Currencies (Required)
... balance 0..* BackboneElement Calculated account balance(s)

.... aggregate 0..1 CodeableConcept Who is expected to pay this part of the balance
Binding: Account Aggregate (Extensible)
.... term 0..1 CodeableConcept current | 30 | 60 | 90 | 120
Binding: Account Balance Term (Extensible)
.... estimate 0..1 boolean Estimated balance
.... amount 1..1 Money Calculated amount
... calculatedAt 0..1 instant Time the balance amount was calculated

doco Documentation for this format icon

See the Extensions for this resource

 

Additional definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions, the spreadsheet version & the dependency analysis

Path ValueSet Type Documentation
Account.status AccountStatus Required

Indicates whether the account is available to be used.

Account.billingStatus AccountBillingStatus (a valid code from Example Account Billing Statuses) Example

Indicates whether the account is available to be used for billing purposes.

Account.type AccountTypes Example

This examples value set defines the set of codes that can be used to represent the type of an account.

Account.diagnosis.condition ConditionProblemDiagnosisCodes Example

Example value set for Condition/Problem/Diagnosis codes.

Account.diagnosis.type EncounterDiagnosisUse Preferred

What a specific Encounter/EpisodeOfCare diagnosis.condition is to be used for.

Account.diagnosis.packageCode Example
Account.procedure.code ProcedureCodesSNOMEDCT Example

Procedure Code: All SNOMED CT procedure codes.

Account.procedure.type Example
Account.procedure.packageCode Example
Account.relatedAccount.relationship AccountRelationship Example

Relationship between accounts

Account.currency Currencies (a valid code from urn:iso:std:iso:4217) Required

Currency codes from ISO 4217 (see https://www.iso.org/iso-4217-currency-codes.html)

Account.balance.aggregate AccountAggregate Extensible

Indicates who is expected to pay a part of the account balance.

Account.balance.term AccountBalanceTerm Extensible

Indicates the account balance's age.

UniqueKeyLevelLocationDescriptionExpression
img act-1Rule Account.diagnosisThe dateOfDiagnosis is not valid when using a reference to a diagnosiscondition.reference.empty().not() implies dateOfDiagnosis.empty()
img act-2Rule Account.procedureThe dateOfService is not valid when using a reference to a procedurecode.reference.empty().not() implies dateOfService.empty()

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 may 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 may be communicated using the Encounter.account or EpisodeOfCare.account properties.

Search parameters for this resource. See also the full list of search parameters for this resource, and check the Extensions registry for search parameters on extensions related to this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.

Name Type Description Expression In Common
guarantor reference The parties ultimately responsible for balancing the Account Account.guarantor.party
(Organization, Patient, RelatedPerson)
identifier token Account number Account.identifier 65 Resources
name string Human-readable label Account.name
owner reference Entity managing the Account Account.owner
(Organization)
patient reference The entity that caused the expenses Account.subject.where(resolve() is Patient)
(Patient)
65 Resources
period date Transaction window Account.servicePeriod
relatedaccount reference Parent and other related accounts Account.relatedAccount.account
(Account)
status token active | inactive | entered-in-error | on-hold | unknown Account.status
subject reference The entity that caused the expenses Account.subject
(Practitioner, Organization, Device, Patient, HealthcareService, PractitionerRole, Location)
type token E.g. patient, expense, depreciation Account.type 11 Resources