This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "Invoice FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
Line 32: Line 32:
==Committee Approval Date:==
==Committee Approval Date:==
<!-- FM has on hold  -->
<!-- FM has on hold  -->
PA Approval (Brian Postlethwaite/Simone Heckmann 3-0-0)
==Contributing or Reviewing Work Groups==
==Contributing or Reviewing Work Groups==

Revision as of 19:27, 4 April 2018


Owning committee name

Financial Management

Committee Approval Date:

PA Approval (Brian Postlethwaite/Simone Heckmann 3-0-0)

Contributing or Reviewing Work Groups

Patient Administration

FHIR Resource Development Project Insight ID


Scope of coverage

The existing Claim resource is constricted to use cases where Claims are sent to insurances for reimbursement, in a message-like style. It neither references ChargeItems nor Accounts

It doesn't not cover use cases where existing ChargeItems in an Account are used to create an Invoice to be sent out to Individuals or Organizations in a document-style.

Unlike the Claim resource it reflect the perspective of the (healthcare) service providing organization.

An invoice is a financial document issued by a Healthcare provider to a patient or a payer indicating the goods and services (ChargeItems) performed with their quantities and prices. The invoice is the hospital’s view, whereas the Claim is the payer’s view on the performed services.

RIM scope


Resource appropriateness

Tracking Financial information is vital in Patient Administration and Finance systems in most Healthcare Organizations. This resource provides the individual items to track.

Competing invoicing standards such as EDIFACT or X12 are aiming at inter-organisational exchange and do not offer human readable representations or traceable links to services rendered which is a requirement for invoicing towards patients.

Expected implementations

  • Any solution that tracks billing information and needs to issue invoices
  • Private Insurance Providers who want to deliver structured information to patients to increase cost transparency
  • Patient apps that want to include information on the amount and reason of the charged costs for the healthcare services a patient received
  • Interested parties: SAP, IBM, Association of Private Insurers in Germany

Content sources

Existing normative V3 and V2 specifications

Example Scenarios

  • Invoicing between systems that primarily interact using FHIR API
  • Patient Apps

Patient apps may chose to not only give patients access to their health data but also to the charges assoicated with them (e.g. provide insight into the cost for medications, treatments and immunizations). Such apps will require structured invoices to allow association between the charges and the services rendered.

Apps can provide abilities to trace and compare costs or deliver additional information as to the meaning of specific billing codes.

It is convenient for both patientes and implementers to be able to exchange billing information through the same app based on the same standard as other information a patiant may want to take home from a doctor's visit or an inpatient tratment such as medication plans or lab results.

These internally created and processed FHIR based invoices may be mapped to other standards such as X12 for posting in external systems.

Resource Relationships

  • Reference to Account (account)
  • Reference to ChargeItems (items)
  • Reference to Encounter/EpisodeOfCare (via Account) (context)
  • Reference to Patient|Group (subject)
  • Reference to any type of Request/Referal (basedOn) (via Account)
  • Reference to any type of Event (service)
  • Payor (Organization|Patient|RelatedPerson)

Referenced by:

  • Claim


The aim is to have a draft (Maturity 0) ready for 4.0 timeline.

gForge Users

brianpos simoneheckmann

When Resource Proposal Is Complete

When you have completed your proposal, please send an email to