Security and data protection
How PrimaCite protects patient data in a hospital deployment. The controls are described in general terms; the providers that process data on a deployment's behalf (sub-processors) are named in the data processing agreement (DPA) agreed with each hospital.
How data moves
In the reference deployment configuration that ships with the platform, clinicians reach it only over an encrypted connection (HTTPS). Documents users add are stored and searched inside the deployment. To write an answer, the deployment sends the question, the recent conversation and the relevant document excerpts to an AI model provider and, where your deployment enables web search, sends search queries to a search service. The answer returns to the deployment, which shows it to the clinician with its citations.
Patient identifiers are replaced before an AI model answers
On a hospital deployment, names, phone numbers, email addresses, national ID and passport numbers, medical record and health insurance numbers, street addresses and exact dates are found inside the deployment and replaced with placeholders such as [BN_1]. This happens before the question, the conversation history and the text of files a user attaches or adds to their personal library are sent to an AI model or a search service to answer it, so those services receive the placeholders. The original values are restored only inside the deployment, in what the clinician sees and what the deployment stores. Detection uses fixed rules that run inside the deployment, not an AI model. Ages, relative times, clinical terms and drug names are kept as written.
How well identifiers are caught
Detection is measured against a labelled set of more than 300 identifiers in Vietnamese and English: it must find at least 95% of them, with at least 90% precision, and must leave clinical text unchanged. It can still miss an identifier, for example a given name written on its own, so clinicians should enter only the patient details a question needs. Pictures cannot be cleaned this way. Files a user attaches or adds to their personal library are therefore read as text inside the deployment and their images are not sent, and a file with no text layer is refused. Dictation and read-aloud, which would send audio, are switched off.
Terms for the AI model provider
Requests to the answering model are routed only to providers that do not collect the data and that have a zero-data-retention commitment. If no such provider is available, the request is refused rather than sent elsewhere.
Masking in traces and logs
Where diagnostic tracing is configured, the deployment keeps a trace of each answer for quality review. On a hospital deployment, patient identifiers in the text of those traces are masked and embedded images are removed before they are stored, and the mask is checked against test values every hour. If the masking step itself fails on a piece of text, that text is stored unmasked and the failure is logged. Traces are deleted after a set number of days. In application logs, selected record and request identifiers are written as one-way digests, and common credential and token formats are removed.
Each user's data is kept separate
Each conversation, chat attachment, personal-library document and answer belongs to one user. The database enforces this itself with row-level security: a request runs as its signed-in user and can read only that user's rows. On every change to the platform, automated checks confirm that each table holding user data carries this protection, and probe a test database holding two users' data for cross-user reads. Your IT team can run similar probes against your own deployment with the security report described below.
Retention and deletion
A user can delete a conversation at any time; its question and answer text is then erased after a grace period (24 hours by default). By default, chat attachments expire after 7 days and generated files after 30 days, and expired files are then purged on a schedule. A hospital deployment must also set a maximum age for conversations and for traces, and will not start without both. A user can delete their account: their conversations, files, documents and profile are removed from the deployment's database, file storage and document index, deletion of their traces is requested (any that remain are removed by the trace age limit), and their sign-in account is removed last. Some audit and deletion records are kept for accountability.
A dedicated deployment for each hospital
Each hospital is given its own production deployment, with its own data and its own address; the platform carries one organization's branding per deployment and has no means of hosting several organizations in one. It can run on infrastructure the hospital controls. A hospital deployment runs a configuration profile that refuses to start unless these controls are switched on: identifier replacement, trace masking, the provider terms, the conversation and trace age limits, and dictation and read-aloud switched off.
Incident response
Operational incidents follow a written runbook that sets out detection, mitigation and root-cause steps for the incident scenarios it covers. Where the deployment has configured a security contact, it is published in the deployment's security.txt file. How the hospital is notified of an incident involving personal data is a term of the DPA.
A security report you can re-run
Your IT team can run a security report inside the deployment at any time. It checks that the hospital profile's settings are in force, tests the trace mask against test values, runs the identifier test set through the deployed detector, and probes per-user isolation on the core user tables of the live database in read-only sessions; where fewer than two users hold data in a table, the isolation result is marked inconclusive rather than passed. It does not check the other sections of this page. It writes a dated result, as a readable summary and a machine-readable file. Ask your deployment's operator for the latest dated result.