Spelregels Medische alarmering

Whitepaper | Regelgeving medische alarmering conform MDD, 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 ........................................................................................................................................ 5
4 EXTENDING FUNCTIONALITY BEYOND THE DEVICE ...................................................................... 6
4.1 ROLE OF REMOTE MESSAGING SYSTEMS IN HOSPITALS .......................................................... 6
4.2 REMOTE MESSAGING SYSTEMS UNDER MDD............................................................................ 7
4.3 REMOTE MONITORING/ALARM SYSTEMS UNDER MDD........................................................... 8
4.3.1 INTRODUCTION ...................................................................................................................... 8
4.3.2 MOS DEVICE FUNCTIONALITY.............................................................................................. 8
4.3.3 MOS AS ACCESSORY TO A MEDICAL DEVICE................................................................ 13
4.3.4 DIFFERENT MEMBER STATE PERSPECTIVES......................................................................... 13
4.3.5 WHAT COMPONENTS OF A MOS ARE (A) MEDICAL DEVICE(S)? ................................ 14
4.4 PRIMARY VERSUS SECUNDARY ALARM FUNCTIONALITY ...................................................... 15
4.5 CLASSIFICATION OF A MOS....................................................................................................... 16
4.5.1 CLASSIFICATION OF SOFTWARE AS MEDICAL DEVICE .................................................. 17
4.5.2 CLASSIFICATION OF SOFTWARE AS ACCESSORY........................................................... 17
4.6 REQUIREMENTS FOR SOFTWARE THAT CONSTITUTES A MEDICAL DEVICE OR AN
ACCESSORY TO A MEDICAL DEVICE .................................................................................................. 18
4.6.1 CE MARKING OF MEDICAL DEVICE OR ACCESSORY ................................................... 18
4.6.2 CERTIFICATION OF ENTIRE MOS CHAIN ........................................................................... 18
5 CONSEQUENCES OF NON-COMPLIANCE IN THE NETHERLANDS ............................................ 19
5.1 ENFORCEMENT SYSTEM .............................................................................................................. 19
5.2 MANUFACTURERS AND DISTRIBUTORS ..................................................................................... 20
5.3 HOSPITALS AND HEALTHCARE PROFESSIONALS..................................................................... 20
5.4 ENFORCEMENT CLIMATE............................................................................................................ 21
5.5 CONSEQUENCES FOR LIABILITY AND LIABILITY INSURANCE HOSPITAL ............................... 22
6 COLOPHON...................................................................................................................................... 23

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 een medisch hulpmiddel.
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 in gebruik bij de 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 van een alarm/berichtenserver in
een medische setting.
Dit document geeft een vijftal 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, 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 Medical Device Directive (MDD) regelgeving.
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. 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, (CE, Medical Class).
2. De wetgever maakt geen melding noch onderscheid tussen primaire- en secundaire
alarmering *3 ten aanzien van alarm/berichtenservers en medische alarmering.
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 Medical Class certificatie is
illegaal.
3. 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
een als CE medisch hulpmiddel gecertificeerde alarmserver of alarmserver software in
de MOS keten op te nemen.
4. Het bedoelde gebruik van een MOS en/of alarm/berichtenserver omvat weliswaar
communicatie, zie flowchart pag. 11 blok 3, 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.
5. Het gebruik van een VOS of MOS als alarm/berichtenserver zonder certificatie als
medisch hulpmiddel voor het versturen van alarmsignalen van medische
hulpmiddelen is niet toegestaan en in strijd met de wet. Het gebruik van een niet-
medisch gecertificeerde alarmserver wordt door de wetgever beschouwd als een
overtreding van de Wet Medische Hulpmiddelen en hiervoor kan een maximale
boete worden opgelegd van € 900.000,-.
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.

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 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.
* 4: Met een verpleeg oproep 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 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.
8 MEDDEV, p. 23, example d.1.3
9 MEDDEV, p. 24

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 interprets 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. This step is discussed in detail in paragraph 4.3.3.
10 Definition 3.1 EN 60601-1-8

4.3.3 MOS AS ACCESSORY TO A MEDICAL DEVICE
Step 6 of the flowchart applies where the software does not constitute a medical device as
such, e.g. because the secondary alarm functionality implemented in the software would not
be seen as a medical device. However, in that case the software still fits the definition of
accessory to a medical device, i.e. an article which whilst not being a device is intended
specifically by its manufacturer to be used together with a device (the medical device that is
connected to the MOS) to enable it (that device) to be used in accordance with the use of
the device intended by the manufacturer of the device (communicating ALARM SIGNALS via
RS232 for extending the ALARM SIGNALS to a network or monitoring station). The term “to
enable” should not be seen as a ‘sine qua non’ enabling, since it was agreed on GHTF level
(so also relevant for the EU) that medical devices accessories constitute:
“an article intended specifically by its manufacturer to be used together with a
particular medical device to enable or assist that device to be used in accordance
with its intended use.”11
So, even if the MOS software is not a device as such, it will still constitute an accessory to a
medical device. Accessories to medical devices are also regulated as devices under the
MDD like medical devices are12, so in the end there is no difference.
4.3.4 DIFFERENT MEMBER STATE PERSPECTIVES
Software systems that monitor medical devices via general purpose IT equipment are
considered medical devices by the Swedish competent authority MPA, given that they “are
normally intended to support diagnosis and treatment of disease or injury of a patient, and
have therefore such functions and medical purpose that fall under the medical device
directive.13 The Swedish competent MPA specifically underlines the medical purpose in its
guidance on Medical Information System by referring to the fact that
“systems for monitoring of medical devices are especially complex products that
normally require extensive configuration work. The products are part of a very
11 See GHTF/SG l/N071 :2012 (“Definition of the Terms 'Medical Device' and 'In Vitro Diagnostic (IVD) Medical
Device'”), chapter 4.0 – this definition including “to assist” has also been proposed as new accessory definition under
the new EU medical devices regulation that is currently in the legislative process (Brussels, 26.9.2012
COM(2012) 542 final, 2012/0266 (COD), Proposal for a Regulation of the European Parliament and of the Council on
medical devices, and amending Directive 2001/83/EC, Regulation (EC) No 178/2002 and Regulation (EC) No
1223/2009.
12 Article 1 (1) MDD provides that “This Directive shall apply to medical devices and their accessories. For the purposes
of this Directive, accessories shall be treated as medical devices in their own right. Both medical devices and
accessories shall hereinafter be termed devices.”
13 MPA Guidance document “Medical Information Systems – guidance for qualification and classification of
standalone software with a medical purpose “, p. 69

complex environment that is affected by many external factors, e.g. upgrades of the
operating system where the software is installed. […] If incorrect information is
presented to health care staff then the wrong measures could be taken. Evaluations
can be delayed due to access problems in the system, which could be critical for
some patients.”14
This is confirmed by the MHRA’s approached discussed above in paragraph 4.3.2, which
confirms that the software in systems comprising of general purpose IT equipment connecting
to medical devices and specifically configured software for patient monitoring constitutes a
medical device.15
4.3.5 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 4.3.4 the MOS software constitutes 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.16
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.
14 MPA Guidance document “Medical Information Systems – guidance for qualification and classification of
standalone software with a medical purpose ,“p. 69/70
16 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 SYSTEM17 and DISTRIBUTED ALARM SYSTEM18. 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.19 When the transmission of alarm
signals takes place via an RMS, the industry tends to refer to this functionality as ‘secondary
alarm functionality’.
17 Definition 3.11 EN 60601-1-8
18 Definition 3.17 EN 60601-1-8
19 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 EQUIPMENT20 or ME SYSTEM21, 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.22 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. Under these rules a
MOS or its software constitutes an active medical device23, more specifically an active
medical devices for diagnosis because it is intended for monitoring.24 The same applies to
accessories. Accessories, like software “are classified in their own right separately from the
device with which they are used.”25
20 Definition 3.63 EN 60601-1
21 Definition 3.64 EN 60601-1
22 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.”
23 Annex IX, point 1.4
24 Annex IX, point 1.6
25 Annex IX, Implementing Rule 2.2

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.6 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 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.26 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.6.1 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.27
4.6.2 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.6.1 and below in paragraph 5.
26 MvT, Kamerstukken II 1965/66, 8726, nr. 3, p. 5
27 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 met28;
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 language29 (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’.
28 See article 10 Bmh and article 12 MDD for these requirements
29 Article 15 Bmh

5.2 MANUFACTURERS AND DISTRIBUTORS
The Dutch rules set out in paragraph 4.6 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.30 The policy described in
the Standards Administrative Penalty Health Minister (Beleidsregels bestuurlijke boete Wet op
de medische hulpmiddelen)31 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.32 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.
30 Article 10 d and j Mandate Regulation VWS
31 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
32 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.33 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.34 With respect to hospital ICT
about 50% of the hospitals does not have this in order.35 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.
33 http://www.igz.nl/actueel/nieuws/thema_software_als_medisch_huIpmiddel_leeft.aspx
34 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
35 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.36
36 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 therefor legal and suited for medical alarming
and notification.
IQ MESSENGER
Pieter Zeemanweg 57
3016 GZ DORDRECHT
THE NETHERLANDS
T: +31 (0)88 202 2333
info@iqmessenger.com

Spelregels Medische alarmering

Recommended

Recommended

More Related Content

Similar to Spelregels Medische alarmering

Similar to Spelregels Medische alarmering (20)

Recently uploaded

Recently uploaded (20)

Spelregels Medische alarmering