GSoC Week 5

From LH-RIS Viewer to AI Model Service


Last week, I primarily focused on coding and making updates to the LH-RIS (Libre Health Radiology Information System) viewer. This week, my work shifted towards the LH AI Model Service.

The current architecture of the Flask REST-API within the AI Model Service was unfamiliar to me. It was built in an object-oriented style, which seemed complex compared to the simpler implementations I've encountered in the past. As such, I took my time to understand the system's components before implementation.

Implementing the Model Selection API


Once I grasped the system, I dived into implementing the Model Selection API. We introduced a few methods on the viewer side that now transmit Dicom tags information and the new model configuration settings, input by the admin in the administration settings. This information is crucial for the Model Selection API, as it determines which model to invoke on the fly.

The concept behind the Model Selection API is straightforward: It offers a flexible endpoint enabling the switch between different ML models dynamically. This approach eliminates the need to hardcode the model choice in the application, as the Model Selection API uses the model argument in the API request instead.

The Model Selection Algorithm in Action


The model selection algorithm follows these main steps:

- Parse the DICOM tags, model properties, and other information relevant to model selection.
- Analyze the DICOM tags information to see if specific tags suggest that the image belongs to a particular modality. (For example: The attribute "BodyPartExamined" with a value "CHEST" would suggest a chest x-ray.)
- If the tags suggest a certain modality, the algorithm filters the model properties for that specific modality.
- With the "task" and "endpoint" properties of the filtered model properties configurations, the algorithm can call the corresponding model. It creates form data and file data (image) and makes a POST request to it.
- By implementing this way, there was no need to modify existing model methods like cheXnet. After testing the implementation on the AI Model Services and debugging a few errors, the output from the Postman call worked flawlessly.

Integration Testing and Future Plans


For the final part of the process, I ran both Docker images with the updated code to ensure the model selection works as intended between the viewer and the AI Model Service. After uploading a DICOM image with proper tags to ORTHANC and opening the study from the study list, it triggered the AI Model Service. The results from the AI Model Service then appeared on the viewer without any errors.

Moving forward into next week, I will align on my Merge Requests (MRs), make adjustments based on my mentor's feedback, and then proceed with modeling.

Comments

Popular posts from this blog

Google Summer of Code 2023: AI Model Service Auto Selection by Modality - Final Report

GSoC Week 1

My First GSoC - LibreHealth Community Bonding Period