Search tips
Search criteria 


Logo of jamiaAlertsAuthor InstructionsSubmitAboutJAMIA - The Journal of the American Medical Informatics Association
J Am Med Inform Assoc. 2012 Nov-Dec; 19(6): 1115–1118.
PMCID: PMC3486732

Challenges in creating an opt-in biobank with a registrar-based consent process and a commercial EHR


Residual clinical samples represent a very appealing source of biomaterial for translational and clinical research. We describe the implementation of an opt-in biobank, with consent being obtained at the time of registration and the decision stored in our electronic health record, Epic. Information on that decision, along with laboratory data, is transferred to an application that signals to biobank staff whether a given sample can be kept for research. Investigators can search for samples using our i2b2 data warehouse. Patient participation has been overwhelmingly positive and much higher than anticipated. Over 86% of patients provided consent and almost 83% requested to be notified of any incidental research findings. In 6 months, we obtained decisions from over 18 000 patients and processed 8000 blood samples for storage in our research biobank. However, commercial electronic health records like Epic lack key functionality required by a registrar-based consent process, although workarounds exist.

Keywords: Biological specimen banks, biorepository, informed consent, electronic health records, medical informatics


Institutions face numerous challenges when developing large-scale biobanks focused on the acquisition, processing, and storage of residual clinical samples for future research use. Here we explore the issues faced by our institution, Cincinnati Children's Hospital Medical Center (CCHMC), in creating such a program, which we call Better Outcomes for Children (BOfC).

One of the most significant tasks when developing a residual sample biobank is addressing the need to obtain informed consent. Institutions have many options in this area. They may: (a) pursue a wholesale waiver of consent; (b) choose to incorporate an agreement to collect samples as part of the standard clinical consent-to-treat document; (c) present patients with a more explicit description of the process and a passive consent (ie, an opt-out process); (d) develop a research consenting process specifically addressing sample collection as part of the hospital registration process; or (e) develop a free-standing research consenting process that occurs at some other point in the care process.1 Each alternative provides its own unique risk/benefit profile. Another factor to consider is the degree to which the samples can be linked back to the medical record or other information that identifies the person providing the sample.1–3


Consent process

In drafting the BOfC sample-handling protocols, it was determined that maintaining a link between patient and sample was vital, both to ensure access to phenotype data as well as for quality assurance purposes. Once this determination was made, a wholesale waiver of consent was ruled out as an option. Incorporating a research consent into the routine consent for medical care or into the institution's notice of the privacy practice process was also frowned upon, as both of these documents serve distinct purposes that are very different from a research consent.

Using information gathered from several consultations with CCHMC's Patient and Family Advisory Council, as well as the local Community Partner's Council (part of the local CTSA (Clinical and Translational Science Award) infrastructure), it was decided that the process of obtaining BOfC consent would consist of a research consent with a condensed consent document. The content of the document was developed in consultation with the Patient and Family Advisory Council. An opt-out approach was considered, but was overwhelmingly viewed as unacceptable.

Surprisingly, a large percentage of council members expressed a desire to be informed of any clinically relevant information discerned through the secondary research use of their samples (ie, incidental research findings). To provide such a choice, the BOfC consent process was constructed to allow for two levels of participation. The first level is essentially anonymous. The patient's residual clinical samples are made available in the repository with no mechanism for re-contact. The second level of participation allows the patient/family providing the sample to receive information on incidental research findings.

From a regulatory standpoint, the BOfC program relies on what could be characterized as a ‘self-consenting process,’ that is, a member of the research team is not immediately available in person to the patient/family at the time of consent (they are available by phone or email, however). In this process, hospital registration personnel (registrars) present the BOfC consent form to the patient/family and are available to assist them in reading the document. If the patient/family does not understand the nature of the BOfC program, or asks a question that cannot be addressed by a relevant section of text in the BOfC consent document, then consent is not obtained at that time. In such instances, the registrars are trained to mark the patient's BOfC consent decision as ‘consent deferred.’ This option is also used in cases where the patient/family needs more time to consider their decision, where an appropriate parent or legal guardian does not accompany the minor patient, or when clinical circumstances are not conducive to obtaining a meaningful consent (eg, in an emergency setting or when the family is overly distraught/distracted by the clinical care of the patient). If BOfC consent is deferred, a patient is not asked again about the project for 7 days. After this period, they are asked at their next hospital encounter.

From an ethical and regulatory standpoint, ‘consent deferred’ is distinct from ‘refused participation,’ with the latter being a definitive choice of the patient/family regarding the use of their residual clinical samples. When developing the BOfC consent process, the question was raised whether to re-approach patients regarding participation once they indicated a refusal to participate. The initial position was to not approach patients again. After considerable discussion and consultation with current and former patients and families, it became clear that a patient/family's opinion on this topic can and does change over time, particularly as their disease or treatment course evolves. Therefore, CCHMC decided to keep the ‘refused participation’ decision in effect for 12 months. Upon expiration, the patient/family would then be asked to participate in BOfC at their next encounter.

If a patient provides consent and later decides to refuse participation (but does not withdraw), any sample collected during the initial period of BOfC consent can still be used for research. If a patient withdraws, however, all existing samples not previously released are destroyed. If a patient is under 18 years of age at the time when the original BOfC consent is obtained, a parent will provide consent and the child assent. After turning 18, the patient will be asked to provide consent at the first visit after their 18th birthday. This BOfC consent does not expire unless the patient specifically withdraws from the study. See the online supplement for additional information on the consent process.


The patient's BOfC consent decision is recorded in the CCHMC's enterprise EHR, Epic.4 It is recorded during the registration process along with the patient's decisions on documents like the ‘consent to treat’ and ‘notification of privacy practices.’ Capturing this information in Epic proved to be problematic, however.

The original BOfC consent form consisted of a single document, with different signature lines to designate a patient's decision on their level of participation. Epic only supports one electronic signature per document. As a result, four different documents needed to be created in the system—one for each consent option, plus a fifth document for patients who elected to withdraw from BOfC.

Epic treats documents as distinct entities. This means it is possible for the registrars to add more than one BOfC consent document to a patient's record, each of which may be considered active, or ‘effective’ (we were unable to find a way to prompt the registrars to NOT ask about the BOfC consent if one had already been obtained). This can result in a patient with multiple effective consents without any indication as to which is correct. To address this, rules were built to warn the registrars that there was more than one consent document attached to the patient's record and to expire the old documents before completing the registration. None of the rules can be triggered until final submission, however. This is very late in the registration workflow and requires the registrars to navigate through several screens before they can resolve the issue. In addition, it is possible to ignore the warnings by simply logging out of the system. As a result, a manual process must be executed to identify and remove all BOfC consent documents for patients with multiple effective consents.

The BOfC consent data are pulled from Epic on a daily basis and stored in Epic's reporting database, Clarity. This database also includes information on the samples that have been drawn for clinical testing. At first, the data related to the BOfC consent documents in Clarity did not match what was on the screen in Epic. As a result, our internal Epic team had to create a number of specialized views to make the data more representative of what is shown in the application. Even with these steps, manual intervention is still needed to periodically clean the data.

Sample verification

In order to determine whether a given residual sample could be used for research, we created a ‘traffic light’ application that would accept a sample accession number and return a green light if the sample could be kept, and a red light if it should be discarded (figure 1). If a sample should be discarded, the application provides the reason why (no consent obtained, consent refused, withdrawn, etc). The clinical samples are not checked whether they can be used for research until they are no longer needed for clinical purposes (typically 7 days after they are drawn). The sample verification application contains all of the business rules that ensure only proper samples are kept for research (figure 2).

Figure 1
A scan log showing both a ‘red light’ and ‘green light’ sample. In this figure, the top two samples have been red-lighted and the bottom three green-lighted. Included in the log is patient information, along with the consent ...
Figure 2
Illustration of application logic for complex sample acquisition scenarios. In each scenario, three different samples are collected. The date of collection is shown, along with the consent type(s) in effect at that time. The scenario then shows the outcome ...

BTM and i2b2

Once the research samples have been processed, they are logged into the biobank's sample tracking and management system, BTM-Research (Biomaterial Tracking and Management—Daedalus Software5). The system tracks data and metadata about the samples (container type, volume, time to freezer, location, etc). This information is interfaced with the hospital's i2b2 data warehouse.6–8 Investigators can use i2b2 to determine whether there are any samples of interest. After a cohort has been generated, they work with the biobank staff to request the samples. If tissue is requested, its release must be approved by a Tissue Use Committee. The sample request process is currently manual, but efforts are underway to automate it.


After going live in several clinics, we have found patient participation to be overwhelmingly positive. As of February 27, 2012, over 86% of asked patients have provided consent and almost 83% have requested to be notified of any subsequent findings. The breakdown of patient decisions is presented in table 1. This approaches the percentages of patients who participate in the opt-out BioVu databank.2 9 In the 6 months that the project has been live, we have obtained decisions from more than 18 000 patients and processed over 8000 blood samples for storage in our research biobank. We have also grandfathered in over 25 000 tissue samples that were collected by our pathology laboratory as leftover surgical specimens. Newly collected tissue samples will be also be included if the BOfC consent status allows.

Table 1
Breakdown of patient consent by document type

Efforts are underway to roll out the BOfC registration process to the rest of the hospital. One notable change that had to be made after the initial go-live period was to allow patients to refuse consent without a signature. The original IRB protocol required each document to be electronically signed. Within Epic, patients are presented with an electronic signature pad, but are not able to see the document they are signing (a hardcopy printout is available). Patients who were distrustful of the project were not willing sign a document that they could not see. As a result, the BOfC protocol and consent process were amended to allow refusal documents to be obtained without an electronic signature.


The idea of reusing residual clinical samples for secondary research has obvious appeal. It is much simpler and more economical to pull samples from the normal clinic flow than to collect them in a separate process requiring an additional needle stick. Looking ahead at the changing regulatory landscape,10 CCHMC is in the vanguard of institutions preparing for the expected need to consent patients even for the use of residual clinical samples. The use of a registrar-based consent process as implemented at CCHMC has obvious appeal: no additional research staff are required, the consent decision is stored directly in the EHR, and the process does not significantly impede patient flow. Commercial EHRs like Epic present significant barriers to the implementation of a registrar-based process, however. It is possible to work around these limitations, but more often than not, the workarounds result in a process that is less reliable and more prone to human error. A more sustainable solution would be the encouragement of open, service-based EHR architectures that allow for the creation of custom interfaces and workflows.

Supplementary Material

Supplementary Data:


Contributed by

Contributors: KM conceived and oversaw the development of the informatics to support the project and prepared the manuscript. JCorsmo provided guidance in developing the regulatory framework for the BOfC IRB protocol and provided content for the manuscript. MGB oversees the operation of the BOfC biobank, prepared the BOfC IRB protocol, and led the discussions with the advisory councils. CP developed the requirements for the ‘traffic light’ application and was instrumental in troubleshooting Epic-related issues. JChalfin worked with the registrars on training and workflow issues and helped rectify the Epic data issues. JN led the development of the traffic light application. CS led the development of the validation rules and modifications to Epic that supported the workflows of the registrars and provided content for the manuscript. RG designed the database to support the traffic light application and helped identify data discrepancies in the Clarity database. All authors provided input in the drafting and finalization of the manuscript.

Funding: This work was funded in part by UL1RR026314 from the Clinical and Translational Science Award Program, National Institutes of Health.

Competing interests: None.

Ethics approval: Ethics approval was provided by Cincinnati Children's Hospital Medical Center Institutional Review Board.

Provenance and peer review: Not commissioned; externally peer reviewed.


1. Rothstein MA. Expanding the ethical analysis of biobanks. J Law Med Ethics 2005;33:89–101 [PubMed]
2. Pulley J, Clayton E, Bernard GR, et al. Principles of human subjects protections applied in an opt-out, de-identified biobank. Clin Transl Sci 2010;3:42–8 [PMC free article] [PubMed]
3. Roden DM, Pulley JM, Basford MA, et al. Development of a large-scale de-identified DNA biobank to enable personalized medicine. Clin Pharmacol Ther 2008;84:362–9 [PMC free article] [PubMed]
4. Epic Secondary Epic. 2012.
5. Daedalus Software, Daedalus BTM—Research. Secondary Daedalus Software—Daedalus BTM—Research. 2012.
6. Gainer V, Hackett K, Mendis M, et al. Using the i2b2 hive for clinical discovery: an example. AMIA Annu Symp Proc 2007:959. [PubMed]
7. Murphy SN, Mendis ME, Berkowitz DA, et al. Integration of clinical and genetic data in the i2b2 architecture. AMIA Annu Symp Proc 2006:1040. [PMC free article] [PubMed]
8. Murphy SN, Weber G, Mendis M, et al. Serving the enterprise and beyond with informatics for integrating biology and the bedside (i2b2). J Am Med Inform Assoc 2010;17:124–30 [PMC free article] [PubMed]
9. Brothers KB, Morrison DR, Clayton EW. Two large-scale surveys on community attitudes toward an opt-out biobank. Am J Med Genet A 2011;155A:2982–90 [PMC free article] [PubMed]
10. HHS Announces Proposal to Improve Rules Protecting Human Research Subjects. 2011. (accessed 23 Jul 2011).

Articles from Journal of the American Medical Informatics Association : JAMIA are provided here courtesy of American Medical Informatics Association