Bijlage 16. Architectuur Informatiesysteem DD JGZ

Transcriptie

1 Bijlage 16. Architectuur Informatiesysteem DD JGZ Inleiding De architectuur van zorginformatie wordt in de regel in een aantal lagen of stacks opgedeeld. Elke laag met zijn eigen niveau binnen en tussen organisaties, bijpassende doelen, structuur en werkwijze. Voor het DD JGZ zijn enkele van deze niveaus al ingevuld. Van de leverancier wordt verwacht dat voor de POC met name de lagen 4 en 5 nader worden uitgewerkt. Deze notitie biedt een aanzet hiervoor. De tekst is gebaseerd op de aanbestedingsdocumentatie. Vijf lagen model Voor deze uitwerking hanteren we een veel gebruikte indeling in vijf lagen, ontleend aan TOGAF, Nictiz en het Generic Component Model (CGM) van Blobel (2010). Dit vijf lagen model start bovenaan met de strategische laag die de business omschrijft, vervolgens worden de processen beschreven van deze business. De derde laag omvat de data en informatieverwerking. Laag vier omvat de applicatie(s), in de regel uitgewerkt in functionele blokken voor de oplossing en de communicatie van data binnen de organisatie en met ketenpartners. Ten slotte wordt op laag vijf de technische oplossing/infrastructuur beschreven. Hoe lager in de hiërarchie, hoe meer de details van gegevens relevant zijn, bijvoorbeeld informatie op laag drie, moet technisch gespecificeerd zijn voor gebruik in de applicatie op laag vier en gecodeerd voor uitwisseling om in de infrastructuur uitgewisseld en gebruikt te worden. Laag 1 De Business GGD en werken aan de uitvoering van de Jeugdgezondheidszorg. GGD staat voor Gemeentelijke of Gemeenschappelijke Gezondheidsdienst. In Nederland is de uitvoering van diverse gezondheidstaken volgens de Wet Publieke Gezondheid (WPG) neergelegd bij de gemeente. Voor de uitvoering is er de Gemeentelijke Gezondheidsdienst (GGD), waarvan het bestuur gevormd wordt door een of meerdere gemeenten. Voor de JGZ is ook in een aantal gevallen een Jeugdgezondheidszorg organisatie verantwoordelijk, hetgeen landelijk gezien per regio verschilt. Het uitvoeren van JGZ vormt een belangrijk onderdeel van de wettelijke taken. Binnen de GGD en zijn het de professionals van de JGZ die samen zorgen voor de preventieve zorg voor kinderen van 0-19 jaar. Waar relevant wordt aanvullende begeleiding gegeven dan wel verwezen naar behandelaars. Elk van de GGD en beschikt over een centrum waar de expertise rondom JGZ is geconcentreerd en waar het regionale beleid wordt ontwikkeld, vormgegeven en geëvalueerd op basis van de landelijke consensus, maar aangepast aan de lokale omstandigheden. De meeste GGD'en hebben een taak als frontoffice, dat wil zeggen dat in deze GGD-consultatiemomenten plaats vinden, ouders worden voorgelicht, kinderen worden gevaccineerd. De GGD en werken op lokaal en regionaal niveau met veel personen en organisaties samen. Het DD JGZ dient een toekomst vast informatiesysteem te zijn, vormgegeven in een moderne interface en met moderne technieken. Klaar voor gebruik in de komende tien (10) jaar.

2 Laag 2 de processen De oplossing van het DD JGZ is proces ondersteunend, specifiek gericht op de contactmomenten die de levensfasen volgen. Dit wordt aangeboden door een heldere werkwijze aan te bieden en te automatiseren doordat het systeem weet welke kinderen op welk moment waar in hun levensfase en waar in een proces zitten. Afspraken voor contactmomenten moeten worden bijgehouden, uitnodigingen verstuurd etc. Om dat te bereiken staan ook zorgplannen (ook wel zorgpaden genoemd) centraal. Het zorgplan doorloopt een vastgesteld proces dat is gekoppeld aan de cliënt. Uiteraard bestaat de mogelijkheid om daar voor individuele cliënten vanaf te wijken. Bijvoorbeeld door de wensen van de ouders voor extra begeleiding, dan wel door specifieke risico s voor het kind. In samenwerking met de projectgroep DD JGZ is een aantal use cases uitgewerkt voor een redelijk uniforme set van werkprocessen zoals afspraken planning, voorlichting, vaccinatie, gehoortest, groei en ontwikkeling, en in toenemende mate ook financiële afhandeling b.v. via declaraties. Dit is een proces op hoofdlijnen dat na gunning in het implementatietraject nader verfijnd kan worden. Deze processen bieden ruimte aan kleine, lokale of regionale afwijkingen. Deze komen voort uit bijvoorbeeld verschil in beschikbaarheid of aanwezigheid van functionarissen en/of faciliteiten. Op hoofdlijnen is het proces echter gelijk en is de beleving voor de cliënt vergelijkbaar ongeacht de locatie of regio waar hij/zij wordt gezien. Belangrijk voor de wijze van uitwerking zijn de volgende beleidswensen: Het DD JGZ is een per GGD ingericht systeem waarbij dossiers van cliënten/kinderen tijd- en plaats onafhankelijk beschikbaar zijn voor alle betrokken zorgverleners van de eigen GGD en samenwerkingspartners, (steeds met inachtneming van geldende wet- en regelgeving). Ook kunnen ketenpartners zoals gemeentelijke zorgteams en het LSP aangesloten zijn en cliënten (n.b. ook de kinderen zelf vanaf een bepaalde leeftijd) krijgen inzage in de eigen gegevens via het cliëntenportaal. Voor het maken en beheren van de afspraken wordt via een web portaal aan de cliënt een aantal opties geboden. Na keuze door de cliënt van locatie, plaats en tijd wordt de informatie doorgegeven aan de GGD en van daaruit wordt de cliënt uitgenodigd voor het contactmoment. In het persoonlijk profiel (een profiel per kind, deels betreffende de familie) komen persoonsgegevens, groei en ontwikkelingsgegevens, risico s en vaccins conform de BDS en lokale aanvullingen aan de orde. Het te ontwikkelen systeem ondersteunt het concept zorgplannen of paden waarbij een zorgverlener, afhankelijk van de situatie van de cliënt, zoveel mogelijk automatisch door de stappen (contactmomenten, programma, enzovoorts) wordt geloodst. In Bijlage 15 van de aanbesteding zijn de processen globaal weergegeven in de vorm van storyboards voor: I. Online afspraak maken, bevestigen en wijzigen. II. Cliëntendossier opzoeken en gegevens opzoeken voor een consult. III. Medicatieoverzicht en toetsing allergieën en bijwerkingen via het LSP bij elektronisch voorschrijven vaccinatie. IV. Verwerken van adviesvragen. V. Verwerken van adviezen VI. Vastleggen van de set financiële gegevens die voor declaraties noodzakelijk zijn.

3 Niet in detail uitgewisseld, maar wel relevante storyboards zijn onder andere: VII. Uitwisseling compleet dossier met gestructureerde gegevens via Dossier Overdracht Bericht (DOB). VIII. Uitwisseling vaccinatiegegevens via RIVM koppeling. Deze storyboards geven een illustratie van de werkzaamheden, actoren, werkprocessen en interacties tussen actoren. Actoren zijn zowel gebruikers als systemen/ systeemcomponenten. Het dossierdeel moet ervoor zorgen dat het: Mogelijk wordt de preventieve zorg en advies aan ouders en kinderen doelmatig en efficiënt in de verschillende regio s te organiseren en samenwerking met ketenpartners te ondersteunen; Een integraal medisch dossier omvat waarin persoonsgegevens, groei- en ontwikkelingsgegevens, medische gegevens en vaccinatiegegevens kunnen worden bijgehouden, alsmede een overzicht van contactmomenten en bijzondere zorg. Rekening houdt met een laagdrempelige en veilige toegang door cliënten en zorgverleners tot dossiers van cliënten die onafhankelijk is van plaats en tijd via het cliëntenportaal dat voor zowel ouders als kinderen vanaf 12 jaar beschikbaar is. Samenwerkt met het landelijk schakelpunt en koppelingen verzorgt met diverse systemen en apps. Informatie en protocollen van het landelijk centrum jeugdgezondheidszorg (NCJ) kan downloaden en opnemen in het dossier bij observaties en/of adviezen. Standaardvaccinatieschema s en werkproces beschrijvingen kan beheren en gebruiken betreffende de uit te voeren consulten en werkzaamheden. Deze schema s kunnen ook in het dossier worden geïntegreerd. Op termijn een module voor de diensten- en productencatalogus bevat waarin zowel diensten als fysieke producten zoals vaccins (voorraden) kunnen worden beheerd en dat ook bestellingen kan afhandelen. Een financiële module waarin diverse vormen van betalingen van diensten en producten in kunnen worden afgehandeld, zoals de declaraties via Vecozo. Daarnaast hebben de opdrachtgevers zich als doel gesteld dat het informatiesysteem DD JGZ (op redelijk korte termijn) te koppelen is aan een extern planningssysteem voor de lokale GGD en waarin de planning van de te leveren consulten wordt gedaan. Dit is dus een verandering ten opzichte van de huidige situatie waarin de planning en DD JGZ geïntegreerd zijn in een systeem. Het DD JGZ moet naast een goede dossiervoering en vastlegging van de planningsmomenten per kind, ook een betrouwbare bron zijn voor voorraadbeheer, facturatie, managementsturing, rapportage en onderzoek. Daarbij passen geen dubbele en vervuilde gegevensbestanden. Om de gegevenskwaliteit te verbeteren zijn koppelingen noodzakelijk met systemen van derden. Deze koppelingen zorgen daarnaast vaak ook voor een efficiënte procesafhandeling, specifiek waar de uitwisseling tussen afsprakenmodule en reizigersdossiers betreft. Voor deze koppelingen wordt waar mogelijk gebruik gemaakt van standaard uitwisselformaten. De minimaal noodzakelijke koppeling is een regelmatige, minimaal 1 x per 24 uur, export van alle data (gestructureerd volgens BDS, eigen aanvullingen en ook documenten) uit het DD JGZ naar een GGD breed Data Ware House.

4 Laag 3. Informatie In de gunningsleidraad voor de aanbesteding zijn de volgende groepen gegevens benoemd, gekoppeld aan specifieke functies. De gegevens zijn verder gespecificeerd in de eisen en wensen. Functies Cliëntenportaal Afsprakenmodule Cliënten Beschrijving Voor ieder kind en zijn/haar ouders toegankelijke website waarin via een beveiligde toegang gegevens uit het DD JGZ kunnen worden bekeken en specifieke gegevens (b.v. specifieke vragen aan de professionals of vragenlijsten) kunnen worden ingevuld. In de web afsprakenmodule worden afspraken met cliënten getoond, gewijzigd, of aangevraagd. Vanuit de afsprakenagenda kunnen ook herinneringen worden verstuurd. Het onderhouden van cliëntdossiers. Alle gegevens van de cliënt zijn beschikbaar. Mailing De applicatie kent mailingfunctionaliteit ( , SMS) naar zowel gebruikers als cliënten. Verrichtingen EPD Import/ Export Preventieve zorg Interventies Rapportage Koppelingen Gebruikersbeheer Beheer Het toont de medewerker welke cliënten hij kan verwachten, wie er in de wachtkamer zit en ondersteunt aansluitend bij het verwerken van het consult of onderzoeken in het cliëntendossier. Onderzoek, vaccinaties, voorlichting e.d. worden bijgehouden. Het bijhouden van een cliëntdossier. Waarin de medische gegevens, maar ook contactmomenten, vervolgacties, gezondheidsverklaringen, brieven, recepten, etc. worden vastgelegd. Het kunnen inlezen en exporteren van cliëntgegevens. Het vastleggen van overzichten zoals groeidiagrammen, van Wiechenschema, geplande en toegediende vaccinaties, waar relevant conclusies. Het registreren van interventies door een arts/ verpleegkundige, bijvoorbeeld specifieke adviezen of deelname aan programma s op maat voor doelgroepen. Het kunnen maken en beschikbaar stellen van rapportages met stuurinformatie voor export naar datawarehouses en/of rapportagetools voor management, maar ook het kunnen maken van rapportages ten behoeve van onderzoek en surveillance. En rapporten voor o.a. verzekerde zorg. De functioneel beheerders kunnen zelfstandig rapportages definiëren en distribueren. Koppeling met systemen van ketenpartners. Het product dient een beheerinterface te hebben voor de interoperabiliteitslaag om de hoeveelheid koppelingen te kunnen onderhouden. Binnen de applicatie is een uitgebreide rollen- en rechtenmodule, waarin op module. scherm-, tabblad- en veldniveau gebruikers toegang krijgen, verdeeld over rechten om in te zien, in te voeren, te wijzigen en te verwijderen (CRUD). De gebruikers zijn bijvoorbeeld onder te verdelen in medewerkers van de GGD (verpleegkundigen, artsen en overig), beheerders en cliënten. Het kunnen beheren van de verschillende instellingen, rollen/rechten, stamtabellen, regionale indelingen en portals. In de beheermodule zijn voor de functioneel applicatiebeheerder alle tools beschikbaar om de applicatie efficiënt te kunnen beheren, inclusief de configuratie van de koppelingen, agenda s, vragen- en anamneselijsten, brieven, declaratiegegevens, producten (vaccins) etc. Laag 4: Applicatie en communicatie van gegevens De volgende functionele modules worden voorzien voor het DD-JGZ (Figuur 1). De blauwe onderdelen maken onderdeel uit van de basisapplicatie, de paarse onderdelen worden voor een verdere toekomst voorzien. De oranje onderdelen betreffen de planning componenten en deze dienen extern van het DD JGZ te kunnen worden verwerkt, bijvoorbeeld in een GGD-breed planningssysteem. De groene onderdelen rechts zijn voorbeelden van landelijke systemen die geen onderdeel uitmaken van deze aanbesteding, maar waarmee wel operationele koppelingen moeten worden gemaakt.

5 Figuur 1. Functionele aspecten van DD-JGZ. De gegevensuitwisseling binnen en tussen regio s, en met systemen van derden moet zo efficiënt als mogelijk verlopen, maar wel binnen de grenzen van vigerende wet- en regelgeving en gebruikte standaarden. De GGD en zijn als zorgpartij verplicht te voldoen aan de NEN75xx familie van standaarden, of de internationale equivalenten in de ISO 27xxx serie. In het licht van reeds gaande aanscherpingen van de Wet bescherming persoonsgegevens en de Europese Verordening Bescherming Persoonsgegevens zien de GGD en hier een noodzaak om niet alleen huidige, maar ook toekomstige inzichten over veiligheid en privacy hun weerslag krijgen in het DD JGZ. Uitgangspunt is privacy by design conform de laatste inzichten op Europees niveau en van de leverancier aan wie het DD JGZ wordt gegund, wordt verwacht dat deze gebruik maakt van deze inzichten en (cryptografische) technieken. In het kader van diezelfde informatiebeveiliging achten de GGD en testbaarheid van opzet bestaan en werking van de maatregelen die leverancier op dit terrein neemt essentieel, tot op het niveau van ingezet personeel en de broncode van de gebruikte software. Informatiebeveiliging is en blijft dus zeer belangrijk. Zeker in het licht van de nieuwe meldplicht datalekken die inging op 1 januari <functionaliteit graag aanvullen door leverancier als basis voor het POC >

6 Laag 5. Technische realisatie van de applicatie en infrastructuur < aan te vullen door leverancier>. Graag de volgende rubrieken uitwerken: Multi-tier opbouw als geheel en beschrijving van elke tier. In ieder geval presentatie laag, applicatie laag, dataopslag laag en data communicatie laag. Datamodel van de applicatie (gedetailleerd model van de database, b.v. als ER diagram of UML model). Hoe is een cliëntenrecord precies opgebouwd? Uitwerking van de splitsing en interactie tussen perceel 1 dossier en perceel 2 planning Privacy by design methoden die zijn toegepast Consent regeling voor cliënten: hoe werkt deze technisch? Security lagen uitwerking en beschrijving welke laag welke taken uitvoeren. Uitwerking hoe normale privacybescherming is uitgewerkt en hoe in noodsituaties deze procedure overruled kan worden (breaking the glass procedure). Tevens hoe bij overrulen van de procedure de logging wordt bijgehouden. Infrastructuur qua locaties, voorzieningen per locatie, back up, hardware, software en netwerk. Inrichting OTAP omgeving en waar klant mee te maken heeft. (Ontwikkeling, Testen, Acceptatietest, Productie). Inrichting van de database en beveiliging indien deze fysiek door meerdere GGDen wordt gedeeld, maar logisch gescheiden is. Uitwerking van de technische realisatie en van de procedures (zoals bij consent en bij geval van nood) voor de situatie dat GGDen met elkaar gegevens kunnen uitwisselen, records kunnen delen.