Security & Trust Center

NEDOCS supports multi-factor authentication for all customer accounts, with two methods. The default method emails a 6-digit one-time code to the account email address (which is also the username); the alternative is an app-based TOTP (RFC 6238) authenticator (Google/Microsoft Authenticator, 1Password, Authy) enrolled by scanning a QR code. After a correct password the user is challenged for the code before a session is established. Email codes expire in 10 minutes and are stored only as SHA-256 hashes; TOTP secrets are encrypted at rest. MFA can additionally be mandated for privileged roles via configuration.

SAML/OIDC SSO is on the roadmap. In the interim, password policy and MFA have been strengthened: minimum 8 characters with upper/lower/number complexity, TOTP MFA, brute-force lockout, and forced password change on reset.

Enforced centrally on account creation, password reset, and password change (config.security.minPasswordLength; validatePassword). Length is configurable per deployment.

AccessFailedCount is incremented on each failed sign-in; on reaching the threshold LockoutEnd is set and further attempts are refused until it elapses. A successful sign-in resets the counter.

Role-based access control (Administrator, NEDOCS, manager, User) is enforced by middleware on every protected route. Hospital-scoped data isolation ensures users only see their own organization's data (least privilege).

Accounts receive only the roles required for their job function; hospital data is logically segregated per tenant.

Authenticated sessions are invalidated after 30 minutes of inactivity (SESSION_IDLE_TIMEOUT_MINUTES). Session cookies are HTTP-only, SameSite=Lax, and Secure in production, with an 8-hour absolute lifetime.

Sessions are stored server-side in MongoDB; the acceptable-use policy prohibits generic/group email accounts as primary account identities.

Data is encrypted at rest at two layers: (1) application-layer field encryption using AES-256-GCM for sensitive fields (MFA/TOTP secrets, phone numbers, one-time verification codes), keyed by a 256-bit data key (DATA_ENCRYPTION_KEY); and (2) full-volume/database encryption provided by the hosting tier. Password material is stored only as PBKDF2-HMAC-SHA256 hashes (100k iterations); reset tokens as SHA-256 digests.

All traffic is served over HTTPS/TLS 1.2 or higher. HTTP Strict Transport Security (HSTS) is enabled in production. HL7/EHR ingestion requires TLS 1.2+.

Application data keys are provisioned via secrets management (environment-injected, never committed) and rotated per policy. Hosting-tier keys are managed by the cloud provider's KMS. Guidance follows NIST SP 800-57.

AI features send de-identified/synthetic operational inputs only; any retained data is encrypted with AES-256 at rest and TLS 1.2+ in transit.

A system architecture and data-flow diagram is published on the Trust Center. It shows browser/EHR clients, the TLS boundary, the Express application tier, network segmentation between the public marketing site and the authenticated app, the MongoDB data tier with encryption at rest, and the external LLM inference boundary (de-identified inputs only).

Security is embedded in the SDLC: peer code review, automated code scanning before production, dependency review, staged test-before-production deployment, and rollback procedures via the change-management process.

Server-side input validation, parameterized database access, output encoding in templates, and CSRF-resistant session cookies (SameSite).

Sensitive identifiers are never placed in URLs; the evaluation tier processes no PHI.

Static analysis and automated code scanning run pre-production today (compensating control). A continuous DAST capability against the production surface is being onboarded.

Documented OpenAPI 3.1 spec at /api/openapi.json. Each hospital is issued a scoped API key; keys are managed in Settings and can be rotated/revoked. PHI is not persisted — only synthesized flow metrics.

Server-side request logging, authentication events (including MFA and lockout), agreement-acceptance audit records, and HL7 ingestion events are captured with source, timestamp, actor, and outcome.

Agreement-acceptance records (timestamp, user, IP, user-agent, version) are stored in an immutable audit collection. Logs can be forwarded to a customer SIEM.

Compensating controls in place today: least-privilege access, encryption at rest and in transit, egress restrictions, and monitoring/alerting on the hosted environment. A dedicated DLP tool is being evaluated.

An independent third-party penetration test is scheduled. Compensating controls today: internally conducted testing, automated vulnerability scanning, and pre-production code scanning. Results will be available to customers under NDA.

Changes are peer-reviewed, validated in a test environment before production, deployed via a documented process, and support rollback. Unauthorized changes are detectable via version control and deployment controls.

AI-assisted and automated code scanning run before production; AI-generated code is reviewed and validated against secure-development standards.

I AM GRACE INC. has completed a SOC 2 Type II examination of the NEDOCS service covering Security, Availability, and Confidentiality Trust Services Criteria. The report attests that controls were suitably designed and operated effectively throughout the examination period. Available to qualified customers and assessors under NDA on request.

Clarification: NEDOCS is designed as a HIPAA business-associate-ready service. The self-serve evaluation tier operates without PHI (attested at signup and re-acceptance). When a hospital moves to production use with PHI, I AM GRACE INC. executes a Business Associate Agreement and acts as a Business Associate under 45 CFR 160.103. Data-input sensitivity and the no-PHI evaluation boundary are documented in the Compliance page and Privacy Policy.

Material sub-processors and vendors that may access confidential or personal data are bound by written confidentiality and data-protection agreements; where PHI is in scope, business-associate or equivalent contractual protections apply. Employees also sign confidentiality agreements as a condition of employment.

Incidents are triaged by severity with defined escalation paths; incident logs are stored separately from application databases.

NEDOCS does not train foundation models. AI-assisted features (shift-debrief summarization, forecasting) call a third-party LLM (Anthropic) under enterprise controls with a contractual no-training commitment. OWASP LLM Top 10 mitigations in place: prompt/response handling to limit prompt injection, no PHI/PII sent in the evaluation tier (input minimization/de-identification), output is advisory only (human-in-the-loop; no automated clinical decisions), least-privilege API keys, rate limiting, and monitoring. Model inputs/outputs are treated as untrusted and validated.

External LLM providers are contractually prohibited from training on NEDOCS inputs/outputs.