Release 5 Ballot
FinancialThis page is part of the FHIR Specification (v5.0.0-ballot: R5 Ballot - see ballot notes). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions 
. Page versions: R5 R4B R4 R3
| Work Group Financial Management | Standards Status: Informative |
The Financial module covers the resources and services provided by FHIR to support the costing, contracting, financial transactions and billing which occur within a healthcare provider as well as the eligibility, enrollment, authorizations, claims, contracts and payments which occur between healthcare providers and insurers and the reporting and notification between insurers, subscribers, patients and other parties.
See also the Administration and WorkFlow modules.
Administrative
| Name | Aliases | Description |
| Account | Cost center | A financial tool for tracking value accrued for a particular purpose. In the healthcare field, used to track charges for a patient, cost centers, etc. |
| Contract | Legally enforceable, formally recorded unilateral or bilateral directive i.e., a policy or agreement. | |
| Coverage | Financial instrument which may be used to reimburse or pay for health care products and services. Includes both insurance and self-payment. | |
| CoverageEligibilityRequest | The CoverageEligibilityRequest provides patient and insurance coverage information to an insurer for them to respond, in the form of an CoverageEligibilityResponse, with information regarding whether the stated coverage is valid and in-force and optionally to provide the insurance details of the policy. | |
| CoverageEligibilityResponse | This resource provides eligibility and plan details from the processing of an CoverageEligibilityRequest resource. | |
| EnrollmentRequest | This resource provides the insurance enrollment details to the insurer regarding a specified coverage. | |
| EnrollmentResponse | This resource provides enrollment and plan details from the processing of an EnrollmentRequest resource. | |
| VisionPrescription | An authorization for the provision of glasses and/or contact lenses to a patient. |
Claims, processing and responses
| Name | Aliases | Description |
| Claim | Adjudication Request, Preauthorization Request | A provider issued list of professional services and products which have been provided, or are to be provided, to a patient which is sent to an insurer for reimbursement. |
| ClaimResponse | Remittance Advice | This resource provides the adjudication details from the processing of a Claim resource. |
Used to support service payment processing and reporting
| Name | Aliases | Description |
| PaymentNotice | This resource provides the status of the payment for goods and services rendered, and the request and response resource references. | |
| PaymentReconciliation | This resource provides the details including amount of a payment and allocates the payment items being paid. |
Patient reporting and other purposes
| Name | Aliases | Description |
| ExplanationOfBenefit | EOB | This resource provides: the claim details; adjudication details from the processing of a Claim; and optionally account balance information, for informing the subscriber of the benefits provided. |
Additional Resources will be added in the future. A list of hypothesized resources can be found on the
HL7 Confluence . Feel free to add any you think are missing or engage with one
of the HL7 Work Groups to submit a
proposal to define a resource of particular interest.
Financial information in general and in particular when related to or including health information, such as claims data, are typically considered Protected Health Information and as such must be afforded the same protection and safeguards as would be afforded to purely clinical identified health data.
The Security and Privacy measures associated with FHIR, such as the use of Security labels and tags in the resource.meta, are encouraged in addition to the use of whatever measures for authorization and encryption are supported by the chosen exchange model, e.g. FHIR REST, Web Services, Direct, MLLP, SMTP and others.
For more general considerations, see the Security and Privacy module.
Financial information in general and in particular when related to or including health information, such as claims data, are typically considered Protected Health Information and as such must be afforded the same protection and safeguards as would be afforded to purely clinical identified health data.
| Term | Alias | Resource Type | Description |
| Adjudication | Claim, Preauthorization or Predetermination Processing | ClaimResponse | The processing by an insurer of a claim, preauthorization or predetermination to determine under the insurance plan what if any benefits are or would be payable. |
| Assignment of Benefit | Assignment | n/a | When a Beneficiary directs that any benefits they receive from the adjudication of a claim may be paid to the service provider who issued the claim. |
| Attachment | Communication | A collection of information objects sent to a party to support their understanding or processing of another resource such as a claim. | |
| Beneficiary | Patient | Patient | The party whose health care expenses may be covered by a policy issued by an Insurer. |
| Benefit Amount | Benefit | n/a | The amount payable under an insurance policy for a given expense incurred by a patient. |
| Claim | Claim | Claim | A request to an Insurer to adjudicate the supplied charges for health care goods and services under the identified policy and to pay the determined Benefit amount, if any. |
| Coordination of Benefit | COB | n/a | The rules, usually regionally defined, which govern the order of application of multiple Insurance coverages or Self-Pay to a given suite of health care expenses. |
| Dependent | Patient, RelatedPerson | A person who receives their coverage via a policy which is own or subscribed to by another. Typically, these include spouses, partners and minor children but may also include students, parents and disabled persons. | |
| Insurer | Payer, Payor | Organization | The term ”payer” as used in the transactions is defined as the intended entity that is responsible for one or more of the following:
|
| Network | n/a | An insurer defined grouping of Providers for which the Beneficiary's plan preferentially covers the costs of treatment, e.g. closed, rental, etc. | |
| Payer | Payor, Insurer | Organization | A public or private insurer. |
| Payor | Payer, Insurer | Organization | A public or private insurer. |
| Policy | Contract | A contract between an Insurer and an individual or other entity such as an employer to reimburse covered parties (Beneficiaries) for some or all of a prescribed suite of health-related goods and services. | |
| Policy Holder | Policy owner | Patient, RelatedPerson, Organization | The party which owns the policy. It may be the employer for work-related policies or the individual for purchased or public policies. |
| Preauthorization | Prior Authorization, Pre-Auth | Claim | A request to an Insurer to adjudicate the supplied proposed future charges for health care goods and services under the identified policy and to approve the services and provide the expected benefit amounts and potentially to reserve funds to pay the benefits when Claims for the indicated services are later submitted. |
| Predetermination | Pre-Determination, PreD | Claim | A request to an Insurer to adjudicate the supplied 'what if' charges for health care goods and services under the identified policy and report back what the Benefit payable would be had the services actually been provided. |
| Solicited Attachment | Communication | An attachment sent to provide supporting information in response to having received a request for additional information. | |
| Subscriber | Patient, RelatedPerson | The person who signs-up for the coverage. May be an employee or person with dependents. | |
| Unsolicited Attachment | Communication | An attachment sent to provide supporting information without first having received a request for additional information. |
The table below details various common business activities which occur in the financial realm, and the focal resources which may be exchanged, along with supporting resources, to accomplish the business activities. Whether the resources specified are actually needed requires consideration of the business itself and the exchange methodology and transport being used.
For example: If a content model is not required to obtain the appropriate status element then a SEARCH (GET) may be used, however if a content model is required to support the request for information then the content model will need to be CREATEd (POST). Alternately, if FHIR Operations are being used then the specified focal resource may be employed as one of the Operation parameters or might not be required.
| Business Activity | Request Resource | Response Resource |
| Eligibility Check | CoverageEligibilityRequest | CoverageEligibilityResponse |
| Enrollment Update | EnrollmentRequest | EnrollmentResponse |
| Claim | Claim (type={discipline}, use=claim) | ClaimResponse |
| Claim with attachments | Bundle containing Claim and the attachments | ClaimResponse |
| Predetermination | Claim (type={discipline}, use=predetermination) | ClaimResponse |
| Preauthorization | Claim (type={discipline}, use=preauthorization) | ClaimResponse |
| ReversalCancel | Task (code=cancel) | Task (optional output=ClaimResponse) |
| NullifyNullify | Task (code=nullify) | Task (output=error codes) |
| ReleaseRelease | Task (code=release) | Task (output=error codes) |
| Re-adjudicationReprocess | Task (code=reprocess) | Task (output=ClaimResponse) |
| Status CheckStatus | Task (code=status) | Task (output=status code) |
| Pended Check (Polling)Poll | Task (code=poll) | Task (output={Resource}) |
| Payment Notice | Task (code=deliver, input=PaymentNotice) | Task (output=error codes) |
| Payment Reconciliation | Task (code=poll, input=PaymentReconciliation) | Task (output=PaymentReconciliation) |
| Send Attachments | Task (code=deliver, input=Communication) | Task (output=error codes) |
| Request Attachments | Task (code=poll, input=CommunicationRequest) | Task (output=CommunicationRequest) |
| Request an Explanation of Benefits | Task (code=poll, input=ExplanationOfBenefit) | Task (output=ExplanationOfBenefit) |
{discipline} means the type of claim: OralHealth, Vision, Pharmacy, Professional or Institutional.
{Resource} means any pended or undelivered resource subject to the selection details specified in the request.
See the Financial examples in Task.
In addition to supplying a reference to a focal resource in the .focus element, where appropriate an .input element of type 'origresponse' may also be provided with a reference to the resource which was the original response to the focal resource.
The Cancel is the formal request to cease processing an incomplete prior request or to reverse a completed prior request or information submission. A copy of the original request may be retained. The Task will be updated to indicate whether the requested action was accepted and successful or whether errors were found in the request and may contain a reference to the ClaimResponse or such other resource as may be appropriate for expressing the outcome of the cancellation.
The Nullify is the formal request to cease processing an incomplete prior request or to reverse a completed prior request or information submission. All copies of the original submission are to be purged, although audit logs may be retained. The Task will be updated to indicate whether the requested action was accepted and successful or whether errors were found in the request.
Poll provides supporting information for the poll request. The response to a Poll is a Task referring to: a previously undelivered response Resource; a Bundle containing one or more Resources; or, a Task which may contain errors.
A simple Poll request, one which doesn't specify additional .input parameters: origresponse, include, exclude, period or count; would return any single pended resource. Specific types of business behaviors may be supported by providing values for the filtering elements in the .input element, for example:
Upon processing of the request, the Task or Bundle may contain errors or a reference to the resource(s) found.
Release is the formal request for the release of any allocation or reserved resources such as funds or products reserved, for example on a preauthorization, which have not been consumed, e.g. as indicated on claims, and which are no longer required. The preauthorization which request ed the reservation will be identified in the .focus element and the insurer's response confirming the reservation may be provided as a .input element.
Reprocess indicates the resource which is to be reprocessed in the .focus element, for example a claim to be re-adjudicated or a specimen or diagnostic image to be re-examined, and provides both supporting information for the reprocessing and the line items which are to be reprocessed in the .input element.
This is necessary for the limited supporters who require the ability to formally request the reprocessing of specified service sub-trees from an already processed resource such as a previously adjudicated Claim. Upon processing of the request the Task may contain errors or a reference to the ClaimResponse or such other resource as may be appropriate for expressing the outcome of the reprocessing.
Status indicates the resource for which the processing status is requested in the .focus element and provides any supporting information for the status request. The
This is a formal request for systems which require requisition-level information or transports which don't support a 'Get Operation', for the processing status of a previously submitted processing request.
Upon processing of the status request the Task may contain errors or a .output parameter of 'status' containing the status of outcome code of the processing of the targeted resource.
The table below details the relative order of events and use of financial resources for patient care during the care cycle. Not all steps or information exchanges may occur. Supporting information may be required more frequently than has been depicted below.
| Business Activity | Focal Resource |
| Patient visits Provider | |
| Provider checks for valid insurance coverage | CoverageEligibilityRequest |
| Insurer responds with coverage status and optional plan details | CoverageEligibilityResponse |
| Provider examines Patient and reviews treatment options | |
| Provider submits Predetermination(s) for treatment options to determine potential reimbursement | Claim {use=predetermination} |
| Insurer responds with potential reimbursement | ClaimResponse |
| Provider and Patient determine treatment plan | |
| Treatment plan submitted to Insurer to reserve funds | Claim {use=preauthorization} |
| Insurer acknowledges receipt of preauthorization | ClaimResponse |
| Insurer requests additional information | CommunicationRequest |
| Provider submits supporting information | Communication |
| Insurer provides adjudicated response to pre-authorization | ClaimResponse |
| Provider checks on status of pre-authorization processing | Task {code=status} |
| Insurer responds indicating adjudication is ready | Task |
| Provider retrieves pre-authorization adjudication | READ or Task {code=poll} |
| Provider provides treatment | |
| Provider submits patient's claim for reimbursement | Claim {use=claim} |
| Insurer responds with claim adjudication | ClaimResponse |
| Patient leaves treatment setting | |
| Patient requests an Explanation of Benefit for their Personal Health Record application | READ or Task {code=poll} |
| Insurer responds with Explanation of Benefit | ExplanationOfBenefit |
| Provider requests the payment details associated with a bulk payment | SEARCH or Task {code=poll} |
| Insurer responds with a Payment Reconciliation | PaymentReconciliation |
| Insurer notifies provider that payment has been issued | PaymentNotice |
| Insurer notifies parties that payment funds have been received | PaymentNotice |
Financial resources, such as claim and eligibility resources, begin with the status 'draft' and continue with this status during the development of the resource. When a resource is exchanged with an external party, for example when a provider claim is sent or otherwise created on the insurer's system before the exchange the status of the claim shall be changed to 'active'. A resource with the 'active' status is immutable and cannot be edited except for further change to the status in the event the resource is subsequently canceled resulting in a status of 'cancel'.
In the event that a resource is determined to have been entered in error, for example a wrong date of service or billing code, while the status is 'draft' then the status may be changed to 'entered-in-error' and no further editing of the resource is permitted. If the resource status is 'active' when the error is noted, then the resource must be canceled and further interaction with whatever parties have been supplied the resource may be required to halt any processing or reverse any effects of the resource prior to creating an amended instance.
In addition to their primary use of conveying patient billing information to insurers for reimbursement either to the subscriber or the provider ( assignment of benefit), many of the financial resources, such as Claim and ExplanationOfBenefit, may be used to export data to other agencies to support reporting and analytics. Consequently the cardinalities of many elements are set to optional, '0..', to support reporting, for example of partial adjudications, where the cardinality for a normal claim profile or claim response profile would expect the cardinality to required, '1..'.
Profiles will usually be necessary to set tight constraints on cardinalities, require jurisdictional terminologies, and eliminate or introduce elements require to support various business needs and discipline requirements.
There is often a need to provide supporting information, commonly referred to as attachments, to document the need for a service and/or to confirm that the good or service was authorized or rendered. This information may be in many forms, including: scanned documents, PDFs, word processing files, X-Rays, images, CDAs and FHIR Resources.
Supporting information may be provided, as a reference or the actual material, to support the Claim (complete claim or Preauthorization) or ExplanationOfBenefit in a variety of manners:
It is not always appropriate to send a Claim, or other eClaim requests such as eligibility or pre-authorizations, to some insurers. This may be due to jurisdictional rules, for example the national health program may pay for workplace accident claims then recover costs directly against that program, or there may be no direct relationship between the provider and the insurer, for example for injury caused by another party or covered under property or accident insurance, the patient's primary health insurer may pay for services then recover a portion of their costs from that other insurer.
To support the downstream recovery of costs from the appropriate insurer it is necessary to supply the insurance coverage information for all logically potentially applicable coverages and to flag those which are provided for subrogation so that both the provider and payor systems know whether to expect to submit eClaims requests to or expect eClaims responses from these insurers. In the specific case of the Claim resource (claim, predetermination, preauthorization) the provider would list all insurance coverages, including only work or accident related if appropriate, but send Claims only to non-subrogation coverages (Coverage.subrogation=false) and not include ClaimResponses, nor would payors expect ClaimResponses to be provided, for subrogated coverages.
When a patient has multiple Coverages there will generally be agreement within the jurisdiction as to the order of application of claims recovery against the coverages which is referred to as the Coordination of Benefit (COB) order. This would also be the order used to request preauthorization and predeterminations. Coverage eligibility is typically independent of the COB order as it is coverage specific.
While the jurisdiction rules must be consulted for COB specifics, generally: risk specific polices apply before risk-general policies; national policies will apply before personal or top-up policies; coverage obtained with full-time employment applies before coverage obtained with part-time employment; policies where the patient is the subscriber apply before a spouse's policy; and, there will be some understanding as to the order of application for policies which apply to dependents, for example, birthday order of the subscribers.
When sending Claims down the COB order all logically applicable policies will be listed, so that insurers may confirm adherence to the COB order, and, aside from subrogated coverages, will include the ClaimResponses from any coverages appearing earlier in the COB order so that each insurer may correctly calculate their portion of the overall cost of products and services supplied. The claims work their way through the COB order until the order is exhausted or there is no further outstanding balance, whichever comes first.
While it is most common, it is not always the case that all claims originate with the provider. In some jurisdictions, in some or all cases, the primary health insurer takes or is assigned responsibility to obtain the ClaimResponses from downstream insurers and to return the suite of ClaimResponses to the provider. This is similar to subrogation in that it removes the claim-cycle work from the provider but unlike subrogation the individual insurers still make their payments to the provider, if Assignment of Benefit is agreed, and a reversal of the base claim often requires the provider to handle reversal of the downstream claims as well.
eClaims request and response resources may be exchanged between providers and payors individually or via batches. eClaim requests, individual and batches, may be created on a payor system via FHIR REST or sent to the payor, either synchronously via FHIR operations or another request-response protocol such as: WSI Web Services, a SOA exchange, MLLP, etc.
An individual eClaim request or response, for example a Claim (use=claim), may be either a simple Claim resource which refers to or contains any supporting resources or Bundle resource containing a single request, e.g. a Claim, and any associated resources (Patient, Practitioner, Organization, Coverage, etc.).
A batch of eClaim requests or responses is a (FHIR Bundle) containing one or more eClaim requests or responses, as above. The batch is simply a 'bag' of request or responses, typically of a consistent type of request or response, for example: all eligibility, preauthorizations, claim, payment notifications, etc. There is no assurance provided that when receiving a batch of 100 claim responses that they relate to the 100 claims just submitted.
The eClaims resources are intended to support the real-time exchange of eClaim request and responses. While certain eligibility, claims, preauthorizations and predeterminations may be processed in real-time there are many cases where they cannot due to the complexity of the material submitted, the maturity of the jurisdictional styles and insurer processing systems, and the inclusion or requirements for supporting information which tends to require manual review. Therefore, in some cases the eClaim response will only indicate the receipt and typically validation that the request is processable (or that it contain errors which inhibit processing).
Deferred responses, those which could not be returned in real-time, and those returned asynchronously may be obtained either by FHIR REST (a GET or SEARCH) or via a Poll depending upon the style of information exchange supported.
While most current eClaim data models current only support a single tier structure for line items, that is there is only a list of 'n' line items to support exchanging multiple services where complex relations between line items are expressed through business rules such as 'put the professional fee line item before the lab/device/service line item', the FHIR claim-related resources (Claim, ClaimResponse and ExplanationOfBenefit) all support a 3-tier structure, as illustrated in the diagram below. The tiers are:
The base FHIR specification provides for an unlimited numer of .items and within each .item and unlimited number or .details, and similarly and unlimited number of .subDetails within each .detail. It is up to the implementation guides and profiles to determine when .details and .subDetails are permitted and the allowable numbers of .items, .details and .subDetails.
For jurisdictions where tax is billed as a separate line item, through a billing code or category, there is no additional structural information required. The handling of Tax should be detailed in the jurisdictional implementation guide and jurisdictional profiles should remove unnecessary tax-related elements. Therefore: .net=.quantity * .unitPrice * .factor. Also the jurisdictional implementation guide should clarify whether line items are inclusive or exclusive of tax.
For jurisdictions where tax is applied per line item/detail/sub-detail etc. a single tax element shall be added to the respective strictures for .item, ,item.detail, .item.detail.subdetail and similarly in the addItem structure of the Claim, ClaimResponse and ExplanationOfBenefit resources. The Tax element contains the total of any taxes and extensions may be used to breakdown the Tax should that be required. Therefore: .net= (.quantity * .unitPrice * .factor) + .tax. The total tax may be reflected in the resource.total structure if appropriate.
The Financial Management Work Group (FM) is responsible for two subdomains:
Financial Accounts and Billing (FIAB) - resources for accounts, charges (internal costing transactions) and patient billing, and
Financial Claims and Reimbursement (FICR) - insurance information, enrollment, eligibility, predetermination, preauthorization, claims, patient reporting and payments.
To date FM has been focusing on the resources required to support the exchange of claims and related information between health care providers and insurers. The first draft of this work is nearing completion with the release of the first Financial Standard for Trial Use in STU4 of FHIR. Over the next year further refinements will be expected as implementers begin developing regional profiles and begin live pilots with resources.
Once the above is well underway FM can then look to developing the Enrollment-related resources and the resources to support the FIAB functions.
In many cases an example valueset has been provided in this release. Financial Management will be devoting effort in the preparation to Release 5 of FHIR to develop more representative example sets and to determine where global codesets exist such that some of the valuesets may be elevated in strength to extensible or required.
FHIR ®© HL7.org 2011+. FHIR R5 Ballot hl7.fhir.core#5.0.0-ballot generated on Sat, Sep 10, 2022 05:07+1000.
Links: Search |
Version History |
Contents |
Glossary |
QA |
Compare to R4B |
Compare to R5 Draft |
|
Propose a change