How eConsent Optimizes Research – Webinar Q&A, Part 1

By Mitchell Parrish and Kay Neth

Quorum Review IRB recently aired a webinar on how eConsent optimizes research for sponsors and CROs, and what organizations should look for when evaluating electronic informed consent solutions. Viewers had a lot of great questions, and we’re here to answer them all. In this first of three blogs, we will address questions related to compliance, security, and participant accessibility.

 

Compliance and Security

Q: A couple of viewers asked whether they should anticipate opposition from IT/Security teams and whether cloud-based solutions are now considered acceptable from a HIPAA privacy perspective.

A: There are certainly cloud-based systems that are HIPAA-compliant and, therefore, have regulatory-required security protections in place to ensure data privacy. For example, Amazon Web Services (AWS) offers a HIPAA-compliant cloud system. Please keep in mind that not all cloud-based systems are HIPAA-compliant, but the same thing goes for non-cloud based systems. The important thing in selecting an eConsent solution, whether it is a cloud-based system or not, is that the vendor should be able to speak to how their system is compliant with the HIPAA security regulations.

Whether sites run into trouble depends on the eConsent solution the site chooses. For example, a cloud-based, Part 11- and HIPAA security rule-compliant eConsent solution is secure and should not impact any of the site’s IT operations or security infrastructure. On the other hand, a site’s IT security department may take concern with an eConsent vendor who cannot substantiate its compliance with Part 11 and the HIPAA security rules.

Q: Two viewers wanted to know how tracking time spent on a particular consent form page impacts the validity of the consent, particularly when tracking metrics indicate that a participant did not read every word on the page. How will this show up in an audit, for example?

A: Tracking time is not a perfect gauge of whether a participant “read” a page or, more importantly, understood the page’s content. With eConsent, there must still be a consent discussion and the ability for participants to ask questions. It is this process that ultimately gauges whether the participant read and understood the consent form.

However, time tracking is a nice option to have in any eConsent solution, whether it indicates that a participant did or did not read a page, or from an aggregate data perspective, it signals the complexity or importance of a page to the participant population. This aggregate data can help drive decisions on improving the consent form for future studies.

We are in uncharted territory in terms of how the FDA may view time tracking data. Likely, the FDA would realize that the time a participant spends viewing a page is not the definitive determination of whether or not “the investigator has obtained the legally effective informed consent of the subject.” (21 CFR 50.20). Therefore, this would likely not be the key focus of an FDA inspection nor the sole reason for any FDA Form 483 observation pertaining to informed consent.

Nonetheless, this is understandably a concern. That is why, ideally, any eConsent solution that provides this functionality would offer flexibility for the research site to determine its policy on whether or not to use the functionality.

Q: Two viewers asked for more information about technology auditing for compliance with industry regulations, including HIPAA/HITECH and COPPA, with emphasis on documentation of the audit.

A: There is no entity that issues compliance certifications/licensures for eConsent. Compliance with applicable regulations is up to the eConsent technology provider (i.e. vendor) who developed and sells the eConsent. With certifications/licensures unavailable for eConsent, a third party independent assessment is the highest standard to which an eConsent technology provider can subject themselves. Keep in mind that the independent assessment should be performed by a reputable firm. The documentation that the eConsent technology provider would receive at the end of the assessment (i.e. audit) depends on the auditing firm.

Independent assessments of Part 11 and HIPAA security rule compliance are going to be the most common and are a must in terms of eConsent independent assessments. The eConsent technology provider should be willing to speak to such assessment, no matter who is requesting: research site, CRO, or sponsor. COPPA may not always apply based on the study in which the eConsent is being used. Therefore, an independent assessment of COPPA compliance is uncommon. Nonetheless, if requested, the eConsent technology provider should be able to speak to how their eConsent is compliant in those situations in which COPPA requirements apply.

Q: Email is not considered HIPAA-compliant. As a signed consent will include PHI, how is this generally handled in this eConsent process you have described?

A: As is the case with paper consent today or any eConsent solution, all respective parties involved are responsible for their own email systems and responsible for ensuring the security of these systems and any PHI. Email systems can be compliant with the HIPAA security rules, but most email systems are not. The reason is the security rules set forth requirements that, if implemented, can at times impact email’s basic functionality. As one small example, certain HIPAA security rule-required encryption may impact the ability for employees to read each other’s emails if reading these emails on a mobile device. In terms of a cost-benefit analysis then, companies often choose to store and communicate any information containing PHI through specific systems that are HIPAA compliant and choose to make their email systems secure, just not HIPAA security rule-compliant.

The webinar discussed that any eConsent solution should be HIPAA security rule-compliant due to the potential for PHI in the solution (e.g. a participant’s name on a signed consent form). The webinar also discussed emailing consent documents. When we talk about emailing consent documents, we are generally talking about emailing the template, non-signed version of the consent document that does not contain PHI. The point in the webinar was that an eConsent solution should have the ability to store signed consent forms, which participants can then access via the HIPAA-compliant eConsent solution. Moreover, the research site should also be able to access the signed consent forms. If the research site then decides to save a copy of the signed consent form on its own internal system then its system must be HIPAA-compliant. If the site wishes to email the signed consent form then its email system must be HIPAA-compliant. This is no different than today’s world regarding electronically storing or emailing signed consent forms.

For research sites, compliance with Part 11 and the HIPAA security rules are certainly a concern, which is why a Part 11- and HIPAA-compliant, cloud-hosted eConsent solution is ideal. As long as the signed consent form remains in the eConsent solution, where it can be viewed (and printed, if desired), then the site remains compliant.

Q: How can sponsors’ private details of the study be protected if the subject can forward the eConsent freely? Is this an issue for competitive intelligence between sponsors?

A: Questions in this area are understandable, given the ease with which digital information can be shared compared with hard-copy information. An e Consent solution should not increase risks in this area beyond risks that would be in place with a paper-based consenting process. The solution should include passwords to control who can access the consent form and supplementary material. Consider also that a paper consent form isn’t shielded from the possibility of digital distribution: hard copy documents can be scanned and shared via email or posted on a website site.

Consent forms routinely advise that prospective participants may discuss the study with their healthcare providers, family, friends, or anyone they choose. These conversations support prospective participants’ initial decision-making in choosing whether to join the study and ongoing decision-making in deciding whether to remain in the study as it progresses. Regardless of whether a consent form is a paper document or integrated into an eConsent application, the best way to ensure it is not a vector for uncontrolled distribution of competitive intelligence or proprietary information is to carefully consider its content. A consent form that provides useful information to a competitor is likely covering details that do not benefit prospective participants’ comprehension of a study or their decision whether to take part in it.

 

Participant Accessibility

Q: Several questions pertained to participants’ comfort with using new technologies and raised concerns over accommodation, selection bias, and how to navigate the consent discussion with that population.

A: While eConsent is the future of consent, there are certainly those participants who do not have access to a computer or who, in general, feel more comfortable with the paper process. Therefore, when selecting an eConsent solution, look for one that can accommodate the paper process if needed. Make sure the eConsent solution has a print function that prints the consent, allows the participant to read and sign the document on paper, and then has the ability to upload the signed document back into the system to still take advantage of the eConsent tool’s tracking, monitoring, and data features.

With the growing emphasis on recruitment and participant-centricity in research, an eConsent solution isn’t a solution at all if it doesn’t accommodate participant needs during the consenting process. A viable eConsent solution should not exclude participants who prefer paper or lack access to email or devices.

Look for an eConsent solution with functionality that allows sites to accommodate a paper process, including:

  • An eConsent tool should permit site staff (or prospective participants) to easily print the consent form if the prospective participant would like to review a paper document.
  • An eConsent tool should also allow participants to document their consent with either an eSignature (through the eConsent tool) or a handwritten (“wet”) signature on the paper. Further, the eConsent tool should also allow sites to easily document which participants have provided a handwritten signature.

 

More to Come

In Part 2 of this blog, Mitchell and Kay will address questions about site and sponsor roles and responsibilities, as well as the IRB review process for eConsent studies. Stay tuned!

Tags: , , , , , , , ,