It is highly unlikely that your hospital or trust has no IT whatsoever. Likely, your organisation already has dozens, if not hundreds, of healthcare applications and solutions. Unfortunately, all of these systems are probably not truly integrated, which can make it extremely difficult for medical teams to get a single, unified, and up-to-date summary of a patient’s condition and ongoing care processes. Since medical teams have to work with several applications, important clinical data can be highly fragmented.
Your organisation may already have an IT strategy set up, and is striving to become paperless. But, because this process – or, as it turns out, this journey – to become paperless is very complex, and there are no known or widely accepted guidelines for you to follow, it can be really difficult to clearly map out the kind of journey which ultimately leads to a successful transformation into a truly paperless organisation.
And, what is your long-term plan for all of your already existing apps, applications, registries, and processes? Are you even familiar with all the apps that are currently being used in your organisation? And all the processes that are being put into effect on a daily basis?
Finally, what about your people? Are they on board? Is your vision completely clear to them, and is everyone working and focusing just on the things that will lead to digital maturity and a paperless environment?
The fact is, you can’t do this transformation on your own. You alone can’t solve all the challenges and provide all the answers. You need to rely on your team as well, and make full use of their brainpower, experience, and motivation. So, don’t just go and buy the biggest healthcare IT suite out there before you first define your vision and strategy, find out what you really want and need, and set up a transformation team that will be fully aligned with what you want to achieve.
Then, you need to critically evaluate all existing healthcare IT solutions on the market, and make sure that they can support your healthcare organisation and the way you expect it to run. You probably don’t have all the requirements needed by all speciality areas, wards, and care settings, nor do you know what they will need in the future. So, don’t you think that without knowing exactly what you need, just buying the biggest suite out there is probably not the best idea? Buying a “mega suite” without all this information and limited ability to quickly adapt to your organisation’s future needs is basically like rolling the dice.
It would be much more sensible if you could set up the infrastructure which would support the gradual development and rollout of modules, apps, dashboards, and other components based on current and future possibilities regarding: your needs, technology trends, and your financial capabilities. But, for this you would need an IT architecture that would support your ambitions, and you shouldn’t have to wait years for your feature to finally be developed.
So, the question is, how does one go about obtaining healthcare IT that supports innovation and agility on the long-run? Based on my experience, it all comes down to clinical data which should be stored in life-long, structured and vendor-neutral clinical data repository. This creates the foundation for a health data platform which allows for the creation of an ecosystem of applications.
So, wherever you are in your journey to become paperless, make sure you set up a centralised vendor-neutral clinical data repository with the goal of having all patient-related clinical data stored centrally, for the life-time of a patient, and independently of any applications.
Then, you should identify some of the key clinical concepts or information which could currently be stored within different applications, but are highly valuable for your medical team members – usually this concerns allergies, conditions, lab results, discharge letters, and some basic observations. Luckily, all of this data is usually already exchanged through your integration engine, but the issue is that it is stored in different apps, making it hard to easily see all of the relevant details of a patient in a single portal. Simply by routing and storing all this clinical information to your newly set up clinical data repository you can easily set up a physician portal that will suddenly give medical teams quick access to a simple but centralised patient overview.
Our experience has shown that by doing this you can quickly gain the positive support from your team, meaning those who will need to use the system. This then allows you to start looking for the next application to develop on top of your existing platform. For this, you will need to find a use case that is somewhat independent from existing solutions, but at the same time provides significant value for medical teams. One such module is medication management, since it has a noticeably positive impact on patient outcomes, while also leveraging the clinical data that is already stored in the newly set up EHR, such as allergies, medical conditions, body weight, height, INR, blood glucose, and more.
At this point in the process it would make the most sense to integrate all the remaining diagnostic units, as well as your core EMR system, so that all this clinical data is always feeding directly into your health data platform, and gradually building a more and more comprehensive and centralised electronic EHR record.
Storing more and more clinical data in your new EHR makes it possible for you to start developing apps which offer medical teams intuitive, comprehensive, and condition specific patient views. You could then make this information available on all platforms (PCs, tablets, smart phones, etc.) so that medical teams would then be able to easily access patient information in any relevant context – no matter where they are.
By doing things in this way, you will have already provided significant benefits which were lacking in any previously existing and fragmented solutions. You will have offered care teams an easy way to look at patient data, all from within one system. And, without having had to change any of the original underlying processes, everyone would then be able to check labs, documents, measurements, conditions, allergies, and possibly even prescriptions within a single physician portal, accessible from any platform, and all with a single login.
And how convenient is that!?
Imagine that with this approach you have now set up some very solid foundations which support the gradual development and evolution of your healthcare IT solutions. Basically, you have an infrastructure that supports a bi-modal approach: you have your existing core modules running as they were (mode 1), while simultaneously having a digital health data platform which enables you to develop an ecosystem of apps from different vendors, quickly and accordingly to your needs and the maturity of your system (mode 2). We call this the Postmodern EHR.
But, what’s even more important, you will have made sure that all clinical data is stored centrally, independent of the applicaitions, for the life-time of a patient, and in a vendor-neutral format. It will always be readily available through the platform to every app within the ecosystem.
So, where to go next? Based on my experience, supporting nurse workflows is crucial, since nurses welcome good IT solutions that help make their work easier, safer, and more transparent, and ones which also free up their precious time, allowing them to devote more of it to caring for patients. Then, you have to start addressing the areas which engage clinicians – you need to evaluate order comms (labs and radiology), applications, and processes. This is something I will explore in more detail in my next blog, where I will share my experience of transforming eOBS and order comm processes, and explain what it took to get the doctors to create lab and radiology orders by themselves.
As you can imagine, it took a lot of energy and innovation to make this ordering step so simple and intuitive that doctors actually started to do it themselves, and began to see the value in it as well.