Best-of-breed and Big Box approaches to provider digital maturity

Ade Byrne, CIO at Southampton University Hospital, shares his thoughts on best of breed (BoB) integrators, EPRs and digital maturity ahead of hosting a dedicated Regional Networks Best Practice event in Southampton on 23 October.

How can best of breed hospitals best approach digital maturity, how can they solve the interoperability challenges, and how do they avoid running out of road compared to big box EPR solutions?  These are some of the big questions Southampton has been trying to answer in its GDE programme.

Some of us have been in this for a long time, in my case over 20 years, and not much has changed in some respects. At University Hospital Southampton (UHS) we decided to develop around systems that would talk to each other, and a common data model or enterprise architecture.

This strategy has stood the test of time at UHS and the benefits are clear to see in better patient flow, safety in things such as result acknowledgement, and now a drive for truly paperless working moving away from scanning towards direct input.

But BoB has not worked for every trust.  Why is it that many who have embarked on this way of working have seemingly run out of road, and are there lessons that can be learned to help them keep their project viable and in flight?

Obstacles of Best of Breed

It is fair to say that this best of breed approach has had its critics, but challenges exist however you try to digitise a hospital. The obstacles of BoB are clear around managing multiple vendor relationships, maintaining a workforce with organisational memory and technical skills, and technical integration.

Outside of that whatever approach may have been taken, issues of change management, affordability of infrastructure, standards of interfacing and coding data, new requirements and emerging technologies will all impact.

It could be argued that big box solutions to hospital digitisation are not so agile, requiring a high degree of conformity, and it is true they do seem to struggle to shake off legacy and carry a lot of technical debt. However, a more patchwork approach will have different levels of technology and this can be hard to manage.

I often wonder why the approaches are presented as a dichotomy.  I would argue that in order to be successful you need elements of everything. This will be more the case in the future as interoperability requirements will be stretched to allow patient pathways to intertwine more between the organisations and sectors. Those who have a good implementation of both a Master Patient Index (MPI) and integration engine will find they are better set up to take on these challenges.

There will probably always be departmental and specialist systems within hospitals, and these will require increased sophistication in interfacing, probably using a mixture of so called legacy HL7 and Fast Health Interoperability Resource (FHIR).

Rule of thumb

In my experience there is very little evidence that many of the specialist systems have been adequately replaced by an integrated suite. You will still find endoscopy, cardiology, ophthalmology systems along with pathology, pharmacy, PACS and many others.

The modularisation of code and growth in the integration capabilities of tools like Microsoft Teams, for instance, will mean that all applications will have to take information from an interface where they had previously expected a user to log in and use their software.

It seems there are certain rules of thumb and things that need to be done well in all models. The key problem with integration is just that, how do you put your data from your lab, your prescribing, your vital signs observations, into a place where the user and system can interact with them to suggest and in the future automate actions in real time?

In the past this would undoubtedly have meant a single database. Now new integration techniques mean that there are alternatives. However, a good base is definitely still required, and I would say this is rule of thumb number one. I cannot see how you can move from what I would call a bits and pieces strategy to one of interoperability where you will really achieve the required benefits. In this case, you will indeed run out of road.

The question for those advising organisations, everyone from central NHS alphabet teams to HIMSS and other maturity auditors, is how do you recognise and identify a bits and pieces strategy from a coherent strategic approach? I think the key differentiator is that you have to have a view on what future state you intend to achieve.

Achievable plan?

Is there a clear plan to get to the integration that will drive integrated and increasingly intelligent automated patient flows? And is this plan achievable? Is it actually plausible and can it be supported by the local teams and technologies currently in use? If this is not the case then alternatives must be explored, as you are potentially wasting time and money.

In an example from my own trust, I often use results acknowledgement as a lesson. To an outsider its often assumed that investigation results go back to the requestor. Wrong. In the hospital juniors are mostly picking those up in consultant-based teams, and of course they go off duty, and then at night the whole pattern of the hospital changes, with wider areas being covered by hospital at night teams. Meanwhile, in outpatients, the consultant will usually have results directly to their queue. The consequences of not getting this right are dire, and it is well known that patient handover situations are a critical risk area.

All of this means that if you regard an order to a lab or endoscopy as a simple request and response mechanism, then you will never properly achieve a closed loop system. It means that the ordering and results systems need to take account of team working, and how these patterns change over the course of the day, and therefore need to be embedded into the task lists within the core electronic work processes of the staff. This is not easy for stand-alone systems, and if your design has not catered for this that is one example of a bits and pieces strategy.

Facing reality

Therefore, despite an interoperability model often being called “best of breed” (personally I don’t like the term) the reality is at least for now you’re going to have to have as much of that data in one place as you can. Many of us will have prescribing systems that differ across critical care, chemo in oncology, and more general ward-based prescribing. What happens though when you need to prescribe in one area, say theatres on a critical care system, but then need to administer in a ward area?

Is this a case for a single prescribing system across one administration area or should we be able to solve it with interfacing. The jury is out on this one but there are some standards being implemented (SNOMED and DM+D) that should help.

In Southampton we are still on the rails rather than the ropes, have not run out of road, and are an exemplar for this way of working. We are showcasing the work of a group of organizations taking this approach at an event on the 23 October.

There is still time to register and come along. You may discuss and debate, take away some ideas or you may decide the right approach is in fact a big box solution. Either way if this is something in your sphere of interest right now I would recommend you to come along.

Also there is a bit of further reading in a similar style in techcrunch.com from 2 months ago.

Book your place today.