Skip to main content
Quick summary
Before generating Patient Summaries, ingest patient FHIR data into the Clinical Knowledge Graph (CKG). Patient Summary uses only the data available in CKG. Wait for ingestion to complete before triggering summary generation.
Summaries for patients are generated from clinical data stored in the Clinical Knowledge Graph (CKG). Before you generate or retrieve summaries, upload the required data into CKG and confirm that ingestion has completed. A typical integration follows this workflow:
  • Collect FHIR data from your EMR or interoperability layer.
  • Upload the data to CKG.
  • Monitor ingestion until processing completes.
  • Generate Patient Summaries.

Why CKG is required

Patient Summary generates summaries only from data stored in CKG. It does not retrieve clinical data directly from your EMR during summary generation. Using CKG enables Suki to:
  • Generate summaries from a consistent clinical dataset.
  • Use the same patient, practitioner, and encounter identifiers throughout the workflow.
  • Process summary generation independently of your EMR.
  • Generate structured summary sections such as Summary, Previous visits, and Problems.
If the ingested data is incomplete, outdated, or uses inconsistent identifiers, the generated summary quality is impacted.

What data to ingest

Before ingesting data, review the following FHIR resources and determine which ones are required to generate summaries. Upload FHIR R4 bundles that contain the clinical data required to generate summaries.

FHIR bundle requirements

During CKG data ingestion, your FHIR bundle must meet the following requirements before you upload it:

Required identifiers

Keep patient, practitioner, and encounter identifiers consistent between the FHIR data you ingest into CKG and the generation or retrieval requests you send later. When you generate or retrieve a summary by partner identifiers, use:
  • fhir_encounter_id - Encounter identifier. Must match the identifier in the ingested FHIR data.
  • fhir_practitioner_id - Practitioner identifier. Must match the identifier in the ingested FHIR data.
Refer to the following endpoints to learn more:

Ingestion workflow

The following diagram shows the ingestion workflow. The workflow consists of four steps:
1

Collect FHIR Data

Collect FHIR data for the patients and appointments you plan to generate summaries for.
2

Upload the FHIR Bundle

Request an upload URL and upload the FHIR bundle.Refer to Request upload URL and Upload FHIR bundle APIs.
3

Monitor Ingestion

Monitor ingestion until processing completes. Refer to Check ingestion status API.
4

Generate Patient Summaries

After ingestion completes, generate Patient Summaries.
Uploading a FHIR bundle only stores the data. Wait for ingestion to complete before generating summaries.

Monitor ingestion

Monitor ingestion using the transaction_id returned when requesting the upload URL API. Continue polling until the transaction reaches a terminal status. Refer to Check ingestion status API for implementation details. Monitoring lets you confirm that:
  • The data is ready for summary generation.
  • Processing completed successfully.
  • Uploads can be traced using the organization_id, transaction_id, and correlation_id.

Status values

Use the status field to decide what your application should do next.
COMPLETED, FAILED, and ARCHIVED are terminal statuses. Stop polling when you receive one of them.
Keep the following in mind:
  • Poll about every 5 seconds.
  • Ingestion status is available for 7 days after the last status update.
  • Start summary generation only after status is COMPLETED.

Common issues

Cause: Upload started after the URL expired.Resolution: Request a new upload URL.
Cause: Summary generation started before ingestion completed.Resolution: Wait for ingestion to complete before generating summaries.
Cause: Required clinical history was not ingested.Resolution: Upload the missing FHIR resources and generate the summary again.
Cause: Identifiers differ between ingestion and generation.Resolution: Keep identifiers consistent across the workflow.
Cause: Provider schedule was not ingested.Resolution: Upload schedule data before generating summaries.

Best practices

For optimal summary generation, follow these best practices:
  • Ingest clinical data before generating Patient Summaries.
  • Wait for ingestion to complete before starting summary generation.
  • Keep patient, practitioner, and encounter identifiers consistent across ingestion, generation, and retrieval.
  • Upload updated clinical data whenever patient history changes.
  • Log organization_id, transaction_id, and correlation_id for troubleshooting.

Next steps

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