Towards a Logic-Based Extension of a Relational Software Tool for Coherent Technical Documentation of Medical Devices

This work presents a novel software tool intended to support compilation of coherent technical documentation. It is based on a relational database system serving as knowledge base incorporating information from the European Medical Device Directive and harmonized standards such as ISO 14971, ISO 980 or ISO 10993-x. In order to achieve increased consistency among sections of documentation for medical devices, a concept for formal description of technical documentation and an additional logic-based system is presented.

Editor’s Note

The paper on which this article is based was originally presented at the 2015 IEEE Product Safety Engineering Society Symposium, where it received recognition as the Best Symposium Paper. It is reprinted here, with permission, from the proceedings of the 2015 IEEE Product Safety Engineering Society International Symposium on Product Compliance Engineering. Copyright 2015 IEEE.

With 89% of all revenue in the worldwide medical device industry earned by only 30 companies, 11% of sales revenue accounts for the remaining 27.000 medical device companies around the globe, which vastly categorize as small to medium size enterprises (SME) [1]. Recent studies revealed that particularly these SMEs assess current medical device certification processes as fourth biggest obstacle to innovation [2], although particularly these smaller companies are seen as most innovative [1]. On the contrary complexity of medical devices [3] together with the number of adverse events [4] [5] is continuously increasing.

Manufacturers of medical devices are confronted with various processes and documentation requirements in order to market medical devices in the European Union. Besides quality management requirements such as production and order management, vigilance and market observation, together with thorough customer management, regulatory processes for certification represent mandatory tasks for each manufacturer. An excerpt of these processes is illustrated in Figure 1. In the European Union the certification process of medical devices is regulated by the Medical Device Directive 93/42/EEC (MDD) [6].

Content of Technical Documentation

Technical documentation is the fundament to prove conformity with essential requirements stated in Annex I of the MDD. Depending on its potential risk to users and patients, determined by its device class (I, IIa, IIb, III), technical documentation is subject to thorough evaluation by Notified Bodies.

A basic description of the necessary content of technical documentation is given in Annex VII of the MDD. Further examples for the structure and setup of technical documentation are given in [7], [8] and [9].

State of the Art—Tools for Generation of Technical Documentation

Technical documentation is often generated manual and paper-based [10]. Microsoft Word and Excel are also commonly utilized [11], [12]. Beyond text editors, IBM DOORS, SAP and HP Mercury Quality Center are utilized to perform risk assessment, traceability of control measures and documentation management [12]. Further tools are Qware Riskmanager [13].

Deficits of State of the Art

Manual, paper-based documentation is error-prone, not scalable and can cause inconsistency as well as redundancy among data sets [13]. Spreadsheets and macros are two dimensional and only offer limited and inefficient access to information [14].

None of the above mentioned tools specifically focuses on technical documentation and dependencies among its sections. Various tools concentrate on one specific process, such as for example risk analysis, but do not allow linking to other sections, such as user information or system components. This causes use of various modalities and software tools and ultimately causes inefficient data maintenance and consistency.

In an evaluation of 21 technical documentations of separate manufacturers, Roszek et al [15] found inadequate reciprocity among sections in 70% of all 21 documentations. These were especially noteworthy for risk analysis, user information and market observation. Other deficits were unsatisfactory labeling with no information on residual risks or contact details. System descriptions and aspects of combination with other devices had short comings in reciprocity with risk analysis. Similar sources for errors, e.g., poor labeling or product manuals, are mentioned in [3].

Objective
Specifications

This work is part of the development of a software tool to support the process of compiling technical documentation according to the MDD, 93/42/EEC. We aim to overcome deficits mentioned above with the development of a software tool based on a relational database application. We aim to meet the following specifications:

• Increasing data consistency and reduce redundant data sets within technical documentation, e.g., central implementation of harmonized standards and their revision for up-to-date cross- references to harmonized standards in all documents;
• Increasing reciprocity and coherence between sections of technical documentation by relational links and methods of truth-maintenance systems, e.g., automatic mentioning of residual risks of the device from section risk analysis in section user information such as instructions for use and labeling;
• Tracking of alterations and checking for consistence/truth maintenance of technical documentation, e.g., altering of intended use from “no contact to injured skin” to “contact with injured skin” and implications on parameters such as medical device class (I, IIa, Iib, III), biocompatibility tests according to ISO 10993-1 [16] and hazards in risk analysis according to
  ISO 14971 [17];
• Semi-automatic generation of sections of technical documentation by information and data sets of related sections, e.g., conclude on applicable and not applicable hazards for risk analysis from device parameters specified within its classification according to Annex IX of the MDD.

Advantages

With the implementation of the specifications mentioned above, we see the following advantages for the development process of medical devices and the generation of their respective technical documentation:

• Increased safety of medical devices based on consistent and comprehensive documentation, for example sections such as user information, labelling, risk analysis and tests are interrelated;
• Simplification of further development of devices already certified and placed on market by enabling to implement consistent and transparent alterations to the device and its technical documentation;
• Reduction of time needed for compiling technical documentation and ultimately for the certification process.

Structure of Software Tool

The software is based on a relational database schema, which allows relational linking of data sets and entities. As illustrated in Figure 2, the database system in the center orchestrates information about the medical device from various sources.

The tool implements information from the MDD and makes it easily accessible for the user. Furthermore it incorporates information about essential requirements in Annex I and their applicability as well as a linkage to harmonized standards to proof conformity.

Besides information from the MDD, the database system compromises data and processes according to harmonized standards. One of these processes is risk management according to ISO 14971. The tool allows structured risk analysis incorporating information from other sections of the technical documentation such as classification parameters, user manual, system components and market observation by relational links.

It furthermore interacts with a software development platform (MATLAB©, MathWorks Inc.) and a CAD tool (CATIA©, Dassault Systèmes Inc.)

Relational Data Model

For the knowledge base of the software, a relational data model was implemented.

The current implementation of the software tool allows structured entry of sections such as classification (as described in [18]), system description in a component tree with linking to a list of purchased parts, product and installation manual, risk management, labeling and declaration of conformity. It furthermore supports maintenance and a list of harmonized standards together with customer, OEM and competent authority management.

These processes are relationally linked to allow basic coherence between sections as for example ensure correct manufacturer details (address, project title picture, etc.) on each file or up-to-date harmonized standards of the documentation (risk analysis, user manual, product manual) by central modeling. Also warnings about residual risks can be directly connected to chapters of the user manual to increase coherence as depicted in Figure 3.

Even though basic coherence is implemented with the current relational links, no conclusions or evaluations about consistency of entered information is possible. We therefore propose a second level, logic-based system that can evaluate and draw conclusions on entered data sets and implications.

Logic-Based System

The software tool consists of two separate sub-systems. First, a relational database that implements the above mentioned information about the medical device and represents the knowledge base of the software. Second, a logic-based system [19], [20] and [21] that implements rules and logical assertions about the information of the knowledge base mainly by IF-THEN rules. This logic-based system evaluates modifications made to the database for logic consistency and gives user feedback in case of logic disruption.

Parameters for Description of Medical Devices

We propose the following formal description of sections of technical documentation in order to allow the database system to derive information about consistency and use available information to conclude on related sections.

Mandatory classification of a medical device according to Appendix IX of the MDD is a set of 56 rules [18], [22] and [10]. An implemented algorithm for semi-automatic classification based on user inputs v_n returns a defined set P_Class generally describing the device:

f : Classification(v_n ) → P_Class (k_i )       (1)

Thereby k_i is the criteria with currently k_i; 1 < i < 21 and n_ki is the number of values for criteria k_i. For each classified device a list of the parameters is returned. Parameters for k_i: 1 < i < 7:

• k₁ = Invasivity I = {non-invasive, intact skin, injured skin, body orifice, surgically invasive, implant}
• k₂ = Body Orifice BO = {oral cavity till pharynx, ear canal till ear drum, nasal cavity}
• k₃ = Surgical Invasivity SI = {central nervous system CCS, central nervous system CNS, bone B, dentin D}
• k₄ = Duration D = {transient (<60 min), limited (>60 min ^ <24 hours), short-term (>24 hours ^ < 30 days), long-term (>30 days)}
• k₅ = Activity A = {active, non-active}
• k₆ = Active Device AD = {active therapeutical, active diagnostical}
• k₇ = Connectivity C = {no connectivity, connectivity to medical device class I, connectivity to medical device class IIa ^ IIb ^ III}

Further parameters of k_8-21 are administration/removal of liquids, software, human blood derivative and others.

The set of parameters from Annex IX given by P_Class will be extended by a set of parameters P_Missc that further describe the device in detail. These parameters origin from Annex I, Annex VII and Article 1 of the MDD, together with harmonized standards ISO 60601-1, ISO 10933-1, ISO 1041 and DIN EN 980:

• g₁ = Measurement Function MF = {yes, no}
• g₂ = Device Type DT = {medical device, medical device supply}
• g₃ = Product Type PT = {for clinical investigation, for marketing}
• g₄ = Sterility S = {sterile product, non-sterile product}
• g₅ = Reusability R = {single use device, multiple use device}
• g₆ = Connectivity Type CT = {electrical, mechanical}

Together they build the set P_MedDev : = P_Class ∪ P_Missc, which is a comprehensive formal description of the device.

Logic-Based Conclusions

Hazards for Risk Analysis

Similar to classification, a formally described repository of generic hazards for risk analysis was implement as illustrated in excerpts in Figure 6. It is defined by the set P_Hazards (r_i ), with r as risks. Hazards are currently derived from harmonized standards such as IEC 60601-1 Attachment H7 [23], IEC 61784-3-2 Section 5.3 [24], ISO 14971 Attachment E2, IEC 62366 Section 5.1.2.2 [25], ISO 62304 Section 7 [26] and IEC 10993-1 Section 4.3.

For a given set P_MedDev, a subset P_{Hazards-MedDev} can be derived according to

P_MedDev → P_{Hazards-MedDev}      (2)

For example, each device that is characterized as k₅ = active device automatically correlates with hazards P_Hazards of category electrical, such as leakage current. In case it is characterized as having a connectivity k₇ ! = no connectivity and g₆ = electrical hazards of category electrical are applicable and can automatically show up in the risk analysis for consideration.

Tests According to Harmonized Standards

In order to conclude on tests according to harmonized standards, information from these standards has to be incorporated in a formal description. One example is ISO 10993-1 [16] regarding biological evaluation of medical devices. Table 1 of Attachment A (excerpts given in Table 1 on page 34) describes a matrix of tests for consideration. Necessary tests are defined by a general category, the exact contact type and contact duration. With knowledge of these parameters, tests to proof biocompatibility and show conformity with essential requirements of Annex I, Category II.7., regarding chemical, physical and biological properties are defined.

In the same manner as potential hazards depending on device classification parameters can derived, automatic analysis of test for proof of biocompatibility are retrievable from the subset

P_{Biocomp-MedDev} = (k₁, k₃ , k₄) ⊂ P_MedDev

which maps

P_{BiocompMedDev} → P_Biocomp      (3)

In the same manner, applicable and non-applicable essential requirements, harmonized standards to apply, sections of the product manual or the correct competent authority can be retrieved.

Evaluation

A risk management file, product manual and system description were generated for two unlike devices. First, a measurement device for quantifying motor symptoms in

Parkinson’s disease [27]. Second, a multi-arm, snake-like robot for Natural Orifice Transluminal Endoscopic Surgery (NOTES) [28]. For each device technical documentation was successfully compiled and will be used in further steps towards clinical investigation.

Conclusion

This work describes the concept for a logic-based software tool intended to support compilation of technical documentation of medical devices. By formal representation of a medical device, those formal parameters can be logically related among each other in order to increase consistency among data sets and thus improve quality of technical documentation and simply further development of devices. First implementations and generations of technical documentation have proven promising for further investigation and experimentally evaluation regarding usability of the tool and quality of generated documentation.

Acknowledgements

The German Ministry for Education and Research (BMBF) funded this research under Grant 16KT1202. The authors wish to thank Johannes Coy and Luis Hopf for their contributions to this work.

References

1. WHO, World Health Organization – Medical devices: managing the mismatch: an outcome of the priority medical devices project: World Health Organization, 2010.
2. VDE, VDE-Studie MedTech 2020. Frankfurt am Main: Verband der Elektrotechnik Elektronik Informationstechnik e.V., 2009.
3. WHO, World Health Organization – Increasing complexity of medical technology and consequences for training and outcome of care, 2010.
4. R. Kramme, Medizintechnik: Springer-Verlag, 2011.
5. C. Backhaus, “Defizite durch eine unzureichende Gebrauchstauglichkeit,” in Usability-Engineering in der Medizintechnik, ed: Springer, 2010, pp. 21-28.
6. Commission of the European Communities, Council Directive 93/42/EEC concerning medical devices – Rev. 2007, 1993.
7. F. Capanni, A. Steffen, and J. Stockhard, Medizinprodukte planen, entwickeln, realisieren – Der CE-Routenplaner. Köln: TÜV Media GmbH, 2014.
8. R.C. Fries, Reliable design of medical devices: CRC Press, 2012.
9. ISO, “ISO 13485:2014 – Draft – Medical devices – Quality management systems – Requirements for regulatory purposes,” 2014.
10. N. Leitgeb, “Sicherheit von Medizingeräten. Recht-Risiken-Chancen,” 2010.
11. A. Steffen and D. Hientzsch, “Software-Based Risk Management Documentation for Medical Devices,” Biomedical Engineering/Biomedizinische Technik, 2013.
12. V. Hegde, “Case study—Risk management for medical devices (based on ISO 14971),” in Reliability and Maintainability Symposium (RAMS), 2011 Proceedings- Annual, 2011, pp. 1-6.
13. A. Steffen and D. Hientzsch, “Software-Based Risk Management Documentation for Medical Devices,” Biomed Tech, vol. 58, p. 1, 2013.
14. C. Carlson, Effective FMEAs: Achieving safe, reliable, and economical products and processes using failure mode and effects analysis vol. 1: John Wiley & Sons, 2012.
15. B. Roszek, A. v. Drongelen, R. Geertsma, and E. v. Tienhoven, “Assessment of technical documentation of Annex II medical devices,” 2005.
16. ISO, “10993:2009 – 1 – Biological evaluation of medical devices Part 1: Evaluation and testing within a risk management,” 2009.
17. ISO, “ISO 14971:2013 Medical devices – Application of risk management to medical devices,” 2013.
18. T. Lueddemann, J. Schiebl, H. Bebert, and T. C. Lueth, “Dynamic Generation of Technical Documentation for Medical Devices,” in IEEE International Conference on Robotics and Biomimetics (Robio), Bali, Indonesia, 2014, p. in press.
19. C. Beierle and G. Kern-Isberner, “Methoden wissensbasierter Systeme,” Auflage. Vieweg, 2008.
20. K.D. Forbus, Building problem solvers vol. 1: MIT Press, 1993.
21. R. Akerkar and P. Sajja, Knowledge-based systems: Jones & Bartlett Publishers, 2010.
22. MEDDEV2.4/1rev.9, “MEDICAL DEVICES: Guidance document – Classification of medical devices,” 2010.
23. IEC, “60601: 2012 Medical electrical equipment – Part 1: General requirements for basic safety and essential performance,” 2012.
24. IEC, “61784-3-2: 2010 Industrial communication networks – Profiles – Part 3-2: Functional safety fieldbuses,” 2010.
25. IEC, “IEC 62366:2012 Medical devices – Application of usability engineering to medical devices,” 2012.
26. IEC, “IEC 62304:2012 Medical device software – Software life cycle processes,” 2012.
27. Johannes A. Coy, Jan H. Mehrkens, Daniel B. Roppenecker, and T. C. Lueth, “Finding the Center of Parkinson’s Disease; A Novel Measurement Device for Quantifying Motor Symptoms During DBS-Surgery,” in in IEEE International Conference on Robotics and Biomimetics (Robio), Bali, Indonesia, 2014.
28. D. B. Roppenecker, M. F. Traeger, J. D. Gumprecht, and T. C. Lueth, “How to Design and Create a Cardan Shaft for a Single Port Robot by Selective Laser Sintering,” in ASME 2012 International Mechanical Engineering Congress and Exposition, 2012, pp. 49-58.