The greatest ills in managing medical software development
Is managing medical software development different from managing other 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 methodology. The requirements defined by ISO and IEC 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.
I have chosen option two. What I wanted was for the project, the application we produce, to meet the requirements of the medical product, but it was also essential for me 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 me 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? I 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) in place, and when you start working in the company you receive training on its principles.
I think 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 Lead Developer who has collected the knowledge already written down, publications and conclusions from the workshops with the doctors we cooperate with.
In our Sens.AI project we cooperate 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 and DOD 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)
I guess everyone in the IT industry would like to create/write flawless applications. Release the perfect work, where there are no bugs, no objections – me too. And now, let’s think realistically: I don’t think it’s possible. It may be possible, but with very, very much effort. It is even hard for me to determine how big.
In the case of medical projects, it is worth taking into account the specifics of our product implementations, such as the requirements of hospital infrastructure, the relationship between hospital/medical applications.
In Future Processing Healthcare 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.
