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

# Standards & protocols

> The open healthcare standards and vendor interfaces MediSync Connect speaks — and what each one enables.

MediSync Connect meets each system on the interface it already exposes. Depending on
the system, that is a modern FHIR/REST API, a hospital ISiK endpoint, or a classic
file-based practice interface such as GDT or HL7 v2. Everything below is an open,
published specification — there is nothing proprietary to adopt on your side.

## Modern APIs

### HL7 FHIR R4

The primary standard for cloud-capable systems. Connect models patient context and
clinical documentation as standard FHIR **R4** resources (`Patient`, `Condition`,
`Observation`, `DocumentReference`, `Appointment`, `Slot`, `Bundle`), aligned with
German base profiles and **ICD-10-GM** coding.

### ISiK (Terminplanung Stufe 3)

For German hospital systems, Connect speaks the **gematik ISiK** FHIR profiles —
specifically **Terminplanung Stufe 3** for scheduling (Slot / Appointment /
`Appointment/$book`). One FHIR contract serves every ISiK-conformant KIS; what varies
between hospitals is only the endpoint URL and how the access token is issued.

### SMART on FHIR (OAuth2)

For FHIR servers that authorize with **SMART on FHIR**, Connect uses the OAuth2
authorization-code flow with PKCE and scoped access. For ISiK hospital endpoints,
access is typically a **bearer token** issued by the hospital's IT rather than an
interactive OAuth dance. Access and refresh tokens are stored **encrypted**, and no
long-lived static credentials are shared.

### REST / JSON

Some practice systems expose a vendor REST API (for example authenticated with a
short-lived JWT or an API key). Connect talks to these over standard HTTPS with JSON
payloads.

## Practice interfaces (file-based)

Many German practice systems (PVS) do not expose an internet API; they exchange data
locally through file-based interfaces. Connect reaches these through the
[MediSync Agent](/connect/medisync-agent).

### GDT (xDT family)

**GDT** (Gerätedatenträger) is the dominant device interface in German practices.
Connect implements GDT and exchanges records through the import/export folders your
practice software is configured to use — reading patient context (record type `6302`)
and writing back examination/result records (record type `6310`). Related xDT formats
(**LDT**, **BDT**) appear on many systems' interface lists as well.

### HL7 v2

For systems that prefer **HL7 v2** messaging — often KIS-oriented practice and clinic
software — Connect exchanges HL7 v2 messages through the Agent.

### Structured XML

Some systems accept a vendor-specific **structured XML** document format for
write-back, with one section per clinical block (anamnesis, findings, therapy, and so
on). Connect produces that native format where a system supports it.

### HL7 CDA

Connect supports **HL7 Clinical Document Architecture (CDA)** for exchanging structured
clinical documents, complementing the FHIR `DocumentReference` flows.

## How the standard maps to the model

| Interface                        | Typical systems                         | Connectivity model                                          |
| -------------------------------- | --------------------------------------- | ----------------------------------------------------------- |
| FHIR R4 / ISiK (bearer or OAuth) | Hospital KIS (ISiK), cloud FHIR servers | [Direct](/connect/connectivity-models#direct-integration)   |
| REST + JWT / API key             | Cloud-capable PVS                       | [Direct](/connect/connectivity-models#direct-integration)   |
| HealthHub FHIR                   | medatixx product family                 | [HealthHub](/connect/connectivity-models#healthhub)         |
| GDT / HL7 v2 / XML / local FHIR  | On-site PVS                             | [On-site Agent](/connect/connectivity-models#on-site-agent) |

<Note>
  Which interface a given system uses is confirmed during onboarding — see
  [Supported systems](/connect/supported-systems) for the per-system view and
  [Getting connected](/connect/getting-connected) for the flow.
</Note>