Inhoudsopgave

Voorbeelden uit de praktijk

Hoofdstuk 3

Voorbeelden uit de praktijk

Afhankelijk van de situatie kunnen we medische informatietechnologie indelen in vijf categorieën. In de praktijk blijkt deze indeling niet altijd eenduidig. We hebben daarom een aantal herkenbare praktijkvoorbeelden uitgewerkt waarmee we een groot deel van de categorieën beschrijven, maar we pretenderen hiermee niet om alles volledig afgedekt te hebben.

Categorieën en voorbeelden

Medische informatietechnologie als medisch hulpmiddel kan in de praktijk in verschillende categorieën worden onderverdeeld. In dit hoofdstuk hebben we voor elk van deze categorieën toegelicht hoe de medische informatietechnologie gedurende de levenscyclus veilig in de specialistische patiëntenzorg kan worden toegepast.

Het Convenant onderscheidt binnen de informatietechnologie drie categorieën. In deze Praktijkgids hanteren we de volgende onderverdeling met vijf categorieën:

  1. Embedded software
  2. Geïntegreerd medisch systeem (binnen één CE aangeboden door een leverancier)
  3. Softwareapplicatie (ook medische apps en Software as a Service)
  4. Medisch systeem
  5. Zelfbouw software

Afhankelijk van de situatie kunnen we medische informatietechnologie indelen in een van bovenstaande categorieën. In de praktijk blijkt het niet altijd eenduidig. Daarom hebben we hierna een aantal herkenbare praktijkvoorbeelden uitgewerkt waarmee een groot deel van de categorieën is beschreven, maar we pretenderen hiermee niet om alles volledig afgedekt te hebben. In de praktijk kunnen andere situaties/configuraties leiden tot discussie, maar hopelijk geven de voorbeelden voldoende richting en handvatten om de vragen te beantwoorden.

Elk praktijkvoorbeeld begint met een globale beschrijving, vervolgens belichten we de diverse overwegingen die in de praktijk gemaakt moeten worden. We sluiten elk praktijkvoorbeeld af met een casus vanuit de praktijk van een zorginstelling waarin we de aandachtspunten per fase in de levenscyclus van medische informatietechnologie concreet maken. Dit zijn dus slechts voorbeelden hoe dit in specifieke zorginstellingen is uitgewerkt.

 

We beschrijven in de voorbeelden de volgende aspecten:

  • Wet- en regelgeving
  • Systeem specificaties/PvE
  • Security
  • IT-infrastructuur
  • Beheerafspraken
  • Test- en vrijgaveprocedure
  • Wijzigingsbeheer
  • Afstotingsprocedure

Echo

Echotoestellen worden toegepast voor de diagnostiek in bijvoorbeeld de cardiologie, verloskunde en radiologie. De ultrageluidtechnologie heeft de afgelopen decennia een grote ontwikkeling doorgemaakt, zo is inmiddels het maken van real-time 3D kleurenbeelden mogelijk. Vanwege deze ontwikkelingen is er een steeds grotere rol voor informatietechnologie in deze toepassing.

Het besturingssysteem dat in het echotoestel wordt toegepast is een embedded Operating System (OS). Dit besturingssysteem dient primair als applicatieplatform voor de software die zorgt voor het aansturen van het echotoestel en secundair voor de communicatie van de patiëntinformatie.

Het echotoestel is inclusief het besturingssysteem CE-gemarkeerd. Veiligheidsupdates worden geïnstalleerd nadat ze door de leverancier zijn gevalideerd. Soms betekent dit dat antivirus en security-patches voor het besturingssysteem helemaal niet worden doorgevoerd omdat dit consequenties kan

hebben voor de CE-markering. In dat geval zijn dit soort systemen vaak slecht beveiligd tegen invloeden van buitenaf zoals virussen en hacks.

 

Overwegingen

De apparatuur wordt steeds minder in standalone opzet gebruikt, al kan vaak de eerste diagnostiek gedaan worden via het beeldscherm en de functionaliteiten van het echotoestel. Echotoestellen worden vaak aan het IT-netwerk van het ziekenhuis verbonden om werklijsten op te halen van het informatiesysteem waarin patiëntafspraken worden bijgehouden, en om beelden te versturen naar een Picture Archiving and Comunication System (PACS). Als we het echotoestel beschouwen hebben we dus te maken met een medisch apparaat met embedded OS en geïntegreerde software. Dit apparaat wordt vervolgens vaak gekoppeld aan het netwerk terwijl de beveiliging van het apparaat niet altijd up-to-date is.

 

In deze Praktijkgids richten we ons op de software, de data en de koppelingen aan systemen.

Tijdens de verwervingsfase van een echotoestel moet men in het Pakket van Eisen (PvE) aan een aantal punten zeker aandacht besteden. Eén daarvan is de gewenste koppelingen aan informatiesystemen en het communicatieprotocol dat daarvoor gebruikt moet worden. Ook moet men benoemen hoe omgegaan wordt met de gegenereerde data. Zoals: worden de data lokaal opgeslagen of direct opgestuurd naar het PACS? Hoe lang moeten de gegevens lokaal blijven staan en moeten ze gebufferd worden? Omdat het apparaat vaak aan het ziekenhuis-IT-netwerk gekoppeld wordt, is het van belang dat ook de aansluitvoorwaarden van dit netwerk meegenomen worden in het PvE.

 

Er zijn diverse mogelijkheden om de echo aan informatiesystemen te koppelen. Dit kan via een dedicated verbinding zijn maar vaak wordt gekozen voor het IT-netwerk van het ziekenhuis dat vervolgens ingedeeld wordt in VLAN’s. Via een vast IP-adres of DHCP via het MAC-adres wordt het toestel in het juiste netwerksegment geplaatst. Dit kan voor een bedrade toepassing ook door een netwerkoutlet te koppelen aan het juiste VLAN. Het is afhankelijk van de mogelijkheden van het apparaat (zowel bedraad als draadloos), het standpunt van de leverancier en de voorkeur van de IT-afdeling van de organisatie welke koppelmethode wordt gebruikt.

 

Er moeten maatregelen genomen worden om een veilige IT-toepassing te garanderen. Dit kan door een up-to-date virusscanner te verlangen van de leverancier. Vaak is dit echter, in verband met de CE-markering, niet toegestaan. Voor de beveiliging kan het echotoestel aan het netwerk worden gekoppeld door deze in een VLAN te plaatsen die achter een firewall met IPS-functionaliteit (Intrusion Prevention System) gesitueerd is. Wel moet men rekening houden met andere bronnen van virussen, zoals het gebruik van usb-sticks. Het risico kan verkleind worden door gebruik van usb-sticks te verbieden en bijvoorbeeld de poorten fysiek af te dichten. Als iemand een usb-stick echt moet gebruiken, bijvoorbeeld tijdens onderhoud van het medische apparaat, dan moet de usb-stick op virussen gescand worden vóór toepassing op het apparaat. Dit kan men vastleggen in de afspraken die met de onderhoudspartij worden gemaakt.

 

Naast een adequate infrastructuur, en een adequate beveiliging van het apparaat, is het van belang dat wijzigingen aan de software op het apparaat of IT-infrastructuur via een wijzigingsprocedure lopen. Beoordeel eerst of de wijziging wenselijk of noodzakelijk is. Als dat het geval is en de wijziging wordt doorgevoerd, moet het apparaat na de wijziging functioneel getest en vrijgegeven worden. Belangrijk is om ook de koppelingen met informatiesystemen in de testen mee te nemen. Tijdens diverse stadia van de levenscyclus (bijvoorbeeld voor aanschaf, voor ingebruikname, voor het doorvoeren van wijzigingen) moeten de stakeholders de risico’s afwegen.

 

Klik hier voor een overzicht van de aandachtspunten per fase van de levenscyclus.

Figuur 3.1Echotoestel

Ergometrieopstelling

De traditionele 12-kanaals cardiografen die voor de inspanningscardiogrammen werden gebruikt zijn inmiddels vervangen door papierloze digitale systemen. Het inspanningscardiogram wordt nu doorgestuurd naar het elektronisch patiëntendossier. De cardiograaf is vervangen door een werkstation waarop een 10-kanaals-ECG-versterker, ergometerfiets, loopband en een automatische bloeddrukmeter zijn aangesloten. Het werkstation heeft een netwerkverbinding om de werklijsten op te halen en de inspanningsrapportage te versturen. Op het aangesloten scherm wordt het volledige 12-afleidingencardiogram plus ritmestrook weergegeven. Voor de bewaking van de patiënt tijdens de inspanningsoefeningen is dit onmisbaar. De bediening van de aangesloten medische apparatuur vindt ook plaats via het werkstation.

 

Overwegingen

De eerste overweging bij de aanschaf van dit systeem is de keuze voor een dedicated, door de leverancier geleverde, pc of een door het ziekenhuis beschikbaar gestelde pc. Soms heeft het ziekenhuis hier geen keuze in omdat de CE-certificering alleen geldt bij de geleverde opstelling van de leverancier. In andere gevallen stelt de leverancier eisen aan de door het ziekenhuis te leveren pc. Men kan dan

kiezen om bijvoorbeeld de ziekenhuisstandaard in te zetten.

 

Als het ziekenhuis er samen met de leverancier voor kiest om een dedicated pc van de leverancier te gebruiken, wordt het beheer van de pc bij dezelfde partij belegd als het beheer van de rest van de opstelling. De pc draait dus niet mee in Windows- en antivirussoftwareupdates die gecoördineerd worden in het ziekenhuis; dit wordt, altijd pas na validatie van deze updates, geregeld door de leverancier. Vaak zijn deze pc’s daardoor niet goed beveiligd waardoor de pc het beste achter een firewall met IPS-functionaliteit kan worden geplaatst als de koppeling aan het netwerk nodig is. Het is dan van belang dat het systeem wel aan de regels voldoet om in dit netwerksegment geplaatst te worden. Zo is vaak geen internetverbinding mogelijk en is het niet toegestaan usb-sticks op de pc te gebruiken.

Het voordeel is dat het beheer volledig bij de leverancier ligt en geen andere toepassingen op de pc de werking van het systeem kunnen beïnvloeden.

 

Als een ziekenhuis-pc is gekozen, beheert de ITafdeling van het ziekenhuis deze pc. Vervolgens moet bepaald worden of deze pc mee kan draaien in de Windows- en antivirussoftwareupdates.

Als dit het geval is, moeten deze wijzigingen vaak gevalideerd zijn door de leverancier, maar is het ook noodzakelijk dat het ziekenhuis bij elke wijziging de werking controleert. Als dit echter niet het geval is, wordt de pc vaak in een afgescheiden compartiment van het IT-netwerk (achter firewall met IPS-functionaliteit) geplaatst omdat de beveiliging niet gegarandeerd is. In dat laatste geval kan de pc enkel voor die specifieke opstelling worden gebruikt en kan verder geen gebruik worden gemaakt van andere applicaties en internet (of indien nodig enkel op basis van een whitelist met toegestane websites).

 

Omdat de pc in beide gevallen vaak niet afdoende beveiligd is, moet terughoudend worden gewerkt met usb-sticks zodat deze het apparaat niet kunnen besmetten. De usbpoorten kunnen niet afgeschermd worden omdat de sensoren vaak via usb aan de pc worden aangesloten. Daarom is het belangrijk om de gebruikers duidelijk te instrueren over het verbod om usb-sticks te gebruiken en dit in protocollen vast te leggen. Als iemand toch een usb-stick moet gebruiken, moet de usb-stick eerst gescand worden op virussen op een pc met up-to-date antivirussoftware.

 

Tijdens de verwervingsfase van een ergometrieopstelling moet men in het Pakket van Eisen (PvE) aan een aantal punten zeker aandacht besteden. Eén daarvan is de gewenste koppelingen aan informatiesystemen en het communicatieprotocol dat daarvoor gebruikt moet worden. Ook moet men benoemen hoe omgegaan wordt met de gegenereerde data. Zoals: worden de data lokaal opgeslagen of direct opgestuurd? Hoe lang moeten de gegevens lokaal blijven staan en moeten ze gebufferd worden? Omdat het apparaat vaak aan het IT-netwerk van het ziekenhuis gekoppeld moet worden, is het van belang dat ook de aansluitvoorwaarden van dit netwerk meegenomen worden in het PvE. Tijdens diverse stadia van de levenscyclus (bijvoorbeeld voor aanschaf, voor ingebruikname, voor het doorvoeren van wijzigingen) moeten de stakeholders de risico’s afwegen.

 

Klik hier voor een overzicht van de aandachtspunten per fase van de levenscyclus.

Figuur 3.2Ergometrieopstelling

PACS

Het Picture Archiving and Comunication System (PACS) is software die wordt gebruikt voor de verwerking, bewerking en beoordeling van beelden van verschillende beeldvormende modaliteiten, zoals SPECT, PET, CT en MRI.

Maar PACS-software kan ook voor specifieke specialismen worden ingezet. Bijvoorbeeld voor cardiologie, waarbij bewegende beelden van angiografiesystemen en echotoestellen worden opgeslagen als vervanger van de 35-millimeter filmprojector waarmee de hartfilmpjes van de angiografie opnamen werden bekeken.

Specialisten beoordelen de beelden op de werkstations met CE-gemarkeerde diagnostische schermen waarbij de functionaliteiten voor beeldbewerking en berekeningen onderdeel zijn van de PACS-software.

Het PACS is vaak als viewer geïntegreerd in een epd zodat de beelden onderdeel zijn van het dossier van een patiënt. Hierbij worden dan werklijsten voor modaliteiten (indirect) vanuit het epd gegenereerd op basis van de afspraken of orders die voor patiënten worden gemaakt.

 

Overwegingen

Op de markt is PACS-software in verschillende oplossingen te verkrijgen. Afhankelijk van de intended use van de leverancier wordt PACS-software geclassificeerd als een medisch hulpmiddel. Het kan bedoeld zijn om simpelweg beelden op te slaan en te versturen, dan is het PACS geen medisch hulpmiddel. Als het beeld echter ook bewerkt wordt voor kwaliteitsverbetering of analyse van bijvoorbeeld anatomische structuren voor een (automatische) diagnose, is er wel sprake van een medisch hulpmiddel. Als PACS-software wordt aangemerkt als medisch hulpmiddel dan moet deze conform Medical Device Directive 2.1/6 ook CE-gemarkeerd zijn.

 

Ook in de uitvoering kent een PACS verschillende oplossingen. De software kan draaien op een specifiek werkstation, er kan een cloudoplossing gebruikt worden of het kan draaien als client-server applicatie. In alle gevallen is hier sprake van software die via het IT-netwerk is verbonden met beeldvormende modaliteiten en/of andere software. Wanneer de software als een cloudoplossing (of als Software as a Service) wordt aangeboden, vergt dat specifiek op deze situatie gerichte beveiligingsmaatregelen. De leverancier moet zorgen voor een passende IT-infrastructuur en informatiebeveiliging en hij moet in

overeenkomsten met afnemers garanties bieden over het op peil houden hiervan.

 

Daarnaast moet een keuze gemaakt worden voor de inrichting van het beheer. Dit kan centraal worden ingericht of juist decentraal, waarbij eventueel gebruik kan worden gemaakt van key-users.

De opslag van de beelden kan volgens verschillende architecturen worden gerealiseerd: Direct Attached Storage (DAS), waarbij de opslag direct aan slechts één server is verbonden; Network Attached Storage (NAS) en Storage Area Network (SAN) waarbij gebruik wordt gemaakt van netwerkoplossingen.

Als men voor een netwerkoplossing kiest, moeten hiervoor aparte eisen worden opgenomen in het PvE. Ook moeten er eisen worden opgenomen voor de snelheid van de verschillende opslagtypen (hiërarchie): recente beelden moeten sneller beschikbaar zijn dan beelden van een paar jaar geleden.

Er moeten daarnaast functionele eisen worden opgesteld over communicatiestandaarden, standaarden voor opslag en eventuele integratieprofielen. De software moet gebruikt kunnen worden met alle aanwezige merken en modellen beeldvormende modaliteiten, het bestaande ziekenhuisinformatiesysteem en eventueel het bestaande PACS.

Er moeten, gezien het geïntegreerde karakter van de software, uitgebreide integratietesten worden uitgevoerd voordat men het PACS kan gebruiken. Koppelingen met modaliteiten en werklijstbrokers en communicatie met andere software moeten worden getest. Zodra de software in gebruik is genomen mogen toekomstige wijzingen in de software niet leiden tot beperkingen in functionaliteit. Hiertoe moeten voorafgaand aan wijzigingen impact en risico’s in kaart worden gebracht.

Tijdens diverse stadia van de levenscyclus (bijvoorbeeld voor verwerving, voor ingebruikname, voor het doorvoeren van wijzigingen) moeten de stakeholders de risico’s afwegen.

De bewaartermijn van persoonsgegevens moet in acht worden genomen, waarbij de organisatie zelf verantwoordelijk is voor het bepalen van deze termijn. Identificeerbare persoonsgegevens mogen alleen worden opgeslagen zo lang als nodig voor het doel waarvoor ze dienen. Data kan geanonimiseerd

langer worden bewaard, dit geldt ook voor data voor algemeen belang, wetenschappelijk of historisch onderzoek of statistische doeleinden.

 

Klik hier voor een overzicht van de aandachtspunten per fase van de levenscyclus.

Figuur 3.3PACS

Total body irradiation software (zelfbouw)

Als voorbeeld van zelfbouw standalone software nemen we een applicatie voor de dosisberekening bij Total Body Irradiation (TBI). Zelfbouw van dit soort applicaties is op radiotherapieafdelingen niet ongewoon.

Bij een TBI-behandeling wordt de gehele patiënt tot een bepaalde dosis bestraald, met uitzondering van enkele organen zoals longen en/of nieren. Omdat bij deze behandeling de gehele patiënt bestraald moet worden, wijkt de geometrie nogal af van de standaardbestralingen waarbij slechts een klein gedeelte van de patiënt (alleen de tumor) wordt bestraald. Daarom is het vaak lastig om met de standaard radiotherapie-planningssystemen de dosisplanning voor deze behandelingen te doen.

Voorheen werden tabellenboeken gebruikt om de benodigde machineparameters op te zoeken voor een patiënt. Deze parameters hangen met name af van de doorsnede van de patiënt en de geometrie van de opstelling (zoals de afstand tot de bron). Tegenwoordig zijn deze tabellen vaak vervangen door software die op basis van input de juiste waarden uit tabellen en grafieken haalt en eventueel nog schaalt naar bijvoorbeeld de juiste afstand.

 

Overwegingen

Als de software alleen dient voor eigen gebruik, wordt degene die de software maakt/levert volgens de Europese Medical Device Regulation niet als leverancier gezien en is CE-certificering niet nodig. Degene die de software ontwikkelt is vrij in de keuze voor de softwareontwikkeltechniek, bijvoorbeeld Scrum, maar moet wel voldoen aan diverse zaken die ook voor externe leveranciers gelden conform de IEC 62304. In deze norm is de levenscyclus voor softwareontwikkeling beschreven. Ook in het geval van wijzigingen aan de software worden aan de ontwikkelaar van de software binnen de eigen organisatie dezelfde vragen gesteld als aan een externe leverancier. We raden daarom ook aan om je als ontwikkelaar te conformeren aan dezelfde verplichtingen die gelden voor een leverancier, waaronder bijvoorbeeld ook het bepalen van de risicoklasse van de software.

De te ontwikkelen software moet worden geclassificeerd als klasse A, B of C conform IEC 62304, afhankelijk van het risico op schade voor de patiënt, gebruiker of enig ander persoon waaraan het falen van de software kan bijdragen. Als er geen risico is op schade aan personen wordt de software geclassificeerd als A. Als er alleen risico is van niet serieuze gezondheidsschade wordt de software geclassificeerd als B. Bij risico op serieuze gezondheidsschade of overlijden van personen wordt de software geclassificeerd als C.

Aan de beslissing tot zelfbouw van een TBI-programma ligt een multidisciplinaire risicoanalyse ten grondslag voor het gebruik van de standaard radiotherapieplanningssoftware voor deze behandeling. De grootste bij deze risicoanalyse gevonden risico’s worden met behulp van de zelfgebouwde applicatie afgedekt. Voor de zelfbouwapplicatie zelf moet een risicoanalyse uitgevoerd worden die toegespitst is op de risico’s van het gebruik van de applicatie. Denk hierbij aan risico’s van foutieve invoer door de gebruiker, het niet up-to-date zijn van meetdata en foutieve extrapolatie van tabellen. Men moet proberen om alle mogelijke situaties in kaart te brengen waarin de applicatie kan falen. Vervolgens moet men deze situaties zo netjes en veilig mogelijk voorkomen. Duidelijke foutmeldingen voor de gebruiker zijn hierbij belangrijk. De bij deze risicoanalyse gevonden risico’s moeten worden afgedekt door diverse maatregelen, zoals het inbouwen van extra controles op de invoer, het opnemen van testscenario’s in het testplan en opnemen van bepaalde controles in de werkinstructies. Het risicomanagementproces moet gedurende het gehele ontwikkeltraject worden gevolgd.

 

Software of unknown provenance (SOUP) die wordt gebruikt door de zelfontwikkelde applicatie kan in het geval van softwareupdates nieuwe risico’s introduceren. Voor het TBI-programma worden de berekeningen bijvoorbeeld met een bepaalde versie van Matlab uitgevoerd. In het geval van een nieuwe Matlab-versie moet je als ontwikkelaar nagaan of er nieuwe risico’s ontstaan in de berekeningen en of al bekende risico’s en maatregelen nog actueel zijn. De risico’s van de software en bijbehorende SOUP-versies kunnen in een commercieel beheersysteem, maar bijvoorbeeld ook een Excelwerkblad worden opgeslagen.

 

Om gebruikers voor de TBI-software te autoriseren moet een keuze gemaakt worden uit de beschikbare mogelijkheden. Er kan bijvoorbeeld een eigen gebruikersdatabase opgezet worden waarin verschillende rollen van gebruikers worden vastgelegd. Maar om aan te sluiten bij al bestaande oplossingen, kan autorisatie verlopen via een standaardprotocol (LDAP/Active Directory). Door deze standaard te gebruiken kunnen gebruikers inloggen met hun netwerk-/werkplek-gebruikersnaam en wachtwoord. De gebruikersnamen en wachtwoorden hoeven hierdoor ook niet binnen de zelfbouwapplicatie opgeslagen te worden, wat ook weer een extra risico zou introduceren. De gebruikersauthenticatie via LDAP is niet zelfgeschreven, maar er wordt een standaardbibliotheek voor gebruikt. Het gebruik van veelgebruikte en goed geteste bibliotheken verkleint de kans op fouten ten opzichte van volledige zelfbouw.

In het ontwerp is gestreefd naar zo min mogelijk afhankelijkheden van andere systemen. In dit voorbeeld van het TBIprogramma was dit niet zo moeilijk gezien de geringe complexiteit van het op te lossen probleem. Bij eventuele interactie met andere databases of een PACS moet ervoor worden gezorgd dat de uitgevoerde queries als gevolg van foutieve invoer niet te belastend of schadelijk kunnen zijn voor deze systemen.

 

Alle data binnen de applicatie worden op het netwerk op gedocumenteerde locaties opgeslagen. Dit voorkomt dat er patiëntgegevens verspreid worden over allerlei computers. Het is bovendien duidelijk welke locaties meegenomen moeten worden in de back-up en ook tijdens de afvoerfase om de data veilig te stellen nadat de software buiten gebruik wordt gesteld.

 

Bij voorkeur wordt al tijdens het ontwerp en de implementatie rekening gehouden met de eventueel noodzakelijke toegankelijkheid van de data na afvoer van de software. Hiervoor kan bijvoorbeeld het ontwerp modulair worden opgezet (raadpleging los van verwerking) of gekozen worden voor opslag in standaardformaten zoals pdf en DICOM.

 

De bewaartermijn van persoonsgegevens moet in acht worden genomen, waarbij de organisatie zelf verantwoordelijk is voor het bepalen van deze termijn. Identificeerbare persoonsgegevens mogen alleen worden opgeslagen zolang als nodig voor het doel waarvoor ze dienen. Geanonimiseerde data kunnen langer worden bewaard. Dit geldt ook voor data ten behoeve van algemeen belang, wetenschappelijk of historisch onderzoek of statistische doeleinden.

 

Klik hier voor een overzicht van de aandachtspunten per fase van de levenscyclus.

Alarmering: VOS-MOS-MA

De komende jaren zal de trend in de zorginstellingen doorzetten dat minder zorgprofessionals complexere zorg moeten verlenen. Hiernaast kiezen de zorginstellingen steeds vaker voor éénpersoonskamers vanwege privacy en infectiepreventie. Deze veranderingen hebben veel impact op de observatie en bewaking van de patiënten. Het overzicht over de afdeling wordt moelijker. De technologische ontwikkelingen maken het mogelijk om de alarmen door te sturen naar een draadloze ontvanger/handheld waardoor de observatie niet meer achter de centraalpost hoeft plaats te vinden. De koppeling van het medisch apparaat met een alarmfunctie (bijvoorbeeld fysiologische bewakingsmonitoren) met een oproepsysteem voor de draadloze ontvangers moet voldoen aan de vigerende wetgeving en richtlijnen voor de medische hulpmiddelen en informatiebeveiliging. Het medisch apparaat, de server die de geselecteerde alarmen verzendt en het softwareprogramma in de ontvanger moeten CE-gemarkeerd zijn als medisch hulpmiddel.

 

We houden hier de volgende terminologie aan:

- VOS: Verpleegkundig Oproepsysteem → patiëntoproepen, assistentoproepen, serviceoproepen en reanimatieoproepen.

- MOS: Medisch Oproepsysteem → medische apparatuur gekoppeld via maak-/

breekverbinding aan een alarmsysteem met draagbare devices.

- MA: Medische Alarmeringssysteem → alarmen met context informatie vanuit medische apparatuur worden doorgestuurd naar draagbare devices.

 

Overwegingen

Voor dit systeem moet men kijken naar de risico’s in het gehele systeem en de inzet van het systeem in het zorgproces. Een aantal risico’s zijn specifiek van toepassing:

  1. onopgemerkt blijven van verstoring ergens in de systeemketen;
  2. invloeden van buitenaf zoals hacks, virussen;
  3. interferentie van systemen, bijvoorbeeld verstoringen van wifi;
  4. afhankelijkheden in de keten (systeem is zo sterk als de zwakste schakel);
  5. gebruikersfouten, bijvoorbeeld bij koppelingen;
  6. informatie-overload van gebruikers;
  7. complexiteit van storingen met mogelijk lange doorlooptijd tot gevolg;
  8. infectiegevaar door inzet van niet schone IT-apparatuur in directe zorgomgeving van kwetsbare patiënten, zoals neonaten.

 

Dit zijn een aantal toprisico’s rondom het gebruik van medische oproepsystemen. Het is vooral belangrijk om met elkaar te bespreken wat gedaan moet worden als componenten in de keten niet goed werken. Hoe weet de zorgprofessional dat er een verstoring is in de keten? Welke noodprocedure geldt zodra dit gebeurt? En waar moet de zorgprofessional de verstoring melden?

Een goede en onoverkomelijke basis om de veiligheid van het systeem te borgen, is een uitgebreide multidisciplinaire risicoanalyse voor het medische alarmeringssysteem waarbij alle stakeholders, inclusief gebruikers, betrokken zijn.

 

Uit risicoanalyses komt direct naar voren dat de keten bestaat uit diverse schakels waarbij de schakels aan de regelgeving moeten voldoen en veilig moeten zijn, maar ook dat de gehele keten als systeem veilig moet zijn. Een dergelijk ketensysteem kan men in zijn geheel laten certificeren door een notified body. Dit kost echter wel veel tijd en geld. Bovendien is het moeilijk om wijzigingen in een ketengecertificeerd systeem door te voeren. Als men niet kiest voor een officieel ketencertificaat moeten het ziekenhuis en de leveranciers wel adequate veiligheidsmaatregelen nemen. Zo is een wijzigingsproces waarin alle stakeholders betrokken worden noodzakelijk. Daarnaast is bijvoorbeeld ketenmonitoring en logging van alarmen belangrijk. Het wijzigingsproces wordt verder besproken in Praktijkvraag 8. Denk bij systemen als medische alarmeringssystemen aan hoe de componenten elkaar beïnvloeden. Zo is het van belang dat onderhoud zoveel mogelijk op elkaar afgestemd wordt zodat het systeem niet keer op keer ‘uit de lucht gehaald’ wordt. Ook is het van belang dat bij elke wijziging (ook aan de hardware van het IT-netwerk!) gecontroleerd wordt of dit voor de gehele keten zondermeer kan worden doorgevoerd.

Voor elke server moet bekeken en afgewogen worden of deze redundant uitgevoerd wordt, of de server fysiek of virtueel uitgevoerd wordt en of de server voorzien wordt van alle security- en OS-updates. Als dit laatste het geval is, kan men overwegen de server in een algemeen netwerk te plaatsen. Als de server niet tijdig wordt voorzien van alle security- en OS-updates, moet ook hier een firewall geplaatst worden om de communicatiestromen te reguleren. Wat betreft beheer is dit een complex systeem. Dit betekent dat alle verantwoordelijkheden expliciet en SMART in een verantwoordelijkhedenmatrix moeten worden benoemd.

 

De bewaartermijn van persoonsgegevens moet in acht worden genomen, waarbij de organisatie zelf verantwoordelijk is voor het bepalen van deze termijn. Identificeerbare persoonsgegevens mogen alleen worden opgeslagen zo lang als nodig voor het doel waarvoor ze dienen. Geanonimiseerde data kunnen langer worden bewaard. Dit geldt ook voor data ten behoeve van algemeen belang, wetenschappelijk of historisch onderzoek of statistische doeleinden. Zo kan in dit systeem de anonieme logging van alarmen nuttig zijn voor onderzoek naar trends in alarmering.

 

Klik hier voor een overzicht van de aandachtspunten per fase van de levenscyclus.

Figuur 3.4VOS-MOS-MA