Interoperable Identifiers

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 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.

​

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.

​

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.

​

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 to retrieve the note content.
• Note Context to retrieve the note context.
• 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:

​

Understand the two encounter identifiers

The names emr_encounter_id and encounter_id represent different concepts. For every interoperable ambient workflow, store the identifiers your integration uses:

​

Next steps

Refer to How to use interoperability across Suki products to create, continue, and retrieve interoperable ambient notes. Refer to Best practices and FAQs for implementation guidance, conflict handling, and common questions. Refer to Create ambient session for the request and response fields used by interoperable ambient sessions. Refer to Ambient interoperability for an overview of how ambient products share the same clinical note.