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

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.

References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.

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

Links the request to the Encounter context.

References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.

Describes the type of performance or participation(e.g. primary surgeon, anaesthesiologiest, etc.).

Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination.

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

References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.

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 may 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 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-site-instance. 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.

References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.

Account into which this ChargeItems belongs.

Systems posting the ChargeItems may 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.

For systems that do not have structured annotations, they can simply communicate a single annotation with no author or time. This element may need to be included in narrative because of the potential for modifying information. Annotations SHOULD NOT be used to communicate "modifying" information that could be computable. (This is a SHOULD because enforcing user behavior is nearly impossible).

Further information supporting the this charge.

References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository.