![]() ANSI/HL7 V3 AB, R2-2008 (R2012) HL7 Version 3 Standard: Accounting and Billing, Release 2 03/06/2008 (reaffirmed 6/5/2012) |
Content Last Edited: 2008-06-04T13:47:15
|
||||||
|
For details on the interpretation of this section, see the storyboard discussion in the Version 3 Guide.
This domain area covers the basic interactions needed to manage patient billing accounts.
A Billing Account is an accumulator of financial and administrative information for the main purpose of supporting claims and reimbursement. Secondarily, the billing account may contribute significant information to cost accounting and financial decision support systems. A billing account is simply that entity that captures the elements reflecting the cost and price of services provided and supplies consumed for a healthcare activity. The focus for which an account accumulates information will vary. (For example: In a realm where billing is based on periodically collecting financial transactions for a patient, the accumulator might be the patient.) A billing account might also include links to insurance and benefit information, and relevant responsible parties.
Create Patient Billing Account Notification | ![]() |
Update Patient Billing Account Notification | ![]() |
Delete Patient Billing Account Notification | ![]() |
Merge Patient Billing Account Notification | ![]() |
Close Patient Billing Account Notification | ![]() |
Patient account close
Ms Smith's account for a previous visit is at a zero balance and has not had any activity for some specified period of time. The account is closed, declared inactive and not available for further activity, prepatory to archiving and/or removal from the administrative system.
Patient account create
Ms. Adams, the admitting clerk, needs to create an account for patient Sam Smith as a result of his admission. She collects and enters the relevant information from him into the hospital administrative system, which then creates a patient account that may be used subsequently to collect charges and credits to support financial transactions, including billing specific to this hospital stay.
Patient account delete
A patient account was created for Ms. Sally Simth as a result of pre-admit processing for cosmetic surgery. Ms. Smith subsequently changed her mind and did not proceed with the surgery. Consequently the patient account must be deleted
Patient account merge
Ms. Smith was admitted to the hospital, with the subsequent creation of a patient account, within 72 hours of discharge from a previous stay. The diagnosis reveals that her admission is the result of a condition or conditions arising from her previous stay. It is necessary to merge the account created for this visit with the patient's previous visit account as this stay represents a continuation of the previous encounter for both care and financial transaction purposes, including billing. Note that once charges for an encounter have been posted to an account, that account can no longer be merged to an account created for a continuation of that encounter.
Patient account unmerge
Ms. Smith has been admitted to the hospital twelve hours after her discharge from elective surgery. Noting the previous visit the clerk arbitrarily merges the new patient account with the patient's previous visit account. Subsequent diagnosis reveals a condition unrelated to the previous stay necessitating a reversal of the patient account merge; i.e., the need to reestablish the account specific to this encounter. No message types have been developed for this storyboard.
Patient account update
As a result of pre-admit processing a patient account was created for Ms. Sally Smith. During the process of her admission, the admitting clerk verified the information on file and collected and entered additional patient account data resulting in an update of the patient account.
|
||||||||
|
For details on the interpretation of this section, see the discussion of application roles and their relationships in the Version 3 Guide.
|
||||||||||||||
|
For details on the interpretation of this section, see the discussion of trigger events in the Version 3 Guide.
Type: |
This trigger event signals that a financial transaction is posted to the patient billing account for billable service charges; payment made for the portion of the charges that are the patient's responsibility; or a payment by an alternative guarantor, e.g. Workers' Insurance payor. The charge or reversal can be triggered from different systems once the account is already established in the billing system. A) Hospital Information systems generate charge or reversal triggered at various instances of a clinical workflow based on different status. For example Charge on Order, Charge on Charting, Charge on Result, Charge on Assessment. The Status can be active, Complete, etc. B) Hospital Information Systems can generate charge or reversal, which are manually posted. These are material, supply or miscellaneous that could not be generated in a workflow and need to be captured manually. C) Departmental Systems like Oncology, Cardiology etc. can post charges or reversals, which are directly sent to the billing system, or may be routed via the Hospital Information system. D) Ancillary Systems like Laboratory and Radiology can post charges or reversals, which are directly sent to the billing system, or may be routed via the Hospital Information system. E) The Master ADT system may generate charges or reversals to be sent to the billing system, once a patient account has been established. V2 Reference: The Post financial transaction most closely aligned with the HL7 2.4 DFT^P03-Post Detail Financial Transaction and HL7 2.5 DFT^P11 - Post Detail Financial Transactions - Expanded.
Type: |
This trigger event signals that a patient billing account was Update on the financial system. V2 Reference: Update Patient Billing Account is most closely aligned with the HL7 2.4 to BAR^P05 Update Account (used for inpatient coding), BAR^P10 - Transmit Ambulatory Payment Classification (used for outpatient coding) and HL7 2.5 - BAR^P12 -Update Diagnosis/Procedure. only when FIAB supports the update mode for the Patient Billing Account Event Revise messages). In V3 the concept of inpatient vs outpatient does not exist, this is accomplished via the A_BillableService CMET.
Type: |
This trigger event signals that the patient's billing account is deleted. This is usually an internal function controlled by the financial system. But sometimes a series of accounts need to be corrected , in which case, a notice of account deletion needs to be conveyed to other systems over an interface system. V2 Reference: The Close Patient Billing Account is most closely aligned with the HL7 2.4 BAR^P02-Purge Patient Account.
Type: |
This trigger event signals that the status of a merge-from account goes to obsolete and any outstanding balance is transferred with a financial transaction to the merge-to account. V2 Reference: The Merge Patient Billing Account is most closely aligned with the HL7 2.4 ADT^A41- MergeAccount - Patient Account Number. s
|
||||||
|
For details on the interpretation of this section, see the description of RMIMs in the Version 3 Guide.
Parent: | Patient Billing Account (FIAB_DM000000UV) |
This message model includes the creation and management of patient billing accounts. Central to the model is the concept of an account, with attributes such as identifier, type (code), balance and the currency (e.g. US $) of the account. Associations to the account include patient identification, insurance policy, encounter, and the optional specification of a guarantor for any outstanding balance in the account.
A Billing Account is an accumulator of financial and administrative information for the main purpose of supporting claims and reimbursement. Secondarily, the billing account may contribute significant information to cost accounting and financial decision support systems. A billing account is simply that entity that captures the elements reflecting the cost and price of services provided and supplies consumed for a healthcare activity. The focus for which an account accumulates information will vary. (For example: In a realm where billing is based on periodically collecting financial transactions for a patient, the accumulator might be the patient.) A billing account might also include links to insurance and benefit information, and relevant responsible parties.
Patient Billing Account Event | FIAB_HD010100UV02 |
|
||||||
|
For details on the interpretation of this section, see the description of HMDs in the Version 3 Guide.
This HMD includes the creation and management of patient billing accounts. Central to the model is the concept of an account, with attributes such as identifier, type (code), balance and the currency (e.g. US $) of the account. Associations to the account include patient identification, insurance policy, encounter, and the optional specification of a guarantor for any outstanding balance in the account.
A Billing Account is an accumulator of financial and administrative information for the main purpose of supporting claims and reimbursement. Secondarily, the billing account may contribute significant information to cost accounting and financial decision support systems. A billing account is simply that entity that captures the elements reflecting the cost and price of services provided and supplies consumed for a healthcare activity. The focus for which an account accumulates information will vary. (For example: In a realm where billing is based on periodically collecting financial transactions for a patient, the accumulator might be the patient.) A billing account might also include links to insurance and benefit information, and relevant responsible parties.
|
||||||||||||||
|
For details on the interpretation of this section, see the definition of Interactions in the Version 3 Guide.
Create patient billing account.
Trigger Event | Create Patient Billing Account | FIAB_TE010001UV02 |
Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
Message Type | Patient Billing Account Event Activate | FIAB_MT010101UV02 |
Sender | Patient Billing Account Informer | FIAB_AR010001UV02 |
Receiver | Patient Billing Account Tracker | FIAB_AR010002UV02 |
Update patient billing account.
Trigger Event | Update Patient Billing Account | FIAB_TE010002UV02 |
Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
Message Type | Patient Billing Account Event Revise | FIAB_MT010102UV02 |
Sender | Patient Billing Account Informer | FIAB_AR010001UV02 |
Receiver | Patient Billing Account Tracker | FIAB_AR010002UV02 |
Close patient billing account.
Trigger Event | Close Patient Billing Account | FIAB_TE010003UV02 |
Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
Message Type | Patient Billing Account Event Complete | FIAB_MT010103UV02 |
Sender | Patient Billing Account Informer | FIAB_AR010001UV02 |
Receiver | Patient Billing Account Tracker | FIAB_AR010002UV02 |
Delete patient billing account.
Trigger Event | Delete Patient Billing Account | FIAB_TE010004UV02 |
Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
Message Type | Patient Billing Account Event Nullify | FIAB_MT010104UV02 |
Sender | Patient Billing Account Informer | FIAB_AR010001UV02 |
Receiver | Patient Billing Account Tracker | FIAB_AR010002UV02 |
Merge patient billing accounts.
Trigger Event | Merge Patient Billing Account | FIAB_TE010005UV02 |
Transmission Wrapper | Send Message Payload | MCCI_MT000100UV01 |
Control Act Wrapper | Trigger Event Control Act | MCAI_MT700201UV01 |
Message Type | Patient Billing Account Event Obsolete | FIAB_MT010105UV02 |
Sender | Patient Billing Account Informer | FIAB_AR010001UV02 |
Receiver | Patient Billing Account Tracker | FIAB_AR010002UV02 |
Return to top of page |