In the age of AI, electronic health records (EHRs) need a makeover. But what would it look like to rethink EHRs and deeply embed AI? And could this accidentally produce something more than we bargained for—like a fully autonomous AI doctor?

I’ve thought a lot about AI-native EHRs. Previously, I spent seven years as the CEO/Founder of Cydoc, a startup aiming to build an AI-native EHR. In this article, I’ll first discuss the problems with legacy EHRs, before diving into ideas for AI-native EHRs, ranging from mundane changes to problem lists to wild Roomba-like robots. If you’re curious about the health tech platforms of the future, this article is for you.

What are EHRs?

An electronic health record (EHR) is a complex software application that serves as a central management tool for clinical care and as a digital repository of patient data. EHRs offer several advantages over paper records, including faster updating and retrieval of records, lower rates of handwriting-related errors, safer prescribing, and facilitation of electronic billing and payment. These benefits combined with government incentive programs have led to the adoption of EHRs in the United States in over 88% of physician offices and 97% of hospitals (Melnick). Inpatient/large health system EHRs include Epic Systems (43% market share), Oracle Cerner (18%), and Meditech (10%) (Definitive). Outpatient/ambulatory/private practice EHRs include over 500 different vendors, many of them small specialty-specific EHRs. The largest outpatient EHRs are Epic (20%), eCW (12%), athenahealth (7%), and Oracle Cerner (5%) (Definitive). The EHR companies Epic Systems, Cerner, and Meditech were all founded over 40 years ago, and accordingly are built on older technology, from decades before modern AI existed.

Limitations of legacy EHRs

Legacy EHRs have a variety of limitations. Despite administrative advantages such as streamlined billing, legacy EHRs are not optimized for care delivery, clinical research, or AI development (Weiskopf, Amisha). Legacy EHR limitations include:

Legacy EHRs have poorly-designed user interfaces that cause clinician burnout and harm patients via medical errors. The Problem: Legacy EHR user interfaces are unintuitive, illogical, and confusing (Ratwani). They increase cognitive load, errors, and inefficiency by requiring clinicians to view many screens and keep information in memory or external tools, instead of displaying all relevant information at once (Senathirajah). The Root Cause: EHR vendors often do not conduct clinician usability testing (Ratwani). Furthermore, many EHR products were first designed for scheduling, billing, and regulatory requirements rather than clinical care, establishing a pattern of cumbersome user experiences fixated on data entry (Tutty), and creating a scenario where administrators work less and physicians work more (Zhou). The Consequences: Prior to 2005, physicians spent the majority of their time providing direct patient care, but now they spend the majority of their time on the EHR: up to 2 EHR-hours for every 1 hour of patient care (AHA). “Click fatigue” is common; on some EHRs it takes >60 clicks merely to order Tylenol (Ratwani). Excessive EHR time is the leading cause of burnout. Patients do not have as much facetime with their physicians, and poor usability directly leads to medical errors that can cause serious patient harm, e.g., medication errors in the intensive care unit (Nijor, Carayon).

Legacy EHRs prevent data exchange, leading to fragmented, incomplete patient data. The Problem: EHRs do not support interoperability with other EHRs, sometimes even within the same product from the same vendor, which results in fragmentation of patient data (Bernstam). (As they say, if you’ve integrated with one Epic instance, you’ve integrated with one Epic instance.) Over 95% of Medicare patients have their record fragmented across multiple EHR vendors (Sorace). If data is shared, this is typically done via faxing paper records, or sending lengthy concatenated PDFs that are difficult to review. One study found that only 0.6% of patient records are complete (Weiskopf). The Root Cause: EHR vendors have a financial incentive to prevent interoperability, since this locks clients into their products (Tutty). The Consequences: The fragmentation of a patient’s medical information impairs clinical care by preventing clinicians from evaluating patients holistically, and it leads to redundant medical testing, which can be painful and costly. Incomplete records can even be fatal: a recent study found that incomplete transfer documentation leads to significantly higher patient mortality (Usher).

Legacy EHR data is unstructured and chaotic. The Problem: In addition to being incomplete, EHR data is also unstructured, noisy, and heterogeneous. Patient records contain significant quantities of unstructured narrative text, redundant information, and complex longitudinal information (Weiskopf). The Root Cause: The majority of legacy EHRs were initially developed for administrative tasks and only later adapted for clinical use. Furthermore, the underlying databases were designed to support “filing cabinet” functionality rather than research, analytics, or AI. The Consequences: Unstructured data limits the use of EHRs for clinical research and constrains healthcare AI innovation. Recent groundbreaking advances in AI have led to high hopes that AI will revolutionize healthcare. However, data from legacy EHRs is so disorganized it cannot typically be used to train AI systems in its raw form (Dziadkowiec). EHR data must be intensively cleaned before any task-specific modeling can occur, and model performance still suffers because post-hoc cleaning is not as good as collecting clean data in the first place. The vital importance of clean data for AI relates to the concept of “data-centric AI,” in which researchers improve the quantity and quality of data before making changes to the models themselves (Zha, Getzen). Overall, the chaotic nature of existing EHR data is a serious bottleneck to clinical research and the creation of clinical AI applications.

Legacy EHRs do not support seamless, flexible integration of third-party AI tools into clinical workflows. The Problem: Many legacy EHRs do not permit AI-focused companies to integrate AI tools at the necessary point in the clinical interface, which relegates powerful AI technology to third-party platforms or, more commonly, to no clinical use at all. The Root Cause: While some legacy EHRs have “app stores,” many legacy EHRs do not natively support third-party UI integrations. Furthermore, EHRs typically do not support UI integrations that remove parts of the UI, and no existing EHRs provide inbuilt support for modern AI model training, evaluation, deployment, or integration. The Consequences: Over 33,700 medical AI papers have been published in the past decade alone (Mesko) but fewer than 2% of these innovations have been FDA approved (FDA), and even fewer are integrated into any EHR.

(Now, after formally laying out all these limitations, I do want to point out that there is a lot to be said for building an EHR that is deployed in the real world and used in real hospitals and practices. This is an enormous technological undertaking. Epic, for example, has over 18,000 tables in its database. I’m not saying that having 18,000 tables is in itself “good”–just that it’s an indicator of a lot of people doing a lot of work.)

Overall, there remains a critical unmet need for an AI-native EHR system. Such an EHR could combine the following components:

  • Built-in AI automations;
  • A minimalist, simple, intuitive user interface;
  • A database design that supports AI through clean, structured data;
  • A built-in no-code user interface to accelerate AI research and deployment.

The relationship between user interfaces, databases, and AI

EHR user interfaces, underlying databases, and AI are all tightly interconnected.

The cleaner the underlying data, the easier it is to create intuitive, seamless output user interfaces. By “output” user interfaces I mean interfaces that display results or summarize data. Consider laboratory testing. A really annoying EHR user interface that I have personally experienced forces you to click on individual links generically named “lab test result” to slowly load a PDF over several seconds. You then have to scroll through the PDF to find the patient’s results, and if it’s not the lab you’re looking for, you go back to the list of vaguely named PDFs and try another one at random. It is very easy to dump PDFs into a database, but this disorganized data yields a horrible user experience. A better user interface shows the lab test results for a specific lab as a table–for example, a table of the patient’s creatinine values over time. In order to support this UI, the lab test results must be either be received as structured data via an API, or extracted from PDFs and stored in a database in structured form. It’s more work to set up a database that will store the labs in this structured way because you need pipelines for ingesting lab test results from multiple vendors and standardizing the data–but the result is a better user interface.

Unfortunately, the more you change the user interface to optimize for clean data collection, the less usable the user interface becomes! Some EHRs favor maximal structure in their user interfaces. Every interface has hundreds of buttons and boxes, and every tiny fragment of information has a special place where it’s supposed to live. The upside of this approach is that if the database has been well-designed, then these neurotic “input” user interfaces could lead to neurotically well-structured data. The huge downside is that as the user, it’s extremely tedious to have to put each piece of information into its own tiny box. Accordingly, other EHRs favor minimal structure in their “input” user interfaces. For example, in some EHRs, almost everything is collected as free text and scanned PDFs. This makes data entry extremely easy–simple typing, or file upload–but it makes the database an unstructured disaster, leading to poor “output” user interfaces like the labs disaster described previously.

One way to overcome this user interface/database catch-22 in the age of generative AI is to leverage large language models to automatically structure otherwise unstructured data.

AI interacts with user interfaces in another way too. People often like to think about what AI should add to an EHR’s user interface, but I’d argue it’s even more important to consider what AI could take away. For example: consider an AI-native EHR that has such incredible automated billing capabilities that clinicians simply never see any user interfaces related to billing, ever.

And of course, data is the foundation of performant, trustworthy AI. We can’t build good healthcare AI without good healthcare data.

Thus, an AI-native EHR must address user interfaces, databases, and AI simultaneously to maximally unlock the synergies between these components.

What could an AI-native EHR of the future look like?

This section includes possibilities for an AI-native EHR of the future. I’ll confess that a few of these possibilities aren’t AI-specific, they’re more about rethinking how EHRs should work or what kind of assumptions should be baked in to the software.

Simplifying the UI with AI

EHRs could offer support for more flexible changes to the user interface based on AI, including removal or simplification of user interface components based on AI automation. AI will never reach its full potential in healthcare if the paradigm is always “AI = more user interfaces.”

New UI defaults and hyper-customized UIs

Ambient scribing to automate note generation is already here and widespread. That’s great–we need to go further. Scrap the idea that the primary way of communicating about patients should be 10-page-long free text notes. Instead, the EHR could include a free-text narrative of the patient’s whole story, for those who want all the gory details, and then these two things:

  • a scrollable timeline of labeled dots — e.g., with hospitalizations, visits, labs, imaging — expandable to full detail;
  • a condensed bullet history.

But the key is that the timeline and condensed history are automatically customized with AI behind the scenes for each specialty, user, and patient. So an ob/gyn seeing a patient for a prenatal care visit would see information pertinent to obstetrics, while a cardiologist seeing a patient for heart failure would see information pertinent to cardiovascular health. Relevant labs and imaging could be featured too. It’s basically like AI-powered chart review, but all the time, as the default.

Going further, what if each doctor could specify what kind of user interface they want for their EHR in natural language, and this user interface could be programmatically created for them using AI, perhaps combining pre-built modular user interface components with custom spontaneously-AI-coded components?

(This is conceptually related to the concept of headless EHRs. Modern headless EHRs like Healthie allow different practices and startups to leverage the same backend but build different frontends.)

Notes

The EHR could distinguish between “notes for legal and billing purposes” and “notes for clinical use.” The legal/billing notes could be the bloated monstrosities seen in EHRs today, automatically generated by AI scribing, and never actually looked at by any humans because they’re too long. The clinical notes could hark back to the 1980s approach of handwriting on a 3×5 notecard: capped at 300 characters to include only the most pertinent information a clinician wants to remember for a patient interaction. These “micro-notes” could be written by people or AI. Notes could be organized with hashtags (#goalsofcare, #RRT, #diabetes) for improved searchability.

Medications

Current medications lists are bloated, and include medications the patient never filled and never took. EHRs need to give up on the fantasy that just because a doctor prescribed a medication, the patient is taking that medication as prescribed. Any medication list in the EHR should include this information:

  • The most recent date that the patient filled the prescription (obtained automatically by syncing data with pharmacies), and whether the patient likely still has that medication available (auto-calculated based on how long ago the patient filled it, the amount they picked up, and the dose/frequency instructions);
  • Whether the patient reports taking the medication or not. If the patient does take it, do they take it as prescribed? If not, what dose do they actually take and how often?

Medications should be displayed in order:

  • First, what medications the patient has filled and is actually taking;
  • Next, everything else, displayed in a different section or in a different color to make it clear the medication is not being taken as prescribed.

Each medication should be clearly associated with a purpose: what disease/condition the patient is taking it for.

It should be possible to search for medications the patient took in the past but stopped, and each one should have a reason it was stopped: either they recovered from the condition, the medication was ineffective, the patient had specific listed side-effects, or the patient had an adverse drug reaction or allergy.

The problem list

Some legacy EHRs show a problem list with 30+ different conditions in an essentially random order–everything the patient was ever diagnosed with. Problem lists should be displayed according to importance of the problem, something that could be automatically determined by AI and/or simple summary stats–e.g., by analyzing how often the patient is seen for that problem.

It’s also pretty morbid that many EHRs assume that once a problem is on somebody’s problem list, it should be really difficult to remove that problem from the problem list. It should be easier to put in “end dates” for conditions so that if a patient gets cured, that’s no longer showing up as an active problem. (Patients do get cured of diseases, occasionally…)

Order sets

Individual doctors should be able to easily make their own order sets, and AI should automatically surface the relevant order sets based on analysis of a visit so far, e.g., from a conversation transcript obtained through AI scribing or from a note-in-progress.

Interaction between notes and orders

In many legacy EHRs, notes and orders are separate, creating redundancy. You need to mention in the note “I’m going to prescribe medication ABC and order test DEF” and then you need to separately e-prescribe medication ABC and place the order for test DEF. AI should allow bidirectional seamless interaction between notes and orders:

  • If something is mentioned as part of the plan in a note (either a human-written or AI-written note), then the relevant e-prescriptions and orders should be queued up automatically for human approval, in a simple interface (e.g., one click to approve);
  • If a medication is prescribed or something is ordered as part of an encounter, that should be auto-documented in the note.

Interaction between patient messages and orders

All patient messages should be automatically scanned by AI and a relevant user interface queued up below each message. For example:

  • A medication refill request produces a “Refill” button below the message. If this button is clicked, multiple things happen automatically: the e-prescription is sent off to the pharmacy to do the refill, and a message is composed and sent to the patient informing them that their medication has been refilled.
  • A specialist referral request produces a “Refer” button below the message along with an AI-generated written referral for the specialist with all the relevant information pulled out of the patient’s record. The referral text can be edited if needed and then pressing “Refer” places the referral and also notifies the patient that the referral was placed.

Integration with the medical literature

Many diagnoses and treatments are algorithmic and are literally described in medical society guidelines as flow charts. These flow charts should be incorporated into the EHR so that for any given patient, the EHR will display a visualization of the flow chart for that patient along with where they are in the flow chart–making it clear what results have been obtained so far, what path the patient is on, and what needs to be done next. OpenEvidence displays figures, diagrams, and flowcharts directly, so this proposed feature would be like automatically combining these validated flowcharts in real time with the content of an individual patient’s record.

All of the calculator functionality from MDCalc should be integrated into the EHR and for any given patient encounter, AI should determine what calculators/risk scores are relevant, and automatically calculate and display the results and interpretation. Additional algorithmic processes should be incorporated such as automated analysis of a patient’s acid-base status for inpatients.

Preventative care should be more automated. Recommended screenings and vaccinations should be surfaced automatically based on the patient’s demographics and risk factors.

What kind of data could be included in an EHR on an individual level

The next generation of healthcare AI tools could be much more powerful if built upon EHR data synchronized with structured digital data from many sources. For patients who opt in, EHRs could also store:

  • Genomic information: a searchable, annotatable whole genome sequence or whole exome sequence.
  • Genealogy: family links between patients in the record. For clinicians family history could be viewable by disease, by family member, or by genealogy. (Accidentally exposed family links between patients would be a huge problem for some patients, and so this feature would have to be strictly based on mutual opt-in by each patient, and for genetics x environment research purposes only–i.e., no family relationships would ever be shown to patients.)
  • Devices/wearables/apps for outpatients: continuous glucose monitors, pacemakers, smart watches, smart rings, smart scales, etc., all integrated into the EHR along with automated systems that flag a patient to seek care (e.g., a weight increase in a patient with heart failure or a spike in blood sugar for a patient with diabetes).
  • Devices/wearables/apps for inpatients: continuous vital sign monitoring in ICU patients, cardiotocography for L&D, etc. – all integrated and saved as structured data, with AI continuously running that predicts impending medical events–like a patient deteriorating or dying.

Interoperability and data exchange between EMRs

In the U.S., we’re making some progress towards interoperability, but actual interoperability remains poor. It should be a legal requirement that every EHR be capable of exporting and importing data in a specific standardized format, to completely remove all EHR switching barriers. A medical practice should be able to export their practice’s EHR data one day, and upload it to a new EHR the next day. A patient should be able to ask for a USB of their entire personal medical record, receive it promptly, and take that exact USB to a new practice/health system for immediate structured upload and ingestion.

Medical images often need to be exchanged on CDs. We need a digital system for exchanging medical images between hospitals and practices.

Scheduling

Smart paging should bundle pages. Probably nobody will ever build this feature due to the scariness of “determining automatically if this page is important” but the honest truth is that some pages are not urgent and it’s likely not worth fragmenting the clinician’s sleep when that non-urgent page could be programmatically delivered an hour later bundled with other non-urgent pages.

Smart scheduling systems for staff should take into account circadian rhythm and schedule night shifts in blocks. Smart scheduling should favor continuity of care so that patients are scheduled with doctors they’ve already seen before. Smart scheduling for patients should enable a calendar interface where patients can see available appointment slots and book their appointments online. The “smart” aspect of this involves an AI that understands all the complicated scheduling requirements of individual doctors, specialties, and clinics, and processes this into a simple interface patients can use to self-schedule.

Patient-produced information

Patients can see notes now. It would be useful if patients could ask for corrections to their notes or add information not described in the notes. This information could be stored separately as patient-produced information.

Inbuilt AI development platform

A no-code AI platform integrated into the EHR for R&D purposes could dramatically accelerate both retrospective clinical research and healthcare AI development. The platform could be used to develop models for specific tasks–e.g., a research scientist specifies what input data should be used and what general type of model should be used, and all training and evaluation takes place automatically, like Google’s Gemini/Vertex AI/AutoML but for healthcare on EHR data–and not just for developing “agents” but also for training task-specific deep learning models which are still highly relevant in healthcare. A patient’s medical record number could be automatically used to assign a patient to a training, validation, or test set.

Going one step beyond a no-code AI platform, we can consider an agentic automated healthcare AI research framework that, given a goal like “predict hospital readmission for pediatric cancer patients”, automatically cleans the data, trains and evaluates the models, and produces artefacts like research papers or FDA applications.

Automated data cleaning

On the note of automated data cleaning–so far, nobody has fully solved the problem of automatically cleaning a healthcare dataset with AI, because each dataset is ugly in its own way, and different tasks require different approaches to data cleaning. In an automated system, a user could upload a database, and the platform identifies variable types, groups synonymous meanings (e.g., all the names for a glucose test), flags outlier cells and proposes fixes for approval, standardizes lab units, extracts entities from notes, and produces a step-by-step cleaning report. The goal would be to cut data cleaning time and cost by 70%. This could support modeling, research, billing, and/or interoperability. Multiple businesses are already working on this category of problem, e.g., Zus Health.

Rethinking paper and PDFs

Scanned paper forms, digital PDFs, and faxes aren’t going to disappear overnight, so we need a better way to ingest them with AI. AI should automatically determine which individual patient the data belongs to (often difficult, especially if only the patient’s name and birthday are in the PDF), automatically structure the data, and automatically insert it into the relevant place in the EHR. Startups like Tennr and Reducto include features that do smart healthcare PDF processing like this, and multiple big companies are working on the broader problem of “automatically structuring and analyzing scanned PDFs.”

Forms AI could be better

There are zillions of forms in healthcare: insurance paperwork, clinical questionnaires, etc. It should be possible to give the EHR a description or PDF of some form, and then have the EHR use AI to capture this information in a structured way. That could be by using AI to generate a web form that the patient fills out, or it could be using AI to have a conversation with the patient to collect the form information.

Voice interaction with the EHR

Companies like Suki are challenging the notion that users should interact with EHRs through clicking and typing. Voice commands could be used instead like “show me Ms. Smith’s MRI” or “summarize Mr. Lee’s most recent endocrinology visit.”

Voice agents: automated medical receptionists, autodialers, and intake

Voice agents are already taking over in non-health industries. A few weeks ago I called a hotel and spoke entirely to a voice agent. A voice agent for healthcare could answer phone calls from patients and interact with the EHR in an intelligent way to schedule appointments or submit requests for refills.

Autodialers are not new technology, but it boggles my mind that doctors generally don’t use them. If a doctor has 10 patients to call, they should have an autodialer functionality they can turn on that will start calling patients and will only actually transfer them to a call once somebody picks up. Possible AI automation includes delivery of completely normal results through an AI agent. (I still think discussion of abnormal results should be human to human, but maybe that makes me old-fashioned.)

Intake and other standard interactions with patients could be done through voice agents. Companies like Hippocratic AI offer many voice agents for healthcare. Multiple doctors I’ve spoken to in my consulting practice are interested in making “clones of themselves” (video and voice, individualized to their own appearance/sound) that could help streamline their practices through automating certain kinds of patient interactions. While there are multiple companies working on customizable AI avatars, these avatars are not yet ready for healthcare due to ongoing issues with unpredictable behavior. But AI avatar technology is only going to improve over time, and it will likely find its uses in healthcare settings.

Open-source EHRs

Open-sourcing EHR codebases makes it easier for other companies to determine how and where they could integrate their AI. Especially in the age of AI-assisted coding, big codebases aren’t the moat they once were, so there is less argument for closed-source than there used to be.

Ultra-minimalist EHRs

The EHR could be a blank screen that the doctor interacts with entirely through typing in free text, or speaking aloud: “show me the schedule for today” “do a chart review for every patient I’m seeing tomorrow and show it to me” “summarize Ms. Smith’s record” “what was my note for Mr. Lee the last time he was here” “I need to place an order” etc. The EHR just pulls up whatever the doctor needs whenever the doctor needs it. This can extend to phone calls: “call CT radiology” “call the patient’s healthcare power of attorney.”

Incumbents vs startups

Incumbent EHR companies have a huge advantage: they already have customers and revenue. These companies are rapidly integrating AI. But they also have a disadvantage: they’re adding AI to an existing system that was not originally built with AI in mind, which is a different game than building a fresh system from scratch for AI. It will be interesting to see how this plays out in the long run.

Adjacent Ideas

“Upwork for healthcare”: a virtual network of private practices

An AI-native EHR could support an “Upwork for healthcare”: a distributed, telemedicine-first network private practices where doctors collaborate, share records seamlessly, refer to each other, set their own hours, and use shared offices–all while maintaining the independence and flexibility of their own practice. Doctors set their own work hours and schedule. Support staff and billing are centralized and mostly automated with AI. CME events, journal clubs, and easy referrals between doctors turn it into a professional network. Doctors keep profiles advertising their expertise, patients describe what kind of care they’re looking for, and the platform matches patients with doctors–like OneMedical except it’s not amorphous corporate medicine, it’s individual doctors owning their own businesses. Variations: nights and weekends only (which also avoids syncing with existing scheduling systems), specialty specific (e.g., just pediatrics, just dermatology), or charity options connecting doctors with patients in LMICs. This has the potential to yield the scheduling efficiency and referral efficiency of the outpatient component of a large hospital system but all of the doctors on the platform would be independent.

“Expedia for health tech”: a database of health AI companies, products, and research papers

An “Expedia but for healthcare AI”: a database of every health AI company, product, and research paper, sortable by function, reviews, EMR compatibility, and whether any information exists on model architecture, performance, bias, and generalization. The platform could facilitate matchmaking between academics with commercializable ideas and people who want to build them, to streamline deployment of promising innovations. The platform could also provide visibility into “what clinicians are searching for,” which reveals the gaps.

Getting wild

A fully automated practice with an AI avatar receptionist and a Roomba-like robot that automatically rooms patients.

“Loom for medicine” with async doctor-patient consults and/or video after-visit summaries.

An automated clinic inside big apartment buildings: blood pressure cuff, laser thermometer, scale, digital stethoscope, etc. Automated patient interviewing, vitals, and medical advice. Like CVS MinuteClinic but more automated.

Questioning assumptions about how medicine is practiced: there’s group therapy, so why not group medicine? There’s a bit of this in group prenatal care, but it hasn’t spread to other specialties. Why not? Patients with similar conditions could learn from seeing how the doctor interacts with other patients who have the same condition, and some patients might like the chance to meet with others who are suffering from similar problems. Patients could opt in to “group visits” where the doctor meets with 3 to 5 people who all have the same condition, at the same time. AI automations surrounding these group visits could automate away the otherwise intimidating paperwork.

At what point does an AI-native EHR become an AI doctor?

Let’s imagine that an EHR has tons of AI integrations and automations.

AI scheduling and voice agents carry out all appointment scheduling automatically over the phone or through patient self-serve interfaces.

Patient intake is fully automated too, via AI chatbots, voice agents, or avatars that collect insurance paperwork, take a clinical history, and produce a summary of the patient’s current conditions, concerns, and symptoms. This has the limitations of telemedicine — there’s no physical exam. The AI systems include more and more video analysis capabilities, until AI agents videoconferencing with patients work alongside behind-the-scenes models that analyze the patient’s appearance, tone, and nonverbal cues. The conversation content, past records, and video analysis results get incorporated into summary predictions of “what’s going on with the patient and what do they need as their next step in diagnosis/treatment.” An AI scribe starts writing the note based on the AI-patient conversation.

The AI-native EHR uses its deep integrations with the medical literature to automatically pull in relevant diagnosis and treatment flowcharts, including all of the latest medical society guidelines and research tailored to this specific patient’s conditions. The AI also automatically calculates the patient’s risk scores and needed preventative care. This contributes automatically to the plan section of the note. The AI-native EHR surfaces relevant order sets including diagnostic tests and prescriptions likely to be relevant to this patient based on their past records and current visit. Built-in chat features answer the patient’s medical questions.

Suddenly, this AI-native EHR looks a lot like an AI doctor.

And it has more features too. The AI-native EHR predicts future patient complications, and it monitors real-time streams of data from smart devices. It flags patients who need a phone call or a visit and then calls them automatically and books their appointments. It improves itself by identifying limitations in its capabilities and conducting research on its own data to build new models that perpetually expand its skills.

Where is the line, between an AI-native EHR and an AI doctor? What is the future of AI-assisted healthcare? How will we preserve human interaction in healthcare? Will we reach a future where human clinicians focus specifically on fine motor skills, like physical exams and procedures? (At the point where AI-powered robots have the fine motor skills to suture the circumference of a tiny blood vessel, we’re all out of a job.)

The dystopian view of an AI-enabled healthcare future is that everyone will get funneled into clunky, impersonal, AI-driven care where patients get misdiagnosed due to lack of a physical exam.

The utopian view is that AI will bring healthcare to the 4.6 billion people worldwide who lack access to essential health services, including the 100 million Americans who lack a regular primary care doctor. The truth is, most people don’t have good medical care right now, and there aren’t currently enough human clinicians to bridge the gap. In the utopian view, AI-native EHRs or AI doctors enhance, augment, and expand the human core of healthcare so that everyone gets the care they deserve.

Making the utopian view a reality is a challenging task. It will require not only an understanding of medical science, but also an understanding of different cultures, languages, health literacy levels, modes of human-computer interaction, and AI safety concerns.

About the Featured Image

The featured image was generated by ChatGPT. The text in it made me squirmy–the mug that says “Human First” and the screen at the back that says “Care Augmented By Intelligence / Guided by Empathy” but I just left the text there, simultaneously unsettled and impressed that the model wrote it by itself based on this short prompt: “Generate a 2:1 image that captures an AI doctor using an AI native electronic health record to see a real human patient.” One way or another, the future’s going to be wild.

About me / stay connected

As an independent researcher (MD + AI PhD + 7 yrs prior founder/CEO experience), I build and evaluate cutting-edge healthcare AI for startups. Contact me to learn more.

Want to be the first to hear about my articles bridging healthcare, artificial intelligence, and business—and get a free list of my favorite health AI resources? Sign up here.