To Integrate or Not Integrate…. That is the Question.

This audio was created using Microsoft Azure Speech Services

To turn a phrase from the Bard, whether ‘tis nobler in the hospital system to suffer the pain and complication of non-connectivity or to take up our programmers against the sea of data and by connecting them make them work for us.” Alright so it is a bit corny but I was watching a production of Hamlet the same day there was a major discussion surrounding integrated data in a hospital and there are some parallels to the stories.

Building Blocks with LegosThe challenge Hamlet faced was the benefit of living or the alternative. What we have as managers in healthcare, while not nearly as dire, is to see if it is better to have systems combined or separate. I would pose that we are better served by connected systems but only if connected in a way that improves our operation. One might sense that any step towards integration is a good thing but therein sits a danger that can both increase costs and decrease effectiveness. The business case for pursuing integration must bring a positive result and align with the overall operation and service strategy.

In healthcare, goals can range from improved patient satisfaction to cost reduction but always with an eye on Joint Commission or DNV guidance. For Example, integrating the Building Management System (BMS) with the Admission/Discharge/Transfer (ADT) system so patient rooms are properly heated and cooled based on occupancy enhances the patient experience but also reduces direct energy costs and indirect costs such as maintenance. Another logical integration would be to connect the RFID or asset tracking and security systems not only to reduce theft but also improve worker safety. Both of these examples have been implemented at many hospitals and there are pieces of each that have a dollars and cents component but in addition a component that is non-financial. Which is the greater motivator? In short, the answer depends on your hospital, its management, its goals and its patients.

Integration Image

This sounds all well and good, right? But what if, like so many hospitals, you have systems purchased over many decades and from various vendors. Is it even possible to have conversations between these disparate systems that make sense and are cost effective? The short answer is yes but the basic building blocks must be in place. HL7 protocols already exist and there are applications in place to transfer data between ADT and BMS systems that provide useful data interchange, meet HIPPA standards and are straight forward to implement. BMS and security systems can already integrate using BACNET or MODBUS . Integrating an RFID or asset tracking system uses that same language structure. So if you have these basic building blocks in place, you’re partially down the path of integration.

The art comes next and that art is determining the best solution taking into consideration how a user will access the combined data, use the data, report on the data and update the data. It also requires an understanding of data storage as well as having systems in-place that can transport and “crunch” this large system of bytes to develop timely and actionable information. This is where having a trusted Technology Integration Partner who understands the healthcare operational system from a user, developer, implementer and maintainer perspective will help to lead an integration success from design through end-use. Too often a “go–it-internally” mindset, while saving some costs, creates major issues in the long term. We can simply look to the ACA enrollment system as a prime example of integration malfunction.

Looking back on Hamlet, that is what he needed, a trusted guide to help him successfully navigate his dilemma. Integrating operational and facility systems for maximum effectiveness also requires a trusted guide that understands, knows and has proven experience combining data, operational and facility systems. Find such a solution architect and you will be on the path to integration success.