Skip to content

Latest commit

 

History

History
87 lines (63 loc) · 4.43 KB

README.md

File metadata and controls

87 lines (63 loc) · 4.43 KB
Raw

Back to Projects List

Lightweight DICOMweb Server with CouchDB

Key Investigators

  • Emel Alkim (Stanford)
  • Steve Pieper (Isomics)
  • Andrey Fedorov (BWH) - interested to deploy and test the resulting platform
  • Markus Herrmann (CCDS)
  • Tobias Stein (DKFZ)
  • Marco Nolden (DKFZ) - optional CTK/C++ based client side testing

Project Description

This project aims to work on a prototype lightweight DICOM server that will support DICOMweb standard and host the DICOM files as JSON objects. It will leverage previous work on SlicerChronicle and dcmjs.

Objective

  1. Provide prototype of a lightweight DICOM server that supports DICOMweb queries
  2. Provide an example implementation of a proxy layer to transfer DICOMweb queries to CouchDB

Approach and Plan

  1. Review and define project ideas
    1. Consider how to encapsulate DICOMweb logic so that it facilitates use in servers, but also in testing and other scenarios
    2. Define a reasonable subset of DICOMweb that can be supported easily (at least basic QIDO/WADO/STOW RS)
    3. Pick a nice web server infastructure that can easily implement rest api proxies
      1. maybe build on express/pouchdb-server
      2. also look at fastify
    4. Find an easy way to host the service for development, testing, and demos
  2. Implement an example translation of a DICOMweb query to CouchDB map/reduce statements
  3. Implement translation of the CouchDB response to DICOMweb response
  4. Build a bridge between SlicerChronicle and dcmjs to host the DICOM files as JSON files and support CSTORE

Progress and Next Steps

  1. SlicerChronicle stores DICOM object instances as documents in CouchDB

  2. Repository created in https://github.com/emelalkim/dicomweb-server-js using fastify node.js framework

  3. DICOMweb queries and CouchDB views created for:

    1. QIDO
      1. {s}/studies endpoint: Query for studies
      2. {s}/studies/{study}/series endpoint: Query for series
      3. {s}/studies/{study}/series/{series}/instances endpoint: Query for instances
    2. WADO
      1. {s}/studies/{study}/series/{series}/instances/{instance} endpoint : WADO-URI Retrieve Instance
      2. {s}/studies/{study}/metadata endpoint: Retrieve study metadata

  4. JSON schemas defined for QIDO query responses for studies, series and instances level

  5. Implemented STOW using some parts from Dicomweb-client (https://github.com/dcmjs-org/dicomweb-client) and dcmjs (https://github.com/dcmjs-org/dcmjs)

  6. Improve code base with documentation, organization and testing

  7. Handling different tag values throughout study

    1. If there are different values for different series: We are thinking of showing an interface to fix
    2. If same uid is used with different values: We will show user notification. Optinons are overwriting or letting the user fix. We will start with overwriting

  8. Handling multiframes and frames endpoints

  9. Handing compression

  10. Integrate Dicomzero code to dcmjs utils

  11. Message.js should be exported from dcmjs to be used in this project

Side project C++ : this made some progress in parsing the JSON query results in C++, next steps will be to refactor some methods inside CTK to use JSON objects instead of relying on DcmDataset for internal storage and passing around of DICOM meta information. experiment code

Illustrations

Example sequence diagrams STOW and WADO-URI example WADO metadata example

Background and References