Scope, and the status of this policy
This policy describes the Synaptiq Health AI demonstration environment as it actually operates today, last reviewed 3 August 2026. It has not yet been reviewed by privacy counsel, and it is published in this state deliberately so that what the system does is visible rather than implied. It will be replaced by a counsel-reviewed policy before any production or clinical deployment. Where a fact is not yet established, this policy says so rather than describing an intention as a practice.
This environment holds synthetic data only
Every clinical record reachable through this environment is synthetic. Charts come from the public SMART Health IT FHIR sandbox, whose contents are synthetic by construction, or from snapshots captured from it. No real patient data has ever been present, and none may be introduced. This environment is not approved for protected health information and must never be promoted into one that holds it; a PHI-bearing environment is a separate build under separate agreements, not this one reconfigured.
Physician and administrator account information
When a clinician requests access we collect their full name, hospital email address, a password, their credential type, their ten-digit NPI number, and their organization name. Passwords are never stored in readable form; we store a PBKDF2-SHA256 hash. The NPI number is checked against the public NPPES federal registry, and the registry's returned name, taxonomy, verification status, and verification timestamp are stored on the account. That check is advisory information for the administrator who approves the account. It is not an automated gate.
Patient account information
A patient registering for the patient portal provides first and last name, date of birth, sex, phone number, street address, city, state, ZIP code, an optional email address, a password, and a default access duration. This information exists for one purpose: matching the account to the correct record in the connected record source, and operating the approval workflow that governs which physicians may view that record. Each patient account also receives a generated public identifier used in place of an internal database key in URLs. One point of honesty about the account flags: the match is a fuzzy comparison of demographics against records returned by the record source, and the resulting "identity verified" flag reflects that comparison. It is not identity verification in any stronger sense. The email address is verified, in the narrow sense that a link sent to it must be opened before the account can sign in; the phone number is not verified at all.
Contact and access-request messages
The contact form collects a name, email address, optional organization, a topic, and a message body. That message is delivered through our transactional email provider and is retained in that provider's systems. The platform also sends address-verification email: registering an account generates a single-use link, valid for twenty-four hours, sent to the address given at signup, and signing in requires that address to have been verified. It sends password-reset email on request: a single-use link valid for sixty minutes, and we answer a reset request identically whether or not an account exists, so the response cannot be used to discover who has one. Security notifications are sent after an authenticator is enrolled or administratively reset; they contain no authenticator secret or recovery code and a delivery failure does not undo the security operation. There are no marketing emails. When a physician requests access to a specific patient's chart, the free-text reason they give is stored with the request and is visible to reviewing administrators.
What we hold about records, and what we do not
The platform is a read-only review layer. It retrieves, normalizes, and summarizes records; it never writes to, edits, or overwrites a source system. Charts themselves are not stored: they are fetched from the record source per request and held only in an in-process cache with a ten-minute lifetime, alongside a small set of synthetic snapshot files committed to the source repository for demonstration reliability. What our database does hold is a thin search index of patients discovered from the record source — name, date of birth, sex, and a mapping to the source system's identifier — and, for each indexed patient, a short summary line and a primary-conditions string. Those last two are clinical text, and we would rather say so than describe the index as containing none.
Audit logging
Access to records is recorded. The audit trail captures logins and blocked logins, account approvals, denials, suspensions, password resets and deletions, access requests, patient approvals, denials and revocations, chart views, and chart questions. Audit rows deliberately outlive the accounts they reference, because a compliance trail that disappears when an account is deleted is not a compliance trail. An audit row records who acted, which patient was involved, what the action was, and when — it does not record an IP address, a user agent, or a session identifier. Where an action was taken by an administrator on someone else's behalf, the trail records both the person it concerned and the administrator who performed it. One property is worth stating plainly rather than burying: audit rows retain the full text of questions asked of the assistant and the free-text reason given for an access request. The administrator view filters question and reason text out of its responses; the physician-facing audit view for a single patient does not.
Application and platform logs
Our application logs are structured and scrubbed. They never record a question, an answer, chart content, a credential, or an exception body, the emitted fields are allow-listed, and routes are logged as templates so that a patient identifier does not appear in a log line. That describes our logs and not the whole system: the hosting platform's edge proxy separately records resolved request paths, client IP addresses, and user agents in a stream we do not control. Because every identifier in this environment is synthetic, that is acceptable here. It would be a prerequisite to resolve before handling real patient data.
Artificial intelligence and how answers are produced
Chart questions asked by an authenticated clinician are answered by a large language model operated by OpenAI. The question text and a bounded extract of the chart are transmitted to that provider to produce the answer. That extract is not anonymous: it includes the patient's demographics — name, date of birth, and sex — together with the chart overview and a capped number of timeline entries, conditions, medications, observations, imaging reports, encounters, and source records. The model is instructed to answer only from the supplied records, to cite its sources, to state "not found in available records" when the answer is absent or uncertain, and never to diagnose or recommend treatment. Answers carry a label identifying whether they came from the model, from a deterministic local fallback used when the model is unreachable, or from the local stub provider. Our API credentials remain server-side and are never exposed to the browser. The public demonstration question box on the sample patient page does not reach any model at all; it answers from a fixed synthetic chart.
Subprocessors
Four external services receive data from the platform, and one more hosts it. Railway hosts the application and the PostgreSQL database. OpenAI receives chart questions and the chart extract described above. Resend receives the contents of contact-form submissions in order to deliver them. The NPPES registry, a public directory operated by the U.S. Centers for Medicare & Medicaid Services, receives the ten-digit NPI number alone during clinician verification — the name comparison is performed locally on the returned record, so the clinician's name is not transmitted. The public SMART Health IT FHIR sandbox is the synthetic record source; it receives the search terms a physician types when looking for a patient, and the date of birth supplied by a patient at registration, both used as query parameters. No business associate agreement is in place with any of these providers today. That is one of the reasons this environment is restricted to synthetic data.
Retention and deletion
We have not yet established a formal retention schedule, and we will not describe one that does not exist. There is no scheduled purge and no automated deletion job. Browser credentials and the in-memory chart cache stop being usable on fixed lifetimes, but their server-side session metadata is retained until its owning account is deleted; expiry is not deletion. When an administrator deletes a user account, that account's row, its patient portal profile, its session rows, and the access requests it made are removed; the patient search index, the source-system identity mappings, and organization records are not. The audit trail is preserved by design, including a row recording the deletion itself, which retains the deleted account's email address. There is no self-service account deletion and no data export endpoint for either clinicians or patients. Defined retention periods, a documented deletion workflow, and a data subject request process are outstanding items rather than current practice.
Patient control over record access
A physician cannot open a patient's chart merely by holding an approved account. Chart access additionally requires an approved access request for that specific patient. Patients holding a portal account see requests directed at them and can approve them, deny them, or revoke access that was previously granted. Revocation blocks chart access immediately and is distinct from denial, which refuses a request that was never approved. Every one of those decisions is written to the audit trail. Console administrators can also act on these requests.
Security measures in place, and those that are not
In place today: passwords hashed with PBKDF2-HMAC-SHA256 at 210,000 iterations with a per-user random salt, revocable cookie-backed sessions over TLS, administrator approval before any account can sign in, per-patient access gating, rate limiting on authentication and other sensitive endpoints, strict transport security and framing, content-type, referrer and permissions headers, allow-listed and scrubbed logging, and a full audit trail. Physician and administrator accounts support TOTP authenticator MFA and one-use recovery codes; password acceptance creates no session when deployment-wide enforcement is required. The public synthetic-data demo currently runs with MFA disabled, so this is implemented and tested capability rather than an actively enforced demo control. Access credentials last no more than fifteen minutes; one-time refresh credentials can renew them within a thirty-minute idle window but cannot extend the session past twelve hours. Signing out, password reset, denial, or suspension revokes server-side session state. Not in place, and not claimed: an encryption-at-rest attestation, automated database backups on the current hosting plan, a SOC 2 or HITRUST report, a formal risk analysis, a documented incident response plan, and workforce security training. One product boundary is worth naming rather than leaving for a reader to find. An approved clinician may request access to any patient in the search index, because being granted access is what establishes their organization's relationship to that patient in the first place. Reading a record is scoped. Opening a chart, asking a question of it, or reading its access history requires both that the specific request was approved and that the clinician's organization has been granted visibility of that patient, and search results outside a clinician's organization show identity details only, without the clinical summary or condition list.
Cookies, analytics, and tracking
The application uses essential cookies for physician, patient, and administrator sessions. Authentication credentials are stored in httpOnly cookies that page scripts cannot read; separate readable anti-forgery values are random non-credentials. Signing out revokes the server-side session and clears the cookies. There is no analytics package, no advertising or tracking pixel, no session replay, and no third-party telemetry of any kind in the application. We are not tracking visitors across this site or any other.
HIPAA posture
Synaptiq Health AI is not operating as a HIPAA business associate today, and this environment is not HIPAA-compliant. The specific disqualifiers are the absent business associate agreements, the absence of automated database backups, and the retention of full question text in audit logs without a governing retention policy. The architecture is built with these obligations in mind, and the audit trail and access-control model are genuine controls rather than aspirations. That is not the same as compliance, and we will not present it as such.
Matters not yet established
Several things a finished privacy policy would state are genuinely not settled yet, and are listed here rather than invented: the contracting legal entity and its registered address, a named privacy contact, the governing law and jurisdiction, defined retention periods, the legal basis and safeguards for any international data transfer, a breach notification commitment, and a documented process for data subject access, correction, and erasure requests. Questions about any of these are welcome through the contact form, and will be answered with the current state rather than a placeholder.