Vitalink HealthData, Swiss clinical interoperability
Vitalink HealthData develops an API that connects data from glucometers and smartwatches to electronic patient records. Our work sits between consumer devices and Swiss clinical systems. This page presents our mission, our technical approach, and the principles that guide our decisions.
An integration layer, not a replacement for your EHR
We want to make device data usable in a Swiss clinical context, without imposing an overhaul of existing systems. This means absorbing heterogeneous streams, normalizing them, and transmitting them via FHIR. Our role is that of an integration layer, not a replacement for your EHR. This position guides our technical choices.
- What we absorb
- Blood glucose series and smartwatch readings, with formats, cadences, and signal qualities that vary by manufacturer.
- What we do not touch
- Your patient record remains the reference. We do not overwrite your clinical model: we deliver readable resources to your target system.
- Why this choice
- An EHR overhaul takes years and mobilizes entire teams. An integration layer is deployed project by project, without freezing your roadmap.
- What you keep
- Control over your architecture, your data, and your clinical decisions. Our API fits into your existing access rules.
FHIR as a foundation, hospital reality as a framework
HL7 FHIR, developed by Health Level Seven International, is based on REST, JSON, and XML. This modular standard is simpler to implement than previous mechanisms. We rely on it, while taking into account Swiss hospital realities. The electronic patient record remains the reference, but FHIR is not deployed end-to-end.
REST and JSON first
Application teams get HTTP verbs and readable payloads, rather than a protocol to re-implement from scratch.
Profiles rather than inventions
We start from recognized profiles and exchange guides, then we document every intentional deviation rather than masking it.
The patient record remains in control
The EHR retains clinical authority. Our API routes and normalizes; it does not make decisions on its behalf.
The Swiss context
In Switzerland, the use of FHIR in the electronic patient record is described as limited to certain cases, notably vaccination and medication.
Exchange requirements are framed by specific guides. Working here requires working with this environment, not ignoring it. Our integrations align with these constraints, and we explicitly document cases where a stream falls outside the scope covered by the guides. This honesty avoids surprises during the acceptance phase.
Hospital legacy and modern architectures
Our team brings together integration and software development profiles. We know HL7 v2, IHE, DICOM, and XDS, as well as modern APIs. This dual culture helps bridge the gap between hospital legacy and modern architectures. We do not claim to replace your teams; we provide them with tools.
Historical standards
HL7 v2, IHE, DICOM, XDS: the formats your systems already use on a daily basis.
Modern stack
REST, JSON, OAuth, queues: what your developers expect from an API today.
Role in your projects
We equip your teams: documentation, test environments, support on profiles.
What we ask for
A technical contact on the client side and a clear definition of the target system from the first exchange.
Security is designed with the clinical architecture
Security is not an option added at the end of a project. Encryption in transit and at rest, OAuth authentication, role-based access control, and logging are part of the foundation.
Access rights must be thought out with the clinical architecture from the conceptual phase. Our work falls within the framework of the Swiss Federal Act on Data Protection (FADP) and the European General Data Protection Regulation (GDPR), which we detail in our privacy policy.
Read the privacy policyThis requirement comes up in every project, and it influences our choices of encryption schemes as well as our authorization model. For technical details, consult the page dedicated to security and encryption.
See encryption schemesOur acknowledged limits
Clearly stating what we do not do is part of our approach. This prevents you from building a project on an expectation that we will not be able to meet.
What our API does
- Transport series of measurements from consumer devices.
- Normalize heterogeneous formats into readable FHIR resources.
- Route to your EHR or an intermediate middleware.
What we do not do
- We do not manufacture medical devices.
- We do not provide diagnosis or clinical interpretation.
- We do not replace your institution's clinical responsibility.
Our API transports and normalizes data; clinical use remains your responsibility. This boundary is clearly stated in our project exchanges.
We fit into these architectures without replacing them
We focus on absorbing sensor streams and routing them to the EHR or a middleware. Other components remain in place, with their own standards and their own teams.
- Sensor streams
- Our core business: reception, normalization, and routing of measurements from consumer devices.
- Document sharing
- Handling other standards like XDS, supported by institutional infrastructures.
- Clinical modeling
- Can be handled via openEHR, with its own archetypes and governance.
- Our place
- An integration layer between devices and these architectures, documented and without surprises.
How a project starts
The quote follows technical validation. We do not price an integration we have not understood.
-
1
Describe your use case
Devices involved, expected volumes, target systems, and your team's constraints. This determines everything else.
-
2
Identify FHIR endpoints and profiles
We determine the resources involved, applicable profiles, and gaps to document before writing a single line of integration.
-
3
Validate with a technical demonstration
A session with your developers, using a representative dataset, to confirm that the approach works in your environment.
-
4
Receive the quote
Pricing is based on the validated scope. For large volumes, enterprise rates adapt to the number of streams and sites.
Enterprise rates are detailed on the dedicated page, along with support and onboarding options. Our team is reachable Monday to Friday, from 09:00 to 18:00 (CET).
Continue reading according to your needs
Depending on your role in the project, one page will be more useful than another. Here is where to start.
Vitalink HealthData AG · Seefeldstrasse 45, 8008 Zürich, Schweiz
+41 21 581 78 71 · [email protected]