Дэшборды, Автоматизация | Олег Брагинский, Максим Мухтаров
Основатель «Школы траблшутеров» Олег Брагинский и ученик Максим Мухтаров рассказывают о том, как спроектировать систему, автоматизирующую обновление корпоративной отчётности для многофилиальных отечественных медицинских учреждений.
В крупной сети частных поликлиник возникла ситуация, когда множество информационных систем, снабжённых собственными модулями отчётности, настолько усложнили общую архитектуру, что в какой-то момент главный ИТ-шник твёрдо решил: «Проще разработать собственный репортинг».
Начали с построения принципиальной схемы, объединившей:
- Медиалог – ведение медицинских карт пациентов большинства городов
- Инфоклиника – аналогичная система для ряда населённых пунктов
- SAP – автоматизация расчёта основных финансовых показателей
- Мобильное приложение – запись на приём, телемедицина
- 1С MDM – хранение нормативно-справочной информации
- ТАСУ – обмен историями болезни с фондами ОМС
- Intersystems Laport – лабораторные тесты.
Предстояло объединить разнородные интерфейсы, распарсить файлы разноформатных данных, связать информацию по ключевым полям. Отдельную сложность представляло получение доступов от службы информационной безопасности и обеспечение достаточного быстродействия.
Собрали требования с бизнес-заказчиков. Договорились, что проект не будет работать в режиме онлайн. Составили план очерёдности подключения подразделений к пилотному тестированию.
Предусмотрели:
- механизмы передачи данных в Excel
- ежесуточную подгрузку информации
- роли продвинутым пользователям
- доступность отчётов в браузере.
Отдельным вызовом стало отсутствие единой шины данных. Похожий механизм окружал только SAP, остальные приложения подключались друг к другу по схеме «звезда». Рассматривали вариант сделать мастер-системой Медиалог. Идея провалилась из-за совокупной технической сложности.
Приступили к проектированию хранилища данных, заливке информации в соответствующие таблицы, связыванию объектов по ключевым полям. Дополнительным плюсом стали повышение реляционности сущностей, усердная борьба с дубликатами, сопутствующие чистки записей.
Определили слои:
- внешние системы исходных данных и справочная информация
- внутреннее множество таблиц для массового копирования
- базы данных с представлениями для отчётов
- OLAP-кубы бизнес-процессов
- визуализация.
Для хранилища данных выбрали MS SQL Server: служил основой для большинства внутренних корпоративных приложений, технические администраторы были обучены и сертифицированы, организация обладала достаточным количеством приобретённых лицензий на Enterprise Edition.
Сбор, трансформацию и загрузку данных организовали двумя способами: а) для исходных систем с MS SQL Server, – через связанные сервера, хранимые процедуры, менеджер заданий; б) для прочих взяли решение с открытым исходным кодом Apache Airflow, запускающее python-скрипты.
Для OLAP-кубов единственным вариантом видели установку SQL Server Analysis Services. В качестве приложения слоя визуализации выбрали Power BI Report Server с дэшбордами и постраничными отчётами SQL Server Reporting Services, шедший в комплекте с софтом хранилища.
Работа с некоторыми внешними системами организовали на базе предоставляемого ими API. С частью настроили файловый обмен. С оставшимся большинством взаимодействовали через прямое чтение информации из соответствующих таблиц боевых сред и аналитических реплик.
Несмотря на наличие отраслевых вендорных решений по управлению справочниками, пришлось разработать собственный интеграционный подход, насыщенный аналитическими атрибутами: виды филиалов, эталонные специальности, категории отделений, группировки услуг, календари.
Удалось установить соответствие для одинаковых объектов, хранящихся в разных приложениях: лечебные учреждения из Медиалога, Инфоклиники, SAP. Предусмотрели сущности: плановые показатели, паспорта кабинетов и медицинского оборудования, унифицированные контрагенты.
Информацию из исходных систем черпали тремя способами: а) копируя структуру части оригинальных таблиц, необходимых для построения отчётов, б) загружая файлы в неизменном формате; в) разворачивая в реляционный вид получаемые по API структуры данных.
Для универсализации сущностей, используемых во множестве витрин, произвели дополнительную обработку: а) атомизировали текстовые строки парсингом; б) сгруппировали аналитические атрибуты алгоритмами; в) восполнили историзацию объектов логированием.
Для целей репортинга создали отдельные детализированные и/или агрегированные таблицы. Подразделениям, которые обросли собственными аналитиками, предоставили «лягушатники», где можно было безнаказанно резвиться, решая локальные задачи без помех глобальному замыслу.
Центральным элементом решения стали OLAP-кубы бизнес-процессов: оказания услуг (позиции в счёте), реализации направлений (приёмы, анализы, исследования по плану лечения), фиксации визитов (записи в расписании и приходы по ним), госпитализации (движения по койкам и выписки).
Визуализацию обеспечили двумя способами: а) большинству – через веб-приложение, доступное из корпоративной сети, в виде воронок, гистограмм, графиков, распределений, карточек KPI; б) любителям подробностей – посредством получения данных в умные/сводные таблицы Excel.
Наличие мощных серверов и малого количества начальных отчётов и пользователей позволили не задумываться о производительности и пропустить этап оптимизации. Последующее использование потребовало в какой-то момент вернуться и повысить скорость предоставления информации.
От полной перегрузки таблиц не сразу перешли к инкрементальным обновлениям, т. к. стремились удовлетворить как можно больше запросов. По этой же причине строили индексы не с самого начала и не заботились о нормализации представлений, что вело к разрастанию объёмов данных.
Сосредоточение на локальных задачах позволило быстро преодолеть этап тестирования и перейти к промышленной эксплуатации. Обрадованные подразделения начали заказывать больше информационных продуктов, что укрепило привычку централизованного просмотра отчётности.
Таким образом, проект, который запороли нанятые интеграторы, удалось вернуть к жизни, внедрить использование системы в ежедневную практику компании, уйти от множественных источников информации, централизовать методику расчётов, избежать найма дополнительного персонала.
Планируем расширить архитектуру для обновления в реальном времени, внедрить колоночные базы данных для источников больших объёмов, предоставлять отчёты на мобильные устройства, импортозаместить критические компоненты, оставшиеся без поддержки зарубежных вендоров.