Belang van de levenscyclus
Elke fase kent onderwerpen die op dat moment van toepassing zijn, zoals het opstellen van het Pakket van Eisen tijdens de fase verwerving. Ook zijn er onderwerpen die spelen over de gehele levenscyclus, zoals risicomanagement en Taken, Bevoegdheden en Verantwoordelijkheden. Er zijn ook onderwerpen die meerdere keren in de levenscyclus voorkomen, zoals de test- en vrijgaveprocedure. We bespreken hier de hele levenscyclus en de bijbehorende onderwerpen in het kort. In hoofdstuk 4 gaan we nader in op specifieke vragen rondom deze onderwerpen. Figuur 2.1 geeft een goed overzicht van de verschillende fasen en de bijbehorende onderwerpen die in deze Praktijkgids aan bod komen.
In het Convenant vallen verwerving en ingebruikname samen onder de fase ‘invoering’. Wij hebben deze fase opgesplitst in twee delen omdat de fase van ingebruikname een aantal specifieke stappen vereist die in deze Praktijkgids nader worden uitgewerkt. Naast deze vier fasen is het ook mogelijk dat een ziekenhuis zelf medische hulpmiddelen ontwikkelt. Als dit het geval is, begint de levenscyclus bij de fase ontwikkeling.
Het is belangrijk om te beseffen dat in de verschillende fasen van de levenscyclus er bij het implementeren van medische (informatie)technologie niet alleen afspraken moeten worden gemaakt over de techniek. Meestal wordt de technologie in een bestaand zorgproces binnen een bestaande organisatie ingezet en moet de technologie (samen-)werken met andere medische (informatie)systemen. Het is dan belangrijk dat de nieuwe informatietechnologie ook binnen deze bestaande architectuur functioneert. In de praktijk van informatiemodellen wordt dit ook wel interoperabiliteit genoemd. Een belangrijk model hiervoor is het interoperabiliteitsmodel van Nictiz, zie figuur 2.2. Hierin zijn de verschillende lagen weergegeven van heel abstract (wetgeving) tot de fysieke componenten (infrastructuur). Dit model is ook het uitgangspunt voor samenwerking tussen verschillende organisaties, maar dat onderwerp valt buiten de scope van deze gids.
De kern van de Praktijkgids is dat er op de verschillende lagen afspraken moeten worden gemaakt voor de implementatie van medische informatietechnologie.
Overkoepelende processen
Sommige processen zijn tijdens de hele levenscyclus van belang: Risicomanagement, Taken, Bevoegdheden en Verantwoordelijkheden, Wet- en regelgeving en Samenwerken in de keten. Hieronder staan ze kort beschreven. Zoals in het interoperabiliteitsmodel te zien is, zijn deze processen ook overkoepelend over de
verschillende lagen.
Risicomanagement
Onder risicomanagement verstaan we beleid gericht op risicobeheersing, waarbij de veiligheid van patiënten, zorgverleners en bezoekers zo veel mogelijk wordt nagestreefd. Deze definitie impliceert dat zekerheid in de strikte, risicovrije betekenis niet bestaat; het lukt lang niet altijd alle risico’s te voorzien.
Risicomanagement van medische informatietechnologie wordt door het Convenant zelfs gedurende de gehele levenscyclus voorgeschreven. Daarnaast wordt risicomanagement ook aangeraden vanuit normen en richtlijnen zoals de IEC 80001 (IEC 80001-1 Application of risk management for IT networks incorporating medical devices IEC 80001-2-1 Step-by-step risk management of medical IT-networks) en IEC 80002-1. Vaak wordt aangeraden om risicomanagement volgens de ISO 14971 uit te voeren. Naast deze richtlijnen zijn er ook praktijkrichtlijnen of praktijkgidsen zoals de Leidraad NIKP, Nieuwe Interventies in de Klinische Praktijk ,de praktijkgids Risicomanagement Medische Technologie van VMSzorg en het WINT2.0 rapport vanuit de Koepel MT over Risicomanagement ten behoeve van veilig toepassen van medische hulpmiddelen.
In Praktijkvraag 3 beschrijven we welke methodieken van risicoanalyses er zijn, wat de belangrijkste risico’s zijn waarmee men rekening moet houden en hoe men die zo klein mogelijk kan houden.
Taken, Bevoegdheden en Verantwoordelijkheden
Om medische hulpmiddelen veilig toe te passen gedurende de gehele levenscyclus is het noodzakelijk om de Taken (T) Bevoegdheden (B) en Verantwoordelijkheden (V) op een duidelijke manier te beschrijven en binnen de organisatie bij de verschillende actoren te beleggen. In Praktijkvraag 4 komen verschillende methodieken om dit te doen aan bod, inclusief voorbeelden.
Wet- en regelgeving
Er is heel veel wet- en regelgeving die van belang is tijdens de levenscyclus van medische informatietechnologie. De belangrijkste is de Wet op de medische hulpmiddelen. Deze beschrijft wanneer iets een medisch hulpmiddel is en waaraan dit minimaal moet voldoen. Daarnaast zijn er nog normen op bijvoorbeeld het gebied van risicomanagement, het ontwikkelen van software en databeveiliging die van belang zijn voor medische informatietechnologie.
Samenwerken in de keten
In het Toetsingskader e-health is uitgebreid aandacht voor het samenwerken in een netwerk en het elektronisch vastleggen en uitwisselen van gegevens. Het is van belang dat je als zorgaanbieder weet welke gegevensbehoefte er is binnen een zorgketen (samenwerkingstraject), met name bij overdrachtsmomenten. De IGJ stelt hiervoor in haar toetsingskader dat dit ook aantoonbaar moet zijn, bijvoorbeeld door beleid of een architectuur voor elektronische gegevensuitwisseling en bijbehorende platformen/standaarden.
Voor belangrijke gegevensstromen, bijvoorbeeld het regionale medicatieproces, moet in gezamenlijkheid worden opgetrokken binnen de regio voor de keuze van een platform en/of gebruikte standaarden. Daarnaast moet er ook aandacht zijn voor evaluatie van de benodigde gegevens binnen het samenwerkingstraject, bijvoorbeeld door periodiek overleg.
Het beleid en procedures voor het elektronisch uitwisselen van gegevens moet schriftelijk worden vastgelegd, waar ook expliciete toestemming van een patiënt onderdeel van is voordat gegevens aan derden beschikbaar kunnen worden gesteld. Deze schriftelijke afspraken moeten ook weer periodiek worden geëvalueerd.
Fase 1A: Ontwikkeling
Sommige ziekenhuizen ontwikkelen in eigen beheer medische informatietechnologie die onder de definitie van medisch hulpmiddel valt. Vaak worden deze producten alleen binnen de eigen instelling gebruikt, soms worden deze echter ook (al dan niet tegen betaling) aan andere instellingen ter beschikking gesteld.
Als dit laatste het geval is, is het ziekenhuis fabrikant geworden en geldt de daarbij behorende wet- en regelgeving. Voordat een ziekenhuis start met zelfbouw moet men eerst goed afwegen of het noodzakelijk is om zelf te ontwikkelen. Is er niet ook een commercieel alternatief voor handen? Vanaf 26 mei 2020 (de ingangsdatum van de nieuwe MDR), respectievelijk 26 mei 2022 voor IVD medische hulpmiddelen, mag zelf ontwikkelen alleen nog als aangetoond kan worden dat er geen product op de markt is dat voldoet aan de gestelde eisen.
Ongeacht de toepassing is de kwaliteit van het geleverde product belangrijk. Om een zeker kwaliteitsniveau te garanderen, bespreken we in Praktijkvraag 1 welke stappen doorlopen kunnen worden om zelf software veilig te ontwikkelen. In Praktijkvraag 2 en Praktijkvraag 8 komt ook de relevante wet- en regelgeving aan bod.
In het kort komt het zelfbouwproces op de volgende stappen neer. Na een marktonderzoek, waaruit de rechtvaardiging voor zelfbouw volgt, wordt een ontwikkelplan geschreven dat alle facetten van het ontwikkeltraject beschrijft. Hierna volgt het programma van wensen en eisen, waarin alle eisen voor het te bouwen systeem worden verzameld. Dit wordt gevolgd door de ontwerpfase, die afhankelijk van de risicoklasse van het te bouwen systeem uit één of meerdere stappen kan bestaan, zoals architectuur en gedetailleerd design. Zie hiervoor de paragraaf over ingebruikname.
Fase 1B: Verwerving
Verwerving bevat alle acties voor het, al dan niet met behulp van een overeenkomst, ter beschikking krijgen van een medisch hulpmiddel. Er zijn diverse vormen van verwerving zoals aanschaf, lease, huur, (bruik-)leen, consignatie, proefplaatsing en zichtzending.
De verwervingsfase start met de behoefte van een gebruiker om voor een bepaalde toepassing medische informatietechnologie aan te schaffen. Daarbij levert de aanvrager een onderbouwing met nut en noodzaak van de beoogde verwerving. We gaan er voor deze Praktijkgids vanuit dat er toestemming is om de beoogde medische informatietechnologie te verwerven. De voorbereiding van de verwerving kan dus starten. De documenten die opgesteld worden tijdens de verwervingsfase moeten vastgelegd worden in het productdossier (convenant MT).
De belangrijkste onderdelen van de verwervingsfase zijn het opstellen van een Pakket van Eisen (PvE), prospectieve risicoanalyse, cybersecurity, het IT infrastructuurontwerp en de beheerafspraken.
Deze onderdelen worden hieronder kort toegelicht.
Pakket van Eisen
Bij iedere verwerving van medische informatietechnologie is het noodzakelijk om een Pakket van Eisen (PvE) op te stellen. Een PvE heeft drie doelen. Allereerst zorgt het ervoor dat eisen en wensen van de diverse betrokken partijen duidelijk zijn en op elkaar afgestemd worden. Daarnaast wordt het gebruikt voor een leveranciersselectie: welke leverancier voldoet het beste aan het opgestelde PvE? Ten derde kan het door de leverancier ingevulde PvE gebruikt worden als onderdeel van het latere koopcontract en een eventuele onderhoudsovereenkomst, waarbij een deel van de afspraken vastligt.
Binnen het ziekenhuis moeten goede afspraken zijn wie er verantwoordelijk is voor het opstellen van het PvE. Om een goed PvE op te stellen is er een multidisciplinaire groep nodig. Bij het opstellen van het PvE is het belangrijk om een goede afweging te maken tussen algemene en specifieke eisen. Bij te algemene eisen zullen alle leveranciers voldoen, bij te specifieke eisen kan het voorkomen dat veel leveranciers afvallen. Eén van de ontwikkelingen binnen het opstellen van een PvE is het maken van een functioneel PvE in plaats van een opsomming van eisen en wensen. Hiermee wordt bedoeld dat vanuit het ziekenhuis de functionele wensen en eisen op papier gezet worden. Zoals: voor welke toepassing is de medische informatietechnologie bedoeld? Op welke afdeling wordt het ingezet? En welke processen moeten ermee ondersteund worden?
Dit biedt meer vrijheid aan de leverancier om aan te bieden wat zij denken dat bij het ziekenhuis past.
Bij het opstellen van de eisen is het zinvol om na te gaan of de afspraken op alle lagen van het Interoperabiliteitsmodel (figuur 2.2) zijn verwoord. Denk bijvoorbeeld aan eisen omtrent het inpassen binnen het beleid van de organisatie, de bestaande workflow en het zorgproces, maar ook eisen in relatie tot bijvoorbeeld de applicatiearchitectuur en bestaande technische infrastructuur.
Cybersecurity
Onder cybersecurity wordt verstaan het vrij zijn van gevaar of schade veroorzaakt door verstoring, uitval of misbruik van IT. Het gevaar of de schade door misbruik, verstoring of uitval kan bestaan uit beperking van de beschikbaarheid en betrouwbaarheid van de IT, schending van de vertrouwelijkheid van
de opgeslagen informatie of schade aan de integriteit van die informatie.
Om de cybersecurity goed te regelen is het noodzakelijk om in de verwervingsfase met de leverancier en de relevante afdelingen binnen het ziekenhuis goede afspraken te maken hoe de nieuwe medische informatietechnologie beveiligd kan worden. Denk hierbij bijvoorbeeld naast de IT-afdeling ook aan de security officer en de functionaris bescherming persoonsgegevens. Cybersecurity komt terug op alle lagen van het Interoperabiliteitsmodel (figuur 2.2) omdat het niet alleen technische maatregelen betreft maar bijvoorbeeld ook het beleid. Diverse wet- en regelgeving, zoals de Algemene verordening gegevensbescherming (AVG), eist van de ziekenhuizen dat ze de cybersecurity goed op orde hebben.
IT-infrastructuurontwerp
Waar in het verleden sprake was van fysiek gescheiden medische en niet-medische IT-netwerk(en), is in de afgelopen jaren een duidelijke trend waarneembaar waarbij ziekenhuizen er steeds meer voor kiezen om ook medische toepassingen gebruik te laten maken van het algemene IT-ziekenhuisnetwerk.
Een belangrijke voorwaarde om het standaardziekenhuisnetwerk te gebruiken voor medische toepassingen is het maken van goede afspraken tussen de afdelingen IT en Medische Techniek. Er is dan namelijk sprake van gedeelde verantwoordelijkheid voor de juiste werking van de keten. Dit is een onderwerp op de infrastructuurlaag van het Interoperabiliteitsmodel (figuur 2.2).
Voor de inrichting van de IT-infrastructuur moeten in de verwervingsfase goede afspraken gemaakt worden met de leverancier. Welke eisen stelt deze aan de infrastructuur, en kan het ziekenhuis daaraan voldoen bij de inrichting van bijvoorbeeld VLAN en wifi-infrastructuur?
Beheerafspraken
Om medische informatietechnologie veilig toe te passen gedurende de gehele levenscyclus is het noodzakelijk om tijdens de verwervingsfase de Taken (T) Bevoegdheden (B) en Verantwoordelijkheden (V) op een duidelijke manier te beschrijven. TBV moeten intern bij de verschillende actoren belegd worden en extern bij de leverancier. Dit laatste kan bijvoorbeeld met behulp van een Standaard Service Overeenkomst (SSO) van de WIBAZ, of met een SLA. Een SLA (Service Level Agreement) is een overeenkomst tussen een opdrachtgever en een leverancier (intern of extern) waarin afspraken worden opgenomen over de diensten of producten die een leverancier aan de opdrachtgever levert, met welk kwaliteitsniveau en tegen welke kosten.
De afspraken moeten zodanig zijn ingeregeld dat er tijdens het gebruiksproces een goede storingsprocedure en wijzigingsproces zijn ingericht. Vanuit de MDR gezien, moet de leverancier een werkende post market surveillance en een recall procedure hebben.
Voor een goed service management is het van belang om de gemaakte afspraken regelmatig te evalueren aan de hand van rapportages over de geleverde prestaties. De beheerafspraken worden gemaakt op de laag Organisatiebeleid van het Interoperabiliteitsmodel (figuur 2.2).
Fase 2: Ingebruikname
De fase ingebruikname loopt vanaf het moment van de verwerving tot de klinische ingebruikname. In deze fase worden alle voorbereidingen voor de gebruiksfase getroffen. Zo moet het product getest worden en moeten de gebruikers en beheerders getraind worden. Pas daarna volgt uiteindelijk de vrijgave.
OTAP
Om het product te kunnen testen en te valideren wordt vaak een OTAP-omgeving ingericht. Dit acroniem staat voor:
• Ontwikkelomgeving (meestal alleen bij de fabrikant)
• Testomgeving (onderdeel van de initiële installatie)
• Acceptatieomgeving (een recente kopie van de Productieomgeving inclusief de koppelingen)
• Productieomgeving (de uiteindelijke productieomgeving)
Deze omgevingen zijn virtueel en/of fysiek van elkaar gescheiden. Voor validatie/verificatie van medische systemen is het noodzakelijk om naast de productie (klinisch gebruik) ook een acceptatieomgeving beschikbaar te hebben.
Het is belangrijk dat de acceptatieomgeving een representatieve kopie van de productieomgeving is. Denk dus ook aan de gekoppelde randapparatuur en/of de interne en externe datakoppelingen.
Bij het inrichten van een OTAP-omgeving hoort ook een wijzigingsproces om gedurende de levensduur van de medische informatietechnologie, de kwaliteit goed te borgen. De geldende afspraken op de applicatie- en infrastructuurlaag van het Interoperabiliteitsmodel (figuur 2.2) moeten daarbij in acht worden genomen.
Vrijgaveprocedure
Wanneer het installeren, configureren, testen en valideren met succes is afgerond volgt de vrijgaveprocedure. De vrijgave kan onderverdeeld worden in een technische en functionele vrijgave. De technische vrijgave geeft aan dat de medische informatietechnologie technisch functioneert en vrijgegeven wordt door de beheerder/ deskundige aan de gebruiker. De functionele vrijgave wordt bij voorkeur door een gebruiker gedaan en geeft aan dat de technologie klinisch gebruikt mag worden. Op het moment van klinische ingebruikname moet de gebruiker dus ook getraind zijn.
Vrijgave vindt plaats op drie verschillende momenten binnen de levenscyclus: bij de ingebruikname van nieuwe technologie en in de gebruiksfase na (preventief en correctief) onderhoud en na het doorvoeren van wijzigingen.
Voor de formele overdracht van technologie aan de afdeling/gebruiker kan men een standaard overdrachtsformulier gebruiken (bijlage II).
Fase 3: Gebruik
In deze fase is de medische informatietechnologie in gebruik genomen. Deze fase omvat periodiek en correctief onderhoud, modificaties, bij- en nascholing, evaluaties en recall- en veiligheidsmeldingen.
Wijzigingsbeheer of modificaties?
Net als bij de beheerafspraken in de verwervingsfase moeten op de beleidslaag van het Interoperabiliteismodel (figuur 2.2) ook in de gebruiksfase goede afspraken worden gemaakt. De leverancier van software kan periodiek nieuwe versies van zijn software uitbrengen. Dit kunnen versies met vernieuwde functionaliteit zijn (upgrades), maar ook met oplossingen voor (risicovolle) problemen(updates). Een leverancier kan in dat geval de gebruiker verplichten de nieuwe versie van de software in gebruik te nemen. Bij een grote upgrade wordt er vanuit deze fase weer teruggegaan naar de verwervings- of ingebruiknamefase. Naar welke fase wordt teruggegaan hangt van een aantal zaken af.
Als er een afweging gemaakt moet worden of de upgrade wel of niet uitgevoerd moet worden is het verstandig om terug te gaan naar de verwervingsfase, waarbij wederom alle interne partijen in het ziekenhuis (gebruikers en beheerorganisatie) betrokken worden. Er kan dan op basis van een PvE, de release notes van het product en een risicoanalyse een keuze gemaakt worden voor wel of niet
implementeren van de upgrade. Als het een verplichte upgrade is, wordt alleen de fase ingebruikname doorlopen. In het geval van zelfbouw moet men teruggaan naar de ontwikkelfase.
De aangepaste versie moet in de verschillende beschikbare OTAP-omgevingen worden geïmplementeerd en getest. Deze testen kunnen zowel technisch als functioneel van aard zijn.
Functioneel gaat het dan om de werking en het gebruik van de software zelf. Technisch moet worden gedacht aan het testen van koppelingen en de integratie met andere systemen, aan performance-testen en veiligheidstesten.
Tijdens het uitvoeren van een wijziging liggen de verantwoordelijkheden bij de betrokkenen zoals is vastgelegd in de diverse interne beleidsstukken of overeenkomsten (TBV, SLA, SSO). Deze zijn zo wel op in- als externe samenwerkingen gericht.
Vrijgaveprocedure
Afhankelijk van de impact van het periodiek of correctief onderhoud inclusief eventuele modificaties, kan men kiezen voor een beperkte set van technische en functionele testen ten opzichte van de testen bij ingebruikname. De vrijgave zelf vindt op dezelfde manier plaats als in de fase van ingebruikname, ook weer met de tweedeling in technische en functionele vrijgave.
Datalek
Sinds 1 januari 2016 geldt de meldplicht datalekken. Dit houdt in dat een organisatie zoals het ziekenhuis direct een melding moet doen bij de Autoriteit Persoonsgegevens zodra er een ernstig datalek is. Het gaat dan om tot een persoon herleidbare data. De meldplicht datalekken is ook van toepassing bij medische informatietechnologie. Rondom medische informatietechnologie hebben we voornamelijk te maken met patiëntgegevens en deze data mogen niet in handen van onbevoegde personen vallen.
Fase 4: Afstoting
Tijdens de afstotingsfase wordt de medische informatietechnologie afgekeurd, buiten gebruik gesteld en afgevoerd. Hierbij zijn een aantal zaken van belang:
- buiten bedrijf stellen software;
- veiligstellen data, via conversie of via data warehouse;
- verwijderen data;
- beëindigen servicecontract en/of licentieovereenkomst.
Bij afvoer van medische informatietechnologie moeten de data die daarop staan veiliggesteld worden en daarna verwijderd worden van het apparaat. Ingeval de data niet verwijderd kunnen worden door het ziekenhuis zelf moet het ziekenhuis met de leverancier een vernietigingsverklaring opstellen en gezamenlijk ondertekenen. Daarmee wordt de verantwoordelijkheid om de patiëntgegevens te verwijderen overgedragen naar de leverancier. De afstoting is een voorbeeld van een onderwerp op onder andere de informatielaag van het Interoperabiliteitsmodel (figuur 2.2).
De daadwerkelijke afvoer valt buiten de scope van de Praktijkgids, maar kan worden opgenomen in een vernietigingsverklaring.