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

# Connectivity models

> The three ways MediSync Connect reaches a clinical system — Direct, HealthHub, and the on-site Agent — and when each applies.

Clinical systems differ in how they can be reached: some run in the cloud with a
modern API, some sit behind a vendor partner platform, and many run only on a server
inside the practice. MediSync Connect supports all three through **three connectivity
models**. Each system in the [catalog](/connect/supported-systems) uses one of them;
which one is a property of the system, not a choice you have to engineer.

<CardGroup cols={3}>
  <Card title="Direct" icon="cloud" href="#direct-integration">
    Cloud-to-cloud over FHIR/REST.
  </Card>

  <Card title="HealthHub" icon="link" href="#healthhub">
    FHIR via the medatixx HealthHub platform.
  </Card>

  <Card title="On-site Agent" icon="server" href="#on-site-agent">
    A local connector for systems inside the practice network.
  </Card>
</CardGroup>

## Direct integration

**When:** the system exposes an endpoint MediSync can reach over the internet — a
cloud-hosted FHIR/REST API, or a hospital **ISiK** FHIR endpoint that IT has made
reachable.

MediSync talks to the system's API directly from the cloud:

* **FHIR R4 / ISiK** endpoints, authorized with a **bearer token** (typical for ISiK
  hospital endpoints) or **SMART on FHIR / OAuth2** (for OAuth-capable FHIR servers).
* **REST** APIs, authorized with a short-lived **JWT** or an **API key**.

Data flows as standard FHIR resources (or the vendor's REST objects, mapped to the
same clinical concepts). Nothing is installed at the practice.

<Info>
  Some practice systems technically have a REST/FHIR API but run on a server that
  isn't exposed to the internet. Those are reachable either directly (if IT publishes
  the endpoint) or through the [on-site Agent](#on-site-agent) — this is decided per
  connection based on how the system is reachable, not by the standard it speaks.
</Info>

## HealthHub

**When:** the system is part of the **medatixx** product family.

For medatixx systems, MediSync connects through the **medatixx HealthHub** partner
platform, which exposes a FHIR interface to the underlying practice software. This is a
platform partnership: the practice authorizes access, and MediSync exchanges FHIR data
through HealthHub rather than talking to the local installation directly.

<Note>
  Some medatixx systems are available today through the [on-site Agent](#on-site-agent)
  (GDT), and move to HealthHub FHIR as that partnership rolls out. The connection in
  your dashboard stays the same — only the underlying transport changes.
</Note>

## On-site Agent

**When:** the system runs only inside the practice network and exchanges data through
a local, file-based interface (**GDT**, **HL7 v2**, or a vendor **XML** format) or a
local FHIR endpoint (e.g. a deep-link launched by the practice software).

Most established German PVS fall here. The **MediSync Agent** is a small application
installed on a workstation in the practice. It makes a **secure, outbound-only**
connection to MediSync (no inbound ports or firewall changes) and bridges MediSync to
the local system:

* **GDT / HL7 v2** — the Agent exchanges records through the import/export folders the
  practice software is configured to use: it reads patient context the PVS drops there,
  and writes examination/result records back.
* **Structured XML** — for systems that accept a native XML document format, the Agent
  writes documentation in that format.
* **Local FHIR (deep link)** — for systems that expose a FHIR endpoint only on the
  local machine, the practice software launches MediSync in the patient's context and
  the Agent relays FHIR calls to that local endpoint.

Patient context flows **in**, and finished notes / diagnoses / documents flow **back
out** to the record — the same clinical capabilities as the other models, just over a
local transport.

See [The MediSync Agent](/connect/medisync-agent) for install, pairing, and security.

## Choosing a model

You don't choose — the system does. When you pick your system in the dashboard,
MediSync already knows which model it uses and guides you through the matching setup.

| Your system                            | Model                          |
| -------------------------------------- | ------------------------------ |
| ISiK hospital KIS (reachable endpoint) | Direct (FHIR / bearer)         |
| Cloud-capable PVS with a REST/FHIR API | Direct (REST/JWT or OAuth)     |
| medatixx family                        | HealthHub (or Agent/GDT today) |
| Established on-site PVS (GDT/HL7/XML)  | On-site Agent                  |

<Card title="See where your system fits" icon="network-wired" href="/connect/supported-systems">
  The full catalog, grouped by connectivity model.
</Card>