Improving Patient Outcomes with FHIR APIs

I spontaneously thought of a new way to express something in my recent APICON session. I want to capture it, because it’s important.

The example (and prop) I used was for healthcare.

I have a Bluetooth enabled blood-pressure cuff.

I can take my blood pressure, and see it in my phone on both an app and the Apple Health App. The Apple Health App supports FHIR (an API standard for healthcare integration).

If I were “selling” to my care provider, let’s pick on Hospital for Special Surgery (which in my experience is not very special), their response would likely be along the lines of “we use EPIC, and EPIC support FHIR along with the appropriate security protocols, so we can do it”.

But they don’t. And they can’t.

The key observation that was new to me was that:

Every technical piece is in place to make this work. But it doesn’t work.

It’s worth considering the obvious question: why not?

The answer is it's not in place because it's easier to justify "no" than to ask "how can we do that?"

Common misconceptions expressed as reasonable objections

There are a three common objections, and I’ll answer them as I would if I were speaking about this:

First objection: there’s no business case.

Maybe yes, maybe no… Remember in my session, I shared a tweet from a doctor who was using his lunch hour to reach patients overdue for a blood pressure checkup. A highly trained doctor was hunting down patients and phone numbers. Have you ever seen doctors type?

Let’s pretend that there isn’t a business case. I have long believed that we are using the wrong things to evaluate projects. I had a customer who had customers asking them for an API to their solution, and it was only when the largest customer threatened to leave that they “scrambled” to create an API (our best work is done while scrambling, right?). When I asked them if that meant they’d now do APIs for other products, their answer was “only if customers threaten to leave.”

Their business model included upsetting customers so much that they’d threaten to leave. Would you even know if a patient started visiting another doctor's office? Pause and reflect on that.

Which leads us to the second objection.

Second objection: it’s not a priority.

This is the best objection of the bunch. And, why? Well, there are a lot of things to do, and only a few things can be at the top of that list.

In fact, my very argument of how much software is needed in today’s world implies that if we do things the way we’ve always done them, very little (relative to the need) will get done. This “blood pressure use case” would stand in comparison to upgrading the patient record system (EHR), or making sure there was enough bandwidth for patients who are using more mobile devices, or doing patient intake over a tablet.

Clearly the blood pressure use case is not as important as patient intake (designed to streamline the patient experience, which of course is really code for reducing admin support… reducing the need for admin support because patients do their own paperwork has a clear ROI by the way… of course it has a better priority when a doctor can just “grab a phone number and call when they have five minutes”.

The priority question gets more complicated, at least in the US. If I take my own blood pressure and it syncs with the EHR without any doctor involvement, how do they bill the insurance company? They can’t. However, if the patient comes in or does a telehealth visit, they can bill the insurance company.

Often, not always, the prioritization for patient experience comes with the caveat “assuming patient experience aligns to our business model”.

Which brings me to my final objection, included because I hear this so often I want to scream.

Third objection: you’ve described a solution for iPhone owners, what about Android?

If we can’t help patients with Android, we don’t want to help patients with iPhones. Ok, well, that's how I internalize this objection.

Aside from the fact that I’m sure Android and Google have their own solution (whoa, talk about timing! This article from just yesterday talks about Google’s latest attempt at personal health records).

But, if you do one thing for iOS and another for Android, the implication is you need a third thing for the web… that’s three things that you have to do, when if you just do something for the web you can get away with doing one thing. IT can feel that they’ve done their job, and move on after checking off that box.

This is a systemic challenge

This is small thinking and completely opposite the way successful companies, companies that deliver a great experience to their customers/patients/employoees think these days. In fact, I’d argue that it’s this same thinking that’s causing doctors to burn out at an extraordinary pace. This trend in doctors burning out due to health IT use predates covid, just to be clear. And, has been consistent from 2018 (the date of the previous link) into late 2019, where a study showed that physician burnout was tied directly to EHRs.

Back to the point

The point is that the pieces are in place and yet still this doctor is calling patients during his lunch hour, after digging around to find phone numbers of those who need to be called.

It's not enough to think about APIs as the solution, because in my case above the APIs literally exist, as do the products that can take advantage of them to improve patient outcomes and completely reinvent the process.

What's holding them back?

Technically, they're held back by the problem of scale. It's not about doing this one process improvement. If they tied in remote blood pressure cuffs to the EHR, I'd find three more solutions that they didn't get to deliver. Read more about the technical details that impact scale over at Mulesoft.

They're not held back by the APIs or the tech, but rather by the lack of a platform in place to scalably and securely solve problems with software using data, events, and processes that are locked in enterprise/corporate silos.

Emotionally, they're not putting themselves in the customer's shoes. Whether the customer is a patient who can have their heart health more closely monitored, or the doctor who is overworked... there's not a lot of empathy for users once a solution is in place (and the solution is come to the office and we'll check your blood pressure).

Financially, they're not measuring the right things. Sometimes there's a good reason. Not being able to bill someone (in the US it's the insurance company) for a service is a really tough problem. Though, with the world going to subscriptions, maybe if you have high blood pressure, the insurance company could use a subscription billing model while blood pressure is being monitored?

Just because they're not technical problems, doesn't mean they aren't hard problems AND doesn't mean we don't need to solve them. However, in the context of APIs and the benefits that APIs promise, realize that it's not only about whether you're using FHIR or XML. Or only about whether you're using Amazon's API Gateway or an on-premise solution. It's not only about your security model.

It's about your business.