Ontwikkeling van een gestandaardiseerd

29-jan-2008 Ontwikkeling van een gestandaardiseerd registratie en opvolgingsysteem voor patiënten in een Permanent Vegetatieve Status (PVS) en Minimaal Responsieve Status (MRS)

pagina 1 | 26

Ontwikkeling van een gestandaardiseerd registratie- en opvolgingssysteem voor patiënten in een Permanent Vegetatieve Status (PVS) en Minimaal Responsieve Status (MRS) FOD Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu Tussentijds rapport Ontwikkeling van een gestandaardiseerd registratie en opvolgingssysteem voor patiënten in een Permanent Vegetatieve Status (PVS) en Minimaal Responsieve Status (MRS)

© 2008 HICT nv Ezelstraat 69 8000 Brugge België

Document versie: 1 Bestandsnaam: del.nl.20080103.fod.ontwikkeling van een registratie en opvolgingssysteem.doc HICT nv | Ezelstraat 69 | 8000 Brugge | Belgium | RPR/RPM: 0866 039 556

l © HICT nv


1

pagina 2 | 26

Inhoudstafel

Inhoudstafel .................................................................................... 2 1 2 Context van het project .................................................................... 3 2.1 Situering......................................................................................... 3 2.2 Scope ............................................................................................. 4 3 Aanpak ........................................................................................... 5 4 Conceptuele architectuur .................................................................. 6 4.1 Actoren........................................................................................... 6 4.2 Use cases........................................................................................ 7 4.3 Informatie flow ................................................................................ 10 4.4 Toegang controle proces ................................................................... 11 5 Voorstel oplossing ............................................................................ 13 5.1 Mogelijke oplossingen voor het registratie en opvolgingssysteem ........... 13 5.2 Randvoorwaarden van het registratie- en opvolgingssysteem ................ 15 5.2.1 Gebruikersbeheer en authenticatie ..................................................... 15 5.3 Integratie met instellingen ................................................................ 16 5.3.1 Mogelijkheden bij de diverse instellingen ............................................ 16 5.3.2 Sumehr compliance.......................................................................... 17 5.4 Pseudo anonimisatie......................................................................... 18 6 Voorstel architectuur ........................................................................ 19 6.1 Logische architectuur ....................................................................... 19 6.2 Fysische architectuur – infrastructuur ................................................. 20 6.2.1 Componenten van de architectuur...................................................... 21 6.2.2 Beveiliging ...................................................................................... 21 6.2.3 Gegevenstransport ........................................................................... 21 6.2.4 Traceerbaarheid............................................................................... 21 6.2.5 Confidentialiteit ............................................................................... 22 7 Formeel antwoord op de gestelde vragen ............................................ 23 7.1 Meest efficiënte manier van gegevensverzameling ............................... 23 7.2 Het beschrijven van de technische specificaties van het registratie- en opvolgingssysteem ....................................................................................... 23 7.3 Kosten-baten analyse van het invoeren van een dergelijk systeem......... 23 7.4 Plan van aanpak .............................................................................. 24 8 Addendum ...................................................................................... 26

Bestandsnaam: del.nl.20080103.fod.ontwikkeling van een registratie en opvolgingssysteem.doc HICT nv | Ezelstraat 69 | 8000 Brugge | Belgium | RPR/RPM: 0866 039 556

l © HICT nv


2

Context van het project

2.1

Situering

pagina 3 | 26

In juli 2004 werd een pilootproject opgestart voor patiënten in een permanent vegetatieve status (PVS) en een minimaal responsieve status (MRS): een zorgnetwerk werd gecreëerd en medische/klinische en epidemiologische gegevens werden verzameld in het kader van een gestandaardiseerd activiteitenrapport. Dit piloot project is ten einde en vanaf 1 juli 2007 wordt er structurele financiering van het zorgnetwerk voorzien. Een zorgregistratie netwerk heeft als doel toereikende zorg verlenen aan de juiste patiënt, op het juiste moment, op de juiste plaats met de juiste middelen waarbij er gezorgd wordt voor de continuïteit binnen het zorgcircuit zelf. M.a.w. een homogeen zorgaanbod optimaal af te stemmen op de behoeften op het vlak van revalidatie en chronische verzorging. Om het zorgnetwerk te kunnen evalueren en verder op punt te zetten is een continue registratie en opvolging noodzakelijk. De Fod Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu wenst in deze context een gestandaardiseerd registratie- en opvolgingssysteem te ontwikkelen ter ondersteuning van enerzijds de continuïteit van de zorgnetwerken voor PVS/MRSpatiënten en anderzijds de ondersteuning van de gegevensregistratie over PVS/MRS patiënten. Het eindresultaat van dit project is een gestandaardiseerd registratie en opvolgingssysteem voor patiënten in een permanent vegetatieve status (PVS) en minimaal responsieve status (MRS). Dit met het oog op: - het bekomen van epidemiologische gegevens voor deze groep van patiënten, - ten allen tijde een accuraat beeld kunnen vormen van de beschikbare plaatsen in het zorgnetwerk om te vermijden dat patiënten buiten het zorgcircuit zouden vallen en om doorstroming binnen het zorgnetwerk te optimaliseren. De doelstelling is eveneens om dit systeem te integreren met bestaande systemen en geregistreerde gegevens moeten van die aard zijn dat ze op een internationaal niveau vergeleken kunnen worden. Ook wat betreft het ondersteunen van de continuïteit van de zorgnetwerken zal het systeem bijdragen aan on-line aanmelden door geautoriseerde personen van PVS/MRS patiënten en dit zowel op het niveau van het algemeen ziekenhuis naar expertise centra voor PVS/MRS patiënten toe als op het niveau expertisecentra voor PVS/MRS patiënten naar long term care centra toe. Het systeem dient in de toekomst beleidsinformatie te leveren en te fungeren als een reservoir van officiële statistieken en wetenschappelijk onderzoek.


l © HICT nv


2.2

pagina 4 | 26

Scope

Gezien de omvang van dit project, werd dit project opgesplitst in fasen. De eerste fase van dit project worden volgende doelstellingen van een antwoord voorzien: 1. Het bepalen van de relevante gegevens van patiënten in een permanent vegetatieve status (PVS) en een minimaal responsieve status (MRS) die noodzakelijk zijn om over epidemiologische gegevens te kunnen beschikken en om het voor gestandaardiseerd registratie en opvolgingssysteem te kunnen evalueren naar doeltreffendheid. Deze gegevens moeten ook internationale vergelijking toelaten. 2. Het bepalen van het meest efficiënte systeem om de gegevens te verzamelen uitgaande van het gegeven om zoveel mogelijk integratie te bewerkstelligen met bestaande systemen. 3. Het beschrijven van de technische specificaties van het systeem, rekening houdende dat enkel geauthoriseerde gebruikers op elk moment het aantal beschikbare plaatsen kunnen zien in de expertise centra en de long term care centra. 4. Een kosten-baten analyse van het invoeren van een dergelijk systeem. 5. De kost evalueren van het opzetten en het onderhoud van de voornoemde systemen, een planning voor de implementatie van deze twee systemen voorstellen en de mogelijkheid nakijken om deze systemen uit te breiden voor patiënten met andere niet aangeboren hersenletsels. In een tweede fase van dit project wordt het implementatie traject voor het registratie- en opvolgingssysteem voor patiënten in een permanente vegetatieve status en minimaal responsieve status verder uitgewerkt.


l © HICT nv


3

pagina 5 | 26

Aanpak

Dit project werd uitgevoerd in samenwerking met het universitair ziekenhuis van Luik (CHU de Liège). Zij werden verantwoordelijk gesteld voor het beantwoorden van de eerste doelstelling. HICT, als leverancier van management advies en IT oplossingen voor de gezondheidszorg is verantwoordelijk voor het in kaart brengen van de mogelijke technische oplossingen voor het registratie- en opvolgingssysteem, waarbij ook de kosten en baten van dergelijk systeem in beschouwing worden genomen. De aanpak die HICT hier hanteert in dit project baseert zich op twee principes: 1. Gebruik maken van verschillende invalshoeken om conceptuele, logische en fysische architectuur in kaart te brengen. 2. Op basis van de kritische - eigen kennis oplossingvoorstellen aanreiken om tot een werkbaar registratie- en opvolgingssysteem te komen. Dit rapport geeft inzicht in de conceptuele architectuur, logische en fysische architectuur van het registratie- en opvolgingssysteem. Het hoofdstuk conceptuele architectuur beschrijft de actoren, de informatieflow en de functionele eisen van het registratie systeem. In een volgend hoofdstuk worden de mogelijke oplossingen aangereikt. Er is bewust voor gekozen afstand te nemen van de technologie. Op deze manier fungeert de architectuur als een ideaal model op basis waarvan in een later stadium ontwerpbeslissingen als een ideaal model kunnen worden afgeleid c.q. getoetst. Vervolgens gaat het hoofdstuk ‘architectuur’ dieper in op een aantal belangrijke aspecten zoals beveiliging en toegangscontrole. Ook een voorstel naar fysische architectuur en beveiliging is opgenomen. Tot slot wordt een formeel antwoord geformuleerd op de vooropgestelde doelstellingen.


l © HICT nv


4

Conceptuele architectuur

4.1

Actoren

pagina 6 | 26

De actoren van het registratie- en opvolgingssysteem worden besproken aan de hand van de componenten van het zorgnetwerk1. Het zorgnetwerk voor patiënten in een PVS of MRS bestaat uit 4 componenten1: 1. Het stabiliseren van de vitale functies van de patiënt gebeurt tijdens het verblijf in het ziekenhuis. De verantwoordelijke arts van de patiënt van het ziekenhuis wordt hier als actor beschouwd. 2. Een overgangshospitalisatie in expertisecentra Vijftien expertisecentra zijn erin gespecialiseerd om gedurende gemiddeld zes maanden opvang en multidisciplinaire revalidatie te bieden aan patiënten in PVS of MRS met als doel de patiënt maximale ontwaak- en herstelkansen te bieden. De zorg en interventies zijn gericht op het creëren van optimale condities voor herstel en het voorkomen van complicaties. De verantwoordelijke arts van de patiënt van het desbetreffende expertisecentra wordt hier als actor aanzien. 3. Aangepaste zorg op lange termijn Bij ontslag uit het expertisecentrum kan de patiënt in: • één van de 30 in het kader van het zorgnetwerk gespecialiseerde RVT’s opgenomen worden. Deze RVT’s beschikken over aangepaste personeelsomkadering en infrastructuur. Ze garanderen kwaliteitsvolle opvang en begeleiding in een familiale omgeving en stellen zorgcomfort van de patiënt centraal. De actor is hier eveneens de verantwoordelijke arts van de patiënt. • een nursingtehuis van het VFSIPH opgevangen worden; Tot op heden wordt de beheerder van het nursing tehuis als actor beschouwd. • in de thuisomgeving, in samenwerking met een geïntegreerde dienst voor thuisverzorging (GDT), opgevangen worden. Tot op heden wordt een vertegenwoordiger van de geïntegreerde dienst voor thuisverzorging hier als actor beschouwd. 4. De kwaliteit en de continuïteit van de langdurige zorg wordt gegarandeerd door een blijvende nauwe samenwerking (externe liaison) met de expertisecentra. Indien de externe liaison is opgesteld, kan ook de arts van het expertise centra als actor worden beschouwd. Binnen de Fod Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu worden volgende actoren gedefinieerd: Beheerder van het registratie- en opvolgingssysteem IT-medewerkers Data-analisten 1

Eindrapport van het Federaal Deskundigenplatform gecreëerd in naleving van het protocol van 24 mei 2004 betreffende het gezondheidsbeleid ten aanzien van patiënten in een persisterende vegetatieve status.


l © HICT nv


pagina 7 | 26

De wetenschappelijke instanties worden de data analisten aangehaald als type actor voor het analyseren van data met het oog op outcome studies, het doorvoeren van internationale vergelijkingen en het in kaart brengen van de zorgtrajecten, na toelating van de FOD Volksgezondheid, Veiligheid van de voedselketen en Leefmilieu.

4.2

Use cases

De uses cases beschrijven de geautomatiseerde oplossing voor een elementair proces volgens de behoeftes en doelen van de gebruiker. De uses cases worden beschreven aan de hand van de hierboven gedefinieerde actoren. De case record form is het formulier die is opgesteld door de Universiteit van Luik in samenspraak met het beroepsveld. Dit formulier bevat de relevante gegevens van patiënten in PVS en MRS, die noodzakelijk zijn om epidemiologische gegevens te kunnen beschikken en het zorgnetwerk te kunnen evalueren naar doorstroming en capaciteitsplanning. 1. Use case van de verantwoordelijke arts van de patiënt van het algemeen ziekenhuis:

•

Generieke parameter • Inloggen platform op niveau van de arts van de instelling • Afmelden platform op niveau van de arts van de instelling

•

Aanmelden van een patiënt in PVS/MRS • Aanmaken PVS/MRS patiënt in systeem • Invullen van het administratieve gedeelte (eerste deel Case Record Form) • Invullen van het klinische gedeelte (tweede gedeelte Case Record Form)

•

Tijdens verblijf van de patiënt in PVS/MRS • Aanvullen klinische parameters (tweede gedeelte Case Record Form)

•

Aanvraag tot opname van patiënt in PVS/MRS voor een expertise centra • Raadplegen van de bedbezetting van de expertisecentra • Aangeven patiënt in PVS/MRS ontslagklaar is • Aanvraag indienen bij specifieke expertisecentra

•

Doorverwijzing naar specifiek expertise centra • Overdracht Sleutel Case Record forms

•

Bij sterfte van patiënt in PVS/MRS • Aanmelden in zorgregistratie netwerk

2. Use case van de verantwoordelijke arts van de patiënt van het expertisecentra: • Generieke parameter • Inloggen platform op niveau van de arts van de instelling • Afmelden platform op niveau van de arts van de instelling


l © HICT nv


pagina 8 | 26

•

Opname van PVS/MRS patiënt • Aanmelden PVS/MRS patiënt • Eventueel aanvullen van het administratieve gedeelte (eerste gedeelte Case Record Form) • Aanvullen van het klinische gedeelte (tweede gedeelte Case Record Form)

•

Tijdens verblijf van de PVS/MRS patiënt • Maandelijks aanvullen van klinische parameters

•

Indien een heropname in ziekenhuis • Overdracht sleutel Case Record Form

•

Aanvraag tot opname long term care instellingen • Bedbezetting bekijken long term care instellingen • Aangeven patiënt ontslagklaar • Aanvraag indienen bij specifiek long term care instelling

•

Doorverwijzing PVS/MRS patiënt long term care instellingen • Overdracht sleutel Case Record Form

•


3. Use case van de verantwoordelijke arts van het gespecialiseerde RVT • Generieke parameter • Inloggen platform op niveau van de arts van de instelling • Afmelden platform op niveau van de arts van de instelling •


•

Tijdens verblijf van de PVS/MRS patiënt • Periodiek aanvullen van klinische parameters

•


•

Heropname in ziekenhuis/expertisecentra • Overdracht Sleutel Case Record form

4. Use case van de vertegenwoordiger van de GDT-instelling • Generieke parameter • Inloggen platform op niveau van de beheerder van de instelling • Afmelden platform op niveau van de beheerder van de instelling •

Opname van PVS/MRS patiënt • Aanmelden PVS/MRS patiënt


l © HICT nv


• •

pagina 9 | 26

Eventueel aanvullen van het administratieve gedeelte (eerste gedeelte Case Record Form) Aanvullen van het klinische gedeelte (tweede gedeelte Case Record Form)

•


•


•


5. Use case van de verantwoordelijke beheerder van de VFSIPH / AWIPH • Generieke parameter • Inloggen platform op niveau van de beheerder van de instelling • Afmelden platform op niveau van de beheerder van de instelling •


•


•


•


6. Use case van de Fod Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu als administrator • Beheren van de applicatie • Raadpleger van de basisgegevens (structureel zorgnetwerk) • Gebruikersprofielen kunnen instellen en beheren • Aanmaken van nieuwe subusers kunnen aanmaken: dit zijn gebruikers die onder zijn bevoegdheid vallen. 7. Use case van de FOD Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu: IT - medewerkers • Staan in voor het dagelijks functioneren van de applicatie • Logging • Auditing 8. Use case van de Fod Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu: data analyse cel • Analyse van gegevens in functie van epidemiologie en capaciteitsmanagement Bestandsnaam: del.nl.20080103.fod.ontwikkeling van een registratie en opvolgingssysteem.doc HICT nv | Ezelstraat 69 | 8000 Brugge | Belgium | RPR/RPM: 0866 039 556

l © HICT nv

29-jan-2008 Ontwikkeling van een gestandaardiseerd registratie en opvolgingsysteem voor patiënten in een Permanent Vegetatieve Status (PVS) en Minimaal Responsieve Status (MRS) pagina 10 | 26

9. Use cases van de wetenschappelijke instanties • Na toelating Cel FOD Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu • Analyse van geanonimiseerde data met het oog op outcome studies, internationale vergelijkingen en zorgtrajecten in kaart brengen.

4.3

Informatie flow

Om inzicht te hebben in de informatiestromen van het registratie- en opvolgingssysteem voor patiënten in permanent vegetatieve status (PVS) en minimaal responsieve status (MRS) is het van essentieel belang om een duidelijk inzicht te hebben in het zorgnetwerk. Onderstaande figuur geeft een visuele voorstelling van de patiëntenstroom en de informatiestroom binnen het zorgnetwerk.

GDT acuut ziekenhuis

Patiënt

expertise center

Patiënt

Gespecialiseerd RVT VFSIPH / AWIPH

Data gegevens ingegeven

Data gegevens consulteren

Niet erkend RVT of andere

Longitudinale evolutie Met patiënt ID Zonder patiënt ID

FOD

Figuur 1: overzicht in de patiëntenstroom en informatiestroom binnen het zorgnetwerk.


l © HICT nv


4.4

Toegang controle proces

Iedereen die toegang heeft tot het registratie- en opvolgingssysteem voor PVS/MRS zal worden gekoppeld aan een gebruikersprofiel. Ieder gebruikersprofiel heeft een verschillend aantal standaard rechten. Deze profielen worden beheerd door de applicatiebeheerder. De functies die gevraagd worden zijn: 1. Identificatie van gebruikers In een inlogscherm invoeren van een gebruikersnaam of user ID of Electronische ID. 2. Authorisatie van gebruikers Niet alle informatie moet voor iedereen toegankelijk zijn. De informatie moet toegankelijk zijn voor de bepaalde rol en stadium van het registratie proces. Beveiligde authorisatie van de applicatie gebeurt via logonnaam en paswoord. Dit betekent dat er een beheersmodule moet zijn om gebruikers toe te kennen en rechten te geven. Deze functie kan eventueel gedelegeerd worden naar meerdere personen die de rechten van het userbeheer krijgen. 3. Authenticatie van gebruikers Het proces waarbij iemand, een computer of een applicatie nagaat of een gebruiker, een andere computer of applicatie daadwerkelijk is wie hij beweert te zijn. Bij de authenticatie wordt gecontroleerd of opgegeven bewijs van identiteit overeenkomt met echtheidskenmerken, bijvoorbeeld het in een systeem geregistreerd bewijs. Onderstaand schema geeft meer inzicht in de rollen en rechten die worden toegeschreven aan de verschillende actoren van het registratie- en opvolgingssysteem. Create Patiënt verblijft in het ziekenhuis Arts Fod Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu Patiënt verblijft in een expertise center Arts Fod Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu Patiënt verblijft in een gespecialiseerde RVT Arts Fod Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu Patiënt verblijft in een VFSIPH / AWIPH Beheerder Fod Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu

Read

Update

Delete

X X

X X

X X

X X


l © HICT nv


Patiënt verblijft in een GDT instelling Verantwoordelijke GDT instelling Fod Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu

X X

Figuur 2: Matrix omtrent de rollen en rechten van registratie- en opvolgingssysteem.

Bovenstaande matrix is een voorstel op basis van de voorbije meetings, een formele bevestiging van deze rollen is er niet genomen.


l © HICT nv


5

Voorstel oplossing

5.1

Mogelijke oplossingen voor het registratie en opvolgingssysteem

Er zijn 4 niveaus van oplossing mogelijk, waarbij de complexiteit van het systeem telkenmale stijgt, alsook uiteraard de implementatietijd en implementatiekost.

Niveau 4 Integratie Niveau 3 Transactie Niveau 2 Interactie Niveau 1 Informatie FOD Volksgezondheid publiceert informatie op hun portal

Gebruikers kunnen elektronisch communiceren met FOD maar kunnen niet per definitie elektronisch communiceren

Gebruiker kan Elektronisch communiceren met FOD en de toepassingen van de FOD antwoorden elektronisch op het verzoek van de gebruiker

Overkoepelende informatie en transacties zijn toegankelijk via intentiegerichte portalen

W aa rd e

Complexiteit / Kostprijs Figuur 3: Niveau van oplossingen voor het registratie- en opvolgingssysteem.

Hieronder volgt korte een beschrijving waarbij de vier niveaus ingevuld worden: •

Niveau 1: Informatie, dit resulteert in het publiceren van informatie door de Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu en COMAorganisatie op een publieke website.

•

Niveau 2: Interactie, dit betekent het doorsturen en invullen van informatie naar de Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu op een regelmatige basis, bv. bedbezetting binnen een instelling aan de hand van het aanmelden van een patiënt in PVS/MRS, invullen van case record form, ... . Idealiter kunnen de IT-systemen binnen de instellingen deze data automatisch doorsturen.

•

Niveau 3: Transactie, dit behelst de communicatie tussen de Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu enerzijds en de gebruiker anderzijds. Dit is een uitbreiding van niveau 2, waarbij de mogelijkheid bestaat om bijvoorbeeld via een webinterface data over de instelling, aanvullen van case record form, ... op een regelmatige basis bij te werken.


l © HICT nv


•

Niveau 4: Integratie, dit behelst de communicatie tussen alle actoren, en dit in alle richtingen. Op deze wijze kan geanonimiseerde patiëntendata doorvloeien naar wetenschappelijke instanties maar kunnen dossiers ook mee overgedragen worden met de fysische verplaatsing van patiënten.

In de conceptuele architectuur zijn reeds functionaliteiten en verwachtingen aangegeven welke enkel kunnen ingelost worden door een oplossing dat in sterke mate een “Niveau 4” haalt. Dit resulteert in een sterke doorstroming van informatie tussen alle spelers binnen dit terrein. Een oplossing die voldoet aan het niveau 4 zal een longitudinale opvolging van de patiënt mogelijk maken. Gezien de projectdoelstellingen die geformuleerd zijn, namelijk ten allen tijde een accuraat beeld kunnen vormen van de beschikbare plaatsen in het zorgnetwerk om te vermijden dat patiënten buiten het zorgcircuit zouden vallen en om doorstroming binnen het zorgnetwerk te optimaliseren, is het wenselijk niveau 4 verder uitgewerkt wordt. Er zijn verschillende mogelijkheden om een dergelijk platform uit te werken. De drie mogelijkheden zijn: • Mogelijkheid 1: Uitwerken van een eigen initiatief door de COMA organisatie • Mogelijkheid 2: Uitwerken van een platform door een TTP (Trusted Third Party) • Mogelijkheid 3: Uitwerken van een platform door de FOD Volksgezondheid, cfr. MUG-registratie Hierbinnen adviseren wij om mogelijkheid 3 verder uit te werken, namelijk een platform gehost door de FOD Volksgezondheid. De argumenten die wij hierbij naarvoor brengen zijn: • dit project is complex qua infrastructuur, het moet een voldoende beveiligingsniveau halen, alsook maximaal beschikbaar zijn; • het project bevat een niet te onderschatten aspecten op juridische gebied, meer bepaald de anonimiteit van gegevens; • het uitwerken van deze oplossing door een TTP (Trusted Third Party) is een mogelijke oplossing naar legale en privacy issues; • echter, de FOD Volksgezondheid heeft ruime ervaring en expertise in het behandelen van initiatieven zoals deze, zoals de nieuwe online MUG- registratie. De MUG registratie steunt namelijk op gelijkaardige principes: “De MUG-gegevens worden geregistreerd door het invullen van MUG-fiches in een via het internet toegankelijk registratieprogramma. De MUG-fiche kan ten behoeve van het patiëntendossier door de MUG die de interventie uitvoerde en door het ziekenhuis waarnaar de patiënt werd vervoerd, nadien terug gedownload worden. Na anonimisatie wordt een deel van de data automatisch overgemaakt aan de FOD Volksgezondheid, met behulp van een beveiligde internettoepassing2.” Bij MUG registratie worden volgende voorwaarden gerespecteerd: • een on-line applicatie (24/7 beschikbaar); • omgaan met patiëntengegevens en privacy (deze worden in het MUG project van de MUG databank niet overgedragen naar de databank van de FOD Volksgezondheid); • Anonimisatie van gegevens. 2

Bron: MUGREG - Gebruikershandleiding MUG Federale Overheidsdienst (FOD) Volksgezondheid, Veiligheid van de Voedselketen en Leefmilieu


l © HICT nv


5.2

Randvoorwaarden van het registratie- en opvolgingssysteem

Naast de functionele vereisten die zijn beschreven in de conceptuele architectuur dient het registratie- en opvolgingssysteem aan de volgende vereisten ook voldoen: • •

• •

•

•

Het platform moet op ieder moment beschikbaar zijn, zowel voor ingave, doorsturen als opvragen van gegevens, maw een 24/7 beschikbaarheid. Het platform moet gelijk welke cliënt toegankelijk zijn. Een internet browser applicatie is hiervoor het geschikte middel. Deze applicatie is niet enkel in staat te draaien op de meest gangbare PC’s en portables, maar eveneens op andere mobiele toestellen, wat registratie aan het bed van de patiënt mogelijk maakt. Een platform dat beschikbaar is via het internet vereist uiteraard een constante internet connectie. Maximale bescherming van patiëntengegevens. Hierbij stellen we een zeer sterk authenticatieproces voor, een geëncrypteerde communicatie van informatie tussen de instelling en de FOD Volksgezondheid. Indien mogelijk een integratie tussen de systemen van de instellingen en de FOD Volksgezondheid. Maw een 1-richtings upload verkeer van berichten vanuit de systemen binnen de instellingen, dit zou handmatig invullen van informatie via de web toepassing moeten uitschakelen. Hiervoor is een vastgelegd formaat nodig. De FOD Volksgezondheid en wetenschappelijke instanties moeten toegang kunnen krijgen tot deze informatie om het beleid beter af te stemmen. De beschikbare informatie moet geanonimiseerd kunnen worden vrijgegeven.

5.2.1 Gebruikersbeheer en authenticatie Hier is een strikte scheiding tussen het beheer van instellingen, en het beheer van de gebruikers binnen de instellingen opportuun. Het beheer van de instellingen (zowel acute ziekenhuizen, expertise centra als long term care centra) valt onder de bevoegdheid van de FOD Volksgezondheid. Binnen de instelling kunnen gebruikers beheerd worden door een applicatie verantwoordelijke. Het is de verantwoordelijkheid van de instelling om deze lijst van gebruikers steeds up-to-date te houden. Volgende informatie is een minimum set welke moet ingegeven worden om een gebruiker te kunnen identificeren: • Naam • Voornaam • Email adres • Rijksregisternummer • Taal Na aanmaken van een nieuwe gebruiker krijgt deze een bevestigingsmail op zijn/haar email adres. Het invoeren van naam, voornaam en rijksregisternummer laten toe om informatie van de federale overheidsbank over de gezondheidsberoepen op te vragen en automatisch de titels van de zorgverleners na te kijken om zo rechten aan de gebruikers toe te kennen.


l © HICT nv


Wat betreft authenticatie zijn er 2 mogelijkheden: • ofwel via een token, een combinatie van een gebruikersnaam en een cijfer/lettercode die slechts beperkt geldig is in tijd (enkele minuten); • ofwel via de electronische identiteitskaart; De MUG-registratie maakt gebruik van tokens, toegang tot KCENet loopt bijvoorbeeld wel reeds via E-id, alsook andere nationale en regionale initiatieven.

5.3

Integratie met instellingen

Een optimale integratie met de applicaties binnen de instellingen is reeds aan bod gekomen. Technologisch is dit mogelijk, doch een specifieke standaard is hier momenteel niet voor beschikbaar.

5.3.1 Mogelijkheden bij de diverse instellingen Wat zijn de mogelijkheden tot integratie bij de diverse instellingen? •

Acute ziekenhuizen: De acute ziekenhuizen beschikken allemaal over een administratief systeem (ADT berichtgeving) die de administratieve opvolging van de patiënt mogelijk maakt. Deze systemen zijn vaak HL7-compatibel en zouden via deze standaard informatie over de patiënt kunnen doorsturen.

•

Expertise centra: Het administratieve systeem van de expertise centra zijn minder geënt op systemen die een standaard navolgen

Brussel Centre Hospitalier Universitaire Brugmann Centre de Traumatologie et de Réadaptation Subtotaal Vlaanderen Heilig Hartziekenhuis, Roeselare Algemeen Ziekenhuis Sint-Jan, Brugge Universitair Ziekenhuis Gent Algemeen Ziekenhuis Salvator – Sint. Ursula, Hasselt Heropbeuring vzw De Mick, Brasschaat Zusters van barmhartigheid Ronse Universitair Ziekenhuis Leuven, Pellenberg Ziekenhuis Inkendaal, Vlezenbeek Subtotaal Wallonië Centre Hospitalier Régional de Tournai, Tournai André Vésale Charleroi CHR– Clinique Saint Joseph/Hôpital de Warquignies, Mons

Aantal Bedden

ADT

4 4 8

CPO CPO

5 5 5 5 5

Xtenso PADM1 Siemens Azis 1 Oracle DB (Lev: Obasi) Azis 2 Xtenso onbekend

5 16 46 5 5


Xtenso CPO CPO

l © HICT nv


Les Cliniques de l’IPAL, Luik Centre Neurologique et de Réadaptation Fonctionnelle, Fraiture Centre Neurologique William Lennox, Ottignies Subtotaal TOTAAL

5 5

Siemens CPO

6 26 80

CPO

Figuur 4. Administratieve systemen van de expertise centra

•

Long term care centra De long term care centra gebruiken waarschijnlijk een mix van toepassingen om het dossier van de patiënt te beheren, ondersteunen geen of amper gezondheidszorgbrede standaarden.

5.3.2 Sumehr compliance Een uitwisseling van boodschappen tussen de instellingen en de FOD Volksgezondheid verloopt het best via een gestandaardiseerd formaat. SUMEHR is een Belgisch initiatief. Sumerh – Summarized Electronic Health Record – is een gestandaardiseerd formaat voor elektronische uitwisseling van het kerndossier van een patiënt. Het is een afgeleide van de Belgische KMEHR standaard (Kind Messages for Electronic Health Records) en wordt toegepast in de boodschappenuitwisseling tussen huisartsen en andere systemen. Huisartsenpakketten moeten dan ook SUMEHR-compliant zijn. De • • • • • • •

SUMEHR structuur bevat volgende onderdelen: Patient-identificatie Patient information (name, sex, birth-date) Contact person Risks Antecedents Actual problem list Actual medication list

De SUMEHR standaard laat enkel toe om een basisset aan medische en achtergrond informatie van de patiënt te communiceren. Deze standaard is niet toepasbaar voor het registreren of communiceren van beschikbare bedden. Het is mogelijks bruikbaar om (beperkte) gegevens van de patiënt uit te wisselen wanneer de patiënt van centrum wijzigt. Onze conclusie over deze standaard is dat deze te beperkt is, en er weinig overeenkomst is tussen de 2 domeinen. De SUMEHR standaard is een afslanking van de KMEHR standaard, een XML-gebaseerd formaat. Deze standaard laat wel uitbreidingen toe, en dit op een gestructureerde manier, dit in tegenstelling tot de HL7 standaard. De KMEHR standaard wordt reeds voor andere initiatieven uitgebreid (bv. GZOinitiatief in de Gentse Regio), en bevat reeds standaard berichten om administratieve patiënten informatie door te sturen (oa. Waar verblijft een patiënt?), en geeft de mogelijkheid om deze op een gestructureerde wijze uit te breiden naar de noden van het zorgregistratienetwerk voor PVS/MRS patiënten .


l © HICT nv


5.4

Pseudo anonimisatie

Pseudonimisatie verwijst naar technieken die persoonlijke identificatoren (ID’s) van individuen vervangen door pseudo-identiteiten (pseudo-ID’s). Dit op een manier dat er geen verband meer kan gelegd worden met de nominatieve identiteit van de persoon.3 Deze techniek moet toegepast worden wanneer gegevens “beschikbaar” gemaakt worden voor onderzoek. Idealiter is deze techniek ingebed in de architectuur van de applicatie. Participerende actoren (ziekenhuizen, expertise centra, ...) werken rechtstreeks op een online database (uiteraard hebben ze enkel toegang tot de dossiers waartoe ze toegang mogen hebben). De toegang verloopt via een PPE (Privacy Protection Engine), welke de identiteit van de gebruiker controleert, en toegang verleent tot de nominatieve gegevens. Raadpleegt men “rechtstreeks” de databank, dan krijgt men enkel toegang tot de geanonimiseerde data, bijvoorbeeld wetenschappelijke onderzoekers, of gebruikers van de FOD Volksgezondheid. Deze vorm van anonimisering wordt reeds uitgebreid toegepast bij het uitvoeren van “clinical trials”. Idealiter worden alle gegevens – net zoals in MUG-project – geëncrypteerd opgeslagen.

3

Moderne privacybescherming, het nut van privacy enhancing techniques, Revue hospitals, Brecht Claerhout VOLUME 3, JANVIER-FÉVRIER-MARS 2005


l © HICT nv


6

Voorstel architectuur

6.1

Logische architectuur

Figuur 5: Logische architectuur

1 + 2 = Het beheren van enerzijds de bedbezetting in het centrum, als de case record forms verloopt via een formulier gebaseerde web oplossing. Deze applicatie is 24/7 beschikbaar. De applicatie vereist geen installatie op de lokale computer, enkel internet toegang is vereist. Het authenticeren van de gebruikers verloopt via een strenge procedure (token, e-id,...) en verleent de gebruiker enkel toegang tot deze informatie die nodig is om zijn/haar job naar behoren uit te oefenen. Mogelijks kunnen de IT-systemen uit de diverse centra via een gestandardiseerd formaat de gegevens naar dit platform opsturen. 3 = De gegevens van de patiënten en het centrum worden in een aparte databank opgeslagen, waar het personeel van de FOD, noch onderzoekers toegang tot hebben. Gevalideerde dossiers worden op regelmatige basis doorgestuurd naar de FOD en dit op een beveiligde manier. Op dit moment worden de gegevens ook geanonimiseerd. 4 = FOD Volksgezondheid, wetenschappelijke instanties, ... kunnen op basis van de beschikbare data rapporten trekken naar bedbezetting, maar kunnen ook deze geanonimiseerde data gebruiken voor onderzoeken.


l © HICT nv


6.2

Fysische architectuur – infrastructuur

Het is een vereiste dat de FOD Volksgezondheid een infrastructuur ter beschikking stelt voor alle betrokkenen, en garandeert een 24/7 beschikbaarheid. De applicatie dient een minimum aan beheer te vragen. Er is een zero-client die via een klassieke internet browser en zonder installatie van programma’s kan iedere gebruiker dit op zijn centra gebruiken. De architectuur zoals deze gebruikt wordt binnen de MUGREG is ook hier van toepassing.

Figuur 6: Fysische architectuur Bestandsnaam: del.nl.20080103.fod.ontwikkeling van een registratie en opvolgingssysteem.doc HICT nv | Ezelstraat 69 | 8000 Brugge | Belgium | RPR/RPM: 0866 039 556

l © HICT nv


De fysische architectuur wordt idealiter dubbel opgesteld, en is verspreid over 2 verschillende sites: • afhankelijk van de beschikbaarheid van de systemen worden oproepen naar het systeem met de minste bezetting doorgestuurd, dit is “load balancing”; • mocht 1 van de sites uitvallen, dan kan een andere site direct overnemen, dit is “fail over”.

6.2.1 Componenten van de architectuur Componenten van de architectuur zijn: • Firewalls filteren geldige oproepen van de ongeldige, en werken mee aan een hoog veiligheidsniveau. • De “reverse proxy” server is een onderdeel van de security oplossing. • De “application server” is het hart van het platform. Hierop staat de web applicatie. Het is deze server die met FEDICT communiceert om gebruikers te authentificeren. Hier gebeuren ook de verschillende encrypties van confidentiële gegevens. Het anonimiseren van gegevens om door te sturen naar de FOD Volksgezondheid databank vindt hier plaats. • De “LDAP server” speelt eveneens een rol in de authentificatieprocedure. • De “database server” geeft toegang tot de verschillende databanken. Databanken met de effectieve dossiergegevens, configuratietabellen, gebruikers, rollen, ... .

6.2.2 Beveiliging De authenticatie gebeurt op basis van gebruikersnaam en paswoord en het gebruik van een token. Deze token kan vervangen worden door een elektronische identiteitskaart (authenticatie op basis van een token is reeds beschikbaar door FEDICT en wordt gebruikt binnen Portahealth). Het beheer van de toegang binnen de applicatie en rollen is de verantwoordelijkheid van de applicatiebeheerder binnen de instelling. Deze kan de nodige gebruikers en rollen definiëren. Het is de rol van de instelling om er voor te waken dat de gebruiker de juiste kwalificaties heeft om de gegevens te behandelen. De applicatie moet een aantal basisrollen voorzien. De applicatiebeheerder zorgt voor de koppeling gebruiker <-> rol.

6.2.3 Gegevenstransport Alle communicatie tussen de cliënt en dit platform verloopt via het HTTPS protocol. Het gebruik van een SSL certificaat garandeert de applicatie dat de gegevens afkomstig zijn van de oorspronkelijke verzender.

6.2.4 Traceerbaarheid Iedere activiteit op het platform wordt opgevolgd door de applicatieserver en wordt gelogd (wie/wat/wanneer opgevraagd/gewijzigd/verwijderd/... heeft).


l © HICT nv


Ook moet de applicatie het mogelijk maken om verschillende versies van de patiëntendossiers bij te houden.

6.2.5 Confidentialiteit Om te vermijden dat er onrechtmatig toegang wordt verkregen tot de gegevens, worden deze geencypteerd opgeslagen (AES 128 bits algoritme). Decrypteren is enkel mogelijk met de applicatie.


l © HICT nv


7

Formeel antwoord op de gestelde vragen

7.1

Meest efficiënte manier van gegevensverzameling

Een advies hierin hangt in grote mate af van de consensus betreffende: • • • • •

het type gegevens (administratief, klinisch, ...), welke men wenst te registreren; de plaats van registratie (bureau, bed patiënt, ...); de periodiciteit van registratie (dagelijks, wekelijks, maandelijks, ...); de hoeveelheid van informatie; ...

We gaan er van uit dat op geregelde tijdstippen: • een bedbezetting binnen het centrum moet doorgegeven worden; • de status van de patiënt in het dossier moet bijgewerkt worden; Het bijwerken van de actuele bedbezetting en de status van de patiënt kan gebeuren via een web toepassing, in de vorm van digitale case record form (CRF). Een goed doordachte web toepassing laat ook toe om deze op mobiele toestellen te draaien, en aldus overal informatie registratie uit te voeren, mits een stabiele en constante internetverbinding (draadloos).

7.2

Het beschrijven van de technische specificaties van het registratie- en opvolgingssysteem

Zoals aangegeven in zowel alle hoofdstukken rond architectuur is het technisch mogelijk om met 1 platform alle stakeholders van dit project te bedienen, zonder in te boeten naar functionaliteit of veiligheid. Het voorgestelde platform ziet ook een volledige scheiding tussen nominatieve gegevens voor de instellingen, als geanonimiseerde gegevens voor de FOD Volksgezondheid, wetenschappelijke instanties, ... Details over dit platform zijn uitvoerig beschreven in dit rapport.

7.3

Kosten-baten analyse van het invoeren van een dergelijk systeem

De voordelen van het vooropgestelde platform zijn: • uiteindelijk een longitudinale opvolging van de patiënt; • een beter zicht krijgen op de beschikbaarheden binnen de centra door een geregelde rapportering van de centra naar de FOD Volksgezondheid; • op een gestructureerde manier de patiënt opvolgen wat toelaat om data te vergelijken, ook internationaal; • op een gestructureerde manier rapporteren naar de overheid; • ... De kosten daarentegen zijn op dit moment minder goed in te schatten omwille van een aantal openstaande punten waarover consensus tussen alle actoren moet bereikt Bestandsnaam: del.nl.20080103.fod.ontwikkeling van een registratie en opvolgingssysteem.doc HICT nv | Ezelstraat 69 | 8000 Brugge | Belgium | RPR/RPM: 0866 039 556

l © HICT nv


worden (oa. Verantwoordelijke arts in ieder centrum, toegangsrechten op actieve dossiers en zowel afgesloten dossiers, onduidelijke workflow bij overdracht van patiënt tussen centra, ...). Voor een dergelijk project, waarbij veiligheid en confidentialiteit van cruciaal belang zijn, kunnen we in de grootorde van 3 manjaar spreken.

7.4

Plan van aanpak

Het project kent nog te veel risicofactoren en punten waarop een duidelijke beslissing moet genomen worden, zoals bijv. de periodiciteit van registratie, het overdragen van dossiers van 1 instelling naar een ander, ... . Een IT project is idealiter een opvolging van een aantal stappen, waarbij om tot duidelijke kosten en inschattingen te komen én de kosten/risico’s onder controle te houden, de volgende stap niet genomen wordt vooraleer de huidige stap heel duidelijk en finaal is. De stappen die elkaar volgen zijn: 1. analysefase 2. ontwikkelingsfase architectuur 3. ontwikkelingsfase business functies 4. testfase 5. rollout Wij stellen voor om in een volgende fase ons te focussen op 2 domeinen: diepgaande analyse fase naar functionaliteiten; architectuur voorstel. Binnen de analyse fase moeten een aantal punten zoals aangegeven terug aan bod komen om de flow van patiënten, case record forms, toegangscontroles, ... duidelijk naar voor te brengen, voor alle belanghebbenden, waarbij er ook een consensus bereikt wordt over deze manier van werken! Zoals reeds aangegeven kan het MUGREG-project hier tot inspiratie dienen. Een architectuurontwikkeling kan niet starten vooraleer de vereiste business functies éénduidig op papier gezet zijn. Binnen de architectuurfase moeten er een aantal gesprekken plaatsvinden met de IT-cel van de FOD Volksgezondheid om tot een duidelijk inzicht te komen van de technische mogelijkheden en beperkingen. Een gesprek met de IT-ploeg die instond (zowel functioneel als technisch) voor de realisatie van het MUGREG-project strekt tot de aanbeveling. Inschattingen: 1. Architectuurstudie: Wat: gesprekken met de IT-cel van de FOD + opstellen voorstel architectuur geschat aantal mandagen: 10 dagen 2. Procesanalyse: Wat: gedetailleerde beschrijving van de gewenste processen in de diverse instellingen en op de FOD Volksgezondheid: Bestandsnaam: del.nl.20080103.fod.ontwikkeling van een registratie en opvolgingssysteem.doc HICT nv | Ezelstraat 69 | 8000 Brugge | Belgium | RPR/RPM: 0866 039 556

l © HICT nv


geschat aantal mandagen: 15 dagen 3. Ontwikkeling functionaliteitendraaiboek: Wat: vertaling van de gewenste processen naar functionaliteiten binnen de applicatie a. Uitwerken gebruikersinterface b. Uitwerken test en acceptatie aanpak geschat aantal mandagen: 15 dagen 4. Opmaken gedetailleerd plan van aanpak, risicobeheersingplan: geschat aantal mandagen: 10 dagen 5. Algemene coördinatie en projectmanagement: geschat aantal mandagen: 10 dagen Totaal aantal mandagen: 60 dagen

De kracht van het platform zou pas maximaal benut worden indien ook andere patiënten met een niet aangeboren hersenletsels longitudinaal kunnen worden opgevolgd. Een zorgregistratienetwerk zou een meerwaarde kunnen geven voor de patiënten met een dergelijke zware zorgbehoevenheid, die bij gebrek aan mantelzorg aangewezen zijn op residentiële zorg. We denken hierbij initiëel aan: o Patiënten met een cerebro vasculair accident o Patiënten met een traumatisch hersenletsel (‘traumatic brain injury’) Het is belangrijk om eventuele knelpunten bij deze patiëntengroep in kaart te kunnen brengen en eventueel te kunnen koppelen aan indicatoren van zorgbehoefte, waarbij dit longitudinaal zou kunnen worden opgevolgd.


l © HICT nv


8

Addendum

Overzicht meegeleverde werkdocumenten: DEL.HICT.NL.Presentatie 3 december.v1 DEL.HICT.NL.Presentatie 4 februari.v1


l © HICT nv

Ontwikkeling van een gestandaardiseerd

Recommend Documents