Healthcare software has a problem that most AI tooling ignores completely. The data cannot leave the building.
Not "should not." Cannot. A hospital that ships patient records to a third party API is not making a tradeoff between convenience and privacy. It is breaking the law in most jurisdictions, and it is breaking the trust of every person whose record is in that system.
I build NeonCore, a Windows desktop AI assistant that parses documents entirely on the machine it runs on. No cloud upload, no data retention. A few months ago I started getting the same question from people in the health sector: can it read our patient records?
The honest answer was no. So I built it.
Why FHIR and not something simpler
FHIR R4 is the standard most modern hospital systems already speak. If you want to read patient data without asking an institution to change anything about their infrastructure, FHIR is the door that is already open.
The alternative would have been asking hospitals to export data into some format my app understands. That is a non-starter. Every export step is a copy of sensitive data sitting somewhere it should not be, and no IT department will approve it.
So the design constraint was simple: talk to the FHIR server the institution already runs, on their own network, and never write anything back out.
The architecture
Three pieces:
1. A local FHIR client. NeonCore connects to the institution's FHIR R4 endpoint over the local network. The endpoint address is configured by the institution, not by me. I never see it.
2. Query tools exposed to the model. Two functions, fhir_sorgula for searching resources and fhir_kayit_oku for reading a specific record by ID. The model calls these the same way it would call any other tool.
3. On-device reasoning. The record comes back, gets reasoned over locally, and the answer appears on screen. Nothing is written to disk unless the user explicitly saves it. Nothing goes to a cloud endpoint.
The important part is what is missing from that list. There is no sync layer. No telemetry on query contents. No caching of patient data between sessions.
What was harder than expected
FHIR is a large standard. R4 defines well over a hundred resource types. I did not implement all of them and I do not intend to. Patient, Observation, Condition, MedicationRequest and DocumentReference cover the overwhelming majority of what a clinician actually asks about. Scope discipline mattered more than completeness.
Authentication varies wildly. Some institutions use SMART on FHIR, some use plain bearer tokens, some sit behind a network boundary and use nothing at all. I ended up supporting a configurable auth layer rather than assuming any one flow.
Search parameters are inconsistent in practice. The spec says one thing. Individual server implementations do their own interpretation. Defensive parsing was not optional.
Explaining it is harder than building it. I spent months describing "on-device processing with zero data retention" and watching people nod politely. The moment I changed the sentence to "patient records never leave the institution," people understood immediately. Same architecture, different words.
What I would tell someone building in this space
Do not treat privacy as a feature you add. Treat it as a constraint that removes options. Once you accept that data cannot leave the machine, a lot of architectural decisions make themselves. You stop reaching for the cloud service that would have been easier, because it is simply not available to you.
That constraint is also the entire product. There are plenty of AI assistants that can read a document. There are very few that a hospital's compliance officer will approve.
Where this is going
FHIR support is live in NeonCore now. Next on the list is expanding resource coverage based on what people actually ask for rather than what the spec suggests, and better handling for institutions running older FHIR versions.
If you work in health IT and want to poke holes in this, I would genuinely like to hear it. The failure modes I have not thought of are worth more to me than the ones I have.
https://neondijital.com/blog/fhir-r4-local-first-ai
NeonCore is at neondijital.com. Built and maintained solo, self funded, from Izmir.
