Patient Privacy & Data Handling
Patient data handling your IRB and sponsors can document
Cohortbridge is designed with HIPAA administrative, technical, and physical safeguards throughout the patient matching pipeline. This page describes the architecture your procurement team will ask about.
What Cohortbridge does — and does not — claim about patient data
What we state
- Designed with HIPAA administrative, technical, and physical safeguards
- IRB-compatible data flow — we provide architecture documentation for your IRB submission
- FHIR R4-based integration — a published, auditable standard
- De-identified cohort output — no patient names, MRNs, or direct identifiers in the matching results
What we do not claim
- HIPAA "compliant" or "certified" — Cohortbridge has not undergone formal HHS certification
- That Cohortbridge replaces your organization's HIPAA BAA obligations — you retain responsibility for your BAA with participating health systems
- That our data flow eliminates the need for IRB review — IRB authorization requirements depend on how your organization and health system define the research activity
Administrative, technical, and physical safeguards
Administrative Safeguards
Designated privacy officer. Workforce training on patient data handling. Data use agreements executed before any EHR access. Protocol-specific access scoping — staff access only the protocol cohorts they are assigned to.
Technical Safeguards
Unique user identification per staff member. Automatic session timeout. Encryption in transit (TLS 1.3) and at rest (AES-256). Access logs maintained for all data queries. De-identification layer enforced at API output level — no query returns identified patient records.
Physical Safeguards
Infrastructure hosted in SOC 2-audited data centers with physical access controls. On-premise deployment option for health systems with strict data residency requirements — in this configuration, all processing occurs within the health system's physical infrastructure.
De-identification process
Patient EHR data is processed at the health system boundary. The matching engine evaluates structured field values (ICD codes, lab values, demographics as ranges) against protocol criteria logic — but the output of this matching process contains no direct patient identifiers.
The de-identification layer removes: full name, date of birth (replaced with age range), medical record number, social security number, full ZIP code (replaced with 3-digit prefix where population > 20,000), admission dates, geographic identifiers smaller than state, and all other HIPAA Safe Harbor identifiers before any data is transmitted to Cohortbridge infrastructure.
Role-based access and protocol isolation
Role-based access
Each CRO staff member is assigned to specific protocols only. A feasibility analyst working on Protocol A cannot access Protocol B cohort data, even within the same organization.
Unique user authentication
No shared login credentials. Each user account requires unique authentication. Multi-factor authentication available for organizations that require it.
Session timeout
Automatic session expiry after inactivity. Cohort data is not cached in browser state after session end.
Sponsor data isolation
Cohort data from Sponsor A's protocol is logically isolated from Sponsor B's protocol, even when the same CRO is managing both. CRO staff only see cohorts for protocols they are explicitly assigned to.
Every query, every access — logged
Cohortbridge maintains an immutable audit log of all data access events: EHR query executions, cohort output retrievals, user logins, and protocol setup changes. Audit logs are retained for a minimum of 6 years and are available to your compliance team and your sponsors for audit and regulatory review.
The audit log format is compatible with common CTMS and eTMF systems for sponsor filing. Cohortbridge provides audit log exports in CSV and JSON formats upon request.
ACTION cohort_query_run
user=u_4821 | protocol=XY-2024-003 | site=HS-007 | records_evaluated=1842 | cohort_size=43
ACTION cohort_output_accessed
user=u_4821 | protocol=XY-2024-003 | ip=10.x.x.x
ACTION user_login_success
user=u_4821 | mfa=true
Our role in the patient data ecosystem
Cohortbridge is a tool used by CRO and health system staff to identify potentially eligible patients — it is not a patient-facing system. Patients have rights under HIPAA that are exercised through their healthcare provider, not through Cohortbridge.
How patient consent works in the Cohortbridge model
Cohortbridge does not contact patients. The matching output identifies potentially eligible patients to the site's clinical staff. Consent for trial participation — if any is indicated — is obtained by the health system's clinical team under their existing IRB authorization. Cohortbridge does not retain a mapping between our cohort reference IDs and patient identities accessible to CRO staff.
Questions about our data architecture?
Our clinical informatics team is available to walk through the data flow documentation with your IRB, legal, or compliance team. We provide architecture diagrams and data flow descriptions for IRB submissions on request.