We distinguish here between the context of providing health care, which is a highly regulated and complex area, and the specific use case where an individual's information is being sought for use in health care research. The particular case here involves a person whose disease has experimental treatments available. We will assume for this case that the person is both an adult and capable of making decisions for themselves and giving consent. This use case may be extended into the future to account for paediatric research or research involving persons deemed incapable (mental health for example). We also note that there may be a predecessor or stereotypical case - Human Research Consent - that encompasses any research project that has humans as subjects. This could include but is not restricted to areas like human-computer interface research, social sciences research or marketing research.
Alice has been diagnosed with cancer and is being treated by her doctor, Carol. Carol is an oncologist with an active research agenda and is aware of a Phase III trial of a new drug for the type of cancer that Alice has. The trial is a randomised unblinded two-armed study that compares the standard of care (the treatment that Alice is currently receiving) vs standard of care plus the new drug.Two-armed means that the patients in the trial will be divided into two groups randomly (hence randomised). It is an unblinded study, which means that patients will know which arm they are on. While Carol is not an investigator on the study, she feels that Alice should be presented with the option of participating in the study. This use case starts after Alice has made the choice, in discussion with Carol, to participate in the study. We note that this narrative elides over whether or not Carol's use of Alice's health information to determine if Alice might be a candidate for research raises its own set of consent and use issues. Carol will provide Alice with treatment, including the experimental drug if Alice ends up on the experimental arm, but will not participate in the study. If Alice consents, the study team will be provided with regular data extracts from Alice's health record for the purposes of their research. To enable this data extract Bob from the study team will seek consent from Alice to participate in the study, using a standardised consent form. Alice will be assigned a study number (typically a random number of some kind.) The study team will regularly extract health data from Alice's health record in accordance with the consent until a defined study end-point is reached or Alice withdraws from the study. Each tranche of data collected by the study team will be de-identified (used) and tagged with Alice's study number. The de-identified data will be sent to the drug manufacturer who is the sponsor of the trial. The drug company will use the de-identified data to evaluate the study results and produce any necessary regulatory or research results.
For the purposes of this discussion group, the consent that Alice agrees to is a 'contract' which can be recorded on a blockchain. It may be the case that each data extraction and/or each transfer of data to the drug sponsor may be recorded as well. Until the data is de-identified, the study team will record access to and uses of the data on the blockchain. These transactions on the blockchain will enable Alice to verify that her data is only being used for the purposes set out in the consent/contract and only by authorised people.
Once the study has been completed the study data is stored by the Study Sponsor. There are both regulatory and research reasons for this. Regulators will want to keep health data from drug trials for a long period in the event that there are long-term impacts from the drug that are not immediately apparent on trial. Researchers will want access to the data for secondary or related studies. This later gives rise to a secondary use case where Edna will want access to the data for a study. The study sponsor publishes a data dictionary describing the kind fo data that they have available for researchers and Edna determines that the study in which Alice participated will provide the basis for a study that she is interested in. She initiates a request for access to the data. Dan receives the request and reviews the study in which Alice participated to determine if the study consent allows such secondary use (it usually does). Dan follows the study sponsor policies and procedures and gets Edna to sign a data sharing agreement that grants her access to Alice's data on the condition that she will neither attempt to re-identify Alice nor transfer the data to any other entity.
Role in the use case
The patient who is the subject of health research and whose consent is required to enable the research.
The person or entity that seeks consent from Alice. They are assumed to be an investigator or worker in the study team.
|#Carol||The physician who is providing care to Alice and identifies her as a candidate for the study. Whether or not Alice consents to the study, Carol will be providing her standard care and the experimental drug. For this use case, we separate the attending physician and the investigating physician so that there is a clear demarcation between access to health information for treatment and access to health information for research. We recognise that this is a bit of a contrivance but do so nonetheless to clarify the roles and data flows.|
|#Dan||An authenticated and authorised individual or system that is acting for the Study Sponsor and that is not on the Study Team. Typically an analyst or researcher using the data set that includes Alice's data.|
|#Edna||An authenticated and authorised researcher that has been granted access to the Study Sponsor's database of research data. This may be a staff researcher for the Study Sponsor doing cross-study correlations, or an external researcher with a different study question that can be answered with previously collected data.|
Generic bad actor (M for Man in the Middle in the original cryptography scenario)
|Care Team||The individuals and systems that provide health care services to Alice. Carol is Alice's oncologist and a member of her care team. For the purposes of diagrams and data flows, any member of the care team will be represented as "Carol"|
|Study Sponsor||The organisation that receives study data. These individuals or systems use or disclose Alice's health information (presumptively but not necessarily in a de-identified form). For the purpose of diagrams and data flows, any member of the study team will be represented as "Dan"|
|Study Team||The individuals and systems who collect Alice's information at the health organisation where she receives care. Bob is a member of the study team. For the purpose of diagrams and data flows, any member of the study team will be represented as "Bob"|
The following steps comprise the primary use case.
Carol uses Alice's personal health information (PHI) to determine if she qualifies for the study
|2||Carol shares a subset of Alice's PHI with Bob|
|3||Bob obtains consent from Alice|
|4||Bob stores a signed copy of Alice's consent|
|5||Bob makes a record of Alice's consent on the blockchain|
Carol provides care to Alice, including any study related treatments.
|Loop while Alice is on study|
|7||Bob extracts study data from Alice's health record|
|8||Data extract data and metadata recorded on blockchain|
|9||Bob de-identifies data extract and attaches Alice's study #|
|10||Bob sends Alice's data to Dan|
|11||Data transmission recorded on blockchain|
|12||Dan performs interim analysis|
|End Loop (study is complete)|
Dan completes analysis and publishes results
|14||Study data is deleted after retention period expires|
This use case arises after step 13 above, but before the data is deleted.
|1||Edna Reviews the data dictionary and determines that the data from Bob's study may be useful for her study|
|2||Edna applies for access to Bob's study data|
|3a||If the data is deidentified (or if the data is identifiable, but the original consent allowed secondary research) Bob grants access to Edna (with data sharing agreement in which Edna agrees not to attempt re-identification)|
|3b||If the data is identifiable and a new consent is required, Bob contacts Alice to see let her know about Edna's study. If Alice is interested, Bob shares Alice's contact information with Edna. Go to Step 3 of Primary Use Case (Edna now becomes Bob in the use case)|
|4||Bob records that Edna has been granted access to Alice's data|
|5||Edna extracts Alice's Data. Go to Step 8 in the Primary Use Case (Edna becomes Bob in the Use case)|
The use case ends when the study is over. Even if Alice has withdrawn from the study before it completes, or is taken off study for any reason, it is normal for this kind of research that any of her data that has already been collected will remain in the study data set.
See these resources for related ideas about consent:
Alice Authorizes Clinical Research from HEART (talks about an aggregator subsequently sharing with clinical researchers)
Alice Selectively Shares Health-Related Data with Physicians and Others from HEART (talks about deidentified data)
The GA4GH folks have a committee that created a model data sharing consent form in CommonAccord. There's capacity for it to be signed. (This is perhaps where we want to concentrate our efforts.)
Jim shares this link as a resource for helping with the first use case.
FHIR: Fast Healthcare Interoperability Resources (FHIR, pronounced "Fire") defines a set of "Resources" that represent granular clinical concepts. The resources can be managed in isolation, or aggregated into complex documents. Technically, FHIR is designed for the web; the resources are based on simple XML or JSON structures, with an HTTP-based RESTful protocol where each resource has predictable URL. Where possible, open internet standards are used for data representation.
HEART: The OpenID HEART Working Group intends to harmonise and develop a set of privacy and security specifications that enable an individual to control the authorization of access to RESTful health-related data sharing APIs, and to facilitate the development of interoperable implementations of these specifications by others
Common Accord: CommonAccord is an initiative to create global codes of legal transacting by codifying and automating legal documents, including contracts, permits, organisational documents, and consents. We anticipate that there will be codes for each jurisdiction, in each language. For international dealings and coordination, there will be at least one "global" code. Center for Collaborative Law