Quick summary
Call create when the clinician starts Ambient. Store ambient\_session\_id for this recording and note\_id from the response. Pass emr\_encounter\_id for cross-modality notes. For re-ambient, reuse encounter\_id when you sent it, or use the returned note\_id. Do not send patient, sections, or note style on create.
Last updated:
September 2026
Ambient sessions are recordings of patient-provider conversations that produce a clinical note. Clinicians use ambient sessions to automatically document patient history, physical exams, and clinical observations. Use the [Create ambient session API](/api-reference/ambient-sessions/create) to start an ambient session recording for a patient visit.
Call this API when the clinician chooses **Start Ambient** in your application. Suki creates the ambient session and returns the identifiers you need for the rest of the workflow:
* `ambient_session_id` identifies the recording session.
* `note_id` identifies the note linked to that session. Use it with note-level Ambient APIs.
Your application should keep these identifiers with the current visit so it can use them when it streams audio, ends the session, checks processing status, and retrieves the note. Pass **`emr_encounter_id`** when the note must work across modalities. For re-ambient, reuse **`encounter_id`** when you sent it. If the first create omitted **`encounter_id`**, pass the returned **`note_id`** as the **`encounter_id`** field value. For Mobile SDK and Web SDK field names, see [Interoperable identifiers](/documentation/concepts/ambient-clinical-notes/interoperable-identifiers#field-mapping).
### Multiple notes on the same EHR visit
An EHR visit can have **multiple clinical notes**. In this case, each note has its own `note_id`, while the notes are associated with the same EHR visit through `emr_encounter_id`.
`emr_encounter_id` is the ID of the EHR visit. **Your application provides this value when you create the ambient session.** Suki does not generate it.
When you use the same `emr_encounter_id` for interoperable Ambient workflows:
* Suki associates the ambient session work with that EHR visit.
* The visit can have multiple ambient notes over time.
* Each note has its own `note_id`.
To retrieve all notes associated with an EHR visit, call [List encounter notes](/api-reference/ambient-content/list-encounter-notes) with the same `emr_encounter_id` you used when creating the session. The response returns the notes associated with that visit. Use a returned note `id` as the `note_id` for note-level APIs.
| Use case | ID to use | Result |
| :- | :- | :- |
| Record another ambient session for the **same note** | Same `encounter_id` on create when you sent it, or pass the returned `note_id` as the `encounter_id` field value if the first create omitted `encounter_id`. Keep the existing `note_id` for note-level APIs | Adds another ambient session to the same note |
| Work with the **same EHR visit** and retrieve its notes | `emr_encounter_id` | Accesses the EHR visit and its associated notes |
For how to retrieve by session, note, or EMR encounter, see [Work with shared notes](/documentation/how-to/ambient-clinical-notes/retrieve-note-and-encounter-content).
## Cross-modality workflows
Cross-modality ambient session means clinicians can work on the **same clinical note** across more than one Suki ambient session product. For example:
* Start ambient session on the Mobile SDK or Ambient APIs during the visit.
* Open the same note later in the Web SDK to review and edit.
* Retrieve the latest note text through the **Note-level APIs**.
To enable this, pass **`emr_encounter_id`** when you create the ambient session. That value is your EHR visit id (**UUID or non-UUID**, at most **36 characters**). **Your application provides it.** Suki does not generate it.