Pages

Sunday, May 29, 2016

Simplified #FHIR Privacy Consent Directive resource

The most simple Privacy Consent Directive would really just be a YES/NO flag, so I don't actually mean that simple. What I mean is more simple than the last update I made, yet still functional. With the previous version I learned a few more things to be simplified.  The most shocking that I forgot is that the most prevalent exception is to exclude data published duing a date/time range.

So now I have updated the Privacy Consent Directive resource that has a base that identifies the patient, authority, domain, location, recipient, grantor, data, and actions. These are the elements needed for an all-or-nothing kind of consent.


Then there are a set of exceptions to this base: additions or subtractions. The set of exceptions include a list of data objects, list of authors, list of recipients, list of Organizations, list of purposeOfUse, and Date Range.

All of this sits within broader policy that is not part of the Consent, but surrounds it. The operational access controls that cover the meaning of opt-in and opt-out; and also cover the case where no consent has been achieved.

Because there was discussion of some things that are clearly beyond what we are minimally trying to enable, I created some extensions: Authorization Service (such as OAuth/UMA);  Computable Consent Rules (such as XACML);  Notification endpoint to receive Disclosure events in AuditEvent form; and  Witness reference for those that need to expose who was the witness.

There have been discussions of Digital Signature, but that is already supported through a Provenance.signature.

Clearly that is more simple than my first Consent resource


Especially more simple than Contract


Updated 5/30/2016: Fix FHIR spelling in the title, and add background policy that covers operations and case where no consent has been achieved.

No comments:

Post a Comment