What if there was a search engine for your patient's history?

The scale of the problem, in one number

In 2006, the median patient arriving at an emergency department carried about 1,700 words of prior documentation, roughly a short essay. By 2022, that had grown to nearly 59,000 words, close to the length of Fahrenheit 451. One in five patients now arrives with a chart the size of Moby Dick.

That is a 30-fold increase in the volume of documentation sitting in front of a clinician at the exact moment they need to make a decision. Medical knowledge and patient-level data have both expanded far faster than the tools built to search through them. The gap is not between what is recorded and what exists. It is between what is recorded and what a clinician can actually process in the few minutes they have.

Source: Patterson et al., "Call me Dr Ishmael: trends in electronic health record notes available at emergency department visits and admissions," JAMIA Open, 2024.

What Google solved for the internet

The internet was designed to host documents. For years, that is all it did. It was not built to be searched.

In 1998, Google changed that. The value of the internet was no longer just the documents themselves. It was the index layer built on top of them, something that could crawl, understand, and retrieve across billions of pages in a way no human could do manually.

Electronic health records are in a similar position today. They are designed for storage, not for search. They hold enormous amounts of clinical data, documented across years of patient encounters, structured and unstructured, from multiple institutions, in multiple formats. They were not built to be searched, not in the way clinicians actually need to search them.

The question worth asking: what would it look like to build the equivalent of a search engine on top of clinical data? Not just to find information, but to source it, trust it, and act on it.

The storage problem dressed up as a search problem

When a clinician needs to understand a patient's history, they do not issue a structured query. They open the record and scroll. They skim notes looking for things that seem relevant. They try keyword search, get a long list of loosely matched results with no useful ordering, and often give up and keep scrolling. If they are lucky, a colleague who saw the patient before can give them a verbal summary.

This is not a failure of the clinician. It is a failure of the tool.

EHR systems are built around explicit retrieval: if you know you want a specific note from a specific date, you can pull it. They cannot:

• ❌ Answer questions you did not know to ask
• ❌ Surface the fact that a patient had a medication reaction documented three years ago in a note from a different department
• ❌ Tell you that a symptom mentioned in passing during an outpatient visit six months ago is the same symptom the patient is presenting with now, significantly worse

The information is there. The retrieval architecture is not built for it.

What a search layer would actually need to do

Thinking about this as a search problem, rather than a records problem, changes what you build. A search engine has three jobs:

1. Index content
2. Rank results by relevance
3. Return what the user actually needs.

An EHR search layer has the same three jobs, with clinical constraints applied to each.

Finding it. The index needs to understand clinical meaning, not just keywords. A note that says "patient reports lower back pain radiating down the left leg, onset three weeks ago" should surface when a clinician is looking for prior episodes of radicular pain, even if none of those words match exactly. This requires semantic understanding of clinical language, not keyword matching.

This gets more complex when the data is not text at all. A significant portion of clinical history lives in PDFs: lab results, referral letters, discharge summaries from other institutions, scanned documents. A useful search layer has to be able to read these too. Vision language models capable of handling handwritten and structured document formats now exist and are cost-effective. The content is not inaccessible; it requires a different extraction step.

Sourcing it. Search results without provenance are dangerous in a clinical setting. If a system surfaces a peanut allergy, the clinician needs to know where that came from. Was it self-reported during registration? Confirmed by an allergen test? A suspicion documented by a clinician who has since updated their assessment? A result that shows "peanut allergy" without context is not the same as one that shows "peanut allergy, confirmed by skin prick test, 2019, immunology department."

A Google result being slightly wrong is an inconvenience. A clinical result being wrong, or being right but missing context about its reliability, can cause harm. The search layer has to return not just what was found but where it came from and how much weight to give it.

Handling conflicts. The same clinical history gets documented multiple times, often inconsistently. Different clinicians ask the same questions across different encounters. Patients remember things differently. A clinician writes a summary that slightly misrepresents an earlier note. Errors get copied forward.

A useful search layer does not arbitrate between conflicting accounts silently. It surfaces the variation. If a patient reported back pain starting in 2022 in one note and 2020 in another, both answers should be visible with their sources, so the clinician makes the judgment rather than having the system make it invisibly.

Context changes everything

Search in a general context returns the same results to everyone who asks the same question. Clinical search should not work that way.

A clinician's role, care setting, and what they are about to do all change what information is relevant. An anesthesiologist reviewing a patient before surgery needs specific information: allergies, current medications that interact with anesthetic agents, prior anesthesia complications, relevant cardiac or respiratory history. A nurse taking over a shift needs to know what has happened in the last eight to twelve hours. A GP seeing a patient for the first time needs different historical depth than an emergency physician who has thirty seconds before making a treatment decision.

The insight that surfaced in our team's discussion goes one step further: context does not only mean who you are, it means what you are about to do. Consider a practical example from a neonatal ward: before a procedure, fasting status, consent, and last vitals are all time-sensitive but scattered across different parts of the record. A context-aware system that knows a procedure is planned could surface all of those proactively, flagging what is missing or out of date, without requiring the clinician to go looking.

Or consider a simpler case: a nurse's sister arrived for an MRI and mentioned, just before the scan, that she had the same scan done years earlier at a different institution. The team had no way of knowing. With that information, they could have skipped most of the planned scan and completed only the necessary sequences, saving time and cost. The history existed. It was not surfaced. This is the search problem in its most basic form.

This is the shift from reactive search to proactive retrieval. Instead of a tool you query when you think to, a tool that anticipates the query based on what is happening.

From finding to acting

Search is only useful if it leads somewhere. In a consumer context, the action is usually reading. In a clinical context, the action is a decision, a documentation entry, a medication order, a referral, a procedure.

A search layer that stops at retrieval leaves the clinician to translate what they found into action manually. Consider the allergy example again. The system surfaces a suspected penicillin allergy from a note three years ago. The clinician is about to prescribe amoxicillin. The relevant action is not just to show the clinician the note. It is to flag the potential conflict, explain the source and confidence level of the allergy record, and if the clinician confirms it is valid, offer to update the structured allergy field in the EHR so that every subsequent clinician has access without requiring another search.

This is the full arc: find the data, surface it with source and context, enable an action that improves the quality of the record going forward. Each loop through this process makes the underlying data slightly better structured, slightly more reliable, slightly more useful the next time.

The trust threshold

There is a constraint that exists in the context of healthcare that did not at the inception of the consumer internet. Clinical AI has a trust threshold that consumer search does not.

A result should carry enough information for the clinician to evaluate it independently. Where did this come from? How confident is the extraction? Is this the only mention of this finding, or does it appear consistently across multiple encounters? Is there conflicting information elsewhere in the record?

This is not about being overly cautious or burying results in disclaimers. It is about building a system that genuinely supports clinical judgment rather than replacing it. The clinician remains the decision-maker. The search layer's job is to make sure they are working with the most complete, most legible version of the available information.

Why now

The reason this is worth building now is that the components have converged. Large language models capable of reading and understanding clinical text at scale are available. Embedding models that can index and semantically retrieve across large document sets are available. Vision models that can extract content from PDFs and scanned documents are available. Agent frameworks that can coordinate across these capabilities and push structured data back into EHR systems are available.

The EHR itself does not need to change. The search layer sits on top, reads what is already there, and returns it in a form that is useful at the moment of care.

This is not a replacement for the EHR. It is the index the EHR never had.

‍

Working on this problem?

If you are a developer at an EHR looking to bring your platform into the AI era, already working on a version of this problem, looking for a partner to help you get there, or building a new AI-native EHR from scratch, we want to hear from you.
Tell us what we got wrong, what we missed, or where there is room to collaborate.
‍
‍Reach out to our team

‍

This piece is part of Corti's ongoing series exploring clinical workflows where AI infrastructure can make a meaningful difference. The ideas here draw from problem exploration sessions run by Corti's Clinical Innovation Team.

‍