Hi John, Agreed. The current workflows of consent handling can be respected while also getting the benefits of templating, standards formation and machine readability. Regarding "smart contracts," it may be helpful to think of them as independent of the database (blockchain). In this view, "smart contracts" are functions executed in code. They can schedule an access, transfer a ledger entry, provide a notice mechanism, etc. The code needs to be abstracted from any particular computer language (Thomas's Smart Contract Definition Language) and from any particular database. In some instances, it will make sense to use a blockchain as the database and execution platform, but in most, a more conventional database will be appropriate. For uses where confidentiality or ability to delete information is important, a blockchain will be inappropriate. In any event, the "smart contracts" must be independent of the form of database because a person (including and institution) must be able to have a database representation of all of their interactions. Best, Jim On Tue, Aug 23, 2016 at 1:05 PM, John Moehrke wrote:

James,

In healthcare this is current best-practice, when a consent needs to be known by multiple parties. Most consents only need to be known by the data-holder to enable them to release data that the consent authorizes. When multiple parties need to know, we use a system like you have described. The dominant form of this comes from a profiling organization -- Integrating the Healthcare Enterprise (IHE) -- a very similar organization to Kantara for the healthcare domain. This is profiled in "Basic Patient Privacy Consents (BPPC)".

There is also the work of Kantara on Consent Receipts....

This kind of evidence could be defined in pseudonym space and of YES/NO basis, thus reasonable to put on blockchain. If done, the smart-contract could be simple enough. This is the essence of a blog article I posted in May. https://healthcaresecprivacy.blogspot.com/2016/05/ healthcare-blockchain-big-data.html

This supports consents without exceptions or conditions or obligations. Which covers some space. Healthcare is moving to the next step, being able to encode some of the rules (vectors) that are commonly needed by Patients. Again within IHE there is an effort focused on a Document Sharing system, also from IHE. This is profiled as "Advance Patient Privacy Consent" (APPC), which is a profile of XACML policy-set. It leverages BPPC to manage the documentation, just using XACML for the exceptions to the base policy.

SImilar is being done in HL7 FHIR in a RESTful resource -- Consent Resource. ....

somewhat related is the work of HEART. -- rather than focus on capturing consent rules in standardized documentation, they focus on standardizing access control decisions using UMA.....

I am working on a series of blog articles to explain this. Just published yesterday a top-level view https://healthcaresecprivacy.blogspot.com/2016/08/controlling-big- data-feeding-frenzy.html

when the rules get more complex, I think the system must use a more comprehensive access control system, smart-contracts will not be sufficient. It is possible that the smart-contract could leverage a access control service using one of the above. But question as to why it would be helpful to put a smart-contract onto blockchain that does nothing but return the results of service call... Hence why I am not convinced that the authorization to access healthcare data should be implemented in smart-contract. This doesn't diminish the discussion, it is just my current perspective.

John

John Moehrke Principal Engineering Architect: Standards - Interoperability, Privacy, and Security CyberPrivacy – Enabling authorized communications while respecting Privacy M +1 920-564-2067 JohnMoehrke@gmail.com https://www.linkedin.com/in/johnmoehrke https://healthcaresecprivacy.blogspot.com "Quis custodiet ipsos custodes?" ("Who watches the watchers?")

On Tue, Aug 23, 2016 at 11:12 AM, James Hazard wrote:

...

Very good call today. I was very interested in the discussion of templated consents. This seems very productive. If the consents are authored from templates and have GUIDs, then they can be made machine readable even if all the machine can read is the GUID (for instance in scanned PDFs, which I'm told are common). The GUID also provides a basis for notifications and permissions.

Here is a bit of old work that I did (Primavera did the diagrams) for the Global Alliance for Genomics and Health. http://www.commonaccord.org/index.php?action=list&file=Wx/or g/genomicsandhealth/REWG/Demo/ The complexity of the example reflects (some of) the complexity of the relationships.

-- @commonaccord

_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc

-- @commonaccord