The First EMRs Were Designed to Help Clinicians. What Happened?

Look at almost any modern electronic medical record and you’ll recognize the pattern: forms, fields, tabs, tables, checkboxes.

The person sitting in front of it is expected to ask questions, find the right information, categorize it and put it in the right place. It feels designed for someone whose job is to collect and enter data.

It's easy to assume this is simply what happens when you take a paper medical record and put it on a computer.

But that isn't how the history of electronic medical records began.

In the 1970s, there was PROMIS

More than 50 years ago, physician Lawrence Weed and a team at the University of Vermont were developing an ambitious system called PROMIS: the Problem-Oriented Medical Information System.

PROMIS was built around Weed's idea of the problem-oriented medical record. Rather than simply creating a digital filing cabinet, he was interested in a much bigger problem: how could computers help clinicians deal with the growing complexity of medicine?

By the 1970s, clinicians were interacting with PROMIS using touchscreens (you read that right), reportedly the first clinical information system to use them. Nurses, patients and clinicians entered structured information, which was organized around the patient's medical problems. Once that information was captured, the system could help construct problem lists and support the development of plans and progress notes.

Think about how ambitious that was!

There was no web. No cloud computing. No LLMs.

PROMIS eventually relied on a vast medical knowledge base built by clinicians and systems analysts, with specialists brought in to extend it as the system grew.

The goal wasn't simply to document what had happened to a patient. The computer could play a role in helping the clinician figure out what the information meant. PROMIS was the clinician's thinking partner.

We started by trying to build computers that helped clinicians think. Somewhere along the way, we ended up building computers that asked clinicians to document.

So what happened?

The EMR acquired a lot of other jobs

There isn't a single moment when the industry made a wrong turn. And there isn't a single villain.

Helping clinicians reason was an ambitious problem to solve, particularly with the technology available at the time. Meanwhile, healthcare organizations had much more immediate problems computers were already good at solving: storing information, scheduling patients, processing bills and keeping track of what happened.

Those problems also had something important behind them: clear economic value.

And that raises an interesting question: who exactly is the EMR supposed to serve?

The clinician uses it. But the information they put into it serves many others.

Then the incentives started piling up.

Payers needed documentation to determine what happened and what should be reimbursed.

Hospitals needed billing, scheduling, orders and operational data.

Governments increasingly wanted standardized data, quality measurement and eventually interoperability.

Regulators needed evidence that certain processes were followed..

These aren't bad things. In many cases, digitization made things possible that paper records simply couldn't do. But all of those requirements had to land somewhere. And increasingly, they landed with the clinician, the same person everyone in this system ultimately relies on to deliver care.

We had an early vision of the computer as a partner in clinical reasoning. But the problems that created the strongest economic and regulatory incentives for digitization were recording, standardizing, exchanging and proving what happened.

Software followed those incentives.

Eventually, all of those requirements landed in one place

The clinician's screen.

And that creates a strange mismatch.

A physician's job is to gather a huge amount of messy information in a short period of time. They have to decide what information matters and what doesn't, recall information from the past, recognize patterns, and decide what should happen next. It's a set of complex thought processes that loop and jump rather than move in a straight line. And somehow all of that was reduced to collecting a complete set of fields.  

At the same time, the EMR needs the encounter translated into something that can be stored, retrieved, billed, measured, shared and audited.

And we've largely made the clinician responsible for doing both.

The consequences are now well documented. A 2024 review by the U.S. Agency for Healthcare Research and Quality describes documentation burden as an important factor affecting clinicians' work experience and contributing to burnout. The burden includes far more than writing a clinical note: orders, inbox work, billing and insurance-related documentation are part of it too.

But burnout isn't the only reason this matters.

That moment is precious

Consider a patient who has recently been diagnosed with Chronic Obstructive Pulmonary Disease (COPD). 

There is clinical information to gather. But there might also be fear or shame sitting underneath the conversation.

Or consider a couple going through infertility. Their medical history matters, but so might the anxiety, helplessness or uncertainty that emerges while they tell their story.

Those things don't necessarily announce themselves in a field. This is the part of medicine that requires presence. The patient needs to feel heard. The clinician needs space to notice what isn't being said explicitly, ask the question they hadn't planned to ask, provide reassurance and gather information that doesn't fit neatly into a form.

In addition to all of this the care plan still needs to be captured including medication that needs to be prescribed. 

But it's worth asking why the most highly trained, and most human, person in the room has become responsible for translating all of that into the language the computer requires, during the very moment we most need their attention elsewhere.

Maybe this isn't fundamentally a design problem

It's tempting to look at today's EMRs and conclude that we simply need better-designed software.

That's probably part of the answer. But history suggests something deeper.

Software tends to become very good at the things the healthcare system rewards it for doing.

For decades, enormous value has been attached to accurately documenting what happened, supporting reimbursement, satisfying regulatory requirements, standardizing information and making that information exchangeable.

So perhaps today's EMR is the product of the incentives we gave it, not simply bad design.

Which makes the moment we're entering now particularly interesting.

We have another chance to decide what computers should do in medicine

More than 50 years after PROMIS, computers can suddenly do things that sound surprisingly close to that early ambition.

They can listen to a conversation. They can summarize years of patient history and retrieve relevant knowledge. They can capture decisions and generate documentation without requiring every piece of information to be manually translated into a field.

For the first time in a long time, it feels technically possible that the computer could adapt to the clinician rather than continually asking the clinician to adapt to the computer.

But PROMIS taught us another lesson: incentives were the driving force behind what EMRs became, not the technology that powered them.

And incentives aren't only economic. They are shaped by what hospitals need, what governments require, what payers reward, but also by the motivations and constraints of the clinicians we expect to use the technology in the first place.

We can build incredibly capable technology. But whether clinicians embrace it, work around it or resent it will depend on whether it makes the thing they came into medicine to do better: care for patients.

As we build the next generation of healthcare technology, we believe the right question to ask is what we're going to reward AI for doing, not just what it's capable of doing.

Will we use this extraordinary new capability primarily to create documentation faster?

Or will we finally measure its value by what happens to care?