ИТ в медицине — достаточно скользкая тема. Нужно отметить, что за последние 10 лет реально растет "проникновение" (как выражаются бюрократы) ИТ в медицину и в здравоохранение в целом. Спецы, работающие в линейных МО (мед. организациях), не дадут соврать. Мне даже представляется, что РФ не то, что отстает, но даже где-то и опережает глобальные тренды. Правда, на мой взгляд, есть разрыв между собственно технологиями и уровнем подготовки и мотивации пользователей, для которых они создаются. Ну и сами ИТ решения не всегда решения, а, скорее, головная боль
Любой МО нужен софт, и не просто бухгалтерский 1С, управление торговлей и CRM, нужен специализированный, МИСы (медицинские информационные системы), и не одна. Нужно вести учет приема пациентов, как-то получать, анализировать и хранить диагностические данные (изображения, графики, результаты анализов, и много чего еще), вести карты с записями о болезнях и т.д. и т.п.
Если МО участвует в программе обязательного мед. страхования (ОМС), она должна ежемесячно формировать и отправлять в территориальный (федеральный) фонд ОМС (ТФОМС) отчеты о количестве принятых в МО пациентов, характере и стоимости оказанной им мед. помощи. Без этого, никак нет возможности получить денежное возмещение от страховых компаний за оказанные услуги.
Собственно отчет — это 2-3 XML файла, упакованных в ZIP архив. Для подготовки пакетов с отчетами, разбора протоколов ошибок и оформления реестров к счетам для страховых компаний, я написал небольшую библиотеку и web приложение (сервер задач) для доступа к библиотеке по REST API.
Возможно, это будет интересно специалистам, или более широкой публике.
Мотивация
На просторах федерации сегодня можно найти пару десятков всяких-разных МИС общего назначения и для частных МО, и для продажи на гос. органы. И, наверное, десятки примеров какого-то регионального софта и для бюджетного здравоохранения, и для коммерческого. Не берусь оценить ни качество, ни стоимость, ни разумность выбора никакого наличного мед. софта, "ни в положительном, ни в отрицательном аспекте".
Бюрократический зуд заставляет ФОМС по нескольку раз в год что-то изменять в структуре файлов, изменять существующие, или вводить новые правила проверки данных. По этой причине нужно постоянно корректировать и справочную информацию и собственно правила формирования файлов отчета.
"Готовые решения" не всегда готовы в режиме реального времени (день, два) подстраиваться под очередные "новые" требования или правила. Что бы как-то облегчит себе жизнь, и был написан этот код.
СУБД и сервер задач
Данные пациентов являются персональными данными (ПД). Такие данные хранить в публичных облаках не желательно. В частном облаке — довольно дорого. Поэтому, все данные будут храниться в частной сети, доступ к которой из-за периметра может быть открыть по зашифрованному каналу, а может быть и нет.
ПД и все остальные данные для ОМС хранятся в СУБД Postgresql, развернутой в частной (локальной или виртуальной) сети МО. Доступ к БД по REST API выполняет выделенный web сервер postgRest.
Собственно для извлечения и обработки данных используется специальная библиотека. Операции с данными в БД можно выполнять либо с помощью CRUD сервера postgRest, либо непосредственно SQL запросами через коннектор. Сервер задач выполняет роль прикладного интерфейса к данной библиотеке.
Для сервера задач подготовлены Dockerfile и docker-compose файлы, так, что, сервер можно запустить в виде контейнера в любой ОС. Сервер доступен по REST API.
Доступ к данным и аутентификация
Сервер postgRest и сервер задач имеет встроенный механизм защиты доступа к таблицам и записям БД, который опирается на нативную поддержку безопасности на уровне записей СУБД Postresql (RLS) и JWT в HTTP заголовках.
Для аутентификации и предоставления графического интерфейса для пользователя (в виде SPA приложений), предполагается, что будет использоваться отдельный, публичный сервис.
Клиентом для сервера задач может быть любой web клиент, хотя web браузер является наиболее естественным. Стоит обратить внимание на шифрование TLS при запросах к серверу задач. Нужно будет либо настроить шифрование всего трафика из частной сети в браузер, либо разрешить браузеру обрабатывать смешанный контент.
Выбор стека
ЯП Python3 - язык на котором написаны библиотека и web-приложение. Считается, что Python достаточно прост и распространен, чтобы на таком ЯП делать практически все, что не нуждается в высокой производительности, или должно быть написано на ЯП Java.
Python имеет низкий порог входа, возможно даже часть админ задач в МО уже выполняется скриптами на Python.
Сервер задач выполнен на базе фреймворка Flask, и может (скорее должен) работать в виртуальном окружении как самостоятельный процесс (под процесс wsgi сервера), и может (необязательно) быть прикрыт с фронта http сервером (IIS, Apache, Nginx).
В сети МО нужно будет развернуть локальный сервер СУБД Postgresql (версия >= 10) и два, три web сервера. СУБД можно развернуть в Docker контейнере.
В качестве адаптера для Postgresql использовалась библиотека psycopg2-binary-2.9.2. Для того чтобы развернуть библиотеку и сервер, подойдет любой дистрибутив ОС Linux, или ОС Windows не старше 7 версии (сервер не старше 2008). ОС Linux - предпочтительный вариант. Я использовал интерпретатор Python версий 3.6.8-3.10.8, при этом последние "фичи" Python из более свежих стандартных библиотек не использовались.
В качестве http прокси использовались IIS-7.5 (в паре с wfastcgi.py) и nginx-1.26 (в паре с gunicorn-20.1).
Как уже было упомянуто, все сервера (postgresql, postgRrest, flask, http-proxy) можно развернуть в контейнерах Docker. Протестировано для docker-20.10 и docker-compose-2.5.
Как использовать
Если сложные (универсальные), дорогие системы вам не особо по карману, у вас не большой объем услуг, и квалификация ИТ персонала МО позволяет, наверное, стоит развернуть и попробовать.
Можно сдавать небольшую часть услуг в тестовом режиме. Структуру XML файла можно легко изменять, поэтому, как вариант использовать приложение для тестовой сборки пакетов.
Приложение "заточено" под конкретные услуги: КТ, МРТ исследования, и можно, адаптировать его для других целей.
Пара слов о резонах
Можно ли считать, что создание и/или использование такого софта, является ошибочным (ненужным, любое прилагательное) решением? It depends (пока еще можно). Вряд ли можно считать задачу формирования архивного пакета из двух, трех XML файлов, достаточно сложной задачей, чтобы нанимать команду разработчиков из 10 человек со средней почасовой ставкой в 1К рублей и выше.
Основная задача такого пакета программ — правильный подсчет значений соответствующих узлов XML дерева, и это вопрос медицинской статистики, а не архитектуры приложения.
Если ваш ИТ персонал со ставкой, скажем, в 300 руб./час способен развернуть и использовать эти программы, это вполне веская причина именно так и поступить.