Building an EHR-Integrated AI Doctor Copilot for Advanced Personalized Medicine

InnMap is not a routine health-check clinic.

The clinic works at the edge of precision and personalized medicine, combining advanced diagnostics, biomarkers, genomics and other patient-specific information with detailed clinical reasoning. Its approach is built around understanding a complex patient as a connected system rather than treating each laboratory result, symptom or risk factor as an isolated data point.

That is clinically interesting.

Operationally, it creates a monster.

The problem: a lot of data before an answer

A complex patient may arrive with up to 100 historical files: previous consultations, laboratory results, imaging reports and years of medical history. InnMap also uses detailed questionnaires containing more than 50 questions, its own diagnostic pathways, specialized tests including genomics and biomarkers, and curated logic for treatment and supplement recommendations.

Before this project, preparing one complicated patient could take approximately 3–7 hours.

A meaningful part of that time was not the final medical decision. It was everything required before the physician could make that decision: reading records, reconstructing longitudinal history, extracting findings, processing the questionnaire, finding relationships between results, checking clinic-specific pathways and entering the resulting structure into the EHR.

The original question was straightforward:

Can we automate the routine intellectual work without automating the doctor?

The second requirement was equally important: this could not become another standalone AI window sitting next to the EHR. Input had to come from the existing clinical system, and useful output had to return directly into the relevant structured EHR fields.

Every medical output would remain subject to physician review and approval.

InnMap had already looked at existing products. There were tools capable of solving individual pieces of the problem, but nothing remotely matched the full workflow. Assembling enough independent products to reproduce it would itself have become a major software and integration project.

So we built the workflow around the clinic instead — which is the same reasoning behind most of our custom clinic automation work: off-the-shelf tools solve pieces, not the process.

The case: from a pile of medical data to a physician-ready patient model

This was never going to be:

upload 100 files → ask an LLM to summarize them → done.

The working system became a set of connected processing engines and knowledge layers built around InnMap's methodology.

Clinical pathways became software architecture

The first major component was a curated knowledge base representing InnMap's diagnostic and clinical pathways.

This was considerably harder than putting documents into RAG.

Historical clinic cases and existing clinical methodology were used to develop, structure, test and iterate the knowledge architecture. We had to make explicit how pathways are represented, which findings connect to them, how input data should be normalized, when particular relationships become relevant and how the model should use the clinic's own logic.

Simply feeding previous cases to an LLM and asking it to infer "the pathway" did not reproduce the clinic's reasoning reliably.

That distinction matters technically. The historical cases were not simply "training data" in the sense of fine-tuning model weights. They were part of the engineering process used to turn implicit clinical reasoning into an explicit, testable knowledge and reasoning structure.

The same approach was applied to InnMap's supplement knowledge. Supplements, associated conditions and pathway relationships became a separate curated and continuously updated knowledge base following the same overall logic rather than existing as a disconnected product catalogue.

We also created a separate service to store these knowledge assets securely. The methodology itself is valuable clinic IP — the kind of thing worth reading about in our security and compliance approach. The architecture is designed so that InnMap can eventually provide controlled access to its knowledge to other physicians or clinics without simply exposing the underlying intellectual property.

Questionnaires became structured clinical data

A 50-question medical questionnaire is not useful if the result of AI processing is another 2,000-word paragraph.

The questionnaire engine converts patient answers into the exact tables and textual structures defined by the clinic and places the output into the relevant EHR fields.

That sounds like an implementation detail. It isn't.

There is a large difference between "AI understood the questionnaire" and "the physician opens the patient chart and the information is already where it belongs."

The second one is what makes the system operationally useful.

Medical history became a longitudinal processing problem

The same principle applies to previous consultations, laboratory results and imaging descriptions.

The system processes source material into InnMap's predefined longitudinal medical-history structures and returns those structures into the EHR. On top of the normalized patient history, additional engines prepare diagnostic-pathway, treatment and supplement suggestions using the combined clinical context.

Every medical output is then reviewed and approved by the physician.

Privacy was designed into the pipeline rather than bolted on afterward: raw patient information is reduced locally using a local LLM, and only anonymized information required for subsequent reasoning is passed to public LLM services.

The result is not an "AI doctor." It is a substantial preprocessing and clinical-reasoning support layer sitting between an unusually complex patient record and the doctor who has to make sense of it.

Here's how the three stages actually connect, end to end:

Lessons learned: where the easy architecture stopped working

This was the technically interesting part.

A conventional LLM pipeline works surprisingly well until the requirement changes from "produce a plausible useful answer" to "do not silently lose one medically relevant fact among hundreds."

We hit four problems particularly hard.

1. The model's medical prior kept fighting the clinic's methodology

General-purpose LLMs come with a strong latent prior about what a medically reasonable answer looks like.

In our testing, when InnMap's personalized pathway moved substantially beyond conventional guideline-like reasoning, models tended to collapse back toward the more statistically dominant conventional answer.

Making the prompt longer did not solve it.

From an LLM-engineering perspective, prompt instructions are inference-time conditioning. They do not erase the model's pretrained representation of the domain. When the proprietary pathway and the model's internal medical prior disagree strongly enough, simply adding "follow this pathway exactly" is not a robust architecture.

We therefore stopped treating the clinic's methodology as supplementary prompt context. The pathway itself had to become an external reasoning structure: explicit knowledge representation, defined relationships, preprocessing rules, engine constraints and controlled prompts working together. The model could perform semantic interpretation and reasoning inside that structure, but it was no longer expected to reconstruct the clinic's methodology from its own latent medical knowledge.

That was one of the most important architectural changes in the project.

2. Attention Is All You Need. Unfortunately, sometimes attention is also the problem.

The title of the paper that introduced the Transformer architecture — Attention Is All You Need — became an inside joke during this project. Because in our case, "attention" was exactly where things started getting uncomfortable.

Suppose we give the model years of patient history. It correctly recognizes that some findings are more salient than others. That is normally what we want from an intelligent system.

Except here a laboratory value that looks completely boring in isolation may become important later when combined with a biomarker, diet history, genomics result or another finding.

So for the first stage of processing, we do not yet know what is unimportant. That changes the engineering objective.

In ordinary summarization we want relevance and compression. Here we initially need something much closer to high recall before relevance is known.

And this is where the marketing number on a model's context window becomes misleading. A 128k context window does not mean 128k tokens of reliable recall.

Long-context research has demonstrated this very clearly. In Lost in the Middle: How Language Models Use Long Contexts, Liu et al. showed that model performance can depend strongly on where relevant information occurs inside a long context: information at the beginning and end is often retrieved more reliably, while material in the middle can be used substantially less effectively even when everything technically fits inside the supported context window.

Subsequent work has connected this phenomenon to positional attention bias. Research on calibrating positional attention bias found a U-shaped attention pattern in which tokens near the beginning and end of long inputs receive disproportionately high attention regardless of their actual relevance.

This was very close to the failure mode we saw in practice. The dangerous result was usually not a spectacular hallucination. It was omission. The model generated a perfectly sensible longitudinal history while quietly dropping something we needed it to preserve.

Our response was a proprietary multi-pass inference architecture we internally call Total Attention.

The name should not be confused with modifying the transformer's internal attention mechanism. We are not rewriting attention weights in the foundation model. We changed the processing architecture around the model so that exhaustive evidence extraction and later clinical reasoning are not treated as one giant long-context generation task.

I am deliberately not publishing the actual pipeline because this became genuine project know-how. Conceptually, though, the important choice was that we optimized the early stages for coverage rather than token efficiency and deferred aggressive relevance filtering until later stages had enough context to determine what was actually relevant.

That costs substantially more tokens and compute than sending 100 files to one huge-context model and asking for an elegant summary. That is fine. A cheaper answer that silently drops the wrong laboratory result is not cheaper.

The engineering lesson was: context capacity is not information-retrieval reliability.

3. Multilingual capability is not multilingual parity

Patient material is multilingual.

Initially, there was an understandable temptation to let modern multilingual models simply reason in whatever language the source document happened to use.

Our testing consistently produced better downstream reasoning when source material was normalized and the core reasoning stages operated in English.

There is no defensible universal claim that "non-English LLM performance is 30% worse." The actual gap depends heavily on the model, language and task.

A recent controlled multilingual reasoning benchmark, Macaron (ACL 2026), evaluated 21 multilingual models across 20 languages and dialects. Strong reasoning-mode models were close to parity, with an average local-language multiple-choice gap of only 1.3 percentage points, while open-weight models degraded by 6.8 points on average in local languages.

That is exactly why we should not publish one universal percentage.

At the architecture level there are also less visible sources of asymmetry. Tokenization is one of them. NAACL 2024 research on tokenizer choice showed that English-centric tokenization can materially damage multilingual efficiency and downstream performance; in the authors' controlled training experiments, inefficient tokenization increased training costs by as much as 68% and caused severe downstream degradation.

Our conclusion therefore was not "English is always X% better." It was much narrower and more useful:

For the models, languages and medical reasoning workloads we tested, an explicit language-normalization stage produced more reliable downstream reasoning.

So the pipeline separates source-language handling from reasoning-language handling. Translation and normalization happen as a controlled preprocessing stage. The core reasoning pipeline operates on normalized English representations, and results can then be returned in the language required by the clinical workflow.

This was an empirical engineering decision, not a religious belief about language.

4. Healthcare expertise became part of debugging

One of the most revealing pieces of feedback during development sounded roughly like this:

"The bone-density result isn't connected correctly to diet and this biomarker, so the system is proposing the wrong supplements."

That is a software bug. But it does not look like one.

There is no stack trace. The model runs. The API returns 200 OK. The generated text may even sound completely reasonable.

The defect is in the representation of medical relationships.

To fix it, someone has to understand the physician's complaint well enough to identify which relationship in the knowledge architecture is missing or represented incorrectly, and then translate the clinical problem into an engineering change.

That happened repeatedly during development. Clinical feedback directly produced changes in pathway and knowledge-base architecture.

It is one of the reasons our founder is fairly skeptical when people treat healthcare domain expertise as a nice bonus for an AI development team.

On projects like this, sometimes domain expertise is literally your debugger.

The result: from 3–7 hours to less than one

After approximately two months of development, the system already handles major parts of InnMap's patient-preparation workflow: questionnaires, longitudinal medical history, laboratory and imaging data, clinic-specific pathways, and treatment and supplement suggestions, with structured information integrated back into the EHR.

Complex cases that previously required approximately 3–7 hours now take less than one hour, including physician review.

That is the metric I care about. Not how many calls we make to an LLM. Not how many agents are in the architecture diagram.

A doctor gets several hours back and spends proportionally more time on the part that actually requires a doctor.

At the same time, the system does not independently release clinical decisions. Every medical output remains subject to physician review and approval.

What's next

Is the project finished?

No.

I am increasingly convinced that sophisticated healthcare AI projects are a little like apartment renovations: they are never truly finished. At some point everybody simply agrees to stop for a while.

The current system already produces a substantial operational result, but InnMap's methodology continues to evolve, the knowledge bases continue to grow, and we already have a long list of things we want to improve and extend.

That is particularly appropriate for InnMap. The clinic is pushing toward increasingly structured, measurable and deeply personalized medicine. The software therefore has to evolve together with the clinical methodology rather than freezing one version of it forever.

There will be more pathway work, more refinement of the processing architecture, more automation where it proves safe and useful, and inevitably more strange edge cases that destroy whichever beautiful assumption we currently think is settled.

Good. Those are usually the interesting projects.

About InnMap

InnMap is an advanced personalized and precision-medicine clinic led by Dr. Lidya Blecher. Its work combines detailed clinical assessment with advanced diagnostics, biomarkers, genomics and other patient-specific information to build highly individualized diagnostic and treatment pathways.

The project described above exists precisely because that methodology does not fit neatly into a standard software template. That is also what made it interesting to build.

Visit InnMap and Dr. Lidya Blecher →