---

In dit derde deel van de BIHR-beschrijving duiken we (een beetje) in de technische context:

Welke concrete interface componenten vormen de 'bouwstenen' van BIHR = de BWO (BIHR Werk Omgeving)

Op welke manier kunnen 'connectoren' de complexiteit van softwareontwikkeling verminderen (en meteen de interoperabilitiet beter garanderen)?

Waarop kunnen softwareontwikkelaars zich meer gaan focussen?

Deel III – De BWO & Connectoren

 

De BWO (BIHR Werk Omgeving)

BIHR is een concept. In het eHealth Actieplan 2026-2029 willen we het omzetten naar een concrete elektronische werkomgeving waarin het geïntegreerde gezondheidsdossier in de praktijk werkt. Die werkomgeving noemen we de “BWO” (BIHR Werk Omgeving). Let wel: BIHR noch de BWO zijn EPD’s. 
BIHR is een concept en de BWO zal bestaan uit software componenten die deels centraal, deels in elke software apart zal ontwikkeld en gebruikt worden.

In feite zal de BWO uit vier grote blokken bestaan:

A.    De (15) rubrieken, met de authentieke bronnen met de data.

B.    De connector(en), die de orkestratie en technische koppelingen van componenten verzorgen.

C.    De (nieuwe) module voor co-creatie van zorgepisodes.

D.    De gebruikersinterface, die zorgt voor visualisatie en registratie door gebruikers.

De blokken A en B worden idealiter onder regie van de overheden ontwikkeld omdat ze door alle gebruikers – en zo uniform mogelijk – zullen gebruikt worden. Blok C wordt in elke geval (door de overheid) voor de burger/zorggebruiker ontwikkel. Het doel is dat die ontwikkeling ook modules of componenten kan omvatten die (als plug in) voor andere gebruikers bruikbaar/beschikbaar zijn.
Daarbij is het doel dat de (centrale) ontwikkeling van de BWO voor patiënten de 'motor' en het 'voorbeeld' kan worden vor de hele BIHR ontwikkeling (voor iedereen allicht zichtbaar in 'MijnGezondheid.be')

De ontwikkeling van blok D beoogt onder meer de werkomgeving voor visualisatie en registratie door zorgverstrekkers en in instellingen. Dat deel zit alleszins in de individuele EPD’s worden dus door de respectievelijke softwareleveranciers ontwikkeld.
Daarbij is het doel dat bestaande EPD's zoveel mogelijk verder gebruikt kunnen worden en dat ze dus hoofdzakelijk aleen aangepast moeten worden om het de andere BWO blokken samen te werken.

Om een zo groot mogelijke cohesie en performantie te realiseren, verdient het de voorkeur om een geïntegreerde ontwikkeling voor te stellen die aan de softwareproviders ‘plug-in modules’ bezorgt, die zij in hun softwarepakket kunnen integreren, waarbij ze ervoor zorgen om de elektronische werkomgeving voor de zorgverstrekker/zorggebruiker zo kwaliteitsvol en gebruiksvriendelijk mogelijk te maken.  Wanneer softwareontwikkelaars de nodige ontwikkelingen zelf realiseren zal strik op de interoperabiliteit van deze applicaties moeten worden toegezien. 

Het is daarenboven de bedoeling dat de huidige monodisciplinaire softwarepakketten van huisartsen, verpleegkundigen, kinesitherapeuten, apothekers, evolueren naar performante interprofessionele pakketten (kan b.v. via incentives gestimuleerd worden), om hen zo snel mogelijk ‘in co-creatie’ met BIHR te laten werken.

Gebruiksvriendelijkheid, kwaliteit en automatisatie

Zeker in Rubriek 2 moet de BWO zorgen voor decentrale ondersteuning van besliskundige processen: Diagnostic and Therapeutic Decision Support (via algoritmes en via A.I.), warnings (‘voor deze patiënt met deze nierfunctie kan U dit antibioticum niet voorschrijven’), mogelijke relevante interacties (tussen geneesmiddelen, tussen geneesmiddelen en allergieën b.v.), aanbieden van relevante EBP-guidelines (cf. destijds DUODECIM), koppelen van data in BIHR aan beslissingsondersteunende tools bv ihkv beeldvorming, …

BIHR mikt ook op de meest doorgedreven vorm van automatisatie bij deze processen:

• Bij registratie – zoveel mogelijk tijdens het patiëntencontact – capteren van gegevens via inlezing (bv. eID-lezing) of barcodes. Hierbij kunnen we zeker op slimme manier A.I. modules inschakelen.
   
• Gebruikerssoftware moet zoveel mogelijk automatisch metadata (voorzien in de CareSet) aanvullen op basis van de context waarin patiënt en zorgverstrekker zich bevinden (plaats, tijdstip, behandeling, etc.).En dus gaan we ook hier bij registratie en visualisatie maximaal gebruik maken van (eenvoudige) A.I. tools. 
   
• Enkele voorbeelden:
  • Gebruik van voice-to-data registratie (de arts spreekt de conclusie van een raadpleging in en A.I. vult maximaal de FHIR-resources in).
     
  • (In principe zal bij de start van de raadpleging de ‘Probleem’ rubriek al worden ingevuld. Maar A.I. kan in dit geval allicht op basis van de data ook een voorstel doen).
     
  • Filtering en rangschikking van de meest relevante data voor visualisatie in het dashboard bij het begin van een patiëntencontact op basis van de zorgverstrekker en de pathologie van de patiënt (bv. bij een hartfalen patiënt bij de cardioloog verschijnen bovenaan de labo, beeld, medicatie, etc. gegevens die bij deze pathologie horen). 
     
  • Medicatieschema’s worden automatisch opgebouwd op basis van de FHIR-resources uit Recip-e (voorschriften) en GFD/DPP (afleveringen), gegroepeerd per VMP-groep (basis omschrijving van een medicatie behandeling: molecule + dosis + toedieningsweg). Aan elke VMP-medicatielijn hangt de hele historiek van voorschriften en afleveringen in die VMP-groep. 
     
  • In deze context stellen we voor een ‘rolkrant’ of ‘opvolgnota’ te ontwikkelen, die tijdens het patiëntencontact automatisch relevante informatie analyseert en interactief presenteert (*). Een overzichtelijke lijst van to do’s in de marge van een dashboard laat toe om met elk item op het gepaste moment rekening te houden (wat beter werkt dat pop-up’s en waarschuwingen tijdens het werkproces).
     
• We verlaten de term ‘SumEHR’ en gebruiken de Europese term ‘International Patient Summary’ (IPS).
   
• Het is de bedoeling dat deze samenvatting steeds meer automatisch kan gegenereerd worden op basis van de meest relevante (selectie van de) beschikbare data.
   
• Vermits veel van deze (nieuwe?) processen breed kunnen ingezet worden, moet onderzocht worden welke ‘automatisatie modules’ gezamenlijk of door de overheid (gefinancierd) kunnen worden ter beschikking gesteld, in samenwerking met CeBaM, EBPracticenet, Worel, KCE…

De zorggebruiker

BIHR beschouwt de zorggebruiker als een ‘producent’ en als ‘gebruiker’ van zijn persoonlijke data. Dat wil ook zeggen dat de zorggebruiker mogelijkheden krijgt om data toe te voegen in zijn dossier conform de EHDS (cf. de rubrieken Telemonitoring en Levensdoelen. In andere rubrieken zal de patiënt ook nota’s of opmerkingen kunnen noteren, die als dusdanig door het zorgteam kunnen worden gevisualiseerd).

De gebruikerssoftware voor de patiënt wordt door de overheid voorzien. Het geïntegreerd interfederaal portaal MijnGezondheid.be heeft hiertoe al een soliede basis gelegd, waarop de verdere uitrol van het BIHR-concept kan worden uitgebouwd ten behoeve van de patiënt.

De Connector en de Hubs 

Zowel bij registratie als bij visualisatie zal de gebruikerssoftware in verbinding staan met een hele reeks authentieke bronnen. Daarom voorziet BIHR het inschakelen van ‘connectoren’ of ‘data brokers’, die het dataverkeer op een efficiëntere manier orkestreren tussen de gebruikerssoftware enerzijds (instellingen en ambulante praktijken) en de diverse authentieke bronnen anderzijds (bv. Recip-e; FarmaFlux; MyCareNet; Kluizen; Hubs; authentieke bronnen van alle rubrieken…) (**).  

Het doel is dat de gebruikerssoftware via slechts één aanspreekpunt alle FHIR-resources uit de diverse bronnen kan oproepen en nieuwe data ernaartoe kan opladen. Uiteraard zullen zowel de bestaande eHealth connectoren als de Metahub hierbij een rol spelen. De connector(en) nemen de technische complexiteit voor de softwareontwikkelaars zoveel mogelijk over, ze garanderen door hun architectuur en aanpak de interoperabiliteit van de systemen en data en ze verlichten de werklast voor visualisatie en registratie bij de gebruiker.

De connector(en) vormen de technische verbinding tussen de rubrieken/authentieke bronnen en de (data I/O van) de gebruikerssoftware (voor zorggebruikers, eerste, tweede, derde lijn, instellingen…). Deze cruciale component moet dus ontwikkeld worden in nauw overleg met zowel de authentieke bronnen als de gebruikers en hun softwareontwikkelaars. Daarbij is het doel van de connector om interoperabiliteit en homogeniteit te verzekeren rond up- en downloaden van de FIHR-resources, zodat het vertrouwen in de data stelselmatig toeneemt.

Voor de instellingen die zijn aangesloten op de Hubs, zullen de Hubs zelf allicht de connector/broker functie op zich nemen, al dan niet met de hulp van gemeenschappelijk ontwikkelde modules voor bepaalde rubrieken. 

De rol van softwarebedrijven 

Via deze aanpak wordt beoogd dat bij de softwareontwikkeling voor de eindgebruikers (in instellingen en ambulante praktijken) veel minder tijd gaat naar al deze koppelingen, waardoor het accent kan verschuiven naar het ontwikkelen en optimaliseren van de end-user-interfaces voor visualisatie en registratie van nieuwe data.

Als gebruikerssoftware slechts één aanspreekpunt hebben en standaard werken met CareSets en FHIR-resources, kunnen de meeste aanpassingen op het niveau van het eHealth Platform en de Authentieke Bronnen (inclusief een resem ondersteunende componenten) opgevangen worden in de connector.

Daarenboven kunnen de aanpassingen die toch een effect hebben op eindgebruiker-software beter gecoördineerd en voorbereid worden, wat de doorlooptijden van innovaties en aanpassingen op het terrein sterk kan inkorten (en het werk op het terrein verlichten) (***).  

Gebruikers en softwareontwikkelaars zullen uiteraard steeds bij de voorbereiding en planning van de ontwikkelingen op het Platform en de Bronnen betrokken blijven, zoals voorzien in de Governance (in dit Actieplan).

-------

(*)   Bijvoorbeeld: een niet-ingevolgde oproep voor borst- of darmkankerscreening; een diabetes-patiënt die toe is aan een oogfundus- of voet-onderzoek; een AB-voorschrift dat niet compatibel is met de nierfunctie van de patiënt; een interactie met een actief medicijn uit het actuele medicatieschema; ‘het nieuw voorgeschreven geneesmiddel was al vroeger voorgeschreven, maar werd niet afgehaald bij de apotheek’; ‘de laatste HBA1C-bepaling is meer dan 6 maanden geleden’; ‘griepvaccinatie nog niet toegediend’;…)

In de rolkrant zal ook een signaal staan wanneer relevante data werden toegevoegd door andere zorgverstrekkers. We trachten immers het zenden aan elkaar van verwijsbrieven en verslagen ('teksten') zoveel mogelijk te vermijden.
Opdrachten ('verwijzingen'; 'voorschriften';...) en nieuwe, relevante gegevens ('voor het verslag') moeten tijdens (of uiterlijk aan het einde) van een patiëntencontact worden geregistreerd. In plaats van hiervan een verslag te maken, kunnen deze data voorzien worden van een 'flag', die er automatisch een overzicht van genereerd wanneer de bestemmeling het dossier van de patiënt opent, al dan niet wanneer ze de patiënt zien.

(**) Men dient nog na te gaan of het al dan niet aangewezen is om verschillende connectoren in te schakelen voor primair gebruik (individuele patiënt), en voor population health management.

(***) Tijdens de Corona crisis leidde een dergelijke aanpak tot ontwikkelingen van complete nieuwe stromen van gegevensuitwisselingen in dagen of weken, eerder dan maanden of jaren.

 

Ga hier meteen naar de andere delen van de BIHR beschrijving:

Deel I – Wat is BIHR?

Deel II – Rubrieken & Zorgepisodes

Vervolg:

Deel IV – Drivers of Change 

REACT

 

---

‹‹Back