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

# Choose Ambient or Standalone

> Choose how to request E/M codes based on where the clinical note comes from: an ambient session or a standalone API request

Quick summary

Pick the E/M Coding request path that matches where the note comes from. If Suki writes the note during the ambient session, enable E/M Coding when you create the session, and if your application already has the finished note, submit that note with the standalone API, using only one path for each visit.

Last updated:
November 2026

These definitions describe the terminology used on this page.

| Term | Meaning |
| :- | :- |
| With Ambient | Generates E/M code recommendations using the note from an existing ambient session. |
| Standalone | Generates E/M code recommendations by submitting an existing clinical note through the E/M Coding APIs, without an ambient session. |

E/M Coding recommends an E/M code from a completed clinical note. If Suki writes that note during the visit, use the Ambient APIs and enable E/M Coding on the session. If the finished note is already in your application or EHR, use the standalone E/M Coding APIs to request the E/M code.

> [card] [With an Ongoing Ambient Session](https://developer.suki.ai/documentation/how-to/em-coding/generate-with-ambient.md)
>
> Your application already records the visit, and Suki writes the note using the Ambient APIs. Enable E/M Coding on that session, then read the recommended code with the note.

> [card] [From a Completed Note You Already Have](https://developer.suki.ai/documentation/how-to/em-coding/generate-standalone.md)
>
> The finished note is already in your application or EHR. Submit that note with the standalone E/M Coding APIs, save the coding `session_id`, and read the recommended code after coding finishes.

## How the two paths differ

Suki recommends Evaluation and Management (E/M) codes from a completed clinical note and the visit details you provide. The recommendation reflects the services documented in the note. Suki does not recommend a code for a service the note does not record. On the standalone path, Suki does not create or complete the note.

The table below shows how the two paths differ, so you can choose the one that matches how your application already documents the visit.

| What changes | Ambient | Standalone |
| :- | :- | :- |
| When to use it | Suki writes the note from this visit, and your application already uses Ambient APIs for the recording. | The finished note is already in your application or EHR, and this visit is not recorded with Ambient. |
| How you request the code | Enable E/M Coding when you [Create an ambient session](https://developer.suki.ai/api-reference/ambient-sessions/create.md) by setting `artifacts: ["EM_CODES"]`. Send the patient, provider, and visit details before the recording ends. | Submit the completed note with `POST /api/v1/em-codes` after the note is complete. This call does not create or change the note. |
| Who supplies the note | You do not send the note sections. Suki writes them from the visit, including each section's LOINC code and text. | You send the sections on that call. At least one section needs a [LOINC](https://developer.suki.ai/documentation/concepts/ambient-clinical-notes/note-sections.md) code in `loinc` and text in `content.text`. |
| How you read the code | There is no separate coding `session_id`. Read the codes with the `ambient_session_id`, `note_id`, or `encounter_id` you already store for the visit. | Save the coding `session_id` from the generate response. Use that session ID to check when coding is done and to read the codes. |

> [!NOTE]
>
> Patient type, visit time, and any diagnoses you already have follow the same rules on both paths. [Provide existing diagnoses](https://developer.suki.ai/documentation/concepts/em-coding/overview.md#provide-existing-diagnoses) explains which diagnosis types to send.

> [!WARNING]
>
> Use one path for each visit. If you enable E/M Coding on an ambient session and also submit that same note with the standalone E/M Coding APIs, Suki can return two recommendations. Your reviewers then have to decide which result to keep.

## Decide where to show the E/M code based on the path you choose

The way you retrieve and display E/M codes depends on how you integrate E/M Coding. With the Ambient APIs, Suki generates the note during the visit and returns the recommended codes with the session. You can retrieve the codes using the ambient session ID, note ID or encounter ID.

With the standalone E/M Coding APIs, your application already has the clinical note. Store the coding `session_id` returned by the generate request and use it to retrieve the recommended codes once processing is complete. You can then display the recommendations alongside the note in your application's review workflow.

> [accordion] When you use Ambient APIs to generate the note
>
> The clinician is already reviewing the note generated from the recorded visit. Show the E/M Coding recommendation alongside that note so the clinician can review both in the same place.
>
> * **Enable E/M Coding when creating the session.** Include the patient, provider, and visit details before the recording ends. Details submitted after the session ends are too late to be used for that visit.
> * **Use the identifiers you already have.** Keep the `ambient_session_id`, `note_id`, and `encounter_id` associated with the visit. Ambient E/M Coding does not create a separate coding session.
> * **Show the note as soon as the session completes.** Add the E/M Coding recommendation to the same screen when it becomes available. Do not delay showing the note while waiting for the recommendation.
> * **Handle visits without a recommendation.** If Suki does not return an E/M code, tell the reviewer that no code was recommended. Keep the note available because the absence of an E/M code does not mean note generation failed.

> [accordion] When you use the standalone E/M Coding APIs
>
> Your application or EHR already stores the completed clinical note. The standalone E/M Coding APIs analyze that note and return a recommendation for the same encounter. The recommendation supplements the existing note; it does not replace it.
>
> * **Submit the completed note.** Send the note sections after the note is complete.
> * **Store the coding session ID.** Save the returned `session_id` against the encounter. The generate response does not contain the recommended code, so your application must wait for coding to finish before displaying the result.
> * **Show the coding status.** While Suki processes the note, display a clear message such as "Recommendation in progress." When coding completes, replace the message with the recommendation.
> * **Handle coding failures separately.** If the coding session fails, tell the reviewer that coding did not finish. Keep the original note unchanged.
> * **Retrieve the recommendation within 30 days.** The coding result is available for 30 days. After that, the session no longer returns the recommended code.

## Design the review screen

Use the same review experience for both integration paths. Place the E/M Coding recommendation alongside the clinical note so the reviewer can assess the recommendation without opening a separate screen.

### Show the recommended code and its supporting details

Display the recommended code prominently, such as **99214**, along with the patient type (new or established) and the visit level. Show the reason for the recommendation directly below the code so the reviewer can understand why Suki suggested it.

The supporting details depend on the basis for the recommendation:

* **Medical decision making:** Show the supporting medical decision-making rationale.
* **Time:** Show the time details used for the recommendation.
* **Preventive or wellness visit:** Show the supporting wellness or preventive visit details.

Each recommendation follows one of these paths. Do not display modifiers or add-on codes unless Suki includes them in the response. See [What to present for review](https://developer.suki.ai/documentation/concepts/em-coding/what-is-em-coding.md#what-to-present-for-review-in-your-application’s-ui) for details.

### Let the reviewer decide what goes to billing

Clearly label the result as a recommended E/M code, not an approved billing code. Give the reviewer the option to accept the recommendation or select a different code. Your application should send the code to your existing billing workflow only after the reviewer makes that decision.

### Handle the two workflows differently while coding is in progress

With Ambient, the clinical note can appear as soon as the session completes. Show the recommendation on the same screen when it becomes available.

With existing notes that used the standalone E/M Coding APIs, the note already exists, but the recommendation is not available immediately. Show a clear "Recommendation in progress" message while Suki processes the note and recommends the code, then replace it with the recommendation when coding completes.

Handle the error gracefully by telling the reviewer that coding did not finish and leaving the note unchanged.
Learn more about the Error Codes in the [E/M Coding API Reference](https://developer.suki.ai/em-coding-api-reference/error-messages-em-coding.md).

## Next steps

 **[Add E/M codes to an ambient visit](https://developer.suki.ai/documentation/how-to/em-coding/generate-with-ambient.md)** - Enable coding on an ambient session and retrieve the recommendations.

 **[Generate E/M codes from a note](https://developer.suki.ai/documentation/how-to/em-coding/generate-standalone.md)** - Submit a completed note through the standalone APIs.

 **[What E/M Coding is](https://developer.suki.ai/documentation/concepts/em-coding/what-is-em-coding.md)** - Visit codes and what Suki returns for review.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.