Trusted Applications: an Interoperability Parable

Imagine you have to go to the Florida Blues Deerwood campus to pick up a copy of your significant other Sam’s claims history. (I am picking on Florida Blues because Deerwood is a compound, you pretty much have to drive there, and there is an only-friendly-to-cars guard gate. What follows is fiction, not what actually happens – I don’t think there is even a customer service office there. : )

You drive up to the first gate. The guard asks you “what kind of ID will you be presenting today, and from whom was it issued?”.

“A driver’s license,” you respond, “issued by the great state of Alabama”.

“Fine”, says the guard, checking his acceptable ID chart, “drive on to the next gate” (feeling like you are in the drive-thru at McDonalds about now). If you had said “my Rotary Club membership card”, the guard would have replied “I’m sorry, but we don’t accept that form of ID. Please use that drive to exit.”

Now, at the next gate, you hand your driver’s license to the guard. She carefully compares you to the photo on the license, then steps into her guard shack and validates it (like the TSA agent in the security line at the airport.).

Returning your license, she asks “what is the purpose of your visit?”

“Picking up my partner Sam’s claims history.”

“Why?”

“To what-if plans for open enrollment.” (Going old-school.)

“You will need a signed consent form from Sam”.

“Here it is,” you reply, handing it over. The guard validates the consent form, and creates you a temporary query pass.

“OK”, says the guard, “here is your pass. Don’t lose it , or you will have to come back and get another one. It only permits you to get Sam’s claims history. You will have to present it at the next gate. It will expire in 30 minutes. You can come back here before then and get it renewed if you need more time. Please drive on to the gate marked ‘Queries'”.

At the gate marked ‘Queries’, you present your temporary pass. They validate it, take a copy, and ask you to pull into spot number ‘3’ and wait. (Still feeling like the McDonald’s drive-thru.)

A Florida Blues query runner takes your query pass, and goes to the Security office. The officer takes the information written on the pass about your identity, query, intent, and consent, and looks up the rules that apply. They discover that Sam has a standing rule that no one may access their mental health claims history unless they provide explicit consent. The officer creates an access authorization for Sam’s claims that excludes mental health claims and gives it to the runner.

The runner drops off the authorization at the Claims Query Processing office. They verify that the request is intelligible. It is, so they translate it into a SQL SELECT statement. They query the database, and translate the result into an Excel spreadsheet, which they put on a thumb drive. Then they call a reply runner and give them the thumb drive to return.

The reply runner takes the thumb drive back to the ‘Queries’ gate (where you are patiently waiting in your car) and gives it to the guard. The guard walks to your car, hands you the thumb drive, and points you to the exit.

Now for the ‘parable’ part of our story. At no point did Florida Blues need to check your car’s make and model against an approved list. They did not have to look up your license plate number or VIN. As long as the car functioned to get you through the process, none of that mattered at all.

Of course, they did have trained dogs sniff your car for explosives. And they had a guard carefully examine the undercarriage with a mirror looking for IEDs.

But the farthest your car got was the ‘Queries’ gate, where you – and your car – waited while your request was being processed. If your car had exploded, the damage would have been contained.

Now imagine that was all automated. Your car is the software application you are using to access the Florida Blues Blue Button 2.0 API to make the query.

The software application is a tool, just like a car, that conveys your will. In the car your will is corporeally contained, and transmitted by voice, your credentials physical. In the software application your will is virtually contained, transmitted by HTTP/TCP/IP over the Internet, your credentials electronic.

But it is your identity, your credentials, your intent, that are required – not your application’s. Legacy standards and implementations conflate them. The onus is on Florida Blues to make sure that no nefarious application you might inadvertently use can hurt them – the explosives dogs are the Web Application Firewall, the machine-learning-powered bot behavior detectors, the buffer-overrun detectors, and so on.

The consumer’s choice of application is made independently. Just like with a car purchase, a sensible consumer needs to carefully check its features, its reliability, and its performance. A sensible car consumer vets their purchase carefully with Consumer Reports, and MotorTrend, and Edmunds, and TrueCar.

And remember, stretching our poor car metaphor near to breaking, safety features are legislated for cars. They all have seatbelts, airbags, bumpers, child restraint anchors, standardized placement of headlights, tail lights and turn signals, and so on. Consumer privacy safety features for healthcare applications are already emerging – please see ‘Informational Identities and Personal Privacy: Persistence and Use‘ from my Informational Identity series for details – and will continue to emerge. That HIPAA ends at a covered entity’s border is a function of its being a horse-and-buggy law in a Tesla world.

In the interim, woe betide the healthcare API owner who discriminates against an app based on their perception of its quality – seeking not to have their reputation smeared by association should that app not protect their users’ privacy. They would be guilty of information blocking.

Ultimately, a registry of vetted applications is not logically necessary for interoperability. But consumers would clearly benefit from one. They will emerge organically, like Good Housekeeping Seals of Approval.

Stay tuned.