Om deze vraag zo helder mogelijk te beantwoorden, hebben we een animatie gemaakt. Hierin wordt, aan de hand van een usecase uitgelegd hoe de digitale gegevensuitwisseling onder de motorkap werkt. Bekijk hier de animatie:
https://babyconnect.org/toolkit/animatie-onder-de-motorkap/

Bekijk de volgende video waarin wij antwoord geven op deze vraag: https://www.youtube.com/watch?v=tTp2MvLJkVs

Interoperabiliteit betekent dat systemen, afspraken en randvoorwaarden op elkaar aansluiten. Dit is nodig zodat er onderling gegevens uitgewisseld kunnen worden. Het afsprakenstelsel interoperabiliteit in de geboortezorg beschrijft de afspraken, architectuur en technische specificaties die nodig zijn om interoperabiliteit in de geboortezorg te bereiken. 

Het afsprakenstelsel bestaat uit twee onderdelen:

• Grondslagen
  Deze beschrijven het fundament waarop het afsprakenstelsel is gebaseerd. Hierin staan o.a. de achtergrond, de doelstelling, de randvoorwaarden, de uitgangspunten en de begrippenlijst van het afsprakenstelsel.

• Architectuur
  In dit onderdeel wordt de referentiearchitectuur uitgewerkt aan de hand van het interoperabiliteitmodel van Nictiz. Deze architectuur is het resultaat van de eisen en wensen van eindgebruikers die aan de hand van use cases in kaart zijn gebracht.

Ga naar het afsprakenstelsel interoperabiliteit in de geboortezorg >>>

Het uitgangspunt bij digitale gegevensuitwisseling in de geboortezorg is: de juiste gegevens op het juiste moment bij de cliënt en de juiste zorgverleners. Om ervoor te zorgen dat dit kan, is een flexibele samenstelling van informatie nodig die je kunt opvragen. Om deze flexibele samenstelling te krijgen – zodat informatie hergebruikt kan worden – moet data in stukjes geknipt worden. Hiervoor zijn zorginformatiebouwstenen (zibs) ontwikkeld.

Een zib beschrijft wat er over een bepaald item van het zorgproces van de cliënt moet worden vastgelegd en hoe dat moet worden vastgelegd. Een zib beschrijft van een bepaald zorginhoudelijk concept (bijvoorbeeld een Apgar score) uit welke elementen het is opgebouwd, welke waardelijsten gebruikt kunnen worden, etc. Hierdoor kan informatie eenduidig worden vastgelegd en is de bouwsteen bruikbaar in verschillende situaties en in verschillende zorginformatiesystemen. Informatie die gestandaardiseerd is vastgelegd in het zorgproces, kan verderop in het proces en voor andere doeleinden worden hergebruikt, omdat het kan worden uitgewisseld. Zibs zijn een conceptueel model en worden gebruikt voor het vastleggen van inhoudelijke (niet technische) afspraken. Voor gebruik in de praktijk moeten ze ‘vertaald’ worden naar een technische communicatiestandaard zoals FHIR.

Meer informatie over zibs vind je hier>>>
En bekijk deze animatie: https://youtu.be/L_sjCGzav8A

FHIR staat voor “Fast Healthcare Interoperability Resources”. Het is een internationale standaard voor digitale gegevensuitwisseling in de zorg die wordt beheerd door de organisatie HL7. Met deze technische standaard kunnen de conceptuele zorginformatiebouwstenen (zibs) in de praktijk worden gebruikt.

FHIR is opgebouwd uit implementeerbare bouwstenen die we “resources” noemen. Je kunt bij een server bepaalde resources opvragen (“GET”), aanmaken (“POST”), updaten (“PUT”) en in sommige gevallen ook verwijderen (“DELETE”). Hiervoor moet je uiteraard wel toestemming hebben en geautoriseerd zijn.

Deze standaard bouwstenen zijn nader te specificeren, voor bijvoorbeeld Nederland of de geboortezorg, met behulp van profielen (“profiles”). Resources zijn ook verder uit te breiden met behulp van zogenaamde extensies (“extensions”). FHIR maakt gebruik van bestaande webtechnologie, zoals RESTful API’s, en is snel en relatief eenvoudig te implementeren.

Een implementatiehandleiding is een hulpmiddel voor regionale projectleiders om een bepaalde oplossing of software, zoals een viewer, bij een of meerdere zorgaanbieders in te voeren. Zo’n handleiding beschrijft in verschillende stappen hoe je die invoer het beste aan kunt pakken. Je kunt erin lezen wat de activiteiten, doorlooptijden, afhankelijkheden en succescriteria zijn. Een projectleider kan hiermee in verschillende stappen de benodigde informatie aan de juiste personen beschikbaar stellen om het project uit te voeren. De implementatiehandleidingen worden door het programmabureau per proces en per zorginformatiesysteem opgesteld. 

In het afsprakenstelsel staat exact beschreven welke rollen nodig zijn voor interoperabiliteit in de geboortezorg. Voor het publiceren van gegevens zijn dit de volgende rollen: Registrator, Extractor, Converter en Resource Server. Een zorginformatiesysteem (XIS) kan al deze rollen vervullen of maar een deel ervan op zich nemen. In dat laatste geval zijn één of meerdere losse applicaties nodig om de gegevens toegankelijk en vindbaar te maken. Omdat de verschillende rollen op basis van standaarden met elkaar gekoppeld kunnen worden, maakt het niet uit welke rollen door een XIS worden ingevuld en welke door derde partijen. In het afsprakenstelsel Interoperabiliteit Geboortezorg zijn implementatievarianten opgenomen. Hierin wordt d.m.v. verschillende afbeeldingen getoond welke rollen door derde partijen moeten worden ingevuld, afhankelijk van welke rollen door een XIS worden ingevuld.
Wanneer alle benodigde rollen voor het Proces Publiceren zijn ingevuld is het mogelijk om FHIR te ontsluiten.

Een use case is een specifieke beschrijving van een praktijksituatie in de geboortezorg waarbij voor een concrete situatie wordt beschreven welke informatie een zorgverlener wil zien. Dit wordt beschreven aan de hand van actoren (mensen, systemen) en transacties (welke informatie wordt wanneer vastgelegd en wanneer opgeroepen). Use cases slaan een brug tussen de zorgwereld en de IT wereld. Zie meer in factsheet usecases bij VIPP Babyconnect.

De use cases waar VIPP Babyconnect naar verwijst, zijn tot stand gekomen in samenwerking met zorgverleners. Er is aan zorgverleners gevraagd op welke momenten in het zorgproces behoefte is aan het raadplegen van geboortezorggegevens. Op basis van deze input is een aantal use cases met bijbehorende scenario’s uitgewerkt. Deze vind je in het afsprakenstelsel interoperabiliteit geboortezorg.

Voor goede en efficiënte zorg is het belangrijk dat informatie eenduidig wordt vastgelegd en gedeeld. Daarvoor moeten systemen, afspraken en randvoorwaarden op elkaar aansluiten. Dat noem je ook wel interoperabiliteit. Interoperabiliteit is de mogelijkheid van zelfstandige, niet gelijke organisaties, partijen, eenheden, systemen of individuen om met elkaar samen te werken, te communiceren en informatie uit te wisselen (Bron: Nictiz).

Om interoperabiliteit in de praktijk mogelijk te maken, zijn er verschillende middelen, afspraken en voorzieningen met betrekking tot informatie(uitwisseling) nodig. Om deze in kaart te brengen wordt het interoperabiliteitsmodel van Nictiz gebruikt. In dit model worden 5 lagen onderscheiden met elk haar eigen actoren, begrippen en standaarden:

• Organisatiebeleid

• Zorgproces

• Informatie

• Applicatie

• IT-infrastructuur

Daarnaast zijn er twee kolommen met randvoorwaarden die op alle lagen van toepassing zijn: informatiebeveiliging en wet- en regelgeving. In de factsheet Interoperabiliteit Geboortezorg wordt het model verder uitgelegd.

Voor de implementatie van digitale gegevensuitwisseling in de geboortezorg is de landelijke informatiestandaard voor de geboortezorg het Perinataal Woordenboek en Dataset (PWD). De basis voor de datasets zijn zorginformatiebouwstenen (zibs). Lees meer >>> 

Net als nu: in de systemen van de zorgverleners.
Voor meer informatie hierover bekijk je deze animatie: https://youtu.be/L_sjCGzav8A Cliënten hebben de regie over hun eigen gegevens. Zij geven zorgverlener(s) toestemming voor het mogen delen van de gegevens. 

Inzien is de eerste stap. In de toekomst gaan alle systemen naar dezelfde eenheid van taal (zibs), wat importeren op termijn makkelijker maakt. Idealiter wordt dan ook rekening gehouden met de nadelen van importeren. Zie deze factsheet voor een verdere toelichting.

Jazeker. Het dossier is een samenstelling van zibs. Bij elk consult worden gegevens in het eigen systeem ingevoerd en daarmee toegevoegd aan het (totaal)dossier.
Het kan zijn dat een verloskundige iets verkeerd heeft ingevoerd. Bijvoorbeeld hemoglobine 3,6 in plaats van 6,3.  Als hij of zij deze fout ziet, wijzigt deze de gegevens in het eigen systeem naar 6,3. En publiceert hiermee een nieuwe zib met de juiste gegevens. Er zijn nu twee zibs met verschillende informatie over de hemoglobinewaarde. Omdat iedere zib een eigen datum en tijd heeft, is er dus sprake van versiebeheer.

Bovengenoemd voorbeeld is een uitzonderlijk geval. Mocht de gynaecoloog intussen de waarde van 3,6 hebben gezien, zal hij of zij eerst contact opnemen met de verloskundige, voordat hij of zij overgaat tot een bloedtransfusie. Als de gynaecoloog de verkeerd ingevoerde waarde wil dubbelchecken en de gegevens wil terugzien, dan kan dat. Historische gegevens zijn altijd te raadplegen, mits de zorgverlener daar toestemming voor heeft gekregen van de cliënt. Dit doet hij of zij via de viewer, waar gegevens op datum en tijd teruggevonden kunnen worden.