MediMind: An AI-Native Hospital System
MediMind is a proactive, AI-native hospital system built from the ground up on FHIR R4, now under contract with a 25-hospital network in the Republic of Georgia. Here is why we rebuilt what a hospital runs on instead of adding features to what was already there, and why we built it on Medplum.
The bet
I am a physician, and I think that within a few years, practicing medicine without AI assistance will look like malpractice. The timeline is a guess and I may be wrong about it by years. I am not hedging on the direction at all.
If AI assistance is going to be the standard of care, you cannot get there by adding AI to existing hospital software. You have to build the thing AI runs on. That is what MediMind is: a hospital system designed from the data layer up to be reasoned over by a model, covering clinical workflows end to end, from the moment an analyzer produces a result to the moment the ministry receives the report, with AI inside the flow instead of beside it.
Why Georgia
We chose Georgia deliberately, for velocity: how fast an idea becomes something running in a real clinical workflow with real patients. It had to practice Western, evidence-based medicine so that whatever we learned would transfer everywhere, and it had to let us move.
The clinical culture here is Western-oriented and evidence-based, and the hospitals are close to greenfield: no thirty-year installed base, no integration debt between forty systems that all half-talk to each other, no five-year procurement cycle between a decision and a deployment. A network here can decide to change everything at once and mean it. Some of the same conditions have made Georgia a destination for early-phase clinical trials.
None of that is about lighter rules. We are treating patients across a 25-hospital network, we carry the obligations any hospital system carries for accuracy and availability, and we handle personal health data under Georgian data protection law, which is aligned with GDPR. What we do not carry is thirty years of software sediment.
The catch is that effectively nobody here builds on FHIR. The software on the market is dated across the board: international systems that do not fit this market, and local systems designed long before FHIR existed and never meant to be read by anything except themselves. No standard is shared even between two hospitals in the same city. Georgian is also a low-resource language for today's models, and unstructured clinical data on top of that makes already-hard medical AI tasks harder still. None of this is specific to Georgia; it is the reality across the region.
Georgia is a spectacular place to prove out AI-native healthcare and a difficult place to build the substrate one runs on. We wanted the first badly enough to go do the second.
Why FHIR from the beginning
The standard advice was to sit on top of the incumbent systems and ship features. We solved the substrate instead, and not by building another system of record that would age into the same legacy everyone else is stuck with. AI is only ever as good as what it can see, and a hospital storing its data across forty proprietary schemas can never hand a model a whole patient. It can only hand it fragments.
So FHIR R4 became our operational data model, not an interoperability layer bolted to the edge of the system. A lab result is an Observation when the analyzer produces it, when the ward reads it, when our models reason over it, and when the insurer receives it. There is no separate internal representation we translate out of on the way to an API.
Nobody made us do this, and that is unusual enough to say out loud. In the US, FHIR mostly arrives as a compliance requirement, which is why so many engineers there treat it as a tax. There is no Georgian FHIR mandate, and no regulator here was ever going to ask us for it. We adopted it because it was the best available data model for the product we wanted to build.
FHIR also solved the language problem in a way we did not anticipate. When the structure is standard, the model already knows what an Observation is, what a MedicationRequest is, where to look and what to expect. The structure carries the meaning and Georgian only has to carry the free text. A low-resource language stopped being a compounding penalty. Medplum's multilingual support means the same record serves our Georgian, Russian and English interfaces without a separate translation layer.

Why Medplum
We did not want to spend two years writing a FHIR server. We wanted to spend them writing the hospital.
That is most of the reason, and the list of what we skipped is long: FHIR search and chained search, transactions, version history and AuditEvent, SMART on FHIR authorization, role-based access control, subscriptions, binary storage, terminology, bulk export. Every one of those is real engineering that no clinician ever sees, and all of it stood between us and the first useful thing we could put in front of a technician.
What we did not appreciate at the time is how much the deployment flexibility would matter. Medplum self-hosts as naturally as it runs in the cloud, so when our anchor customer needed the entire stack on their own hardware, that was a configuration choice and not a second architecture.
We now have [80+] FHIR resource types in production. Every department we have added since (lab, pharmacy, imaging, beds, billing, HR, ministry reporting) has been a vocabulary, not an architecture. That is why a team this small can cover a hospital.

Figure 1: MediMind production architecture. Medplum at the storage and API layer, MediMind's departments above it.
Where we are
Thirteen months from idea to a counter-signed contract with a 25-hospital network. Most healthcare startups spend thirteen months getting a pilot scheduled.
- A 25-hospital network under contract, with the first modules live in production
- AI tools in daily clinical use since May 2025
- About 1.1 million patients migrated into FHIR
- Roughly 3.1 million visits and 3.7 million clinical observations behind them
- [80+] FHIR resource types in production, ~2,200 files, 70+ shipped features
- A 150,000 GEL grant from GITA, Georgia's Innovation and Technology Agency
- Among the first companies in the country granted innovative startup status, with the associated tax exemptions. We were the fifth.
- Two founders and an AI code factory

Modernizing a hospital that never stops
A hospital laboratory does not stop. There is no maintenance window for a blood count, so we never asked for one. Every analyzer reported to two places at once, to us and to the incumbent, in the exact shape the old system already expected. The incumbent never noticed it had company, not one technician changed a habit, and for the entire migration rolling back was a decision we could execute in well under a minute.
The hospital handed us a virtual machine and an SSH key on a Friday and the stack was live the next day. Fifteen analyzer lines were live within three weeks of a standing start, over HL7 v2 interfacing and ASTM. That is work that gets quoted in quarters here. One junior engineer on site was enough for the on-premise wiring; the rest was done over SSH from a desk in Tbilisi. Imaging went in the same way, and a CT study now moves from scanner to archive to FHIR to viewer without a step where somebody retypes anything.
Then we spent a week standing in that laboratory, writing down every complaint and every wish. Several of them went from a sentence said out loud to running in production the same day. By the third time that happened, the technicians stopped asking carefully.

Figure 2: Laboratory task board. Analyzer results arriving as Observation and DiagnosticReport.

Figure 3: Imaging viewer, CT study.
Open source is a procurement argument
The objection we meet in this market is not technical. Hospitals here have watched their own data become hostage to vendors they do not even hold a contract with. Being able to say "you can see the server you are running, and your data is yours in a standard format", and then prove it at the storage layer, closes conversations that a feature list does not. Building on a recognized FHIR platform also shortens the "are these people serious" conversation with hospital IT by about a meeting and a half.
There is a real trade here and we would make it again. Self-hosting means we own upgrades, patching, and backups, and we take new Medplum releases after a soak instead of on day zero. For a regulated on-premise hospital deployment, that is the right side of it.
Why the AI works
It never reads a lab result on its own. It reads the patient. The result sits beside the medication, the imaging, the admission, and the entire history, all in one place and one format. A patient handed to you in fragments can only be reasoned about in fragments, and that is the ceiling every AI layer stacked on top of a stitched-together hospital eventually hits. No amount of model quality raises it.
Structure is also what makes proactive possible. Healthcare AI today is mostly reactive: you ask it something and it answers. We are building the opposite, a system that notices deterioration before any single department would see the pattern and then coordinates the hospital around it: surfacing the right labs, alerting the right specialist, checking the drug is in stock, flagging the bed, and catching the billing requirement while care is still happening. Subscriptions and bots let that run as events instead of as a nightly batch.
Structure is also what lets us do it safely. Anything our AI produces goes into its own report, permanently marked preliminary and permanently coded as AI-generated, and never merged into the clinical conclusion. The AI flags and clinicians decide, and the data model does not let the two blur. The same access policies and audit trail that govern a clinician govern the AI.

Figure 5: Patient hub with AI-generated preliminary findings and CDS alerts.
Where MediMind is headed
Near-term, network-wide go-live. Georgia is the first step because it accumulates evidence quickly, and that evidence is what we intend to take global.
A hospital today runs on something like forty systems. One will run them tomorrow, and it will not be forty systems with AI bolted on top.