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 (external) source of pricing information, rules of application for the code this ChargeItem uses.

see http://en.wikipedia.org/wiki/Uniform_resource_identifier

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

see Canonical References

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 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. This property indicates which Organization requested the services to be 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 an 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 bodySite. May be a summary code, or a reference to a very precise definition of the location, or both.

Codes describing anatomical locations. May include laterality.

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

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

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 choose 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 the person considered responsible for factor/price overrides 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.

Example binding for reason.

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 might not always be able to determine, which accounts the Items need to be places into. It is up to the postprocessing 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 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.