aws-samples/aws-healthimaging-samples

Sample projects on working with AWS HealthImaging, an AWS service that allows you to store, analyze, and share medical images in the cloud at petabyte scale.

AWS HealthImaging Samples

This monorepo provides examples on working with the AWS HealthImaging service.

AWS HealthImaging is a new HIPAA-eligible capability that enables healthcare providers and their software partners to easily store, access, and analyze medical images at petabyte scale.

• Ingestion
• Validate/Verify
• Retrieval
• Proxies
• Front-End
• Security
• License

Ingestion

S3 StoreSCP

This AWS CDK project implements a DICOM StoreSCP listener capable of receiving DIMSE messages and storing the received SOP instances as DICOM Part10 files on Amazon S3. The listener is deployed as service on AWS ECS Fargate. DICOM Part10 files stored on S3 can then be imported into AWS HealthImaging.

DICOM Ingestion From On-Prem to AWS HealthImaging

This AWS CDK project allows to host a DICOM Service to receive data via DICOM-DIMSE and ingest it to S3 and HealthImaging. The on-prem service is hosted as part of AWS Greengrass IOT service. The project also demonstrates how to profile DICOM data, index it into a database and manage a queue of import jobs into AWS HealthImaging.

AWS HealthImaging Metadata Index with RDBMS and Datalake (Athena)

This AWS CDK project allows the indexing of DICOM metadata as it is being imported in AWS HealthImaging. The metadata can be stored in a relational database (RDS MySQL) and/or a data lake (Amazon S3 with AWS Athena), enabling with query and analytics capabilities.

Validate/Verify

Pixel Data Verification

This example demonstrates how to use the AWS HealthImaging Pixel Data Verification feature to ensure the image you decoded matches the original DICOM P10 Image.

Retrieval

AHI Batch Image Frame Retrieval

This repository contains a C++ library and command line tool that performs high speed batch image frame retrieval from AWS HealthImaging. These can be used to rapidly download large data sets to support various workflows such as AI/ML training, AI/ML inference, image processing and visualization. This is helpful because existing applications are implemented in a variety of languages and runtimes many of which have limitations related to concurrent downloads and decompression that prevent them from fully utilizing AHI's performance.

Proxies

Tile Level Marker (TLM) Proxy

This AWS CDK project allows you to retrieve image frames from AWS HealthImaging by using tile level markers (TLM), a feature of high throughput J2K (HTJ2K). This results in faster retrieval times with lower-resolutioned images. Potential workflows includes generating thumbnails and progressive loading of images.

Amazon CloudFront Delivery

This AWS CDK project allows you to retrieve image frames from Amazon CloudFront, a content delivery network (CDN) service built for high performance, security, and developer convenience. Image frames are delivered from AWS HealthImaging to an Amazon CloudFront Point of Presence (PoP) via the AWS network backbone, then delivered to the user. Subsequent retrievals are delivered directly from the PoP, reducing latency and increasing performance.

Front-End

AWS HealthImaging Viewer UI

This AWS Amplify project deploys a frontend UI with backend authentication that allows you to view imageset metadata and image frames stored in AWS HealthImaging using progressive decoding. You can optionally integrate the Tile Level Marker (TLM) Proxy and/or Amazon CloudFront Delivery projects above to load image frames using an alternative method.

Security

See CONTRIBUTING for more information.

License

This library is licensed under the MIT-0 License. See the LICENSE file.

aws-healthimaging-samples's Issues

Duplicate image sets !!!

Hi,

I am new to the HealthImaging service and trying it out for a personal project. I was trying to import some of my sample dicom files from my S3 to the healthImaging service. I was able to do the import with the help of the import job successfully through the console, but the issue here is when I run one more import job over the same files in S3 it will again create the same image set that it created before as a duplicate.

I got wondered why the service is again importing the same image set which I imported just before. The duplicated one have exact same "version" also. I was expecting some duplication prevention (De-dup) algorithm in the service. As per my understanding based on the official docs(please correct me if I am wrong) there is only option to specify the source S3 bucket with the prefix in the Import job rather than specifying the dicom files for the import job. So if I want to import a new file from the same S3 prefix folder, I have to either remove the old one from there to prevent duplicate image set or process all of the together(Old+new) such that I will have duplicate image sets in my data store.

Please help me out to figure out whether it is a feature or issue. Thank you.

DICOM Images are not being put on HealthImaging

The project was successfully deployed, and after running a local EC2 instance to send the dicom imeages, the images are uploaded to s3 bucket successfully and the metadata is visible in the RDS table. However in HealthImaging the dicom data is not getting stored, nor are the rds ahli tables populated.

Coloured DICOM Images are not showing correctly

I have tried a colored but it seems to be not showing up correctly, have attached original image along with image viewed on the Viewer for your reference.

-SK

Recreating DICOM compatible data from AWS Health Imaging service.

Hi,

We are exploring the capabilities of Health Imaging Service for consuming it for one of our use case.

Use case:

1. Import the DICOM data from On-premise to Health Imaging.
2. Apply some AI/ML algorithms over the data set(using sage maker or something).
3. Use the inference result to create a new Image data set based out of the original data set by adding some annotations , color mapping etc.
4. Now I want to store the processed data set back to On premise PACS or to show in a Standard DICOM Viewer deployed locally.

For implementing the 4th step following tasks are expecting.

1. Retrieve newly created data set as meta data and Image data using Health Imaging APIs.
2. Uncompress the image data.
3. Re-create the DCM format data using the meta data and uncompressed pixel data.
4. Push to PACS using C-STORE/STOW DICOM communication.

But I am not seeing any sample implementation for the same among the given examples.
Is it not a recommended use case for Health Imaging Service?

Or

Is there any recommended way for doing this?
What deployment modes are preferable for achieving low latency and high performance?
I am mostly concerning about the time taken for uncompressing and re-stitching the DCM files.

Looking forward to your thoughts on this.

how i run this .

i saw multiple folders hear. so how i run this.

kindly update the read.me file for this.