Financial
This
page
is
part
of
the
FHIR
Specification
(v3.0.2:
(v4.0.1:
R4
-
Mixed
Normative
and
STU
3).
)
in
it's
permanent
home
(it
will
always
be
available
at
this
URL).
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
R4
R3
|
Work
Group
Financial
Management
|
|
The Financial module covers the resources and services provided by FHIR to support the costing, financial transactions and billing which occur within a healthcare provider as well as the eligibility, enrollment, authorizations, claims and payments which occur between healthcare providers and insurers and the reporting and notification between insurers and subscribers and patients.
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. | |
|
|
The
|
|
|
|
This
resource
provides
eligibility
and
plan
details
from
the
processing
of
an
|
|
| 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
|
|
| 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
|
| 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
|
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
wiki
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,
is
encouraged
as
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 | A public or private insurer which will adjudicate Claims for health care goods and services to determine if the there is any benefit payable, amount due, under the policy which covers the patient. |
| 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
may
might
not
be
required.
| Business Activity | Request Resource | Response Resource |
| Eligibility Check |
|
|
| Enrollment Update | EnrollmentRequest | EnrollmentResponse |
| Claim |
Claim
(type={discipline},
|
ClaimResponse |
|
|
Bundle
containing
Claim
|
ClaimResponse |
|
|
Claim
(type={discipline},
|
ClaimResponse |
|
|
|
ClaimResponse |
|
|
|
Task (optional output= ClaimResponse ) |
| Nullify Nullify | Task (code=nullify) | Task (output=error codes) |
| Release Release | Task (code=release) | Task (output=error codes) |
| Re-adjudication Reprocess |
|
Task (output= ClaimResponse ) |
| Status Check Status |
|
|
| Pended Check (Polling) Poll |
|
Task
(output=
{Resource}
|
| Payment Notice | Task (code=deliver, input= PaymentNotice ) |
|
| Payment Reconciliation |
|
Task (output= PaymentReconciliation ) |
| Send Attachments | Task (code=deliver, input= Communication ) |
|
| Request Attachments |
|
Task (output= CommunicationRequest ) |
| Request an Explanation of Benefits |
|
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,
and
supporting
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 |
|
| Insurer responds with coverage status and optional plan details |
|
| Provider examines Patient and reviews treatment options | |
|
Provider
submits
|
Claim
|
| Insurer responds with potential reimbursement | ClaimResponse |
| Provider and Patient determine treatment plan | |
| Treatment plan submitted to Insurer to reserve funds |
Claim
|
|
Insurer
acknowledges
receipt
of
|
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 |
|
| Insurer responds indicating adjudication is ready |
|
| Provider retrieves pre-authorization adjudication |
READ
or
|
| Provider provides treatment | |
| Provider submits patient's claim for reimbursement |
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
|
| Insurer responds with Explanation of Benefit | ExplanationOfBenefit |
| Provider requests the payment details associated with a bulk payment |
SEARCH
or
|
| 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
(
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,
XRays,
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
Pre-Authorization)
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.
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,
pre-authorization,
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
healthcare
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
STU3
STU4
of
FHIR.
Over
the
next
year
further
refinements
will
be
expected
as
we
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.
Financal
Financial
Management
will
be
devoting
effort
in
the
preparation
to
Release
4
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.
®©
HL7.org
2011+.
FHIR
Release
3
(STU;
v3.0.2-11200)
4
(Technical
Correction
#1)
(v4.0.1)
generated
on
Thurs,
Oct
24,
Fri,
Nov
1,
2019
11:53+1100.
09:37+1100.
QA
Page
Links:
Search
|
Version
History
|
Table
of
Contents
|
Credits
|
Compare
to
DSTU2
R3
|
|
Propose
a
change