Folks,

This issue has come up as I am looking into issues raised by the recently announced API access to individual's Medicare records: https://bluebutton.cms.gov/developers/#production-api-access

To frame the issue, under current US law, the patient has an unrestricted right to directed access (patient can specify any address for the record to be sent to directly) to their own data, at least when the access is via paper or fax. The question is how will patient-directed access work on top of a FHIR API.

For example, the policy for registering an OAuth client to the production Open.Epic FHIR API, is accessible to anyone willing to assume the role of "developer" and holding a valid credit card. The Client registration process is tedious and takes up to 24 hours, but otherwise unrestricted.

The process for registering a client to the Medicare production API (link above) is considerably more tedious and expensive. It involves a claim that you're a US corporation, a link to a privacy policy, a telephone conference, and up to two weeks delay.

Which brings up my UMA question: Who is responsible for RqP's (Bob) Client Registration (OAuth or UMA)?

(1) Is it the patient, because under patient-directed access the patient takes all responsibility for Bob's actions?

(2) Is it Bob, because he is presumed to have the responsibility for his own Client and patient Alice has no real way to know much about Bob's client?

(3) The Resource Server is responsible but highly constrained in its actions by HIPAA and the API Task Force that say that patient-directed Client access can be denied only in the case of security violations like a DoS attack?

What is the current situation with or without Dynamic Client Registration in OAuth and UMA?

Adrian

--