Postmodern EHR: Solving the feral systems dilemma

Tomaž GornikFeral systems are software solutions developed by individuals or groups to help with day-to-day activities. They are called feral (or “wild”) because they are used in addition to core IT systems, working around key system architecture – more often than not without the blessing of management.

I was first made aware of this expression a couple of years ago by Ewan Davis, who wrote a blog post about it stating:

“The hundreds of “Feral Systems” in an average large hospital represent a goldmine of knowledge and innovation that could be harnessed in the design of digital systems that really work, but as they are today they also create a massive technical debt and create safety, governance and reputational risks for the organisation in which they are used.”

In the last few years, through interaction with many healthcare IT executives, I realised not only the magnitude of this problem (all organisations have some – many several hundred), but also the dilemma they present – IT cannot manage the feral systems, but it also cannot live without them.

On the positive side, because they are driven by end-users, feral systems fill many gaps, are developed quickly, solve real problems and can also be very innovative. They often become essential for users to carry out their daily work.

But there is another side to feral systems. For one, lack of integration with core systems prevents sharing of data, requiring users to enter the same data repeatedly. Think about compliance and lack of governance. How can a CIO ensure these systems comply with regulation? In healthcare, security and data privacy are paramount and users demand availability and performance as well as access to data across applications. How do you do that if you have no control over how the systems are built? Also, what happens when the user responsible for the application leaves? In short, feral systems are often not built or managed properly and thus pose serious risks to organisations.

So how should CIOs approach this dilemma?

Let’s begin by looking at the reasons feral systems appear. Many times, the user has a need for functionality that is not supported by existing systems. The first step is often to talk to IT and see if they can get new features added to their current systems. Often this is either too costly, too late or not even possible, usually because it is not on their vendor’s roadmap. Since the functionality is very important for the end-user, they have no choice but to find their own solution.

Because they fill a very real and unmet need, feral systems will not go away. CIOs need to find a way to help build them in a controlled manner without compromising their biggest benefits – innovation, flexibility and speed of development. One approach is what I call the Postmodern EHR – a platform approach with a well-defined, vendor-neutral data layer and open, easy to use APIs and tools. Here’s how to get started:

1. catalogue the feral systems to understand how big the problem is. As mentioned, most large organisations will find tens if not hundreds of such systems.
2. define a strategy on how to let users build or buy these applications in the future and how to eventually migrate the existing ones.
3. select the first application. It should be an area which has eager end-users, will provide high-value and does not require a lot of existing legacy data. Inspecting the backlog is a good place to start. To ensure early success, choose an application which was planned or where a burning need already existed.
4. start synchronising data from your legacy systems. Administrative patient data found in ADT messages are the low hanging fruit and are usually necessary for any new application, so start there (hopefully you can subscribe to this data through an existing integration engine, otherwise you will have some work in synchronising it). Normalise this data into a vendor neutral format and store it in a data platform. Add clinical data like allergies, labs and vitals but only as needed by the first application.
5. use the APIs and tools to build the app. Use outside help if needed. Outsourcing the front-end, requiring the developers to use the common APIs and selected data models lowers your risk considerably. Developers can focus on the user-experience and nailing the usability and process aspects of their solution while delegating the data management part to the platform. This also ensures that the new data collected will be available for the next applications preventing new silos of data.
6. finally, roll out the app and make sure it is providing value before going on to the next one. Depending on the use case, this first iteration can be done quickly, in a matter of weeks ensuring early success and providing immediate value while setting the foundation for the future.
7. repeat steps 3 to 6 by selecting a new use case or replacing one of the existing feral systems

The Postmodern EHR concept is based on shrinking the core EHR and surrounding it with smaller, innovative, mostly cloud based applications and apps – very similar to the positive features of feral systems. Integration is easier to achieve since these applications are built on a common set of APIs accessing the same data. Low-code tools are used to build new applications quickly while the platform ensures the data is shared between applications and managed properly. And even if an application is retired or replaced, the data stays to be reused. Applications built on such a common platform thus replace the feral systems of today while at the same time keeping their advantages, offering a solution to the dilemma.