Overlay and PHR
Add capability. Replace nothing.
Your record stays in the system your team knows. Hilbi reads through FHIR, adds the pathway on top, and writes results back. No migration. No parallel record.
- Your EHR stays the record
- Hilbi holds the patient's record
- One FHIR R4 contract
Above your system
nothing is migrated
Your record stays yours
we never become the system of record
This is the question that ends most evaluations
Replacing a system of record is a migration project with a clinical risk profile, a procurement cycle and a training bill. It is why most digital-health evaluations end before they begin. Hilbi does not ask for it. The record stays where it is today, under the law that governs it today, and the capability is added above it.
Two records, two roles
The distinction is legal as much as technical, and it is what makes the model work across providers.
Your EHR stays the record
The health record is the provider's, under Act 576/2004 Coll. and Act 372/2011 Coll. Hilbi reads and writes through FHIR R4 and never becomes it.
Hilbi holds the patient's record
A personal health record is a different legal object. It is the patient's, and it is how they exercise access and portability.
The patient is the only constant
A record anchored to the patient stays whole where an institutional record stops at the institution's edge. Consent travels with it.
One contract, any system
One FHIR R4 resource contract whatever sits behind it, so a new market is a connector and a configuration, not a rebuild.
The overlay, stated as facts
What Hilbi masters, what your record system masters, and what never moves.
- Position
- An orchestration layer above the existing record system. Never the system of record.
- What Hilbi masters
- Plan definitions, patient-reported data, and the patient's own personal health record.
- What the record system masters
- The clinical record, under Act 576/2004 Coll. in Slovakia and Act 372/2011 Coll. in Czechia.
- Interface
- HL7 FHIR R4; ISO 13606 semantics for synchronisation with local systems.
- Basis of the patient's record
- The patient's own; consent travels with it between providers and borders.
- Synchronisation readiness
- Stapro, CGM, Epic: readiness declared; live status per system.
- Backbone mode
- Where standardisation is required, Hilbi can operate as the core patient platform.
- Data residency
- Stated per market; never one global claim.
- What it does not do
- No migration, no parallel record, no moment where clinical data is in two places at once.
- Exit
- Your record never left your system. Audit log exportable; patient-held data exports as a FHIR R4 bundle.
What the connection model is ready for
Readiness is declared here. Whether a connection is live is a separate statement, made per system.
- Stapro and CGM are live at named sites in Slovakia and Czechia.
- Epic is live at one international site and readiness is declared for the rest.
- Every live connection is listed with its agreed scope on the integrations page.
| System | Primary markets | Interface model | Status |
|---|---|---|---|
| Stapro | Czechia, Slovakia | HL7 FHIR R4, mapped from the local record | |
| CGM | Czechia, Slovakia, DACH | HL7 FHIR R4, mapped from the local record | |
| Epic | United States, international | HL7 FHIR R4 | |
| Live connection status per system | All markets | Published on each system's integration page |
Questions about the overlay model
Does anything migrate?
Is Hilbi our system of record?
What is the practical difference between the EHR record and the PHR?
How does this relate to the European Health Data Space?
Can we start without an integration?
Monthly briefing
The signal, once a month.
What changed in European health data, what we shipped, and what it means for a provider. Nothing else.