This is part two of a 3-part series on designing future clinical information systems. Part 1 covers the importance of data models. This part covers clinical modelling in relation to process and workflow. Part 3 covers patient portals and the internet-of-things.
In this blog post, I want to talk about how we model clinical information systems and how communication between patients, professionals and services underpins all that we do in healthcare.
Essentially, my arguments are:
- It is easy to see information technology (IT) as a product to be deployed: “drop it in and all will be well”. This isn’t true. Instead, IT should be used to support existing workflow and planned changes in that workflow to improve patient care. You need to therefore understand workflow.
- This boils down to understanding how we work in teams and how those relationships between people need to be modelled within any computer system designed to support healthcare.
Healthcare is all about communication: between patient and the team and between team members and the services that we use. The communication may be a patient phoning us, but it is much more that that. For example, the communication from the laboratory to us on the ward relating to the results of a blood investigation such as a renal function test or a full blood count, the discussion I have with a colleague about the most appropriate next step or my request for that MRI scan of the brain sent from my clinic this morning.
However, it is easy to forget and instead see technology as an answer itself. As such, we end up with a read-only portal to which I login to see a list of patients on the ward, a list of pending outpatient referrals and a chronological list of investigations for that patient. Such software has been created in response to a requirement such as “allow the professionals to see all of the results”, which seems like an entirely reasonable statement of the requirements.
But has that requirement been correctly scoped?
Poor scoping and the mismatched model
We need to step back and consider all of the information flows that exist, and particularly note the difference between “push” and “pull” communications. A “push” communication is a message that you receive as an active process : a letter is posted through your letterbox, a result is placed on your desk, the laboratory phones you because the haemoglobin is very low. A “pull” communication is something you fetch yourself : you go and read the noticeboard, you look through a list of results on the computer, you look through the notes to find a filed letter.
Historically, information technology in healthcare has adopted a “pull” model for end-users because there was no practical way of offering “push” notifications. This is an interesting paradox because at a technological level, most health enterprises have used “push” messaging (HL7) to integrate different systems within their architecture. There are many reasons why end-users have missed out:
- How could a system stand any chance of sending a blood result to the right person when, as designed, no computer could work out to whom to send the result? The request was made on paper, with an illegible name for the consultant, and no way of knowing which professionals worked in which team.
- How do push notifications work when ward computers are used by multiple users, many of whom move around every few months? Users did not carry personal devices.
And yet so many processes are predicated upon a “push” model, in which the receipt of a communication (a request or a result of a test), is an integral part of the workflow of a service. The team need to know the result of the blood test in order to send the patient home; a delay in getting that blood test results in a late discharge and a consequent effect on hospital bed efficiencies.
Nevertheless, I still get a lot of “push” notifications: my office is cluttered with paper records, post-it notes and a paper inbox. Similarly, I have NHS email with an electronic inbox that fills up with alarming rapidity with stuff for me to do but none of those emails end up linked into the patient record and are not visible to anyone else in the team.
Just as email is not designed as a system to manage workflow, these different systems are not joined up and do not support me in my care for patients. Most of us set-up workaround systems that mean that when we sign off typed letters, we get the notes and can check the results.
The systems I have to use don’t support the clinical processes I need in order to provide safe, good care. I have solutions that have been poorly scoped, poorly thought through and a mismatch between reality and the implicit or explicit model underlying those solutions.
We need help!
As the examples above demonstrate, I now receive a variety of healthcare information via paper, traditional email, and existing organisation-provided and national all-Wales portals. I also receive messages within my own homegrown electronic patient record system.
Paper post-it notes and my in-tray on my shelf do not support modern ways of working and timely collaboration of patient care, but at least there is no mismatch in the process. I request something, the result is posted back, an administrator bundles the result with the notes and I can deal with it. It is a workflow that is generally safe, if not rather old-fashioned.
My health board turned off paper reports for laboratory investigations. I currently receive no notifications about results, whether normal or abnormal. It is left to chance, unless I make a habit of always checking results whenever I sign off letters. This is a process model mismatch. I have to login and manually check results for patients under my care and there is currently no way of knowing that someone has dealt with a result. Now we’re starting to fix this as part of the Welsh Clinical Portal project within NHS Wales but there is more work to do.
In the PatientCare EPR, I built a model for rapid team-based, patient-linked electronic communication. While not perfect, it builds in a task-manager so that users can track what they have and have not dealt with. At the time of writing, users have sent 57,412 messages between each other with 45,743 explicitly linked to a patient record. Users now send over 1,000 messages per month to one another.
As the graph shows, the vast majority of messages are sent by administrators and by specialist nurses.
There are many different ways of supporting team communication and it is important for users to be able to send messages from lots of different contexts.
The first context is the software’s encounter wizard, which can be used to record clinic encounters, ward reviews or telephone calls (or any other user-defined service-specific type of encounter):
Here you see an administrator recording encounters against two patients. Those encounters will be recorded in the longitudinal record for that patient automatically. For each encounter, a user has the option of sending a message to a colleague. As such, in one click, the user records both an encounter with the patient and informs someone else of the need to do something. Once created, at any time a user can see a list of encounter. Users are able to filter the list depending on a range of different characteristics.
Of course, we can also see a pure list of the messages for that patient, irrespective of whether an encounter exists.
And we can create a message directly from the patient’s record:
Users can choose whether to receive an email notification about secure messages received. If all our users had their own personal handheld devices, a push notification would work similarly. In addition, within the PatientCare EPR, they have a simple inbox functionality to see their unread messages:
And to facilitate task management, messages can be flagged as complete:
The most important feature is that the contents of the communications are available to all members of the team looking after that patient, because it is recorded within the patient record.
A model for the future
Importantly, patients and users are explicitly linked to one another via the concept of “episodes of care” and “user registration”. As such, the system supports a finely-grained security model in which we can vouch that a particular health professional has a direct-care relationship with a specific patient.
For our services for long-term health conditions, the episode is lifelong as you would expect. For more acute services, such as our liaison neurology service, the system closes episodes after a custom defined period (e.g. 3 months). At any point, users with the correct permissions can themselves can register patients to a service.
As a result of this information and process model, the software is a fine abstraction of the real-world, making it more likely that it can be repurposed for future needs. This approach creates systems that have longevity.
Given this modelling of real-life processes and communication, it is easy to see how dealing with communications from patients could work. Rather than communications being sent to an individual health professional, who conceivably may be on leave or unable to respond, building a process and information model that mimics real-life offers the potential to build true team/patient communication. Likewise, the same model works for data from the patient’s own devices, whether they be home-monitors or wearables.
Part 3 of this series covers patient portals and the internet-of-things.