This summary explains how TrialsNest is designed to handle data for patient recruitment, coordinator operations, sponsor reporting, and administrative workflows. It is intended for customer review and should be aligned with the applicable agreement, Business Associate Agreement when required, and customer policies.
Data categories
TrialsNest may process account information, role assignments, study information, site information, sponsor information, patient application details, prescreening responses, scheduling details, coordinator notes, outreach records, message records, document metadata, document upload/download events, sponsor reporting data, audit events, and support/security information.
TrialsNest should not receive data that the customer is not authorized to provide.
Hosting boundary
The frontend is hosted separately from the PHI-processing backend. Frontend code must not contain database credentials, AWS access keys, private S3 credentials, Twilio secrets, EHR secrets, or other backend secrets.
PHI-processing backend logic is handled through AWS API Gateway and Lambda. The active backend function is `clinical-recruiting-api-dev-v2`.
Authentication and roles
TrialsNest uses Cognito-backed authentication and role-aware access controls. Current roles include patient, coordinator, site admin, sponsor, and admin.
Direct role claims should take priority over Cognito group claims. Public signup should default to patient and should not allow public users to select privileged roles.
Storage and encryption
Application records are stored in private AWS RDS infrastructure. The reviewed development RDS instance is private and encrypted.
Document storage should remain private, block public access, and use encryption appropriate to the deployment. Lifecycle rules should not delete completed patient documents unless the retention policy and customer agreement allow it.
Audit logs and operational logs
TrialsNest records audit events for important application, coordinator, admin, consent, status, outreach, document, and access activities.
Operational logs should be sanitized. Logs must not include patient names, email addresses, phone numbers, dates of birth, medical histories, diagnoses, medication names, prescreen answers, note bodies, message bodies, document contents, document keys, JWTs, authorization headers, cookies, database credentials, AWS secrets, Twilio secrets, raw database rows, or SQL queries with values.
Retention
Retention durations vary by record type, customer agreement, legal requirement, and operational need. Retention and disposal should follow the Data Retention and Disposal Policy and the applicable customer agreement.
Audit records, consent evidence, patient authorization records, security records, and legal hold records should not be deleted solely for cost reduction.
Customer responsibilities
Customers should ensure that study content, eligibility criteria, recruitment language, outreach templates, consent workflows, data uploads, user access, role assignments, and sponsor/site relationships are accurate and authorized.
Customers should promptly request access removal when users no longer need access and should report suspected incidents or unauthorized access.
Review status
This summary is an operational and customer-facing starter document. It should be reviewed by legal, privacy, security, and customer stakeholders before production use.