In today’s interconnected world, medical devices are called on to include more innovative features that offer intelligent functions. These new capabilities are typically designed using software; as a result, the software used to create these new features has become increasingly complex. Concurrently, FDA and other regulatory agencies are stepping up pressure on medical device manufacturers to ensure product safety and accuracy in reporting information about their medical devices.

In a marketplace facing increased product complexity, time-to-market pressure, and product safety and regulatory scrutiny, it is good business sense for medical device companies to address these challenges. This article explores a model-driven approach for developing medical device software.

Device manufacturers are at a software development turning point, and several tools may be able to help them improve productivity and quality. A model-driven development process integrates the various phases of product development, from requirements analysis to system design, implementation, documentation, and testing. This work flow helps to enable complex requirements and architecture to be represented graphically in diagrams, thereby reducing complexity while also assisting communication about requirements and the design among stakeholders. The diagrams have semantic meaning and are interconnected, helping enable traceability directly from requirements to design. Furthermore, the software implementation can be directly generated from the model, providing an audit trail from requirements to design to implementation.

Delivering Device Software

In the medical device marketplace, the drive to deliver innovative technology is very real and smart devices are everywhere. In this space, it is the software that delivers the functionality that enables a high-tech world. Software is used to perform functions in medical devices that may have previously been done in hardware: for example, physical knobs and buttons on diagnostic equipment are often replaced by touch screen dsiplays, or medical images such as x-rays and MRIs are increasingly delivered in a digital format instead of a physical one.

Competition in the medical market is fierce, and it is paramount that products go to market before the competition can get there. Getting through premarket activities (such as the 510(k) process) and following good manufacturing practices (GMP) are essential to bringing a device to market and to capturing a strong market share. But a balance between speed and patient safety must be made to avoid costly product recalls. One strategy is to reuse existing and largely equivalent programming code for premarket efforts, particularly when working with software for life-critical operations. The critical path to successful software reuse is through understanding; in some cases, software could be years old and engineered by personnel no longer with the company, which is why effective reuse hinges on understandable documentation.

 

Document, Document, Document

Organizations that can leverage their intellectual property (IP)—and reuse it—have a leg up when they engineer new medical device software. For reuse, nothing is more critical than good documentation, which has other benefits as well. For maintaining project information, a design history file (DHF) is used to store project artifacts. FDA regulates products developed for the U.S. marketplace via the quality system regulation (QSR), 21 Code of Federal Regulations (CFR) Part 820.30, which requires a DHF. The DHF contains information regarding the project from a variety of sources, including items such as requirements, system specifications, risk analysis, and other formal documents. Notes, sketches, or other pieces of information may also be included. The rationale behind having a DHF is to provide traceability and documentation that shows that the device is being used for its intended purpose, with all the requirements implemented in its design. However, how this is achieved is somewhat haphazard: some companies use source code printouts as evidence to show that the requirement has been implemented. Of course, using source code as the method of communication is only effective if the reader is able to understand code. Nontechnical stakeholders may lack the skills needed to understand source code, creating a potentially dangerous communications vacuum.

 

Visual Software Development

Model-driven development (MDD) creates a visual development environment for software delivery. MDD’s foundation is the unified modeling language (UML) from the Object Management Group. The MDD environment visualizes complex design input to promote communication among various stakeholders. Development teams can represent requirements, architecture, structure, design, and behavior in a format that is easier for stakeholders to understand than source code. UML defines several different diagrams to capture the structure, architecture, and behavior of systems or applications. Similar to UML, the systems modeling language (SysML) is based on UML, but it is tailored for systems engineering needs.

The information on the UML diagrams is stored in a model repository, which greatly expands the role of the diagrams beyond that of mere illustrations (see Figure 1). A change in information on one diagram is reflected in the model repository and propagated to other diagrams to reflect the same information. For example, assume there is a class named “Pump” in the design and that same class appears on two different diagrams. Changing the name of “Pump” to “InfusionPump” on one diagram will automatically be reflected in the other diagram.

 

Tracing Requirements to Model Elements

Requirements for a medical device are typically defined by textual documents or in a requirements management tool that is used for design input. Although text can communicate a great amount of detail about what needs to be done, it is also subject to misinterpretation. More importantly, there is no filter or process to prevent conflicting requirements to be written in the first place. Performing requirements analysis can help resolve conflicts by breaking down the requirements into further details for each of the components within the product. Modeling assists this process by visualizing the textual requirements with diagrams and providing traceability to design and implementation.

The first step in tracing requirements to model elements is to associate the textual requirements with the modeling environment. A requirement element within the model stores the requirement and holds the text describing the requirement in addition to other pertinent information such as requirement ID, priority, safety integrity level, and risk. There is no limit to the type of data that can be stored. Synchronization is maintained between the requirements and the model so that changes in either are reflected in the other. Traceability from the requirements to model elements satisfying those requirements can be represented in the model. With this information, requirement coverage reports can be generated or an impact analysis of a design change can be performed. For example, a UML profile can be created that defines a fault-tree-analysis diagram. Safety and risk analysis can be performed in the model. Figure 2 shows how faults can be traced to the requirements concerned with the fault. Further analysis of the model information can be performed to show gaps in coverage.

 

Working with Code and Models

Medical device manufacturers already have validated and verified software in use in existing devices that can be used in future devices. This software can be imported into the modeling environment. UML diagrams for the code can automatically be created to visualize the existing structure, architecture, and behavior of that code. The result is better documentation for the existing code, which helps new developers or other stakeholders obtain a better understanding of the intended purpose of the code.

Once represented in the model, traceability to requirements can be added to the existing code, which can then be used to help create new features being developed in the model. For example, a new user interface may be created for an infusion pump but the existing code to deliver medication to the patient should be reused. The user interface code simply calls the existing code and a relation in the model is created between the two.

As design progresses, more details and behavior are added to the model. The UML provides facilities to specify the entire application in the model, and the detailed target-level code can be included in the model. Code for the device can be generated directly from the model. This helps create traceability from the code to the design in the model. The requirements are also included in the model, so traceability is achieved from requirements to the implementation code (see Figure 3). It is possible to include the requirements information directly in the code as a comment for further traceability between requirements, design, and implementation.

Software developers do not need to abandon their current development environment to use a model-driven approach. The code generated from the model can be edited in their code editor of choice, with the changes automatically updated in the model (see Figure 4). This keeps the implementation in sync with the design.

 

Validation and Verification

FDA guidance recommends starting validation early with the initial design input and continuing validation iteratively throughout the development process. Most defects enter the system during the initial analysis phases of development but typically are not found until late in the integration phase. The model-driven approach uses model execution and consistency checks to identify problems early in the design of the product when they are the easiest to address. Using the model, it is possible to generate production-quality code, including C code.

For medical device software engineers, model execution performed on the host platform validates design behavior well before hardware may be ready for software testing. When hardware becomes available, engineers can then focus on target-specific issues such as timing.

 

Documentation

With a model-driven approach, as software developers create the model, they also provide the documentation for their designs. The diagrams in the model visualize the design and can be used for communication with project stakeholders or regulatory agencies. Because the implementation code is also generated from the model, both the implementation and the documentation remain synchronized to help ensure that the documentation accurately represents the implementation. Documentation from the model can be generated in a variety of formats and tailored to each company’s needs. Diagrams, tables, matrices, and textual information can each be included in the documentation for the entire device.

 

Conclusion

The complexity of medical device software is increasing, and agency scrutiny is a fact of life. An MDD environment based on UML helps enable visualization of textual requirements and strengthens the design process. It empowers teams to break down complex requirements and communicate more effectively with the project team and government agencies. The semantics of the model help to manage change by maintaining consistent information in multiple views.

Quality and safety goals can be met using validation, performed early in the design cycle to identify errors when they are the least costly to address. For medical device developers, a model-driven approach integrates the different phases of the product life cycle—helping improve a company’s ability to deliver innovative medical device software while gaining a competitive edge.

 

Paul Urban is Rational Rhapsody and medical device industry marketing manager for IBM Corp. (Westford, MA). He can be reached at purban@us.ibm.com.