[Openid-specs-heart] User Experience and Privacy Engineering in HEART
Adrian Gropper
agropper at healthurl.com
Mon Jun 13 22:54:19 UTC 2016
Let me try to clarify a number of things said in today's call and put them
in the context of Alice and Bob's user experience and Justin's concern
regarding privacy engineering.
The baseline user experience should be:
1. *Alice has to remember only one thing*: Her voluntary globally unique
pseudonym. I suggest we use an email address as the reference point.
2. *Dr. Bob gets everything he needs,* Alice's policies permitting, by
simply entering Alice's pseudonym into his client.
3. *Resource Server (the source of Alice's attributes, a PHR or EHR)
allows Alice to specify her Authorization Server* (This is what I can't
convince the HL7-FHIR folks to consider).
4. *An Interop Label *defined by a neutral entity, (e.g.: PPR)
encourages Alice's AS, Dr. Bob's Client, and the Resource Server to make it
easy for Alice by promising interoperability with web services that
separately self-assert that Label. The label definition may include a
suggested set of policies that Alice might use by default, scope, and IdP
options.
The rest is easy.
1. Alice opens an account with an AS that installs the Interop Label by
default and makes itself discoverable via her chosen globally unique
pseudonym. Alice can accept the defaults mindlessly if she really trusts
the Interop Label source and AS. She can always modify her policies at a
later time.
2. Alice supplies her pseudonym to the Resource Server. The rest is
handled automagically by UMA / HEART.
3. Alice supplies her pseudonym to Dr. Bob. The rest is handled
automamagically by UMA / HEART.
4. Alice receives notification whenever the Resource Server authorizes
release of her attributes. After a while, Alice goes to her AS and turns
those notifications into a monthly digest, similar to the statement she
gets from her bank.
For extra credit:
Here's a list of 10 things Halamka would like to see per his blog post
today:
http://thehealthcareblog.com/blog/2016/06/13/fud-part-ii-the-return-of-fear-uncertainty-and-doubt/
(my comments in (parenthesis))
*A master patient identifier for the country (easy if resource servers
would accept a voluntary unique pseudonym)
*A provider directory for the country
*A consent registry/record locator service for the country (easy if
resource servers would accept a patient-specified UMA AS)
*A customer relationship management platform that supports care management
*A groupware communication tool for healthcare
*A set of security solutions that makes two factor authentication/endpoint
encryption easier (easy if resource servers actually allowed patients and
doctors to use OpenID Connect)
*A mobile platform for patient/family engagement that provides usability
and high value transactions to the consumer (easy if instead of multiple
portals, the focus of engagement was delegated through a patient-specified
AS)
*A telehealth/telemedicine platform that supports documentation/billing in
the cloud
*An interoperability platform that leverages cloud technologies to
seamlessly provide clinicians with the information they need when their
need it (easy if we have a model where an inteorperability label actually
means something the way WiFi or Bluetooth do)
*An analytics platform that notifies/alerts clinicians when something needs
to be done – providing wisdom, not just a flood of data. (easy if the
interoperability label specifies AS notification at the level of the Enter
key in associated resource server. FHIR can do this. My proposed
interoperability label is "Independent Decision Support at the Point of
Care" (iDSpoc) indicating that not only are the patient and physician able
to specify their respective authorization servers but that the EHR issues a
notification to that AS whenever an order is entered or other significant
change is made.
My concern is that FHIR, including SMART on FHIR, have not allowed the most
obvious user experience use-case into the spec. The result will be the FUD
that Halamka discusses and another three or five years of information
blocking.
Adrian
--
Adrian Gropper MD
PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: http://patientprivacyrights.org/donate-2/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-heart/attachments/20160613/c434654f/attachment.html>
More information about the Openid-specs-heart
mailing list