Suno Clinical Bridge

Inspiration

Suno Clinical Bridge was inspired by one of the most persistent problems in healthcare: doctors spend too much time documenting visits and too little time focusing on patients. Clinical conversations are rich with useful information, but turning that unstructured dialogue into standardized records is slow, repetitive, and mentally draining.

We wanted to build something that could act as an intelligent bridge between natural conversation and interoperable clinical data. The idea was to combine conversational AI, MCP-based tool orchestration, and FHIR R4 so that spoken or typed encounters could be transformed into structured, doctor-reviewable records.

What it does

Suno Clinical Bridge is an MCP-powered clinical scribe system that helps convert doctor-patient conversations into structured healthcare data. It can:

transcribe recorded clinical audio into text
structure a conversation into a clinical encounter payload
retrieve a patient's prior medical history from a FHIR server
suggest possible diagnoses, red flags, and next steps
write doctor-approved encounter data back into the EHR as FHIR resources
support direct patient and chart operations such as conditions, allergies, observations, medications, and appointments

At a high level, the project follows this pipeline:

$$ \text{Audio or Transcript} \rightarrow \text{Structured Encounter} \rightarrow \text{Diagnosis Support} \rightarrow \text{FHIR Commit} $$

How we built it

We built Suno Clinical Bridge as a modular MCP server connected to a FHIR R4 backend and powered by Gemini for the AI workflow.

The system has three main parts:

mcp_app/ for the server, tool registration, request handling, and FHIR context resolution
shared/agents/ for the AI pipeline: transcription, structuring, and diagnosis support
shared/fhir/ for schemas and conversion of structured payloads into real FHIR transaction bundles

The workflow works like this:

The Prompt Opinion platform LLM calls our MCP server over HTTP.
The MCP server exposes tools for reading patient data, structuring encounters, suggesting diagnoses, and committing results.
Gemini handles the AI steps using structured outputs validated through Pydantic schemas.
The FHIR client reads and writes patient records from the connected EHR-compatible backend.

Instead of relying on loose text generation, we used schema-validated JSON outputs. If T is the transcript, S is the structured payload, and H is prior patient history, then the reasoning flow is:

$$ T \rightarrow S $$

$$ (S, H) \rightarrow D $$

where D is a diagnosis-support object containing a ranked differential, red flags, and recommended next steps.

Challenges we ran into

One major challenge was converting messy, natural conversation into structured clinical information. Real doctor-patient dialogue is often interrupted, informal, and ambiguous, so distinguishing symptoms, diagnoses, medications, and vitals required careful prompt and schema design.

Another challenge was mapping AI output into FHIR resources. FHIR is flexible, but that also means we had to make thoughtful decisions about how to represent observations, conditions, medication statements, allergies, and clinical impressions in a way that was both valid and useful.

We also had to balance model helpfulness with safety. In a clinical setting, guessing is dangerous, so we designed the system to prefer omission over hallucination and to keep the physician in control of final approval.

Finally, orchestrating multiple layers at once, including MCP, Gemini, HTTP-based tool calls, authentication context, and FHIR persistence, made the architecture more complex than a typical chatbot project.

Accomplishments that we're proud of

We are proud that Suno Clinical Bridge is more than a simple demo. It is a full workflow-oriented system with:

a publishable MCP server
a multi-stage clinical AI pipeline
validated structured outputs instead of brittle string parsing
FHIR-compatible persistence back into an EHR-style system
a design that keeps doctors in the approval loop

We are especially proud that the project connects modern AI tooling with a real interoperability standard instead of stopping at a flashy interface.

What we learned

We learned that building healthcare AI is as much about structure and reliability as it is about intelligence. Prompting matters, but schema design, validation, and careful data modeling matter just as much.

We also learned how powerful MCP can be for tool orchestration. It gave us a clean way to expose a set of targeted capabilities to a platform LLM without collapsing everything into one monolithic prompt.

On the technical side, we gained experience with:

structured LLM outputs
async Python service design
FHIR-based resource modeling
AI pipeline decomposition
tool-based orchestration between systems

On the product side, we learned that trust is everything. A clinical assistant has to be transparent, constrained, and supportive rather than overconfident.

What's next for Suno Clinical Bridge

The next step for Suno Clinical Bridge is to make it more production-ready and clinically robust.

We would like to add:

stronger coding support for standards like SNOMED CT, LOINC, and RxNorm
better handling for larger audio uploads and more diverse recording quality
richer patient history summarization across longer clinical timelines
more advanced physician review interfaces before FHIR commit
improved auditability and traceability of which history signals influenced each recommendation
tighter security and deployment support for real healthcare environments

Longer term, we want Suno Clinical Bridge to become a trustworthy interoperability layer between clinical conversation and standardized medical systems:

$$ \text{Conversation} + \text{Clinical AI} + \text{FHIR} \rightarrow \text{usable healthcare workflow} $$

That is the vision we are excited to keep building toward.