Notermed is an AI scribe for medical practices. A doctor records the visit, the app turns the conversation into a clinical note, and the doctor reviews and signs it.
When we built it, the AI ran on OpenAI. Then a simple requirement changed everything: every piece of patient data had to stay with providers covered by a HIPAA agreement. The cleanest way to meet that was to move all of the AI onto Amazon Bedrock, which is covered by our agreement with AWS.
On paper, switching AI providers is a configuration change. In practice, it was a short project with real decisions in it. If you lead a team that uses AI, or plans to, these are the lessons worth knowing before you start.
1. Decide where your data may go, then make anything else impossible
The tempting plan was to keep the old provider as a backup, just in case. We didn’t. A backup that can receive patient data is also a way for patient data to leak, the first time someone flips the wrong setting.
So we removed the old provider completely. The app now cannot even start if someone tries to point it back. For compliance, “we promise not to use it” is weaker than “it is no longer possible.”
For managers: When you write an AI policy, ask your team how the system enforces it, not only whether it does.
2. “Supported” and “works with our setup” are two different answers
Our first choice of AI model was available on the platform and listed as supported. It still failed, because of a small mismatch with the version of the software library we use. We picked an equivalent model that worked, inside the same compliant platform.
For managers: Budget a few days of testing for any provider switch, even when the vendor says it is a drop-in replacement. The surprises are small, but they stop releases.
3. Your AI’s “memory” is tied to the model that built it
Notermed can answer questions from a clinic’s own documents: guidelines, forms, internal procedures. To do that, the documents are converted into a format the AI can search. That format depends on the exact AI model that created it.
Change the model, and every document has to be processed again. We did that into a fresh store and kept the old one untouched, so we could roll back in minutes if anything went wrong. One admin screen kept showing the old store after the switch and confused users for a while. Small things like that are why you plan a rollback.
For managers: Treat an AI model change like a data migration, with a rollback plan, not like a settings tweak.
4. Real documents break assumptions
The new model has a limit on how much text it accepts at once. Our default settings sent larger pieces, so some uploaded PDFs and Word files simply failed. The fix was to cut documents into smaller pieces and enforce the limit strictly, instead of trusting an estimate.
For managers: Test with your customers’ real, messy files, not with clean samples. That is where production issues hide.
5. In medicine, the AI must not be “helpful”
Language models are trained to complete things. In a medical note, that is dangerous. If a doctor never examined the lungs, the AI must not write “lungs clear” just because most notes in the world say that.
So the instructions we give the AI read like a contract: use only what was said in the visit, never guess a diagnosis, dose or test result, never add standard “normal” findings, and leave a section out rather than fill it with assumptions. If the plan is unclear, the note says “Pending clinician review.” The doctor always has the final word.
For managers: In any high-stakes AI feature, define what the AI must never do before you define what it should do.
6. Customization must never take the core feature down
Clinics and individual doctors can adjust how their notes are written and which model writes them. Those settings are useful, but a broken setting must not stop a doctor from getting a note. Every customization falls back to the standard behaviour if anything goes wrong.
For managers: Ask your team what happens when a customer’s custom configuration is broken. The right answer is “they still get the standard result.”
7. Keep each customer’s data in its own lane, all the way down
Each clinic’s documents are visible only to that clinic. Separating customers in the database is the obvious part. The less obvious part is the AI search itself: it also has to be restricted to the customer’s own documents, or it could quote another clinic’s material.
For managers: When your product adds AI, ask whether customer separation still holds inside the AI features, not just in the database.
The short version
The switch itself went smoothly, and the product’s core logic barely changed. The work was in decisions: where data may go, how to roll back, how to handle real documents, and what the AI must never do. Those decisions matter more than which AI model you choose.