Billing Admin Site Visit

<< back to Billing

Michael Trenholm-Boyle visited the Family Medical Centre and observed Kruise perform billing claim submission and rejected claim processing using Wolf.

Wolf is designed to support billing in different provinces and we will need to take care to
abstract the billing process. There are things which are common to all provinces such as the
service provider ULI (PRACID) and the patient ULI (PHN).

The billing admin submits claims on a daily basis. The submission workflow is optimized for the case
where there are no rejected claims. As a result, the workflow for the billing admin to submit claims
is extremely streamlined: simply hit a “submit” button and type a passcode (i.e., the passcode
displayed on the RSA SecurID key fob).

This is where Wolf underwhelms and where the billing admin invests a lot of effort. It is thus also the area where we can offer substantial differentiation.

First, the billing admin must poll for claims results. Generally, this is performed on a weekly basis or faster.
To poll for a claim, the admin clicks a button and enters the passcode on the RSA SecurID key fob.
All claims with rejections are displayed and it is up to the billing admin to remember which claims are
new and which were there from before. Worse, of the claims that are not new, the billing admin must remember
which have been resubmitted already and which are still awaiting action.

Wolf has a messaging system built-in
that allows the billing admin to send a message to the practitioner about a claim: the messages are linked to the
relevant claim and when looking at the claim itself it is possible to see a log of all the messages exchanged about it.
The billing admin can determine if a claim has been adjusted by a practitioner and is now awaiting resubmission by
examining the claim's message log.

Next, the billing admin must search for “exceptions”. To search, the billing admin specifies how
far back to search (typically 30 days or less) and what kind of “exception” to look for:

1. Refused claims
2. Paid out < 100% of the claimed amount
3. Paid out > 100% of the claimed amount (rare)

The first class of exceptions, refused claims, are common and generally indicate an error or ommission
in the data entered by the practitioner.
Although Alberta HLink reports only very terse error codes, Wolf provides a rich description of the exception,
including its raw HLink error code (e.g., 37A), a short description and a long explanation that may
describe typical reasons for the problem and common solutions.

The second class of exceptions, claims which paid out less than the full amount claimed, are routine.
Sometimes the amount paid out is, for example, 75% of the full amount; other times, the amount paid
is zero. For example, there are restrictions on how frequently over the course of a year a practitioner
can claim a particular code for the same patient: when the limit is reached, subsquent claims pay
out at 75% until a different limit is reached and beyond that limit the claims pay out at zero.

For this class of exception, the billing admin first checks the data to ensure there wasn't an error
in what was provided by the practitioner. Even if the data looks reasonable, there are often ways
of ammending the data, changing the claim, so that the claim can be resubmitted for a greater amount.

Since Kruise, the billing admin I shadowed, was still in training, she used the messaging
system built into Wolf to ask the practitioner what they would like have done about the claim.

Often, the only thing that can be done is to simply accept and acknowledge that a reduced amount
has been paid. Doing so does more than just clear the claim from the list of “exceptional” claims.
Wolf includes a simple accounting system that is also used when patients pay out of pocket for
services. Acknowledging the reduce payout in claim exception processing ensures that the billing
module will be reconciled with the the accounting system.

The final class of exception, claims which paid out more than the full amount claimed, are rare.
Generally, all the billing admin does for these claims is acknowledge the adjusted amount to
ensure the accounting is reconciled.

Kruise provided copies of materials that she received when being trained on how to submit billing claims. Scans of these documents appear below:

• AHW Billing
• Kruise's Billing Cheat Sheet

• The Alberta billing module will need to store, for each billing admin, a submitter prefixthe RSA SecurID username, RSA SecurID PIN, the HLinkWeb username and HLinkWeb password.
• The Alberta billing module will need to keep track on a per-appointment basis, a submission status: unsubmitted –> submitted –> rejected ←–> re-submitted –> (processed | refused | cancelled)
• The Alberta billing module will need to store on a per-appointment basis a complete log of submissions and results.
• MedCloud appointment view must show an indication of current submission status with a hyperlink to a log of claim submission history.
  • The log of claim submission history must show, for each submission attempt, the date of the submission, the result, the date the result was received, and extra information associated with the claim result such as the amount paid or the reason for rejection or refusal.
• MedCloud must have a button on the appointment view to prepare a claim for the submission (or resubmission) and a indicator of submission status.
  • Submission status is independent of “locked” status.
• MedCloud admin menu must have an option to submit claims marked for submission.
  • The user must be prompted for their PIN + RSA SecurID passcode.
  • When entered, the system should submit the claims via the Alberta billing module and mark the claims as submitted (awaiting results).
• MedCloud admin menu must have an option to fetch processed claims.
  • The user must be prompted for their PIN + RSA SecurID passcode.
  • When entered, the system should retrieve the results of submission and update the status of any claims.
• When results are fetched and process, a list of the updates to claims should be presented to the admin.
  • Each result should give the date of submission, the submitting practitioner, the result and the extra information associated with the result with a hyperlink to display the corresponding appointment.

• MedCloud should have a per-appointment message log (chat history).
• MedCloud should have a billing/invoicing system.
• MedCloud should have an abstraction of billing systems.