The greatest ills in managing medical software development
Are there differences between managing medical software development and other IT projects? Well, that depends. Imagine such a situation when you start a project and at the outset you have to define some things. Project goal, product owner, team structure (its name, allocation of roles to team members), project events cycle (like daily scrum, planning, review, retrospective). As well as the first elements of the project backlog, rules of cooperation and many more.
Scrum methodology
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. We wanted 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?
Components of managing the medical software development
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. Which 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), and 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. 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, and ensure proper care of the software we make. 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
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?
Onboarding procedure
For those who join the project, we have prepared an onboarding procedure, which explicitly includes, among other things, getting to know the domain of the project, and the basic medical knowledge necessary to work on the project. The final version has been developed by those who have 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. Obviously, 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 (by 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 by the Usability Engineering Process based on IEC 62366. Such established, written and followed rules will allow for the 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, the 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, 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?
Certainly the same as in any other IT project/product. In addition, everything depends on knowledge and awareness of medical standards. Thanks to their analysis and understanding, we can 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
See the prevoius post: Quality assurance in a medical project