Skip to main content

​
Overview

Problem-Based Charting (PBC) is a feature that structures the clinical note around a patient’s specific problems. This ensures the generated note reflects the most up-to-date clinical context by capturing diagnoses discussed during the visit and seamlessly combining them with any existing diagnoses you provide.

​
Example Workflow

The following diagram illustrates the recommended flow for handling diagnoses, especially in reambient scenarios.

​
Core Principles

Suki’s Problem-Based Charting feature is designed to be robust and flexible, while also being easy to use. The following core principles guide how the system processes and generates diagnoses.
All diagnosis generation is done on a best-effort basis. The system is designed to be resilient, prioritizing the return of partial, useful information over failing an entire request due to an issue with a single data point.
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
  • Integration with existing clinical workflows
  • Normalization of other code types (, SNOMED)
Non-ICD10 codes are automatically converted to ICD10 equivalents when possible.
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.

​
Input Processing And Validation

​
Providing Diagnoses

You can seed existing diagnoses for a session using the following Context APIs:

​
Validation Rules

The following rules are strictly applied to the diagnosis objects in your input payload:
  • The API will reject any request where a single diagnosis object contains multiple code types (e.g., both an ICD and an IMO code).
  • The API will also reject a request if a diagnosis object contains no code at all.
  • Each diagnosis must have exactly one code.

​
Normalization And Deduplication

  • If a non-ICD10 code is provided, the system uses IMO APIs to find the best possible ICD10 code equivalent.
  • After all codes have been normalized to ICD10, any input diagnoses that share the same ICD10 code will be merged into a single object.
  • The notes from the merged diagnoses will be combined into a single note for the new, unified diagnosis object.
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.

​
Output Generation And Access

​
How Diagnoses Are Generated

The Machine Learning model may perform one of three actions on the input diagnoses:
  • Update the content of an existing diagnosis.
  • Generate an entirely new diagnosis.
  • Keep an input diagnosis untouched if it was not significantly discussed.
Only diagnoses that were updated or newly generated are returned in the final output. Untouched diagnoses are not returned.

​
Output Enrichment

  • For any diagnosis that was updated or newly generated, the system calls IMO to enrich it with an ICD code, IMO code, laterality, and a post coordination flag. No other code types will be returned.
  • If the enrichment call fails, the system will still return the diagnosis with the note and any available code to ensure you do not lose the generated information.
The IMO code returned in the output may be different from any IMO code that was sent in the input payload.

​
Accessing Diagnoses

You can access generated diagnoses through the following Structured Data APIs:
  • Session Level API - GET Structured Data API: Returns the state of the diagnoses after the specified session ID.
  • Encounter Level API - GET Encounter Structured Data API: Returns the latest state of diagnosis for an encounter. Since diagnoses are not carried forward automatically, this is equivalent to accessing the diagnosis from the most recent session.

​
Handling Reambient Scenarios

In reambient scenarios, where a single patient encounter involves multiple recording sessions, it is critical to understand how context is managed.

​
Diagnosis Consideration

Only diagnoses passed via the Context APIs for the current session are considered. Diagnoses from previous sessions are not automatically carried forward.

​
Client Responsibilities

Because sessions do not inherit context, you must provide the complete and current list of all relevant diagnoses for each new session. This includes:
  • Diagnoses that were modified by the end user.
  • Any newly added diagnoses.
  • Diagnoses from previous sessions that should be retained.

​
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.
The system normalizes all codes to ICD10 before processing.
The system deduplicates diagnoses based on the ICD10 code.

​
Next Steps

Use the following APIs to get started with Problem-Based Charting:

Context API

Learn about the Context API

Update Context API

Learn about the Update Context API

Structured Data API

Learn about the Structured Data API

Encounter Structured Data API

Learn about the Encounter Structured Data API