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.

The identification of the code system that defines the meaning of the symbol in the code.

Need to be unambiguous about the source of the definition of the symbol.

The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should de-reference to some definition that establish the system clearly and unambiguously.

The version of the code system which was used when choosing this code. Note that a well-maintained code system does not need the version reported, because the meaning of codes is consistent across versions. However this cannot consistently be assured. and when the meaning is not guaranteed to be consistent, the version SHOULD be exchanged.

Where the terminology does not clearly define what string should be used to identify code system versions, the recommendation is to use the date (expressed in FHIR date format) on which that version was officially published as the version date.

A representation of the meaning of the code in the system, following the rules of the system.

Need to be able to carry a human-readable meaning of the code for readers that do not know the system.

Indicates that this coding was chosen by a user directly - i.e. off a pick list of available items (codes or displays).

This has been identified as a clinical safety criterium - that this exact system/code pair was chosen explicitly, rather than inferred by the system based on some rules or language processing.

Amongst a set of alternatives, a directly chosen code is the most appropriate starting point for new translations. There is some ambiguity about what exactly 'directly chosen' implies, and trading partner agreement may be needed to clarify the use of this element and its consequences more completely.

A human language representation of the concept as seen/selected/uttered by the user who entered the data and/or which represents the intended meaning of the user.

The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source.

Very often the text is the same as a displayName of one of the codings.

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

Links the request to the Encounter context.

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

How the value should be understood and represented - whether the actual value is greater or less than the stated value due to measurement issues; e.g. if the comparator is "<" , then the real value is < stated value.

Need a framework for handling measures where the value is <5ug/L or >400mg/L due to the limitations of measuring methodology.

This is labeled as "Is Modifier" because the comparator modifies the interpretation of the value significantly. If there is no comparator, then there is no modification of the value.

If there is no comparator, then there is no modification of the value

A human-readable form of the unit.

There are many representations for units of measure and in many contexts, particular representations are fixed and required. I.e. mcg for micrograms.

The identification of the system that provides the coded form of the unit.

Need to know the system that defines the coded form of the unit.

A computer processable form of the unit in some unit representation system.

Need a computable form of the unit that is fixed across all forms. UCUM provides this for quantities, but SNOMED CT provides many units of interest.

The preferred system is UCUM, but SNOMED CT can also be used (for customary units) or ISO 4217 for currency. The context of use may additionally require a code from a particular system.

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.

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.

Further information supporting the this charge.