> ## 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.
# June 2026
> June 2026 release notes for Suki APIs and SDKs
This release adds **Medication orders** to the headed **Web SDK**. During ambient sessions, clinicians can review recommended medications in the built-in note UI, and your application receives structured order data on note submit. The **Ambient API** now returns **HCC codes** alongside ICD10, IMO, and SNOMED in structured data output for suggested diagnoses. For the **Ambient API**, **Dictation API**, and **Form filling API**, you now have the option to authenticate providers with a **Single Auth Token** shared across all clinicians. When you choose this option, you must send `sdp_provider_id` on every REST and WebSocket request so Suki can route each call to the correct provider.
## What's enhanced
### Enhancements
Web SDK
**Medication orders**: The Suki Web SDK now supports **Medication orders generation during ambient sessions**. During a visit, the SDK identifies recommended medications from the clinician's conversation and displays them in the built-in **Medication orders** section for review. When the provider submits the note, the SDK returns structured order data in the note submission payload.
To enable this capability, pass the LOINC code `52471-0` in the `ambientOptions.sections` array when you mount the Web SDK or set ambient options.
* Medication orders are supported on **v2** and **v3** versions of the Web SDK.
* Combine `52471-0` with your other note sections and a PBC section when you need to link orders to problems in the same session.
* On note submit, parse `orders.medication_orders` from the payload and send validated orders to your EHR.
**Implementation**
```js JavaScript theme={"theme":{"light":"github-dark","dark":"material-theme-darker"}}
sdkClient.mount({
rootElement: document.getElementById("suki-root"),
encounter: encounter,
ambientOptions: {
sections: [
{ loinc: "52471-0" }, // Medication Orders LOINC code
],
},
});
```
**Why it matters**: Clinicians can review and complete medication orders inside the headed Web SDK without leaving the ambient workflow. Your application receives structured JSON on note submission so you can validate and persist orders to the EHR the same way you handle note `contents`.
Learn more in the [Medication orders overview](/web-sdk/medication-orders/overview), [Medication orders payload structure](/web-sdk/medication-orders/payload-structure), and [Web SDK changelog](/web-sdk/product-updates/changelog).
***
API v1.5.0
**HCC codes**: The **Structured data API** and **Encounter structured data API** now return [HCC codes](https://www.aapc.com/resources/what-is-hierarchical-condition-category?srsltid=AfmBOopcl-dIWrRrQFq58LGS72p58BakTdoWdEHv0P9z89c3XBXuJAOY) alongside ICD10, IMO, and SNOMED for each suggested diagnosis in ambient structured data output.
* HCC values are derived from the ICD-10-CM code using the [CMS-HCC V28 model](https://www.raapidinc.com/blogs/cms-hcc-model-v28).
* Each HCC entry uses `type: "HCC"` in the diagnosis `codes` array. The `description` uses the format `CMS-HCC model category ` (for example, `CMS-HCC model category 65`).
* If an ICD-10-CM diagnosis does not map to an HCC model category, Suki looks for general HCC codes that match the diagnosis description. If no match is found, the diagnosis is returned without an HCC code.
HCC codes are returned in structured data output only. Do not send HCC codes in session context.
**Example**
```json JSON theme={"theme":{"light":"github-dark","dark":"material-theme-darker"}}
{
"structured_data": {
"diagnoses": {
"values": [
{
"codes": [
{
"code": "A00.0",
"description": "Acute myocardial infarction",
"type": "ICD10"
},
{
"code": "65",
"description": "CMS-HCC model category 65",
"type": "HCC" // HCC code in the format `CMS-HCC model category `
}
]
}
]
}
}
}
```
**Why it matters**: You can validate suggested diagnoses against EMR context and pass HCC categories into downstream risk-adjustment or quality workflows without a separate mapping step.
Learn more in the [Structured data API](/api-reference/ambient-content/structured-data), [Encounter structured data API](/api-reference/ambient-content/encounter-structured-data), and [Problem-Based Charting](/api-reference/capabilities/problem-based-charting).
API v1.4.0 | Form Filling API v1.1.0
**Single Auth Token authentication**: You now have the option to authenticate providers in your application using a single authentication token for all clinicians. When you choose this option, your backend uses one shared `partner_token` instead of a per-user token. The shared token proves your organization is authorized, but it does not identify who is signed in. You **must** send `sdp_provider_id` on every REST API and WebSocket API call so Suki can route each request to the correct clinician.
This applies to **Ambient, Dictation, and Form filling API** requests. Send `sdp_provider_id` on Register and Login, and include it on every subsequent request along with `sdp_suki_token`.
```json JSON theme={"theme":{"light":"github-dark","dark":"material-theme-darker"}}
{
"sdp_suki_token": "your-suki-token", // sdp_suki_token required for all API calls
// Required with Single Auth Token auth: send sdp_provider_id on Register, Login, and every API call
"sdp_provider_id": "doc1234567890"
}
```
**Why it matters**: You can support multiple clinicians with one organization token without a separate IdP token per user, while Suki still knows which provider each request is for.
Learn more in the [Provider authentication](/api-reference/provider-authentication#authentication-with-a-single-auth-token) guide.