> ## 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. # Interoperable Identifiers > Understand EMR Encounter ID, Encounter ID, Composition ID, and naming conventions for Ambient interoperability
Ambient interoperability uses the `emr_encounter_id` to make a note interoperable. Use **`encounter_id`** to group re-ambient sessions for the same note. Use **`composition_id`** as **`note_id`** to retrieve note content, context, and structured data.
Suki uses a small set of identifiers to associate multiple ambient sessions with the same clinical note. If a clinician starts an ambient session on one Suki product and later continues or re-ambients it on another, your application must pass the correct identifiers so that every ambient session is linked to the same patient encounter and clinical note. Provide `emr_encounter_id` when calling the [Create ambient session](/api-reference/ambient-sessions/create) API for an interoperable session. Provide `encounter_id` when sessions **must** re-ambient the same note. Store and use **`emr_encounter_id`**, **`encounter_id`**, **`composition_id`** / **`note_id`**, and **`ambient_session_id`** for interoperable re-ambient workflows. ### Identifiers you provide * **`emr_encounter_id`**: **Required** for interoperability. Your EMR or EHR encounter identifier for the patient visit. One EMR encounter can contain multiple clinical notes. * **`encounter_id`**: **Provided** to group ambient sessions for one note. Reuse the same value for every re-ambient session on that note. ### Identifiers returned by Suki * **`ambient_session_id`**: Uniquely identifies an individual ambient recording session. * **`composition_id`**: Uniquely identifies the shared clinical note created for the patient encounter. Use this value as the **`note_id`** when calling note-level Ambient APIs to retrieve or manage the note. ## Identifier hierarchy Use this hierarchy when you design interoperable ambient workflows: 1. **`emr_encounter_id`**: the patient visit. One visit can contain multiple notes. 2. **`composition_id` / `note_id`**: the clinical note for that visit. 3. **`encounter_id`**: the value that groups re-ambient sessions for one note. Reuse it for every re-ambient session on that note. 4. **`ambient_session_id`**: each recording session that contributes to that note. ```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 TD E[EMR Encounter ID
emr_encounter_id
one patient visit] --> N1[Clinical note 1
composition_id / note_id] E --> N2[Clinical note 2
composition_id / note_id] N1 -.-> SG1[encounter_id
for re-ambient] N1 --> S1[Ambient session 1
ambient_session_id] N1 --> S2[Ambient session 2
ambient_session_id] style E fill:#FFF394,stroke:#FFE148,stroke-width:2px,color:#111827 style SG1 fill:#FFFADE,stroke:#FFE148,stroke-width:2px,color:#111827 style N1 fill:#FFF394,stroke:#FFE148,stroke-width:2px,color:#111827 style N2 fill:#FFF394,stroke:#FFE148,stroke-width:2px,color:#111827 style S1 fill:#FFF394,stroke:#FFE148,stroke-width:2px,color:#111827 style S2 fill:#FFF394,stroke:#FFE148,stroke-width:2px,color:#111827 ``` | Identifier | Purpose | Where it's used | | -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | **EMR Encounter ID** | Identifies the patient encounter in your EMR or EHR. One EMR encounter can contain multiple notes. | Provide it as **`emr_encounter_id`** when calling [Create ambient session](/api-reference/ambient-sessions/create). | | **Composition ID**
(Note ID for Ambient APIs) | Identifies the shared clinical note. | Returned as **`composition_id`**. Pass it as **`note_id`** when calling note-level Ambient APIs. | | **`encounter_id`** | Groups re-ambient sessions for one note. | Provide it on the first session, then reuse the same value for every re-ambient session on that note. | | **ambient session ID** | Identifies a single ambient recording session. Each recording has its own unique session ID, even when multiple sessions belong to the same clinical note. | Returned as **`ambient_session_id`**. Use it with session-level APIs for streaming, status, context, and session content. | ## EMR Encounter ID **`emr_encounter_id`** is required to make a note interoperable across Ambient APIs, Mobile SDK, Headless Web SDK, and Web SDK. It identifies the patient visit, but it does not identify a single note because one EMR encounter can contain multiple notes. Use it when: * You want Mobile SDK and Web SDK to work on the same visit note. * You want Ambient APIs and an SDK to share the same note. * You want to list all notes for that EMR encounter later. **You must remember these rules:** * Always pass a valid **UUID** for **`emr_encounter_id`**. * Without **`emr_encounter_id`**, the ambient session is created, but the note is **not interoperable** across Suki products. * In the Web SDK, the encounter identifier you supply maps to this same **EMR Encounter ID** value. * In the Mobile SDK, pass **`SukiAmbientConstant.kEmrEncounterId`**. Refer to [Mobile SDK interoperability](/mobile-sdk/ambient-guides/ambient-interoperability) for more details. ## Encounter ID When you create an ambient session, pass **`encounter_id`** to group ambient sessions for one note when you re-ambient. Use **`encounter_id`** to: * Pass a grouping value on the first session. * Reuse that same value on later re-ambient sessions for the same note. **You must remember these rules:** * **`encounter_id`** can be up to **255** characters. * [Create ambient session](/api-reference/ambient-sessions/create) does **not** return a separate **`encounter_id`** field. * Store and reuse **`encounter_id`** for every re-ambient session on the note. To re-ambient across ambient products, create a new ambient session with the same **`emr_encounter_id`** and **`encounter_id`**. ## Composition ID and Note ID When you create an ambient session, Suki returns **`composition_id`**. Use that value as **`note_id`** with the note-level Ambient APIs: * [Note Content](/api-reference/ambient-content/note-content) to retrieve the note content. * [Note Context](/api-reference/ambient-content/note-context) to retrieve the note context. * [Note Structured Data](/api-reference/ambient-content/note-structured-data) to retrieve the note structured data. ## Best practices and naming conventions The Ambient APIs, Mobile SDK, and Web SDK support the same interoperability workflow, but they use different names for some identifiers. When your application uses more than one product, map these identifiers correctly. Using the wrong identifier can create a new clinical note instead of continuing an existing one. ### Identifier mapping for all Ambient products Refer to the following table for the identifier mapping for all ambient products: | Concept | Ambient APIs | Mobile SDK | Web SDK | | -------------------------------------- | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------- | | Patient encounter in your EMR or EHR | `emr_encounter_id` | `SukiAmbientConstant.kEmrEncounterId` (`"emrEncounterId"`) | `encounter.identifier` | | `encounter_id` for re-ambient grouping | `encounter_id` | `SukiAmbientConstant.kSessionId` (`"sessionId"`). Pass the same value as `encounterId` for `encounterContent` when you use that API. Create response `sessionId` is the ambient session ID, not `encounter_id`. | Not a Web SDK encounter field | | Shared clinical note | `composition_id` (used as `note_id` in note APIs) | Returned as `compositionId` in the create session response (online). Note APIs accept `noteId`. | `noteId` | | Individual ambient recording session | `ambient_session_id` | Returned as `sessionId` in the create session response; conflict responses return `blockingSessionId` | — | ### Understand the two encounter identifiers The names `emr_encounter_id` and `encounter_id` represent different concepts. | Identifier | Purpose | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | `emr_encounter_id` | Identifies the patient encounter in your EMR or EHR. One encounter can contain multiple notes. In the Web SDK, this is referred to as the **Encounter ID**. | | `encounter_id` | Ambient API field used to group re-ambient sessions for one note. | Do **not** use these values interchangeably. Although their names are similar, they serve different purposes. Using the wrong identifier prevents ambient sessions from being associated with the same clinical note. For every interoperable ambient workflow, store the identifiers your integration uses: | Identifier | Why you should store it | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------- | | **`emr_encounter_id`** | Create additional ambient sessions for the same patient encounter. | | **`ambient_session_id`** | Identify and manage an individual ambient recording session. | | **`composition_id`** | Retrieve and manage the shared clinical note using note-level Ambient APIs. | | **`encounter_id`** | Create ambient session does not return it, so store the value you provide and reuse it for every re-ambient session on that note. | Store **`emr_encounter_id`**, **`encounter_id`**, and **`composition_id`**. ## Next steps Refer to [How to use interoperability across Suki products](/documentation/how-to/ambient-clinical-notes/use-ambient-across-modalities) to create, continue, and retrieve interoperable ambient notes. Refer to [Best practices and FAQs](/documentation/how-to/ambient-clinical-notes/ambient-interoperability-faqs) for implementation guidance, conflict handling, and common questions. Refer to [Create ambient session](/api-reference/ambient-sessions/create) for the request and response fields used by interoperable ambient sessions. Refer to [Ambient interoperability](/documentation/concepts/ambient-clinical-notes/ambient-interoperability) for an overview of how ambient products share the same clinical note.