RegOps – agile development of medical software

The development of a medical device or software is regulated in Europe by the Medical Device Regulation (EU 2017/745). Then again, MDR does not really involve much extra work to software development – compared to what it should be anyway. So how can you make the most of the regulation without it becoming a burden?

The easies way to medical device software to comply with the MDR requirements is to apply the ISO 13485, IEC 62304, ISO 14971 and IEC 62366-1 standards, in addition to which, depending on the product and its purpose, some other standards may also be required.

Traditional waterfall model

When standards are applied into operating models, the process may easily look like the traditional waterfall model. The waterfall model first defines the intended use and requirements of the medical device. This is followed by design and documentation of the software architecture and interfaces. Once all the plans have been completed and reviewed, the software enters the implementation stage. This is the stage in which the actual code will be written.

Once the software has been implemented, automated tests for verification will also be written. Subsequently, a clean test report and software enters the validation stage by the clinicians. Usability tests complying with the IEC 62366-1 standard must be conducted, including risks to patient safety according to the ISO 14971 standard.

Waterfall or SCRUM?

When the traditional waterfall model is applied, design, review, implementation, verification and validation stages are performed on the entire software in large steps. In the extreme case, software documentation is written only afterwards in order to comply with the regulations. In addition to this, members of the medical software team work at different times or are compelled to work for long periods outside their own areas of competence. This makes the team less efficient and at worst causes frustration among the staff – at least from the viewpoint of software designers who would like to write code.

Agile development solves problems in the waterfall model and speeds up the turnaround time of individual changes in particular. One of the commonly used agile development frames of reference is SCRUM, in which development proceeds in sprint cycles. One sprint takes a few weeks and for the duration of the sprint, the team selects the tasks and objectives from the list of jobs.

At the end of the sprint, a new software iteration is created, effectively a new version ready for production. From the viewpoint of the system developer, a sprint allows them to focus on development – although a project-specific process obviously requires that planning, documentation and testing must be carried out. Implementation presented in the sprint demo should deliver towards the goals, which gives a good rhythm to the software developer’s work.

RegOps

When traditional software development consists of not only software development and testing but also production maintenance, we talk about DevOps (a blend of development and operations). In practice this means that the development team is also tasked with system maintenance. DevOps can be managed in the SCRUM framework, as long as a reservation is made for any unexpected maintenance alongside the development work.

In the case of medical software, when compliance with the regulations is added, we arrive at the definition of RegOps. RegOps calls for requirement specification, plans, assessment of risks to patient safety, and a review of all of these. And the software must also be coded, tested and reviewed. Could all of this be done agilely in the SCRUM framework?

Reaching the goal through scrums

Agile development of medical software can be built in the SCRUM reference around reviews (see Figure 1).

Starting a sprint

A sprint is started by selecting a suitable number of tasks from the list and by refining them. In Atostek projects, the tasks on the list are generally software development tasks in compliance with the customer’s requirements, raised into the sprint together with the customer’s product owner. The tasks are new features or changes to existing ones and they may also involve clearing up bug reports and thereby contributing to code corrections.

In certain cases, we complete high-level tasks at Atostek, broken down into smaller sprint tasks to enable completion in a sprint. Tasks in a sprint are specified accurately enough to ensure that the description clearly indicates the definition of done.

From review to implementation

During a sprint, the entire team reviews and approves the medical software’s updated requirements, architectural designs, unit design, interface descriptions, risk tables and any other necessary plans. In this design review, each team member will present their own plans and with official review minutes this complies to a design review as ISO 13485 specifies.

After this, the features that have been designed are implemented, tested and published internally. The sprint demo acts as an implementation review.

Depending on the changes made during the sprint, and particularly on any related risks, the software must still be validated and potentially subjected for approval by the notified body before being released to production. In case of minor changes, a notification is generally sufficient for the notified body. After this the new version can be transferred through validation review to production.

What if things don’t go swimmingly?

Sometimes things do not go according to plan. Some item on the task list may turn out to require more work than originally thought. Or maybe a team member gets a cold, and everything isn’t ready by halfway through the sprint for the design review. Some plans cannot therefore be reviewed, and you cannot proceed to the implementation stage with them.

If the team runs out of tasks for implementation and other tasks, new features can be picked into the sprint from the list in order to balance things. It is always also possible to have another design review during the same sprint if the original set of features are critical to the sprint’s goal.

Multi-skilled team or a range of work duties?

But how can you get the most out of regulation? The RegOps method broadens the job description of software designers, and a single feature can be given to a single employee to complete from start to finish. Based on the desired feature, this person will update the requirement specification, architectural design, interfaces and any necessary unit design, and present the feature in the risk management meeting and design reviews.

Any potential patient safety issues regarding the new feature will be discussed by the entire team. The project manager and/or quality manager will obviously support the work if necessary. Once the plans have been approved, the matter becomes clear and the implementation is straightforward.

The software designer can start writing the automated tests and utilize them already during development, which brings out the greatest benefit of the tests. Suddenly regulation is no longer a burden but the tasks are similar to what you were used to as a computer science student. And what’s best – each sprint allows you to design, code and maintain the production system. For many employees at Atostek, that’s the greatest part of their work!

When software designers take part in the requirement specification, planning, testing and reviewing as part of the agile process, they not only fulfil the requirements of the medical software but also make full use of their university education. High-quality work gives a good feeling to everyone!

---