this article first appeared on https://www.linkedin.com/pulse/fhir-up-oven-promoting-interoperability-turning-apis-pies-king/
The American healthcare system is increasingly worried that patients might want their health records in a troublingly new and scary form: digital.
Despite the billions of dollars invested into arming the nation’s healthcare industry with electronic health records, very little of that data has turned into actionable, patient-centered data that regular people can use to manage their health and wellness. A vast, tangled mess of EHR vendors and software systems still refuse to talk to each other in any truly meaningful way, and thus the government has stepped in to grease the wheels on health data exchange.
Rules proposed by Centers for Medicare and Medicaid Services and by the Office for the National Coordinator for Health Information Technology are ready to hit the street, and will require that hospitals and clinicians meet a new “Promoting Interoperability” rule to maintain their payment levels, which includes making patient data available to the patient in the application of their choice via an API.
This has a lot of people on edge, because they don’t know what an API is, they probably don’t want one, and they certainly don’t want to get sued for having the wrong one give the wrong person the wrong health data.
In an effort to combat this, I will attempt to calm some nerves by describing another extremely complex content delivery system, namely, your local pizzeria.
Dear hospital or clinical practice,
Imagine for a moment that you are a delicious pizzeria. You have an elegant restaurant, white tablecloths, highly trained staff, and a wide menu of pizza and other delicious Italian dishes. Hungry people enter your restaurant and seek these items from you, often without knowing how much your pizza will cost until a month or two after they ate there. But that’s for a different story.
So come they do, and they eat, and they leave. If they have issues with the service they can talk to your highly trained staff. If they have questions your friendly staff can find the right person for their needs, maybe someone who knows wine, or cheese. Your full menu is on offer, and you control the customer experience from the moment they walk through the door until they leave. Occasionally the health department comes by and makes sure your pizza kitchen (where you keep all the ingredients) is healthy and secured from things like rats and mice nibbling away at your data. I mean pizza.
But, you come to find out there’s a bunch of people who don’t want your highly recommended pasta dishes, or an espresso, or a dessert, they just want one thing.
Pizza.
To go.
You Can’t Make Pizza Pie Without “API”
Now, you could allow these would be diners into your elegant restaurant and disturb the staff and your diners by allowing takeout orders but you and I both know this will disrupt service. So, a choice many restaurants make is to open a window around the side of the restaurant, offer a smaller menu, and let people just walk up and take their pizza and leave.
Why don’t these people want to eat their pizza inside your restaurant? We may never know, but we do know this:
- The pizza comes from the very same kitchen under the very same care and attention all your food receives. Your Chief Pizza Officer is still in charge of what goes out.
- You retain all control over ingredients and what’s on the takeout menu. Of course there are national standards that you simply have to make available, like pepperoni, sausage, ham and pineapple… but you’re going to offer these because you know that’s what everyone wants.
- You are not going to offer custom menu items that include hard to get ingredients or ingredients you don’t even have. That would be silly.
In fact the only change is that when the pizza is ready to eat instead of going out the double doors into the dining room, it takes a slightly different path to the takeout window.
Once the customer takes their pizza from your takeout counter, they’re gone. They are no longer your problem. They can do whatever they want with that pizza. They can take it home, look at it. Take a photo of it. Post it on Instagram. They can share their pizza with whomever they like. Because it’s their pizza.
So, you’re a hospital or a clinical practice, and you are worried about these apps and APIs and what people might do with their pizza once you give it to them. But you will not be allowing the world to walk into your kitchen. Instead, you are going to need to open a carefully monitored API, I mean takeout window, and let people order from a slightly smaller menu.
You can close the window whenever you need if there’s a problem, and if anyone comes up and asks for something you don’t have, let’s say fish tacos, you simply look at them with a blank stare and point to your menu. This is all you can offer, this is all they can receive. And you’ve got receipts for everything, so you know exactly what went out and when.
So then how do you know if this is the right person getting the right pizza? Can’t anyone just walk up and take any pizza?
Imagine if someone, instead of walking up to your takeout window decided to ask DoorDash or GrubHub or their cousin to pick it up? Well, DoorDash uses the very same process your customers do, and your customers have a very carefully managed set of credentials to prove they are who they say they are.
Hungry Person asks DoorDash, DoorDash asks you, you give pizza to DoorDash, DoorDash takes it to your customer. It’s like a trusted pizza exchange framework.
DoorDash can’t get the order for pickup until your hungry customer has demonstrated they have the correct credentials. DoorDash never sees these credentials, but they use an international standard to allow hungry people to order food from their favourite pizzeria.
In your case if a health app developer makes an app that allows someone to download their pizza, they don’t see their password, they just see that they went to your portal and got a token for access, and then authorised the app to do something on their behalf. They don’t have any higher privileges, they can’t walk into the restaurant like they own the place, go into the kitchen and start grabbing food. All they can do is go pick up the very same pizza they ordered.
Now, you may feel you need to educate your customers a little on what to do with their pizza. It might be sensible to say something like “don’t leave this out where anyone can find it, they might eat it”. That’s your call. You made the pizza, you probably want them to enjoy it in a safe, clean, harmless manner, and that’s noble.
But if a patient really wants to take their pizza and share it, that’s not your issue. It’s their pizza. They’re not governed by the health department, they’re just a regular consumer. They can give pizza to absolutely anyone they want to, there’s no law against it. You might think there’s an arcane law called “PIZAA” that prohibits sharing pizza, but in truth that only applies to people who sell food, not people who eat it.
So, in short, an API – or application programming interface – is a set of functions and procedures allowing others to create applications that access your data, based on a very careful set of rules and procedures of your choosing. Or, more likely, the builders you hired to install the takeout window. Which in your case is your EHR vendor.
Twitter has an API. So does Google. So does your EHR. In fact so does Domino’s. It’s just a way for those companies to say to a select group of carefully vetted developers “here, if you sign this paperwork we will let you interact with a small piece of our system and use this specific data”.
So, next time you hear “FHIR API”, just remember: you need fire to make pie.
Further Reading
- https://www.carinalliance.com/ – industry led standards alliance for consumer directed exchange
- https://www.healthit.gov/playbook/pe/ – patient engagement playbook
- 45 CFR § 164.524 – individual right to access protected health information
- http://build.fhir.org/overview.html – FHIR overview
