7 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. IQ Messenger When the message is critical 6

8 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. IQ Messenger When the message is critical 7

9 4.3 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 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 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 IQ Messenger When the message is critical 8

10 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) IQ Messenger When the message is critical 9

11 [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 systems 8, 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 MEDDEV, p. 24 IQ Messenger When the message is critical 10

13 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 CONDITION 10. 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 Definition 3.1 EN IQ Messenger When the message is critical 12

14 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 are 12, so in the end there is no difference 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, 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/ 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 IQ Messenger When the message is critical 13

15 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 WHAT COMPONENTS OF A MOS ARE (A) MEDICAL DEVICE(S)? As described in paragraphs 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 and 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 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 :2007+A1:2013 (E), p. 64) IQ Messenger When the message is critical 14

16 4.4 PRIMARY VERSUS SECUNDARY ALARM FUNCTIONALITY The 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 SYSTEM 18. 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 Definition 3.17 EN Definition 3.3 EN IQ Messenger When the message is critical 15

17 Since the definition of the concept of ALARM SYSTEM requires that the ALARM SYSTEM is part of ME EQUIPMENT 20 or ME SYSTEM 21, 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 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 device 23, 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 Definition 3.63 EN Definition 3.64 EN EN , 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 Annex IX, point Annex IX, Implementing Rule 2.2 IQ Messenger When the message is critical 16

18 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 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. IQ Messenger When the message is critical 17

19 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/ 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 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 and below in paragraph MvT, Kamerstukken II 1965/66, 8726, nr. 3, p See article 9 (3) and (4) Bmh and the MDD annexes referred to in that article IQ Messenger When the message is critical 18

20 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 language 29 (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 IQ Messenger When the message is critical 19

21 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 , 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 IQ Messenger When the message is critical 20

22 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, 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 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 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 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 IQ Messenger When the message is critical 21

23 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 Gerechtshof 's-hertogenbosch , Zaaknummer HD _01, ECLI:NL:GHSHE:2014:4936 IQ Messenger When the message is critical 22

24 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 When the message is critical 23

25 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 GZ DORDRECHT THE NETHERLANDS T: +31 (0) IQ Messenger When the message is critical 24

Version 1.2 DECLARATION FOR GAD approval Declare that for the following central heating boilers Intergas Calderas de Calefacción S. L. Kombi Kompakt R 24, 28/24, 36/30 and Prestige The installation and

Settings for the C100BRS4 MAC Address Spoofing with cable Internet. General: Please use the latest firmware for the router. The firmware is available on http://www.conceptronic.net! Use Firmware version

CREATING VALUE THROUGH AN INNOVATIVE HRM DESIGN CONFERENCE 20 NOVEMBER 2012 DE ORGANISATIE VAN DE HRM AFDELING IN WOELIGE TIJDEN Mieke Audenaert 2010-2011 1 HISTORY The HRM department or manager was born

www.iuscommune.eu Dear Ius Commune PhD researchers, You are kindly invited to attend the Ius Commune Amsterdam Masterclass for PhD researchers, which will take place on Thursday 16 June 2016. During this

Introduction Henk Schwietert Evalan develops, markets and sells services that use remote monitoring and telemetry solutions. Our Company Evalan develops hard- and software to support these services: mobile

(for Dutch go to page 4) How to install and use dictionaries on the ICARUS Illumina HD (E652BK) The Illumina HD offers dictionary support for StarDict dictionaries.this is a (free) open source dictionary

167 Appendix A: List of variables with corresponding questionnaire items (in English) used in chapter 2 Task clarity 1. I understand exactly what the task is 2. I understand exactly what is required of

it would be too restrictive to limit the notion to an "inner circle" in which the individual may live his own personal life as he chooses and to exclude therefrom entirely the outside world not encompassed

UNIVERSITY OF CAMBRIDGE INTERNATIONAL EXAMINATIONS International General Certificate of Secondary Education *0535502859* DUTCH 0515/03 Paper 3 Speaking Role Play Card One 1 March 30 April 2010 No Additional

Policy Aspects of Storm Surge Warning Systems Ir. Herman Dijk Ministry of Transport, Public Works and Water Contents Water in the Netherlands What kind of information and models do we need? Flood System

UNIVERSITY OF CAMBRIDGE INTERNATIONAL EXAMINATIONS International General Certificate of Secondary Education *7261263430* DUTCH 0515/03 Paper 3 Speaking Role Play Card One 1 March 30 April 2011 No Additional

Healthy people want everything, sick people want only one thing. would love to see a Hospital Teacher Consultant Education Sick Pupils Educational Service Centre University Medical Centre The Netherlands

*2942209982* UNIVERSITY OF CAMBRIDGE INTERNATIONAL EXAMINATIONS International General Certificate of Secondary Education DUTCH 0515/03 Paper 3 Speaking Role Play Card One 1 March 30 April 2012 15 minutes

Cambridge International Examinations Cambridge International General Certificate of Secondary Education DUTCH 0515/03 Paper 3 Speaking Role Play Card One For Examination from 2015 SPECIMEN ROLE PLAY Approx.

*3745107457* Cambridge International Examinations Cambridge International General Certificate of Secondary Education DUTCH 0515/03 Paper 3 Speaking Role Play Card One 1 March 30 April 2015 Approx. 15 minutes