Agenda Items:
- Database and metadata related issues with DICOM
- ImagingDataCommons/dicomweb-client#57
- S3 Native DICOM Web Adapter DICOMWeb Client (Python Client)
- Is a database still a bottleneck for QIDO-RS only?
- Is there alternative architectures? Pregenerated data?
- Three levels of queries (non relational)
- Patient/Study
- Series
- SOP Instance
- Question: DICOM in the real world has data missing - is this normal?
- Answer: yes unfortunately, each vendor needs to assume data is bad and provide workflows to fix it
- Question: Should dicom on disk be kept up to date, or leave it dirty and have DB be the master?
- Answer: IMO, the data on disk should be kept up to date, the DB should not be authoritative
- Question: Should you keep the original DICOM as received?
- Answer: Yes, although maybe exception for pixel data
- Question: What are the options to do indexed look ups on Study Level Attributes (patient name, patient id, study date)
- RDBMS
- Pros: Everyone knows how to use them, ACID transactions, good query support, can do more complex queries than CFIND (e.g. operational analytics)
- Cons: Expensive (probably)
- NoSQL
- Pros: More scalable than RDBMS, more cost effective (probably) than RDBMS, good enough query support
- Cons: Does not have ACID transactions (probably), harder to add indexes (depends on implementation)
- In memory indexes (redis, in RAM with language)
- Pros: Super fast, can scale with sharding, can do updates atomically (probably)
- Cons: How to store on disk?
- Object Storage Attributes
- Pros: no additional tech - feature of object storage
- Cons: Indexable (probably?)
- FHIR (ImagingStudy document)
- Pros: keeping DICOM metadata up to date not as big an issue (FHIR is authoritative)
- Cons: hard dependency on FHIR
- RDBMS