Запрос на дашборд часто начинается со списка показателей и заканчивается красивым отчётом, по которому непонятно, что делать дальше. На примере BI-дашборда для сравнения подразделений разбираю, как перейти от пожеланий к конкретному решению, проверить сопоставимость данных и построить структуру отчёта от отклонения к деталям.

Ниже не попытка восстановить всю работу над проектом по дням, а структура подхода, к которой я пришёл на практике.

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

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

Здесь появляется RAG, или Retrieval-Augmented Generation. Но в медицинской среде я бы рассматривал его не как чат-бота и тем более не как автономного медицинского советника. Более полезная модель - управляемый слой между данными, документами, аналитическими системами и пользователями.

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

В такой ситуации возникает понятная идея: подключить мобильный клиент напрямую к существующей базе или быстро добавить несколько методов в старую систему. Это действительно позволяет показать первые экраны, но дальше начинают появляться проблемы. Клиент зависит от структуры таблиц, разные разделы возвращают данные в разных форматах, права доступа проверяются непоследовательно, а любое изменение монолита может сломать уже опубликованное приложение.

В этой статье разберу более устойчивый вариант: отдельный API‑слой между мобильным приложением и существующей системой. Без полной переработки монолита и без попытки сразу перейти на микросервисы.