Romain Bénéteau is a software engineer specializing in Java. He has been working with Keosys since 2016.
"I look for ways to constantly improve imaging management tools for all users involved in clinical trials."
My job is to continuously add value to our products.
To achieve this, I regularly meet with the software users to understand their activities, responsibilities, and their needs in order to improve end user efficiency and productivity.
I then design a solution fitting their requirements that can seamlessly be integrated into the software.
Once it is approved by all stakeholders, I write the codes and algorithms needed following software factory best practices (code quality check, unit testing…).
As you can imagine, most of my time is therefore spent problem solving!
For example, a feature may not work as intended or an interface is not displaying the information needed clearly enough and I need to figure out how to make things better.
That can be tricky at times, but I am lucky to have a great team around me to help me out whenever I need.
The team focuses on 2 specific areas. I personally work on the Imagys platform, Keosys proprietary clinical trial management software. I look for ways to constantly improve imaging management tools for all users involved in clinical trials : the study coordinators, the monitors, the investigational sites and so on.
Whereas some of my colleagues concentrate more on our reading software. They work on making the reading process as easy as possible for our experts while always ensuring regulatory requirements are met since our reading software is classified as a medical device.
As a development team, we also work closely with Keosys R&D department which includes research scientists and PhD students working on the use of AI in imaging. Once a new algorithm is validated, we incorporate their work into our software.
We follow the scrum method in Agile methodology which involves strong communicative teamwork and frequent feedback from clients, our internal teams, and other stakeholders. We have a backlog listing all requests from which we build high level roadmaps to plan and prioritize.
We have a specific roadmap listing the platforms needed for new studies. The process to build a study platform is straightforward. During the start-up phase, our scientific team writes with the sponsor the imaging review charter and the image acquisition guidelines. Once they are signed off, the project manager writes the software specifications giving us all the instructions needed to develop the platform. Depending on the complexity of the trial, this task can take only a day or up to 3 months.
We also follow a product roadmap for features that are common to all trials and for which we release new versions of our software every 2 to 3 months. For these, we form feature teams with members who have a different set of skills to focus on a specific customer-centric feature. Each team is responsible for delivering its feature and ensuring that it is stable and long-lived.
There are different kinds of tests. We start with the unit testing of the code during the development phase which includes automatic tests to ensure there is no regression regarding the other features already in the software.
Then all stakeholders in the feature teams - which always includes a testing engineer - test the added feature. On a project level those tests that we call User Acceptance Tests are carried out by the project manager and even sometimes the sponsor. These tests are essential to make sure that everything is developed according to operational needs. For example, a user will check that the reading workflow implemented is as described in the imaging review charter.
And finally, we test to ensure that any new feature is correctly integrated in the whole system. This is done by Keosys’ senior testing engineer.
The main challenge is usually technology integration and upgradation. For example, we need to adapt to the wide range of operating systems and IT environments that we can expect when managing sites worldwide. At the same time, we also need to take into consideration data integrity and security for regulatory compliance.
In development you must also regularly rethink current processes and what I find hard is to accept that what I previously did wasn’t good enough and needs to be changed. However, as anyone would tell you, in the field of technology change isn’t easy, as it is all about ensuring maintainability. Your code needs to easily be changed without breaking the whole system or creating insanely high additional costs.
You need to be creative sometimes and that’s why I feel it’s important to leave your comfort zone because that’s how you learn, grow and innovate! For example, I recently led for the first time a workshop on improving both user experience and user interface while I usually focus more on the code behind the scenes.
We’re focusing on a long-term project at the moment to reshape the user interface. Last year, we started with the supervisor role to gain in efficiency in project management and study coordination. We’re now continuing this overhaul for other users such as the investigational sites, the quality controllers and the central readers. We’re currently in the conception phase following feedback from users.
On a smaller scale, we’re also working with our R&D team to integrate the latest automatic volumetric tools they have developed to help our readers with lesion assessments and limit inter-reader variability.
We actually have a new release coming up soon, so watch this space, more information to come!