[It is now June 2024, nearly four years since I wrote this post. Talk about a swing and a miss! In practice there are very few software applications actually using Patient Access APIs – not the tsunami I saw in my crystal ball. I need to do a post-mortem to figure out how I – and I was not alone – was so wrong, and if there is some inflection point looming on the horizon.]
I started my software career back in the 1980’s as temporary Christmas help working the customer service phones for a top-ten shrink-wrap software publisher. (The plan at the time was to establish California residency – which was easier back then – then go figure out a cognitive science program heavy on Heidegger with Hubert Dreyfus at Berkeley. Instead I fell through the looking glass and took a 30+ years and counting detour into building software.)
I wax nostalgic to point out that despite my current gig as an architect at a large payer, I have some sense of the impact of a high volume of software users, whether the software is delivered on a set of 5 1/4 inch floppies or an API.
We are not ready for the wave of consumer apps that is going to inundate our Cures-Act-mandated FHIR APIs in 2021.
This is not going to be an Epic app orchard app with a few hundred clinicians knocking on your FHIR door.
This is going to be thousands, tens of thousands, hundreds of thousands of accesses as your patients, your members, either hook up the consumer health apps they are already using to your APIs, or are seduced by the immediately-richer feature set those apps will have to test drive a half-dozen till they find one they like.
If we are expecting some kind of slow ramp we should think again.
Some obvious stuff:
- your APIs need to scale, preferably automagically;
- they need to be monitored closely, and that monitoring staffed – your current back office op center could be overwhelmed if you are not ready;
- you have to have a well-oiled, as-automated-as-you-can-make-it app credentialling process;
- you need a solid developer portal with a lot of self-service documentation and working stubbies;
- you need a developer-facing help process, again, as automated as you can, but you will need some people back there somewhere;
- and you need to _follow the standards_.
That last one is going to be hard – as I wrote about in my last couple of posts the currently mandated specs don’t cover the currently mandated use cases, so there is going to be some scrambling between now and 1/1 and beyond.
There is also going to be another wave of technology evolution coming, driven by the broad emergence of connected consumer apps.
More about that soon, but here is a teaser.
As you know, consumer apps are not in the HIPAA space. We – the covered entities we – have been constrained in our operational uses of patient/member matching because of the potentially serious impacts of false positives, such as wrong surgery, wrong prescriptions, wrong care advice.
Consumer apps are going to be matching your members/patients willy-nilly across APIs _with nigh-on 100% accuracy_.
The FHIR patient resource ID they get back in the app launch context is not going to be the same for the same consumer from API to API, the Patient.identifier they get is going to be _your_ internal proprietary ID, which won’t match with someone else’s proprietary ID.
The thing is, they are going to know they match because the consumer has authenticated against all the APIs.
And as the apps start to play together, and integrate with other sources of personal data, they are going to start off using probabilistic matching based on demographics and shared history, freely, without regard to Type 1 errors – those are your problem.
But that matching, our some-day TEFCA-based matching, our even further in the future universal patient ID, those are going to get washed away by some emergent identity capability that is going to bubble up out of the consumer app space based on common need.
An existing, publicly-accessible, consumer-owned, centralized ID solution – a self-sovereign ID – is going to explode. Less than two years from now I expect all of those consumer apps will have their users create such an ID, then link it to all their API-based data.
My money is on https://sovrin.org/
Stay tuned.
Health IT Architect 