Whitepaper Regelgeving medische alarmering conform MDD, WMH en BMH

Whitepaper | Regelgeving medische alarmering conform MDD, WMH en BMH

1 INHOUDSOPGAVE 1 2 3

INHOUDSOPGAVE ............................................................................................................................. 1 INTRODUCTIE ...................................................................................................................................... 2 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

IQ Messenger ● When the message is critical ● www.iqmessenger.com

1


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.


2


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


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 nietmedisch 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.


4


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.


5


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.


6


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.


7


4.3 4.3.1

REMOTE MONITORING/ALARM SYSTEMS UNDER MDD 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 MDD 2 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

EU directive 93/42 as amended 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 1 2


8


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,

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)” 5


9


“[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.

See MHRA guidance note “Guidance on medical device stand-alone software (including apps)” MEDDEV, p. 23, example d.1.3 9 MEDDEV, p. 24 7 8


10


SOFTWARE UNDER MEDICAL DEVICE DIRECTIVE (MDD)

Figure 1 Flow chart for qualification of software under 93/42


11


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


12


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 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 11


13


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.

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) 14


14


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 SYSTEM 17 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’.

Definition 3.11 EN 60601-1-8 Definition 3.17 EN 60601-1-8 19 Definition 3.3 EN 60601-1-8 17 18


15


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

Definition 3.63 EN 60601-1 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 20 21


16


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.


17


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 27

MvT, Kamerstukken II 1965/66, 8726, nr. 3, p. 5 See article 9 (3) and (4) Bmh and the MDD annexes referred to in that article


18


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 met 28; 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 29

See article 10 Bmh and article 12 MDD for these requirements Article 15 Bmh


19


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.

Article 10 d and j Mandate Regulation VWS 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 30 31


20


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.

http://www.igz.nl/actueel/nieuws/thema_software_als_medisch_huIpmiddel_leeft.aspx 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 33 34


21


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


22


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.


23


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 [email protected]


24

Whitepaper Regelgeving medische alarmering conform MDD, WMH en BMH

Recommend Documents