“Elementary, My Dear Watson”: How to Find Missing Healthcare Data after a Major System Upgrade

Across the years, Sherlock Holmes has been counted on to solve all kinds of seemingly impenetrable cases that have baffled lesser minds. For example (and spoiler alerts for those uninitiated in the Sherlockian Arts), he deduced with surgical precision that the killer in Hound of the Baskervilles was the nasty neighbor, and that the Red-Headed League was actually a ruse designed to help two would-be robbers dig a tunnel to a bank. Not too shabby for a guy who had a habit of storing tobacco inside a slipper.

However, if Holmes was transported to the 21^st century — or if the folks behind the current BBC series wanted to take the show in a radically different direction — he might find it more than tough to unravel what we can dub: “The Very Curious, Most Concerning, and Totally Confounding Case of the Missing Healthcare Data After a Major System Upgrade.”

Chapter 1: The Crime Scene

In the best tradition of Holmes’ faithful friend and biographer Dr. Watson, let us start with a look at the grizzly details around the crime scene. Here are the reasons why data often vanishes after a major system upgrade:

• Since major system upgrades are new, they contain unfamiliar and re-written modules, as well as extended functions. Staff are left groping in the dark to find their bearings. They do not even know what they do not know.
• In an attempt to get the most value out of the major system upgrade, management often sees this as an ideal time to restructure things like expanding codes for cost centers, restate the Charge Description Master, and re-do archaic revenue cycle systems to better handle recurring procedures. Amid this re-invention, it is really not a question of whether data will go missing, but how quickly and how much will disappear.
• Change is inherently stressful — even the kind that is supposed to be positive (something to which those of us who have a long list of failed New Year’s Resolutions can shamefully attest). During a major system upgrade, some people can feel so disoriented and threatened that they insist on customizations to make things work the way they used to. Not only is this expensive, but it can trigger issues that ultimately require even more customizations and rework — effectively diminishing or even negating the new and improved system design.
• While there is usually a third-party implementation team involved, they are not always in a position to catch problems in the making.  Basically, they do not really understand the hospital’s current flow and business rules. To be fair, however, old systems have been modified, patched and “MacGuyvered” for years — and sometimes decades — and as such the hospital itself does not fully understand why it works the way it does.
• The process of converting data can unleash all kinds of data chaos. For instance, old systems always have both defined fields and standard fields that a hospital has repurposed. This needs to be understood and resolved, yet is often missed. In addition, major system upgrades are often viewed as an opportunity to consolidate best-of-breed choices into a single system approach, which requires data conversion from one vendor to another. Usually, the original vendor is not interested in helping too much, and so the conversion is messy at best.
• It is rare when staff are completely free to focus on designing and validating the new system. After all, they still need to perform their day-to-day job. Nevertheless, milestones are set, and penalties may in place for missing deadlines. Consequently, priority is given to transactional flow within a department, minimal work is done coordinating between departments (e.g. clinical operating procedures and revenue flow), and robust and systematic validation is often replaced by random tests. This latter pitfall is particularly problematic, because the best (and experts would say the only) time to test a new system is before it goes live — not after. Believing that there is plenty of time to get things right because some areas like the General Ledger will not close the books for a month or so after going live is an invitation for data chaos.

Chapter 2: The Evidence

Sherlock Holmes is reported to have said that “it is a capital mistake to theorize before you have all the evidence. It biases the judgment.” Far be it from us to incur the wrath of Mr. Holmes (he is an outright bear when irritated). And so, before we start looking at clues and solutions, let us scan the scene and pound the pavement to gather proof of this alleged offense.

Below are some of the severe problems that erupt when healthcare data goes missing after a major system upgrade:

• Bills do not go out, which means that revenues do not come in — at least not in a timely manner. This is unacceptable at even the best of times, and we are certainly not in one of those halcyon periods at the moment. Across the U.S., hospitals have collectively lost hundreds of billions of dollars in revenue due to the pandemic.
• Charges are reported in the wrong places — which makes some departments look great against the budget, while others look bad (or terrible).
• Throughput is much slower. Admittedly, the learning curve has something to do with this, but new customizations can negatively impact performance.
• Critical data is no longer captured, or is no longer in a recognizable location in the data (imagine trying to read a giant 1,000-page technical manual after someone rips out the table of contents and appendix).
• Fields that are supposed to have data are NULL — usually because nobody understands why the data was needed.

To say that this is ample evidence of a data crime is a gross understatement. As long as we are evoking celebrated fictional figures: attorneys such as Perry Mason, Ben Matlock, or Jack McCoy (*ping*) do not need to be attached to this case. Heck, even Arrested Development’s Barry Zuckerkorn or The Simpsons’ Lionel Hutz would be fine.

Chapter 3: The Victims

The most compelling cases have the clearest victims, and unfortunately the case of the missing healthcare data checks this box. There are four classes of victims.

The first victims are management. Rather of reaping the rewards of a major and expensive investment — one that took many months of discussing and planning, and may have been on the agenda for years — they are confused and frustrated. Instead of things getting better, they are worse.

The second victims are end users, who are already fatigued and overwhelmed from implementation and go-live activities. They cannot do their jobs in an efficient manner, which puts them further and further behind. Unfortunately, management (see above) does not have the answers they need. Instead, they just have more questions.

The third victims are the reporting tools, which are mistakenly blamed for vaporizing the data. Alas, reporting tools make easy scapegoats. As the old saying goes: garbage in, garbage out.

And the fourth victim — and most damaging of all — is trust. When the organization no longer trusts its own data, management is forced to rely on anecdotes, rumors, guesses, hearsay, “squeaky wheels,” and so on. They lose focus, make regrettable decisions, and momentum slows down or stops. Once lost, trust can take a long time to re-establish.

Chapter 4: The Solution

What makes reading (or watching) Sherlock Holmes so compelling, is that just when the well-meaning but mediocre talents around him believe they have cracked the case, the legendary private eye announces something shockingly unconventional that changes the entire paradigm — and casts a whole new light on the scenario. In storyteller circles this is called a plot twist.

Well, the plot twist in The Very Curious, Most Concerning, and Totally Confounding Case of the Missing Healthcare Data After a Major System Upgrade is that the reporting team — yes, the very folks behind unfairly maligned reporting tools — can solve the case.

Here is what the reporting team can do to reclaim all the missing data after a major system upgrade:

• Augment staff at any time – during the implementation or after — to reduce the significant, and often overwhelming administrative burden.
• Convert old reports so they can be used in the new system.
• Create a range of special reports to ensure system integrity, such as: master lists to verify alignment between old/new data; compare values before/after the upgrade to detect trends and patterns; take snapshots of data to trace problems and aid resolution; find NULL values so they can be addressed; and configure program rules to evaluate data and expose inconsistencies/reconcile bad data.
• Archive data from retired systems —possibly by copying key data to a server and layering a reporting tool/service on top, which is highly cost effective. Archiving data is vital, because by law some clinical and financial data must be kept for a specified number of years. At the same time, by having the reporting team archive data hospitals are not forced to pay excessively inflated rates to their old vendor if they need retrieve information down the road.

Indeed, hospitals will be more than impressed — they stand to be amazed —when they realize how the reporting team can turn the major system upgrade from a struggle into a triumph. Of course, we would not expect the restrained Sherlock Holmes to share in this excitement. Indeed, for the master of all sleuths, coming to this inescapable conclusion after analyzing the crime scene, collecting the evidence, and assessing the victims is nothing more than Elementary, My Dear Watson.

Contact Polaris and learn how we can help your organization reclaim missing data after a major system upgrade. Like Sherlock with his magnifying glass, we have the expertise and tools to shine a light on your healthcare analytics — and ensure your team gets the information and answers they need.