This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Invoice FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
(migrate to Confluence)
 
(16 intermediate revisions by 2 users not shown)
Line 1: Line 1:
  
 
<div class="messagebox cleanup metadata">
 
<div class="messagebox cleanup metadata">
<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div>
+
Current version: https://confluence.hl7.org/display/FHIR/Invoice+FHIR+Resource+Proposal<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div>
 
<div style="background:#F0F0F0">
 
<div style="background:#F0F0F0">
 
This page documents a [[:category:Pending FHIR Resource Proposal|Pending]] [[:category:FHIR Resource Proposal|FHIR Resource Proposal]]
 
This page documents a [[:category:Pending FHIR Resource Proposal|Pending]] [[:category:FHIR Resource Proposal|FHIR Resource Proposal]]
Line 31: Line 31:
  
 
==Committee Approval Date:==
 
==Committee Approval Date:==
<!-- FM has on hold  -->
+
FM Approval (17 Jan 2019 Paul Knapp/Brian Postlethwaite 10-0-0)
 +
PA Approval (4 April 2018 Brian Postlethwaite/Simone Heckmann 3-0-0)
  
 
==Contributing or Reviewing Work Groups==
 
==Contributing or Reviewing Work Groups==
Line 43: Line 44:
  
 
==Scope of coverage==
 
==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.
+
In cases where the provider bills another party directly for products and/or services, an Invoice is used.
It neither references ChargeItems nor Accounts
+
An invoice is a financial instrument issued by a Healthcare provider to a patient or other party indicating the goods and services performed with their quantities and prices.
 
 
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.
 
  
 +
The Claim resource is constricted to use cases where a request for reimbursement is sent on behalf of the insured to an insurance for reimbursement under a specified policy.
  
 +
An Invoice can use ChargeItems in an Account to provide the details to support the creation of an Invoice.
  
 
==RIM scope==
 
==RIM scope==
 
+
FinancialTransaction[MoodCode=RQO]
-none-
 
<!-- Identify the formal RIM mapping for the root concept of the resource.  The expectation is that the RIM mapping will be sufficiently precise so as to not overlap with any other resource definition. -->
 
  
 
==Resource appropriateness==
 
==Resource appropriateness==
  
<!-- Does the resource meet the following characteristics?
+
Tracking Financial information is vital in Patient Administration and Finance systems in most Healthcare Organizations. This resource provides the details of the invoice, and which items are allocated to it.
  
Must
+
Competing invoicing standards such as EDIFACT or X12 are aiming at inter-organisational exchange and do not offer traceable links in FHIR to the services rendered.
* Represents a well understood, "important" concept in the business of healthcare
 
* Represents a concept expected to be tracked with distinct, reliable, unique ids
 
* Reasonable for the resource to be independently created, queried and maintained
 
 
 
Should
 
* Declared interest in need for standardization of data exchange</span>
 
* Resource is expected to contain an appropriate number of "core" (non-extension) data elements (in most cases, somewhere in the range of 20-50)
 
* Have the characteristics of high cohesion & low coupling – need to explore whether coupling is good some places, not elsewhere – layers from Bo’s document
 
-->
 
 
 
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==
 
==Expected implementations==
  
 
<!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. -->
 
<!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. -->
* Any solution that tracks billing information and needs to issue invoices
+
*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
+
*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
+
*A Patient facing application that handles healthcare invoice information, such as costs, amounts and reasons of the charged costs for the healthcare services a patient received
* Interested parties: SAP, IBM, Association of Private Insurers in Germany
+
*Interested implementing organizations: SAP, IBM, Association of Private Insurers in Germany
 +
*more interested parties: https://chat.fhir.org/#narrow/stream/4-implementers/topic/Invoices
  
 
==Content sources==
 
==Content sources==
Line 107: Line 89:
  
 
Are there any source specifications that you wish to consult but are concerned about access to or expertise to consider? -->
 
Are there any source specifications that you wish to consult but are concerned about access to or expertise to consider? -->
Existing normative V3 and V2 specifications
+
Content for the resource has considered the existing normative V3 and V2 specifications and other knowledge of invoicing in general
  
 
==Example Scenarios==
 
==Example Scenarios==
Line 113: Line 95:
 
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this resource.  They should demonstrate the full scope of the resource and allow exercising of the resources capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) -->
 
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this resource.  They should demonstrate the full scope of the resource and allow exercising of the resources capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) -->
  
* Invoicing between systems that primarily interact using FHIR API
+
*Invoicing between systems that primarily interact using FHIR API
 +
 
 +
*Patient Apps
  
* 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.  
 
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.
 
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 provider created and processed FHIR based invoices may be mapped to other standards such as X12 for posting in external systems.
 
 
These internally created and processed FHIR based invoices may be mapped to other standards such as X12 for posting in external systems.
 
  
 
==Resource Relationships==
 
==Resource Relationships==
Line 134: Line 115:
 
Reference to resources is really only relevant at the "same or higher level" (Bo – fix this wording)
 
Reference to resources is really only relevant at the "same or higher level" (Bo – fix this wording)
 
  -->
 
  -->
* Reference to Account (account)
+
*Reference to Account (account)
* Reference to ChargeItems (items)
+
*Reference to ChargeItems (items)
* Reference to Encounter/EpisodeOfCare (via Account) (context)
+
*Reference to Encounter/EpisodeOfCare (via Account) (context)
* Reference to Patient|Group (subject)
+
*Reference to Patient|Group (subject)
* Reference to any type of Request/Referal (basedOn) (via Account)
+
*Reference to any type of Request/Referal (basedOn) (via Account)
* Reference to any type of Event (service)
+
*Reference to any type of Event (service)
* Payor (Organization|Patient|RelatedPerson)
+
*Payor (Organization|Patient|RelatedPerson)
  
 
Referenced by:
 
Referenced by:
* Claim
+
 
 +
*Claim
  
  
Line 149: Line 131:
  
 
<!-- Indicate the target date for having the resource complete from a committee perspective and ready for vetting and voting -->
 
<!-- Indicate the target date for having the resource complete from a committee perspective and ready for vetting and voting -->
The aim is to have a draft (Maturity 0) ready for 4.0 timeline.
+
A draft is included in R4.
  
 
==gForge Users==
 
==gForge Users==
Line 156: Line 138:
 
brianpos
 
brianpos
 
simoneheckmann
 
simoneheckmann
 +
paulknapp
  
 
==When Resource Proposal Is Complete==
 
==When Resource Proposal Is Complete==
 
'''When you have completed your proposal, please send an email to [mailto:FMGcontact@HL7.org FMGcontact@HL7.org]'''
 
'''When you have completed your proposal, please send an email to [mailto:FMGcontact@HL7.org FMGcontact@HL7.org]'''

Latest revision as of 15:08, 31 October 2019



Invoice

Owning committee name

Financial Management

Committee Approval Date:

FM Approval (17 Jan 2019 Paul Knapp/Brian Postlethwaite 10-0-0) PA Approval (4 April 2018 Brian Postlethwaite/Simone Heckmann 3-0-0)

Contributing or Reviewing Work Groups

Patient Administration


FHIR Resource Development Project Insight ID

pending

Scope of coverage

In cases where the provider bills another party directly for products and/or services, an Invoice is used. An invoice is a financial instrument issued by a Healthcare provider to a patient or other party indicating the goods and services performed with their quantities and prices.

The Claim resource is constricted to use cases where a request for reimbursement is sent on behalf of the insured to an insurance for reimbursement under a specified policy.

An Invoice can use ChargeItems in an Account to provide the details to support the creation of an Invoice.

RIM scope

FinancialTransaction[MoodCode=RQO]

Resource appropriateness

Tracking Financial information is vital in Patient Administration and Finance systems in most Healthcare Organizations. This resource provides the details of the invoice, and which items are allocated to it.

Competing invoicing standards such as EDIFACT or X12 are aiming at inter-organisational exchange and do not offer traceable links in FHIR to the services rendered.

Expected implementations

  • Any solution that tracks billing information and needs to issue invoices
  • Providers who want to deliver structured information to patients to increase cost transparency
  • A Patient facing application that handles healthcare invoice information, such as costs, amounts and reasons of the charged costs for the healthcare services a patient received
  • Interested implementing organizations: SAP, IBM, Association of Private Insurers in Germany
  • more interested parties: https://chat.fhir.org/#narrow/stream/4-implementers/topic/Invoices

Content sources

Content for the resource has considered the existing normative V3 and V2 specifications and other knowledge of invoicing in general

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.

These internally provider 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


Timelines

A draft is included in R4.

gForge Users

brianpos simoneheckmann paulknapp

When Resource Proposal Is Complete

When you have completed your proposal, please send an email to FMGcontact@HL7.org