BIHR-connector (FHIR-broker)

Welk probleem wil de connector oplossen? Binnen BIHR moet de software van elke zorgverlener gegevens ophalen uit en publiceren naar verschillende authentieke bronnen. Het BIHR-concept stelt daarvoor één connector voor: in de slides van de BIHR Summer Day (24 augustus 2026) is de connector (FHIR-broker, API) één aanspreekpunt dat de complexiteit achter de schermen overneemt en interoperabiliteit garandeert tussen gebruikerssoftware en bronnen zoals Recip-e, FarmaFlux, BruSafe, Inter-Med en Vitalink^[1]. Het is de zesde van zes bouwstenen die al op de Interoperability Day van 24 maart 2026 werden opgesomd^[2]; toen werd het publiek ook bevraagd over centraal bijgewerkte 'connectoren' tussen de rubrieken van de authentieke bronnen en het EPD^[2].

Aard van de bron. Het gaat om een concept uit BIHR-werkgroepen en -presentaties (slides op de wiki van HL7 Belgium), geen RIZIV-regelgeving. Plenaire sessie II van de Summer Day behandelde de koppeling van software met de authentieke bronnen via een "rapidly implementable FHIR broker", voor primair en secundair gebruik^[3]. De slides zetten het oorspronkelijke concept af tegen "what is under development"; in augustus 2026 is de connector dus een concept in uitwerking, geen operationele dienst^[1].

Voorgestelde functies en doelen (Summer Day-slides)

Connector versus bestaande uitwisselingsarchitectuur

Zie Hubs-metahubsysteem voor de huidige architectuur.

Bevinding: de BIHR-connector is een werkgroepconcept dat sinds maart 2026 wordt besproken en in augustus 2026 nog in uitwerking was^[2][1]. De officiële RIZIV-tekst spreekt enkel algemeen van een behouden uitwisselingsplatform met connectoren^[4]. Wie de broker bouwt of beheert, is niet publiek vastgelegd; de rol van de hubs is een leveranciersverwachting^[5].

• Geen verplichting en geen dienst: er is geen connector om op aan te sluiten; de bestaande Hubs-metahubsysteem- en eHealth-connectorarchitectuur blijft de referentie^[4][1].
• Wat wel verandert: nieuwe en gewijzigde stromen worden binnen BIHR FHIR volgens Belgische profielen (planning vanaf 2028)^[4]; een broker zou dat voor de softwareontwikkelaar moeten vereenvoudigen^[1].
• Aanbeveling (eigen): vraag de EPD- en integratieleverancier hoe hun FHIR-koppeling zich verhoudt tot een eventuele centrale broker, en behandel een product dat zich 'BIHR-connector' noemt als leveranciersclaim zolang eigenaar en specificatie niet publiek zijn.

Een connector die filtert op CareSet-metadata en semantische conformiteit controleert, veronderstelt gepubliceerde CareSets en profielen (zie BIHR: CareSets en EHDS-roadmap)^[1]. Filtering op rol, rechten, therapeutische relatie en toestemming is binnen BIHR hoe dan ook vereist vóór weergave^[4].

• Eigenaar, specificatie en aanbesteding: niet gevonden (stand 2026-10-01) bij RIZIV, eHealth-platform, Vitalink en CoZo. Eigen vaststelling (zonder citaat): ook in het Belgisch Staatsblad, op de RIZIV-pagina's over het BIHR en het actieplan en in de bekeken TED-aankondigingen van het RIZIV uit 2026 werd geen officiële specificatie, aangewezen eigenaar of aanbesteding voor een BIHR-connector gevonden; de RIZIV-presentatie van maart 2026 noemt connectoren enkel als partij die moet voorbereiden en testen^[8]. e-Procurement werd niet doorzocht (gap). Niet gevonden is geen bewijs van afwezigheid; zie ook Verplichting of planning? Rechtsgrond voor SNOMED CT, CareSets en FHIR.
• Rol van de hubs: enkel een leveranciersverwachting^[5]; een gefedereerde FHIR-opstelling bij CoZo werd in juni 2026 getest, niet als BIHR-connector aangekondigd^[6]; het enige publieke FHIR-project rond de hubs is sinds juni 2023 inactief^[7].
• Oorspronkelijk concept versus in ontwikkeling: de slides maken het onderscheid^[1], maar de gepubliceerde selectie maakt niet duidelijk wie wat ontwikkelt.