I am a long-time software professional who first started working with security in 2014 and then with medical software in 2015. I was working at Nokia at the time, and we were – of course – using agile methodologies. It was nothing fancy at the beginning, just your garden variety Scrum(my) processes, but when we started defining our software development processes for medical software development we tried at the same time to elevate our development process to the DevOps model and to include the regulatory requirements of medical device development – meaning ISO 14971 (Risk Management) and IEC 62304 (Software Life Cycle Processes). We weren’t too worried about ISO 13485 (Quality Management Systems) since the EU Medical Device Directive does not require a quality management system for Class I devices, which was our target at the time. We were working on a remote patient monitoring system that used mobile phones, and such systems are not even considered to be medical devices unless you do something a little more fancy, e.g. something that counts as a decision support system. My main responsibility was security architecture and medical device risk management, but I found the software development process aspect interesting as well, and worked with the team leads on JIRA workflows and the like.
It was an interesting journey. I will not claim that we reached some kind of panacea for combining agile software development with strict regulatory compliance requirements, but we developed our processes through several iterations and learned quite a bit. In the meantime I was also immersed in the requirements of complying with both US and EU health and privacy regulation – HIPAA, GDPR, and local Finnish medical record regulations. Unfortunately, right at the time when we had completed our work and were ready to release, Nokia abandoned its health ambitions, and work on the remote patient monitoring system ceased. Many of the people involved wanted to continue with healthcare though, me included. Our Director of Business Development, Head of Engineering, and Cloud Software Lead / Product Owner founded a start-up company to continue the commercialization of the software we had been developing (this kind of spin-off happens more often than you might think, other Nokia spin-offs include Sports Tracker, Quuppa, PulseOn and Cumulocity). Our system architect started a consulting business. Many others found new jobs in the healthcare sector. I moved on to Elisa, a Finnish teleoperator which also operates a remote patient monitoring service. With the impending new EU Medical Device Regulation, that service will require medical device certification, including the establishment of a certified quality management system, and defining the required procedures is my current job. I also manage the security requirements. My current role is thus perhaps best described as “security and compliance”.
This gives me the opportunity to apply the learnings from my Nokia career to develop medical device software development processes that are agile-friendly while still supporting the plethora of regulations and standards that we have to comply with:
- EU Medical Device Regulation
- ISO 13485 (Quality Management Systems)
- ISO 14971 (Risk Management)
- IEC 62304 (Software Life Cycle Processes)
- IEC 82304 (Health Software)
- IEC 62366 (Usability Engineering)
- GDPR (EU general privacy regulation)
- Perhaps HIPAA (US health-specific privacy regulation) later
- National medical record regulations related to countries where the system is to be sold
- For example, a typical requirement (that is not already included in GDPR requirements) is to maintain a complete version history for health data, so that if changes are made, you can see who made them and when
The purpose of this blog is to document that journey and to gather feedback from other medical software professionals. The topics may vary; I would expect to cover at least medical device regulation, software development processes, and privacy and security aspects. The viewpoint in my writing will be somewhat like in a startup – operating with limited resources in an organization where most developers are new to medical device regulation.
This blog is also to some degree an extension of my LinkedIn presence. LinkedIn does not provide the ability to create your own blog (although you can publish articles in your feed), so I created a separate WordPress site. However, I want to keep the interaction on LinkedIn and make it as easy as possible for everyone. So I will share all articles on my LinkedIn feed, and you can comment on the articles there. I will add a link to the share at the bottom of each article. No need for logins on this site. Be sure to mention this blog if you want to connect on LinkedIn so that I know the context of the connection.
Thanks for reading, there is more to come!