Our principles
Careful by design.
Specific by choice.
The record underneath the note matters. So do the boundaries around the software preparing it.
What makes it different
Specifics, not adjectives.
Seven properties of how the system is being built. The specificity is the point: this is a system of record, not a documentation layer on top of someone else's EHR.
-
Audio is never stored.
The recording is held in memory only, zeroed immediately after transcription, never written to disk, and never sent to a third-party transcription vendor. Only the transcript text moves onward.
-
The model cannot invent a code.
A separate terminology step builds a bounded list of candidate codes from standard code sets such as ICD-10-CM and RxNorm, and the language model may only select from it. A validation gate then independently re-checks the finished record and rejects any code that wasn't in the candidate set. The rule is enforced by code, not by asking the model nicely.
-
AI-assembled records are validated before they are written.
Each record the AI assembles is checked by HL7's official FHIR validator against the US Core 6.1.0 implementation guide before it is stored. If the validator can't run, that counts as a failure — "couldn't check" is never treated as "passed."
-
Only a clinician with signing authority can sign.
Enforced in independent layers: the server's own signing command, its access-control policies, and a guard on the automated processes that write drafts. No automated process in the system can produce a signed note.
-
Everything starts as a draft.
Anything the AI produces stays a draft until a clinician approves it, item by item.
-
Standards-native means portable.
The chart is standard FHIR R4 rather than a proprietary schema, so the data isn't locked in.
-
Automated processes cannot rewrite the audit trail.
Changes to the record are logged in an audit trail. The system's own automated processes can add entries to it, but they cannot edit or delete them.
Built on standards
A chart you could take with you.
The record underneath the note is stored as standard FHIR R4 resources, and AI-assembled entries are checked against US Core — the US profile of the FHIR standard for health data exchange. It is not a schema invented for this product. Problems, medications, allergies, observations and orders are stored as standard resources, coded with standard vocabularies such as ICD-10-CM, RxNorm and LOINC.
Practically, that means the chart can be exported in a standard format rather than one only this product can read, and the vocabulary in it is the vocabulary the rest of US healthcare already uses.
One clinic, one deployment.
Each clinic is planned to have its own separate deployment and database, not one shared with other clinics.
An invitation, not a launch
Built with care.
Still being built.
HealthAI is in development. If you want to be involved early, you would be working directly with the person building it.
Please don't include patient or health information in email.