The greatest ills in managing medical software development
By Daria Bernys
Are there differences between managing the development of medical software and managing other IT projects? Well, that depends. Imagine such a situation when you start a project and at the outset you have to define: project goal, product owner, team structure (its name, allocation of roles to team members), project events cycle (like daily scrum, planning, review, retrospective), first elements of the project backlog, rules of cooperation and many more. What helps in defining these issues is the Scrum [1] methodology. The requirements defined by ISO [2] and IEC [3] should also be added to this list. And at this point you will either feel that you are losing ground – because there is no book, no bible on project management that will tell you how to combine project management methodology with the standards and requirements of medical products, or you will prepare a plan and focus on areas where taking care of the combination of these two worlds is most important.
We have chosen option two. What we wanted was for the project, the application we produce, to meet the requirements of the medical product, but it was also essential for us to maintain the awareness that it is still software production. Being more precise – creating software in medical imaging. And exactly this order was the key for us to reconcile the two worlds: IT and medical product requirements.
Managing medical software development – to harness the “enemy”
However, when you focus on directly linking individual requirements to the software development cycle it is a bit easier. Trying to picture the planning process, for example, you may see in your mind’s eye a team of talented ambitious and positive people who are just now discussing the possibilities of implementing another system function. An image like that could easily make a ready-made graphic for marketers, couldn’t it? And now you throw in a few bricks into this beautiful setting, in the form of ISO and IEC standards. A pleasant view? We don’t think so. Now let’s tweak the situation a bit, you still have a great team, which already at the start of the project gets to know the above mentioned requirements, understands their purpose, in addition to the standards presented in the form of a solid text, there are also studies of people who have analyzed them before, you can talk to an MRQ (Manager Responsible for Quality), where you work there is a QMS (Quality Management System) [4] in place, and when you start working in the company you receive training on its principles.
In our opinion one of the most important things is to understand what these requirements are for, what they are like, what they mean for our specific project, and then you will understand that, in addition to the initial requirements, they carry a lot of positives. They systematize the work, teach open thinking, take care of the structure and order, ensure proper care of the software we make, and finally, they relate what we do to the end user that is, what this software, this project, this medical product will ultimately be.
Managing medical software development – knowledge silos and continuity of rotation in the team
In the medical device production team, just like in any other development team, there is a phenomenon of rotation of team members – some people leave, but new people join in. In order to ensure continuity of work and minimize possible loss of project knowledge, it is important to disseminate it, especially in the case of complex projects such as medical software development, where it is important to get to know the domain and even knowledge outside of IT. How to address this?
For those who join the project we have prepared an onboarding procedure, which includes, among other things, getting to know the domain of the project, and the basic medical knowledge necessary to work in the project. The final version has been developed by the who has collected the knowledge already written down, publications and conclusions from the workshops with the doctors we cooperate with.
In our Sens.AI [5] project we cooperated with doctors, medical physicists or hospitals and research centres. It is our project practice to make notes of such meetings, which we then publish in our documentation. Thanks to this, we have constant access to information important for the project, and this knowledge can be available to members of the development team at any time.
In a situation where someone leaves, there is also a helpful procedure, but this time for leaving the team. It determines, among others, knowledge transfer, assignment of tasks to other team members, or copies of important data from the project space of the person who is about to leave.
Adjusting the Definition of Ready and Definition of Done
DOR [6] and DOD [7] should be adapted to the standards of medical projects. The easiest way to adapt them is to know ISO and IEC standards and to complete our list with such points as the requirement number (in accordance with the defined project requirements), the need to update the documentation, review of the documentation by team members (to verify the correctness of records) or implementation and verification of changes in accordance with the Usabillity Engineering Process based on IEC 62366. Such established, written and followed rules will allow for efficient execution of tasks, while taking care of necessary standards.
CAPA (Corrective Action and Preventative)
Picture this: everyone in the IT industry creating or writing flawless applications—without any bugs, objections, and where everything works perfectly. Let’s be honest, in the real world, achieving such perfection is nearly impossible to implement. While it might be theoretically conceivable, it would demand an extraordinary amount of effort. Estimating the magnitude of this effort proves to be quite challenging.
In the context of medical software development, it becomes essential to consider the unique demands of our product implementations. These include requirements stemming from hospital infrastructure and the intricate interplay between hospital systems and medical applications.
At Graylight Imaging we focus on defining the process of feedback and troubleshooting, Issue Review Process, review of reports by CAPA team. Depending on the type of request, it can be handled in the request system as a functionality request, a task or a bug. The project leader and support team are responsible for the review, the analysis and coordination of the requests. All our activities are naturally focused on risk analysis according to ISO 14971.
Reconciliation of two worlds
What are the biggest problems in managing medical software development?
Mostly the same as in any other IT project/product. Everything depends on knowledge and awareness of medical standards. Thanks to their analysis and understanding, we are able to produce medical imaging software in such a way that you will like this job and you will like it very much! Is it always easy and fast? No, but you can learn a lot from it, it is an experience unique from others and a satisfaction second to none.
Contact us if you have any questions!
References:
[1] Scrum methodology https://www.scrum.org/
[2] ISO https://www.iso.org/home.html
[3] IEC https://www.iec.ch/homepage
[4] QMS https://www.iso.org/standard/59752.html
[5] Sens.AI https://sensai.eu/en/
[6] DOR https://www.scrum.org/resources/blog/walking-through-definition-ready
[7] DOD https://www.scrum.org/resources/blog/walking-through-definition-done
