Alles over het Pakket van Eisen

Hoe stel je een PVE op?

In ieder ziekenhuis moeten de verantwoordelijkheden binnen de levenscyclus van medische hulpmiddelen beschreven en belegd zijn. Hierin is ook aangegeven wie er verantwoordelijk is voor het opstellen van een PvE en wie er betrokken moeten worden.

Om een goed PvE op te stellen is er een multidisciplinaire groep nodig. Denk voor de samenstelling van de groep aan de gebruikers en aan de afdelingen Medische Techniek/Klinische Fysica, Klinische Informatica, IT, Inkoop en Hygiëne. Om geen zaken over het hoofd te zien, is het handig om een standaard format voor een PvE te hanteren waarin alle onderdelen benoemd zijn. Alle leden van de multidisciplinaire groep vullen dan het voor hun relevante deel in. De groep moet gezamenlijk de samenhang tussen de diverse eisen en wensen bewaken. Hierbij moeten zij rekening houden met relevante wet- en regelgeving, normen en ziekenhuisbeleid. In bijlage X is een format van een PvE te vinden. Afhankelijk van de structuur van de ziekenhuisorganisatie wordt er uit één van de betrokken afdelingen een projectleider aangewezen om de medische informatietechnologie te verwerven. Deze projectleider moet ervoor zorgen dat de juiste mensen tijdig betrokken worden.

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. Bij een teveel aan criteria kan het voorkomen dat belangrijke criteria ondersneeuwen door de veelheid aan (minder belangrijke) eisen. Eén van de ontwikkelingen om dit te voorkomen is dat men een functioneel PvE gebruikt. Het ziekenhuis stelt dan de functionele wensen en eisen op papier. Zoals voor welke toepassing is de medische informatietechnologie bedoeld? Op welke afdeling wordt het ingezet? En welke processen moeten ermee ondersteund worden? Dit wordt vervolgens naar de leveranciers gestuurd en die kunnen dan aangeven of en welk product hieraan voldoet. Dit geeft leveranciers meer vrijheid om aan te bieden wat volgens hen bij het ziekenhuis past. Ook nieuwe ontwikkelingen kunnen zo makkelijker meegenomen worden.

Informeer bij de afdeling Inkoop wat de gebruikelijke manier van specificeren is binnen het ziekenhuis. Afhankelijk van de complexiteit van het verwervingstraject kan ervoor gekozen worden om eerst een Request for Information (RFI) op te stellen waarin bij diverse leveranciers informatie opgevraagd wordt om een goed beeld te krijgen van de mogelijkheden op de markt. Op basis daarvan kan dan een Request for Proposal (RFP) opgesteld worden waar het PvE een onderdeel van is. Daarnaast bevat een RFP nog algemene zaken zoals een korte omschrijving van het ziekenhuis en de afdeling waarvoor de medische informatietechnologie bedoeld is, een planning van het verwervingstraject, een gewenste installatiedatum en antwoordinstructies.

Naast dat het PvE in een multidisciplinair team wordt opgesteld is het ook van belang om de antwoorden van de leveranciers in een multidisciplinair team te beoordelen.

Wat moet er in het PVE staan?

Hieronder noemen we de belangrijkste eisen/vragen/aandachtspunten die in een PvE moeten staan. In hoofdstuk 3 Praktijkvoorbeelden staan per type medische informatietechnologie voorbeeldeisen genoemd.

• Welke eisen stelt de leverancier aan de verschillende type systemen waar de software op moet kunnen draaien: op welk besturingssysteem, binnen welke architectuur, et cetera?
• Software-updates: hoe vaak, kosten, verantwoordelijkheden, hoe lang na aanschaf?
• Softwarelicenties: aantal gebruikers, type licentie, eigendom.
• Remote beschikbaarheid van applicatiesoftware.
• Hoe vindt de software-installatie plaats: wel of niet via het netwerk?
• Welke serversoftware wordt er gebruikt of is er vereist?
• Hoe garandeert de leverancier databasecompatibiliteit?
• Hoe vindt communicatie met andere systemen plaats, zoals gebruik van DICOM of HL7? Denk hierbij specifiek aan het vermelden van de versienummers van de systemen waaraan gekoppeld moet worden (bijvoorbeeld Metavision PDMS versie 5.xx). Dit voorkomt het probleem dat een koppeling wel goed werkt met een bepaalde versie software terwijl deze versie (nog) niet in de zorginstelling in gebruik is. Denk hierbij ook aan de informatie die je via een koppeling wilt uitwisselen, zoals alarmen of data. Als er cruciale alarmen in de koppeling moeten worden doorgegeven specificeer dan vooraf welke en op welke manier. Denk eraan dat de vraag of iets gekoppeld kan worden nog niet betekent dat de koppeling al beschikbaar is vanuit beide partijen. Wees concreet en geef aan dat op een bepaalde datum de driver voor de koppeling werkend beschikbaar moet zijn. Bedenk hierbij ook wie dat betaalt, en dat het juiste communicatieprotocol gebruikt wordt.
• Wat levert de leverancier aan antivirussoftware, malwaredetectie/-preventie en hoe houdt de leverancier dit up-to-date? Kan de antivirussoftware van het ziekenhuis gebruikt worden? Zo ja, welke eisen stelt de leverancier hieraan?
• Welke hoeveelheid data dient opgeslagen te worden?
• Data moeten zoveel mogelijk centraal opgeslagen worden. Hoe wordt dit geregeld, welke koppelingen zijn hiervoor nodig?
• Worden er nog data lokaal opgeslagen? Zo ja, hoe lang/hoeveel?
• In welk dataformaat wordt de data opgeslagen (bijvoorbeeld DICOM), en hoe garandeert de leverancier toekomstbestendigheid hiervan?
• Datadefinitie: volgens welke systematiek moeten de gegevens vastgelegd worden? Denk aan 11-cijferige patiëntennummers of specifieke eisen vanuit EZIS.
• Wat heeft de leverancier geregeld voor back-ups, dataverlies bij stroomuitval of andere calamiteiten en het loggen van foutmeldingen?
• Wat heeft de leverancier geregeld voor (patiënt-)databeveiliging (denk ook aan privacy, autorisatie, uitwisseling van gegevens) en wat moet het ziekenhuis hier zelf voor regelen?
• Biedt de leverancier de mogelijkheid van conversie van oude data?
• Is het mogelijk om aanpassingen in de applicatie door de eindgebruiker en/of ziekenhuis-IT te laten aanbrengen? Bijvoorbeeld het zelf opstellen van scripts om databases, back-ups en dergelijke aan te maken.
• Welke mogelijkheden biedt het systeem om een rechtenstructuur in te richten? Denk aan creëren, lezen, wijzigen en verwijderen van data (rechten, bewaartermijnen, mogelijk ook rechten voor patiënt, audit trail).
• De software in het medisch apparaat moet onderdeel zijn van de CE-certificering van het medische apparaat. Als het gaat om standalone medische software moet deze zelfstandig CE-gemarkeerd zijn.
• IT-aansluitvoorwaarden/infrastructuureisen voor apparatuur/software op het netwerk als dit van toepassing is voor de zorginstelling. In deze aansluitvoorwaarden staan veelal zaken als: DHCP, AD, DNS, geen fixed IP-adres, up-to-date zijnde OS en antivirus.

Afwegingen

Afhankelijk van het type medische informatietechnologie moet men soms kiezen tussen ziekenhuisstandaarden of leveranciersspecifieke oplossingen. Denk hierbij aan een dedicated pc of een ziekenhuis-pc, antivirussoftware die ziekenhuisbreed gebruikt wordt of leveranciersspecifieke software en een dedicated netwerk of het ziekenhuisnetwerk. Vanuit beheeroogpunt is het meestal wenselijk om voor de ziekenhuisstandaard te kiezen, maar niet alle leveranciers werken hieraan mee. Het is daarom van belang om dit goed uit te vragen bij de leverancier. Is het mogelijk om voor de ziekenhuisstandaard te kiezen, en zo ja, welke eisen stelt de leverancier dan en welke inspanning leveren zij om het ziekenhuis hierbij te ondersteunen? Goede afspraken tussen leverancier en ziekenhuis over bijvoorbeeld verantwoordelijkheden en aansprakelijkheden zijn hierbij noodzakelijk. Zie voor verdere informatie hierover Praktijkvraag 9.