Security and its limits
Implemented controls are not the same as a configured, independently assessed production service.
Application-level controls
The repository implements mandatory MFA for private records; owner-and-MFA checks in API code and database policies; private storage; quarantine with authenticated file-bound scanning; short-lived downloads; redacted access audits; exact-origin mutation checks; and signed, consented CME imports.
Packet assembly rechecks selected document ownership, scan status and size. Recipient invitations use fragment-handled secrets, email-code verification and short-lived packet-scoped access. GET requests do not send codes or release archives. The browser removes the invitation fragment on initialization; codes and downloads require explicit actions.
Protected first-page previews
Private previews require ownership, MFA, clean file-bound scanning, rate limiting and a redacted access audit before a bounded PNG is released. The server rechecks ownership and scan state after rendering. No original inline PDF, active annotations, public private-image URL, third-party viewer or persistent private image cache is used. Scan-cleared is not issuer-verified.
Visible items load lazily with at most two client jobs through complete response-body reading. Hide previews in Diplomas & records or Settings applies across evidence slots, cancels queued and in-flight requests, closes image dialogs and releases transient blobs. Navigation and sign-out also release them. Filenames remain visible; supported clean originals retain guarded Download when rendering is unavailable.
Rendering is disabled by default. Its worker time and JavaScript-heap limits are not an OS sandbox or native-memory containment. Deployment-specific process/native-memory, CPU, hard termination, network-deny and runtime packaging controls require operator acceptance before enabling. Local tests do not establish hosted acceptance.
The public demo image is bundled fictional artwork associated only with its exact sample metadata record. Visitor-selected demo files remain metadata-only, with no file-byte read, upload, storage or substitute sample preview. This fictional asset exception never applies to private records.
What the status labels mean
Mail provider accepted means the mail API accepted the request, not that the email reached a recipient. Inbox verified means a code was redeemed, not that the person is employed by the named hospital. Download access recorded means the server authorized access, not that the recipient saved the complete file or accepted the credentials.
Recipient expiry and revocation are checked on access. Neither can recall completed or in-flight downloads. A compromised recipient inbox or privileged server account remains a risk.
Known limits
The design is not end-to-end encrypted. Privileged operators and configured processors can access records. A clean malware scan does not prove a document is authentic, current or accepted. Source-linked requirements and provider signatures do not establish legal compliance.
No HIPAA certification, SOC 2 certification, zero-knowledge architecture, immunity from attacks or uptime guarantee is claimed. Local automated tests are development evidence, not an independent penetration test or certification.
Hosted acceptance before launch
Real identity/email/storage configuration, scanner deployment, MFA recovery, rate limits at the edge, incident response, monitoring, retention, private-data backup restoration and recipient delivery require operational acceptance. Staging must use separate owner accounts and a separate recipient inbox. Local HTTP is not production TLS.
Public registration and sensitive sharing must wait for approved operation and legal documentation. See Contact for explicitly configured reporting channels; never send passwords, MFA codes, patient records or credential packets in ordinary support email.