Documentation is one of the most common complaints clinicians raise about their working day, and ambient tools promise a direct fix: listen to the visit, draft the note, let the clinician edit and sign. The market is crowded, the demos are impressive, and the decision usually lands on a CIO, CMIO or head of product who has to choose between buying a finished product, integrating a vendor's capability into their own software, or building something custom.
This guide sets out how to make that choice. It does not rank vendors. It lists the factors that decide whether an ambient documentation tool survives contact with real clinics, and the questions to ask before you commit.
The three options
Buy an established ambient scribe
Several vendors sell ambient documentation as a finished product, for example Microsoft Dragon Copilot and Abridge, among many others. You get a tested capture app, note templates, EHR integration work already done for common systems, and a vendor responsible for the models. You give up control over how notes are structured, how quickly niche specialties are supported, and where audio and transcripts are processed.
Integrate a vendor capability into your own product
If you are a health-tech company and documentation is one step inside a broader workflow (a telehealth platform, a specialty practice system, a care-management tool), you may want speech recognition and note drafting as components rather than a separate app. You own the experience and the data model; the vendor owns the hardest modelling problems. You also inherit the work of integration, evaluation and support.
Build custom
A custom pipeline combines speech recognition, speaker separation, an LLM that drafts the note against your templates, and your own review screens. It makes sense when your specialty, language mix or note format is poorly served, or when documentation is the core of what you sell. It is also the option with the most to maintain. Our build-vs-buy framework for when SI is the wrong answer is a useful first filter before you commit to it.
Should we build, buy or integrate an ambient clinical documentation tool?
Buy an established ambient scribe if you are a provider organisation and a product already integrates with your EHR and fits your specialties. Integrate a vendor's API if you are a health-tech company and documentation is one step inside your own product. Build custom only when your specialty, language, data or workflow is poorly served and you can fund evaluation and upkeep. In every case, test drafts on your own encounters, keep clinician review and signature in the workflow, and settle consent, BAAs and audio retention first.
Decision factors that actually separate the options
EHR integration
A draft note that has to be copied and pasted into the chart is adoption friction. US certified health IT must offer a standardized API built on HL7 FHIR Release 4, the US Core implementation guide and SMART App Launch, which gives you a common way to read patient context. Writing a draft back into the chart, launching inside the clinician's workflow and appearing in the EHR vendor's catalogue (Epic's Showroom is one example) usually depend on the vendor's own developer programmes. Ask exactly which read and write operations each option supports in your EHR version, not in general.
Specialty fit
A primary care visit, a psychiatry session and an orthopaedic follow-up produce very different notes. Check which specialties a product supports with dedicated templates, how it handles procedures and multi-party visits (interpreters, family members, trainees), and which languages it handles in the same encounter.
Clinician review and sign-off
The draft is a draft until a clinician signs it. CMS's Medicare Program Integrity Manual says the treating practitioner's signature affirms that a note adequately documents the care, and that the same practitioner concurrence is required when software captures the transcription of medical record entries. Design the review screen so edits are easy, uncertain passages are visible, and nothing is filed unsigned. The patterns in human-in-the-loop approval for SI agents apply directly.
Accuracy on your own encounters
Vendor accuracy figures come from someone else's patients, accents, microphones and templates. Run a structured pilot on your own encounters, with clinicians grading drafts against what happened in the room, and score the failure types that matter clinically.
- Omissions: findings, plans or patient concerns that were discussed but left out.
- Fabrications: exam findings or history that were never said.
- Medication, dose and laterality errors.
- Negation errors, where "no chest pain" becomes "chest pain".
- Speaker errors, where a family member's statement is attributed to the patient.
Keep that test set and rerun it whenever the vendor changes models or you change templates. Our piece on eval-first SI explains how to turn a pilot into a regression suite.
Patient consent and recording disclosure
Ambient tools record conversations, and recording-consent rules vary by state, so have counsel set the consent wording and decide how a patient can decline without friction. Voice prints are among the identifiers HIPAA's Safe Harbor de-identification method lists, so treat audio as identifiable. If the tool also drafts after-visit summaries or patient messages, state rules on generated patient communications may apply: California's AB 3030, for example, requires a disclaimer unless a licensed provider has read and reviewed the message.
BAA and data retention
Any vendor that processes or stores the audio, transcript or draft on your behalf is a business associate, and HHS guidance says that holds even for a cloud provider that stores only encrypted data without the key. Get a business associate agreement with every vendor in the path, and get written answers on how long audio and transcripts are kept, whether any of it trains models, and how it is returned or destroyed when the contract ends, which the BAA must address.
Liability and regulatory status
Whether software is regulated by FDA as a device depends on its intended use. FDA's Digital Health Policy Navigator walks through the software functions that section 520(o) of the FD&C Act excludes from the device definition, and its Clinical Decision Support Software guidance was issued in final form in January 2026. A tool that drafts a note for a clinician to edit raises different questions from one that suggests diagnoses or orders. Ask each vendor how it has assessed its status, get your regulatory counsel's view on a custom build, and agree in the contract who is responsible when a draft is wrong.
Total effort to maintain
Buying moves most upkeep to the vendor. Integrating and building keep it with you: model and API changes, EHR upgrades, new templates as specialties onboard, re-running evaluations, monitoring quality in production and supporting clinicians who need help on a busy clinic day. Count that work honestly before comparing options.
A simple way to decide
- If you are a provider organisation and an established product integrates with your EHR and covers your main specialties, start by piloting two or three products on your own encounters.
- If you are a health-tech company and documentation is one step inside your product, integrate a vendor capability through custom software around it, and keep the review experience and data model yours.
- If your specialty, language or note format is poorly served, or documentation is your core product, consider a custom build, starting with an evaluation set before any interface work.
- Whichever path you choose, do not go live until consent, BAAs, retention and sign-off are settled in writing.
Questions to ask any option
- Which EHR read and write operations are supported in our version, and who maintains the integration?
- Which specialties have dedicated templates, and how are new ones added?
- Can we run a pilot on our own encounters and keep the test set?
- Where are audio, transcripts and drafts processed and stored, for how long, and are they ever used for training?
- Will you sign a BAA covering every subprocessor in the path?
- How are model changes announced and re-validated before they reach our clinicians?
- What does the clinician see when the system is unsure, and can anything be filed without a signature?
Judge an ambient scribe on your own encounters, not on the vendor's demo.
Where Octalcode fits
For most provider organisations the right answer is to buy, and we would say so. Where documentation sits inside a health-tech product, or a specialty is poorly served, Octalcode designs and builds the custom software around it: EHR integration, review and sign-off screens, evaluation on real encounters and HIPAA-grade, BAA-ready data handling.
We sign an NDA before any client data and limit access to the project team. Our healthcare SI page explains how we approach clinical projects, and the decision about which path to take stays yours.