The resource ChargeItem describes the provision of healthcare provider products for a certain patient, therefore referring not only to the product, but containing in addition details of the provision, like date, time, amounts and participating organizations and persons. Main Usage of the ChargeItem is to enable the billing process and internal cost allocation.

Identifiers assigned to this event performer or other systems.

Allows identification of the charge Item as it is known by various participating systems and in a way that remains consistent across servers.

References the source of pricing information, rules of application for the code this ChargeItem uses.

Target Resource is yet to be defined as a container that holds information about list prices and rules applicable to the charge item code. Once defined, change type back to Reference(Definition Type).

The current state of the ChargeItem.

Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is.

This element is labeled as a modifier because the status contains the code entered-in-error that marks the charge item as not currently valid.

ChargeItems can be grouped to larger ChargeItems covering the whole set.

E.g. Drug administration as part of a procedure, procedure as part of observation, etc.

A code that identifies the charge, like a billing code.

The individual or set of individuals the action is being or was performed on.

Links the event to the Patient context.

The encounter or episode of care that establishes the context for this event.

Links the request to the Encounter context.

Date/time(s) or duration when the charged service was applied.

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 performance or participation(e.g. primary surgeon, anaesthesiologiest, etc.).

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

The organization requesting the service.

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.

The organization performing the service.

The rendered Service might not be associated with a Request. It has to be made clear, ob which Organization's Request, the services have been rendered. (In many cases, this may just be the Department associated with the Encounter.location).

The financial cost center permits the tracking of charge attribution.

The costCenter could either be given as a reference to a Organization(Role) resource or as the identifier of the cost center determined by Reference.identifier.value and Reference.identifier.system, depending on use case requirements.

Quantity of which the charge item has been serviced.

In many cases this may just be a value, if the underlying units are implicit in the definition of the charge item code.

The anatomical location where the related service has been applied.

Only used if not implicit in code found in Condition.code. If the use case requires attributes from the BodySite resource (e.g. to identify and track separately) then use the standard extension body-structure. May be a summary code, or a reference to a very precise definition of the location, or both.

Factor overriding the factor determined by the rules associated with the code.

There is no reason to carry the factor in the instance of a ChargeItem unless special circumstances require a manual override. The factors are usually defined by a set of rules 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.

Total price of the charge overriding the list price associated with the code.

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.

If the list price or the rule based factor associated with the code is overridden, this attribute can capture a text to indicate the reason for this action.

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

The device, practitioner, etc. who entered the charge item.

The enterer is also te person considered responsible for factor/priceOverrides if applicable.

Date the charge item was entered.

The actual date when the service associated with the charge has been rendered is captured in occurrence[x].

Describes why the event occurred in coded or textual form.

If the application of the charge item requires a reason to be given, it can be captured here. Textual reasons can be captured using reasonCode.text.

Indicated the rendered service that caused this charge.

Account into which this ChargeItems belongs.

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.

Comments made about the event by the performer, subject or other participants.

Further information supporting this charge.