An electronic post market surveillance system for medical devices

An electronic post market surveillance system for medical devices

Computer Methods and Programs in Biomedicine 71 (2003) 129 /140 www.elsevier.com/locate/cmpb An electronic post market surveillance system for medic...

1MB Sizes 0 Downloads 41 Views

Computer Methods and Programs in Biomedicine 71 (2003) 129 /140 www.elsevier.com/locate/cmpb

An electronic post market surveillance system for medical devices I. Vlachos a, D. Kalivas b, O. Panou-Diamandi a,* a

Department of Electrical and Computer Engineering, Biomedical Engineering Laboratory, National Technical University of Athens, 9 Iroon Polytechniou Str., GR-15773 Zografou, Greece b Department of Electronics, Technological Education Institute of Piraeus, 250 Thivon Str., 12244 Athens, Greece Received 25 November 2001; received in revised form 5 February 2002; accepted 5 February 2002

Abstract An important issue in the health care sector is the collection of information about adverse incidents relative to medical devices and the exchange of this information among Health Care Institutions, Manufacturers and Competent Authorities. We present an Electronic Post Market Surveillance System, which solves in an efficient and secure way the above problem and it is compliant to the International Standards. The system consists of the PMS Server Application installed in the manufacturers/suppliers premises and the PMS Client Application installed in the Health Care Institutions. The PMS applications are used for the management of the PMS Reports and Responses with important features such as the user-friendly interfaces, interoperability and different implementations depending on the performance and cost requirements. The messages are in XML format and the security is based on public /private key cryptography. The system was evaluated in a systematic way by a variety of users, who were satisfied by the system functionality and efficiency. # 2002 Elsevier Science Ireland Ltd. All rights reserved. Keywords: Post market surveillance; Medical devices; UMDNS; XML; CORBA; Public /private key cryptography

1. Introduction In the last decades, technological development has influenced the health care sector. Various types of healthcare devices and technologies have been introduced in the Health Care Institutions (HCIs). This has contributed to the improvement

* Corresponding author. Tel.: /30-1-772-3893; fax: /30-1772-2431 E-mail address: [email protected] (O. PanouDiamandi).

of treatment, but it has also raised issues on safe use and maintenance of medical devices. Furthermore, the need for appropriate reporting systems, in order to collect information about adverse incidents has been recognized worldwide. Information on these incidents needs to be exchanged among Competent Authorities, HCIs and Manufacturers, in order to deal with the consequences and prevent the reappearance of the same problems in the future. The approach for the implementation of such reporting systems varies from country to country,

0169-2607/02/$ - see front matter # 2002 Elsevier Science Ireland Ltd. All rights reserved. PII: S 0 1 6 9 - 2 6 0 7 ( 0 2 ) 0 0 0 6 0 - 3

130

I. Vlachos et al. / Computer Methods and Programs in Biomedicine 71 (2003) 129 /140

and many countries have already established their own reporting systems [1]. In the UK, a system of user and manufacturer adverse reporting already exists. Norway has a compulsory reporting system for device related events, such as accidents, near accidents and failures. Other European countries, such as Austria, Ireland and Finland have also implemented their own vigilance systems for medical devices over the last 15/20 years. Also, in the USA, the FDA has introduced the MEDWatch since 1993. This is a problem reporting system designed to ensure the safety of drugs, medical devices and other products regulated by FDA. All these reporting systems are mainly paper-based. In order to provide the means for a harmonized approach for vigilance systems the EU has issued the directives for Active Implantable Medical Devices (AIMD) [2] and Medical Devices (MDD) [3]. A medical device manufacturer is obliged to report to the Competent Authority any adverse incident, which has or could have led to death or serious harm of patients or users. This obligation is elucidated in a MEDDEV document entitled ‘Guidelines on a Medical Devices Vigilance System’ [4] issued by the European Commission. This document also describes the required details to be reported to the Competent Authority in a Member State. According to these guidelines, reports should be submitted by the manufacturer to the Competent Authority, in the country where the incident occurred, within a specific amount of time. Competent Authorities have to monitor the effectiveness of the manufacturer’s follow-up on reported incidents and take any further action that may be necessary to supplement the actions of the manufacturer. At the end of the investigation, any necessary information should be disseminated to all other Competent Authorities and the Commission. It is obvious that the medical device directives have imposed new requirements and the need for a harmonized approach and cross-national exchange of information has been recognized. Effective and efficient data handling and exchange tools are required. The use of information systems in the reporting procedure would increase the effectiveness and efficacy of the whole procedure.

The motivation for the development of the PMS System was to build a full electronic system for reporting adverse incidents, in order to facilitate the whole reporting process. The system covers a big part of the reporting procedure and provides facilities to the involved parties, which reduce the time spent on the procedure. An important requirement for the system was to comply with the European directives on medical device incident reporting, so that it could be used by different users all around Europe for a long period of time. Securing the whole procedure to the maximum degree was also an essential requirement, due to the confidential information that may be included in the reports.

2. System functionality The system is aiming at a variety of end users: (1) Health Care providers, (2) Manufacturers, suppliers or Authorized Representatives of Medical Devices and (3) Competent Authorities and Notified Bodies. The different users of the PMS System and the communication flow among them are shown in Fig. 1. The Health Care providers may vary from a single physician who will use the system in his private office, to large HCIs where the system will be used in a variety of places in their premises. More specifically, in a HCI clinicians and paramedics are the end-users of medical devices. They report on device related problems experienced during the use of the device(s) concerned. The clinical engineering departments are responsible for the maintenance of medical equipment. These clinical engineers generate reports on device problems discovered during acceptance tests and/or maintenance. The Manufacturers, suppliers or Authorized Representatives of Medical Devices receive incident reports from health care institutions. They have to decide on the follow-up of these reports. They can inform the relevant Competent Authority, inform their suppliers (in case of manufacturers), inform other health care institutions that use the medical device concerned and respond to the source of the report.

I. Vlachos et al. / Computer Methods and Programs in Biomedicine 71 (2003) 129 /140

131

Fig. 1. Communication diagram of the PMS System. It presents the different users of the system and the exchange of information among them.

The Competent Authorities and Notified Bodies receive reports on serious incidents involving medical devices, submitted by the manufacturers or the HCIs. Generally, they have to monitor the manufacturer’s investigation and intervene, whenever necessary. Although Competent Authorities and Notified Bodies are potential users of the system, the first version of the system that is currently available has not included them. However, all the other involved parties can prepare all the necessary documents that are needed for the communication with Competent Authorities according to their national policy. The PMS System is divided into two subsystems (1) the PMS Server Application, which is installed in the manufacturers/suppliers premises and is used for the management of the PMS Reports and Responses concerning the manufacturer’s devices and (2) the PMS Client Application, which is installed in the Health Care Institutions and is used for the management of the local PMS Reports and Responses. The PMS Server functionality (Fig. 2) includes the collection of reports from healthcare organisations related to medical devices issues, the handling of the responses to these reports with instructions for problem correction, the broad-

casting of messages to the corresponding healthcare organisations and the preparation of final reports for the Competent Authorities. The PMS Client (Fig. 3) is hosted in the healthcare organization site. It can work off line in order to collect reports from the users of the medical devices and send them to the corresponding PMS Servers. The PMS Client offers an interface for registration of the medical equipment installed in the organization premises and their relation to other devices, an interface for report registration, evaluation and distribution, the receipt of the manufacturer responses and the preparation of reports for the Competent Authorities. In the development of the above applications, security issues were faced, concerning authorization, authentication, and data integrity. Authorization, also referred to as access control service, guards against improper, unauthorized access to data or to a computer resource. Authorization establishes what a user is allowed to do. In our system, authorization is handled on the application level. The user names and passwords are stored in the database and the users need to insert a valid combination when the application starts. If they fail to provide it, the application terminates. Authentication provides assurance for the claimed

132

I. Vlachos et al. / Computer Methods and Programs in Biomedicine 71 (2003) 129 /140

Fig. 2. The PMS Server functionality. The registered user logs in the system and performs a variety of functions. The users with full permissions (advanced users) can perform all operations, including updating or deleting information. The users with limited permissions can only retrieve information without making any changes.

identity of a user. It verifies that you are who you claim you are. Integrity protects against improper modifications to messages, duplication of messages, insertion of superfluous messages in message sequences, deletion of part or all of messages in a sequence, or reordering of parts of a message sequence. Authentication and data integrity mainly concern the exchanged messages and are covered with the use of cryptography. Finally, an agreed and widely used nomenclature system for the identification and description of medical devices in general terms was needed, allowing collation and data exchange across Europe. Given that the Universal Medical Devices Nomenclature System (UMDNS) [5] is already widely used in Europe and is adopted by the European Commission as interim standard, it was used in the system as the classification basis.

3. System components As described above, the system was designed as two independent applications that have the ability to communicate and exchange information. Each user of the system is completely independent. The two applications have generally the same architecture, but each of them is fine-tuned to cover the specific needs of its users. The main components of both the applications are: . The end user interface. . The RDBMS. . The communication module. The architecture of the system, along with the technology used, is shown in Fig. 4 and is presented in greater detail in the following sections.

I. Vlachos et al. / Computer Methods and Programs in Biomedicine 71 (2003) 129 /140

133

Fig. 3. The PMS Client Functionality. The registered user logs in the system and performs a variety of functions. The users with full permissions (advanced users) can perform all operations, including updating or deleting information. The users with limited permissions can only retrieve information without making any changes.

Fig. 4. The architecture of the system and the technologies used. Both the PMS Server and PMS Client Applications follow the clientserver architecture. The client applications are connected to the Database Server with the use of JDBC. All software has been developed in Java.

134

I. Vlachos et al. / Computer Methods and Programs in Biomedicine 71 (2003) 129 /140

3.1. The user interface The design of an efficient and user-friendly interface is very important for all computer-based applications. In the case of the PMS System discussed here, the different types of users of the system, makes the design even harder. An important point in this case is the fact that many of the users may not have advanced computer skills, or enough time for extensive training. The application that most people use, even if they do not have advanced computer skills, is an email client. Since the PMS applications function as specialised e-mail clients with additional functionality in some areas, it was decided that the user interface should follow the rules of the common email clients, customised and adjusted for the special needs of the PMS System. The main screen of the PMS Client application is shown in Fig. 5.

Its similarity to an e-mail client application minimises the need of training The user interface of the PMS server application was also designed in a simple and user-friendly way. Two screenshots of the PMS Server application are shown in Figs. 6 and 7. Furthermore, the PMS applications have a complete help system that can guide the users for any operation. The main screen of the PMS Server Help System is shown in Fig. 8. In order to permit interoperability with different Operating Systems and to reduce the cost of the applications, all the software was developed in Java [6]. 3.2. The RDBMS Both applications provide local storage of data. This includes administrative data that are neces-

Fig. 5. The PMS Client Application Main Page. The user interface is similar to the common email clients, such as Microsoft Outlook Express. Therefore, the time required for familiarization with the application is minimized.

I. Vlachos et al. / Computer Methods and Programs in Biomedicine 71 (2003) 129 /140

135

Fig. 6. The form used for Device Registration (PMS Server Application). Through this interface the users of the application can insert to the database information about their medical devices.

sary for the preparation of reports, and the incident related data of the reports and responses. The administrative data include . Data for the medical devices for which the PMS procedure is carried out. The PMS messages need to include very specific information for the device related to the reported incident (like production or serial numbers). In order to provide a common nomenclature to all the users of the system, the information stored on devices also includes a unique device category name, according to UMDNS. . Data for the participants in the PMS procedure and communication, like HCIs, Competent Authorities or manufacturers. This is necessary for the automation of the preparation and dispatch of the PMS messages.

. Information about the users of the system. The PMS facilities are only available to designated users, who have the knowledge and responsibility to create and dispatch PMS messages. . Additional auxiliary information that is helpful for the preparation and processing of the PMS messages. The database also holds all the actual data of generated reports and responses on adverse incidents, in order for the users to have a complete history on the use of the medical devices. Each report and response is associated with a medical device, one or more manufacturer and/or suppliers and one or more HCIs. During the design and development of the Database, special care was given to the issue of interoperability, since many of the potential users

136

I. Vlachos et al. / Computer Methods and Programs in Biomedicine 71 (2003) 129 /140

Fig. 7. Preview of a final report, prepared for a Competent Authority (PMS Server Application). The application permits the preparation of reports for the Competent Authority. The reports include all the necessary information and the users can print and send them by fax or regular mail.

of the system may already have an RDBMS installed, which they would probably want to use for the PMS system. Furthermore, the issue of cost is quite important, since some of the users may not afford the cost of an expensive RDBMS. In order to provide the ability of easily working with different databases, the JDBC interface was used to build the connection to the database. Special care was also given in designing the applications in a way that would permit the development of new versions for different RDBMSs with minimum changes in the code. During the development phase three different RDBMSs were used and different versions of both the PMS Server and PMS Client applications were developed, proving that the design was easily adaptable. We used Microsoft Access, Microsoft SQL Server 7, and Oracle 8. Therefore, the system provides various

combinations of cost and performance, to satisfy the needs of almost every possible user. 3.3. The communication module One of the main aspects of the PMS System is the communication among the different parties. An efficient and low cost mechanism is needed, in order to handle the information exchange. The PMS Reports and Responses are transferred among the different users of the PMS system, with the use of the e-mail protocol. E-mail was chosen because it provides a stable and effective method of communication, which covers the requirements of the PMS System. Additionally, it is an offline communication mechanism, which does not require a full time connection to the Internet, and can, therefore, reduce the cost. The

I. Vlachos et al. / Computer Methods and Programs in Biomedicine 71 (2003) 129 /140

137

Fig. 8. The main screen of the PMS Server Help System. Both the PMS Client and the PMS Server Applications include complete Help Systems, which give information for their use.

reports can be prepared whenever necessary and can be sent at anytime. A disadvantage of the email as a communication mechanism is that there is no guarantee about the time that a message will need in order to reach the recipient, although in most cases of reporting, this is not a very important factor. However, in order to provide an electronic means of communication even in these few cases, an additional mechanism has been implemented that gives the ability for online and real time communication. This mechanism uses Corba [7] technology to give instant communication among HCIs and manufacturers/ suppliers of medical devices. All the communication modules were developed in Java. The email software supports the SMTP protocol for sending e-mail messages and the POP3 protocol for receiving. The messages are formatted with special headers. The applications

read the email messages in the designated e-mail account, recognizes those that are part of a PMS communication and retrieve only the latter. Any email messages not relevant to a PMS communication remain unharmed. In this way, the system does not require a special email account, but it can use an existing one. In order to further facilitate the exchange of PMS messages and to make the system compatible with future technology developments, the contents of the e-mail messages are formatted with the use of extensible Markup Language (XML) [8,9] tags. This facilitates the storage and retrieval of data from/to the database, while it makes the messages easy to use for other purposes. For example, it is much easier to use the XML documents in order to publish the information on the Internet. An example of an XML formatted PMS Report is shown below:

138

I. Vlachos et al. / Computer Methods and Programs in Biomedicine 71 (2003) 129 /140

B/PMS_REPORT / B/HOSPITAL_INFO / B/CD_IN_KRHCI / 1 B//CD_IN_KRHCI/ B//HOSPITAL_INFO / B/PMS_DATA / B/HCI_REPORT_CD/ 55 B//HCI_REPORT_CD / B/DEVICE / B/MANUF_PRODUCT_CD / 2511 B//MANUF_PRODUCT_CD / B/HOSPITAL_PRODUCT_CD / 4 B//HOSPITAL_PRODUCT_CD / B/DEVICE_NAME / Name of the Device B//DEVICE_NAME / B/SERIAL_NUMBER / 24545 B//SERIAL_NUMBER / B/LOT_NUMBER / 69234AFDF B//LOT_NUMBER / B//DEVICE / B/INCIDENT / B/INCIDENT_DATE / 2000-12-28 00:00:00.0 B//INCIDENT_DATE / B/INCIDENT_DESCRIPTION / Description of the incident B//INCIDENT_DESCRIPTION / B/INCIDENT_CATEGORY / Adverse Incident B//INCIDENT_CATEGORY / B/INCIDENT_CATEGORY_CD / 1 B//INCIDENT_CATEGORY_CD / B/RESULT / Result of the incident B//RESULT / B/COMMENTS/ Additional comments B//COMMENTS / B/REPAIR_STATUS / Repair Status B//REPAIR_STATUS / B//INCIDENT / B//PMS_DATA / B//PMS_REPORT /

Due to the nature of the information contained in the messages a security mechanism is necessary. The software for encryption-decryption was developed in Java using the toolkit Cryptix [10]. Cryptix is an international volunteer effort to produce robust, open-source cryptographic software libraries. Cryptix products are free, both for commercial and non-commercial use and are being used by developers all over the world. Cryptix provides support for a variety of algorithms, both for symmetric key cryptography and public-private key cryptography. The PMS security is based on public-private key cryptography. Each participant in the PMS System (manufacturer or HCI) has a pair of keys, one private and one public. The public key is publicly available, while the private should remain secret. When a participant in the system needs to send a message to another participant, the message is first

signed with the private key of the sender and then encrypted with the public key of the recipient, so only the recipient will be able to decrypt it, by using his/her private key. In this way, the message is both signed and encrypted, so the recipient is certain that the message originates from the real sender and that nobody has seen the content. The encryption software provides facilities to automatically send and receive e-mail messages, after encrypting (or decrypting) them. A schematic representation of the Encryption/Decryption procedure is shown in Figs. 9 and 10.

4. Pilot evaluation During the project MEDICOM [11], a variety of users, who cover the whole range of use of medical devices, tested the applications. The ISO/IEC 9126

I. Vlachos et al. / Computer Methods and Programs in Biomedicine 71 (2003) 129 /140

139

Fig. 9. Procedure followed for encrypting a report. The XML-formatted report is first signed with the private key of the sender and then encrypted with the public key of the recipient. This procedure ensures that only the intended recipient will be able to read the message. Furthermore, the recipient can verify the identity of the sender.

‘Information Technology-Software product evaluation-Quality characteristics and guidelines for their use’ [12] has inspired the evaluation procedure. Additionally, simple questionnaires were used for the assessment of the user satisfaction. A set of usability metrics was chosen, in order to measure the effectiveness of the system. These include the time needed to complete a task, the percentage of the task completed, the ratio of successes to failures, the time spent in errors, the number of commands used, the frequency of help and documentation used, the number of repetitions of failed commands, the number of times the interface misleads the user and the number of available commands not used. The pilot users of

the system completed a number of reports, which were broadly based on the ‘Common Industry Format for Usability Test Reports’ [13]. The overall opinion of the users was very satisfactory. Their conclusion was that the PMS system improves the organization of Reports and Responses, and that it allows to prepare a report in less time as compared with the standard procedure used until now. They found the user interface effective and they asked only for minor changes. The Help system provided was also found satisfactory. Finally, the time needed for the communication with the other parties of the PMS reporting procedure was reduced significantly.

Fig. 10. Procedure followed for decrypting a message. The recipients use their private key to decrypt the message and the sender’s public key to verify its origin. This procedure ensures that only the intended recipient can read the message.

140

I. Vlachos et al. / Computer Methods and Programs in Biomedicine 71 (2003) 129 /140

5. Conclusions The Post Market Surveillance system, presented in this paper, provides an effective and secure way to handle the PMS data that need to be circulated among the Health Care Institutions, the manufacturers, the suppliers and authorized representatives. The traditional way of sending reports through ordinary mail or fax is replaced with electronic means of communication and data storage. The system was evaluated by a variety of users, who concluded that the efficiency of the mechanism is strengthened and the response times are shortened.

Acknowledgements This work was partially supported by the ESPRIT project MEDICOM [13]. Partners in the MEDICOM project were ICCS-NTUA and Epograf Ltd from Greece, Selisa S.A. from France (project coordinator), TNO (Netherlands Organization for Applied Scientific Research) from Netherlands, AUSL Modena (Health Care Organization of the Public Service in the Province of Modena) and ESAOTE S.p.A. (manufacturer of medical devices) from Italy, and Pixelpark from Germany. We would like to express our thankfulness to all participants in the project for their fruitful collaboration. Especially we would like to acknowledge TNO for their contribution to the

definition of the PMS concept and AUSL and ESAOTE for the systematic system evaluation.

References [1] N. Pallikarakis, N. Anselmann, A. Pernice, Information Exchange for Medical Devices, IOSPress, 1996. [2] ‘Council Directive 90/385/EEC of 20 June 1990 concerning active implantable medical devices’, Official Journal of the European Communities, L189. [3] ‘Council Directive 93/42/EEC of 14 June 1993 concerning medical devices’, Official Journal of the European Communities, L169, ISSN 0378-6978. [4] Guidelines on a Medical Device Vigilance System, Commission of the European Communities, L169, ISSN 03786978. [5] Medical Product Purchasing Directory with Official Universal Medical Device Nomenclature System, Health Services Sourcebook, ECRI, ISBN 0-941417-50-6. [6] ‘Java Technology’, http://www.javasoft.com/ (current Apr. 15, 2002). [7] ‘Object Management Group’, http://www.omg.org/ (current Apr. 15, 2002). [8] ‘World Wide Web Consortium’, http://www.w3.org/ (current Apr. 15, 2002). [9] ‘The XML Industry Portal’, http://www.xml.org (current Apr. 15, 2002). [10] ‘Cryptix’, http://www.cryptix.org (current Apr. 15, 2002). [11] Project Program ‘MEDICOM’ (Medical Products Electronic Commerce)-Annex 1, ESPRIT IV PROJECT 25289, financed by the Commission of the European Communities. [12] ‘International Organization for Standardization’ http:// www.iso.ch (current Apr. 15, 2002). [13] ‘Industry Reporting Usability project’ http://zing.ncsl.nist.gov/iusr/ (current 15 April 2002).