User Guide — Post Date Reporting FAQ

athenaCollector

 

 

 

The post date in athenaOne is the general ledger reporting date in athenaOne.

 

 

 

You would want to use the post date if you need to run a static report (one that will not change over time). For example, if you want to find the sum of all charges (or all payments, or all adjustments) posted in a given month, and you never want that number to change if you run the report later, then you would run that report by that post date. This is a common requirement for running numbers that will be fed into a GL system.

 

 

 

It depends: You can specify the post date when the transaction is created, but you cannot update the post date after the transaction has been created. These dates are exposed as yellow Post Date fields wherever you can create or void transactions — on the Charge Entry page, the Claim Edit page, the Post Payment page, etc. You cannot edit the Post Date on the Prepare Deposit Batch page.

 

 

 

Once the system close date is set to a certain date, no new transactions can have a post date that is on or before that date.

 

For example, if the system close date is 02/28/2022, then all new transactions must have a post date of 03/01/2022 or greater. This means that after the post date is set to 02/28/2022, February reports that are run by post date will not change.

 

The system close date determines the open post date range. Transactions and accounting records (i.e. unpostables) are considered "closed" for the period up to and including this date.

 

Your practice automatically locks down transaction and deposit activity at the end of each the month, as an integral part of maintaining accounting integrity.

 

Your practice's close process has four important dates:

  • System Close Date — the date through which no new transactions can be posted
  • Day To Close Prior Month — the day of the new month to advance the System Close Date to the last day of the prior month
  • Deposit Close Date — the date through which no new deposits can be posted
  • Day to Reconcile Deposits — the day of the new month to advance the Deposit Close Date to the last day of the prior month

 

By default, Day to Close Prior Month and the Day to Reconcile Deposits, will advance on the 7th of the month.

 

If the Day to Close Prior Month is set to a non-default value but the Day to Reconcile Deposits is still the default value, both the SYSTEMCLOSEDATE and DEPOSITCLOSEDATE will advance on the Day to Close Prior Month.

 

If the Day to Reconcile Deposits is set to a non-default value but the Day to Close Prior Month is still the default value, the DEPOSITCLOSEDATE will advance on the selected day. The SYSTEMCLOSEDATE will still advance on the 7th of the month.

 

 

The reason that you might not want to use the created date is because of the way that athenaOne keeps the post date static — i.e., "ghosting." Basically, if the payer/provider/department/procedure code on a claim is updated after the system close date, then a copy of the claim is ghosted and the original claim is updated. From a system perspective, your historical reports will change, and a 99213 that was performed 3 months ago will suddenly look like activity posted today (although there will be a corresponding void for that charge that will have the exact same time stamp). For more information, including the reasons why we do this, see the section on ghosting below.

 

Reports run by creation date will generally not change drastically over time, so if you want reports that are mostly accurate, reports run by creation date may work; but again, they are not guaranteed to remain static over time. That is, if you run the sum of charges for the current month, and then run the report again the next day, the sum may have changed (regardless of what the system close date says) because the charge amount may have been updated in the interim. Reports run by creation date are therefore not suitable for GL purposes.

 

 

 

The sum total for each transaction type (CHARGE, PAYMENT, ADJUSTMENT, TRANSFERIN, TRANSFEROUT) and each transfer type (primary, secondary, patient) are guaranteed to remain static over time when run by post date. That is, if the system says that $5000 worth of primary charges were posted in February and the system close date is 02/28/2024, then the $5000 total will never change.

 

Breakdown reports run by provider, supervising provider, department, and procedure code are guaranteed to remain static over time — i.e., the breakdowns will not change over time.

 

Reports run by insurance package are guaranteed to remain static with the following exceptions:

  • Pending insurances may "migrate" to their proper insurance.
  • If athenahealth merges insurance packages, the two "old" rows will appear as one row.

Reports run by insurance reporting category are guaranteed to remain static over time with the following exceptions:

  • Because insurance reporting category is simply a roll-up of insurance packages, both of the exceptions for insurance package apply.
  • If athenahealth changes the insurance reporting category that a package belongs to, then the report will reflect the new insurance reporting category.

No other reports are guaranteed to remain static over time.

 

 

 

 

How about the service date, the charge post date, the service post date, the charge creation date, the last billed date, the first billed date, and the last action date?

 

 

 

If I enter a $50 charge with a from date of 1/21/2024, then regardless of when I entered it or what its post date is, that $50 will appear in an Activity report (Activity Wizard — advanced view) run by service date for January. (Select "service" to show claims that have service dates within the Start Date/End Date: range.)

 

What may be somewhat less intuitive is that the payment, adjustment, and other columns reflect payments made against that change. In the example above, let's say that in March, I post a $30 payment and a $20 adjustment against the 1/21/2024 charge. I then run the Activity report for January. What I will see is $50 in charges, $30 in payments, and $20 in adjustments.

 

That is, the payments, adjustments, and transfers-out inherit the service date of the charge that they are posted against. This sort of report may be useful if you want to see how much you have collected against services rendered in January.

 

 

 

This is much the same as running a report by service date (see above), except that the narrowing criteria for the set of charges is charge post instead of the charge's service date. That is, this report tells me how many dollars worth of charges I posted in January (which, as per the post date discussion, will remain static over time), but will also tell me how many dollars worth of payments and adjustments I have posted so far against those January charges.

 

As an example: Let's say I post a $50 charge on 1/30/2024. Let's then say that in March, I post $30 in payments and $20 in adjustments against that charge, and then immediately run the Activity report for January. I will see $50 in charges, $30 in payments, and $20 in adjustments.

 

For reports run by charge post, the charge column should remain static over time, subject to the post date constraints above. The payment, adjustment, and transfer columns will change as those transactions are posted against those charges.

 

 

 

The last billed date is the last date that this claim was batched into a file to be sent to the payer. As in the previous two cases, payments, adjustments are inherited from the charge last billed date.

 

 

 

 

A/R represents amounts that are outstanding to you. Regardless of which date you choose (service, charge post, service post, charge creation, last billed, first billed, last action), the total amount of A/R will not change. What changes is how the A/R is apportioned into the aging buckets, i.e., how "old" the outstanding amount is considered to be.

 

 

The age is measured from the date of the charge service (the from date on the Claim Edit page).

 

 

 

The age is measured from the date that the charge or transferin was posted (see "service post" for more information). To maintain historical accuracy when a claim is changed after a financial period has been closed, claims that you're reporting on appear as "ghosted." The transaction ghosting mechanism creates a copy of the claim as-is before any changes are made and freezes that copy. Therefore, the claim appears as a closed result on the A/R Aging Wizard but can still have an outstanding A/R. Because of this ghosting mechanism, charge post is a useful way to run this report.

 

 

 

As transactions, transfers in athenaOne are modeled as follows:

 

Type amount code postdate insurance
CHARGE $80 99213 3/14/2024 MEDICARE
PAYMENT $60- 99213 3/14/22024  
TRANSFEROUT $20- 99213 3/14/2024  
TRANSFERIN $20 99213 5/12/2024 MEDICAID SUPPLEMENTAL

 

If you run this report by charge post on 5/20, you see $20 in the 0-30 bucket. If you run this report by service post on 4/20, you see the $20 as of the post date on the parent CHARGE, i.e., in the 60-90 bucket.

 

 

 

The report will be aged by the date that the charge was created. On account of ghosting, this is also a relatively stable and useful way to run A/R.

 

 

 

The report will be aged by the date that the charge was last batched into a billing batch (not including appeals or follow-up). If the charge has never been billed, the charge is considered to be one day old.

 

 

 

The report will be aged by the date that the charge was first batched into a billing batch. If the charge has never been billed, the charge is considered to be one day old.

 

 

 

For any claim notes except those of type ALARM or SCRUB, the claim's last-action date is time-stamped to the time stamp of claim note creation. Reports aged by last action are therefore aged according to the last non-ALARM/SCRUB claim note.

 

 

 

The aging-as-of field cuts the universe of transactions so that only transactions posted on or before the aging-as-of date are considered.

 

For example, take the following transaction set:

type

amount

code

postdate

insurance
CHARGE

$80

99213

2/15/2024

MEDICARE

PAYMENT

$60-

99213

4/14/2024

 
TRANSFEROUT

$20-

99213

4/14/2024

 
TRANSFERIN

$20

99213

4/14/2024

MEDICAID SUPPLEMENTAL

 

If you run an aging as of 2/28/2024, you will see $80 outstanding to MEDICARE for this charge. If you run the aging as of 4/15/2024, you will see $0 outstanding to MEDICARE, and $20 outstanding to MEDICAID SUPPLEMENTAL.

 

 

 

Running the A/R report by date of charge creation or by date of service is generally the most useful way to run an aging report in athenaOne; these options yield results closest to what you might expect.

 

 

 

 

 

After the system close date advances beyond the post date of the charge on a claim, athenaOne guarantees that historical reports run along the following dimensions remain static:

  • PROVIDERID — If the provider changes.
  • PRIMARYPATIENTINSURANCEID, SECONDARYPATIENTINSURANCEID — This is the big one; if the primary or secondary policy is switched (not if the policy number, for example, is updated).
  • PATIENTDEPARTMENTID — If the patient department on the claim changes.
  • DEPARTMENTID — If the department on the claim changes.
  • Any transaction-level updates to the charge procedure code, charge amount, etc.

"Transaction ghosting" is the technical mechanism by which athenaOne ensures that historical reports run via their parameters remain static.

 

History

Let's say that we keyed in a $80 99213 for Joe Black on 2/15/2024, with primary insurance Cigna.

 

Today is 3/15/2024. The system close date is 2/28/2024, so February reports should remain static across the dimensions listed above. We receive an EOB from Cigna saying that the patient is not on file; upon doing some follow-up, we find out that the patient lost their Cigna coverage and was covered under Aetna for that time period.

 

In most other practice management systems, you must do the following:

  • Void the original charge.
  • Key in the new charge.

This in and of itself doesn't sound too bad, but let's add a complication. Let's say that the original charge has a $20 copay posted against it, so it's:

 

type

amount

code

postdate

insurance
CHARGE

$80

99213

2/15/2024

CIGNA

TRANSFERIN

$20

99213

2/15/2024

 
TRANSFEROUT

$20-

99213

2/15/2024

 
PAYMENT (patient payment)

$20

99213

2/15/2024

 

 

In order to preserve historical reporting, you must:

  • Void the payment, transferin, transferout.
  • Re-post the transfer and the payment.

From a transaction standpoint, we need a charge history that looks like the following:

 

the original transaction set, posted on 2/15
type

amount

code

postdate

insurance
CHARGE

$80

99213

2/15/2024

CIGNA

TRANSFERIN

$20-

99213

2/15/2024

 
TRANSFEROUT

$20

99213

2/15/2024

 
PAYMENT (patient payment)

$20-

99213

2/15/2024

 
voiding the original transaction set
type

amount

code

postdate

insurance
CHARGE

$80-

99213

3/15/2024

CIGNA

TRANSFERIN

$20

99213

3/15/2024

 
TRANSFEROUT

$20-

99213

3/15/2024

 
PAYMENT (patient payment)

$20

99213

3/15/2024

 
re-posting the new AETNA transaction set
type

amount

code

postdate

insurance
CHARGE

$80

99213

3/15/2024

AETNA
TRANSFERIN

$20-

99213

3/15/2024

 
TRANSFEROUT

$20

99213

3/15/2024

 
PAYMENT (patient payment)

$20-

99213

3/15/2024

 

 

This gets much more complex if you have a secondary payer involved and multiple adjustments and payments; the tree gets deeper.

 

In most other practice management systems, you are forced to void and reconstruct this tree of transactions manually. This is a laborious, error-prone, time-intensive process.

The athenahealth Ghosting Method

 

We do the following using ghosting:

  • Create a new claim that looks exactly like the old claim, complete with the old claim's post dates; immediately void all these transactions.
  • Update the old claim with the updated information and update the post dates on the old claim so that it has current post dates (for example, 3/15).

This is probably worth re-stating. In essence, we update the claim as we normally would. athenaOne then updates the post dates on the claim so that from a post-date standpoint, the claim looks like it was created today. Then, in the background, athenaOne transparently creates a voided copy of that claim (a "ghost"), complete with old post dates, to preserve historical transaction reports. This preserves and optimizes the two basic use cases — operations and reporting:

  • For operations, a biller can simply and intuitively update the claim without having to void and recreate the transaction tree manually.
  • For reporting, anyone reporting on this data can be confident about transaction reports run by post date.

Ramifications for Technical Report Writers

  • If you are running your own SQL queries: for most reports where claim is the driving table (i.e., where charges are not the driving table), you should add the SQL clause "where originalclaimid=claimid". This clause ensures that you don't double-count ghosted claims.
  • From a SQL standpoint: as long as you always query on post date, you will be fine. That is, here's a sample query that gives all charges posted in February:

select  sum(charge.amount)

from     transaction charge

where  charge.type in ('CHARGE','TRANSFERIN')

 

You should never rely on transaction.id. That is, the following query is not guaranteed to remain static over time:

 

select  sum(charge.amount)

from    transaction charge

where  charge.id in (123,124,125,126,127)

 

A full example:

 

1* select id,to_char(created,'MM/DD/YYYY HH24:MI:SS'),postdate,voided,type,procedurecode,amount

from transaction

where patientid=72399 and createdby='epark'

 

13:31:30 ATHENA322 on MIN1> /

 

ID TO_CHAR(CREATED,'MM   POSTDATE VOIDED TYPE PROCEDURECODE AMOUNT

62852    05/19/2024           13:28:04     05/19/2024 CHARGE 99213 95

62853    05/19/2024           13:29:45     05/10/2024 05/19/2024 CHARGE 99213                 85

 

13:31:31 ATHENA322 on MIN1> ed

Wrote file afiedt.buf

 

select id,to_char(created,'MM/DD/YYYY HH24:MI:SS'),postdate,type,procedurecode,amount from transactionreport

where patientid=72399  and createdby='epark'

/

 

1* select id,to_char(created,'MM/DD/YYYY HH24:MI:SS'),postdate,type,procedurecode,amount from transactionreport

where patientid=72399 and createdby='epark'  

 

13:38:00 ATHENA322 on MIN1> /

 

ID TO_CHAR(CREATED,'MM POSTDATE TYPE PROCEDURECODE AMOUNT

62852  05/19/2024    00:00:00        05/19/2024    CHARGE       99213                            95

62853  05/19/2024         00:00:00       05/10/2024    CHARGE       99213                            85

62853  05/19/2024         00:00:00        05/19/2024    CHARGE       99213                            -85