Invoice containing collected ChargeItems from an Account with calculated individual and total price for Billing purpose.

Identifier of this Invoice, often used for reference in corresponcence about this invoice or for tracking of payments.

Allows Identification of this Invoice instance.

The current state of the Invoice.

In case of Invoice cancellation a reason must be given (entered in error, superseded by corrected invoice etc).

Derived Profiles may chose to add invariants requiring this field to be populated if either priceOverride or factorOverride have been filled.

Type of Invoice depending on domain, realm an usage (eg. internal/external, dental, preliminary).

The individual or set of individuals receiving the goods and services billed in this invoice.

Links the event to the Patient context.

The individual or Organization responsible for balancing of this invoice.

Date/time(s) of when this Invoice was posted.

The list of types may be constrained as appropriate for the type of charge item.

Indicates who or what performed or participated in the charged service.

Describes the type of involvement (e.g. transcriptionist, creator etc.). If the invoice has been created automatically, the Participant may be a billing engine or another kind of device.

The device, practitioner, etc. who performed or participated in the service.

The organizationissuing the Invoice.

Practitioners and Devices can be associated with multiple organizations. It has to be made clear, on behalf of which Organization the services have been rendered.

Account which is supposed to be balanced with this Invoice.

Systems posting the ChargeItems might not always be able to determine, which accounts the Items need to be places into. It is up to the potprocessing Financial System to apply internal rules to decide based on the Encounter/EpisodeOfCare/Patient/Coverage context and the type of ChargeItem, which Account is appropriate.

Each line item represents one charge for goods ond services rendered. Details such as date, code and amount are found in the referenced ChargeItem resource.

Sequence in which the items appear on the invoice.

The ChargeItem contains information such as the billing code, date, amount etc.

The price for a ChargeItem may be calculated as a base price with surcharges/deductions that apply in certain conditions. A ChargeItemDefinition resource that defines the prices, factors and conditions that apply to a billing code is currently under developement. The priceComponent element can be used to offer transparency to the recipient of the Invoice of how the prices have been calculated.

This code identifies the type of the component.

A code that identifies the component. Codes may be used to differentiate between kinds of taxes, surcharges, discounts etc.

The amount calculated for this component.

There is no reason to carry the price in the instance of a ChargeItem unless circumstances require a manual override. The list prices or are usually defined in a back catalogue of the billing codes (see ChargeItem.definition). Derived profiles may require a ChargeItem.overrideReason to be provided if either factor or price are manually overriden.

The factor that has been applied on the base price for calculating this component.

There is no reason to carry the price in the instance of a ChargeItem unless circumstances require a manual override. The list prices or are usually defined in a back catalogue of the billing codes (see ChargeItem.definition). Derived profiles may require a ChargeItem.overrideReason to be provided if either factor or price are manually overriden.

The total amount for the Invoice may be calculated as the sum of the line items with surcharges/deductions that apply in certain conditions. The priceComponent element can be used to offer transparency to the recipient of the Invoice of how the total price was calculated.

Invoice total , taxes excluded.

There is no reason to carry the price in the instance of a ChargeItem unless circumstances require a manual override. The list prices or are usually defined in a back catalogue of the billing codes (see ChargeItem.definition). Derived profiles may require a ChargeItem.overrideReason to be provided if either factor or price are manually overriden.

Invoice total, tax included.

There is no reason to carry the price in the instance of a ChargeItem unless circumstances require a manual override. The list prices or are usually defined in a back catalogue of the billing codes (see ChargeItem.definition). Derived profiles may require a ChargeItem.overrideReason to be provided if either factor or price are manually overriden.

Payment details such as banking details, period of payment, deductables, methods of payment.

Derived Profiles may chose to add invariants requiring this field to be populated if either priceOverride or factorOverride have been filled.

Comments made about the invoice by the issuer, subject or other participants.