Skip to main content
Suki for Partners provides Patient Summary APIs for generating concise pre-visit summaries from FHIR data ingested into the Clinical Knowledge Graph (CKG). Patient Summary is an API-first integration. Your application owns the clinician UI, when generation runs, and how completed summaries are displayed. This guide explains how Patient Summary fits into your product and helps you select the integration approach that best matches your application architecture, clinic-day workflow, and user experience goals. Use this guide to understand what you build with the Patient Summary APIs, including CKG ingestion, asynchronous generation, status polling, and summary retrieval. For Ambient clinical documentation and Dictation workflows, refer to the Ambient & Dictation integration decision guide. For Form filling workflows, refer to the Form filling integration decision guide.

​
Integration optionss

​
Patient Summary APIs

Patient Summary APIs are the supported integration path. You build your own user interface and authentication flow, then call Suki REST endpoints from your backend to ingest FHIR data, generate summaries, monitor jobs, and retrieve completed content.

Recommended For:

  • Backend systems and server integrations.
  • Custom schedule, chart, and patient-profile UIs.
  • Multi-platform applications that share one API surface.

What You Build:

  • Complete user interface for schedule and chart review.
  • Authentication and token handling on your backend.
  • CKG ingestion, generation triggers, polling, and retrieval.
Patient Summary does not currently ship a client SDK or hosted clinician UI. Integrate through the Patient Summary APIs and render summary sections in your own application.

​
Designing Patient Summary into your clinical UX

Patient Summary is pre-visit preparation. It is not Ambient note generation during an encounter, and it is not Dictation. Use it when clinicians need concise prior-visit context before an upcoming appointment.

​
Where will clinicians see the summary

​
When should your application generate summaries

​
What your application owns in the workflow

Generate summaries from your backend before the clinic day begins whenever possible. Reuse an existing summary when one is already available for the appointment, and regenerate only after meaningful CKG updates.

​
How to choose

Patient Summary uses one integration path for now: the Patient Summary APIs. The decisions that matter most are when to generate, which generation workflow to use, and what content to retrieve.
Choose Patient Summary APIs if:
  • You need pre-visit summaries in a web EHR, schedule view, or patient profile.
  • Your backend can ingest FHIR data into CKG and trigger generation.
  • You will render summary sections in your own browser UI.
Patient Summary is backend-driven. Keep Partner credentials and generation calls on your server, then return completed summary content to your web application.
For iOS Applications:
  • Choose Patient Summary APIs through your backend, then display completed summaries in the native UI.
For Android Applications:
  • Choose Patient Summary APIs through your backend with the same ingest, generate, poll, and retrieve workflow.
Choose Patient Summary APIs
  • This is the primary integration path.
  • Provides complete control over CKG ingestion, generation timing, polling, and EHR handoff.
HIPAA Compliance: Patient Summary APIs can be implemented in a HIPAA-compliant manner. Compliance depends on your implementation practices and security measures.

​
Prerequisites for Patient Summary

Before integrating Patient Summary, you must complete the partner onboarding process:

​
Required for Patient Summary

Partner Registration:
  • Complete the Partner onboarding process.
  • Receive your unique partner_id from Suki.
  • Provide your JWKS endpoint URL to Suki for token validation.
Authentication System:
  • OAuth 2.0 compliant authentication system.
  • JWT token generation with consistent user identifier.
  • Publicly accessible JWKS endpoint for token verification.
  • Ability to obtain sdp_suki_token for Patient Summary generation, status, and retrieval calls.
  • Ability to generate and sign the SDP JWT required for CKG Data Ingestion.
Clinical data:
  • FHIR R4 patient, encounter, practitioner, schedule, and history data for the appointments you want to summarize.
  • Stable identifiers such as fhir_encounter_id and fhir_practitioner_id.

​
Additional requirements

Patient Summary APIs:
  • HTTPS/TLS support for secure API communication.
  • Backend capability to upload FHIR bundles to CKG and poll ingestion status.
  • Backend capability to trigger generation, poll summary job status, and retrieve completed summaries.
  • UI design for preparing states, empty appointments, and limited prior history.

​
Integration scenarios

Scenario: Existing web-based EHR that needs short pre-visit context on the provider schedule before clinic starts.Recommended: Patient Summary APIs
  • Ingest provider schedule and patient FHIR data into CKG.
  • Use scheduled generation before the clinic day begins.
  • Retrieve pre-visit sections for appointment cards.
  • Open the full summary when the clinician selects a patient.
Scenario: Clinician opens a patient profile before an upcoming appointment and needs a concise clinical overview.Recommended: Patient Summary APIs
  • Confirm an upcoming appointment exists.
  • Generate a single encounter summary if one is not already available.
  • Retrieve the full Patient Summary for chart review.
  • Render About this visit, Summary, Previous visits, and Problems in your UI.
Scenario: Web clinician workflow where Patient Summary must match your design system, layout, and interaction patterns.Recommended: Patient Summary APIs
  • Full control over schedule previews, chart layout, and empty states.
  • Your backend owns ingestion, generation, and retrieval.
  • Your frontend owns presentation and clinician navigation.

​
Next steps

To begin your integration, review the documentation for your chosen approach: Patient Summary overview - What Patient Summary is, what it includes, and where to start. Integrate CKG - Ingest FHIR data into the Clinical Knowledge Graph before generation. Generate patient summaries - Choose scheduled or single-encounter generation. Retrieve patient summaries - Load full and pre-visit summaries into your application. Patient Summary basic usage - End-to-end Partner API workflow. Patient Summary API overview - Build custom Patient Summary integrations with the Partner APIs. Patient Summary API quickstart - Get started with authentication and core API calls. Partner onboarding - Start your integration journey with Suki.

​
Get personalized integration guidance

If your use case doesn’t clearly match the scenarios above, or you need specific technical advice for your healthcare application, our customer success team provides personalized consultation. Before contacting support or sales, prepare:
  • Description of your healthcare application and pre-visit workflows.
  • Target platform (web, iOS, Android, backend system).
  • Where clinicians will see summaries (schedule, chart, appointment details).
  • Whether you need morning scheduled generation, on-demand encounter generation, or both.
  • Development timeline and resource constraints.
  • Specific technical requirements or compliance needs.
Contact options:
Last modified on August 7, 2026