> ## Documentation Index
> Fetch the complete documentation index at: https://developer.suki.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Patient Summary Architecture

> Learn how Patient Summary architecture, lifecycle, data flow, and summary generation fit together

<div className="quick-summary-wrapper">
  <div className="quick-summary-header">
    <span className="quick-summary-icon" aria-hidden="true" />

    <span className="quick-summary-title">Quick summary</span>
  </div>

  <div className="quick-summary-content">
    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.
  </div>
</div>

<Info>
  **Patient Summary is supported by:** Patient Summary APIs
</Info>

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-api-reference/overview).

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.

```mermaid actions={false} theme={"theme":{"light":"github-dark","dark":"material-theme-darker"}}
flowchart TB
  subgraph SukiPlatform["Suki platform"]
    direction LR
    D["Clinical Knowledge Graph<br/>CKG"]
    E["Patient Summary service"]
    F["Background job"]
    G["Generated summary"]
  end

  subgraph PartnerApp["Partner application"]
    direction LR
    A["Collect FHIR data"]
    B["Upload data to CKG"]
    C["Generate summary"]
    H["Poll job status"]
    I["Retrieve and display summary"]
  end

  A --> B
  B --> D
  C --> E
  D --> E
  E --> F
  F --> G
  F --> H
  H --> G
  G --> I

  style A fill:#FFF394,stroke:#333,color:#000
  style B fill:#FFF394,stroke:#333,color:#000
  style C fill:#FFF394,stroke:#333,color:#000
  style D fill:#FFF394,stroke:#333,color:#000
  style E fill:#FFF394,stroke:#333,color:#000
  style F fill:#FFF394,stroke:#333,color:#000
  style G fill:#FFF394,stroke:#333,color:#000
  style H fill:#FFF394,stroke:#333,color:#000
  style I fill:#FFF394,stroke:#333,color:#000
```

| Component                          | Responsibility                                                                                                |
| :--------------------------------- | :------------------------------------------------------------------------------------------------------------ |
| **Partner application**            | Collects FHIR data, uploads it to CKG, starts generation, polls job status, and displays completed summaries. |
| **Clinical Knowledge Graph (CKG)** | Stores the ingested clinical data used during summary generation.                                             |
| **Patient Summary service**        | Generates structured patient summaries from the data available in CKG.                                        |
| **Background job**                 | Processes summary generation asynchronously so the request does not block your application.                   |

## Patient Summary lifecycle

The Patient Summary lifecycle is as follows:

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Tip>
  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.
</Tip>

## 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.

```mermaid actions={false} theme={"theme":{"light":"github-dark","dark":"material-theme-darker"}}
flowchart LR
  A["Ingest FHIR data"] --> B["Generate summary"]
  B --> C["Background processing"]
  C --> D["Generated summary"]
  D --> E["Retrieve and display summary"]

  style A fill:#FFF394,stroke:#333,color:#000
  style B fill:#FFF394,stroke:#333,color:#000
  style C fill:#FFF394,stroke:#333,color:#000
  style D fill:#FFF394,stroke:#333,color:#000
  style E fill:#FFF394,stroke:#333,color:#000
```

<Note>
  For workflow details, refer to [Generate patient summaries](/documentation/how-to/patient-summary/generate-patient-summaries). For display and empty-state behavior, refer to [Retrieve patient summaries](/documentation/how-to/patient-summary/retrieve-patient-summaries).
</Note>

## Data flow

Patient Summary relies entirely on data previously ingested into CKG.

```mermaid actions={false} theme={"theme":{"light":"github-dark","dark":"material-theme-darker"}}
flowchart TD
  A["EMR"] --> B["FHIR resources"]
  B --> C["Clinical Knowledge Graph"]
  C --> D["Patient Summary generation"]
  D --> E["Patient Summary APIs"]
  E --> F["Partner application"]

  style A fill:#FFF394,stroke:#333,color:#000
  style B fill:#FFF394,stroke:#333,color:#000
  style C fill:#FFF394,stroke:#333,color:#000
  style D fill:#FFF394,stroke:#333,color:#000
  style E fill:#FFF394,stroke:#333,color:#000
  style F fill:#FFF394,stroke:#333,color:#000
```

<Tip>
  Use consistent patient, practitioner, and encounter identifiers throughout ingestion, generation, and retrieval so requests map to the correct clinical data.
</Tip>

## Summary structure

A completed Patient Summary typically contains the following sections:

| Section              | Description                                                   |
| :------------------- | :------------------------------------------------------------ |
| **About this visit** | Appointment type and reason for the visit.                    |
| **Summary**          | High-level overview of the patient's recent clinical history. |
| **Previous visits**  | Summaries of recent encounters.                               |
| **Problems**         | Active problem list.                                          |

<Note>
  The sections returned and its quality depend on the clinical data available in CKG and your implementation decisions.
</Note>

## Recommendations to design your integration

Keep the following in mind when designing your integration:

<Tip>
  * 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.
</Tip>

## 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:

* [Integrate CKG](/documentation/concepts/patient-summary/integrate-ckg) to ingest FHIR data.
* [Generate patient summaries](/documentation/how-to/patient-summary/generate-patient-summaries) to start summary generation.
* [Retrieve patient summaries](/documentation/how-to/patient-summary/retrieve-patient-summaries) to display completed summaries in your application.