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, HL7 v2, or THEDEX. Everything below is a published specification — there is nothing for you to implement 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 uses the gematik ISiK FHIR profiles where the hospital system provides them — specifically Terminplanung Stufe 3 for scheduling (Slot / Appointment / Appointment/$book). One FHIR contract then serves each such KIS; what varies between hospitals is only the endpoint URL and how the access token is issued. MediSync Connect implements these profiles as a client. It does not claim a gematik conformity confirmation of its own.

​

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.

​

THEDEX (therapy practices)

THEDEX (THErapy Documentation EXchange) is the interface of THEORG, the SOVDWAER practice software used by physiotherapy, occupational therapy, speech therapy, and podology practices. SOVDWAER publishes the specification; participating systems exchange messages as text files (.TDX) through a shared THEDEX directory on the practice network, each system with its own registered sender ID and inbox. Connect participates through the MediSync Agent: it reads patient master data from ClientNew / ClientChange messages and writes finished documentation back as ClientReport messages with the document attached, so it lands in the THEORG patient record. THEORG does not expose GDT, HL7, or FHIR; THEDEX is its integration path.

​

How the standard maps to the model