In line with Ann's comment, I've made a rough list of roles for a Consent. It is mostly self-explanatory. If you mouseover the text you will see the name of each component, hence the naming scheme. Click on source for the structure. Basically, it imagines a Consent being created from a form and a list of participants in roles. The list of roles (with versions) can serve for the life of the relationship, and each document can be made by referencing it. I experimented with a hash "ID", with privacy preservation in mind. The hash could be used in support of or instead of personal info. The hash is primitive - once I had some rough info for the participants I zipped the list and put the zipped list into IPFS. Each participant has a "ID.Hash" consisting of that hash and their name. As I said, rough. Based on "Health Research Context", I put the files under "HRC" and only noticed the coincidence afterwards. Any political inferences are your own. http://source.commonaccord.org/index.php?action=doc&file=GH/KantaraInitiative/DG-BSC/HRC/Demo/Consent/0.md On Sat, Jul 30, 2016 at 10:35 AM, M AV <av_m@hotmail.com> wrote:
Great use case write up!
In thinking about it, starts to seem to me that there are actually two things going on in terms of transaction tracking via the smart contract/immutable ledger technology.
First is “Alice”’s consent form – that is a document event like, say a stock ownership certificate, and with regard to that, perhaps the ledger-ing has more to do with accounting for the parties that participate in that contract of consent – for example, if the sponsoring drug company is acquired by another corporate entity there would be a substitution of parties in the chain of participants that would appear in the record as a change event to the original consent contract creation event.
Second is Alice’s data – that, seems to me, is a somewhat entirely different thing insofar as it entails an inventory of objects – e.g, various clinical measurements taken at perhaps various chronological points – that could be variously accessed by various parties at various times in the life and framework of the consent.
I guess I just have an intuition that the first aspect – the consent qua thing – is the more amenable use case; and, certainly, the data use tracking is the more intriguing but is sort of mind-blowing in terms of the complexity of even just defining “data” as a thing for the purposes of an implementation of some sort within the smart contract/ledger technology.
Just some thoughts. J
Best, ann vroom
*From:* dg-bsc-bounces@kantarainitiative.org [mailto: dg-bsc-bounces@kantarainitiative.org] *On Behalf Of *John Wunderlich *Sent:* Friday, July 29, 2016 3:45 PM *To:* dg-bsc@kantarainitiative.org *Subject:* [DG-BSC] Use Case updated
I've renamed the use case and put in a basic narrative and use case diagram. I've tried to put forward the simplest case. Please review and comment if you have a chance, before I move on and fill in the rest of the use case.
http://kantarainitiative.org/confluence/display/BSC/Trust+and+verification+i...
Sincerely, John Wunderlich @PrivacyCDN
Call: +1 (647) 669-4749 eMail: john@wunderlich.ca
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.
_______________________________________________ DG-BSC mailing list DG-BSC@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/dg-bsc
-- @commonaccord