If you work in Revenue Cycle, odds are you have requested a report before. Perhaps those report requests were a result of a new regulation or a request from an executive in your health system. Or maybe you were worried a payer was not paying appropriately and you wanted to investigate denial data. There are a million and one reasons why we request reports, and often it is an urgent, last-second request.
From an IT perspective, I have found report requests to be one of the more challenging requests that an IT team will address. Report requests come from all areas of the health system, for all types of workflows, and all types of data. A report writer might start their morning addressing a request regarding radiology orders and end their afternoon writing a query for coding results. Likewise, they are likely being told every request is urgent and needs to be prioritized.
Additionally, bridging the gap between IT and Operations becomes significantly more challenging in reporting as you start from a place of no common knowledge. IT reporting speaks in data sets and Operations speaks in workflows. Thus, to find success in reporting, you need to establish shared knowledge between IT and Operations. Here are 3 steps I recommend for those conversations:
- Define the workflow and the end goal
- Provide examples
- Screenshots
1. Define the workflow and the end goal
I received this report request recently:
“I need a report to give me monthly infusion volumes. This report is for senior leadership”.
This is one of the more descriptive report requests I have received over the past few weeks. However, for a report writer who speaks in data models and not in workflows, this request is lacking.
The report writer is going to want to know the following for the report request:
- How do we define infusion (scheduled appointments, specific CPT codes charged, completed appointments, by claims data or something else)
- What are we calculating volume for?
- Should we restrict this report to a certain department/location/facility?
- Do we need the data summarized? Or just raw data?
- How do we distribute this report?
In this request, the workflow was infusion scheduling, but there is clearly missing context that the report writer would not know. If they did not ask questions, they might end up drafting a report on the measurement of infusion doses given over the past month!
A Better Way to Request:
“I am looking for a report that provides a count of infusion appointments for all of our infusion departments over the past month. You can identify Infusion appointments by a provider including the word Infusion in the name of the visit type. This report should be grouped to show the total infusion appointment count by day by provider. As I’m sending this report to Senior Leadership, this should be in an easily printable/PDF format that I can run ad hoc and send via email.”
From this request, the report writer can clearly see the use case, what needs to be defined, and the format which you want the results summarized. The report writer has clear instructions on what is needed, and it will be easier for them to ask clarifying questions to finalize your request. It is better to be specific and assume the report writer is not familiar with your workflow to ensure they do not jump to incorrect conclusions when compiling your report.
2. Provide examples
Most users do not need to understand how their EMR stores data. The account, transaction, admission, and appointment data just lives there from our perspective, and we do not think about the backend storage that is used to house and organize all that data.
When you request a report, your report writer immediately thinks about the backend data storage and how to search this data. If we are pulling data from two types of data, the report writer will need to figure out how to link these separate data sets together. Sometimes that can be really challenging, which is where being specific and providing examples is useful.
Let us say we are requesting a report on revenue generated by providers for an oncology department. In this scenario, we have transaction data, provider data, and appointment data for the visits to the oncology department. In your EMR, these data sets are separate, and the report writer will need to investigate to see how we can relate these data sets together.
Providing an example enables the report writer to follow the trail. They can identify the links between the data sets. Once they write the report, they can test with the example to ensure the results are populating correctly.
3. Screenshots
One piece of feedback I often hear from users involves a lack of consistency in how EMRs name certain fields. It is confusing to users that charges, payments, and adjustments are actually transactions, that claims are invoices, and that appointments are sometimes called visits.
Report writers share this confusion. Just yesterday I was working with a Finance team on writing a revenue report, and they wanted to see Surgical data. We had a half dozen emails back and forth trying to come to a shared knowledge on what they were really looking for before having to jump on a call and begin to take screenshots in the system to confirm the data fields. Ultimately an initial screenshot of what they were looking for could have quickly put to rest an hour of back-and-forth conversation. As they say in school, a picture is worth a thousand words.
If you are undertaking a large reporting project or are finding it difficult for Operations and IT to find a shared knowledge, it can help to have a resource who has experience and knowledge in both areas. Our team at The Wilshire Group fills that void perfectly between IT and Operations. Reach out to us to hear more about how we can support you. Contact Daniel Bianchini at d.bianchini@thewilshiregroup.net.
