top of page

In-house development of medical software

European Union (EU) regulations:

 

Specific requirements of MDR17

​

Clause 4 of the regulations states that “devices that are manufactured and used within health institutions shall be considered as having been put into service ... [but] .. with the exception of the relevant general safety and performance requirements set out in Annex I, the requirements of this Regulation shall not apply to devices manufactured and used only within health institutions established in the Union, provided that all the conditions set out in Article 5.5 are met. A discussion of each of the conditions has recently been published [ref, see page 24], so will not be repeated here. The UK's MHRA is referring to a combination of Annex 1 requirements and Article 5.5. conditions as the "Health Institution Exemption" (HIE), but this is slightly misleading as the hospital department actively involved in medical software development is only really exempt from the formal CE marking process. Also, the circumstances in which a department may transfer its software to another legal entity is currently being debated. On the face of it, such transfer is not allowed under condition 5.5.a, but the MHRA's original (2019) draft HIE guidelines suggested otherwise. 

​

Latest IPEM guidance on in-house development on medical devices (including software) can be found here.

 

What should you be doing now?

​

  1. Review the requirements of the new regulations and decide (as a department) whether you wish to continue to develop medical  software.

  2. If you don't have a departmental software development policy, write one.

  3. Get the support of senior hospital management. Make sure that the hospital assumes vicarious liability in the event of any legal action being taken in relation to your software development activity. Get this in writing from the Chief Exec or his/her nominee.

  4. Decide whether the developed software will be for internal (within the Trust) use only, or whether you intend to make it available to other health institutions. 

  5. List the additional resources that you are going to need to continue this work into the MDR17 era. Write a business case if additional funding is required.

  6. Update all your technical procedures in relation to software development. That will take a while!

  7. Make sure that you follow guidance set by your professional body and the national Competent Authority (the MHRA in the UK).

  8. Think about joining or establishing a local network of like-minded departments. Learn from each other and don't re-invent the wheel.

​

For help with MDR17 implementation, see Publications, References and Current Projects pages. The latter has details of a comprehensive new book on regulatory compliance requirements for medical device software.

​

​

To be added in due course:

 

*  A template for a departmental software development policy (this is included in the above book)

*  Use of standards and certification

*  Competency assessment

*  Does the use of open source software make life any easier?

​

United States regulations

​

*  Status of in-house software developers (details in the above book)

*  Requirements under federal law

*  FDA guidelines and current practice

​

​

If you would like something addressed/clarified that may not be covered above, please email me via the Contact page.

​

​

 

​

​

​

​

 

This page last updated: 01 April 2024

​

​

 

 

​

​

©2018 by The software medical device. Proudly created with Wix.com

bottom of page