Meeting 2020-04-01 AdvCIS

Date

Attendees

Goals

  • Use case selection - 

Discussion items

TimeItemWhoNotes

use-cases kick-off with presentation (use-cases-20200401.pdf)

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 scenarioPaul Knowles
  • Paul K - presented a Mickey Mouse Model (VJ–AdvCIS_use_case_pk.pdf), 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)

Action items

  •