Crescendo - Ambient Intelligence for Clinicians
Save hours each day in your physician practice
Our ambient AI summarizes conversations into clinical notes, instantly.
Ambient AI listens to a clinical conversation and produces a structured note, so documentation stops competing with the patient in front of the clinician. These 6 rows summarise how the Crescendo demo above is built and governed.
| Aspect | How it works |
|---|---|
| Input | A transcript of the clinician-patient conversation, captured ambiently rather than typed during the visit. |
| Output | A structured clinical note summarising the encounter, produced for the clinician to review and correct. |
| Clinician role | Review and sign-off stay with the clinician — the output is a draft, not an authoritative record. |
| Where it runs | Inside your own cloud account on Kubernetes, so protected health information stays within your boundary. |
| Safeguards | Jarvis guardrails apply PII handling, denied topics, and full message logging on every interaction. |
| Audit | Each interaction is logged in your environment for compliance review and SIEM ingestion. |
Clinical deployments turn on 3 questions: where the data sits, who signs the note, and what the audit trail proves. The rows below answer each one, and cite the regulation the safeguards are designed against.
| Specification | Value |
|---|---|
| Input | 1 ambient transcript of the clinician-patient encounter |
| Output | 1 structured draft clinical note, presented for review |
| Notes written without review | 0 — clinician approval is part of the workflow, not a setting |
| Hosting | Customer-owned Kubernetes cluster on 1 of 3 supported clouds |
| PHI leaving the account | 0 bytes — no shared control plane and no external data plane |
| Guardrails | 100+ prebuilt policies across 4 control layers, applied before the model call |
| Caller identity | Azure EntraID via OpenID Connect Core 1.0; SAML 2.0 supported |
| Authorization | OAuth 2.0 (RFC 6749), Bearer usage per RFC 6750 |
| Transport security | TLS 1.2 minimum, TLS 1.3 preferred (RFC 8446) |
| Audit record | 3 artefacts per encounter — transcript, draft, and review outcome |
| Telemetry | OpenTelemetry OTLP spans for each interaction |
| Regulatory reference | HIPAA Security Rule, 45 CFR Part 164 Subpart C |
| AI governance reference | NIST AI RMF 1.0 (2023) |
| Zero-trust reference | NIST SP 800-207 (2020) |
| Pilot footprint | 1 cluster, 1 clinic, 1 encounter type before access widens |
| Recommended review window | The first 2 weeks of interactions, reviewed weekly |
This is a different healthcare use case — pharmacy fraud detection — recorded on the same governed platform. It is included because it shows the audit and policy layer working on real health-sector data.
The demo above runs the same 5 stages a production deployment does. Trying it with the sample transcript is the quickest way to see where a clinician stays in control of the output.
Capture the conversation. The encounter is transcribed ambiently, so the clinician is not typing while the patient is talking.
Filter before the model. Guardrails apply PII handling and policy checks before any content reaches a language model.
Summarise into a note. The model produces a structured draft note from the transcript rather than free-form prose.
Clinician reviews and corrects. The draft is presented for review; nothing enters the record without a clinician approving it.
Log the interaction. The transcript, the draft, and the review outcome are recorded in your own environment for audit.
Healthcare deployments live or die on what happens to the content before and after the model call, which is why the same guardrail and audit layer used across Jarvis applies here without modification. There is no clinical-specific exception path: the same 2 controls that protect a support conversation protect a patient encounter.
Clinical deployments raise a narrower set of questions than general enterprise AI, and they are almost always about data boundaries and clinician control.
No. Jarvis is licensed, customer-hosted software: it deploys into your own Kubernetes cluster, and prompts, transcripts, and generated notes stay inside your account.
There is no shared control plane and no external data plane, which is the property that makes a protected health information workload tractable in the first place.
No. The output is a draft note for the clinician to review, correct, and approve. Human review is part of the workflow rather than an optional setting.
That boundary is deliberate: ambient AI is intended to remove typing from the encounter, not to remove clinical judgement from documentation.
Keeping inference and storage inside your own account means the technical safeguards you already operate — access control, audit controls, and transmission security — continue to apply to the AI workload.
Jarvis adds the AI-specific pieces on top: identity-bound access to models, guardrails on the request path, and a full interaction log for the audit trail.
Yes. The demo above runs a sample encounter end to end, including the example transcript, so a clinical team can judge output quality before any infrastructure work starts.
A production pilot then follows the standard Jarvis rollout: 1 cluster, 1 team, and a reviewed audit trail before wider access.
The strongest fit is a conversational encounter with a predictable structure — history, examination, assessment, plan. The sample transcript in the demo above is deliberately of that shape: a presenting complaint, a series of clarifying questions, and a plan at the end.
Encounters that depend heavily on what the clinician is looking at rather than saying are a weaker fit, because the transcript alone does not capture them. Those are better served by structured templates than by ambient capture.
Starting with 1 clinic and 1 encounter type is the usual approach: it gives a clean comparison against how those notes are written today, without confounding the result with 5 different documentation styles.
The goal is to move documentation out of the encounter itself. Instead of typing while the patient talks, the clinician reviews a draft afterwards and corrects it — which is a different and usually faster task than composing from a blank field.
Measure it on your own data rather than on a vendor claim. Record how long the current note takes for a given encounter type, run the same encounter type through the draft-and-review flow, and compare across at least 2 weeks so novelty effects wash out.
The audit trail supports that measurement directly, because it records the draft, the reviewed version, and the time between them for every interaction.
Three things, in this order. A Kubernetes cluster in the account and region that already holds your clinical data. An identity provider connection, so every interaction carries a real clinician identity rather than a shared login. And a named reviewer for the audit trail during the pilot period.
The third is the one most often skipped, and the one that matters most: an audit log nobody reads is evidence you cannot act on. A weekly review of the first 2 weeks of interactions is usually enough to tune guardrail policy before access widens.
Nothing here is specific to ambient AI — it is the same rollout discipline the rest of the Jarvis platform follows, applied to a clinical workload.
Ambient AI reuses the Jarvis governance stack. These pages cover the controls and the healthcare practice behind it.
ASCENDING is an AWS Advanced Tier Services Partner with the AWS Generative AI Competency, and builds Jarvis as licensed software that runs inside your own cloud account. The references below cover the regulatory and technical frameworks behind a clinical deployment.
