Meeting 2020-04-01 AdvCIS

use-cases kick-off with presentation ()

@vitor jesus (Unlicensed)

• 5 use-case scenarios presented: healthcare, information services, IoT, Smart Cities, Managed Consent

• James Hazard: I'm thinking of an element in GA4GH consents that asks if the data user can recontact the data subject for further permission

• James Hazard: does Notice, Notification, Consent include also a cycle of renotification and reconsent?  E.g., you permitted us to ask you for further permission.  And notices includes notices of results, or breach, etc.??

• Xiaohu: notices have different classifications; terminology (as usual) needs to be clarified

• James Hazard: I've been collecting data use frameworks.  Suggestions appreciated: http://www.commonaccord.org/index.php?action=source&file=S/Index/DataSharing/Frameworks.md; this is a low-tech, but high legal power initiative on clearing IP problems in covid https://opencovidpledge.org/

• James Hazard: the lawyer comes in when something goes wrong – it needs traceability and auditability

presentation of a pharma scenario

Paul Knowles

• Paul K - presented a Mickey Mouse Model (VJ–), a model for a safe and secure data sharing economy.

• Participants agreed on that this use-case is very representative and powerful and have shows keen interest in adopting it for the group.

• Tom J: Within us healthcare federation, Kantara is proposing that the user should know that the party is a "Covered Entity", that there are a set of rules that the receiver has agreed to follow before the user is able to give consent. Exports of data beyond covered entities is a more deliberate process that the user must follow. I would hope that you insist on some multilateral federation of federations that can result in user knowledge of the continued protection of the user data. → VJ: healthcare may need to prove who they are à kind of a federation

discussion

Potential requirements identified for a receipt:

• receipts need a strong identifier that may need to outlive the local transaction, i.e., it may need to set a context that is later invoked such as when re-consent is required or the user needs to be notified about a past consent action. in other words, it may need a consent lifecycle identifier that persists over time until revoked

• receipts should hold information about all the context necessary to later invoke it

• receipts may need to have the identity of the parties and that identity may need to be verified

• receipts need to be a tool in themselves to support traceability and auditability

• if a receipt has a notion of session/lifecycle, it may enable scheduled/batched consent where the user may not need to provide consent at the precise time but it comes from a past "batch" action (say, user agrees with a set of preferences that are reused over time)