Vitalink connects glucometers and smartwatches to your EPD
Your team needs to integrate blood glucose measurements and sensor series into a Swiss electronic patient record without rebuilding the entire interoperability chain. Vitalink HealthData exposes a REST API that absorbs device streams, normalizes them, and writes them into your clinical system via Swiss FHIR profiles.
What the API actually does
The Vitalink API receives data from glucometers and smartwatches, converts it into FHIR resources, and transmits it to your EHR or existing middleware.
-
REST Endpoints
You call standard REST endpoints in JSON or XML, without having to write your own parsers for each device manufacturer.
-
Metadata
The service handles timestamps, patient identification, and device metadata so that the source remains readable in the record.
-
Real-time
This is a real-time integration layer, not just a file export dropped once a day on a server.
-
Target
The same layer feeds an EHR, an institutional middleware, or an internal clinical database, depending on the architecture already in place.
FHIR interoperability and Swiss context
HL7 FHIR, developed by Health Level Seven International, is based on REST, JSON, and XML. In Switzerland, the EPD remains the reference, but FHIR is not deployed end-to-end there.
Swiss integration teams are already working with HL7 v2, IHE, DICOM, and XDS. Our role is to bring sensor data into this environment without breaking it, and to clearly distinguish clinical document sharing from real-time device streams.
Your integrations must therefore take into account the gap between "API first" ambition and hospital reality. Vitalink documents the resources used for each type of measurement, as well as the associated patient metadata.
Why a middleware layer before the EHR
Writing directly into a patient record from a watch raises questions of access rights, format, and traceability. A middleware layer like Vitalink absorbs these streams, applies authorization rules, and then feeds the target system.
This avoids dispersing device logic across multiple applications and maintaining a different parser every time a manufacturer changes its format.
Authorization perimeters by role and resource, delegated on the API side.
Normalization of units, observation codes, and date formats before writing.
Each access is logged to answer hospital audit questions.
Encryption, traceability, and access control
OAuth authentication allows delegating access without sharing secrets between systems. Access rights are a major integration point as soon as multiple systems and partners touch the same patient data. They must be designed with the clinical architecture and deployment environment in mind, not added as an afterthought.
Health data in transit and at rest is encrypted. Each access is logged, which allows answering hospital audit questions. Traceability is one of the recurring expectations of compliance officers in Switzerland.
Processing falls under the Swiss Federal Act on Data Protection (FADP) and the European GDPR for cross-border flows. Details on schemas, subcontractors, and retention periods are described on the Security and encryption page and in the privacy policy.
Privacy policy- In transit Encrypted channels between the device, the API, and the clinical system.
- At rest Encrypted storage of measurement series and associated patient metadata.
- Logging Each read and write leaves a trace that can be used for auditing.
Enterprise pricing
Options are chosen based on the volume of measurements, the number of connected institutions, and your organization's compliance requirements.
Pilot project
To validate the complete chain on a service or clinic, with a limited scope of devices.
- REST endpoints and OAuth authentication
- FHIR standardization of blood glucose measurements
- Technical onboarding support
Hospital or group
For an institution connecting multiple departments, with FHIR profiles and terminology specific to its environment.
- Targeted Swiss FHIR profiles and terminologies
- Smartwatch time series
- Role-based and resource-based access control
- Audit-ready logging
Medical software vendor
For vendors integrating Vitalink into their product who need to connect patient applications to a clinical system.
- Separate environments for development and production
- OAuth access delegation for your clinical clients
- Compliance options discussed with your team
Standardization and terminologies
Consumer devices do not all speak the same language: units, codes, and date formats vary. The API applies semantic standardization before writing to the EHR. This concerns units of measurement, observation codes, and repositories like SNOMED CT. Without this step, every integration becomes a full-scale translation project.
A blood glucose measurement is represented with observation resources, linked to a patient and a device. Smartwatch time series require a different structure, adapted to volume and frequency. Vitalink documents the resources used for each type of measurement. You retain control over the target profile and the terminology used.
- Point-in-time blood glucose
- Observation resource linked to the patient and the device.
- Time series
- Structure adapted to the volume and frequency of smartwatch measurements.
- Terminology
- Units, observation codes, and repositories like SNOMED CT.
openEHR and clinical modeling
Some teams prefer to model clinical data more deeply, using openEHR, rather than transporting FHIR resources. This choice depends on the persistence and the level of clinical detail expected. Vitalink fits into both approaches: FHIR transport or feeding a richer clinical model. It is up to you to decide where the boundary lies.
Read the API documentationEPR, XDS, and document sharing
The Swiss electronic patient record (EPR) relies on specific exchange guides. XDS remains used for document sharing between institutions, which complements architectures that do not rely solely on APIs.
It is necessary to distinguish clinical document sharing from real-time sensor streams. Vitalink handles the latter case, integrating with existing document exchanges when necessary.
Who the API is designed for
The API is aimed at developers in Swiss hospitals and clinics, medical software vendors, and integration teams. It is also suitable for projects that connect patient applications to a clinical system.
- Hospital and clinic developers Internal teams
- Medical software vendors Product
- Integration and middleware teams Systems
- Projects connecting patient applications to a clinical system Partners
Where to start
-
1
Read the API documentation
The endpoints, OAuth authentication, and FHIR resources used for each type of measurement.
Open API documentation -
2
Consult the security page
Useful if your compliance officer has questions about encryption, traceability, or the scope of FADP and GDPR.
Open security page -
3
Compare enterprise pricing
Options are detailed according to the volume of measurements and your organization's compliance needs.
Open enterprise pricing -
4
Request a technical demo
We prepare a session with your use case: devices involved, target system, and deployment constraints.
Contact us
Frequently asked questions
The three questions that come up most often during initial technical discussions. Other detailed answers can be found in the site's FAQ.
See the full FAQIs it necessary to go through a middleware layer before writing to the EHR?
Not necessarily, but a middleware layer facilitates access control, standardization, and traceability. It avoids scattering device logic across multiple applications.
Which Swiss FHIR profiles must be respected?
This depends on your institution and its exchange guides. Vitalink documents the resources used and aligns with the profiles you target.
How is data secured?
OAuth authentication, role-based access control, encryption in transit and at rest, and access logging. Details are on the Security and encryption page.
Request a technical demo
Describe your use case: device types, target system, and deployment constraints. We will prepare a technical session adapted to your clinical environment.
Vitalink HealthData AG
Seefeldstrasse 45, 8008 Zürich, Schweiz
Monday – Friday: 09:00 – 18:00 (CET)