AWS EKS high level diagram

This is a high level diagram of our entire system on AWS EKS.

External PACS Server: Serving as a link to hospitals, this component acts as the gateway for incoming medical imaging data.

Study Pipeline:

• Internal PACS Server: Facilitates secure communication between hospitals and our system.
• Data PVC (Persistent Volume Claim): Safely stores DICOM data transferred from the PACS.
• Listening Agent: Periodically checks for new data in our internal PACS server
• Study Handler: Initiates the study pipeline process by spawning study jobs.
• Product: Processes the data and creates results to send back to the hospital

Job Monitoring App:

• Database (PostgreSQL)
• Backend (Python)
• Frontend (React)

A hospital PACS begins by sending data to our internal PACS. Our listening agent checks for any new data. Once new data is found the study pipeline kicks off and a study job is spawned. Within this job the data is downloaded, received, processed, and returned. Once we hit the processing step a product job is spawned. This product job processes the data and creates readable results to send back to the hospital PACS. All while this is happening a user can log in via the frontend and view the timeline of events for this particular study in real time.

---

ER

original job monitoring app

This is the original schema our database. As you can see it does not align with medical imaging terminology and is very generic.

Updated job monitoring app 2-28-24

This is our updated schema for our database. We have included Hospital and Provider tables as well as adding new roles to users. The idea here is that a user can be associated with a hospital or a provider. Also, we now use the term "study" instead of job to align with the goal of our project: processing medical studies.

System diagram 3-25-24