В данный момент занимаюсь этой задачей. Работаю над реализацией следующего алгоритма: в каждом файле снимка имеется вся необходимая информация о пациенте и исследовании. Открываем файл, читаем дату создания, создаём папку даты (если её нет), создаём папку пациента (если её нет) пишем в неё все снимки пациента. Пользователь работает следующим образом: копирует массив DICOM файлов, а затем формирует из него папки пациентов. После этого можно хранить эти структуры папок где угодно и обращаться к ним с рабочих станций.
По сути идея верна и достаточно проста. И, собственно, что-то подобное я уже реализовывал - програмку на AutoIt написал, которая из какой-либо папки "сортирует" любые сваленные в кучу файлы DICOM по датам и принадлежности к пациентам (создавая при этом упорядоченную структуру папок по годам/месяцам/дням/ФИО_пациента). Если есть мало-мальские навыки программирования и представления о DICOM-тэгах, то идея достаточно простореализуема. От себя добавлю - полученные папки пациентов (спустя какое-то время) лучше сжимать архиватором, т.к. обычно кол-во файлов даже у одного пациента большое, а оперировать миллионами файлов ОС нелегко. Плюс архивация ужимает данные КТ примерно в 3 раза (очень заманчиво, не правда ли?) - опять же облегчая их хранение (разжать - дело буквально несколько десятков секунд). А для удобства поиска в имени архива забивается помимо ФИО еще и необходимые даннеы из тэгов как-то - дата ииследования, ID, дата рождения, область исследования и прочее, что захотите.
Чего только не придумают, лишь бы не использовать сеть и не ставить DICOM-сервер. а сортировщик файлов можно хоть на BAT-файлах сделать с использованием какого-нибудь gdcmdump
Сеть-то как раз и нужна - без нее никак. Да и сервер-"времянка" нужен. А вот с более длительным хранением все сложнее. А вот свою идею с архивацией все-таки буду отстаивать. Минус у нее только один - нужно написать программу удобного поиска в этих архивах (что, собственно, я и сразу сделал).
А вот экономия места на каждом исследовании примерно в 3 раза и меньший напряг файловой системы - однозначно плюс. Это я еще посмотрел бы как в архиве почти на 90 тыщ КТ-исследований какой-нить сервер работал :-). И сколько б место это б "жрало" Дак еще и какого размера RAID должен быть...
Вобщем - мое ИМХО: мое видение не только более проще/надежно/масштабируемо, но и вполне функционально и ГОООРАЗДО дешевле ЛЮБОГО офиц.продаваемого продукта за большое кол-во нулей... Расходы только на более-менее нормальном ПК и все более увеличивающемся кол-ве террабайтных винтов (один для хранения/второй для бэкап-копии)
Сообщение отредактировал Bomberbug - Пятница, 25.Ноя.2016, 08:03
На данный момент программка, которая извлекает снимки пациентов из DICOMDIR файла на DVD носителях в директорию [Диск]:/[дата исследования]/[Ф.И.О. пациента]/[ID исследования] уже работает в мед. уч., где я обслуживаю. Людям нравится.
Еще относительно сервера "за деньги" добавлю. Некоторые, например ИНТЕГРИС, хранят файлы изображения отдельно от описательной части (т.е. не DICOM-контейнер), которая уже хранится в файле базы. Так вот файл базы этой растет просто непомерно быстро, а в случае краха все данные преспокойно можно "слить в помойку", потому как это просто большой набор картинок, которые "никому не принадлежат"... Подход, конечно, оправдан относительно "заботы о конфиденциальности", но на практике это просто геморр... Не дай боже чего с файлами базы случится и тю-тю все данные...
Сообщение отредактировал Bomberbug - Пятница, 25.Ноя.2016, 08:35
Дата: Пятница, 25.Ноя.2016, 08:34 | Сообщение # 10
У вас сообщений: 711
engineer
OFFлайн
Российская Федерация
Россия
Цитатаzonger58 ()
Людям нравится.
Людям вообще нравится, когда есть что-то удобное и бесплатно :-)
Цитатаzonger58 ()
которая извлекает снимки пациентов из DICOMDIR файла на DVD носителях
Вот именно чтоб не морочиться с носителями я и затеял архив... Потому как доступ раб.станции к данным любого пациента за любой период времени за 1-2 минуты - это гораздо и проще и быстрее, чем "рыться" в сотнях-тысячах носителей... Примерно 8Тб данных - это вам на болванки не нарезать... (я б не стал )
Сообщение отредактировал Bomberbug - Пятница, 25.Ноя.2016, 08:43
Дата: Пятница, 25.Ноя.2016, 12:19 | Сообщение # 11
У вас сообщений: 1070
программист
OFFлайн
Российская Федерация
Москва
ЦитатаBomberbug ()
Это я еще посмотрел бы как в архиве почти на 90 тыщ КТ-исследований какой-нить сервер работал :-). И сколько б место это б "жрало"
вы как в прошлом веке живете 8 ТБ, это сейчас два диска, пусть в рейде с резервированием 4, купите хранилку NAS вот моя база на 2014 год http://www.medteh.info/forum/58-9272-138592-16-1395755448 13 млн снимков, а вы тут про костыли какие-то рассказываете
ЦитатаBomberbug ()
ГОООРАЗДО дешевле ЛЮБОГО офиц.продаваемого продукта за большое кол-во нулей
conquest бесплатный от слова совсем описательная часть хранится в отдельной общей системе всего медучреждения
Сообщение отредактировал naves - Пятница, 25.Ноя.2016, 12:29
Дата: Вторник, 29.Ноя.2016, 05:26 | Сообщение # 12
У вас сообщений: 711
engineer
OFFлайн
Российская Федерация
Россия
Цитатаnaves ()
описательная часть хранится в отдельной общей системе всего медучреждения
База данных результатов да, в отдельной хранится (там уж не моя забота).
Под описательной частью я имел ввиду - все данные по исследованию (дата, время, ФИО пациента и т.п.) - т.е. в случае проблем с базой (применительно к указанному ИНТЕГРИСУ) - данные изображения могут стать бесполезными ввиду отсутствия возможности определения их принадлежности к человеку...
По поводу NAS и прочего подобного: понятно, что на фоне необходимости сохранения данных, надежности хранения, престижа "имения" архива и т.п. финансовая составляющая не на первом плане, но все ж есть зависимость и от учреждения (мы бюджетники) и от удаленности "от центра". Для какой-нибудь больнички (а тем более частного учреждения) "с деньгами" - вопрос о закупке компьютерных комплектующих остро может и не стоит, а мне вот даже купить лишний винт на пару террабайт уже не просто так - тут и объясни и убеди... Посему, из примера: 8 Тб х 4 штуки = 100 тысяч (не самые еще хорошие винты) - только на винты!. Да и ПК нормальный нужен...
Кто не сталкивался с "экономией на всем" - тот не поймет :-)
Плюс. Указанный мой объем хранения в 8Тб примерен - и написан для сжатых архивов. Реальный размер данных - примерное в 3 раза больше - т.е. около 24 Тб... Плюс. Указанный тип моего хранения позволяет вообще просто поиском средствами ОС найти нужного человека без необходимости установки какой-либо доп.программы, восиожно SQL-сервера... Программа работы с базой может внезапно "сдохнуть"...
P.S. Собственно, полемику не собираюсь развивать. Просто высказался по поводу своей реализации хранения. Топорно, но достаточно надежно и дешево (условно). Вот. Других вариантов не отвергаю.
Сообщение отредактировал Bomberbug - Вторник, 29.Ноя.2016, 05:41
Дата: Вторник, 29.Ноя.2016, 11:46 | Сообщение # 14
У вас сообщений: 1070
программист
OFFлайн
Российская Федерация
Москва
обычно, когда условия "экономией на всем" то, как то и вопрос хранения вообще не стоит, да и хранить тоже нечего в силу отсутствия цифровых аппаратов, ну это уже другая крайность.
conquest умеет: 1) автоматически сжимать в lossless jpeg2000, который по степени сжатия будет превышать обычные архиваторы, тк алгоритм специально предназначен для изображений. 2) размазывать хранение по нескольким носителям, те можно либо использовать несколько внешних дисков, либо подключить несколько сетевых дисков с других компьютеров.
Не было б "цифры" - и темы б этой не было :-) Вопрос хранения мог бы и отпасть - если сразу бы предложили руководству "рекомендуемый продажниками" какой-нибудь PACS-сервер за парочку миллионов. А т.к. ПК уже был, на несколько винтов "разорились", то за счет моего альтруизма достаточно оперативно поставленная задача была решена и архив организован.
Цитатаnaves ()
автоматически сжимать в lossless jpeg2000, который по степени сжатия будет превышать обычные архиваторы, тк алгоритм специально предназначен для изображений.
Немного изучал этот вопрос (была необходимость работы со снимками Проскана на ЕПО - там неподдерживаемое lossless-сжатие). Так вот, не заморачиваясь относительно удобства/скорости обрабодтки - сжатие "по дефолту" того ж winrar-а - практически один в один результат дает по конечному размеру.
Цитатаnaves ()
размазывать хранение по нескольким носителям
Примерно так и есть. Только носители у меня внутренние (когда уж некуда подключать будет - тогда другой сетевой ПК буду, наверное, использовать)
Сообщение отредактировал Bomberbug - Среда, 30.Ноя.2016, 04:25
Российская Федерация
)
достаточно оперативно поставленная задача была решена и архив организован.