White paper: Regelgeving Medische Alarmering_Mei2017

Whitepaper | Regelgeving medische alarmering conform MDD, MDR, WMH en BMH
IQ Messenger | When the message is critical | www.iqmessenger.com 1
1 INHOUDSOPGAVE
1
INHOUDSOPGAVE............................................................................................................................1

2
INTRODUCTIE ....................................................................................................................................2

3
MANAGEMENTSAMENVATTING......................................................................................................3

3.1
MANAGEMENTSAMENVATTING, CONCLUSIES EN IMPLICATIES ............................................4

3.2
DEFINITIES....................................................................................................................................8

4
EXTENDING FUNCTIONALITY BEYOND THE DEVICE .......................................................................9

4.1
ROLE OF REMOTE MESSAGING SYSTEMS IN HOSPITALS .........................................................9

4.2
REMOTE MESSAGING SYSTEMS (RMS) UNDER MDD .............................................................10

4.3
REMOTE MONITORING/ALARM SYSTEMS UNDER MDD........................................................11

4.3.1
INTRODUCTION .................................................................................................................11

4.3.2
MOS DEVICE FUNCTIONALITY ..........................................................................................11

4.3.3
WHAT COMPONENTS OF A MOS ARE (A) MEDICAL DEVICE(S)?.................................16

4.4
PRIMARY VERSUS SECUNDARY ALARM FUNCTIONALITY......................................................17

4.5
CLASSIFICATION OF A MOS....................................................................................................18

4.5.1
CLASSIFICATION OF SOFTWARE AS MEDICAL DEVICE ..................................................19

4.5.2
CLASSIFICATION OF SOFTWARE AS ACCESSORY ..........................................................19

4.5.3
CLASSIFICATION UNDER THE NEW MEDICAL DEVICE REGULATION (MDR) .................19

REQUIREMENTS FOR SOFTWARE THAT CONSTITUTES A MEDICAL DEVICE OR AN ACCESSORY
TO A MEDICAL DEVICE.....................................................................................................................20

4.5.4
CE MARKING OF MEDICAL DEVICE OR ACCESSORY ...................................................20

4.5.5
CERTIFICATION OF ENTIRE MOS CHAIN ..........................................................................20

5
CONSEQUENCES OF NON-COMPLIANCE IN THE NETHERLANDS ..............................................21

5.1
ENFORCEMENT SYSTEM...........................................................................................................21

5.2
MANUFACTURERS AND DISTRIBUTORS ...................................................................................22

5.3
HOSPITALS AND HEALTHCARE PROFESSIONALS ...................................................................22

5.4
ENFORCEMENT CLIMATE.........................................................................................................23

5.5
CONSEQUENCES FOR LIABILITY AND LIABILITY INSURANCE HOSPITAL ...............................24

6
COLOPHON....................................................................................................................................25

2 INTRODUCTIE
Patiëntbewaking in ziekenhuizen en zorginstellingen evolueert continue als gevolg van diverse
ontwikkelingen in de gezondheidzorg.
Ten eerste is er een geringer aantal zorgprofessionals beschikbaar voor fysieke controle van
de patiënten.
Ten tweede hebben patiënten steeds minder de mogelijkheid elkaar te bewaken en
observeren en hierdoor een verminderde capaciteit tot het waarschuwen/alarmeren van
zorgprofessionals.
Ten derde zijn patiënt bewakingsmonitoren (een medisch hulpmiddel) verder ontwikkeld
waardoor zij in een permanente patiëntobservatie kunnen voorzien. Bij overschrijding van
grenswaarden kan de monitor een akoestisch- en/of optisch alarm verspreiden. We spreken
hier over medische alarmering afkomstig van het medisch hulpmiddel zelf, ook wel primaire
alarmering genoemd.
Zorgprofessionals zijn echter vaak niet in staat deze medische alarmering (tijdig) waar te
nemen en vertrouwen steeds meer op de technologie van een berichten/alarm server die de
berichten/alarmen van het medisch hulpmiddel verstuurd naar draadloze- of
draadgebonden apparatuur gebruikt door zorgprofessionals.
Voorbeelden van deze apparatuur in gebruik bij zorgprofessionals zijn piepers, DECT-, Wi-Fi-, of
GSM handsets, smartphones, tablets en desktop PC’s welke worden gebruikt voor de
ontvangst van medische alarmen/berichten verstuurd door een alarm/berichtenserver.

3 MANAGEMENTSAMENVATTING
Dit White Paper heeft tot doel om ziekenhuizen en andere zorginstellingen te informeren over
de Europese- en Nederlandse richtlijnen, wetgeving, brancheafspraken en verplichtingen ten
aanzien van het gebruik van een alarm/berichtenserver ten behoeve van medische
alarmering.
Het White Paper voorziet in bewustwording omtrent wettelijke verplichtingen inzake medische
alarmering en schept duidelijkheid over het juist gebruik en benodigde CE markering van een
alarm/berichtenserver in een medische setting.
Dit document geeft een negental conclusie welke eenvoudig kunnen worden gebruikt voor
of als:
Interne toetsing en controle op juist gebruik en handhaving van uw medische
alarmering conform de MDD, MDR, WMH en BMH
Instrument voor het opstellen van bestekeisen en product- of leverancierskeuze
Richtlijn en instrument voor onderbouwde dialoog met zorgprofessionals en
toeleveranciers omtrent de aanschaf en legaal gebruik van een
alarm/berichtenserver ten behoeve van medische alarmering
De onderstaande conclusies zijn in dit White Paper expliciet beschreven, uitgewerkt en van
juridische onderbouwing voorzien. Voor de uitwerking en onderbouwing van de conclusies
is gekozen voor de Engelse taal gezien een belangrijk deel van de toepasselijke wet- en
regelgeving afkomstig is van Europese Medische Hulpmiddelen Richtlijn (MDD) en de
Medische Hulpmiddelen Verordening (MDR) welke vanaf 25 mei 2017 van kracht zal zijn.
Als laatste geeft dit document een inzicht in de sancties die door de IGZ kunnen worden
opgelegd in geval van niet nakoming van de wet- en regelgeving hieromtrent.

3.1 MANAGEMENTSAMENVATTING, CONCLUSIES EN IMPLICATIES
1. CE MDD/MDR medische certificering verplicht
Wanneer een alarm/bericht/melding afkomstig van een medisch hulpmiddel*1
middels het gebruik van een alarm/berichtenserver*2 wordt verstuurd naar een
draadgebonden of draadloos apparaat zoals een DECT-, Wi-Fi-, GSM toestel, pieper,
desktop PC, tablet of smartphone dient de alarm/berichtenserver of de software
daarop altijd CE gemarkeerd te zijn als een medisch hulpmiddel.
2. MOS alarm/berichtenserver functionaliteit is meer dan enkel communicatie
Het bedoelde gebruik van een MOS en/of alarm/berichtenserver omvat weliswaar
communicatie, zie flowchart pag. 14, maar de functionaliteit gaat verder dan enkel
communicatie omdat de software van het MOS en/of alarm/berichtenserver
inkomende alarmsignalen interpreteert en op basis van de configuratie beslist naar
welke op het systeem aangesloten draadloze- of draadgebonden
apparatuur/toestellen het specifieke medische alarm/bericht gestuurd wordt.
3. Gebruik VOS/MOS voor medische alarmoproepen
Het gebruik van een VOS of MOS als alarm/berichtenserver zonder CE markering als
medisch hulpmiddel voor het versturen van alarmsignalen afkomstig van medische
hulpmiddelen is niet toegestaan en in strijd met de wet.
4. CE markering verplicht bij secundaire medische alarmering
De wetgever maakt geen melding noch onderscheid tussen primaire- en secundaire
alarmering *3 ten aanzien van alarm/berichtenservers en medische alarmering.
Met primaire alarmering wordt bedoeld de alarmering (akoestisch of optisch) aan het
medisch apparaat zelf. Met een secundair alarm wordt de verlengde alarmoproep
bedoeld, welke afkomstig is van het medisch apparaat en middels de verwerking van
de alarm/berichtenserver wordt verzonden naar een draadgebonden of draadloos
apparaat zoals een DECT-, Wi-Fi-, GSM toestel, pieper, desktop PC, tablet of
smartphone.
De argumentatie dat een alarm/berichtenserver geen medisch hulpmiddel is omdat
het uitsluitend secundaire alarmeringstaken zou verzorgen is daarmee onjuist en het
toepassen van een dergelijke alarmserver zonder CE markering is illegaal.

5. Strafmaat niet-medisch gecertificeerde alarmserver
Het gebruik van een niet-medisch gecertificeerde alarmserver wordt door de
wetgever beschouwd als een overtreding van de Wet Medische Hulpmiddelen.
Hiervoor kan een boete worden opgelegd welke maximaal kan oplopen
tot € 900.000, per overtreding.
Tevens is er sprake van een schending van het Convenant Veilige toepassing van
Medische Technologie welke tussen de Nederlandse ziekenhuizen en de Inspectie
voor de Gezondheidszorg (IGZ ) is opgesteld en kunnen verzekeringsmaatschappijen
sancties opleggen indien er sprake is van illegaal handelen.
6. MOS en ketencertificering
Het toepassen van een ketencertificering op het Verpleeg Oproep Systeem (VOS)*4,
alarmserver, infrastructuur en (draadloze) ontvangers met het doel tot een Medisch
Oproep systeem te komen (MOS)*5 maakt de alarm/berichtenserver in deze MOS
keten geen medisch hulpmiddel. Een MOS certificering verandert niets aan de plicht
om de alarmserver of alarmserver software opgenomen in deze MOS keten zelf CE te
markeren als medisch hulpmiddel.
Het feit dat IQ Messenger in een MOS keten is opgenomen betekent niet dat elk
device in deze keten hetzelfde geclassificeerd moet worden. De MDD en MDR
bepalen dat ieder device apart en op eigen merites geclassificeerd moet worden
tenzij het ene apparaat het andere aanstuurt (zie 8, geen accessory), wat in geval
van de alarmserver of alarmserversoftware/message broker niet het geval is.
7. Medische classificatie
Nu dat bepaald is dat de alarmserver/message broker/alarmserver software een
medisch hulpmiddel is (zie ook figure 1 pag 14 uit MEDDEV 2.1/6 en conclusie 2
hierboven) dient de classificatie hiervan op eigen merites te worden bepaald. Uit de
classificatie annex van de bestaande MDD en de nieuwe MDR volgt dat deze in
geval van de alarmserver/message broker/alarmserver software op grond van de
beide EU wetten klasse I dient te zijn, zie ook 4.5.3.
MEDDEV 2.1/6 over standalone software als medisch hulpmiddel vereist dat de
software zelf een bewerking op de data doet voor de in de classificatielogica
genoemde doeleinden (dus bijv. het bewerken van data tot een betekenisvol
resultaat voor klinische besluitvorming, zoals: bij deze waarde moet er een alarm
komen) om als medisch hulpmiddel te kwalificeren.
Wat de message broker/alarmserver of alarmserver software doet is niet het bewerken
van medische data voor dat bedoelde gebruik van de medische hulpmiddelen
upstreamende keten, want dat hebben de devices die de data genereren die door
de message broker heen loopt al gedaan. De message broker verplaatst de door
andere medische devices gegenereerde en of bewerkte data/alarmen 'as is' volgens
beperkte ‘extra functionaliteit’ voor parsing, welke de gebruiker zelf kan instellen.

Deze ‘extra functionaliteit’ voorziet de gebruiker in de mogelijkheid om het reeds
gegenereerde of bewerkte alarm/bericht/data te voorzien van additionele informatie
en of akoestische en optische signaleringen ter verhoging van de attentie, herkenning
en/of het begrip van het alarm/bericht.
De functionaliteit van de message broker/alarmserver of alarmserver software is ook
niet bedoeld voor monitoring of klinische besluitvorming omdat het eerste device in
de keten bepaalt of er een alarm nodig is en er al door de gebruiker is bepaald bij de
configuratie wie welk alarm moet krijgen. De parsing gebeurt dus niet via een
algoritme maar is gebaseerd op door de gebruiker ingestelde ‘als-dan’ regels. Tevens
kent IQ Messenger geen bepaalde graad aan het alarm toe, maar stuurt alleen een
alarm van een door de gebruiker voorgedefinieerde categorie door naar de
personen die daar volgens de gebruiker bij horen.
De functie van distributie van reeds gegenereerde alarmen door de message
broker/alarmserver of alarmserver software mag niet verward worden met de
autonome functie van een medisch hulpmiddel voor het bepalen aan de hand van
medische meting of een alarm gegenereerd moet worden.
Filtering door de gebruiker, in de message broker/alarmserver of alarmserver software
van de door andere medische devices gegenereerde en of bewerkte data/alarmen
ten behoeve van de reductie van alarmmoeheid (alarm fatigue) is geen klinische
besluitvorming waarvoor de software data als input genereert. Immers de
besluitvorming is al gedaan door de gebruiker bij het instellen van de parameters op
‘als-dan’ basis.
Het criterium in de classificatie van MDR regel 11 is "intended to provide information
which is used to take decisions with diagnosis or therapeutic purposes" wat leidt tot
een classificatie van klasse IIa of hoger. ‘Intended to provide’ betekent in deze
context het generen van de informatie op basis van metingen aan de patiënt
(oftewel, het genereren van een al dan niet alarm status).
Wat IQ Messerger doet is het sorteren en doorsturen van reeds gegenereerde
informatie voor klinische besluitvorming. Bij het sorteren wordt de informatie
niet aangepast, maar alleen gekanaliseerd volgens door de gebruiker gedefinieerde
vaste parameters. Dat kanaliseren valt niet onder 'genereren van informatie voor
klinische besluitvorming' maar is doorsturen van reeds gegenereerde informatie.
Ook is IQ Messenger niet bedoeld voor monitoring in de zin van regel 11 MDR, op
grond waarvan een device in klasse IIa of IIb geclassificeerd kan worden, aangezien
IQ Messenger enkel de signalen doorgeeft van de devices die monitoren.
IQ Messenger genereert zelf geen monitoring data omtrent de patiënt en heeft
daarmee niet ‘monitoring’ als bedoeld gebruik.
Daarmee valt IQ Messenger nog steeds onder de groep van 'alle overige software' in
de zin van classificatieregel 11 onder de MDR.

8. Geen accessory
IQ Messenger is geen ‘hulpstuk’ (accessory) van de devices waarvan het de
alarmering verdeelt en dat dezelfde classificatie moet hebben als het device
waarvan het de alarmering verlengt.
Ten eerste bepalen zowel de MDD als de MDR dat accessories op hun eigen merites
beoordeeld worden voor classificatie, los van het device waarmee ze gebruikt
worden.
Dat betekent dat IQ Messenger sowieso op eigen merites gekwalificeerd wordt.
Ten tweede valt IQ Messenger niet onder de definitie ‘accessory’ onder de MDD of
MDR, aangezien daarvoor niet voldaan is aan twee cruciale criteria in die definitie.
Ten eerste is IQ Messenger wel een zelfstandig device en kan het daardoor geen
accessory zijn. Ten tweede is IQ Messenger niet nodig om het downstream device te
kunnen gebruiken (MDD definitie van accessory) of om het medische bedoelde
gebruik van het downstream device rechtstreeks en specifiek te ondersteunen
(breedste definitie van accessory in de MDR).
9. De inspectie voor de gezondheidzorg (IGZ) als autoriteit
De IGZ inspecteert ambtshalve klasse I geclassificeerde standalone software die in
Nederland wordt aangemeld. De IGZ voert een grondige audit uit en heeft dit ook bij
IQ Messenger gedaan, met als conclusie dat IQ Messenger als een medisch
hulpmiddel moet worden beschouwd, klasse I geclassificeerd dient te zijn en dat de
CE markering voor het bedoelde gebruik volledig op orde is.
Een klasse 2 of 3 medisch hulpmiddel wordt beoordeeld door een notified body,
welke ook onder toezicht staan van IGZ. Een door een notified body beoordeeld
medisch hulpmiddel kan nog steeds door IGZ beoordeeld worden als onterecht CE
gemarkeerd of geclassificeerd. In die zin biedt een door IGZ uitgevoerde beoordeling
zelfs meer zekerheid dan de door een notified body uitgevoerde certificering.

3.2 DEFINITIES
* 1: Een medisch hulpmiddel is “elk instrument, toestel of apparaat, elke software of stof
of elk ander artikel dat of die alleen of in combinatie wordt gebruikt, met inbegrip van
de software die door de fabrikant speciaal is bestemd om te worden gebruikt voor
diagnostische en/of therapeutische doeleinden en voor de goede werking ervan
benodigd is, door de fabrikant bestemd om bij de mens te worden aangewend voor:
— diagnose, preventie, bewaking, behandeling of verlichting van ziekten,
— diagnose, bewaking, behandeling, verlichting of compensatie van verwondingen
of een handicap,
— onderzoek naar of vervanging of wijziging van de anatomie of van een fysiologisch
proces, […]”
* 2: Een alarmserver, ook wel berichtenserver, message broker, message server of
remote message system (RMS) genoemd, is een softwareproduct (pre) geïnstalleerd
op een (generiek of specifiek gebruik) computer/server met het doel de
alarmen/meldingen/berichten afkomstig van een medisch hulpmiddel te
verlengen/verzenden naar draadgebonden of draadloze ontvangers zoals desktop
PC’s, beeldscherm consoles, DECT-, Wi-Fi-, GSM toestellen, piepers, tablets of
smartphones, welke door zorgprofessionals worden gebruikt.
* 3: De zorgsector en toeleverende industrie gebruikt vaak de terminologie Primaire- en
secundaire alarmering als het gaat om berichten/alarmen afkomstig van medische
hulpmiddel.
Met Primair wordt hier verstaan de akoestische- en optische signalering van het
medisch hulpmiddel zelf door de zorgprofessional ter plaatse of middels een veelal
kabelgebonden beeldschermapplicatie kan worden waargenomen.
Met Secundair wordt bedoeld het afleveren van medische alarmen/berichten
middels het gebruik van een alarm/berichtenserver op bijvoorbeeld desktop PC’s,
beeldscherm consoles, DECT-, Wi-Fi-, P-GSM toestellen, piepers, tablets of
smartphones, welke door zorgprofessionals worden gebruikt.
Deze terminologie heeft echter geen wettelijke basis en wordt ook niet in de wet
gebruikt.
* 4: Met een verpleegoproep systeem (VOS) wordt bedoeld een draadloos of
draadgebonden belsysteem welke bedoeld is om patiënten en zorgprofessionals in
staat te stellen een kamer/persoon of bedgebonden alarmoproep te verzenden. Een
VOS is veelal niet gecertificeerd als medisch hulpmiddel.
* 5: Met een medisch oproep systeem (MOS) wordt bedoeld een VOS voorzien van
een ketencertificering door een notified body, anders dan als medisch hulpmiddel.

4 EXTENDING FUNCTIONALITY BEYOND THE DEVICE
4.1 ROLE OF REMOTE MESSAGING SYSTEMS IN HOSPITALS
Remote messaging systems are used in hospitals to transfer either messages and/or signals
from Health Care Professionals (HCPs) or medical devices to HCPs.
Hospitals tend to use remote messaging systems (“RMS”) as an extension of medical devices
or of ALARM SYSTEMS that generate alarms to deliver ALARM SIGNALS to handheld devices
such as pagers, DECT or Wi-Fi handsets, tablets or smartphones carried by HCPs. In the
Netherlands a messaging system in a hospital that is not connected to (a) medical device(s)
is normally referred to as a Nurse Call System (Verpleeg Oproep Systeem (VOS)). Where
medical devices are connected to the system in order to communicate device alarms/status
to system user handhelds, the system is referred to as a Medical Calling System (Medisch
Oproep System (MOS)).
Currently, there are different views in industry about the regulatory requirements that apply to
a MOS as described in this White Paper. This White Paper seeks to set out the medical devices
rules that apply to MOS systems, the consequences of application of such rules and the
liability and administrative risks resulting from not complying with those rules.

4.2 REMOTE MESSAGING SYSTEMS (RMS) UNDER MDD
Remote messaging systems allow
direct calling of HCPs by patients
or by other HCPs. These systems
have historically evolved from the
alarm button at the patient’s bed
to paging systems and systems
that can deliver messages to DECT
or Wi-Fi handsets, tablets or
smartphones of HCPs or other
handheld or desktop devices.

4.3 REMOTE MONITORING/ALARM SYSTEMS UNDER MDD
4.3.1 INTRODUCTION
An RMS generally consists of specific general purpose hardware (RS232 to IP converter
attached to the medical devices concerned, Wi-Fi / Dect routers and LAN switches, server) as
well as software that runs on a server. The RMS software decides on the basis of its
configuration and contents of the received alarm message coming from a medical device
what ALARM SIGNALS are delivered to what devices linked to the RMS.
There is difference of opinion in the industry about the question whether an RMS used as a
MOS must be certified as a medical device under the EU Medical Devices Directive1 (MDD)
and if so, what parts of the MOS must be certified. The answer to this question depends on
whether the MOS provides functionality in scope of the definition of ‘medical device’. In
practice this is normally the case for MOS systems, as will be explained below.
4.3.2 MOS DEVICE FUNCTIONALITY
For a MOS or a component of the MOS to constitute a medical device, its functionality has to
fall within the scope of the definition of medical device in the MDD2 or of an accessory to a
medical device.3 The functionality of a medical device is derived from its intended purpose,
i.e.
“the use for which the device is intended according to the data supplied by the
manufacturer on the labelling, in the instructions and/or in promotional materials”.4
In essence a MOS communicates ALARM SIGNALS from a medical device to designated
mobile devices. To be able to communicate, a MOS uses software to interpret incoming
communication of the medical device that is linked to the MOS as the various ALARM
1 EU directive 93/42 as amended
2 Article 1 (2) (a) MDD: “any instrument, apparatus, appliance, software, material or other article, whether used alone
or in combination, including the software intended by its manufacturer to be used specifically for diagnostic and/or
therapeutic purposes and necessary for its proper application, intended by the manufacturer
to be used for human beings for the purpose of:
— diagnosis, prevention, monitoring, treatment or alleviation of disease,
— diagnosis, monitoring, treatment, alleviation of or compensation for an injury or handicap,
— investigation, replacement or modification of the anatomy or of a physiological process,
— control of conception,
and which does not achieve its principal intended action in or on the human body by pharmacological,
immunological or metabolic means, but which may be assisted in its function by such means;”
3 Article 1 (2) (b) MDD: “an article which whilst not being a device is intended specifically by its manufacturer to be
used together with a device to enable it to be used in accordance with the use of the device intended by the
manufacturer of the device;
4 Article 1 (2) (g) MDD

SIGNALS that are defined in the MOS software and decides to what devices/HCPs the given
signals need to be communicated. The hospital or MOS supplier can configure the software
with its own criteria. The other components of the MOS constitute general purpose network
equipment, such as RS232 to IP converters, servers, routers, switches, Wi-Fi and DECT access
points.
Being used in a medical setting does not make a general purpose device like networking
equipment a medical device. Either
the manufacturer of the device must have intended it as a medical device or
accessory to a medical device (which is not the case for general purpose network
equipment) or
the devices are considered to form part of a system with medical device functionality
that is certified as a medical device.5
However, this is typically what happens when a company puts together general purpose
equipment and software to implement it as a MOS. Since the functionality of the general
purpose components does not chance in a MOS, therefore, the medical device functionality
must reside in the software that runs on the server. This is confirmed by the regulatory
approach of the UK competent authority MHRA towards telehealth and telecare systems with
similar functionality as a MOS, defined as
“the delivery of health services or information [including vital signs from medical
devices] using telecommunications technologies. […]The data can then be
transmitted to a healthcare professional who can observe health status without the
patient leaving home. Increasingly, this latter function could be placed on a server
and software used to interpret the patient data. This is considered a medical
device.”.6
In relation to remote monitoring systems that connect to medical devices the MHRA states
that the general purpose IT components that do not have a medical purpose do not need to
be CE marked as medical devices,
5 As for example in the situation referred to in article 12 (2) MDD, which discusses systems comprising medical devices
and non-medical devices being certified as a complete medical device.
6 See MHRA guidance note “Guidance on medical device stand-alone software (including apps)”

“[h]owever, the software that runs on the server and interprets or interpolates the
patient data is likely to be a medical device and would be regulated as such.”7
This approach is also confirmed by the EU MEDDEV that provides that general purpose IT
network and communication equipment does not constitute a medical device in patient
monitoring systems8, but rather the software, as is confirmed in the example concerning
software
“[m]odules that are intended to monitor the medical performance of medical
devices”,
which fall under the MDD.9
Whether or not software has medical devices functionality under the MDD is decided on the
basis of EU guidance document MEDDEV 2.1/6 Guidelines on the qualification and
classification of stand alone software used in healthcare within the regulatory framework of
medical devices. This guidance contains the below flowchart on page 9 that helps to
determine whether functionality of software is in the scope of the MDD.
7 See MHRA guidance note “Guidance on medical device stand-alone software (including apps)”
8 MEDDEV, p. 23, example d.1.3
9 MEDDEV, p. 24

!
1. IS THE SOFTWARE A
COMPUTER PROGRAM?
2. IS THE SOFTWARE
INCOFPRATED IN A
MEDICAL DEVICE?
3. DOES THE SOFTWARE
PERFORM AN ACTION ON
DATA OTHER THAN
STORAGE, ARCHIVING,
LOSSLESS COMPRESSION,
COMMUNICATION OR
SIMPLE SEARCHING?!
4. DOES THE ACTION
BENEFIT INDIVIDUAL
PATIENTS?!
5. IS THE ACTION IN LINE
PURPOSE DEFINED IN ART.
12A OF MDD? !
6. IS IT AN ACCESSOIRY OF
A MEDICAL DEVICE? !
COVERED BY THE MEDICAL
DIRECTIVES !
STAND-ALONE
SOFTWARE
PART OF A
MEDICAL DEVICE
NOT COVERED BY THE
MEDICAL DEVICE
DIRECTIVES !
NOT A MEDICAL
DEVICE
NO YES
YES
YES
YES
YES
NO
YES
NO
NO
NO
SOFTWARE UNDER MEDICAL DEVICE DIRECTIVE (MDD)
Figure 1 Flow chart for qualification of software under 93/42

Steps 1 and 2 serve to determine if the software running on the MOS server is standalone
software (i.e. not embedded in a medical device), which is the case if the software runs on a
general purpose or proprietary server.
Step 3 serves to determine if the software performs an action on data, or performs an action
that goes beyond storage, archival, communication, ‘simple search’ or lossless compression.
The intended purpose of a MOS is among other things to communicate, but its functionality
goes beyond mere communication because it parses incoming signals and decides, based
on its configuration, to what handheld to transmit what particular ALARM SIGNAL.
Step 4 seeks to determine if the functionality is used for the benefit of a particular patient or
group of patients. That is the case since the ALARM SIGNAL is traced back to a device that is
in a particular ALARM CONDITION10.
Step 5 provides that if the manufacturer specifically intends the software to be used for any of
the purposes listed in Article 1 (2) (a) of Directive 93/42/EEC, then the software shall be
qualified as a medical device. The purposes are:
diagnosis, prevention, monitoring, treatment or alleviation of disease,
diagnosis, monitoring, treatment, alleviation of or compensation for an injury or
handicap,
investigation, replacement or modification of the anatomy or of a physiological
process,
control of conception.
The manufacturer of the MOS software intends the software to be used for monitoring,
whether of disease, injury or handicap. MOS functionality is described as ‘secondary alarm’
functionality, which allows extending the alarm function of medical devices through the
hospital network to the HCP carried handhelds, allowing remote monitoring of patients rather
than needing to be in auditive/visual range of the medical device’s ALARM SYSTEM or
DISTRIBUTED ALARM SYSTEM.
Step 6 is concerned with standalone software as an accessory to a medical device, typically
the device that it connects to. However, since a MOS is not an accessory because is not
intended to enable or specifically assist the intended purpose of the devices it connects to, it
is not an accessory under the MDD or MDR. The devices that the MOS connects to do not
10 Definition 3.1 EN 60601-1-8

need or are assisted by the MOS for their intended purpose, because they can fulfill that
independently. The MOS merely extends signals that have been generated in fulfillment of the
intended purpose of those devices.
4.3.3 WHAT COMPONENTS OF A MOS ARE (A) MEDICAL DEVICE(S)?
As described in paragraphs 4.3.1 4.3.2 a MOS typically consists of general purpose IT
networking equipment and dedicated software that runs on a hospital or other server. As
discussed in paragraphs 4.3.2 and Fout! Verwijzingsbron niet gevonden. the MOS software
onstitutes a medical device because this is the part of the MOS where the medical device
functionality is implemented. The other components are not medical devices as they do not
have that functionality. However, if the manufacturer certifies only the software as medical
device, he must implement appropriate risk management measures to ensure integrity of
communication of alarm signals by analogy to the requirements of harmonized standard EN
60601-1-8 concerning distributed medical alarm systems.11
Alternatively, a manufacturer may choose to define the intended purpose of a MOS for an
entire system, include all general purpose components in the scope of the medical device
and have all hardware certified as part of the CE marking of the whole system.
11 See explanatory comments on clause 6.11 in that standard (EN 60601-1-8:2007+A1:2013 (E), p. 64)

4.4 PRIMARY VERSUS SECUNDARY ALARM FUNCTIONALITY
The 60601-1-8 standard does not discuss what industry generally refers to as ‘secondary alarm
systems’. Secondary alarm systems normally referred to as communication systems are linked
to a medical device and communicate any alarms generated by the medical device to a
general purpose (non medical) device, like a handheld or smartphone. In industry a primary
alarm is referred to as a visible or audible alarm generated by the medical device itself, while
secondary alarms are alarm signals that are relayed/transmitted by a RMS to a wired or
wireless device used by an HCP.
The standard addresses the concepts of ALARM SYSTEM12 and DISTRIBUTED ALARM SYSTEM13. A
DISTRIBUTED ALARM SYSTEM is for example a system that connects to multiple IV pumps in a
ward and shows (alarm) status for these devices on a monitor and can give an audible and
visual alarm signal when a pump generates an ALARM LIMIT.14 When the transmission of alarm
signals takes place via an RMS, the industry tends to refer to this functionality as ‘secondary
alarm functionality’.
12 Definition 3.11 EN 60601-1-8
13 Definition 3.17 EN 60601-1-8
14 Definition 3.3 EN 60601-1-8

Since the definition of the concept of ALARM SYSTEM requires that the ALARM SYSTEM is part
of ME EQUIPMENT15 or ME SYSTEM16, the latter of which incorporates at least one ME
EQUIPMENT. Since ME EQUIPMENT – according to its definition, must have an APPLIED PART
that is in contact with the PATIENT, a MOS as such cannot constitute a system or equipment
discussed in the EN 60601-1-8 except when it is intended as a part of an ME SYSTEM (which
must include a device (ME EQUIPMENT) ‘attached. A MOS is essentially a DISTRIBUTED ALARM
SYSTEM without ME EQUIPMENT in its signal path.
Therefore, while the standard gives useful guidance for how a MOS might be constructed by
analogy to DISTRIBUTED ALARM SYSTEMS, the standard itself also indicates its limitations and
essentially leaves it to the manufacturer to use good risk analysis for the design of DISTRIBUTED
ALARM SYSTEMS.17 Consequently, there is no formal legal basis or basis in a harmonized
standard for the distinction between primary and secondary alarm functionality, nor does this
different have any legal effect.
4.5 CLASSIFICATION OF A MOS
There are examples of MOS’ that are certified as medical devices or accessories by notified
bodies, which brings up the question of classification of a MOS of MOS software. The rules for
classification of medical devices and accessories are set out in Annex IX MDD. Under these
rules a MOS or its software constitutes an active medical device.18
15 Definition 3.63 EN 60601-1
16 Definition 3.64 EN 60601-1
17 EN 60601-1-8, p. 64: “The committee believed that the field was too immature to write a large number of specific
requirements. Perhaps a future edition of this collateral standard will be able to include more specific requirements,
when the technology has matured. In the meantime, a MANUFACTURER is left to use good RISK ANALYSIS to be sure
that their DISTRIBUTED ALARM SYSTEMS serve their primary purpose: to improve the ability of a qualified OPERATOR to
respond in an appropriate and timely manner to every ALARM CONDITION.”
18 Annex IX, point 1.4

!
Start Class I
Class
IIa
Class III
Class
IIb
YES
Software intended to provide
information which is used to
take decisions with diagnosis
or therapeutic purposes?
Software intended to monitor
physiological processes?
Such decisions have an
impact that may cause the
death or an irreversible
deterioration of the state of
health?
Such decisions have an
impact that may directly or
indirectly cause a serious
deterioration of the state of
health or a surgical
intervention?
Software intended for
monitoring of vital physiological
parameters, where the nature
of variations is such that it could
result in immediate danger to
the patient?
YES
NO
NO NO NO
YES
YESYES
NO
4.5.1 CLASSIFICATION OF SOFTWARE AS MEDICAL DEVICE
Since software is an active medical device it is subject to rules 9 to 12 of Annex IX concerning
active devices. RMS software classifies as a class I medical device under rule 12 because
none of rules 9 to 11 apply to the intended purpose of the software, which is to use
predefined criteria to discriminate between inbound ALARM SIGNALS that have already been
generated by medical devices and deliver the ALARM SIGNAL to handsets in accordance
with the predefined criteria. More specifically rule 10 does not apply because the software is
not intended for direct diagnosis or monitoring of physiological parameters.
4.5.2 CLASSIFICATION OF SOFTWARE AS ACCESSORY
Since accessories are classified under Annex IX as devices in their own right, the classification
logic is exactly the same as for the classification of the software as medical device set out in
paragraph 0. The result is therefore the same as well: class I.
4.5.3 CLASSIFICATION UNDER THE NEW MEDICAL DEVICE REGULATION (MDR)
Under the new EU Medical Devices Regulation (“MDR”) that will enter into force on 25 May
2017 and that will apply with the exclusion of the Medical Devices Directive a new
classification rule will be introduced for standalone software in Annex VIII, rule 11, of the MDR.
This rule is graphically represented below. The other classification logic with respect to
software does not change.
It follows that software that extends ALARM SIGNALS that have already been generated by
other medical devices to specific handsets in accordance with user defined criteria falls in
class I. It does not constitute provide information that is used to take therapeutic or diagnostic
decisions, as this information is already provided by the device that generates the ALARM
SIGNAL. The software also is not intended to monitor physiological processes because, again,
this is done by the medical device that generates the ALARM SIGNAL that the software
delivers to a handset in accordance with user pre-defined criteria.

REQUIREMENTS FOR SOFTWARE THAT CONSTITUTES A MEDICAL DEVICE OR AN
ACCESSORY TO A MEDICAL DEVICE
The legislation in the field of medical devices consists of various national and European
regulations. The most relevant for this White Paper are the MDR, MDD, the Act on medical
devices (“WMH”), the Medical Devices Decree (“Bmh”), which cover both medical devices
and their accessories.
The WMH is a framework act that provides a general framework for ensuring good quality of
medical devices and for the prevention of the improper use of these devices.19 The Wmh
regulates the quality requirements for and testing of medical devices and provides for
secondary legislation to be enacted for this purpose. As a result, the Bmh provides further rules
that medical devices must comply with. The Bmh partially implements the MDD in national
legislation. The WMH also implements Directive 93/42.
4.5.4 CE MARKING OF MEDICAL DEVICE OR ACCESSORY
The Bmh requires that medical devices and accessories are CE marked under the MDD. Since
MOS software will constitute a medical device or an accessory, the medical device or
accessory has to be CE marked. The conformity assessment that may lead to a CE certificate
that entitles the manufacturer to issue a declaration of conformity will need to be issued by a
notified body because the software is in class IIa or IIb.20
4.5.5 CERTIFICATION OF ENTIRE MOS CHAIN
As an alternative to certification of only the MOS software on the server it is possible to certify
the whole MOS software chain as a medical device as such. Since the intended purpose of
the whole MOS software chain does not change compared to the software as such, the
classification does not change from class I.
Any certification other than CE certification under the MDD will not give the system legal
status under the MDD and its Dutch implementing legislation discussed above in paragraph
4.5.4 and below in paragraph 5.
19 MvT, Kamerstukken II 1965/66, 8726, nr. 3, p. 5
20 See article 9 (3) and (4) Bmh and the MDD annexes referred to in that article
IQ Messenger | When the message is critical | www.iqm
20 See article 9 (3) and (4) Bmh and the MDD annexes referred to in that article

5 CONSEQUENCES OF NON-COMPLIANCE IN THE NETHERLANDS
5.1 ENFORCEMENT SYSTEM
Article 3 WMH prohibits the import, possession, delivery or use/application of medical devices
if the legal requirements are not fulfilled. Article 4 Bmh provides prohibitions directed to
different actors in the supply chain of a medical device and to end users (doctors and
hospitals):
1. The manufacturer is prohibited from possessing a medical device for delivery or
delivering a medical device if the device does not meet the requirements;
2. Any other person than the manufacturer that integrates a medical device with other
medical devices into a system is prohibited from possessing such a system or
delivering it if the requirements for such integration are not met21;
3. Any other person than the manufacturer is prohibited from possessing a medical
device for delivery or delivering a medical device if the device does not meet the
requirements regarding resale (among which that the device must be CE marked
and is labeled in the Dutch language22 (unless and exemption applies);
4. It is prohibited to apply a medical device if it has not been delivered in conformity
with the above requirements 1, 2 and 3.
Article 5 Bmh provides that a manufacturer must register itself with the Dutch authorities.
Under Article 6 Bmh it is set out the medical devices must meet the Essential Requirements
included in Annex I to the MDD Decision. Article 7 Bmh provides that medical devices must
carry CE marking. Article 8 Bmh provides that medical devices must be classified according
to the risk classes set out in Annex IX of the MDD and must, pursuant to article 9 Bmh, follow
the conformity assessment route corresponding to the risk class of the medical device
concerned.
Article 4, paragraph 1 Bmh reads as follows: "It is prohibited for the manufacturer of a medical
device to have it available or deliver it if the requirements in Articles 5 to 9c, 12, and 13 are
not met. " Article 1, paragraph b of the WMH provides that 'have available’ includes ‘having
available for the purpose of delivery’.
21 See article 10 Bmh and article 12 MDD for these requirements
22 Article 15 Bmh

5.2 MANUFACTURERS AND DISTRIBUTORS
The Dutch rules set out in paragraph 0 are supervised and enforced by the Healthcare
Inspectorate (Inspectie voor de Gezondheidszorg (IGZ)), which is part of the State Supervision
on Public Health (Article 11 WMH). To this end IGZ actively checks whether manufacturers and
suppliers of medical devices adhere to the rules.
Article 14 WMH authorizes the Minister of Health to impose an administrative fine of up to EUR
900,000, - in respect of an infringement of the provisions of or pursuant to Article 3 WMH and 4
Bmh. This authority has been delegated by the Minister to the IGZ.23 The policy described in
the Standards Administrative Penalty Health Minister (Beleidsregels bestuurlijke boete Wet op
de medische hulpmiddelen)24 sets out what policy the Minister of Health applies for the
purpose of imposition of an administrative fine.
5.3 HOSPITALS AND HEALTHCARE PROFESSIONALS
Hospitals and healthcare professionals are also subject to the rules of the WMH and Bmh,
notably the requirement not to apply medical devices that do not meet the requirements set
out in the Bmh. This means that the IGZ can also impose administrative penalties against
hospitals and individual HCPs for infringement of the medical devices rules.
In addition hospitals are subject to the requirements under the Act on Quality of Healthcare
Institutions (Kwaliteitswet Zorginstellingen (KWZ)). Specifically with regard to medical devices
the Dutch hospitals and the IGZ have agreed the Covenant on Safe Application of Medical
Technology (Convenant Veilige toepassing van Medische Technologie (Covenant)), of which
the IGZ has indicated that it will enforce it as a so-called field standard (veldnorm) that
specifies requirements under the KWZ. The covenant provides standards for life cycle
management of medical devices and makes the hospital’s fulfillment of the standards the
responsibility of the hospital’s management. This includes safeguarding the CE mark of
medical devices.25 Installing and using an MOS that should be partially or wholly certified as a
medical device while this is has not happened can also constitute an infringement of the
KWZ, which can be subject to an administrative fine under the KWZ.
23 Article 10 d and j Mandate Regulation VWS
24 Besluit van de Minister van Volksgezondheid, Welzijn en Sport, van 9 juni 2010, nr. MC-U-3006967, houdende
vaststelling van beleidsregels betreffende het opleggen van bestuurlijke boetes op grond van de Wet op de
medische hulpmiddelen
25 Bijlage A: begeleidende tekst, paragraph 1.7

5.4 ENFORCEMENT CLIMATE
On June 5, 2013 and October 2, 2013, the IGZ organized two conferences at its office in
Utrecht to inform the stakeholders in the field of software products about the regulations on
medical devices that might apply to software for medical purposes. These meetings were
attended by hundreds of manufacturers, retailers, hospitals and other interested parties from
the field present. The second conference was actually intended only for hospitals. In addition,
the IGZ has participated in an informal meeting for members of the Association for
organizations for ICT in Healthcare (OIZ) on November 14, 2013. Finally, IGZ has informed
stakeholders via its website.26 At these conferences and on its website IGZ has informed
stakeholders that it intended to start enforcing medical devices regulation against software
products that are not in conformity with the WMH as of 1 January 2014.
During 2014 IGZ has first inspected several companies active in the field of software used in a
medical setting in order to check compliance of the software with the WMH and to form a
benchmark for later enforcement. IGZ visited a significant number of companies in the field
and has now started to issue the first notifications of imposition of a fine, with fines of well over
50,000 Euros announced imposed in a number of cases.
The IGZ has found that hospital management in the Netherlands is seriously lacking attention
to safe use of medical technology in hospitals and do not implement the Covenant
sufficiently. In a 2014 report IGZ reported that especially hospital ICT (insofar as within the
scope of the definition of medical device) is an area to which the hospitals do not give
sufficient attention, while this is within scope of the Covenant.27 With respect to hospital ICT
about 50% of the hospitals does not have this in order.28 IGZ indicates in that report that it will
enforce against hospitals if they do not implement the Covenant better. Apart from imposing
a fine IGZ can place a hospital under increased supervision, issue a mandatory directive
(aanwijzing) or order to remedy a particular situation.
26 http://www.igz.nl/actueel/nieuws/thema_software_als_medisch_huIpmiddel_leeft.aspx
27 IGZ report “Veilig gebruik van medische technologie krijgt onvoldoende bestuurlijke aandacht in de ziekenhuizen:
Geaggregeerd rapport van toezichtbezoeken naar de implementatie van het convenant ‘Veilige toepassing van
medische technologie in het ziekenhuis’, Utrecht, juni 2014, paragraph 2.2.2
28 IGZ report “Veilig gebruik van medische technologie krijgt onvoldoende bestuurlijke aandacht in de ziekenhuizen:
Geaggregeerd rapport van toezichtbezoeken naar de implementatie van het convenant ‘Veilige toepassing van
medische technologie in het ziekenhuis’, Utrecht, juni 2014, p. 22

5.5 CONSEQUENCES FOR LIABILITY AND LIABILITY INSURANCE HOSPITAL
Professional liability insurance policies typically exclude from their cover damages resulting
from willful and/or negligent unlawful acts. If a hospital is aware that that its MOS or parts of it
should be CE marked as medical device (as described in this White Paper) and subsequently
chooses to continue use of the MOS, any resulting damage to patients may well not be
covered under its or its HCPs’ professional liability policies.
The hospital and HCPs may be liable for infringement of article 7:453 Civil Code that concerns
the medical treatment agreement (Wet Geneeskundige Behandelingsovereenkomst
(WGBO)) and which provides that HCPs must act with due care of an HCP in provision of their
healthcare services and act according to their responsibilities resulting from the professional
standards that apply. Using medical technology in accordance with basic legal requirements
is one of these professional standards.
In addition, recent case law provides that hospitals and HCPs may be liable for damages
(onrechtmatige daad) under article 6:77 Civil Code if they use medical devices that are
unsuitable for the performance of their healthcare services that result in damage to the
patient and turned out not be compliant with the medical devices regulations.29
29 Gerechtshof 's-Hertogenbosch 25-11-2014, Zaaknummer HD 200.103.100_01, ECLI:NL:GHSHE:2014:4936

6 COLOPHON
This White Paper has been written for IQ Messenger by and under the supervision of Erik
Vollebregt, founding partner of Axon Lawyers, a boutique law firm specializing in legal and
regulatory aspects of medical technology. Erik has a longstanding record of work for
companies in the medical devices sector both on national and EU level.

IQ Messenger is the leading manufacturer of the vendor independent software platform for
messaging, alarming and notification. Our full IP platform with many in-depth integrations and
smart applications for desktop, tablet and smartphone users puts your working process in pole
position. Through unprecedented flexibility, ease of management and completeness of our
integrations you are now "in control".
IQ Messenger is CE Medical Class certified and therefore legal and suited for medical
alarming and notification.
IQ MESSENGER
Pieter Zeemanweg 57
3016 GZ DORDRECHT
THE NETHERLANDS
www.iqmessenger.com
info@iqmessenger.com
T: +31 (0)88 202 2333

White paper: Regelgeving Medische Alarmering_Mei2017

Recommended

Recommended

More Related Content

Similar to White paper: Regelgeving Medische Alarmering_Mei2017

Similar to White paper: Regelgeving Medische Alarmering_Mei2017 (20)

Recently uploaded

Recently uploaded (20)

White paper: Regelgeving Medische Alarmering_Mei2017