Software in Medical Devices, by MD101 Consulting

The purpose of this guidance is to mitigate any risk related to the failure or misuse of Electronic Data Interfaces (EDI) in an interoperable medical device. To do so, the guidance gives recommendations on artifacts to include in the software development process, and recommendations on how to document these artifacts in premarket submissions.

Content of the guidance

This guidance recommends, for each interface, to:

• Define the purpose of the interface,
• Define the anticipated users,
• Verify and Validate the interface,
• Include information in labeling about interoperability.

Link with IEC 82304-1

There is an big overlap between the artifacts found in this guidance and the artifacts found in IEC 82304-1 standard. This is probably not a coincidence.
IEC 82304-1 requires to:

• Define the purpose of health software,
• Define use requirements of health software,
• Mitigate risks related to health software,
• Validate the health software,
• Identify and create accompanying documents of health software.

Link with IEC 62304

Likewise, there is an overlap with the artifacts of IEC 62304, at a lower level of details:

• Specify and design the interface,
• Mitigate risks related to medical device software,
• Verify the interface.

Link with ISO 14971

The guidance recommends to consider new possible hazardous situations, that could arise form the use (or the presence, even if it isn't used) of electronic data interfaces. This guidance echoes here the two guidances about cybersecurity in medical devices (see here and here), with risks dealing with safety.
Surprisingly, ISO 14971 is only quoted in a footnote, and IEC/TR 80001-1 series is not quoted either. Perhaps FDA doesn't want to impose a risk management standard in a guidance. Or this is still a draft guidance, and the final version will contain a list of standards in the bibliography section.

How to apply it

Just add the relevant artifacts in your existing software documentation:

• Purpose and anticipated users should be found in a high-level document, for example device description,
• They should be refined in software requirement specifications, and their design documented in architectural and detailed design documents,
• Verification and validation of interfaces should be found in verification and validation plans, tests descriptions and reports.

For risk management, just consider the new hazardous situations pointed out by the FDA. A section about interoperability in the risk management plan and in the risk assessment report could be a effective means of documenting risk assessment of interfaces.

Conclusion

This guidance is not a revolution. It is in the stream of evolutions of expectations of regulatory authorities about medical device software. Fortunately, it doesn't put much pressure on manufacturers (unlike cybersecurity guidances). It can be applied by adding relevant artifacts to the existing software development and maintenance processes.