“Paper is one of the most hazardous substances in a hospital.”

“Keeping paper over EHR is like keeping horse and cart for fear of theft of cars.”

“Software is eating the world.”

The first two are informal quips from colleagues on Twitter, but as I am going to argue that they are wrong, they shall remain nameless!

Many of you will recognise the last quote from Marc Andreeson. I truly believe that software is critical to the future of healthcare, in supporting both patients and health professionals in their respective roles.

As a professional, I want information systems that support me in my work and facilitate changes in working practices that mean that I can do my job more effectively and to the greater benefit of my patients. If I have electronic records wherever I am, I can have a consultation at any time, perhaps in person but perhaps not. With paper records, such responsiveness is not possible; who is going to fetch the notes from the archives?

As a patient, I want information systems that support me and facilitate changes in working practices that mean that I can do my job more effectively.

Paper isn’t all bad… it has workflow built-in

“Dear Doctors, Can we stop printing out the electronic discharge summaries from the neurology day unit now that they are available in Welsh Clinical Portal?”

“No. Please keep sending them, as otherwise we won’t know when the patient has been admitted and has had their investigations.”

It is very easy to design clinical information systems thinking about how the system will look and work and build a product that will solve the perceived problem. I have written before about how we need to be careful on framing our problem and scoping the solution to that problem.

Many hospitals now generate discharge documents electronically. They solve a problem: namely transcribing medications and then creating a discharge document. When a patient is discharged from hospital, a communication should be sent to ensure that the patient’s general practitioner is aware of the admission and what happened. Just like a referral to hospital, it is a handover of care from one team to another made up of a diagnostic synthesis and chain of reasoning supporting those diagnoses including results of relevant investigations together with any procedures or interventions and their complications. We used to hand-write these and then the fourth (illegible) copy would be sent to the general practitioner. Later, and sometimes months later, a team member might dictate a more formal summary.

But my colleague above, in asking for the electronic notifications to be printed, has identified a missing need that the new electronic discharge system fails to solve: a notification to support his workflow in his ongoing care of the patient.

Digitisation

Paper is not the most hazardous substance in the hospital; it is a key enabler of many processes and workflows with its use and subsequent benefits not necessarily explicitly understood by outsiders. A benefit of paper is that it allows end-users to rapid prototype a system that support a business workflow when an alternative is either not provided or impedes productivity. In essence, workflows built upon paper were the original “feral” systems until such time that they were replaced with a more formal system or became that system by virtue of its ongoing use.

We all have these “systems”. My secretary places notes in my in-tray and I process them. It is a workflow, albeit a rudimentary one:

The problem is that these “feral systems” may not be acknowledged explicitly during information technology deployments - the workflow may be understood by all who work there but never explicitly expressed - it is tacit knowledge.

Software should be “eating healthcare”

I have previously written about the importance of software in healthcare.

Digital transformation is more than simply replacing a single paper-based process with an electronic one. Instead, one needs to understand the workflows and processes that are dependent on the process you are examining and ensure that these are included in your design for a clinical information system:

1. Start with data and the structures that will be used to hold that data. Data, particularly in health, will be immutable as it reflects what was done at that timepoint and changes in data should be modelled accordingly. Prefer open standards, adopt published information models and bind appropriate terminologies and data dictionaries so that you can provide semantic interoperability with partner software.
2. Examine the workflow and processes that are dependent and create explicit process models; there may be many such processes for different services with different perspectives on the same data. Different professionals need different views of the same data. Consider how such models can be flexibly configured at runtime using rule-based engines written in the language of the business, rather than hard-coding processes.
3. Acknowledge that, at its most fundamental, healthcare is about communication. Software that ignores human factors will be doomed in the pit of real-life/model mismatch. Build systems that improve communication between and among the healthcare team. Create shared records but understand there is a difference between notifications and alerts and reading a medical record.
4. Use the design of user-interfaces as a useful part of an exploratory process to understand data and workflow, but build a layered architecture with separation of data persistence, business/application logic and user interface. Consider user-facing applications to be minimal, thin-wrappers around more substantial services forming a “platform”, providing different perspectives for different users of the same data.
5. Plan user-facing applications for multiple devices, even if you don’t intend to create different versions now so that no-one inadvertently loses separation between business logic and the user interface. Make user interfaces “smart” in the way that they help the user but “stupid” in that they delegate their logic to underlying business services.

Mark