Skip to content
Back to case studies
Case studyTelehealth software

Months with a previous vendor. Grail completed the clinical workflow.

A previous vendor had left the clinical-record workflow unfinished. Grail took over and completed the path from doctor-patient call to a structured record the doctor can check and approve.

The problem

The previous vendor left doctors with the same work after every call.

The company wanted each consultation to end with the clinical record ready to check. The unfinished version still left doctors reconstructing the conversation, writing the note and preparing medication instructions after the call.

Grail took over and completed the workflow inside the existing consultation screen. The public video uses a fictional patient to show how the call becomes a structured draft, how medication details are checked against the doctor’s words and how the doctor approves each part before it is saved.

01 · What we built

The consultation becomes a draft record before the call ends.

The workflow records consent, separates the doctor and patient, and sends the transcript through the Grail LLM Gateway. It returns a structured summary, observations and next steps while the doctor is still on the consultation screen.

Medication instructions appear only when the doctor has stated the medicine, dose and frequency. The server checks each detail against the transcript, removes anything it cannot find and asks the doctor to approve the note and medication separately.

Follow the call

Consent, separate doctor and patient turns, and the patient context already in the app.

Prepare the draft

A structured note and medication instructions tied to the doctor’s words.

Wait for approval

The doctor checks each part before anything can be saved.

02 · How it fits

It works inside the software doctors already use.

The company kept its video, scheduling and patient-record systems. Grail added the assistant inside the consultation screen and limited the data exchange to the information needed for that appointment.

Existing platformConsultation begins

The appointment, doctor, patient context and consent state are shared.

Clinical assistantDraft is prepared

The transcript becomes a note with medication details linked to the doctor’s words.

DoctorReview and correct

Every part remains editable and clearly marked as a draft.

Existing platformApproved record

The checked note returns through the platform’s API or FHIR connection.

Stay in one screen. Add the assistant as a panel, embedded page or native part of the existing product.

Use the existing patient record. Map the note and medication fields to the company’s format instead of creating a second copy of patient data.

Separate every customer. Keep credentials, stored data, retention rules and usage records apart for each organisation.

03 · Testing accuracy

Every change must pass the same clinical examples.

Doctors agree on a set of example consultations and the correct record for each one. We run the complete set after any change to the model, its instructions, transcription or record format.

PartWhat can go wrongHow we test it
TranscriptA medical term is wrong, a speaker is mixed up or part of the call is missingReplay approved examples across accents, audio quality and consultation types
Clinical noteAn important detail is missed or a statement appears that was never saidCompare every field with a clinician-written answer and its source in the transcript
Medication draftThe medicine, dose or frequency is wrong or unsupportedReject any draft that cannot point to the doctor’s exact words
Consultation flowThe draft is late or one service stops respondingTest timeouts and recovery while making sure the doctor can keep working
Doctor reviewThe doctor has to rewrite too much of the draftMeasure approval time and edits during a limited trial before saving to live records

04 · Choosing an AI model

Use the least expensive model that still passes every clinical test.

The workflow sends one clearly defined job through the Grail LLM Gateway. It records the model used, response time and token count so every result can be traced to the setup that produced it.

Every candidate model runs against the same test consultations. The default is the lowest-cost model that meets the agreed standard. Harder cases can move to a stronger model; missing evidence always sends the decision back to the doctor.

1Use the default

The transcript is clear, the expected fields are present and every check passes.

2Try a stronger model

The transcript is unclear, statements conflict or the first answer does not match the required format.

3Ask the doctor

Consent is missing or a clinical detail cannot be supported by the conversation.

A replacement model first runs beside the current one without changing the doctor’s record. It takes over only after performing better on the same consultations.

05 · Controlling cost

Measure the cost of an approved record, not one AI response.

A low-cost draft is still expensive if the doctor has to rewrite it. The real cost includes transcription, the AI response, retries and the doctor’s review time.

Use stronger models selectively

Spend more only when the first route is measurably uncertain.

Send less context

Reuse stable settings and send only the patient information needed for this task.

Set a consultation budget

Track transcription, AI responses, retries and test runs for each customer.

Count doctor edits

Measure how much work remains after the model returns its draft.

06 · Improving over time

Every doctor correction becomes a test for the next version.

  1. 01
    Measure

    Record the model, response time, cost, doctor edits and approval result. Keep patient details out of general application logs.

  2. 02
    Learn

    Turn each approved, de-identified correction into a new test case so the same mistake is easier to catch next time.

  3. 03
    Compare

    Run the current model and each possible replacement on the same examples. Change only when another model is safer or clearly more useful.

  4. 04
    Roll out

    Use the new setup for a small share of consultations first. Keep the previous version ready until the replacement has proved itself.

The doctor can always continue without it.

If transcription, generation or saving fails, the consultation continues. The doctor can finish the record manually while the product records which step failed.

07 · Protecting patient data

Nothing enters the patient record without the doctor.

A real integration starts with the country, the data rules and the telehealth company’s responsibilities. Access, storage, retention, deletion and incident response all need a named owner before patient information is connected.

Every draft stays attached to its consultation, doctor, source and change history. The model never diagnoses or prescribes. The doctor remains responsible for checking and approving the final record.

The result

Grail owned the full workflow, from the call to the approved record.

The completed build works inside the existing product, checks its own output, controls cost, protects patient data and keeps the doctor in charge. That is what turned an unfinished vendor project into a clinical workflow the company could keep improving.

Discuss a workflow
Back to case studies