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

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.

With an Ongoing Ambient Session

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.

Learn more

From a Completed Note You Already Have

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.

Learn more

​

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

Patient type, visit time, and any diagnoses you already have follow the same rules on both paths. Provide existing diagnoses explains which diagnosis types to send.

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.

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.

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

​

Next steps

Add E/M codes to an ambient visit - Enable coding on an ambient session and retrieve the recommendations.

Generate E/M codes from a note - Submit a completed note through the standalone APIs.

What E/M Coding is - Visit codes and what Suki returns for review.