Skip to main content
Quick summary
Patient Summary generates a concise overview of a patient’s clinical history before an upcoming appointment. It uses clinical data that you previously ingest into the Clinical Knowledge Graph (CKG), generates the summary asynchronously, and makes the completed summary available through the Patient Summary APIs.
Patient Summary is supported by: Patient Summary APIs
Patient Summary generates a concise overview of a patient’s clinical history before an upcoming appointment. It uses clinical data that you previously ingest into the Clinical Knowledge Graph (CKG), generates the summary asynchronously, and makes the completed summary available through the Patient Summary APIs. At a high level, your application:
  • Ingests patient FHIR data into CKG.
  • Starts summary generation.
  • Waits for the generation job to complete.
  • Retrieves the completed summary.
  • Displays the summary in your application.

​
High-level architecture

Patient Summary is a shared workflow between your application and the Suki. Your application provides the clinical data and requests summary generation. Suki processes the request, generates the summary, and makes it available for retrieval.

​
Patient Summary lifecycle

The Patient Summary lifecycle is as follows:
1

Ingest Clinical Data

Before you can generate a summary, ingest the patient’s FHIR data into the Clinical Knowledge Graph (CKG).Patient Summary uses only the data available in CKG. If the ingested data is incomplete, outdated, or missing, the generated summary reflects that data.
2

Generate a Summary

After ingestion completes, start summary generation.You can generate summaries for:
  • A provider’s scheduled appointments.
  • A single patient encounter.
Generation starts an asynchronous background job and immediately returns a job identifier. It does not return the completed summary.
3

Wait for Completion

Summary generation runs asynchronously. Your application should periodically check the job status until it reaches a terminal state such as Completed, Failed, or Aborted.Retrieve the summary only after generation completes successfully.
Begin creating patient summaries when the provider logs into the app or opens the app. If a patient summary already exists for a given appointment, do not create a new one.

​
Summary generation workflow

Patient Summary generation follows the same workflow regardless of whether you generate summaries for an entire provider schedule or a single encounter.
For workflow details, refer to Generate patient summaries. For display and empty-state behavior, refer to Retrieve patient summaries.

​
Data flow

Patient Summary relies entirely on data previously ingested into CKG.
Use consistent patient, practitioner, and encounter identifiers throughout ingestion, generation, and retrieval so requests map to the correct clinical data.

​
Summary structure

A completed Patient Summary typically contains the following sections:
The sections returned and its quality depend on the clinical data available in CKG and your implementation decisions.

​
Recommendations to design your integration

Keep the following in mind when designing your integration:
  • Complete CKG ingestion before generating summaries.
  • Generate summaries asynchronously and poll for completion.
  • Retrieve summaries only after the job completes successfully.
  • Handle cases where patient history or upcoming appointments are unavailable.
  • The quality of generated summaries depends on the quality and completeness of the data ingested into CKG.
  • Asynchronous jobs can fail or abort. Your application must handle retries and fallbacks with appropriate error handling and logging.
  • All generated summaries are in English language. If you need a summary in a different language, you must translate it appropriately.

​
Limitations

  • Summaries depend on CKG data. Incomplete or stale ingestion reduces useful content and quality.
  • Patient Summary is intended for patients with scheduled appointments on a provider’s schedule.
  • Generation does not replace chart review. Providers remain responsible for clinical decisions.
  • Summary content, lookback period, and length depend on your implementation and configured requirements.

​
Next steps

Continue with the following guides:
Last modified on August 7, 2026