AI Telemedicine Software Development

What is AI telemedicine software development?

AI telemedicine software development is building the parts of a virtual care product that use models: intake summaries, queue ranking, draft visit notes, after-visit instructions and monitoring digests. Each output stays a draft until a licensed clinician accepts it, and the accepted version is what gets written to the EHR.

Where do models sit in a telemedicine product?

Models fit at five points in the visit. Each point has different inputs, different risk and a different reviewer, so plan them as separate features.

• Before the visit: A model turns the intake questionnaire and prior records into a short summary for the clinician. Input is structured answers and FHIR data; output is read-only context.
• In the queue: A model or rule set suggests an order for on-demand visits based on symptoms. This is a decision support tool, so it needs bias testing and a visible reason for each ranking.
• During the visit: An ambient scribe listens to the session audio and drafts a note. Live captions and translation also sit here, and they need low latency rather than long context.
• After the visit: A model drafts patient instructions in plain language and suggests diagnosis and procedure codes from the signed note. A clinician or coder accepts each suggestion.
• Between visits: For programs with remote monitoring, a model summarizes a month of readings into trends for the clinician's review, rather than raising one alert per reading.

Inputs each placement needs

Scoping the data early avoids surprises in the integration plan. Each placement pulls from a different source, and some sources need EHR access the product may not have yet.

• Intake summary: Questionnaire answers plus FHIR R4 reads of Condition, MedicationRequest, AllergyIntolerance and recent Observation resources.
• Queue ranking: Symptoms, age band, visit reason and wait time, with no free text from prior notes unless the bias tests cover it.
• Ambient scribe: The session audio stream with speaker labels, plus the visit type so the draft follows the right note template.
• Post-visit drafts: The signed note, the order list and the patient's preferred language.
• Monitoring digest: Device readings with timestamps and source device, and the thresholds set in the care plan.

Which rules apply to AI features in virtual care?

No single rule covers AI in telemedicine. These five set the boundaries most products have to work within.

• FDA device status: FDA's Clinical Decision Support Software guidance (issued 6 January 2026, re-issued 29 January 2026) says Criterion 1 excludes software that analyzes a medical image or a signal from a signal acquisition system. A model that interprets digital stethoscope audio or an ECG strip during a visit is outside the non-device CDS carve-out.
• Patient-facing tools: The same guidance places patient-facing tools outside the CDS carve-out. They are not automatically devices, since FDA's wellness and enforcement discretion policies may apply, but each one needs its own review.
• Nondiscrimination: Under 45 CFR 92.210, Section 1557 covered entities must not discriminate through patient care decision support tools, with compliance required from 1 May 2025. A queue-ranking model is such a tool.
• Business associates: HHS cloud computing guidance treats a service that stores ePHI as a business associate even when it cannot view the data. OpenAI, for example, signs BAAs for eligible API services with zero data retention, and consumer ChatGPT is not covered.
• State disclosure: California Health and Safety Code 1339.75, added by AB 3030, requires health facilities, clinics and physician offices that use generative AI for patient communications about clinical information to include a disclaimer and a way to reach a human, unless a licensed provider reviewed the message.

Teams that want a structure for their risk records often use the NIST AI Risk Management Framework (AI 100-1). It is voluntary and gives four functions, govern, map, measure and manage, that line up well with the evaluation and monitoring work described below.

What does the AI service layer look like?

The service layer is the code between the telemedicine app and any model. It keeps models replaceable and keeps ePHI inside a known boundary.

• Model gateway: One internal API that every feature calls. It routes to an approved model host, adds authentication, enforces rate limits and strips fields a feature does not need.
• Prompt and version registry: Each prompt template, model version and configuration has an ID. Every output records which IDs produced it.
• PHI boundary: Only hosts covered by a BAA receive ePHI. Logs, traces and error reports from the gateway stay inside the same boundary.
• Draft store: Model outputs land in a draft table linked to the encounter, never directly in the note or order tables.
• Review service: Presents the draft to the right clinician, captures accept, edit or reject, and records the final text and the editor.
• Write-back adapter: Sends only accepted content to the EHR through the telehealth integration, using the vendor's document or order APIs or HL7 v2.
• Telemetry: Tracks acceptance rate, edit distance, latency and rejections by feature and model version.

Why the gateway matters when models change

Model versions change often. With a gateway and registry in place, switching versions is a configuration change followed by a test run, not an edit in every feature. Without them, nobody can say which version wrote last month's notes.

How should the clinician review step work?

The review step should make checking a draft faster than writing from scratch, while making it hard to accept without reading. These design choices support both goals.

• Label drafts clearly: Show that the text was generated and by which feature, until a clinician accepts it.
• Show the source: Link each statement in a draft note to the transcript segment or intake answer it came from.
• Accept per section: Let the clinician accept the history, exam and plan separately, so a wrong plan does not ride in with a correct history.
• Record edits: Store the draft, the final text and the difference, which feeds the edit-distance metric.
• Block silent filing: The write-back adapter refuses content that has no accept event and named clinician.
• Fail closed: If the model or gateway is down, the clinician writes the note as usual. The visit never waits on the model.

How do you test a model before it reaches visits?

Test each feature against a fixed evaluation set before launch and again on every model or prompt change. A test harness that runs the set automatically makes this cheap enough to do every time.

• 1. Build the set: Collect de-identified or consented visit transcripts and intake records that cover common visit types, accents, interpreters and poor audio.
• 2. Define checks: For scribe drafts, check for omitted findings, invented findings and wrong medication doses. For ranking, check outcomes across age, sex, language and other groups relevant to 92.210.
• 3. Set thresholds: Agree with clinical leads on what error levels block release for each feature.
• 4. Shadow run: Run the feature on live visits without showing output to clinicians, and compare drafts to the notes they wrote.
• 5. Limited release: Turn the feature on for a small group of clinicians, watch acceptance and edit metrics, and keep a feature flag to switch it off.
• 6. Monitor: Re-run the evaluation set on a schedule and after each change, and review a sample of accepted notes each month.

AI feature failure points in virtual care

These failure points recur across AI telemedicine builds. Each one has a design answer covered above.

• Sidecar AI: A scribe in a separate app that produces a PDF or copy-paste text never becomes part of the record cleanly and creates a second chart.
• Consumer endpoints: Sending session audio or notes to a consumer chatbot puts ePHI with a service that has no BAA.
• Wrong patient context: When the intake summary pulls records for a different patient with a similar name, every later draft inherits the error. Match on more than name and birth date.
• Device signals through a language model: Passing ECG or stethoscope data to a general model can move the feature into device territory under Criterion 1.
• Unmeasured drift: Without version IDs and telemetry, a quality drop after a model update goes unnoticed until clinicians complain.
• Missing disclosure: Patient messages drafted by a model and sent without review can trigger state disclosure rules such as California's.

How Agnotic can help

AI features in telemedicine depend on the plumbing around the model, and that plumbing is the work Agnotic does. Agnotic Technologies builds the model gateway, draft store, clinician review screens and EHR write-back for virtual care products, along with the evaluation runs and telemetry your clinical and compliance leads will want to see.

Work usually starts with one feature, often the scribe, built end to end through review and write-back, so the gateway, registry and audit trail are proven before a second model is added.

Sources

• FDA: Clinical Decision Support Software guidance (January 2026)
• 45 CFR 92.210: Nondiscrimination in the use of patient care decision support tools
• HHS: Guidance on HIPAA and cloud computing
• OpenAI: Business associate agreement for API services
• California Legislature: AB 3030, health care services and artificial intelligence
• NIST: AI Risk Management Framework (AI 100-1)