Patient data has rules that shape the architecture.
In healthcare, who may see what is not a permissions feature added late, it is the constraint the whole system is built around. Get it wrong and you do not have a bug, you have a notifiable incident.
Consent and entitlement are architecture, not configuration.
Most systems handle permissions by deciding what a user may see once, at login. Healthcare cannot work that way: entitlement depends on the care relationship, the consent the patient gave, the context of the request and sometimes on an emergency override that must itself be recorded.
That has to be enforced where the data is fetched, not filtered from the answer afterwards. The difference is invisible in a demonstration and decisive in an audit.
The same applies to AI. A clinical copilot that indexes everything into one store and filters the output leaks, and it leaks in ways that are extremely difficult to detect. Retrieval has to inherit the entitlement model before the model ever sees a passage.
Where confidentiality or residency requires it, we run open-weight models inside your own environment so PHI never crosses a boundary. That is often the difference between a project that clears governance and one that does not.
Six pieces of healthcare work we do repeatedly.
Clinical documentation support
Drafting notes and letters from the encounter record for clinician review, reducing the after-hours documentation burden.
EHR · dictation · templatesTelemedicine platforms
Consultation, scheduling and follow-up built for the realities of poor connections and older devices.
Video · scheduling · patient appInteroperability & integration
Moving data between systems that were never designed to co-operate, through HL7, FHIR and purpose-built interfaces.
HL7 · FHIR · DICOM · APIsCoding & billing assistance
Suggesting codes from the documentation with the supporting passage cited, for a coder to confirm.
EHR · coding standards · billingCohort & outcome reporting
Reporting that clinicians and commissioners can both rely on, built on a governed model instead of ad-hoc extracts.
Warehouse · BI · registriesPatient portals & consent
Self-service access with consent captured, versioned and enforced wherever the data is subsequently used.
Portal · identity · consent storeSix questions your information governance team will raise.
None of these are unreasonable, and all of them are cheaper to answer in the design than in a remediation.
Where does PHI physically reside?
In your environment unless you decide otherwise. Open-weight models can run inside your own tenancy so patient data never crosses a boundary.
Is entitlement enforced at retrieval?
Yes; access is applied when data is fetched, before any model or interface sees it, inheriting your existing care-relationship and consent model.
Is every access recorded?
Reads as well as writes, with the user, the purpose and the record identified, retained for the period your regulator requires.
What happens to consent withdrawal?
It propagates. A withdrawn consent removes the data from retrieval and is recorded, not left as a flag someone must remember to honour.
Can a clinician override in an emergency?
Where your policy allows it, yes, and the override is recorded distinctly, reviewable afterwards, which is what makes it acceptable.
Who is accountable for a clinical output?
A named clinician, always. The system drafts and cites; it does not diagnose, and the record reflects that clearly.
Before you build in healthcare.
Three questions we are asked by almost every healthcare client.
Can we use commercial AI models with patient data?
Sometimes, and it depends on your jurisdiction and your governance appetite rather than on the technology. Several providers now offer zero-retention terms and regional processing that some health organisations accept. Many do not accept it, and that is a legitimate position rather than excessive caution. Where the answer is no, open-weight models running inside your own tenancy are capable for the tasks that matter here (summarisation, extraction, drafting and retrieval) and nothing leaves your boundary. We design so the choice stays yours and can be changed later without a rebuild.
Our EHR vendor already offers AI features. Why build anything?
Where their feature covers your need, use it and we will say so. The limit is that a vendor's AI sees its own product's data. Most of the questions clinicians and administrators actually have cross systems, the referral letter in the document store, the result in the lab system, the correspondence in the practice management tool. That is where a custom retrieval layer earns its cost, and it complements the vendor's feature, not replacing it.
How do you handle the risk of a wrong clinical suggestion?
By keeping the system out of the diagnostic decision and being explicit about what it does. Our default is drafting, summarising, surfacing and citing, every output traceable to the source record, with a named clinician confirming before anything enters the patient record. Where the material does not support an answer the system says so rather than producing a plausible one. Anything that would constitute clinical decision support in a regulatory sense is a separate conversation with a different evidence bar, and we will tell you when a request has crossed that line.