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.