In my last blog post, I wrote about the omnipresent desire to always be looking for something that’s just a bit better than what we already have. Since I write about – and work in – healthcare IT, you can imagine that I didn’t focus on dating or relationships. Instead, I noted that clinical and operational leaders in hospitals and health systems are often interested in implementing new software with marginal functionality improvements. “Yes, yes, our current system does most of what we need, but we saw this other application, and boy oh boy, you should see how it handles a few of the more difficult workflows.”
Last time, I observed that with respect to electronic health records (EHRs), it can be difficult or even impossible to connect small, niche applications to the core system. (NB: Nordic’s Digital Health Director Scott Rossignol called me out on my proposition, so as a punishment, I forced asked him to write a blog post outlining his objections. Scott will argue that with standards such as FHIR becoming more mature and well adopted by both large EHR vendors and small, focused app companies, interfaces are increasingly becoming a commodity. Look for it soon!) I argued that if an app can’t be properly interfaced to the EHR, either due to financial or technical constraints, it’s hardly useful as myriad problems will inevitably crop up. One can envision users having to enter identical information in various places, and as a direct consequence, one can foresee erroneous or contradictory data existing in the EHR.
Very large and sophisticated healthcare systems around the world have found themselves with a plethora of software that may have made sense as it was purchased and installed but lacks cohesiveness when studied as a whole. The United Kingdom’s National Health Service (NHS) discovered that it has such a problem. As a recent white paper noted, “…[T]here are typically hundreds of small surrounding ‘feral’ apps, including quality improvement registries e.g., for cancer, cardiology, rheumatology or renal medicine, departmental and clinical hobbyist apps. These are rarely integrated with the main [EHR] system, but often grow to become a key part of service delivery.”
The concept of a “feral” app brings to mind dozens of cats moving in different directions and doing what they want without regard to others. It’s often been said that getting physicians (American ones, at least) to follow a standard is like “herding cats,” so a feral healthcare app is easy for me to contemplate. Companies and health systems end up with these small software programs because users have a need that cannot or will not be addressed by the core EHR. Perhaps clinicians have asked for enhancements from the big IT vendors and their own IT shops but have been turned down. Under any circumstances, the outcome is many apps that serve a small but important function.
Typically, these feral apps run under the hospital’s IT radar. This means that they’re often not interfaced into the EHR, aren’t upgraded as new versions are released, lack the latest security patches, and don’t meet state or national regulatory requirements. Further, the information entered into these apps is siloed and only available to the small group that interacts with them. The hospital’s HIM department frequently doesn’t know these applications exist, and hence can’t reliably produce a complete response to a patient’s (or their attorney’s) release of information request. In the long run, having many small, poorly supported applications isn’t sustainable.
Now don’t get me wrong! When I refer to an unsustainable ecosystem, I’m talking about these feral apps. The dream/vision/expected new reality is that we’ll be able to domesticate these critters so they’ll be able to live in domestic bliss with the rest of us. Apps aren’t feral if they work seamlessly with the big EHR and other core systems. Perhaps we need a concept similar to the Turing Test. In 1950, Alan Turing proposed that a machine would truly exhibit intelligent behavior if it could generate human-like responses in a conversation. In other words, if a person is “talking” to a computer and doesn’t realize that there’s not a human on the other side of the screen, the program is exhibiting intelligent behavior. I propose a similar sort of exercise: if a user doesn’t realize that they’re interacting with an app as they make their way through an EHR workflow, then the app is integrated and interfaced well. However, if they see different formatting, if they need to re-enter information, if it seems “different” than the rest of the system, we’ve got ourselves some more feral apps.
What’s an executive to do? MIT researcher Joe Peppard has an option: get rid of the IT department. In short, Peppard sees innovative companies pushing IT experts into the various business units so they can become one with organizational goals. As long as governance and standards are strictly understood and followed, this can work. Clearly, someone needs to keep the hardware and/or cloud architecture going, so all of IT can’t be sent into the diaspora. Give the tech folks tools and boundaries and let them go to town. This means some of the apps will work just fine, while others won’t make the cut.
I’m going to guess that most tech-focused C-suite folks aren’t ready to give up their departments just yet. In that case, we need to go back to the basics: app rationalization. Find and catalog the applications in your system. If you find any that aren’t used or duplicate current core functionality, delete them (after informing and retraining users, of course!). Prioritize the software that is left and decide what can and should be interfaced into the EHR. Leverage standard interfaces and tools where available to avoid piecemeal work that is expensive to perform and even more expensive to maintain.
If the future EHR is no EHR at all, small, focused applications will undoubtedly increase exponentially. We won’t call them feral apps; we’ll just call them apps. As long as they play by the rules, share data predictably, and serve a specific purpose, the future is bright.