GSoC LibreHealth 2023

 This week I worked on one big task which is, - Integrating mammography cancer classification model The Challenge Initially I planned and still plan on integrating the RSNA mammography cancer classification top ranked model from kaggle. As I dug deep down into the code base of the top solution I realized it is going to take time to integrate it. It uses a YOLO model to detect the mammogram area to crop out and then uses a convnext model to perform classification. I already used a day to figure out integration aspects and how I can productionize it in the LH radiology application. Thinking about this complicated model and also integration strategies it was quiet overwhelming. So I wanted to somehow break down my tasks, strategize and integrate it. Plan of Action Meanwhile I remembered of the VGG16 model that I created to do mammography cancer classification at the start of GSoC. I decided to first integrate the VGG16 model since that would allow me to setup the codebase in the applicati

 This week I worked on three things - Refactoring the model selection code base to move from endpoint redirection to calling the actual methods by importing them - Added test cases for model selection and fix issue with docker image - Progressing on integrating the mammography breast cancer classification model Refactoring the model selection code base The model selection code base was implemented initially where it looks at the imaging information and redirects to the appropriate model endpoint. Something like this, The problem faced with this way of implementing it, the base url was hardcoded and pointed to localhost. Mind that only if systems had set their localhost in their hosts file this would work and hence it was not system agnostic. This was causing my model selection test cases run in my local but not in the gitlab ci/cd pipeline. The other thing I read was in RESTful services this sort of redirection is generally not a good design since in RESTful each endpoint is considered

This week I was able to discuss with my mentor on  my progress and the merge requests. I took him through the changes I made. My mentor suggested a few minor updates to make and there were methods for which the GET method were not setup and we also questioned what their functionality would be. Updates to the Bounding Box Endpoint The /bounding-box endpoint was necessarily a POST method where payload consisting of the image and its relevant information is sent to perform model inference and return them back. The GET method which was previously defined returned all models available in the application. It was redundant to the /models method. We decided to update the /bounding-box GET method to return only the models available under it and their versions. For this task I reorganized the folder structure from models/cheXnet to models/bounding_box/cheXnet. This update opens up a lot of flexibility in terms of integrating models. In future we can have more models under /models/bounding_box an

This week, I was deeply involved in refining and optimizing the model selection hook's implementation on the AI model service end. I also discovered that the existing cheXnet model was not integrated correctly, and I spent some time rectifying that. On top of these tasks, I'm concerned that I have not been able to arrange a meeting with my mentor despite numerous requests. Hopefully, that will change next week. Refining the Model Selection Method Last week, I implemented the model selection method on the AI Model Service end, but some settings, such as the DICOM tag information required for model selection, were hardcoded. Other property-related information was also hardcoded. This week, I focused on separating the hardcoded elements and parameters into a separate YAML configuration file and refactoring the codebase. I learned that using a YAML configuration simplifies the maintenance of the codebase by reducing boilerplate code. Subsequently, I updated the model call method to