Standards & protocols

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.

​

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