Многие из нас бывали в ситуации, когда в поликлинике делают рентген или флюорографию, а затем нужно самостоятельно нести врачу эти большие и неудобные снимки. А сколько килограммов нервов мы тратим, стоя в очередях в регистратуру, чтобы получить свои медицинские карты, которые зачастую не оказываются на месте или вообще теряются. Сколько человеко—дней мы тратим, пересказывая врачам истории своих болезней и недугов, забывая важные детали и преувеличивая малозначимые?

Можно привести такой случай из жизни одного из наших сотрудников: в юности он переболел пневмонией, в результате чего все последующие годы на флюорограммах регистрировалось затемнение в лёгком. Участковый врач об этом прекрасно знал. Но однажды герою этой истории пришлось делать флюорографию в другой поликлинике. И там, увидев пятно, его едва не госпитализировали насильно, заподозрив туберкулёз. Никакие рассказы о пневмонии не помогли, пришлось ехать в свою поликлинику, просить свои старые снимки и везти их в качестве доказательства. Но даже после этого на него смотрели косо и пытались заставить еженедельно делать контрольные снимки. А ведь всех этих неудобств и нервотрёпок можно было бы избежать, будь у нас в стране хорошо развита система хранилищ медицинских данных регионального и городского уровней. Врач мог бы зайти туда и открыть всю историю болезней пациента начиная с рождения. Было бы снято множество вопросов и сэкономлена уйма времени.

Отсутствие систем хранения, агрегирующих медицинскую информацию, характерно не только для городов и регионов. Многие сети поликлиник, а также крупные больницы, клиники и медицинские центры, имеющие по несколько корпусов, тоже до сих пор не имеют собственных единых систем хранения. И врач, принимая пациента в одном корпусе, вынужден запрашивать физические записи от врачей из других корпусов, если того требует процедура диагностики и лечения.

Есть и ещё одна проблема, проистекающая из отсутствия единых систем хранения. Она не столь очевидна. Всевозможные снимки и результаты исследований «оседают» в локальных хранилищах аппаратов и приборов, на которых они были получены. И в связи с ограниченностью доступной памяти самые старые записи периодически удаляются. Поэтому если вас исследовали несколько лет назад и вам понадобилось получить эти результаты, то есть риск, что они уже удалены.

Вендоронезависимые архивы медицинских изображений


Современная медицина оперирует всевозможными данными, полученными в ходе исследований пациентов методом лучевой диагностики: рентгенографическими снимками, результатами УЗИ, МРТ и компьютерной томографии, эхокардиограммами и многим другим. Чаще всего результаты исследования представлены в графическом виде. И традиционным способом обмена этими данными является распечатывание на принтере с последующей отправкой. Со всем вытекающими из этого неудобствами.

Большинство (если не все) из этих приборов поддерживают промышленный медицинский стандарт DICOM (Digital Imaging and Communications in Medicine). Это отраслевой стандарт создания, хранения, передачи и визуализации медицинских изображений и документов обследованных пациентов. Для передачи информации от медицинского оборудования в PACS—систему (Picture Archiving and Communication System) и для связи между PACS—системами используется TCP/IP.

Большинство производителей медицинского оборудования поставляют вместе со своей продукцией также PACS и рабочие станции для обработки исследований врачами—диагностами. Но возможности подобных решений ограниченны, поскольку производители оборудования, как правило, не ставят перед собой задачу построения глобальных систем хранения исследований. И кроме того, желают защитить свои интересы по поставке рабочих станций (довольно дорогостоящих). Например, производители медицинского оборудования «привязывают» потребителей к своим рабочим станциям, используя при сохранении обработанного исследования т.н. «проприетарные» теги DICOM, которые не позволяют нормально работать с этими исследованиями с рабочих станций других производителей. Проблема становится ещё более острой, если клиника (или сеть клиник, или даже регион) решают поменять поставщика PACS/рабочих станций. Проекты по миграции могут занимать месяцы, и в некоторых случаях завершаются провалом.

Как вы понимаете, такая проблема не могла остаться без решения. Сегодня для построения централизованных архивов медицинских изображений используются т.н. вендоронезависимые архивы (VNA – Vendor Neutral Archive) от компаний, которые не являются поставщиками медицинского оборудования. Эти архивы также работают по протоколу DICOM, а в DICOM—сети, естественно, присутствуют как PACS. Вендоронезависимость обеспечивается конвертацией проприетарных тегов в публичные в момент записи исследования в архив. Естественно, каждый поставщик VNA заявляет о полной вендоронезависимости. Но поскольку производители медицинского оборудования не публикуют, по понятным причинам, информацию об использовании проприетарных тегов, реальная степень вендоронезависимости зависит только от опыта конкретного поставщика VNA. Чем больше проектов реализовано, чем они масштабнее, чем больше различных PACS от различных поставщиков интегрировалось в архив, тем больше у поставщика опыта и информации по использованию проприетарных тегов. И тем быстрее его реакция в случае изменения каким—либо производителем медицинского оборудования методов использования этих самых проприетарных тегов.

Кроме того, при построении глобальных архивов уровня региона или даже страны также важен опыт поставщика VNA по управлению очень большими массивами информации, в том числе в распределенной по нескольким ЦОД инфраструктуре. Ведь размер одного DICOM—исследования, например, МРТ, может достигать 4,5 Гб. Риски очевидны — поставщик VNA может заявлять о готовности его решения работать с любыми объемами информации, а по факту может оказаться, что уже с первых нескольких терабайт время отклика у архива вырастает. Бывает даже, что происходят потери информации.

Для решения проблемы зависимости от конечных (дорогостоящих) рабочих станций поставщики VNA предлагают в составе решений средства для просмотра медицинских исследований. У некоторых поставщиков это просто облегченный просмотрщик, у некоторых — полноценное (зачастую, web—based) рабочее место врача—диагноста.

В нашей стране такие архивы уровня региона начали строиться в период массового внедрения МИС (Медицинская Информационная Система) в рамках программы модернизации здравоохранения. Некоторые регионы успешно построили такие архивы и эксплуатируют, хотя, как правило, далеко не все клиники региона подключены к архиву, и не все исследования даже подключённых клиник попадают в центральный архив. Сейчас Министерство здравоохранения РФ вдохнуло новую жизнь в эти проекты, включив создание региональных архивов в дорожную карту до 2018 года.

Решение от EMC


Типовая архитектура вендоронезависимого архива медицинских изображений, предлагаемого EMC, выглядит следующим образом:



  • ЛПУ — лечебно—профилактическое учреждение: больница, поликлиника, медицинский центр и т.д.
  • Модальность — аппарат для медицинских исследований: рентгенографическая установка, компьютерный томограф, аппарат УЗИ и т.д.
  • Просмотрщик исследований — это основной инструмент врачей для работы с данными. Он представляет собой веб—приложение, написанное на HTML5, что позволяет ему работать даже на слабых «тонких клиентах». При этом просмотрщик обладает всеми возможностями рабочей станции. В Европе он лицензирован как средство диагностики и может полноценно использоваться при постановке диагноза.



Медицинские аппараты — модальности — генерируют данные исследований, которые попадают на локальный кэширующий сервер (DICOM—шлюз). Это необходимо для обеспечения бесперебойности работы на случай отсутствия связи с центральным хранилищем. Если связь стабильная, то данные автоматически отправляются со шлюза в хранилище, если связь нестабильна, то данные отправляются по расписанию или по мере появления связи. На кэширующим сервере данные хранятся в течение некоторого времени, которое зависит от ёмкости СХД сервера. Причём все запросы с «тонких клиентов» обрабатываются сначала кэширующим сервером, а если нужной информации на нём нет, то она запрашивается в ЦОД.

Обеспечение вендоронезависимости и подтверждение возможности построения глобальных архивов основано на огромном опыть EMC. Специфика наших продуктов — управление огромными объёмами информации как на аппаратном, так и на программном уровне. В нашем портфеле большое количество внедрённых решений, в том числе проекты уровня страны (например, Финляндия).

Комментарии (18)


  1. amarao
    07.09.2015 12:39

    Я просто скидываю снимки на почту врачу (в принципе, можно прямо сидя в кабинете, если LTE нормальный). И, если делают ещё какие-то снимки, обязательно прошу прислать в электронном виде. В редких случаях нецифровой съёмки — сканирую сам.

    Заметим, эта схема отлично живёт без «специальных решений EMC».


    1. mecheslav
      07.09.2015 13:23

      А если есть электронная медкарта, к которой доступ из нескольких лечебных учреждений? Причем одно (а лучше пара) из них амбулаторные, а значит снимок может посмотреть гораздо больше одного врача, когда к нему на прием придете? Тут как-то грустно без централизованного хранилища.


    1. lexx2real
      07.09.2015 13:51
      +1

      А что по детализации? Те же МРТ например гораздо более детализированы, чем может изначально показаться.
      На одном листе формата А3 там могут быть десятки детализированных снимков.
      На сканер да еще и с шумом?

      Ну а суть ведь еще и в просто хранении. Через сколько снимок понадобится, понадобится ли и где он понадобится — не знаешь. Хранить конечно лично тоже не сложно, всегда с собой таскать. Но иметь доступ всегда и без этого — вроде как лучше.

      Что «живёт» это хорошо, конечно. Думается мне про компьютеры так же говорили, «считать можно и на счётах, без специальных решений». Это, в целом, хороший ответ, чтобы ничего не придумывать и не трогать вообще. Живет же.
      По-моему, это именно та работа, которая должна делаться в век информации. Автоматизировать, систематизировать, упрощать.


      1. amarao
        07.09.2015 15:06

        На MRI выдают диск — там примерно 174Мб.

        Расшаривается в два клика.


      1. Meklon
        08.09.2015 12:37

        3D-исследования и надо хранить в виде 3D. А3 формат это редкое гуано. Ведь это просто набор скриншотов из полноценной картины. Причём именно тех скринов, которые показались значимыми лаборанта. Хотя не факт, что под другим углом картина не была бы лучше.


    1. tsimokha
      07.09.2015 14:25

      Создание таких архивов это следующий шаг после создания централизованной региональной МИС с единой электронной картой, доступной из разных ЛПУ (о чем по факту регионы отчитались). Причем, естественно, создание регионального архива медицинских изображений предполагает интеграцию с МИС с возможностью просмотра исследований прямо из карты пациента. И, к слову, так-же отправка пациента на исследование из карточки МИС (DICOM modality worklist)

      PS: Исследование МРТ может достигать 4-5Gb — можно конечно отправить и по LTE…


      1. amarao
        07.09.2015 15:07

        «отправить» не требует хранить файлы на телефоне. Достаточно отправить файл вложением из того же googledrive. Алсо, 4-5Гб MRI — первый раз такое слышу. Обычно сотни мегабайт.


        1. mecheslav
          07.09.2015 16:14

          Суть-то не в том, что бы пациенту отдать файл. Суть в том, что бы хранить его в рамках больницы/поликлиники/сети леч. учреждений. То что там у пациента на руках это дело десятое и мало кого интересующее. Что бы через год после какого-нибудь перелома ноги легко можно было поднять архив снимков и посмотреть. Или еще чего такое сотворить.


          1. amarao
            07.09.2015 18:12

            Хранение этого в ЛПУ — малоперспективно. ЛПУ меняются (реорганизация, переезд человека, смена клиники из-за изменения страховщика или финансового состояни). Правильно эти штуки делать patient-centric с стандартным интерфейсом импорта/экспорта данных. Чтобы данные хранил человек, а не медучреждения.

            Сейчас мне расскажут про ЛПУ, меняющиеся документами. Ага, ага, паракало сига-сига, звонит кипрский стоматолог в русскую клинику и на ломанном английском спрашивает, как ему получить рентген челюсти такого-то такого-то.


            1. VenomBlood
              07.09.2015 22:56

              Скорее лучше хранить это в специальных сервисах которые будут на этом специализироваться и иметь соответствующие стандартам средства защиты, типа какого нибудь облака, место в котором оплачивает страховая клиента и к которому с разрешения клиента (т.е. пациента) могут получить доступ мед. учреждения. Обеспечивать соответствие стандартам безопасности десятка облачных провайдеров гораздо проще чем десятки тысяч различных клиник.
              Хранить данные у пациента — это для 99% не удобно, никто не захочет разбираться да и данные в гораздо меньшей сохранности, вероятность того что среднестатистический пациент случайно их удалит/потеряет каким-нибудь образом — достаточно значительна.


              1. amarao
                07.09.2015 23:04

                Да пофигу. Стандарты реализуются поверх любого стандартного объектного хранилища, временные токены для доступа — тоже.

                Ключевое:
                1) Выкидываем EMC. Имеем 90% снижение цены
                2) Выкидываем «специализированное решение для мед. учреждений». Имеем ещё 50%.
                3) Делаем на базе стандартного объектного хранилища (VS спец-сервера) — имеем ещё 70% дисконта.
                Итого — 1.5% от того, что тут emc пытается продавать.

                Фанаты делают opensource с self-hosted, и проблему можно считать закрытой. Главное — договориться о стандартных открытых протоколах взаимодействия.


                1. VenomBlood
                  07.09.2015 23:14

                  Не знаю как в россии — а например в США это смысла не имеет (да и с учетом всяких HIPAA возможно для клиник будет меньше мороки с большим вендором). При цене за визит к врачу в 200 долларов — цена на внедрение EMC хоть в дата-центре с позолоченными ковровыми дорожками вдимо будет крайне незначительной. А т.к. платят за все страховые компани (а в конце — работодатель/пациент в виде страховых взносов) — то все это выльется в увеличение страховки на условный 1%, вряд ли ради этого кто то будет заморачиваться, найдут крупного вендора и он все сделает.
                  Ну и к слову «выкидываем EMC» означает что вместо EMC будет какой-нибудь MCE или CEM или любая друга компания, вряд ли цены они опустят ниже рыночных, так что 90% экономии — это какое-то дикое преувеличение. «Стандартное хранилище» еще надо будет допиливать чтобы соответствовала безопасность, доступность и прочее, ну и специализированное решение — это скорее экономия для клиники за счет подгонки софта под ее процессы, тут наоборот «скупой платит дважды». А фанатов с opensource среди всех пациентов будет пол процента, а большая часть клиник из-за возможных проблем доступности/безопасности с ними вообще не будет взаимодействовать.


                  1. amarao
                    07.09.2015 23:19

                    Безопасность у современных хранилищ вполне себе приличная. А вот сертификация — это да, конечно. Изобретать законы, а потом по ним втюхивать лоху сертификаты на вес алмазов — это святое дело.

                    Опыт говорит, что если индустрия идёт по пути «поставщика», то мы наблюдаем застой, уныние и ISDN в куче с MS Office. А когда идёт по пути открытых стандартов — то чоткий дерзкий ethernet/IP, который ISDN оставил далеко за бортом.

                    Открытые стандарты — и дальше EMC может продолжать впаривать корпоративным лохам позолоченные ковры в дата-центр из свёрнутых в нано-трубочки сертификатов, а те, кому работать, спокойно возьмут решение, которое просто работает (и не устраивает истерики, если что-то не так с ключиком/лицензией).


                    1. VenomBlood
                      07.09.2015 23:24

                      Опыт говорит,
                      Не знаю что говорит опыт, но я вижу как много примеров «открытых стандартов» которые выстрелили так и много примеров чего-то закрытого что заняло нишу и никто потеснить не может. Ровно как и наоборот — есть и «открытое» провалившееся и закрытое провалившееся.
                      а те, кому работать, спокойно возьмут решение, которое просто работает
                      Ну это просто инфантилизм. Если решение будет бесплатно — кто будет его поддерживать? А если поддержка будет платной то цена будет скорее сопоставима (поинетесуйтесь сколько стоит поддержка свободного opensource'ного linux'а от RedHat). А учитывая то что там будут медицинские данные — поддержка будет просто необходима. EMC будет этим «корпоративным лохам» приезжать и чинить/настраивать когда что-то пойдет не так, и EMC будет гарантировать соответствие всем стандартам.


                      1. amarao
                        08.09.2015 14:45

                        Вы не знаете примеров открытых стандартов? Познакомьтесь: ip и http.


                        1. VenomBlood
                          08.09.2015 20:56

                          Вы комментарии пробовали читать прежде чем ответить?

                          но я вижу как много примеров «открытых стандартов» которые выстрелили так и много примеров чего-то закрытого что заняло нишу и никто потеснить не может. Ровно как и наоборот — есть и «открытое» провалившееся и закрытое провалившееся.
                          Вы не знаете примеров открытых стандартов? Познакомьтесь: ip и http.


                      1. Meklon
                        08.09.2015 15:06

                        Открытый стандарт подразумевает отсутствие vendor lock-in. Дорого брать поддержку от Красношляпников? Купите поддержку CentOS от местной небольшой фирмы. Или своего админа надрессируйте. Появляется веер возможностей вместо монополии.


  1. tsimokha
    08.09.2015 15:29

    Зачем переводить тему в обсуждение стандартов и предпочтений? тем более что DICOM также открытый стандарт (DICOM Homepage) и для него есть довольно много open-source решений.
    Если конечный заказчик (особенно крупный) хочет получить с высокой вероятностью работающее решение, удовлетворяющее его ожиданиям (в том числе по масштабу и политикам хранения), с пониманием перспектив по развитию и поддержке, то он вероятнее обратится к известному крупному поставщику, чем к команде разработчиков для допила open-source решений. Но, естественно, выбор всегда за заказчиком. И вы верно заметили — бюджет тоже имеет немаловажное значение.

    Отдельно про ЛПУ —

    Хранение этого в ЛПУ — малоперспективно
    если говорить о РФ, то речь идет в первую очередь о региональных решениях. В этом случае снимки хранятся в ЦОД МинЗдрава региона, а ЛПУ к нему подключаются. Как развитие в далекой перспективе — интеграция этих построенных (до 18 года) архивов в архив уровня федерального округа, а потом и страны. Тем более что даже архив регионального уровня решит 95% проблем — не так много людей получают медицинское обслуживание то в одном регионе, то в другом. Отдельные случаи (например снимки, сделанные в клинике в другом регионе или даже стране) решаются порталом пользователя, подключенного также к этому архиву, на котором он имеет доступ к своим исследованиям и может их туда дозагружать или выгружать.