The challenge of MedDevOps is partly similar to DevSecOps: There is an area of expertise that deeply impacts design and development, yet is not fully understood by the developers. As with DevSecOps, you will need to include compliance experts in the development team, who will lead and evangelize the inclusion of compliance in the daily work.
If your organization is not familiar with medical software development, there may also be a DevSecOps-like challenge of “shifting compliance to the left”. If compliance is only considered once the system has already been developed, the likely result is expensive changes. The solution is again similar to DecSecOps: You will need to re-design your processes and toolchains so that compliance is included in the workflow as early as possible. You are in any case required to have a medical device Quality Management System (QMS), so it is advisable to design your QMS processes with MedDevOps in mind. This also applies to compliance with HIPAA and GDPR, e.g. applying Privacy by Design and Privacy by Default requires privacy to be considered early on – another example of “shifting to the left”.
However, medical device compliance also brings its own unique challenges:
Agile Software Development
The safety requirements of medical compliance and the practices of agile software development are to some degree at odds with each other. The purpose of agile software development practices is to embrace change, whereas safety requires us to control change so that we can minimize risks. In order to guarantee safety, we must sacrifice some agility. A DevOps way of working is still possible, but your software deployment process will have to include a large amount of testing, and any significant changes will require approval from your Notified Body prior to release. You will need to be obsessive about both test coverage and test automation. Note that Continuous Deployment is not possible, because there has to be some kind of human approval process before something is deployed. But Continuous Delivery is achievable.
Documentation
Whereas the agile manifesto values working software over comprehensive documentation, compliance values documentation very highly. Your documentation must prove that your software does exactly what was intended, and that all the required procedures (such as risk analysis, software verification and change control) were followed to the letter. You will need to design your tools, processes, and documentation templates so that as much documentation as possible can be automatically generated. For example, your automated testing framework should allow you to automatically produce test reports that include full traceability information, tracing test cases to requirements and showing that all requirements have a comprehensive set of test cases. Similarly, your change management tools should produce a complete record of the processing of each change request, and your risk management tools should produce risk management reports ready for release approval by management.
Procedures
You will have to define and implement a large number of procedures. For medical software development, when the Quality Management System is included in the consideration, approximately 20-30 procedures are needed (for examples, see e.g. this list by Advisera, although that only includes the basic QMS part and you will likely need additional procedures to cover the software development lifecycle). The number varies depending on how you organize your procedures; they are like functions in a program. You could put all the program code in a single main() function, but that would make the program difficult to understand and maintain. Smaller functions are easier to maintain but increase design cost and distributed program logic can be hard to follow. The same applies to medical software development procedures. Incidentally, the Quality Manual document pretty much corresponds to a main() function, and you can put all the procedure-related documentation there, but it becomes very unwieldy, just like with program code.
However, it gets worse. For HIPAA and GDPR compliance you will need another 20-30 procedures (see e.g. this nice summary by TrueVault). This is mainly due to HIPAA, so if you are targeting only Europe, and hence only have to comply with GDPR, you need a little less.
People mainly working with software often underestimate the work it takes to define and implement a procedure. E.g. for HIPAA compliance you are likely going to spend more hours on procedures and documentation than on technical compliance work such as implementing encryption, although that will obviously depend on your starting point and technical constraints. Software only has to work with computers, and computers are predictable, easy to understand, learn instructions instantly, never forget or question them, and follow them literally. People, however…
Because you are in any case going to spend a lot of time on those procedures, you should strive to make them useful and not just something done for the sake of compliance. A procedure should always add value. Design your procedures to support automation and invest in developing automation to reduce the overhead.
The Long Road
Medical software cannot be safe if it is not secure. MedDevOps must therefore include also DevSecOps practices, integrating security into the development process at every level. That means threat modeling, code scanning, scanning for vulnerable software components, fuzz testing, automated vulnerability scans before release, penetration testing, and so on. So MedDevOps is something you do in addition to DevSecOps.
It takes a lot of effort to move to DevOps. When you have achieved DevOps, it takes a lot of effort again to reach DevSecOps. And then it takes a lot of effort again to reach MedDevOps. The overall journey is a long one.