Project: Automated Artifact Detection and Annotation in LibreHealth Radiology

Projects Radiology
, , ,
23

Hi @sunbiz as the bower registery is dead i updated the dependencies using their github urls with the same versions as earlier and opened an MR.

1 Like
24

@TejasSA88 Think of the tooling that would make it easy for people to test what you’re working on, and this would be like, for example, a good Docker where people can just see what your updates are. I think that makes it easy to assess and give you feedback.

1 Like
25

Sure @judywawira i will be doing that one

26

Hi @Rohan.isaac27 @sunbiz, if you both are free this weekend i would like to schedule a call so that i can discuss the weekly goals and also the structure of the program also to clarify some doubts.

@sunbiz I have opened an MR regarding the Bower registery offline issue Iam not sure if i followed the correct process of opening an MR so please correct me if iam wrong.

MR URL: Updates bower.json dependencies to use direct GitHub URLs to fix the broken central Bower registry during Docker builds. (!79) · Merge requests · LibreHealth / LibreHealth Radiology / lh-radiology · GitLab

28

Hi Everyone below are the things which i have done so far.

  • The OHIF Viewer was using the Bower package registry as it was deprecated it broke the container builds. So I manually updated the bower.json dependencies to pull directly from GitHub URLs. The MR for this issue got merged.
  • The OHIF Viewer was not able to load the DICOM data as it was pulling the frozen image from the gitlab registery.
  • I have reported the frozen image issue to @r0bby. In the meantime, to keep my development completely running, I am running the backend databases via Docker and spinning up the Meteor frontend locally. Everything is connecting perfectly and I am fully unblocked to write code
29

Hi @sunbiz @Rohan.isaac27 for the coding period I have planned to do a few things mentioned below for the starting of my coding period. Before the coding period starts I will be testing and looking into the codebase as to develop the following features and the FastAPI server later I need to draft an architecture and make sure that none of the data pipelines collide.

  • WEEK 1: I will create a JavaScript object which will hook into the OHIF and Meteor architecture. I plan to add a new Find Similar Artifacts tool in the toolbarsection.js It will integrate with the existing doctors workspace. planned to implement a capture phase event listener on the new button.
  • WEEK 2: I planned to use the already existing RectangleRoi tool in Cornerstone.js to extract the start, end of the region in the x and y axis. I will be implementing a UI error handler to prevent empty payloads. I will also be implementing an environment fallback pattern so the frontend can run in production without any changes.

As we come to the Dataset I will be using some external ones for the testing purposes. Also for the selection of the ROI I have planned to use the existing RectangleRoi tool what are your views on it.

Tell me if there are any updates in the plan that you suggest so that I can make changes before the coding period begins. I will be posting the full planning and the new data pipeline architecture in a couple of days.

1 Like
30

PHASE 1:

  • WEEK 1: Architecting the ArtifactManager object to hook into OHIF/Meteor safely. Building the Find Similar Artifacts ROI selection tool in the toolbarsection.js and establishing a capture-phase event routing.
  • WEEK 2: Using the RectangleRoi tool to capture the rectangle box coordinates. Implementing the environment fallbacks and securing the DICOM SOP instance UID.
  • WEEK 3: Deploying the FastApi Server. Establishing the internal network bridge to Orthanc. Writing the logic to download the .dcm files into memory and crop the numpy matrices based on the frontend user coordinates.
  • WEEK 4: Establishing the Pytorch environment. Passing the cropped numpy arrays in the MedSam model to extract the 1D feature embeddings of the artifact.

PHASE 2:

  • WEEK 5: Implementing the spatial tracking algorithm. Once the artifact is embedded on slice N,writing a logic to query the Orthanc for the adjacent slices and applying the bounding box to these slices for automatic cropping.
  • WEEK 6: Passing the newly cropped matrices through the MedSAM to extratct the embeddings. Writing a mathematical scoring function to compare these embeddings with the adjacent slices and also across the whole active radiological worklist.

Phase 3:

  • WEEK 7: Building a return data pipeline. Sending the MedSAM’s similarity predictions from FastApi back to the frontend. Visually rendering those pixels automatic segmentation masks on the other slices.
  • WEEK 8: Implementing the review and validation mechanism. If the radiologist deletes an incorrect prediction it will capture that event and routes it back to the backend by this it will adjust the similarity threshold, training the system on user selected examples.

Phase 4:

  • WEEK 9: Converting the validated annotations into DICOM Structured Reports. Implementing metadata synchronization and version control so that every time radiologist edits an annotation, a new version is saved to Orthanc. Generating a performance analytics payload to display to the user.
  • WEEK 10: Writing an automated unit tests for the FastAPI endpoints and the MedSAM tensor conversion logic. Building a GitLab CI/CD pipeline to automatically run these tests, executing the license-maven-plugin checks, and pushing the successfully compiled Docker images directly to the registry on every commit.

Phase 5:

  • WEEK 11: Writing a documentation covering the new data pipeline architecture. Creating a training guide for radiologists on how to use the tools. Solving any remaining merge conflicts and getting the final architecture merged into the main branch.

Hi @sunbiz and @Rohan.isaac27 this is my weekly plan for this project i have kept it for 11 weeks so that i can have an extra week to validate the whole project and also if something goes wrong i can cover it in this week . If there are any corrections needed please let me know.

31

Hi @sunbiz @Rohan.isaac27 There was an specific error while running the OHIFViewer via docker, in which the viewer was not able to get the .dcm files from the Orthanc, throwing the error as ECONNREFUSED

MR LINK : Fixed the OHIFViewer ECONNREFUSED issue (!80) · Merge requests · LibreHealth / LibreHealth Radiology / lh-radiology · GitLab

In the above MR the issues are resolved:

  • publicOrthancDICOMWeb.json had dicomweb.ohif.org hardcoded into the compiled Meteor bundle. This acts as an entrypoint shield, ignoring local Docker Compose environments and forcing requests to an offline server.
  • The Orthanc Image was deprecated updated it with the new one
  • Updated the lh-toolkit to download the image rather than building each time.
1 Like
32

I went ahead and merged that your MR

1 Like
33

Hi @sunbiz @r0bby @Rohan.isaac27 Just opened an initial draft MR for week 1 with the following features:

  • Created ArtifactManager object
  • Created ROI selection tool
  • Drafted the EventListener

Please Report it to me if there are any changes required

MR LINK: Week1 ArtifactManager (!82) · Merge requests · LibreHealth / LibreHealth Radiology / lh-radiology · GitLab

1 Like
34

Hello everyone,

Regarding the MedSAM model weight – is it better to store the weights in the repo, or to download the weights in Docker and store them in volumes?

36

Hi @r0bby the Rocket chat is down right

37

It’s back online. Did an update.

1 Like
39

Hi @Rohan.isaac27 @sunbiz @r0bby It was a great summer working with you guys. ThankYou for everything. I will continue to contribute to the community Thankyou

1 Like
40

Hi @r0bby @Rohan.isaac27 @sunbiz – The current open MRs have not been merged to the topic branch – It would have been helpful for my next works if the MRs got merged to the topic branch