Use-Case Requirements
Dimensions of the use-cases
- Whether there are different domains (hospitals, countries)
- Whether data is pre-anonymised (notably for medical research)
- Whether there is an established identity system able to authenticate and receive requests
Actors
- The subject
- The healthcare organisations holding EHRs
- Requesting parties
- Countries or jurisdictions
Use-Cases
From simplest to comprehensive
...
Requirements/questions collected for a receipt (making sense) so far, by no particular order and most needing refinement or answers:
- identity of parties
- how does Alice verify the identity of Bob? how does Bob verify the identity of Alice?
- is this a requirement for the receipts or out-of-scope?
- types of receipt
- notice, consent, notification
- types of consent
- notice, implied, as-expected, explicit, agreement (user-initiated) – from git hub doc here, Mark L
- receipt-id
- should enable context over a long period of time (re-consent, changes, revocation, etc.)
- a previous-receipt-id to enable protocols and establish a notion of session continuity?
- a receipt needs to embed/facilitate traceability + auditability
- support to batched/scheduled consent to the future
- no-consent/refusal
- In US - among “merchants” (not consumers), failure to promptly object to a notice of a minor change can be taken as acceptance. And there are numberous other situations, time periods for undoing something, making a claim, etc. (quoting and thanks to Jim Hazard)
- deep sharing of 3rd parties
- is there a receipt to be issued?
- who issues the receipt?
- is consent “cascaded” (first party handles everything) or each a sequence of peer-to-peer Consent cycles?
- we need taxonomies for certain fields which can be enumerated
- e.g., purposes, legal basis, types of data collected
- the taxonomies in themselves out-of-scope?
- post-receipt/consent notifications
- means to notify back the recipient post-act (as in a message about changes)