A Discussion with Deb Aryes:
Developing Your Organization’s Data Detectives
Recently we had the opportunity to sit down with Deb Ayres, HSi’s Senior Healthcare consultant with Epic Business Intelligence development and report writing expertise. She shared some insider tips on developing the best reports and maximizing the efficiency of those reports.
Q: If I wanted to develop Epic report writers at my organization, where would you suggest I start?
A: If you have people with basic report writing skills, then starting with Epic’s delivered reports and adjusting or reverse-engineering them is a good way to learn. This will develop familiarity with Clarity tables and structure and provide some initial skills. Having a certification in build is a big plus to understand the workflows and data captured. Once you have a working knowledge of one area’s Hyperspace data structure and Clarity tables, it is easier to apply that learning to other application reporting. Because Epic is an integrated database, there are many tables shared with all applications, and linking the data between those tables is very similar.
Understanding workflows or having the ability to observe workflows is a big part of a report writers’ success. By understanding how and why data is collected in the operational setting, it is easier to look at data trends and see outliers or problems. For example, I was able to find missing revenue in an established service concerned their revenue was lower than it should be. I was able to create a report allowing us to drill down to specific codes and found many were not valid. By being able to fix the corresponding codes, the client was able to recapture millions of dollars of revenue.
Because of this need to understand the data and workflows, it is tempting to develop report writers in operational departments. I would caution organizations in this approach as I have seen more successful teams centralized in the IS department. By consolidating into a unified group, it allows the collective team to look at duplicate requests or create reports with adjustable parameters meeting multiple department and user needs.
Q: For an application you are not familiar with, what steps do you go through to create a report from a request?
A: First, you should sit down with the requestor and understand how they are going to use the report and the problem trying to be solved. Often requestors ask for reports that may not give them the information they need to solve the problem they are working on. I like to be more consultative with the requestor rather than taking their order and maybe giving them what they asked for but not exactly what they need.
Next, I would want to see how the data I am reporting on is entered in Hyperspace. I would look at the steps inside the application and ask front line users how they capture it. Once I am familiar with the workflows, I can determine the best way to visualize the data to give the information they need. I also work with the application analysts to understand the Hyperspace build components making up the workflow we are reporting on.
Before I start to create the report, I need to make sure I use the right reporting tool. I would ask how much data they want, what filters will be applied, and over what timeframe. If it is a lot of data or spans more than a few weeks, then the report should be run in Clarity where the environment can handle the larger queries without impacting performance. If the data is time-sensitive or run daily, Reporting Workbench is likely the better option. It is important to check if the report is pulling from the shadow server where it would also have a reduced impact on performance. Dashboards are also a nice tool to be able to pull together multiple reports and display a snapshot of real-time data in places like ambulatory and surgery settings.
Once I write the Clarity report, I like to validate the data against reports in Hyperspace. If they do not match, it requires some detective work to see if the calculations are different, the data is not being extracted to Clarity correctly, or in some cases, the build on the Hyperspace report may not be correct. It is fun to start off to solve one problem and end up digging in and finding solutions to other problems the client may not know even existed.
Q: What role does a consultant have on the reporting team?
A: Hyperspace is constantly changing, and it is important to keep up with those changes. Not only will data entry and workflow changes impact established reports, but there may be better ways to display information when newer data begins to be collected or collected in a new way. We keep up with these changes so we can share best practices with all our clients.
Additionally, Epic is always developing its reporting capabilities. They have made it known they are moving away from 3rd party reporting tools with enhanced Epic reporting features, but that transition will take time. The current 3rd party tools allow for additional features and I do not believe they are going away any time soon. Consultants can back-fill other reporting roles so the client team can focus on these tool transitions or other reporting projects while the consultant can keep up with the current requests. We can also be a resource to your team as mentors and informal leaders.
Whether a large organization needing a specific type of reporting or a smaller organization needing a broader skillset, we have been able to meet the necessary needs while developing the capabilities of the organization with which we are engaged. If you would like to dig deeper into any of our discussion topics with Deb, she may be reached at HSi@hsi-corp.com.