Software in Medical Devices, by MD101 Consulting

IEC 82304-1 in software development cycle

The most simple presentation of the position of IEC 82304-1 in the software development lifecycle is to use the traditional waterfall process: But it is also applicable with agile methods, like suggested in the following graph: In the example, we still have a separation between the system level, where use requirements and system requirements don't change when a version is being developed, and the software level, where agile cycles (sprints or something else) are performed.

Continuous user input

But we can go further in the representation, by considering that user feedback (the input at the top-left corner of the previous graph), continuously changes. In this case, use requirements and system requirements are treated at sprint level. But not all sprints will contain new and/or modified use requirements and/or system requirements. And a validated version won't be released at the end of each sprint. The minor difference on the graphic compared to the previous one: continuous user input, makes a major difference for the agile development process. Thus the user input is not frozen at system level and evolves continuously.
Practically speaking, the system level requirements are not given in a document, like a statement of work. They are continuously given by the users, when they are provided with demo or stable releases, and are added to the backlog.

Agile at system and software level

It's difficult for a medical device manufacturer to be agile both at system and software level. Having user requirements changing continuously can be troublesome.
Usually, user feedback doesn't change the intended use of health software. But sometimes end-users have tons of ideas... especially when they are doctors! Being fully agile means that it could be possible that the device description or even the intended use could change! This is a situation that manufacturers don't want to encounter.
That's why agile methods assign the role of product owner to someone, who acts as a filter between users' vows and what goes into the backlog.

Static immutable requirements

Coming back to IEC 82304-1, it means that some of the user and system requirements won't change, that they set the basis of the software development project. These user and system requirements are a subset of what is found in sections 4.2 and 4.5 of IEC 82304-1. We can quote some of these types of requirements, for which we are 99% sure they won't change during the project:

• Intended use,
• Addressed users or patients,
• Main use case,
• General system security,
• Regulatory requirements (hum, not so sure :-).

Using software development vocabulary, we can speak of static immutable requirements. All other requirements are dynamic and mutable.
They can be added, deleted and changed from one sprint to another. They can be at system level i.e. other requirements found in IEC 82304-1 or at software level i.e. requirements found in section 5.2 of IEC 62304.

Releasing health software

Since many things can change from one sprint to another, it's not possible to have a stable release after each sprint. You won't put software in the hands of anyone after each sprint. Depending on its status you can determine to whom it will be released:

• Is it demo-able?
  • No (pliz, agile aficionados, don't frown, c'est la vie!), next sprint,
  • Yes, do a demo to the product owner,
• Is it stable?
  • No, next sprint,
  • Yes, consider putting it in the hands of experienced users,
• Is it ready for validation?
  • No, next sprint,
  • Yes, do a validation.

Ready for validation means that its functional scope probably matches the intended use.

Validating health software

Probably matches the intended use is not allowed for software on the market. A validation step is required to ensure that software does match the intended use.
A formal step of validation remains mandatory for software qualified as medical device. IEC 82304-1 helps manufacturers define what should be validated in section 6 of the standard. As already mentioned, this is a major breakthrough of this standard.
In the context of agile methods, the standard leaves the validation method to the choice of the manufacturer. IEC 82304-1 requires at section 6.2 to write a validation plan, which contains the validation methods. Hopefully, it doesn't impose a methods. Thus, the validation method can be:

• Either a formal step of validation, performed after a release candidate is delivered by the software team,
• Or a continuous validation included in the sprints.

A quick search in the scientific literature about software development, or in developers forums, shows that nobody performs a continuous validation of medical device software. It is possible, but it hasn't been implemented (or disclosed) yet.

Conclusion

To conclude this series of articles about IEC 82304-1, the key points are:

• Its scope is standalone health software,
• It calls IEC 62304 for software development, and thus requires ISO 14971,
• It defines types of requirements to document at user and system level,
• It defines requirements on health software validation,
• It will be probably recognized by the FDA and harmonized by the EU when it is published,
• It is portable to the framework of agile methods.