Hakim Click holds consultations, so how it holds them is part of the product rather than a policy written afterwards. This is what it does today.
Patients, encounters, transcripts and dictations are scoped to the account that created them, and the scope is enforced on the server for every read and every write. It is not a filter applied to a list after the fact: a request for a record that is not yours is answered as though the record does not exist.
Two databases. One holds the account: your name, your email, your registration number. The other holds the clinical work, and knows you only as an opaque identifier. Nothing that identifies you as a person is stored beside the consultations you record.
Passwords are stored only as bcrypt hashes and are never held in a form that can be read back. Your session lives in a cookie the page itself cannot read. The clinical service is reached with a separate short-lived token that carries an account identifier and a plan, and nothing else. Provider API keys are encrypted at rest and used only by the server.
The microphone opens only while you have started transcription and closes the moment you stop it. Segments with no speech in them are discarded in your browser and never leave the device. What is kept is the text; the audio is not retained once it has been transcribed.
Every note, letter and summary the product drafts is a draft. Signing is an explicit act by a named physician, and a signed document can no longer be edited. The clinical decision, and the responsibility for it, stay with you throughout.
Reads and writes against clinical data are logged with the account, the record and the outcome, so a question about who changed a note and when has an answer rather than an assumption.
Institutions evaluating Hakim Click can ask for a walkthrough of any of the above against the running system rather than against this page. Get in touch and we will arrange one.
What we store and why is set out in the privacy policy; what you and we each undertake is in the terms.