sdp_suki_token) from the Login API, the same token used for Patient Summary generation, job status, and retrieval. Critically, Patient Summary generation depends on identifiers in your ingested FHIR data. Include consistent patient, encounter, and practitioner identifiers in the FHIR resources you upload, and use the same values as fhir_encounter_id and fhir_practitioner_id when you trigger generation and retrieve summaries.
Available endpoints
GET Request FHIR Bundle Upload URL
Purpose: Request a pre-signed upload URL for a FHIR bundle ingestion job
PUT Upload FHIR Bundle
Purpose: Upload FHIR bundle JSON to the pre-signed URL returned from the
Request FHIR Bundle Upload URL endpointGET Check Ingestion Status
Purpose: Poll ingestion status for a FHIR push transaction until CKG processing completes
Related guides
Integrate CKG
Learn why CKG is required and how to upload and monitor FHIR ingestion
Patient Summary Basic Usage
Learn the upload, generate, poll, and retrieve Patient Summary flow
Patient Summary Overview
Learn when Patient Summary fits your clinical workflow
Common use cases
Load clinical data before summary generation
Upload Patient, Encounter, Practitioner, and related FHIR resources so CKG has the chart context required to generate Patient Summaries.
Refresh chart data on a schedule
Push updated FHIR bundles when medications, problems, or visit history change so summaries reflect current clinical information.
Ingest provider schedules for bulk generation
Upload schedule and appointment FHIR data so you can trigger summary generation for all of a provider’s appointments on a given date.
Track ingestion jobs until CKG processing finishes
Poll transaction status after upload so your backend knows when data is ready for summary generation or when an upload failed or expired.