Connectivity models

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 uses one of them; which one is a property of the system, not a choice you have to engineer.

​

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.

​

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.

​

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