Well, I was going to write some witty story about using the right tool for the job, but, with all of the recent election talk, I figure we’ve had enough of that topic. So let’s get into the brisket (no not BREXIT!) ‐ meat, or Tofurkey™ if you prefer…
Reporting can be a challenging topic for anyone that uses, implements or supports reports. The key to understanding reports is to realize that any report you review is built for a specific person for a specific reason at a specific time. That person was trying to answer a specific question, so they built this report.
There are reports that have been developed to be used by the general user, but each general, or “canned”, report is still developed to answer a specific set of questions. This means that using a general report to answer questions for which the report was not designed may give you the wrong answer to the question you are trying to answer. This is why whenever someone is looking for a general report to answer a specific question, the question, business workflow, and variations to the question and workflow need to be reviewed to make sure that the right report is used to answer the specific question asked.
When I talk to different users about reports, I don’t start with an existing report. I always start with the question the user is trying to answer. I ask as many questions I can think of to try to understand what the user is trying to do. Many times I ask the same questions a different way to make sure that I completely understand.
I then get into the process. I look at the business process as a whole, including the system and non‐system parts of the process. Of course writing a custom ehr report from a system requires the data to be in the system, but you would be surprised to hear that many times the data the user wants to report is not currently captured in the system or it is captured in a way that is not reportable. It is only through understanding the business process as a whole that you can identify the restraints of report and the business process changes that might be necessary to properly answer the user’s question with a system report.
Once I understand the question and the process, I detail out the details of the report. There are five major categories of report details: logic, user selected filters, fields, report field to system mapping, field groupings, and report delivery.
Here are the various questions I ask, and items we consider when going through this process:
- Logic ‐ Describe what conditions the data must meet in order to show or to be excluded from the report. For example, I only want patients with appointments in the selected timeframe that do not have a current, valid referral.
- User Selected Filters ‐ List the filters that should be on a prompt page. In the example given above, you would have a “From Appointment Date” and a “To Appointment Date”. You might have an “Appointment Provider” filter if the user wanted to filter by appointment provider.
- Fields – List the fields that the user wants on the report. For the example above, you might have the patient name, date of birth, appointment date, appointment time, appointment provider, and primary insurance.
- Report Field to System Mapping ‐ List where each of the report fields listed above comes from the system. I find it beneficial to not only include the screen and field name in a table with the report field, but also include screen shots of the different fields.
- Field Groupings ‐ Fields in the field list by which the user wants to group data on the report. This is typically for formatting, improving readability, or subtotals. In the example above, you might group by appointment provider or date.
- Report Delivery ‐ It is important to understand what the user wants to do with the report. Do they want to download the data to CSV or Excel? Do they want a formatted report they can export to PDF and email? Do they want to automatically upload the data to a third party like an ACO, 340B vendor, or similar? Depending on the delivery method, you may need to change the tool you use to build the custom ehr report.
As you can see, there is a lot to consider when developing an ehr custom report. If you are looking at using a canned report, don’t just assume that because the title of a report sounds like what you are looking for that it is. Take a step back to look at what questions you are asking, what the business and system processes are, and then review the report to determine if it meets your needs.
Remember this Thanksgiving that sometimes homemade cranberry sauce may be what you think you want, but sometimes you just need a quality can of cranberry gelatin. Either way, give thanks for all your blessings, including the report developer that just completed the 20th revision of your report because you didn’t know what you really wanted when you started. I know they will be thankful for you!
Need a report, canned Spam for the holidays, or just not quite sure how to use all of the “ingredients” that make up your EHR system? Mi7 can mix it all up, cook it, and help you dish up a custom ehr report that your entire practice will enjoy. Want a custom ehr report that will help you better manage certain patient populations? Coming right up! Need to know the primary reasons your claims are being rejected, or where hang ups in the billing process might be? BAM! We can do that too.
Contact us today, we’d like to hear what questions you need answered.