The Medical Device Product Development Process: Technology to Manage Complexities
Technology advancements in medical devices offer the prospect of conversion of clinical research into practical treatments that can be replicated and delivered in hospitals, at medical centers and in home. But the potentially catastrophic results of any device failure demands design, development, manufacturing, service and operational procedures of the highest standards. This article looks at two technologies and engineering methods developed without any specific focus on medical devices, specifically, systems engineering (SE), and application lifecycle management (ALM), and discusses the way they address the needs of medical device development teams.
Complexity with Regulatory and Product Alterations
A medical device research study Cambashi performed reported a number of business characteristics that are familiar in other market segments. For example, the top three areas reported by respondents as the largest opportunities to improve in the next three years were:
- Product development efficiency
- New products and new product lines
- Faster new product introduction
Having these as the top three would not be surprising in many high-tech sectors including consumer electronics. But perhaps some of the unique issues for medical device businesses show up in the same study’s findings related to quality. The top two challenges to maintaining quality were reported as:
- Regulatory changes
- Product changes
So product change appears on both sides of the equation – a source of improvement and opportunity, and, at the same time, a source of quality problems. This puts product change on the agenda for both engineers and business leaders, who together must find the right risk/reward balance. Of course, regulations exist to ensure that the risk mentioned here does not include risk to patients! The scope and rigor of medical device regulations differentiate this sector, and make the risk of incurring excessive costs to achieve appropriate approval and certification very real.
Medical device product change is driven by a number of factors. For example, there are continual advances in medical research and therapeutic practice. These combine with growing demand for healthcare. The result is new opportunities. New devices, integrating new materials and production methods, and offering new ways to address medical conditions, represent business-as-usual for inventive design engineers.
But this is only the beginning. In the medical electronic device part of this market, the current environment also includes significant technology changes that feed straight through to decisions about product architecture. Examples include low power, high performance microprocessors; software; network connectivity; and touch screen interfaces as well as continuing advances in sensors and actuators. All of these extend the envelope of conceivable devices, and act as an additional multiplier on the number of design choices. Some of these choices make big differences to the size, cost and performance of devices. For example, it is easy to imagine a new design study being triggered by a remark such as “If network availability and bandwidth is sufficient, maybe we should make the device smaller by moving more image storage and analysis to a connected server.”
The result is growing complexity. This complexity exists in products driven by demand for innovative capability. New complexity also exists in business processes, which have had to adapt to more complex supply, distribution and service networks. Engineering teams also handle other sources of growing complexity, for example complexity driven by greater globalization of markets, suppliers, and customers. This means more regulations to handle, and stronger requirements for intellectual property protection.
Every medical device engineering team in the industry wants to use the right tools. But which tools are the right tools? In this article, I have picked two categories of tool that I believe take center stage for medical electronic device developers facing growing complexity. The first is an engineering approach applicable to a wide range of projects. The second is a category that addresses one of the specific sources of complexity. So, with apologies to the providers and evangelists for the many other tool types needed, here is a short discussion of systems engineering (SE) and application lifecycle management (ALM).
Systems Engineering is widely used in the aerospace and automotive sectors in the battle to manage complexity. One of the many values of the SE approach is the way in which practitioners are encouraged to think through a suitable scope for the problem or requirement they are working on. The product domain is a legitimate scope. So is the production domain. So are the operational and service domains. So is the development process domain. Thus, for example, ‘design-for-manufacture’ combines the product and production domains, and sets the designer the goal of finding optimum solutions taking into account both product requirements and manufacturing processes. Used wisely, SE thinking helps set an ‘appropriate’ scope for every development activity.
An introduction to SE provided online by Portland State University includes presentation of the “FRAT” model (Function, Requirement, Answer, Test), and is an antidote to the old reputation of SE as a documentation-centric discipline of value mainly in military projects. The FRAT model complements the V-model (Figure 1) – often seen as a ‘signature’ diagram of systems engineering.
It is rarely helpful to interpret the V model as a time sequence from customer needs to release. It is more useful as a map of the artifacts that will be created and used during a development project. Thus, for example, in some environments, a good starting point for a development project could be the point shown as ‘Verify products, services and processes.’ This needs a statement – perhaps in the form of a test specification - to define how the project will know that it has achieved the appropriate product, production, delivery and service capability. Once you are comfortable with using the V-model as a map, not a process flow, then you can use it to help plan suitable traceability connections between development artifacts. A related contribution of the FRAT model is the distinction it makes between functions (which are unquantified), and requirements (which are quantified). A fully defined requirement enables creation of a matching test specification. These links between requirements and tests can be represented as horizontal lines between the two arms of the V-model, and they can be at any level of detail, from requirements and tests for the whole product and service offer (at the top of the diagram), to requirements and tests for individual elements of the product and production process (near the bottom).
As well as mapping this relationship, the V-model causes you to think if horizontal links are appropriate for artifacts in addition to requirements and tests. Perhaps the project has defined a manufacturing process re-use initiative. If so, then you may be able to use the V to see which artifacts will be required for suitable audits of components and processes.
Of course, in regulated environments, the regulations must be handled alongside the customer need. When regulations and guidance focus mainly on the development process, then an SE practitioner might use the V-model to trace out the sequence of steps to clarify which artifacts are relevant to which step of the regulated process.
The V-model is just one of many SE tools. The SE approach requires meticulous analysis and development of requirements. The area of requirement engineering is substantial. A starting point for the availability and scope of requirements-focused tools can be viewed here.
As well as requirements development, SE establishes creation of high-level design and architecture to provide the framework that ensures multiple subsystems and technologies work together. In this context, the software-focused Universal Modeling Language (UML) provided the foundation for SysML. SysML is a combined extension and simplification of UML to create a well-defined and complete specification of diagrams that represent system models. The SysML specification has allowed creation of a range of tools.
One of the interesting aspects of the use of models in systems engineering is the way this begins to build a bridge to simulation. Of course, SysML (and other) forms of model have value as documentation alone – they allow accurate consideration and communication of ideas using a standard set of diagrams. But why stop at documentation? Behind the diagrams is a data structure containing a well-defined model of the structure and semantics of the proposed system. In principle, and to a certain extent in practice, this data structure can provide the framework for simulation of the proposed system. Commercial products offer some capability to ‘execute’ or ‘solve’ SysML models.
The open definition of SysML provides a degree of flexibility and alternatives when it comes to tool choice. Thus, for example, given the growth of software as a component of medical devices, then it may be relevant that some SysML tools can be used to generate code automatically - even though in most medical device development environments, this is seen as something for the future, not today’s requirement.
Proprietary solutions are also competitive in this model/simulate area. For example, NI’s Labview, which has its origins in the area of test equipment development, offers a capability to use component and system diagrams to configure and control operational equipment. Now, it has grown its market footprint to include medical device prototyping and development. And tools relevant to a wide range of modeling and control system development can also contribute to development of medical devices (e.g., Mathworks’ Matlab/Simulink, and Imagine.Lab from LMS – a Siemens business.
Application Lifecycle Management
At one level, software is ‘just another technology’ – albeit one that is handling a growing proportion of functions of medical devices. Medical device development teams have experience of multiple technologies from actuators and sensors to pneumatic, hydraulic, electrical and electronic. But practitioners report that “software is different”, both in the culture of developers, and the actual state-of-the-art of predictable development times, techniques for achieving reliability, approaches to re-usability of software and more.
There are also healthcare trends that are making software ever more central and significant to the functions of medical devices. Connection of devices to hospital networks depends on software. Enabling remote physicians to access and act on data collected by devices depends on software. So the stage is set for tools for software engineers that will help guide and enforce compliance with approved development processes, and software development tools from providers such as IBM and Polarion recognize this need.
Of course it is possible to use general purpose product lifecycle management (PLM) systems to manage change control, workflow, status, communication, access and so on for any type of development artifact. When applied to software, established PLM solutions have the advantage of covering the whole lifecycle, and, in principle, managing software using the same framework as the rest of the project.
But remember ‘software is different.’ For example, software development operates with an intrinsically higher rate of change than other disciplines. On anecdotal evidence, this author would suggest the difference is 10x or even 100x. This difference can affect the practicality of schemes that work well for the slower rates of change of hardware. A current hot topic for project managers is how to handle iterative/agile methods that use prototypes to provide feedback and adjust requirements. This approach is well established in software, but is often not feasible for hardware.
Another challenge is fitting software into the bill-of-materials (BOM) structure for a product. This is easy for final binary files, but complex and sometimes impossible for source code, because different build options and header files may create completely different executables. Add source code configuration options, which can structure code into multiple connected source trees with independent change histories, and the value of specific support for software – namely, application lifecycle management (ALM) - becomes apparent.
Leading PLM providers recognize this. By acquiring MKS, and integrating MKS Integrity ALM technology with its existing Windchill PLM capability, PTC highlighted the importance of specific capability for software. Siemens PLM supplements its Teamcenter technology with ‘Ready for Rational’ certified integration with IBM’s Rational source code management. Dassault Systèmes acquired software specialist Geensoft some years ago, including some automotive-specific tools, but have developed capability for other application areas with separate modules for requirements traceability (‘Reqtify’), and control applications (‘ControlBuild’).
For medical electronic device development teams, the most important conclusion is to have a strategy to manage complexity. This may involve systems engineering, it almost certainly will involve integration of PLM and ALM tools for development process management.
I will leave the last word to a person with the job title ‘head of embedded systems’ who had just completed development of a software-heavy medical device project at the time of our interview. On the broad subject of the value of tools, the response was:
“In my opinion it is the human engineer in the loop that counts. The value of tools is to split things up into units that are humanly digestible, tractable problems” – Source: Cambashi research interview