Let’s pretend it’s Friday afternoon. SuperCare Hospital’s integration engine has started to encounter issues with one of its interfaces, and as a result, all messages are sent to an error queue.
This continues throughout the night and most of Saturday. By the time the issue is discovered and resolved, the server that the integration engine is deployed on is dangerously close to running out of disk space, and all the interfaces have severely reduced throughput.
Everything eventually recovers, but because the slowdown happened in one of the busiest periods for a hospital, huge volumes of messages are queued, and the backlog in some interfaces takes up to a week to clear. This is not a far-fetched scenario; it’s something I’ve witnessed more than once.
Now let’s take a look at some of the consequences of the slow down.
Joe had a heart attack a week ago. He is discharged from SuperCare Hospital on Saturday morning. He takes a long list of medications home with him, as well as a discharge letter explaining how and when to take them. One of the medications is a blood thinner. It requires constant monitoring to ensure the dosage is still correct. The letter instructs Joe to make an appointment with his GP on Wednesday.
An electronic copy of the discharge letter is produced and sent to Joe’s GP, Dr. Young. The intention is for Dr. Young to follow up with Joe, and ensure he makes an appointment.
Because of the backlog, the letter only arrives in Dr. Young’s practice management software inbox on Wednesday afternoon. He reviews his mail on Thursday morning, and notices that he was supposed to follow up with Joe the previous day. Joe hadn’t yet made an appointment, so one is made for him and he visits Dr. Young later in the day. Luckily his medication requires only a small adjustment. It could have had a different and more serious outcome if the medication adjustment had not occurred.
Think about that for a moment.
Here’s another scenario. Janet has been admitted to SuperCare Hospital for appendicitis on Sunday morning. Remember, the integration-engine troubles have been resolved at this point, but there is still a backlog of messages to process, and no messages are being processed in real time yet.
The first thing that happens when Jane is admitted to hospital is that her details and the details of her stay are captured in the patient administration system. These include which ward she has been admitted to, the reason for her admittance, who is responsible for her care, and much more. This triggers a flurry of messages to be sent to various systems in the hospital—systems that operate the lab, the x-ray department, the kitchen, and the operating rooms, among others. It would also trigger a query to the National Health Database, retrieving details of allergies, warnings, and medical alerts.
Blood tests are ordered for Jane. This has to be done manually, as messaging to and from the lab-ordering system is backed up. The lab system has no information for Jane, so they have to be manually captured. The lab results usually appear on the patients record in the patient administration system as soon as they are ready, but today they have to be phoned through. The same thing happens when a scan is ordered for Jane. Manual steps are required to make the x-ray department aware of the request, get Jane’s details onto the x-ray system, and get the results back onto the patient record.
The hospital kitchen doesn’t know there is a new person in the ward, and so lunch doesn’t arrive for Jane. A medical orderly is sent to get her lunch. The kitchen captures her details on their meal-planning software.
Jane is scheduled for surgery the following day. The operating theatre needs to capture her details in their system because the message from the patient administration system hasn’t arrived yet.
Luckily Jane is awake and alert and has told the clinicians that she’s allergic to penicillin antibiotics. This information is stored on the National Health Database, but it hasn’t updated her patient record yet.
Acute hospitals are required to be operational 24/7. A medium-sized hospital admits an average of 150 patients a day. The manual effort I’ve just described would have to be repeated for each of these patients. Even if it’s just a few minutes per patient, that equates to hours engaged in something other than direct patient care, and honestly, I’ve only covered a few examples where real-time messaging is critical. The potential for delay and harm is enormous.
I know that a lot of the issues that are experienced by integration engines are due to the way the software has been deployed, or the interfaces have been designed and implemented. Healthcare integration engines are an essential requirement for hospitals to be able to rapidly exchange and acquire health data. These engines seamlessly integrate different systems and enable connected solutions which provide rapid, reliable, and scalable interoperability.
Most clinicians will never see how important a healthcare-focused integration engine is, even though they rely on it heavily, and it actively facilitates and can improve patient care.
So this is why a healthcare-focused integration engine is essential to a hospital’s core operations. Acute hospitals are required to be operational 24/7, therefore so is the requirement to seamlessly integrate different systems and enable connected solutions which provide rapid, reliable, and scalable interoperability.
