Slides from the full-paper presentation at the 27th International Symposium on Computer-Based Medical Systems (CBMS), 2014.

1. Evaluating a row-store data model for
full-content DICOM management
Alexandre Savaris, Theo Härder, Aldo von Wangenheim
University of Kaiserslautern – Dept. of Computer Science – Kaiserslautern – Germany
Federal University of Paraná (UFPR) – Dept. of Informatics – Curitiba – PR – Brazil
National Institute for Digital Convergence (INCoD) – Florianópolis – SC – Brazil

2. Evaluating a row-store data model for full-content DICOM management 2 / 28

3. Evaluating a row-store data model for full-content DICOM management 3 / 28

4. Evaluating a row-store data model for full-content DICOM management 4 / 28

5. DICOM content is:
• Structured at tag level
– Group/element ordered pair
– VR (Value Representation)
– VM (Value Multiplicity)
Modality
– (0008,0060)
– CS (Code String): 16 bytes maximum, accepting
uppercase characters, “0”-”9”, the SPACE character,
and underscore (“_”)
– 1 (a single value per tag)
Evaluating a row-store data model for full-content DICOM management 5 / 28

6. DICOM content is:
• Semi-structured at image level
– Tags are known at the evaluation (parsing) time
– The number/combination of tags varies according
to the data available at the examination time
– The number/combination of tags varies according
to the examination modality
– The number/combination of tags varies according
to the equipment manufacturer
Evaluating a row-store data model for full-content DICOM management 6 / 28

7. DICOM content is:
Evaluating a row-store data model for full-content DICOM management 7 / 28
Metadata + image
Metadata
Metadata
Metadata Patient
Study
Series
Image Image
Series
Image
Study
Series
Image

8. Storage in File Systems
Evaluating a row-store data model for full-content DICOM management 8 / 28
(0010,0020) PatientID

9. Storage in File Systems
Evaluating a row-store data model for full-content DICOM management 9 / 28
(0020,000D) StudyInstanceUID

10. Storage in File Systems
Evaluating a row-store data model for full-content DICOM management 10 / 28
(0020,000E) SeriesInstanceUID

11. Storage in File Systems
Evaluating a row-store data model for full-content DICOM management 11 / 28
(0008,0018) SOPInstanceUID

12. + Easy to organize and deploy
+ Easy to distribute over the network
+ Mounting points using NFS, for example
- Restrictive for query/retrieval
- Only the hierarchical level IDs are known without
file content evaluation
- Lack of indexes built over tag values
Storage in File Systems
Evaluating a row-store data model for full-content DICOM management 12 / 28

13. Storage in RDBMSs
Evaluating a row-store data model for full-content DICOM management 13 / 28

14. Storage in RDBMSs
Evaluating a row-store data model for full-content DICOM management 14 / 28
+ Easy to map the DICOM hierarchy into a set
of relations/relationships
+ Use of SQL for maintenance
+ Performance boost through indexes
- Need of a predefined DB schema
- Usually, composed by a restricted number of tags
- Scalability is “unnatural”
- Works well for single-node instances
- Multi-node instances are possible, but demand
considerable administrative efforts

15. What about NoSQL?
Evaluating a row-store data model for full-content DICOM management 15 / 28

16. What about NoSQL?
Evaluating a row-store data model for full-content DICOM management 16 / 28
• Native scalability
• Configurable partitioning/replication
• Loose constraints when compared to the
relational model (e.g., schemas, foreign
keys, referential integrity)
• Projected to work in the “huge” level
– Huge volumes of data, huge number of users, …

17. Two questions to be answered
1. Is it possible to manage full-content DICOM
images at tag level, using a data model built
over a row-store, NoSQL database?
2. Despite its close relationship with big
volumes of data, does a row-store, NoSQL
database perform well in scenarios of small
datasets when compared to known
approaches, i.e., relational databases?
Evaluating a row-store data model for full-content DICOM management 17 / 28

18. NoSQL: partitioned row-stores
Evaluating a row-store data model for full-content DICOM management 18 / 28

19. Experimental data model
Evaluating a row-store data model for full-content DICOM management 19 / 28

20. Experimental setup and datasets
Evaluating a row-store data model for full-content DICOM management 20 / 28
Setup Processor Memory Storage
Operating
System
Stand-alone
Intel® CoreTM i7
- 2,7GHz
4GB DDR3 500GB SATA
OS X
10.8.3
Cluster
Node 1
Intel® Xeon®
X3440 - 2,53GHz
(x8) (shared
through
virtualization)
4GB DDR3
(per node)
859GB SATA
(per node)
Ubuntu
10.04.1
Node 2
Node 3
Node 4
Node 5
Examination modality
Tags per
file
(average)
Average size per file (bytes) Size on
disk
(MB)Metadata tags Image tags
Computed Radiography (CR) 80 802 2278594 14
X-Ray Angiography (XA) 120 5662 1442097 83
Secondary Capture (SC) 64 932 168897 151
Positron Emission Tomography (PET) 161 3085 16211 111
Magnetic Resonance (MR) 159 2704 72006 363
Computed Tomography (CT) 132 3888 109054 3272

21. Results – Storage
Evaluating a row-store data model for full-content DICOM management 21 / 28

22. • Results include the time needed to parse/extract
individual tags from image files
• Storage time is derived from a combination of two
characteristics:
– The dataset size
– The file content complexity
• SA = 89.8% faster than CL (in cumulative query time)
– Communication and replication issues
• In CL, parallel writes are a solution to performance
improvement
– Speedup of 77.9% when compared to single writers
Results – Storage
Evaluating a row-store data model for full-content DICOM management 22 / 28

23. Results – Query
Evaluating a row-store data model for full-content DICOM management 23 / 28

24. • Queries are executed by hierarchical level,
selecting values from tags related to each
level
• The row-store performs better when:
– There is high selectivity (the image level)
– The number of selected tags is minimal (the series
level)
• In general, RDBMS outperforms row-store
– 8.9% faster than SA
– 19.2% faster than CL
Results – Query
Evaluating a row-store data model for full-content DICOM management 24 / 28

25. Results – Retrieval
Evaluating a row-store data model for full-content DICOM management 25 / 28

26. • Retrieval operations are executed by
hierarchical level, returning sets of full-content
(metadata + pixel data) images
• Retrieval time decreases as selectivity increases
– CL setup for the row-store performs better than SA setup
– Partition by patientid contributes in routing retrieval
operations to single nodes
• In general, RDBMS outperforms row-store
– 81.7% faster than SA
– 83.2% faster than CL
Results – Retrieval
Evaluating a row-store data model for full-content DICOM management 26 / 28

27. Conclusions
1. Is it possible to manage full-content DICOM images at tag
level, using a data model built over a row-store, NoSQL
database?
– Yes. Row-stores are flexible enough to manage combinations of
DICOM tags in a consistent way.
2. Despite its close relationship with big volumes of data,
does a row-store, NoSQL database perform well in
scenarios of small datasets when compared to known
approaches, i.e., relational databases?
– According to the experiments performed in this work, no. The
row-store setups were outperformed by the RDBMS in the
overall evaluation.
– Other data models, however, can be better suited for the task.
Evaluating a row-store data model for full-content DICOM management 27 / 28

28. Evaluating a row-store data model for
full-content DICOM management