A medical AI engine company, built by a practicing physician
Purpose-built AI engines for each job in care, and a Clinical OS that keeps them on one patient state under one line of physician authority. The reasoning behind each step stays on that same patient state.
AI does not diagnose or decide treatment on its own. Diagnosis and treatment are the physician's authority. The physician makes the corrections, handles the exceptions, and carries final clinical responsibility.
01 · What gets scaled
The steam engine turned fuel into energy. That energy became labor, labor became scale, and factories followed. Machines took over the work that human muscle had been doing.
An AI engine takes in electricity and data, breaks them into tokens, and returns data. That data becomes patterns, and patterns become what a judgment is made from. What scales this time is not muscle. It is cognition.
Medicine is an industry that runs on cognition. The change reaches it last, and it reaches it hardest.
02 · The gap, and the redesign
In 1882, the year Edison's Pearl Street Station opened, factories dropped a large electric motor into the spot where the steam engine had stood and left the shafts, the belts, and the floor plan exactly as they were.
Electricity showed up in US manufacturing productivity in the 1920s, once every machine had its own motor and the floor had been redrawn around the flow of work. What produced the jump was the redesign that took the machines off the shaft.
Hospitals still run the old floor plan. The director moves between the exam-room monitor and the phone, carrying the checks and the handoffs on either side of a judgment.
Connecting general-purpose AI to clinical work runs into the same thing, and for the same reason it has to be designed AI-native from the start.
Source: Paul A. David, "The Dynamo and the Computer", American Economic Review 80(2), 1990, 355-361. What the paper supports is the gap and the redesign in the electrification case. The author also wrote that the analogy should not be carried over literally to other technologies. We use it as a precedent, not as proof.
Hospitals stand in the same place. The redesign is taking the floor off the one shaft and giving each job its own drive.
The chart records what finished. We handle what has not finished yet.
03 · One job that never finished
The patient was told what to do.
The appointment was never booked.
Nobody did anything wrong. It is only that no one knows where the case stopped. Finished work goes into the chart. Unfinished work goes nowhere.
Golden Clinical Loop
Hospital work moves between screens, messages, and what people remember. That leaves work that was handed off and never confirmed. We connect one case as a single loop, from the moment it starts to the moment evidence closes it.
A well-built chart system can show state too. What we build is AI that prepares the next action inside a boundary that has been set. The AI is not a stand-in for a member of staff. It is an actor with stated authority and a stated verification boundary.
One job is where this starts, not where it ends. We do not lay AI over the work as it stands. We rewrite hospital work from the beginning, on the premise that people and AI do it together.
Pre-launch validation
The source, the time of observation, and the uncertainty are preserved.
From the confirmation stage on, the AI holds no authority. Step through it and see who can do what at each stage.
We describe only where the patient currently stands, who approves, the record of why it was done that way, and how completion is confirmed. We publish no effect figures.
04 · The engine lineup
All engines in pre-launch validation
What we do is AI-augmented medicine: medicine that extends the physician instead of standing in for one. It does not mean handing care over to AI. The clinical judgment stays with the director. It means the checks, the handoffs, and the tracking that lead up to that judgment no longer have to pass through the director in person.
We do not build one large AI that does everything. Each job gets its own engine with a defined scope, and those engines are held on one patient state under physician authority. Below are the engines we are building and what each one covers.
Covers what happens where a patient reaches the clinic.
Prepares what the physician will review. It does not judge.
Covers confirmed work until it is finished.
Where this is going
A single job closes. One patient's loop does not.
We are working toward a layer that carries clinical signal in one flow, from conversation to imaging to vital signs, and on through the physician's judgment to what actually happened. We read a patient as a continuing loop, not as one visit.
Today we are at the first step. Inside our own practice we build and test one loop: structuring the exam-room conversation so a physician reviews it.
Imaging equipment and vital-sign streams are not connected yet, and we have no integration record to show.
The final clinical judgment stays with the director. What changes is what they see first, what is left unfinished, and when an exception reaches them. The director moves from carrying every task to setting the standard and approving the exceptions. How much of that changes differs by hospital. We do not hand you a percentage.
05 · The name of that layer
Pre-launch validation
We take clinical work apart one job at a time, build an engine for that job, and gather those engines into one layer. Together they are The Vertical AI Platform for Medicine.
Every hospital needs a different set of loops. The set chosen for one hospital is that hospital's AI-native care system. We call getting there a transition.
Purpose-built AI engines for each job in care, and a Clinical OS that keeps them on one patient state under one line of physician authority.
It does not replace the EMR.
06 · Clinical safety principles
Pre-launch validation
We describe only where the patient currently stands, who approves, the record of why it was done that way, and how completion is confirmed. We publish no effect figures.
See the clinical safety principlesWhich patient and which encounter is settled before anything else.
Anything that needs authority waits until the physician confirms it on the working screen.
State is checked so the same action does not run a second time.
Nothing closes until the evidence of completion has been confirmed.
The clinical procedures the hospital has set sit above the execution boundary.
Final clinical judgment and responsibility rest with the physician.
07 · What you can look at today
Reference apps we build ourselves
The screen shows synthetic data from a demo account. It does not represent real hospital data or operating results.
Pre-launch validation
Patient messaging channel connection
Prepares English guidance and staff handoff on messaging channels authorized by the healthcare institution. No customer account or real patient message is currently connected.
Pre-launch validation
Live medical interpretation
Interprets the exam-room conversation across seven languages in real time, and keeps the speaker and the language direction in the record.
Pre-launch validation
Live clinical reasoning
During the visit it lays out what to check and the evidence behind it, on the physician's review screen.
Pre-launch validation
Agentic hospital manager
Reads operating state and proposes the next task inside set authority and a set order of confirmation. We are testing that on validation screens.
Pre-launch validation
Closing a single job
The structure that carries one case across eight stages, from the moment it starts to the moment evidence closes it. We are testing the checkpoint at each stage.
Pre-launch validation
Pigment vertical
A vertical AI for pigment treatment in dermatology. It produces reference output for a physician to review.
Pre-launch validation
Wound vertical
A vertical AI meant to carry a plastic surgeon's standard of judgment to places that have no plastic surgeon. It is at the research and joint-development stage.
Reference app for teaching hospitals
Pre-launch validation
An on-call case screen for interns and residents
It helps a resident structure a case and get ready to report it to a senior physician. It is a reference app for teaching hospitals, kept apart from the clinic purchase path.
For each product we mark how far it is prepared and what has not been validated yet.
Fifteen minutes on one job that keeps getting handed off by word of mouth and on who carries it today, ending at whether it fits a transition review.
08 · Evidence and boundaries
We show only public evidence that carries a date. Anything we have not confirmed is not written up as a figure or as a finished state.
See every dated recordWe build, test, and measure inside the aesthetic and dermatology practice where our founder still sees patients every week.
This is not a count of outside institutions that adopted anything. It is the access we have to build and test inside our own practice.
We published Whitepaper v2.0, separating the evergreen paper from a dated evidence appendix.
We do not flatten products that are at different stages into one level. Facts that change with the date are written in the evidence appendix, not in the paper.
AetherHeal is a member of the NVIDIA Inception program.
We record membership status only. It is not an endorsement of the product or the company.
What is open to request today
Pick one job where the director keeps going back between a call and a message to check whether it actually finished. Nothing about a patient or a clinical record needs to be prepared before the call.
The call runs as a 15-minute fit check, not as a sales meeting. If it is not a fit, we will say so.
Products that need no access to hospital systems are on the platform page.
15-minute fit call
Write to us about one job that keeps getting handed off by word of mouth, and who carries it today. English or Korean is fine.
Email us