Med-Trace: traceability assessment method for medical device software development

Software to be used in or as a medical device is subject to user requirements. However, unlike unregulated software, medical device software must meet both the user’s requirements and the requirements of the regulatory body of the region into which the software will be marketed. Regulatory requirements are fixed and can be planned for; unfortunately, the same is not true with user requirements. As many medical device software development organisations are following traditional sequential Software Development Life Cycles (SDLC), they are experiencing difficulties accommodating changes in requirements once development has begun. Agile methods and practices offer the ability to overcome the challenges associated with following a sequential SDLC. Whilst the regulatory requirements are fixed, this paper presents these requirements and shows how they appear to mandate the use of a sequential SDLC. This paper also explains how agile methods and practices can be successfully adopted in the development of medical device software without hindering the process of achieving regulatory approval.

Despite mobile medical apps becoming an increasingly important part of the healthcare industry, developers still find it challenging to understand what exactly is required when a mobile healthcare application fulfils the definition of a medical device both in terms of safety and security. To date, the authors have developed and piloted a medical device software process framework called MDevSPICE® that integrates processes from various medical device software standards as well as generic software development best practice standards. This paper describes current research that extends the MDevSPICE® framework to assist organizations developing mobile application software that meets the definition of a medical device and therefore has to be developed in compliance with medical device regulations. This can be a challenge for developers of mobile applications as such applications are normally developed in a much faster and less documented manner than traditional prescribed and plan driven medical device software development. We will describe our approach that increases the flexibility of the MDevSPICE® framework through replacing rigid plan-driven practices with agile practices that are more suitable for the development of mobile medical applications.

Medical Software Quality Regulations have been developed through a concern for patient safety, outcome and care. From our research on a variety of projects, which includes observation within hospitals and clinics, we can demonstrate that there are many situations in which regulations and directives regarding medical device software are not being taken into account, and unregulated software is developed and used in healthcare organisations. This happen mainly because people, not trained in software engineering within a lack of knowledge in regulations develop software solutions for healthcare. In addition, healthcare professionals are unaware of regulations and the effect unregulated software may have on patient and practitioner alike, and so use these systems.Software Engineers have a role to play to solve this problem. We recommend that, healthcare software systems are developed by professional software engineers in interdisciplinary teams with healthcare professionals. Software engineering and healthcare academics can collaborate on the development of modules within healthcare courses and the development of specialist courses. Through these, healthcare professionals will be educated on the value of software engineering practices and principles, and on the requirement for regulation in the development of medical device software. Software engineering courses should include topics focused on Medical Device Software development.

Medical device standards provide effective technique foundation for supervision to ensure medical device safety for the people. With the optimization and upgrading of the medical device industry, the medical devices standard system including law and regulation system, organization management system, and technical management system has been advanced and developed. According to the requirements of the development of medical device industry and its standards, we put forward four working ideas, in order to improve the scientificity and applicability of medical device standards.

In medical devices, nonconformance with Digital Imaging and Communications in Medicine (DICOM) standard is a serious risk. DICOM nonconformance radiology devices could cause undetected image loss, increasing examination time, and costs in health centers and could even result in the wrong patient treatment. However, there is a rich literature on medical standards that identify the best practices for producing safe and effective medical software. However, these standards do not expressly provide tools to deal with all the relevant DICOM compatibility issues in a specific case. This study aims to introduce a systematic software development workflow that complies with medical standards and ensures DICOM conformance of a new or upgraded radiology software project. In this approach, DICOM conformance gets the highest priority, and the whole software project is organized around it. Software requirement analysis, risk evaluation, and test management tasks are arranged systematically to make the final device DICOM conformant. This conceptual framework was developed during the R&D work towards a novel radiography device, and it could be employed as a roadmap in other medical imaging software projects. The proposed methodology controls the DICOM compatibility risk of the final software, and its systematic evaluation complied with medical standards.

AAMI TIR45:2012/(R)2018; Guidance on the use of agile practices in the development of medical device software

The amount of software content within medical devices has grown considerably over recent years and will continue to do so as the level of complexity of medical devices increase. This is driven by the fact that software is introduced to produce sophisticated medical devices that would not be possible using only hardware. This therefore presents opportunities for software development SMEs to become medical device software development organisations. However, some obstacles need to be addressed and overcome in order to make the transition from being a generic software development organisation to becoming a medical device software development organisation. This paper describes these obstacles and how research that is currently being performed within the Regulated Software Research Group in Dundalk Institute of Technology may be used to assist with this transition

While computer-related failures are known to play a significant role in deaths and injuries involving medical devices reported to the U.S. Food and Drug Administration (FDA),1 there is no similar reporting system that meaningfully captures security-related failures in medical devices.Medical device software must satisfy system properties, including safety, security, reliability, resilience, and robustness, among others. This column focuses on the challenges to satisfying a security property for medical devices: post-market surveillance, integrity and availability, and regulation and standards.Medical devices depend on software for patient care ranging from radiation therapy planning to pharmaceutical compounding to automated diagnosis of disease with mobile medical apps. Meanwhile, the medical community has observed an uptick in reported security vulnerabilities in medical device software—raising doubts of cybersecurity preparedness. It should come as little surprise that security risks in medical devices "could lead to patient harm" as recently explained by the chief scientist at the FDA Center for Devices and Radiological Health.2 Device manufacturers and healthcare providers ought to more carefully and deliberately consider security hazards during the phases from design to use of medical devices.Between years 2006 and 2011, 5,294 recalls and approximately 1.2 million adverse events of medical devices were reported to the FDA's Manufacturer and User Facility Device Experience (MAUDE) database.1 Almost 23% of these recalls were due to computer-related failures, of which approximately 94% presented medium to high risk of severe health consequences (such as serious injury or death) to patients.1 For security incidents on medical devices, no systematic national reporting system exists.3 Yet, individual hospitals know of hundreds of security incidents on medical devices.2For instance, the FDA MAUDE does not capture adverse events such as lack of or impaired availability of function when malware infects a medical device's operating system. FDA's own disclaimer explains that the MAUDE database is qualitative rather than quantitative. MAUDE is incomplete with underreporting and reporting bias.Imagine the reaction of a clinician using a high-risk pregnancy monitor that begins to perform more slowly because of a Conficker infection. Would the clinician report a malware infection? Likely not. Admitting to playing a role in accidentally infecting a medical device-would likely lead to consequences ranging from disciplinary action to loss of reputation. Thus, the actual incidence of security failures leading to healthcare delivery failures may be significantly greater than the available statistics suggest. To have a better understanding of medical device security, the bad-news diode must be shorted. Reporting must be incentivized rather than penalized.If you watch television crime dramas, you may be duped into thinking that hacking of medical devices is the number-one risk for public health today. You would be wrong. The most pressing risks are much less sexy: the unavailability of patient care and the lack of health data integrity. Here, we highlight a few examples that illustrate the consequences of unavailability and lack of integrity.Interventional radiology suites and cardiac catheterization labs contain a number of computer systems to perform time-sensitive cardiac procedures, such as angioplasty, to open blocked arteries for improved outcomes in patients suffering acute heart attacks or strokes.According to The Wall Street Journal,2 a Department of Veterans Affairs (VA) catheterization laboratory in New Jersey was temporarily closed in January 2010. Malware had infected the computer systems. The consequence? Patients do not receive the safe and effective care they deserve when malware causes unavailability of care. The VA has experienced hundreds of malware infections in medical devices such as X-ray machines and lab equipment made by well-known, reputable companies.Conficker was detected on 104 devices at the James A. Haley Veterans Hospital in Tampa.2 The affected devices included an X-ray machine, mammography, and a gamma camera for nuclear medicine studies. Conficker is a relatively old piece of malware with well-known mitigation strategies. Why does old malware persist on medical devices?We observe that one of the cultural challenges to improved cybersecurity and t herefore safety and effectiveness is a lifecycle mismatch. For instance, operating system software with production lifecycles measured in months does not match well with a medical device having production lifecycles measured in years or decades. The equivalent of a transformer for impedance matching does not yet exist for safely connecting these different production cultures.Risks of depending on unsupported software has parallels to depending on a device where parts are no longer manufactured or repaired. Medical devices still rely on the original versions of Windows XP (circa 2001). In October 2012, the Beth Israel Deaconess Medical Center in Boston reported to the NIST Information Security and Privacy Advisory Board that the hospital depends on 664 Windows-based medical devices primarily because of supply chain issues. Of the 664 computers, 600 devices run the original version of Windows XP. There are no Service Pack 1 (SP1) machines, but there are 15 SP2 machines and 1 SP3 machine. One MRI machine still runs Windows 95. Security support for SP1, SP2, and SP3 ended on October 10, 2006, July 13, 2010, and April 14, 2014, respectively. In many cases, a medical device manufacturer does not provide an effective way for hospitals to upgrade to supported versions of operating systems. Today, healthcare providers are told to maintain a secure system from insecure devices.4A medical device infected with malware can stray from its expected behavior. For instance, malware can cause a device to slow down and miss critical interrupts. When this happened on a high-risk pregnancy monitor, healthcare professionals could no longer trust the integrity of the sensor readings and depended on backup methods.5Antivirus software can help mitigate certain cybersecurity risks, but they also introduce their own risks. On April 21, 2010, a third of the hospitals in Rhode Island were forced to "postpone elective surgeries and stop treating patients without traumas in emergency rooms" because an automated antivirus software update had accidentally misclassified a critical Windows DLL as malicious. The problem with antivirus software is that by definition, antivirus software is a postmarket afterthought to make up for design flaws in the device. Antivirus software does not remove the need to incorporate security into the early design of medical devices.According to the FDA mission statement, the agency holds responsibility for protecting public health by assuring the safety, efficacy, and security of medical devices. In June of this year, the FDA issued draft guidance on cybersecurity6 and gave examples of what FDA reviewers would expect to see during premarket review. The draft guidance intentionally does not prescribe any particular approach or technology but instead recommends that manufacturers consider cybersecurity starting at the concept phase of the medical device.The FDA recommends that manufacturers provide:Standards bodies are taking actions to improve medical device cybersecurity. For instance, the Association for the Advancement of Medical Instrumentation (AAMI) recently formed a working group on medical device security that includes engineers from manufacturing and regulators. AAMI has already released standards specific to network-related cybersecurity risks (ANSI/AAMI/IEC-80001). International harmonization of cybersecurity guidance is likely on the horizon, given that phrases such as "security patches" appear in proposals from the International Medical Device Regulators Forum.Modern healthcare delivery depends on medical device software to help patients lead more normal and healthy lives. Medical device security problems are real, but the focus on hacking goes only skin deep. Consequences of diminished integrity and availability caused by untargeted malware include the inability to deliver timely and effective patient care. By addressing security and privacy risks at the concept phase, medical devices can remain safe and effective despite the cybersecurity threats endemic to computing. Security of medical devices is more than just a potential problem on the horizon.This work was supported in part by NFS CNS-1331652 and HHS 90TR0003/01. Any opinions, findings, and conclusions expressed in this material are those of the authors and do not necessarily reflect the views of NSF or HHS.

Software safety is checked today in regulatory audits, which verify software development process compliance to regulatory requirements. Ensuring safety is a critical task in complex life-supporting systems and despite many existing ways of assuring it, unanticipated failure will always be possible. Checking process compliance to required standards ensures the quality of the processes by which software is developed but does not necessarily indicate the quality of the resultant software. Since medical device domain is facing an increasing amount of device recalls due to software failures, our goal is to explore the underlying reasons for this and suggest two improvements within this paper. First, we will introduce complicated and complex systems to illustrate why there will always be unforeseeable and unanticipated situations that could cause the failure of the entire system. We will then describe how medical device software systems are reviewed for compliance and safety today, highlighting the shortcomings in the current methods adopted in the medical device domain and suggest the use of systems thinking. We then propose two improvements to medical device software development where process compliance is supported by safety cases and industry-wide learning from experience.

Ethical issues occupy a special place when conducting clinical trials of medicines, where it is impossible to predict in advance and accurately the effectiveness and safety of a new drug on the human body. Currently, during clinical trial examination, attention is paid to patients quality of life, and issues of compliance with patients rights, as well as compliance with the rules of good clinical practice and current legislation. Thanks to technological development, the number medical studies and devices using, among other things, specialized medical technologies and software is increasing.
 Automation, development, improvement, and structuring of the processes involved cause an increase in the use of technical devices that use not only programs but also systems in their work. Artificial intelligence system software have a special place in medical science development.
 Artificial intelligence, which was the field of science fiction 5080 years ago, is now firmly embedded in our everyday life. By introducing artificial intelligences capabilities into medical software, using it as part of medical equipment, and developing medical devices with artificial intelligence systems, we get a product that requires careful study and further development, which includes a complex of works on conducting scientific research, and registration and maintenance of such systems and complexes. All work is regulated by legislation in the field of circulation of medical devices and requires a deep systematic and scientific approach, including involving ethics to monitor compliance with the rights and safety of study participants and their medical data.
 The Ethics Committee is an independent body that monitors compliance with the rights and requirements of legislation and conducts ethical and scientific examination of research documentation. Ethical issues when planning any research involving a person or his/her data should be discussed and considered in detail. The ethics committees should be contacted not only at the stage of approving research materials, but also when planning the design and developing research documentation and materials for patients, as well as regularly at all stages of the study.

Nowadays, medical devices rely on software whether completely such as mobile medical applications or as embedded software into medical chips such as tele surgery systems. Medical device software usually developed by using traditional development methods such as V-model and Waterfall model as these methods are straightforward and has the ability to comply with regulatory requirements such as documentation that ensures traceability. However, these methods could take a long time, could be costly, and these are inappropriate in case of requirements changing. In contrast, agile processes have several benefits such as producing a product of a high-quality with low cost and in short period with the capability to embrace change during development. Therefore, companies that develop medical device software can benefit from adopting agile practices. While the adoption rate of agile practices in software development in different industries is increasing, healthcare industries still have a low rate of agile adoption. This due to the gaps between agile practices and the stringent requirements of healthcare regulations such as documentation, traceability, and formality. The main question of this research is how capable are Agile processes can be in dealing with MDR requirements? This paper will investigate the capability of agile processes to support European Medical Device Regulation (MDR) requirements by extracting the MDR requirements that are related to software development life cycle. Then investigating the robustness of agile processes, to support MDR regulations. These objectives will be conducting by comparing and analysing the most popular agile processes (XP, Scrum, and FDD) to identify the gaps between MDR requirements and agile processes. The analysis revealed that XP is inappropriate for MDR requirements since it lacks the fixed up-front planning and also have insufficient documentations for treatability, Scrum has a model status report can be used for traceability but also it has insufficient documentation for MDR, and FDD is the closest agile practices to satisfy MDR requirements because it has a develop overall model phase which can be considered as semi-fixed up-front planning as well as has more documentations than the XP for traceability purposes such as UML modelling.

Resource Depletion Risk for Medical Equipment: Embracing the Circular Economy.

Software is now a crucial component of every product as technology continues to develop all elements of health care. It is widely integrated into digital platforms for both medical and non-medical uses. One of three forms of software connected to medical devices is software that, on its own, qualifies as a medical device. This article intends to provide an analysis and summary of recent research in the field of medical device development methodology, explore these investigations’ phases, and assess the risk and legal implications. The literature search was carried out to find peer-reviewed articles on content released between 2010 and 2021 in Scopus, Web of Science, and Science Direct. based on criteria for inclusion and exclusion. Given the distinctive characteristics of software as a medical device (SaMD) that go beyond those of conventional medical hardware or devices, regulators across the globe started to realize the need to consent to a framework and set of guiding principles for the industry. This will allow all stakeholders, including regulated entities, to advance safe innovation and safeguard patient safety. From the time a product is first conceptualized until it is launched onto the market, the development of software as a medical device is incredibly complicated and greatly relies on the use of good manufacturing practices. The key issues that must be addressed in the future are the transparency of regulatory processes throughout the globe.

The China State Council released the new generation artificial intelligence (AI) development plan, outlining China's ambitious aspiration to assume global leadership in AI by the year 2030. This initiative underscores the extensive applicability of AI across diverse domains, including manufacturing, law, and medicine. With China establishing itself as a major producer and consumer of medical devices, there has been a notable increase in software registrations. This study aims to study the proliferation of health care-related software development within China. This work presents an overview of the Chinese regulatory framework for medical device software. The analysis covers both software as a medical device and software in a medical device. A comparative approach is employed to examine the regulations governing medical devices with AI and machine learning in China, the United States, and Europe. The study highlights the significant proliferation of health care-related software development within China, which has led to an increased demand for comprehensive regulatory guidance, particularly for international manufacturers. The comparative analysis reveals distinct regulatory frameworks and requirements across the three regions. This paper provides a useful outline of the current state of regulations for medical software in China and identifies the regulatory challenges posed by the rapid advancements in AI and machine learning technologies. Understanding these challenges is crucial for international manufacturers and stakeholders aiming to navigate the complex regulatory landscape.

Traceability of requirements through the software development lifecycle (including supporting processes such as risk management and change management) is a difficult and expensive task. The implementation of effective traceability allows organizations to leverage its many advantages, such as impact analysis, product verification and validation, and facilitation of code maintenance. Traceability is conducive to producing quality software.Within the medical device domain, as in other safety critical domains, software must provide reliability, safety and security because failure to do so can lead to injury or death. However, despite its criticality most software systems don’t employ explicit traceability between artefacts. Numerous barriers hamper the effective implementation of traceability such as cost, complexity of relationship between artefacts, calculating a return on investment, different stakeholder viewpoints, lack of awareness of traceability and a lack of guidance as to how to implement traceability.To assist medical device organisations in addressing the lack of guidance on how to implement effective traceability, this paper aims to present the development of a traceability process assessment model and how traceability process assessment and maintenance could be fully automated using the Open Services for Lifecycle Collaboration (OSLC) initiative. The process assessment model will allow organisations to identify strengths and weaknesses in their existing traceability process and pinpoint areas for improvement.