ABBI and BlueButton+
Over the past six months, I’ve had the privilege of working with the Automate Blue Button Initiative on BlueButton+ specifications for sharing data with patients. Since ABBI’s core goal of enabling automated patient access to health data is so closely aligned with SMART’s vision, it was exciting to see the initial (Push-based) BlueButton+ specifications implemented at HIMSS 13 this month.
Progress in ABBI’s Pull Workgroup has been slower. We’re hashing out the details of an OAuth2-based framework that puts patients in control over when and how apps can fetch health data. An important question has been: how can we enable an ecosystem where thousands of apps connect to providers across the country in a trusted way?
Fostering a BlueButton+ Ecosystem
I’ve been eager to ensure that our specifications enable patients to authorize any app they choose, including apps written by patient-technologists and -tinkerers. A key aspect of this infrastructure is app registration, or a process by which data holders know which apps exist (and hence which apps a patient can authorize). The ABBI Pull group has discussed several options including:
|
OAuth2 Dynamic Registration: a decentralized protocol that allows apps to register withBlueButton+ implementers in a fully automated fashion. |
|
Trust bundle-based Registration: a centralized process where app developers apply for membership in a national “trust bundle” that each BlueButton+ implementer would rely on. |
I have a few opinions about the technology here, but as I commented on Keith Boone’s blog, I have a much stronger opinion about the resulting ecosystem: it should support technologists and tinkerers, allowing informed and intrepid patients to take advantage of a wide ecosystem of apps.
Technology and Policy are Intertwined
An S&I Framework project can’t consider technology in total isolation from policy. App registration provides a very clear example to illustrate the point:
-
If BlueButton+ adopts OAuth2 Dynamic Registration, I’d be reassured that BlueButton+ implementers will (or at least SHOULD, in the IETF sense) “allow initial registration requests with no authentication.” That’s a technical choice with clear policy implications (friendly to tinkerers).
-
If BlueButton+ adopts a centralized trust bundle-based process, that’s a technical choice that leaves policy implications open. With this choice, I’d want additional assurance that app developers will have a non-onerous way to gain membership in a BlueButton+ trust bundle. Otherwise we create an ecosystem that limits patient choice.
Taming Chaos with Levels of Trust
I should add that there’s a very strong role for policy to enable levels of trust. We need an ecosystem where some apps may be vetted and highly trusted by data-holders. (Some apps may even be run by data holders or their affiliates.) Meanwhile, other apps might be registered with a lightweight, fully-automated process and minimal vetting; these apps could trigger warning language informing patients about any risks of sharing data.
BlueButton+ mustn’t overlook this latter category of apps, or we risk excluding innovative mash-ups, weekend projects, open-source tinkering, and can-do “let me solve this problem for myself” patients.