Business intelligence and clinical data analytics are critical to the business and clinical operations of most healthcare organizations. They are both primarily business-oriented activities, helping to inform clinical, quality improvement, and business operations decision-making.
Despite being business focused, there are many technological aspects that influence whether or not business intelligence (BI) and clinical analytics function properly. This may be forgotten when dashboards are working well, reports are being used, predictive models are holding true, necessary decisions are getting made and they are influencing appropriate reactions.
Issues will arise (even in functioning systems)
Some of the biggest technical disasters that I've seen have occurred because an untested or partially-tested solution was placed into a production environment before it was truly ready.
However, as is the case with any technical endeavor, issues can arise at some point, even in properly functioning BI and analytics systems. There are many potential points of failure in analytics systems because of the number of stages between data entry by system users on through to processing and, eventually, decision-making by healthcare leaders and clinicians. Examples of the issues that can arise range from a data entry, validation or other data quality issues, a flaw in business rules logic or algorithms as well as technical infrastructure issues.
Severe consequences can arise when things go wrong with analytics and BI systems. Users of such systems may begin to lose trust in their output and revert to more "gut-based" decisions. Worse yet, though, is that business and/or clinical decisions may be based on inaccurate information.
Troubleshooting analytics and BI issues
When I had more hands-on involvement in software development, issues with code would invariably arise that would require efficient troubleshooting skills to prevent a minor issue from becoming a big problem (both technically, and from an end-user's stress management perspective). Many of those software troubleshooting skills are directly relevant to how I now deal with clinical analytics and BI issues. A brief summary of my analytics and BI troubleshooting approach is as follows:
- Don't panic! Tensions will naturally run high when employees lose use of decision-making tools they've grown to rely upon. Don't let this anxiety force you into a "solution" that may not be fully thought out.
- Identify the scope and root cause of the issue and any associated risks. Find out what tools, reports, dashboards, etc. are affected and how the problem is manifesting to stakeholders and end users. Find out what the risks are, what decision-making processes are affected and how they impact clinical and business operations.
- Communicate with impacted stakeholders. Ensure that all affected stakeholders are made aware of the problem, and how it manifests, so they can change their decision-making approach if necessary. Also keep them apprised of the progress toward a resolution of the issue.
- Determine the root cause of the problem. Taking the time to truly understand a problem helps address root cause, not merely its symptoms. For example, if a data quality issue is causing problems, it's best to address the process or source system causing the issue, not simply applying a patch to the report or dashboard.
- Mobilize resources to fix the issue. Once a possible source or root cause is identified, alert and mobilize the appropriate technical and analyst resources such as database administrators. Keep in mind that resolving for some issues -- such as those relating to source-system processes or data validation -- may involve more than a simple technical fix. These scenarios may require training of end users, or more extensive communication.
- Test and validate the solution. Every fix needs to be thoroughly tested to ensure that the problem is resolved and that other (unintended) consequences and negative downstream effects have not been introduced. Some of the biggest technical disasters that I've seen have occurred because untested or partially tested software was placed into a production environment before it was truly ready.
- Deploy the application. Once it has been tested and validated thoroughly, the system can be deployed into the production environment and/or released to stakeholders.
- Communicate with stakeholders. After deployment, inform your stakeholders that it is available. They must also be told of any changes that were made that would impact how end users interact with the system or the information it generates. You probably noticed that communications is mentioned twice. This is because I don't believe you can over-communicate with stakeholders. Their work is being impacted so the least you can do is keep them in the loop.
Getting back to business
As previously mentioned, issues that arise may be limited in scope or may affect the entire enterprise. Your response to an issue needs to be proportional to its effects. If a problem can be fixed immediately, then there is no need to follow all these steps. However, there are often many points of failure between source systems and the analysis performed on that data. Finding and addressing the root cause can be time-consuming and complex. In the case of a high-impact issue and/or lengthy fix time, the problem-solving detailed above can help keep your team on track and your stakeholders informed.
About the author:
Trevor Strome, M.S., PMP, leads the development of informatics and analytics tools that enable evidence-informed decision-making by clinicians and healthcare leaders. His experience spans public, private and startup-phase organizations. A popular speaker, author and blogger, Strome is the founder of HealthcareAnalytics.info, and his book, Healthcare Analytics for Quality and Performance Improvement, was recently published by John Wiley & Sons Inc.