Skip to main content
Quick Summary
Problem-Based Charting (PBC) is a clinical documentation approach that organizes notes by patient problems instead of traditional note sections, and suggests diagnoses for each problem.
Last updated:December 2025
Problem-Based Charting (PBC) is supported for Web SDK and APIs only. The Mobile SDK and Headless Web SDK do not currently support PBC.

​
Overview

Problem-Based Charting (PBC) organizes clinical notes by patient problems instead of traditional note sections. When you use PBC, Suki generates two things:
  1. Clinical note: Organized by each problem or diagnosis
  2. Structured artifacts: Suggested diagnoses with ICD-10 and IMO codes
PBC notes are different from traditional notes. In traditional notes, information is organized by sections like “History,” “Assessment,” and “Plan.” In PBC notes, information is organized by each problem, grouping all related information together. When you enable PBC, providers get a note that has the following benefits:
  • Easier to read: See everything about each problem in one place
  • Better continuity: Includes existing problems from previous visits automatically
  • Complete picture: Captures both old and new problems discussed during the visit
  • Structured data: Generates standardized codes (ICD-10, IMO) for EHR integration

​
How To Enable Problem-Based Charting

To use PBC, follow these steps:
  1. Mark a section as PBN: Set isPBNSection: true on one section in your ambientOptions
  2. Provide diagnoses: Send existing diagnoses via the Context API when starting the session
  3. Retrieve results: Get generated diagnoses from the Structured Data API after the session
Web SDK Example:
JavaScript
sdkClient.mount({
  rootElement: document.getElementById("suki-root"),
  encounter: encounterDetails,
  ambientOptions: {
    sections: [
      { loinc: "51848-0", isPBNSection: true }, // Mark as PBN section
      { loinc: "11450-4" },
      { loinc: "29545-1" },
    ],
  },
});
API Example:
Python
# Provide diagnoses via Context API
payload = {
    "diagnoses": {
        "values": [
            {
                "codes": [
                    {
                        "code": "I10",
                        "description": "Essential hypertension",
                        "type": "ICD10"
                    }
                ],
                "diagnosis_note": "Hypertension"
            }
        ]
    }
}

​
Configuration Rules

When configuring PBC, follow these rules:
1

Single PBN Section

Only one section can have isPBNSection: true. If multiple sections are marked as PBN, the ambient session will fail to start.
2

Default Behavior

If no section includes the isPBNSection flag and the Assessment & Plan section (51847-2) is present, that section automatically becomes the PBN.
3

Explicit Override

You can explicitly set isPBNSection: false to prevent automatic PBN assignment.
For a given ambient session, only one section can have isPBNSection: true. If more than one section is marked as PBN, the ambient session will fail to start.

​
Core Principles

Understanding these principles helps you use PBC effectively:
The code is treated as the primary identifier for all clinical problems during processing.System Uses ICD10 For:
  • Diagnosis identification and matching
  • Clinical problem categorization
  • Cross-session diagnosis continuity
  • Normalization of other code types (, SNOMED)
Non-ICD10 codes are automatically converted to ICD10 equivalents when possible.
All diagnosis generation is done on a best-effort basis. The system prioritizes returning partial, useful information over failing an entire request due to an issue with a single data point.
In reambient scenarios, diagnoses from previous sessions are not automatically carried forward. You must provide the full context for each new session.
Your Responsibility: Include all relevant diagnoses (previous + new + modified) in each session context.

​
How It Works

PBC processes diagnoses in three steps:
1

Provide Existing Diagnoses

You provide existing diagnoses when starting the session using the Context APIs.
2

Suki Analyzes Conversation

Suki’s AI analyzes the conversation and identifies new problems or updates to existing diagnoses.
3

Generate Structured Output

Suki generates a clinical note organized by problem and structured artifacts with standardized codes.
Suki backend includes the ML-suggested problem name and returns standardized ICD-10 code, description, and IMO equivalent in the final output.

​
Providing Diagnoses

You provide existing patient diagnoses when starting a session using the Context APIs. These diagnoses serve as the starting point for PBC note generation. APIs to use:

POST Context API

Provide initial diagnoses when starting a session

PATCH Update Context API

Update or add diagnoses during a session
Example diagnosis format:
JSON
{
  "diagnoses": {
    "values": [
      {
        "codes": [
          {
            "code": "30422",
            "description": "Essential hypertension",
            "type": "IMO"
          }
        ],
        "diagnosis_note": "Hypertension"
      }
    ]
  }
}

​
Validation Rules

Each diagnosis in your request must follow these rules:
  • One code per diagnosis: Each diagnosis must have exactly one code (ICD10 or IMO)
  • No mixed codes: A single diagnosis cannot contain multiple code types
  • Code required: Every diagnosis must include a code

​
Input Processing

Suki processes diagnoses through normalization and deduplication: Normalization:
  • Non-ICD10 codes (IMO, SNOMED) are automatically converted to ICD10 using IMO APIs
  • ICD10 is used as the source of truth for all diagnosis processing
Deduplication:
  • Diagnoses with the same ICD10 code are merged into one diagnosis
  • Notes from merged diagnoses are combined into a single note
During normalization, the original input code will not be preserved. If a code cannot be mapped to an ICD10 equivalent, the entire diagnosis object will be skipped, and processing will continue with the rest of the input.

​
How Diagnoses Are Generated

During the session, Suki’s AI analyzes the conversation and takes one of three actions on the diagnoses you provided:
  1. Update existing diagnosis: Modify the content if it was discussed
  2. Generate new diagnosis: Create a new diagnosis if a new problem was discussed
  3. Keep unchanged: Leave a diagnosis untouched if it wasn’t significantly discussed
Only diagnoses that were updated or newly generated are returned in the final output. Untouched diagnoses are not returned, if a diagnosis wasn’t discussed, it won’t appear in the output.

​
Output Enrichment

For any diagnosis that was updated or newly generated, Suki enriches it with:
  • ICD10 code: Standard diagnosis code
  • IMO code: Intelligent Medical Objects code
  • Laterality: Left/right/bilateral information when applicable
  • Post coordination flag: Indicates if the diagnosis requires additional modifiers
The IMO code returned in the output may be different from any IMO code that was sent in the input payload. This is normal—Suki uses the most accurate code based on the conversation content.
If enrichment fails, Suki still returns the diagnosis with available information to ensure you don’t lose generated content.

​
Retrieving Generated Diagnoses

After a session completes, retrieve the structured artifacts (including suggested diagnoses with ICD-10 and IMO codes) using the Structured Data APIs:

Structured Data API

Get diagnoses for a specific session

Encounter Structured Data API

Get latest diagnoses for an encounter

​
Response Example

JSON
{
  "structured_data": {
    "diagnoses": {
      "values": [
        {
          "codes": [
            {
              "code": "30422",
              "description": "Essential hypertension",
              "type": "IMO"
            }
          ],
          "diagnosis_note": "The management of essential hypertension remains unchanged from previous plans, as it was not the focus of today's visit.",
          "laterality_indicator": 4,
          "post_coord_lex_flag": 1
        }
      ]
    }
  }
}

​
Handling Reambient Scenarios

In reambient scenarios, where a single patient encounter involves multiple recording sessions, understanding how context is managed is critical.
Sessions do not automatically inherit diagnoses from previous sessions. Each session starts fresh, you must provide all relevant diagnoses for each new session.What this means:
  • Only diagnoses passed via the Context APIs for the current session are considered
  • Diagnoses from previous sessions are not automatically carried forward
  • You must provide the complete and current list of all relevant diagnoses
Your Responsibilities: Because sessions don’t inherit context, you must provide the complete list of all relevant diagnoses for each new session. This includes:
  • Modified diagnoses: Any diagnoses that were changed by the provider in previous sessions
  • New diagnoses: Any newly added diagnoses from previous sessions
  • Existing diagnoses: Diagnoses from previous sessions that should be retained
Recommended Workflow:
After each session, retrieve the generated diagnoses using the Structured Data API, then include all relevant diagnoses (including any modifications) when starting the next session.

​
Best Practices

  • Provide complete context: Always include all relevant existing diagnoses when starting a session
  • Use ICD10 when possible: ICD10 codes are preferred and processed most reliably
  • Handle reambient carefully: Retrieve diagnoses after each session and include them in the next session
  • Validate codes: Ensure diagnosis codes are valid before sending them
  • Monitor output: Check which diagnoses were updated or generated to understand what was discussed
  • Update after user edits: If providers modify diagnoses, include those modifications in subsequent sessions

​
FAQs

In reambient scenarios, the system does not automatically carry forward diagnoses from previous sessions. You must provide the complete and current list of all relevant diagnoses for each new session.
The system uses IMO APIs to find the best possible ICD10 code equivalent for non-ICD10 codes. If a code cannot be mapped, that diagnosis is skipped.
The system normalizes all codes to ICD10 before processing. ICD10 is used as the source of truth for all diagnosis operations.
The system deduplicates diagnoses based on the ICD10 code. Diagnoses with the same ICD10 code are merged, and their notes are combined.
Only diagnoses that were updated or newly generated are returned. Diagnoses that weren’t discussed during the session are not included in the output.