The medical imaging industry is used to diagnose and treat various medical conditions. The medical imaging industry has experienced significant growth  over the past decade and is expected to continue growing in the upcoming years. This is due to the demand for diagnostic imaging services increasing with the aging population, an increase in the incidence of chronic diseases, and the need for early diagnosis and treatment. The development of ongoing technological improvements in advanced imaging modalities and software  has shown a drastic increase in the average imaging study size due to improvements in resolution and the increasing use of volumetric imaging.
Healthcare organizations depend on their medical images to help improve patient outcomes. Therefore, being able to securely store, retrieve, and analyze those images reliably and with low latency is crucial. Organizations face an increasing challenge to support a durable local storage solution with image storage growth rates of approximately 30% annually for medical imaging, as well as 90% of all storage at a health system being medical. Until now, systems like Picture Archiving and Communication System (PACS) and related systems have been supported by local servers confined to the premises of radiology clinics and other medical facilities using them. Transferring to the cloud mitigates these concerns while offering less expensive hardware and software support. Providers can realize the cost savings of transitioning to the cloud while preserving low latency performance, enabling them to focus their time and resources to deliver high quality patient care.
In this post, we demonstrate how healthcare organizations can migrate their medical images securely to AWS HealthImaging (AHI), a new HIPAA-eligible capability that makes it easy to store, access, and analyze medical images at the petabyte scale. This new capability is designed for fast, sub-second medical image retrieval in your clinical workflows that you can access securely from anywhere (e.g., web, desktop, phone) and with high availability. AHI helps providers reduce the total cost of medical imaging storage up to 40% by running their medical imaging applications from a single, authoritative copy of patient imaging data in the cloud with normalized metadata and advanced compression.
The core architecture focuses on sending Digital Imaging and Communications in Medicine (DICOM) images residing on-premises to AHI. DICOM is a data interchange protocol, digital image format, and file structure for biomedical images and images related information. DICOM is the standard for the communication and management of medical imaging information and related data. DICOM is used worldwide to store, exchange and transmit medical images. For more information about DICOM.
Typically, medical devices responsible for creating DICOM images are deployed in a hospital/clinic network without Internet connectivity, and they only allow outbound communication to an edge gateway running AWS IoT Greengrass. Edge gateway proxies one or more medical devices, and they run local (on-premises) applications. For this solution the application is designed as a DICOM Message Service Element (DIMSE) interface to be deployed on an edge device on-premises or in a container on cloud (Amazon Elastic Compute Cloud (Amazon EC2), Amazon Elastic Container Service (Amazon ECS). In case it’s deployed on-premises, the application can be managed by AWS IoT Greengrass.
In this solution, the DIMSE interface listens to any DICOM associations in promiscuous mode. This means it accepts connections from anywhere. When the DICOM images are received from medical devices, the data is stored in the local buffer on the filesystem until it is uploaded to a pre-configured Amazon Simple Storage Service (Amazon S3) bucket. The transfer status of the images is tracked in the memory, and when all the images of a given association have been uploaded to the cloud the application sends a manifest of the association content to Amazon Simple Queue Service (Amazon SQS) in a queue called “inbound “. The Amazon SQS event message triggers AWS Lambda, which in turn calls AHI import APIs to store and optimize the data for clinical usage.
Figure 1 – Acquiring DICOM objects from on-premises to AHI
For this walkthrough, you should have the following:
- An AWS account
- Access to create AWS resources
Solution set up with AWS CDK
Follow the setup steps on GitHub outlined here: Solution for DICOM ingestion pipeline to AHI.
DIMSE to Amazon S3 application design
The edge gateway proxies one or more medical devices, and then runs local (on-premises) DIMSE to the Amazon S3 application. The application has a dual purpose: it acts as the DICOM Service Class Provider (SCP), and it is responsible for transferring all the DICOM objects to Amazon S3. It receives DICOM data and proxies it to the AWS cloud via calls to AWS APIs. The application is automatically configured and started by the AWS IoT Greengrass framework. The following steps occur for each DICOM association, and multiple DICOM associations can be handled simultaneously:
1. A DICOM Service Class User (SCU) creates a DIMSE association with the application DICOM SCP ports and starts sending DICOM objects.
2. The application temporarily stores the data into a new folder dedicated to store this association data, created in the /out folder. It also starts to send the DICOM objects to the S3 bucket specified during the application startup.
3. The DICOM client (SCU) closes the association. Data received during this association continues to be sent to Amazon S3.
4. When all the DICOM objects are stored on the S3 bucket, the application publishes a message to the inbound-notification queue in Amazon SQS. The message contains a manifest of all the DICOM objects received within the association.
5. The application clears up the temporary folder created in the dedicated association folder in the /out directory.
6. Every new DICOM object received on the S3 bucket or overwritten object generates an event to Amazon SQS.
DICOM object Indexing in RDS
7. Lambda is triggered by Amazon SQS with a specific profile which makes Lambda wait and gather up to 20 messages available in the queue (or less if there are less messages) and process them in batch. In case of failure in processing, Lambdas will return individual failed messages back to the Amazon SQS queue (for example, in case of deadlock).
8. The Lambda function parses the DICOM header for all the objects, and indexes the DICOM objects within a database. The Lambda gets the file location on Amazon S3 from the event. It downloads the DICOM object and reads the DICOM header using the pydicom library.
9. Once all the DICOM tags of interest are read, they are inserted into a database describing the Patient, Study, Series, and Instance level via the Python mysql.connector library. In the query editor, you can run the following queries to verify that the data is properly ingested in the database.
Figure 2 – Query the database to verify data is properly ingested
Importing in AHI
10. The DICOM object transfer status is tracked in the edge device application memory. When all the objects of a given association have been uploaded to the cloud, the application sends a manifest of the association content to Amazon SQS in a queue called “inbound” dedicated to the edge device.
11. Lambda is triggered when it receives the Amazon SQS event message as input and creates a new Entry as “submitted” in the “Ahlijob” table.
12. A recurring Lambda function polls for submitted jobs and triggers the imports of the DICOM data into AHI.
13. The same Lambda function also monitors the status of the import jobs into AHI, and updates the database with the corresponding ImageSetId assigned to the DICOM studies in AHI.
14. Once the DICOM objects are successfully imported to AHI. you can verify it on the AHI console.
Figure 3 – Verify the Image sets imported to the AHI console
Customers that are independently managing large archives of DICOM data on-premises can use AWS DataSync, AWS Storage Gateway, or the AWS Snow Family to migrate these archives into Amazon S3 and call AHI to ingest APIs to optimize the data for clinical use. Customers with enterprise PACS systems can work with their ISV partners to assist in migrations to AHI. With AHI, healthcare providers and their software partners can run their medical imaging applications in the cloud to increase scale while also reducing infrastructure costs. Providers can realize the cost savings of transitioning to the cloud while preserving low latency performance, enabling them to focus their time and resources to deliver high quality patient care.
We continue with the journey in our upcoming post to demonstrate how the data stored in AHI can be accessed and visualized, so stay tuned.