iq messenger whitepaper ce mdd

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.

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



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 15 See MHRA guidance note ―Guidance on medical device stand-alone software (including apps)‖ 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

Piter Zeemanweg 57

3016 GZ DORDRECHT

THE NETHERLANDS

T: +31 (0)88 202 2333

[email protected]

iq messenger whitepaper ce mdd

Health & Medicine

mos device functionality

ce marking of medical

medical devices

classification of software

remote monitoringalarm

extending functionality

secundary alarm functionality

conclusies en implicaties