Немного обо мне

В 1987-м году я окончил с красным дипломом приборостроительный факультет челябинского политехнического института по специальности "Автоматика и телемеханика", хотя планировал стать физиком-теоретиком и школу заканчивал в специализированной школе-интернате №18 при МГУ. По распределению попал в специализированное конструкторское бюро и до 1991-го года разрабатывал электронные блоки для бронетанковой техники. До сих пор считаю что полученная при этом инженерная школа является чем-то недостижимым в современных реалиях. В частности, мы с коллегами создали комбинированный аналого-цифровой программируемый комплекс, который в реальном времени проводил расчеты по математической модели объекта, описываемой системой дифференциальных уравнений 4-го порядка с 14-ью нелинейными элементами и принимал решения более 10 тысяч раз в секунду. На современных вычислителях это наверное и можно было бы сделать, но в то время мы решали задачу имея в распоряжении только набор интегральных микросхем, самой крутой из которых была ПЗУ на 2 килобайта и всё наше творчество должно было уместиться в 9 литров объёма и работать в диапазоне температур от -40 до +85.

После того как в 1991-м году страна развалилась я выбрал стезю программирования и с тех пор так или иначе связан с разработкой ПО и построением крупных информационных систем. Начинал с создания комплексного ПО и "умной кассы" для торгового центра, потом была информационная система учёта аренды муниципального имущества. Потом я вернулся в конструкторское бюро на считавшийся безнадёжным проект по созданию комплекса диагностических стендов для автоматизированного поиска неисправностей в электронных блоках в интересах иностранного заказчика. После окончания разработки я возглавлял группу разработчиков, которая сдавала эти стенды заказчику, и мы с этой задачей справились.

После этого бесценного опыта я был техническим директором фирмы по коммерческой разработке программного обеспечения и здесь мне пришлось впервые окунуться в предметную область информационных систем для медицины.

Начало осмысления проблем

Среди нескольких серьёзных разрабатывавшихся проектов (был и "Умный город" с системами распознавания номеров автомобилей, и логистика транспортных средств металлургического комбината и ...) был особенный проект по созданию единой информационно-аналитической системы здравоохранения Челябинской области.

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

Первым объектом глубокого исследования был конечно самый распространённый на то время комплекс стандартов HL7. Изучая его и кучу сопутствующих ему стандартов мы стали впадать в отчаяние - количество терминов и связей, необходимых хотя бы для минимальной функциональности одного лечебного учреждения, превышало наши возможности их осмысления, а тем более реализации, на порядки. Система здравоохранения (в том виде как она нужна именно для повышения показателей здоровья популяции) охватывает огромное количество разнообразных видов деятельности, каждый из которых имеет собственные обширные предметные области. А стандарт HL7, по крайней мере в том виде, в каком он был на момент нашего анализа (сейчас вроде бы сильно изменился, я не уточнял), был конгломератом стандартов на всех уровнях модели OSI. При попытке охватить все необходимые аспекты проект превращался в такое грандиозное нагромождение мало связанных между собой частей, что за его реализацию пришлось бы браться только нашим потомкам.

В ходе поиска возможных альтернатив и рабочих решений мы наткнулись на малоизвестный в то время комплекс стандартов OpenEHR. Заложенные в нём подходы позволяли хорошо упорядочить разработку, охватывали все необходимые направления перспективных разработок и давали возможность реализации отдельных частей по мере развития всеохватывающей информационной системы. Недостатками было то, что единственный на то время разработчик (он же составитель и распорядитель стандарта), находился в Австралии и запрашивал за любые свои услуги неподъёмную для российских субъектов оплату. Он предоставлял хорошие инструменты для проектирования информационных систем на основе его стандартов, но стоимость лицензий на эти инструменты делала разработку на их основе никогда не окупаемой.

Поиск решения

С технической точки зрения комплекс стандартов OpenEHR представляет собой набор правил для создания и эволюции сложных, взаимосвязанных типов данных, язык построения универсальных запросов к данным, являющимся экземплярами таких типов, и набор требований к информационным системам для обеспечения их взаимодействия между собой при условии, что они не обязаны заботится о совместимости друг с другом. Это было очень похоже на идеи, закладывавшиеся при разработке комплекса стандартов XML. Только стандарты консорциума W3C являются унифицированными и распространяются не только на медицину.

В итоге мы сформировали проект, в основе которого был заложен подход, ставящий в центр всей конструкции универсальный "движок XML", а специализация его под медицинский проект осуществлялась путем модификации java-реализации стандарта OpenEHR на использование во всех возможных местах этого "универсального движка". Компания Ocean Informatics вела свои разработки на .Net и данная реализация распространялась ими бесплатно в учебных целях. Сейчас модифицированную java-реализацию можно найти здесь.

Реализации

Как всегда, когда идёт переход от теории к практике,

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

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

Те же проблемы, но в другой сфере

После ухода из упомянутой компании я участвовал во многих проектах, попробовал силы в собственном бизнесе, своими руками перепробовал наверное большинство из современных технологических решений. На проекте с которого я ушёл совсем недавно (очень горячий проект в интересах пенсионного фонда РФ), мне пришлось снова задуматься о документоориентированных/иерархических хранилищах. Если бы не постоянный цейтнот и отсутствие поддержки со стороны руководства, то я точно попробовал бы вернуться на этом проекте к идее "движка XML". Главные болячки этого проекта в том, что практически вся информация, поступающая в систему, это xml-документы из внешних информационных систем, а запросы, поступающие к этой системе, заранее не определены и очень часто меняются. Созданная для этого структура хранения данных напоминает мне попытку компании Oracle реализовать обработку XML в своей базе данных. Oracle конечно подошла к этому вопросу более методично и внедрила все необходимые процедуры прямо в ядро базы данных (это была попытка представить иерархические связи в виде множества генерируемых таблиц, связываемых join-ами), но и она впоследствии отказалась от такого решения, так как попытка загрузить в базу данных xml-документ 10-мегабайтного объёма, приводила к "подвисанию" на несколько часов, а многие из xpath-запросов в принципе не поддавались оптимизации на реляционном представлении.

Так как же всё-таки решать подобные задачи

В 2006-м году корпорацией IBM был опубликован интересный документ. В котором подробно расписана методика исполнения любых XPath-выражений средствами реляционных баз данных, без деградации производительности на рекурсивных процедурах. Ими же была разработана эталонная реализация данного подхода, но дальнейшую судьбу продукта я отследить не смог.

Попутно хочу заметить что к стандартным реализациям XPath в java (xerces, xalan) имеется большое количество вопросов, которые нелегко разрешить.

В свободное от основной работы время, долгими вечерами, я реализовал собственное решение на основе описанного в упомянутом документе подхода. Парсинг XPath-выражений осуществляется замечательным продуктом ANTLR, необходимые для хранения xml-документов и xsd-схем сущности формируются средствами JPA, что даёт возможность использовать любую реляционную базу данных, попутным бонусом получилась неплохая реализация обработки XPath-запросов на файловых ресурсах.

Minimum Value Point решения можно посмотреть на этом ресурсе. Текущая реализация пока имеет много ограничений (не реализована работа с map и arrays, из всех функций полноценно реализована только функция abs), но большинство потребностей обработки иерархических документов обеспечиваются уже на данном уровне реализации. Поскольку это развёрнуто на моей домашней рабочей станции, на которой я ещё и выполняю основную работу, я ограничил поток обрабатываемых запросов (не более 10 запросов в минуту, объём одного документа не больше 1 мб), но внутри обработки никаких ограничений нет и ведутся замеры времени выполнения отдельных частей процесса.