Wearables in Deliverance Research: IRB Templates, Consent Language & Data Safeguards

Introduction: Why wearables need a bespoke IRB approach in deliverance research

Studies that use wearable biosensors (wristbands, rings, chest straps, or companion smartphone apps) to study episodes described as 'possession' or other deliverance‑related phenomena sit at the intersection of mental‑health assessment, sleep/paralysis research and sensitive cultural/spiritual contexts. These projects can yield objective physiological markers (heart rate, heart‑rate variability, skin conductance, motion, sleep staging proxies) but also raise elevated ethical, privacy, and legal concerns because data are often continuous, personally identifying, and may be stored or processed by third‑party vendors. Use clear IRB documentation, plain‑language consent, and pragmatic technical safeguards when designing such studies.

Below we present an IRB‑ready protocol outline, consent language snippets you can adapt, and concrete data‑protection measures that align with current agency guidance for digital health technologies and human‑subjects protections. Where applicable we call out regulatory touchpoints (Common Rule, FDA digital‑health guidance, HIPAA/BAA considerations) so your submission anticipates reviewer questions.

IRB protocol template: essential sections and suggested language

Use the following headings in your IRB protocol; adapt the language to your institution and device choices.

• Study title & objectives — Briefly state aims (e.g., "Characterize autonomic and sleep physiology during self‑reported deliverance or alleged possession episodes to differentiate sleep‑paralysis and other clinical presentations").
• Background & rationale — Summarize prior work on wearables in sleep/paralysis and mental‑health contexts; cite evidence that sensors provide feasible objective correlates.
• Population & recruitment — Inclusion/exclusion criteria, vulnerability assessment (minors, cognitively impaired persons); plans for translation/low‑literacy consent if relevant.
• Device and data flow diagram — Describe each step from sensor → smartphone → manufacturer cloud → aggregator → institutional storage. Provide a diagram and name vendors, APIs, and storage regions. (Regulators expect a clear data flow.)
• Risk assessment — Classify device risk (research‑grade vs. consumer), physical risks (skin irritation), privacy risks (continuous physiologic or GPS data), and psychological risks (triggering rituals or stigma). Address mitigation plans.
• Safety monitoring & adverse events — Define what constitutes an adverse event (e.g., sync errors exposing PHI, participant distress during a documented event) and provide reporting lines to the IRB and sponsor.
• Data management & retention — State retention periods, de‑identification strategy, who can access raw vs. processed data, and secure deletion procedures.
• Vendor contracts — Document Business Associate Agreements (BAAs) or other legal controls when third parties will create/receive/store PHI. If vendors are not BAAs, explain additional participant protections and limitations.
• Statistical & analytic plan — Pre‑specify primary signals, preprocessing, and re‑identification risk assessment for data releases.
• Consent & confidentiality — Attach the consent form (see next block for language). Ensure readability and document translation plans.

Attach vendor documentation (security whitepapers, SOC2/HITRUST attestations, and API details) as appendices to speed IRB review. Many IRBs now expect a brief explanation whether any device or app may be regulated by FDA and, if so, how you are addressing those requirements.

Sample consent language: clear, specific, and adaptable

Below are short, plain‑language paragraphs you can adapt. Keep forms modular: a general study description + a digital‑health (wearable‑specific) addendum. Use the NIH "Points to Consider" resource as a checklist when building these sections.

1) What we will collect

"You will wear a small sensor on your wrist (or ring/chest strap) and use a study app on your phone. The device will record heart rate, movement, and sleep‑related signals. Data will be collected continuously while you wear the device and uploaded to secure servers when your phone is connected to the internet. We will also ask you to complete short event logs and brief surveys after episodes. Specific data types: timestamps, heart rate, accelerometry, device battery/diagnostic logs; we will not collect audio without separate written permission."

2) Who will see your data and where it will be stored

"Raw sensor data may be transmitted to the device manufacturer and/or a cloud vendor as part of normal device operation. The university research team will then download data to our secure server (hosted in [location]) for analysis. Only named study staff will have access to identifiable data. We will use encryption in transit and at rest. If a vendor is storing data on our behalf, we will attempt to have a BAA in place; if a BAA is not feasible, we will explain what the vendor does with data and the additional risks involved."

3) Privacy risks and re‑identification

"Even after removing names, physiological and timestamped location data can sometimes be re‑identified. We will minimize risk by removing direct identifiers, aggregating or blurring timestamps/geolocation where possible, and limiting data shared outside the core study team. However, absolute anonymity cannot be guaranteed."

4) Voluntary participation and withdrawal

"Participation is voluntary. You may stop wearing the device or withdraw at any time. If you withdraw, you can request deletion of identifiable data collected to date; aggregated or de‑identified data already used in analyses may not be removable. Withdrawal will not affect your access to usual medical care."

5) Future use and data sharing

"We may share de‑identified datasets with external researchers or deposit them in a controlled repository. You will be asked to opt‑in for future unspecified research uses, and a separate checkbox will be provided."

Include a short FAQ and contact details for the IRB and study PI so participants can ask about data flows, device security, or spiritual concerns about participation—both issues are relevant in deliverance contexts and help build trust during consent.

Data safeguards: technical, administrative and contractual controls

Below is a compact checklist investigators should include in the IRB submission and operational plan. Cite vendor security documentation and show how institutional policies map to each control.

Control Category	Actionable Measures
Data minimization	Collect only signals needed for the stated aims; disable optional telemetry (e.g., GPS) unless essential.
Encryption	Encrypt data in transit (TLS 1.2/1.3) and at rest using FIPS‑validated algorithms; document key management practices.
Vendor oversight	Obtain BAAs for any vendor that will create/receive/maintain PHI; request SOC2/HITRUST reports or equivalent. If vendor is not a business associate, disclose that to participants and list attendant risks.
Access control & logging	Implement least privilege, multifactor authentication for staff, and audit logs for data exports. Retain logs for IRB‑specified period.
De‑identification & data release	Use randomized IDs, remove direct identifiers, mask timestamps/locations, and require data‑use agreements for external researchers. Perform a re‑identification risk assessment before any public release.
Incident response	Document breach notification timelines, IRB and institutional contact points, and plan for notifying participants and regulators where required (FTC/HHS OCR). Keep template notifications ready.
Regulatory alignment	State whether collected data will be considered PHI under HIPAA (depends on whether a covered entity or BAA is involved) and reference FDA guidance if the wearable is being used as a medical device in the study. Provide IRB with a short legal/regulatory memo.

Operational tips: schedule firmware updates outside monitoring windows; train staff to answer participant questions about vendor privacy; log and version analytic pipelines so processed data can be audited by the IRB or external reviewers.

Finally, include a short plan for community/pastoral liaison and aftercare: because deliverance research often intersects with faith communities and trauma, provide participants with resources (mental‑health referral, chaplain contact) and describe how the study will avoid amplifying stigma or causing spiritual harm. Document these protections in the protocol and consent materials.

For practical templates and sample consent language tailored to digital health technologies, the NIH resource is recommended reading; FDA and HHS guidance provide the regulatory context for device use and cloud storage.