> ## Documentation Index
> Fetch the complete documentation index at: https://developer.suki.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Ambient Interoperability

> Learn about interoperability and how it works across Suki modalities for Ambient workflows

<div className="quick-summary-wrapper">
  <div className="quick-summary-header">
    <span className="quick-summary-icon" aria-hidden="true" />

    <span className="quick-summary-title">Quick summary</span>
  </div>

  <div className="quick-summary-content">
    Ambient interoperability enables multiple Suki ambient products to contribute to the same clinical note for a patient visit. By supplying an `emr_encounter_id` when creating ambient sessions, Suki associates those sessions with one shared note. This allows clinicians to start recording on one product, continue or re-ambient from another, review and edit in other modalities, and retrieve the latest note through the Ambient APIs, all without creating separate notes.
  </div>

  <div className="quick-summary-footer">
    <span className="quick-summary-footer-icon" aria-hidden="true" />

    <span className="quick-summary-footer-text">Last updated:</span>
    <span className="quick-summary-footer-date">July 2026</span>
  </div>
</div>

<Info>
  **Supported interoperable modalities:** Ambient APIs, Mobile SDK, Headless Web SDK(coming soon), and Web SDK.
</Info>

<Warning>
  Interoperability applies only to **ambient workflows**. It is not supported for Dictation or Form filling workflows.
</Warning>

Ambient interoperability lets you run Ambient documentation for one patient encounter **across more than one Suki modality** (Mobile SDK, Headless Web SDK, and Web SDK), and keep a single shared clinical note. For example, a clinician can start recording on the Mobile SDK, continue or review in the Web SDK, and retrieve the latest note through the Ambient APIs.

Before ambient interoperability, each ambient session belonged to the Suki product where it was created. For example, if you started a session using the Mobile SDK, you could only continue or retrieve that session from the Web SDK. A session created through the Ambient APIs could only be managed through the APIs.

With <Tooltip tip="Interoperability is the ability of different systems, devices, or software applications to communicate, exchange data, and use that information seamlessly." cta="View in Glossary" href="/Glossary/i">interoperability</Tooltip>, you can now create and access ambient sessions across different Suki products for the same patient encounter.
When supported Suki products create or access an ambient session using the same `emr_encounter_id`, they work with a single shared clinical note for that patient encounter.

This lets clinicians and you build product integrations without losing context when switching between different ambient modalities. Clinicians can:

* Start an ambient session using the Mobile SDK.
* Start a new ambient session on the Web SDK for the same clinical note.
* Open the same clinical note in the Mobile SDK to review, edit, and submit it.
* Retrieve the latest version of the note through the Ambient APIs using the `emr_encounter_id`.

## How interoperability works

The core of ambient interoperability is a **shared clinical note**.
When you create an ambient session and provide an **`emr_encounter_id`**, Suki creates a new clinical note for that patient encounter, or reuses the existing one if a note already exists for the same encounter.

Every compatible ambient session created with that **`emr_encounter_id`** is linked to the same clinical note, regardless of which Suki product started the session.

The products do not share audio recordings. Instead, each ambient session contributes to the same clinical note. Because every supported ambient product references the note using the same **`emr_encounter_id`**, clinicians can continue recording, re-ambient, review, edit, or retrieve the same note across different products during the patient visit.

```mermaid actions={false} theme={"theme":{"light":"github-dark","dark":"material-theme-darker"}}
%%{init: {'theme':'base', 'themeVariables': { 'primaryColor':'#FFF394','primaryTextColor':'#111827','primaryBorderColor':'#FFE148','lineColor':'#FFE148','secondaryColor':'#FFF394','tertiaryColor':'#FFFADE','mainBkg':'#FFF394','secondBkg':'#FFFADE','tertiaryBorderColor':'#FFE148','border1':'#FFE148','border2':'#FFE148','arrowheadColor':'#FFE148','fontFamily':'Inter, system-ui, sans-serif','fontSize':'14px','nodeBorder':'#FFE148','edgeLabelBackground':'#FFE148','clusterBkg':'#FFFADE','clusterBorder':'#FFE148','defaultLinkColor':'#FFE148','titleColor':'#111827','nodeTextColor':'#111827'}}}%%
flowchart LR
    A[Create Ambient session<br/>with EMR Encounter ID] --> B[Suki creates or finds<br/>shared clinical note]
    B --> C[Ambient session 1]
    B --> D[Ambient session 2]
    B --> E[Ambient session 3]
    C --> F[Retrieve latest note]
    D --> F
    E --> F

    style A fill:#FFF394,stroke:#FFE148,stroke-width:2px,color:#111827
    style B fill:#FFF394,stroke:#FFE148,stroke-width:2px,color:#111827
    style C fill:#FFF394,stroke:#FFE148,stroke-width:2px,color:#111827
    style D fill:#FFF394,stroke:#FFE148,stroke-width:2px,color:#111827
    style E fill:#FFF394,stroke:#FFE148,stroke-width:2px,color:#111827
    style F fill:#FFF394,stroke:#FFE148,stroke-width:2px,color:#111827
```

## Headless and Headed products

Ambient interoperability works across all Suki products that support ambient workflows.

| Product type | Products                                   | Purpose                                                                                |
| ------------ | ------------------------------------------ | -------------------------------------------------------------------------------------- |
| **Headless** | Ambient APIs, Mobile SDK, Headless Web SDK | Capture audio and integrate ambient into your own application experience               |
| **Headed**   | Web SDK                                    | Capture audio and provide the complete Suki review, editing, and submission experience |

Because every product references the same note, you can combine headless and headed integrations within the same patient encounter.

## How to implement interoperable Ambient sessions

To create interoperable ambient sessions, provide the same `emr_encounter_id` whenever sessions belong to the same patient visit.

During the ambient workflow for the same patient visit, you need to:

<Steps>
  <Step title="Create an Ambient Session">
    Create an ambient session using the same `emr_encounter_id` as the previous sessions.
  </Step>

  <Step title="Receive the Shared Note Identifiers">
    Suki creates a shared clinical note and returns identifiers, including the `composition_id`.
  </Step>

  <Step title="Create Additional Sessions for the Same Visit">
    Create additional ambient sessions for the same visit using the same `emr_encounter_id` and `encounter_id`.
  </Step>

  <Step title="Continue Across Products">
    Continue recording, re-ambient, review, or edit from any supported Suki product that supports ambient workflows.
  </Step>

  <Step title="Retrieve the Latest Note">
    Retrieve the latest note content through the Ambient APIs using the `composition_id`.
  </Step>
</Steps>

<Note>
  If you do not provide an `emr_encounter_id`, Suki creates a normal ambient session, but it remains independent and cannot participate in interoperability.
</Note>

## Common integration patterns and use cases

Design your application interoperability around the clinician's journey, not around a specific Suki product. A clinician may begin documentation on one device and finish it somewhere else during the same patient encounter.

The following patterns show common ways to build interoperable ambient workflows using a shared `emr_encounter_id`.

<CardGroup cols={2}>
  <Card title="Capture on Mobile, Review on Web" icon="mobile">
    Create the ambient session from the Mobile SDK using the patient's `emr_encounter_id`. Later, open the same note in the Web SDK so the clinician can review, edit, and submit it.
  </Card>

  <Card title="Capture with APIs, Review in Web SDK" icon="code">
    Use the Ambient APIs to create the session and stream audio from your backend. Open the resulting note in the Web SDK for clinician review and submission.
  </Card>

  <Card title="Continue Documentation Across Products" icon="arrows-rotate">
    Start another ambient session for the same patient encounter from Mobile, Headless, Web, or the Ambient APIs using the same `emr_encounter_id`. Each recording contributes to the same clinical note.
  </Card>

  <Card title="Keep Your Application in Sync" icon="file-pen">
    After clinicians edit the note in the Web SDK, retrieve the latest composition through the Ambient APIs so your application always displays the current version.
  </Card>

  <Card title="Headless Capture, Headed Review" icon="paint-brush">
    Capture audio in your own React experience using the Headless Web SDK, then transition to the Web SDK when the clinician is ready to review and submit the note.
  </Card>

  <Card title="One Encounter, One Shared Note" icon="link">
    Use the same `emr_encounter_id` whenever you create or continue ambient sessions for the patient encounter so every compatible Suki product works with the same note.
  </Card>
</CardGroup>

## Design principles for interoperable Ambient workflows

Interoperable ambient sessions let multiple Suki products participate in the same clinical documentation workflow. Instead of treating each SDK as an isolated system, design your application around the patient encounter and the shared clinical note.

Keep the following principles in mind when building your integration:

* **Use the encounter as the source of truth.** Associate every ambient session for a patient visit with the same `emr_encounter_id`. This allows Suki to identify all sessions that belong to the same encounter.
* **Choose products based on workflow, not data ownership.** Mobile SDK, Headless Web SDK, Web SDK, and the Ambient APIs all provide different user experiences, but they can contribute to the same clinical note.
* **Build for handoffs between products.** Clinicians can begin recording on one device, continue from another, or review later in a different interface without creating separate notes.
* **Always retrieve the latest composition.** After additional recordings or clinician edits, use the Ambient APIs and the returned `composition_id` to retrieve the latest version of the shared note before writing back to your EHR or downstream systems.

Designing around these principles keeps every ambient product synchronized throughout the patient encounter while eliminating the need to merge notes or reconcile multiple versions yourself.

## Related topics

<CardGroup cols={2}>
  <Card title="Identifiers" icon="file-lines" href="/documentation/concepts/ambient-clinical-notes/interoperable-identifiers" cta="Learn more">
    Understand the `emr_encounter_id`, `composition_id`, `note_id`, and related identifiers used by interoperable ambient sessions.
  </Card>

  <Card title="Use Ambient Across Modalities" icon="arrows-rotate" href="/documentation/how-to/ambient-clinical-notes/use-ambient-across-modalities" cta="Learn more">
    Follow a complete workflow that creates, continues, and retrieves interoperable ambient notes.
  </Card>

  <Card title="Best Practices and FAQs" icon="circle-question" href="/documentation/how-to/ambient-clinical-notes/ambient-interoperability-faqs" cta="Learn more">
    Review implementation guidance, conflict handling, offline behavior, and frequently asked questions.
  </Card>

  <Card title="Create Ambient Session API" icon="waveform" href="/api-reference/ambient-sessions/create" cta="View API">
    See the request and response fields required for interoperable ambient sessions.
  </Card>

  <Card title="Mobile SDK Interoperability" icon="mobile" href="/mobile-sdk/ambient-guides/ambient-interoperability" cta="Learn more">
    Pass `kEmrEncounterId`, handle remote conflict and peer terminate, and read shared notes on iOS.
  </Card>
</CardGroup>
