Security and compliance
Patient Journey Intelligence is deployed within your own infrastructure - on-premises or private cloud - and provides the network isolation, identity controls, encryption, and audit logging a regulated healthcare environment requires. This page covers what the platform provides and what your team needs to configure for a production deployment: network isolation, identity and access management, encryption, and the audit infrastructure your compliance team will need.
Network isolation
Patient Journey Intelligence is designed to run in a private subnet with no direct internet exposure. The application servers, databases, and processing infrastructure operate in a network environment isolated from internet-facing connections. Access is controlled through specific, monitored pathways - not open endpoints.
Private subnet deployment. The platform never accepts connections directly from the public internet. Configure all inbound access through your organization's controlled ingress points.
Secure remote access. For remote users or integrated cloud services, use VPN or AWS PrivateLink. These ensure every connection is authenticated, encrypted, and logged. Remote access does not mean public access.
Network segmentation. Isolate Patient Journey Intelligence from general IT infrastructure using network zones with distinct trust levels. This limits lateral movement: a compromised workstation on the corporate network cannot reach the analytics platform if network policies block that path. Segment analytics workloads from production clinical systems and administrative networks from data processing zones.
Web application firewall. Enable a WAF to filter HTTP/HTTPS traffic before it reaches the platform. This blocks SQL injection, cross-site scripting, and malicious bot traffic targeting the web interface.
Identity and access management
Patient Journey Intelligence integrates with your existing identity infrastructure through Keycloak, supporting SAML 2.0 and OIDC connections to your SSO provider. Access is governed by the same identity policies you apply across the rest of your environment.
SSO and MFA
Connect Patient Journey Intelligence to your SAML 2.0 or OIDC identity provider and enforce multi-factor authentication at the IdP level. If a password is compromised through phishing or a credential breach, MFA prevents unauthorized access. Authentication requires proof of identity beyond a shared secret.
Role-based access control
The platform provides predefined roles, each scoped to the permissions that role actually requires:
| Role | Access scope |
|---|---|
| Researcher | De-identified datasets assigned to their projects |
| Data Analyst | Pipeline execution and query access; no administrative privileges |
| Registrar | Registry abstraction workflows; no access to full patient datasets |
| Reviewer | Reviews cases abstracted by registrars; no access to full patient datasets |
| Registry Manager | Manager for the registry projects; read access to full patient datasets |
| Administrator | System configuration and user management; no direct database access |
| Auditor | Read-only access to audit logs and compliance reports |
A researcher analyzing oncology data gets access to oncology datasets, not the full platform. RBAC limits blast radius: a compromised or misused account can only reach what that specific role can access.
Audit logs
Every access and administrative action is logged with user identity, timestamp, and operation. When an action is taken on patient data, audit logs record which named person did it - not a generic service account or shared credential. These logs are available for your compliance team's review and support HIPAA audit control requirements.
Named accounts, not default credentials
Disable or remove default accounts on deployment. Replace them with named accounts tied to specific individuals. Audit logs are only useful when they identify people - a log entry showing "admin" performed an action is not an audit trail.
Access reviews
Conduct quarterly reviews to verify that current permissions remain appropriate. People change roles, projects end, and formerly necessary access becomes unnecessary. Access reviews catch permission creep - the gradual accumulation of rights as users move between projects without old permissions being removed - and identify orphaned accounts or overprivileged users.
Encryption
Encryption at rest. Enable encryption at rest for all Patient Journey Intelligence storage - databases, file systems, object storage, and persistent volumes. If storage media is decommissioned or accessed without authorization, encrypted data is unreadable without the decryption keys. The performance overhead on contemporary hardware is negligible.
TLS 1.2 or higher in transit. All data transmission - between users and the platform, between platform components, and between the platform and integrated systems - requires TLS 1.2 or higher. Older protocol versions have known vulnerabilities. Enforcing modern TLS ensures strong ciphers without practical attacks and satisfies regulatory requirements for data in transit protection.
Customer-managed encryption keys. Use your own encryption keys rather than default cloud provider keys. With customer-managed keys, your organization controls key rotation, access policies, and key lifecycle. You can revoke keys if needed, rendering encrypted data permanently inaccessible. Even a compromised cloud credential does not expose patient data without also compromising your separate key management infrastructure.
Encrypted backups. Apply the same encryption standard to all backups. Backup media contains identical patient data to production systems. An unencrypted backup archive is a complete copy of protected health information in readable form. Encrypted backups protect against media theft, unauthorized storage access, and accidental exposure during backup movement between systems.
Deployment configuration checklist
Patient Journey Intelligence provides the controls above. A production deployment in a regulated healthcare environment also requires configuration on your side:
- Place the platform within a private subnet with no direct internet access
- Route all user and service access through your VPN or PrivateLink configuration
- Connect Keycloak to your SSO provider and enforce MFA at the IdP level
- Enable customer-managed encryption keys before ingesting patient data
- Configure network segmentation to isolate analytics workloads from clinical and administrative systems
- Enable WAF protection on the platform's web endpoints
- Schedule quarterly access reviews as part of your AI governance process
HIPAA and GDPR alignment
The deployment model - on-premises or private cloud, no external data movement, customer-managed keys, full audit logs - is designed to support HIPAA Security Rule and GDPR technical safeguard requirements.
| Requirement | Control |
|---|---|
| HIPAA § 164.312(a)(1) - Access controls | RBAC and SSO/MFA integration via Keycloak |
| HIPAA § 164.312(b) - Audit controls | Complete access and action logging with named user attribution |
| HIPAA § 164.312(c)(1) - Integrity controls | TLS in transit and encrypted storage at rest |
| HIPAA § 164.312(e)(1) - Transmission security | TLS 1.2+ enforced for all data transmission |
| GDPR Article 25 - Privacy by design | On-premises deployment with no external data movement |
| GDPR Article 32 - Technical security measures | Encryption at rest and in transit, access controls, audit logging |
Your compliance and legal teams should verify specific control mappings against your organization's risk analysis and BAA scope.
Vulnerability management
John Snow Labs runs continuous automated vulnerability scanning across Patient Journey Intelligence infrastructure, applications, and software dependencies. Critical vulnerabilities with active exploits receive emergency patches within hours. Standard severity issues follow a structured patch management cycle balancing security urgency with change control discipline. Patch status and remediation timelines are available to customers on request to support your compliance reporting.
FAQ
The platform integrates with your identity infrastructure through Keycloak, which supports SAML 2.0 and OIDC connections. You connect your existing SSO provider to Keycloak and enforce MFA at the IdP level. This means Patient Journey Intelligence access is governed by the same identity policies, MFA requirements, and session controls you apply across the rest of your environment.
The platform provides seven predefined roles - Researcher, Data Analyst, Registrar, Reviewer, Registry Manager, Administrator, and Auditor - each scoped to the permissions that role requires. Each role's access scope follows the principle of least privilege so that no role accumulates more access than its function requires.
Patient Journey Intelligence provides controls that map to HIPAA § 164.312(a)(1) (access controls via RBAC and SSO/MFA), § 164.312(b) (audit controls via comprehensive action logging), § 164.312(c)(1) (integrity controls via TLS and encrypted storage), and § 164.312(e)(1) (transmission security via TLS 1.2+ enforcement). Your compliance team should verify these mappings against your organization's risk analysis and BAA scope.
This page covers technical security controls: network isolation, identity management, encryption, and audit logging. Data Governance covers fact-level provenance, versioning, and audit trails for clinical data. AI Governance covers model transparency, confidence scoring, and human-in-the-loop controls for AI outputs.
Related pages: Data Governance · AI Governance