Skip to content

Compliance Built In.
Not Bolted On.

Every line of code, every database query, every API endpoint in PharmaTrialsCortex is designed with regulatory requirements from day one. We don't retrofit compliance — we architect it.

Compliance in Detail

Click any framework below to see exactly how PharmaTrialsCortex implements each requirement. No vague promises — specific technical controls.

Electronic Records (Subpart B — §11.10)

  • Immutable audit trails with field-level change tracking, timestamps, user identification, and reason-for-change — §11.10(e)
  • Role-based access control with granular permissions and site-level data isolation — §11.10(d)
  • Computer-generated, time-stamped audit trails that cannot be modified or deleted — §11.10(e)
  • Operational system checks enforce visit scheduling order, form dependencies, and workflow state machines — §11.10(f)
  • Authority checks at view, API, and model levels with e-signature re-authentication — §11.10(g)
  • Ability to generate accurate and complete copies via PDF export and CDISC ODM — §11.10(b)
  • Configurable retention periods (default 25 years) with no hard deletes and encrypted backups — §11.10(c)

Electronic Signatures (Subpart C — §11.50–§11.300)

  • Signature manifestation includes printed name, date/time, and meaning of signature — §11.50
  • Cryptographic binding of signature to record (hash-based) prevents separation — §11.70
  • Unique user identification — one-to-one user:signature mapping, no shared accounts — §11.100
  • Password controls: minimum 12 characters, Argon2id hashing, account lockout after 5 failed attempts — §11.300
  • Session timeout after 15 minutes of inactivity — enforced server-side

Data Protection Principles (Article 5)

  • Configurable legal basis per study — consent, public interest, or legal obligation
  • Purpose limitation enforced through study-level access controls and metadata
  • Data minimisation — eCRF builder enforces minimum-necessary fields per protocol
  • Accuracy controls via edit checks, query management, and source data verification
  • Storage limitation with configurable retention periods and automated archival
  • Integrity and confidentiality via AES-256 encryption, TLS 1.3, and access controls

Data Subject Rights

  • Right of Access (Art 15) — participant data export in machine-readable format
  • Right to Rectification (Art 16) — data correction workflow with full audit trail
  • Right to Erasure (Art 17) — anonymisation workflow (clinical trial retention overrides hard deletion)
  • Right to Data Portability (Art 20) — JSON/CSV and CDISC ODM export formats
  • Right to Object (Art 21) — withdrawal of consent workflow with data flagging
  • All AI features are advisory only — no automated clinical decisions (Art 22)

Technical Measures

  • Field-level PII encryption via pgcrypto — participant identifiers encrypted at rest
  • Pseudonymisation — all clinical data identified by Subject ID, PII stored separately
  • Configurable data residency — EU-only, US-only, or global deployments
  • Automated breach detection with anomaly monitoring on access patterns
  • Data Processing Agreement templates for vendor relationships

Administrative Safeguards

  • Security officer designation and workforce training tracking
  • Risk analysis and management procedures
  • Contingency planning with backup and disaster recovery
  • Business Associate Agreement templates provided

Technical Safeguards

  • Unique user identification with emergency access procedures
  • Automatic session logoff after 15 minutes of inactivity
  • AES-256 encryption at rest for all Protected Health Information
  • TLS 1.3 encryption in transit — no exceptions
  • Comprehensive audit logging with anomalous access alerts
  • Data validation and integrity controls with checksums

PHI Handling

  • Minimum necessary standard enforced through RBAC and site-scoped queries
  • De-identification tools for data export and secondary use
  • Encrypted backups with key rotation policies
  • Access logs reviewed for compliance monitoring

Core GCP Principles

  • eCRF data serves as source data when entered directly at point of care — §4.9
  • Study configuration enforces protocol compliance and data validation at point of entry — §5.5
  • Clear source identification for all data entries with timestamps and user attribution
  • No deletion of clinical data — all changes via amendment with documented reason — §5.5.12

Monitoring & Data Quality

  • Field-level Source Data Verification tracking with remote SDV support — §5.18.4
  • Risk-based quality management with configurable Key Risk Indicators — E6(R3)
  • Centralised monitoring dashboards with site risk scoring
  • Query management system with automated query rules for proactive data cleaning

Security

  • Seven-layer defence-in-depth architecture from network to monitoring
  • Web Application Firewall, DDoS protection, and IP allowlisting
  • Multi-factor authentication with OAuth 2.0 and brute-force protection
  • Input validation, CSRF protection, XSS prevention, SQL injection protection

Availability

  • Health check endpoints with automated monitoring and alerting
  • Database replication and encrypted backup procedures
  • Celery-based task queue for reliable background processing
  • Infrastructure designed for auto-scaling and high availability deployment

Confidentiality

  • Field-level PII encryption — not just volume-level encryption
  • Role-based access control with site-level data isolation
  • Session management with strict timeout and secure cookie policies
  • HSTS with 1-year max-age and preload for all connections

Organisational Controls

  • Security policies documented and maintained in version-controlled repository
  • Role-based access control with separation of duties across clinical and data management functions
  • Incident response procedures with breach notification workflows
  • Change management via CI/CD pipelines with automated security scanning

People Controls

  • User training tracking with acknowledgement required before access
  • Account provisioning and deprovisioning workflows
  • Password policy enforcement: complexity, expiration, and lockout controls

Technological Controls

  • AES-256 encryption at rest, TLS 1.3 in transit
  • Immutable audit trails for all system access and data changes
  • Automated vulnerability scanning in CI/CD pipeline (Bandit, Safety)
  • Monitoring with SIEM integration points and anomaly detection
  • Secure development lifecycle with pre-commit hooks and code review requirements

Why Native Compliance Matters

Most EDC vendors bolt on compliance as an afterthought. That approach creates gaps that surface during audits, inspections, and regulatory submissions.

Bolt-On Compliance

  • Audit trails added retroactively — gaps in early records
  • Encryption applied at volume level only — PII exposed in memory
  • RBAC added as middleware — bypassed by direct database access
  • Compliance documentation maintained separately from code
  • Expensive third-party validation for every release

Native Compliance (PharmaTrialsCortex)

  • Immutable audit trails from day one — no gaps, no exceptions
  • Field-level PII encryption with pgcrypto — encrypted at the data layer
  • RBAC enforced at model, view, and API levels — no bypass path
  • Compliance tests in CI/CD — every commit is verified automatically
  • Validation built into the release pipeline — not a separate project
6
Regulatory Frameworks
7
Security Layers
100%
Audit Trail Coverage
0
Hard Deletes Possible

Ready to See Compliance in Action?

Book a compliance-focused demo. We'll walk you through our audit trails, encryption architecture, and RBAC controls — with your compliance team present.