Я занимаюсь разработкой приложения для просмотра в Windows DICOM с использованием Visual C ++ / MFC и dcmtk и хотел бы реализовать локальное хранилище данных для изображений, которые я получил с сервера PACS. В первую очередь я хочу сохранить иерархическую структуру на диске, как вы видите на компакт-дисках DICOM, и использовать DICOMDIR как своего рода индекс для данных. Это кажется немного неуклюжим, поскольку DICOMDIR не кажутся очень гибкими, особенно с помощью API dcmtk (он допускает только 8-символьные имена файлов).
Я видел некоторые программы просмотра DICOM, которые, кажется, используют SQLite или аналогичную утилиту локальной базы данных для организации локальных файлов на диске. Это кажется лучшим подходом, но я не уверен, есть ли лучшая практика для того, что я пытаюсь сделать.
Есть ли лучшая практика для этой, казалось бы, распространенной проблемы?
В Common Toolkit (CTK) есть база данных на C ++ / SQLite и поддерживающие классы, которые разработаны для этой цели. Они используются как в 3D-слайсере, так и в MITK Workbench:
http://www.commontk.org/index.php/Documentation/DICOM_Overview
Это зависит от 😉
Если вы планируете иметь тысячи изображений (что может легко случиться, если вы попытаетесь работать с данными КТ или МР) и собираетесь работать с тегами, то SQLite и сохранение соответствующих тегов в иерархии таблиц, с моей точки зрения, являются хорошим отправная точка. В противном случае всегда анализ всех файлов DICOM может быть довольно медленным.
В самом начале вы можете хранить файлы с идентификаторами экземпляра sop как имя файла в плоской папке. Они уникальны!
НО, прежде чем идти в этом направлении, вам должно быть ясно, что вы хотите сделать. Так что имейте чистые UseCases и сделайте дизайн, который позволит вам отложить принятие решения, если вы хотите получить доступ к данным напрямую через файловую систему или через базу данных настолько поздно, насколько это необходимо.
Обычно вы хотите захватить метаданные (переместить полезные) теги DICOM в базу данных. Затем вы можете хранить файлы любым способом. Плоский подход, как правило, не будет масштабироваться. Нередко встречается структура папок с \ UID экземпляра исследования \ UID экземпляра серии, потенциально с компонентом даты для больших систем \ UID года \ месяца \ дня \ исследования.