Protecting patient data is not a feature; it is our fundamental architecture. Built for CISOs, compliance officers, and health systems that demand zero compromises.
Granular access controls and modern authentication protocols ensure only authorized personnel access the NightingaleMD platform. No generic accounts, no weak links.
Seamless integration with your existing identity provider via SAML 2.0 & OpenID Connect. Plugs directly into Microsoft Entra ID, Okta, Google Workspace, and Ping Identity.
Require Multi-Factor Authentication for all administrative and user logins.
Automated user provisioning and deprovisioning synchronized directly with your HRIS or IT directory.
System natively rejects shared or generic accounts. Every action maps to a specific, unique human identity.
For non-SSO contexts, we enforce rigorous cryptographic and behavioral standards.
Most platforms rely solely on the application layer to separate tenant data. We implement an unbypassable, engine-level security model ensuring true data isolation.
All network traffic is strictly forced to TLS 1.2+ (lower protocols disabled). At rest, all PostgreSQL instances, backups, and read replicas utilize AES-256 block-level encryption.
Tenant isolation occurs at the database engine level. Even if the application logic suffers a flaw, the database categorically rejects queries for unauthorized tenant rows.
All compute nodes, primary databases, backups, and disaster recovery environments are geo-locked to United States AWS regions.
Artificial Intelligence in healthcare requires strict bounding boxes. Our LLMs act as intelligent assistants, heavily restricted by the same security policies that govern humans.
The AI operates under the exact same identity/RBAC context as the user invoking it. It cannot read or synthesize data the human user cannot naturally see.
We maintain strictly negotiated Data Processing Agreements (DPAs) with LLM providers ensuring patient query data is dropped immediately and never used for model training.
AI acts as a co-pilot. For any action modifying clinical state, the system stops and requires explicit, logged human approval before execution.
Instruction synthesis occurs on secure backend servers. Input sanitization and structural separation of instruction vs. data prevent malicious query escalation.
Serverless architecture deployed across multiple availability zones. No single point of failure. Automated database failover with point-in-time recovery to the second.
Every API request, login event, and AI generation is immutably logged with Timestamp, Actor IP, User ID, and Payload. Tamper-evident architecture.
Configurable IP-based geofencing restricts platform access to authorized hospital network perimeters or specific VPN exit nodes.
NightingaleMD maps its security controls to industry-standard frameworks, assessed annually by independent third-party auditors.
Detailed answers to the security and compliance questions healthcare organizations ask most.
NightingaleMD supports single sign-on through SAML 2.0 and OpenID Connect and can plug directly into your existing identity provider (e.g., Microsoft Entra ID). All tokens and credentials are hashed and encrypted before being stored — plaintext secrets are never persisted. We also support SCIM 2.0 for automated user provisioning and deprovisioning, so user access stays in sync with your directory. If SSO is not preferred, we maintain a standalone authentication system with full password policy enforcement, MFA, and session management.
NightingaleMD supports MFA natively. If your organization has an existing MFA solution (e.g., Microsoft Authenticator via Entra ID), MFA is handled at the IdP level during SSO — no additional configuration needed on our side. If you prefer MFA managed within our platform, we support TOTP (authenticator apps), one-time passcodes delivered via email or SMS, and automatically generated encrypted backup codes for account recovery. MFA can be enforced for all users or scoped to specific roles and access scenarios, including remote access.
All password requirements are configurable within our authentication framework. Passwords are hashed using Argon2id. Minimum length, complexity rules, expiration (e.g., 90-day), reuse history (e.g., last 5 passwords), lockout thresholds (e.g., after 5 failed attempts), and idle session timeout (e.g., 15 minutes) are all set through server-side configuration. Sessions are cookie-based with configurable expiration and automatic revocation on password change.
Every user is assigned a unique account tied to a verified identity. Generic and shared accounts are not supported by design. Access control is enforced through a multi-tenant RBAC system built on a defense-in-depth model. Permissions are evaluated at two independent layers: the API/application layer (role-based) and the database layer (PostgreSQL Row-Level Security). Even if application-layer logic were bypassed, the database itself would reject unauthorized access. Roles can be scoped to organizations and nested entities, supporting hierarchical access.
NightingaleMD is deployed on cloud infrastructure that enforces TLS 1.2+ at the edge. Lower protocols (TLS 1.1, 1.0, SSL) are disabled at the infrastructure level. All database connections are encrypted in transit over TLS as well. Data at rest is encrypted using AES-256 by default on all managed PostgreSQL instances — this applies to primary storage, automated backups, and replicas. Encryption is handled at the storage layer by the cloud provider and is the baseline configuration, not optional.
NightingaleMD enforces tenant isolation at the database level using PostgreSQL Row-Level Security (RLS). Every table containing client data is governed by RLS policies that scope all reads and writes to the authenticated tenant. This is not application-level filtering — it is enforced by the database engine itself. A query executed in the context of one tenant is structurally unable to access another tenant's rows, regardless of what the application layer does.
All production infrastructure — application servers, databases, and backups — is hosted within US regions. All cloud infrastructure regions (compute, database, backups, disaster recovery) are explicitly configured to US-only regions. No data replication or failover targets outside the US. All personnel with access to client PHI data are based in the United States.
All AI-driven interactions operate under the same authentication and authorization path as any human user — bound to that user's session token, tenant, and role. The AI cannot escalate its own permissions. No customer data is used for model training; all inference is performed via API under data processing agreements that contractually prohibit training on input/output data. Write operations initiated by the AI are staged, not executed — a human reviews and confirms before they are committed. This human-in-the-loop model is configurable per action. All actions, AI-initiated or otherwise, are logged with full audit trails.
Every action in the system is logged at the API layer — including the authenticated user, action performed, request payload, and response. Authentication events (login, logout, failed attempts, MFA challenges) are captured as well. Logs are structured and exportable in standard formats for ingestion by your SIEM or SOC tooling.
NightingaleMD runs on serverless infrastructure with no single point of failure. Compute scales automatically and recovers without manual intervention. Database failover is handled by our managed PostgreSQL provider with automated backups and point-in-time recovery. Multi-region read replicas can be configured for additional redundancy or geographic failover.
Schedule a deep-dive call with our security engineering team. We're ready to complete your vendor risk assessment and discuss custom implementation requirements.
