Разработка ПО для медицинской визуализации в 2026: HIPAA, DICOM, ИИ и реальная цена

Зачем Фора Софт написала это руководство

Мы разрабатываем медицинское и видеопрограмное обеспечение с учётом требований HIPAA с 2005 года — за это время реализовали более 200 проектов в телемедицине, клинической коммуникации, медицинском обучении и визуализации. Создали CirrusMED — телемедицинскую платформу, соответствующую HIPAA, с защищёнными видеоконсультциями и клиническим чатом, а также Cloud Doctors — онлайн-сеть медицинских консультаций со встроенным рабочим процессом для врачей. Каждый из этих проектов работал в тех же регуляторных условиях, что и DICOM-платформа: заключались соглашения BAA (Business Associate Agreement), обеспечивалось хранение ePHI, велись аудит-логи, контролировался доступ и разрабатывались планы реагирования на утечки данных.

Это руководство — то, что мы передали бы CTO или продуктовому лиду, который собирается запустить проект по медицинской визуализации в 2026 году. Оно заменяет расплывчатые маркетинговые формулировки вроде «HIPAA-совместимость» конкретными техническими ограничениями, компромиссами при выборе поставщиков и реалистичными бюджетами, которые мы видим в реальных проектах. Внутри мы используем Agent Engineering, который сильно сокращает рутинную работу — поэтому наши цифры ниже, чем индустриальные бенчмарки 2024 года из большинства рыночных отчётов, и мы намеренно делаем их консервативными.

ПО для медицинской визуализации в 2026 — срез рынка, на который стоит посмотреть

Глобальный рынок программного обеспечения для медицинской визуализации вырастет с примерно 656 млрд ₽ в 2025 году до 957 млрд ₽ к 2030 году (по данным Mordor Intelligence, Grand View Research) при среднем годовом темпе роста (CAGR) около 7,8%. Самый быстрорастущий сегмент — визуализация на основе ИИ: с 123 млрд ₽ в 2025 году до 486 млрд ₽ к 2030 году при CAGR около 31,5%. Только радиологический ИИ прогнозируется на уровне 170 млрд ₽ к 2030 году. Эти цифры важны при подготовке бизнес-кейса: вы выходите не на узкую нишу, а в самый динамично растущий софтверный сегмент в здравоохранении.

FDA уже одобрила более 950 медицинских устройств с использованием ИИ, из них около 723 — примерно 76% — относятся к радиологии (Imaging Wire, 2025). Темп одобрений составляет 19–34 устройства в месяц. Это означает: клинический ИИ в медицинской визуализации больше не эксперимент, а базовое требование для любой платформы, которая хочет работать с больницами, диагностическими центрами или сетями телерадиологии. Если ваша система не поддерживает подключение стороннего ИИ или не может запускать собственный — она автоматически воспринимается как устаревшая.

Что на самом деле требует HIPAA в 2026 — изменения NPRM

В январе 2025 года HHS опубликовало уведомление о предложенном правиле (NPRM), ужесточающее HIPAA Security Rule. Финальную редакцию ожидают в конце 2025 — начале 2026 года с 180-дневным сроком на приведение в соответствие. Поэтому любая платформа медицинской визуализации, запущенная с 2026 года, должна соответствовать новым требованиям с первого дня.

Что обсуждению не подлежит

1. Шифрование всех ePHI в покое и при передаче. AES-256 в покое, TLS 1.3 при передаче. Формулировка «шифровать там, где это разумно» больше не работает — теперь действуют жёсткие требования. Под них попадает каждый DICOM-объект, каждый аудит-лог и каждая колонка в базе данных, где хранятся идентификаторы пациента.

2. Многофакторная аутентификация на каждой точке доступа к ePHI. Теперь MFA указана явно, а не подразумевается. Это означает, что MFA должна быть включена в веб-приложении для врачей, на рабочем месте рентгенолога, в административной панели и на любом API-клиенте, способном получить DICOM-исследование. Исключения допускаются только для систем, которые технически не могут поддерживать MFA, и такие случаи нужно будет задокументировать.

3. Обязательный анализ рисков и инвентаризация активов. Инициатива OCR по анализу рисков 2024 года уже усиливает применение санкций к вендорам, у которых нет документированной оценки рисков. Согласно NPRM, анализ рисков, инвентаризация активов и сетевая карта должны быть актуальными и подписанными — а не просто лежать забытым PDF-файлом в Confluence.

4. Протестированный план реагирования на инциденты и восстановление за 72 часа. Проект правила устанавливает конкретные сроки восстановления критически важных систем — к ним, как правило, относятся PACS и просмотрщики изображений — а также требует ежегодного тестирования плана реагирования.

5. Контроль вендоров (Business Associate). Каждый субподрядчик, с которым заключён BAA (ваш облачный провайдер, поставщик AI-инференса, платформа логирования), должен ежегодно подтверждать соответствие требованиям. Фраза «у нас есть подписанный BAA» уже не считается достаточным — нужна задокументированная цепочка подтверждений.

DICOM — место, где на самом деле хранятся ePHI

DICOM (Digital Imaging and Communications in Medicine) — формат, на котором общаются все устройства медицинской визуализации в мире: КТ, МРТ, рентген, УЗИ, патология. Именно в этом формате чаще всего теряются персональные данные пациентов (PHI). DICOM-файл выглядит как обычное изображение, но в его заголовке хранится множество атрибутов, идентифицирующих пациента. Небрежная обработка таких файлов может привести к утечке этих данных, даже если сами пиксели изображения не трогались.

Что на самом деле лежит в DICOM-заголовке

Это теги, важные для HIPAA, в порядке, в котором их стоит учитывать инженеру по защите данных:

• (0010,0010) Имя пациента — имя пациента
• (0010,0020) Patient ID / MRN — идентификатор пациента
• (0010,0030) Patient Birth Date — дата рождения пациента
• (0008,0020) Study Date — дата проведения исследования
• (0008,0090) Referring Physician’s Name — имя направляющего врача
• (0008,1070) Operator’с Name — имя оператора
• (0020,000D) Study Instance UID — часто формируется на основе MRN при проведении сканирования
• (0008,0080) Institution Name — название учреждения
• Приватные теги (номера групп с нечётной последней цифрой) — вендорские. Часто в них содержатся заметки оператора сканера или идентификаторы пациента, которые производитель не задокументировал
• Текст, вшитый в пиксели — УЗИ и старые рентген-аппараты часто впечатывают имя и дату рождения пациента прямо в изображение в виде пикселей

Стандарт деидентификации, который всё равно утекает

DICOM Part 15 (PS3.15) описывает Basic Application Level Confidentiality Profile (BACP). Это базовый стандарт деидентификации — но одного его недостаточно. Он удаляет стандартные идентификаторы, но не находит приватные теги, не выявляет текст, встроенный в пиксели, и не предотвращает повторную идентификацию по уникальным Study UID. В промышленных конвейерах сначала применяют BACP, затем удаляют приватные теги, далее проводят OCR-проверку пикселей (особенно для УЗИ и рентгена грудной клетки, где встроенный текст встречается часто), и в конце перекодируют UID с помощью необратимого хеша.

Эталонная архитектура HIPAA-совместимой платформы медицинской визуализации в 2026 году

Для большинства новых проектов мы используем пятислойный облачный стек. У каждого слоя — своя задача и свой набор мер по соблюдению требований. Ни один компонент не отвечает за комплаенс целиком — защита организована по принципу эшелонирования.

Наш дефолтный стек на старте проекта — OHIF + Cornerstone.js на фронтенде, Orthanc или AWS HealthImaging в качестве архива, PostgreSQL и отдельный FHIR-сервер (HAPI FHIR или Azure Health Data Services) для хранения метаданных и клинического контекста, а также тонкий AI-слой на Python / FastAPI с MONAI или сторонним инференсом. Такой подход покрывает 80–90% функционала коммерческого PACS почти без лицензионных затрат и остаётся в рамках требований комплаенса, поскольку каждый компонент развёрнут внутри облачного периметра, защищённого BAA.

Выбор облака — AWS, GCP или Azure для медицинской визуализации

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

Open-Source-блоки, которые нельзя игнорировать

Правильный ответ для большинства проектов разработки ПО для медицинской визуализации — не «писать с нуля» и не «лицензировать закрытый PACS». Это — собрать готовые open-source-компоненты, пригодные для использования в продакшене, и добавить AI, рабочие процессы и комплаенс-обвязку, которые действительно будут вашей собственностью. Вот короткий список того, к чему мы стремимся.

OHIF Viewer (MIT)

Безустановочный браузерный DICOM-просмотрщик. На React/TypeScript, расширяется через extension modes, нативно работает с DICOMweb, используется более чем в 50 клинических исследовательских организациях. Лицензия разрешает коммерческое использование. Для большинства проектов это 6–8 недель экономии по сравнению с просмотрщиком, который пришлось бы разрабатывать полгода только на основе Cornerstone.js.

Cornerstone.js (MIT) и dcmjs (MIT)

JavaScript-примитивы, на которых построен OHIF. Обращаться к ним напрямую стоит только в случае, если вам нужен кастомный просмотрщик — например, киоск, инструмент для онкоконсилиума или встроенный просмотрщик внутри стороннего EHR с жёсткими ограничениями интерфейса.

Orthanc (GPLv3) и dcm4chee (Apache 2.0)

Продакшен-готовые DICOM-серверы и менеджеры изображений. Orthanc проще в развёртывании в Docker, легко расширяется с помощью плагинов и Lua-скриптов; при этом лицензия GPLv3 требует соблюдения условий при распространении производных версий. dcm4chee — мощный Java-решение корпоративного уровня, но с более свободной лицензией Apache 2.0, уже используется в продакшене во многих медицинских учреждениях.

MONAI и TotalSegmentator

MONAI — фреймворк на базе PyTorch для искусственного интеллекта в медицинской визуализации. TotalSegmentator, созданный на основе MONAI, за 5–10 секунд на одном современном GPU размечает более 130 анатомических структур на КТ всего тела. Использование любого из них экономит 3–6 месяцев работы при разработке собственного ИИ, если задача — сегментация.

AI в медицинской визуализации — что реально работает в продакшене

С 723+ устройствами радиологического ИИ, одобренными FDA, вопрос «работает ли ИИ в визуализации?» уже не стоит. Теперь он звучит иначе: «какой ИИ разрабатывать самому, какой покупать, а какой подключать как стороннее решение?». Ответ большинства программ — «все три варианта, в зависимости от задач».

Разрабатывайте сами, когда модель — это и есть продукт

Если модель — это то, за что платят пользователи (например, проприетарный детектор патологий, инструмент для ортопедических измерений или классификатор под конкретный датасет), её разрабатывают сами. Большая часть бюджета уходит на подготовку данных и клиническую валидацию — часто 40–60% от общей стоимости AI-решения. Также нужно закладывать средства на прохождение сертификации FDA (по маршрутам De Novo, 510(k) или PMA класса III), если продукт продаётся в США.

Интегрируйте, когда модель — базовое требование

Триаж (Aidoc, Viz.ai), скрининг туберкулёза по рентгену грудной клетки (Qure.ai), черновики отчётов (Rad AI, Nuance PowerScribe) и оценка костного возраста — это стандартные задачи, где правильнее интегрировать готовые решения, а не создавать свои с нуля. Интеграция обходится в 1,5–4,5 млн ₽ на одного поставщика и включает BAA, настройку маршрутизации данных и доводку интерфейса — это значительно дешевле, чем 37 млн ₽ и более на клиническую валидацию собственной альтернативы. Подробнее об AI-решениях для медицинской визуализации и анализа видео мы расскажем в отдельной статье.

Open-Source — когда нужна скорость

TotalSegmentator, nnU-Net, MONAI bundles и медицинские модели из Hugging Face покрывают сегментацию органов, разметку анатомических ориентиров и измерения для большинства исследовательских и клинических задач поддержки принятия решений. Эти инструменты не имеют одобрения FDA, поэтому используйте их как вспомогательные средства — не для первичной диагностики.

DICOMweb и FHIR — слой взаимодействия, который защищает от привязки к вендору

Самое важное архитектурное решение в современной платформе медицинской визуализации — использование открытых стандартов на всех этапах. DICOMweb отвечает за передачу изображений, а FHIR R4 — за заказы, отчёты и клинический контекст. Оба стандарта необходимы для полноценной интеграции с электронной медицинской картой (EHR) к 2026 году.

DICOMweb в трёх маршрутах

QIDO-RS — маршрут запроса: «найди все исследования этого пациента с 2022 года». WADO-RS — маршрут получения: «отдай пиксельные данные этой серии». STOW-RS — маршрут сохранения: «вот новое исследование». Все три поддерживают серьёзные просмотрщики и крупные облачные сервисы визуализации. Переход на DICOMweb вместо устаревшего DIMSE/C-FIND экономит недели работы с фаерволами и VPN при каждом развёртывании у клиента.

FHIR ImagingStudy и клиническая нить

Ресурс ImagingStudy в FHIR R4 ссылается на DICOMweb-эндпоинты и связывает изображение с Patient, Encounter, ServiceRequest (заказ), DiagnosticReport и Observation. Именно это позволяет вашей платформе аккуратно встроиться в рабочий процесс Epic или Cerner — без FHIR вы прикручиваете визуализацию к стеку здравоохранения через проприетарные адаптеры и переделываете интеграцию для каждой больницы.

Дорожная карта внедрения — запуск за 16 недель

Наша стандартная программа на старте проекта — HIPAA-совместимый MVP для медицинской визуализации за 16 недель силами команды из трёх инженеров (бэкенд, фронтенд, DevOps и комплаенс), плюс продакт-менеджер и QA на частичной занятости. С Agent Engineering сроки сокращаются примерно на 30% на знакомой территории.

Модель стоимости — во сколько реально обходится платформа визуализации, соответствующая HIPAA

Цифры ниже — консервативные диапазоны для проекта с Fora Soft и подключённым Agent Engineering. Реальные рыночные значения обычно выше; вендоры, предлагающие MVP за 6 млн ₽, как правило, строят всё с нуля или несут серьёзные накладные расходы из-за офшорной разработки.

Облачная инфраструктура учитывается отдельно. Для пилота с архивом 10–50 ТБ и умеренной нагрузкой на AI-обработку рассчитывайте на 112–337 тыс. ₽ в месяц при использовании AWS HealthImaging или GCP Healthcare API. GPU-обработка — как джокер: один постоянно работающий инстанс G5/G6 обойдётся в 60–135 тыс. ₽ в месяц, тогда как serverless-обработка держит расходы на уровне нескольких рублей за одно исследование.

Мини-кейс — CirrusMED, уроки, применимые к визуализации

CirrusMED — телемедицинская платформа, соответствующая требованиям HIPAA. Мы разработали её с поддержкой защищённых видеоконсультаций, клинического чата и рабочих процессов для координации медицинской помощи. Это не DICOM-просмотрщик, но регуляторные требования те же: работа с ePHI, наличие BAA, шифрование медиа, аудит-логи и контроль доступа.

Уроки переносятся напрямую. Первое: включайте аудит-логирование с самого начала — каждое чтение данных пациента, подключение к сессии, действие администратора. Добавлять аудит-логи после первой проверки SOC 2 у клиента всегда дороже, чем заложить их с самого первого спринта. Второе: изолируйте арендаторов на уровне базы данных, а не только через API — ошибка в фильтре API — это инцидент; правило row-level security в Postgres — надёжная защита. Третье: сделайте MFA обязательным для всех ролей, включая внутреннего администратора. Больницы обязательно спросят об этом, и ответ должен быть «уже работает», а не «в планах».

Если вы хотите получить такую же 12-недельную оценку для вашей программы визуализации — что соответствует требованиям сегодня, что не пройдёт проверку по HIPAA в 2026 году и сколько стоит устранить пробелы — свяжитесь с нами, и мы предоставим готовый шаблон.

Ландшафт вендоров — когда покупать, а когда строить

Корпоративные PACS-поставщики (Sectra, Visage/Philips, Agfa, GE, Fujifilm) доминируют на рынке больниц и выдают семизначные счета за внедрение. Игроки с фокусом на ИИ (Aidoc, Qure.ai, Rad AI, Subtle Medical, Viz.ai) — это другая категория: обычно это SaaS-решения, которые стоят за исследование или за рабочее место и интегрируются в существующий PACS. Кастомная разработка занимает промежуточное положение и становится выгодной, когда нужен специализированный рабочий процесс визуализации, которого нет в стандартных решениях.

Покупайте коммерческий PACS, когда

Вы — больница с предсказуемым рабочим процессом визуализации, без амбициозных продуктовых задач, и для вас важнее надёжная поддержка, чем гибкость. Sectra или Visage — проверенные десятилетиями решения.

Интегрируйте AI-ориентированных поставщиков, когда

Вы уже используете PACS и хотите добавить триаж, измерения или ИИ для отчётов, не меняя саму систему. Заложите 37–375 ₽ за исследование на большинство ИИ-сервисов плюс 1,5–4,5 млн ₽ на интеграцию.

Стройте кастом, когда

Рабочий процесс визуализации — это и есть продукт: сети телерадиологии, платформы кардиологического анализа, разбор патологических слайдов, ветеринарная визуализация, платформы для клинических исследований, лонгитюдные просмотрщики в портале пациента. Всё, что выходит за рамки типового больничного PACS. Это — зона силы Фора Софт.

Фреймворк принятия решения — build vs buy в пяти вопросах

Q1. Рабочий процесс визуализации — ваше отличие или commodity? Если он определяет, как пользователи просматривают, аннотируют и обмениваются изображениями, — создавайте. Если это стандартный анализ рентгенологов, — покупайте.

Q2. Сколько площадок и арендаторов? Одна больница — покупайте. Пять арендаторов или сеть — стройте. Цена за место в коммерческих лицензиях плохо масштабируется после первого арендатора.

Q3. Несёте ли вы свой AI? Если да, кастомное решение даёт ему первоклассное место для хостинга, версионирования и мониторинга. Коммерческие PACS относятся к AI как к плагину второго сорта.

Q4. Какова ваша позиция по EHR? Если нужно работать внутри Epic или Cerner как нативное расширение — FHIR-ориентированный кастом выигрывает. Если вы отдельный клинический продукт, подойдёт любой подход.

Q5. Насколько болезненна для вас зависимость от вендора? Каждый коммерческий PACS привязывает вас к проприетарной модели данных и создаёт проблему миграции на десятилетия вперёд. Решение на открытых стандартах сохраняет ваши данные переносимыми.

Пять ловушек, в которых тонут проекты HIPAA-визуализации

1. Восприятие BAA как гарантии комплаенса. Подписанный BAA с AWS или GCP не делает ваше приложение HIPAA-совместимым. Модель разделённой ответственности означает, что вам нужно самостоятельно настраивать шифрование, контроль доступа, ротацию ключей и ведение аудиторских логов. Штрафы от OCR выписываются именно вам, а не облачному провайдеру.

2. Незачищенные метаданные DICOM. Самый быстрый способ устроить скрытую утечку — отправить по почте «анонимизированный» DICOM-файл, в котором в заголовке осталось имя пациента, или УЗИ, где имя вшито прямо в изображение. Обязательно стандартизируйте процесс анонимизации перед любым экспортом.

3. Аудит-логи как галочка, в которую только пишут. Логи, которые никто не проверяет, по которым не настроены оповещения и которые хранятся меньше 30 дней, не соответствуют требованиям ни HIPAA, ни SOC 2. Передавайте логи в отдельное, зашифрованное и неизменяемое хранилище, настройте оповещения на действия администраторов, массовые экспорт и ночные подключения.

4. Перетаскивание боевых ePHI в стейджинг. Любимый шорткат любого инженера — скопировать продакшн в дев для тестов. Это самый быстрый способ превратить ноутбук разработчика в источник утечки. Используйте синтетические DICOM-датасеты (например, открытые наборы Cancer Imaging Archive / TCIA) или полностью деидентифицированные выгрузки.

5. Пропуск тренировки за столом. NPRM 2026 года потребует утверждённый план реагирования на инциденты. Тренировки за столом обходятся дёшево; утечки данных — нет. Кейс Vision Upright MRI (21 778 пациентов, отсутствие анализа рисков на руках) — наглядный пример того, что происходит, когда план реагирования существует только на бумаге.

KPI — что измерять после запуска

Качественные KPI. Время до первого пикселя (TTFP) в просмотрщике — цель: медиана менее 2 с для закешированных исследований и менее 6 с для холодного запроса. Доля успешных межплощадочных DICOM-обменов — цель: более 99,5%. Доля успешного аудита деидентификации экспортируемых исследований — цель: 100%.

Бизнес-метрики. Время на исследование у рентгенолога — каждые 10% сокращения приносят дополнительно 7,5 млн ₽ в год при масштабировании. Стоимость хранения одного исследования в год — держите ниже 18 ₽ с помощью политик жизненного цикла. Срок подготовки отчёта с помощью ИИ — цель: сократить на 40–60% по сравнению с базовым вариантом без ИИ.

KPI надёжности. Месячная доступность просмотрщика — 99,95%, приём данных — 99,9%. Время восстановления архива (RTO) — менее 4 часов, допустимая потеря данных (RPO) — менее 15 минут. Уровень доступности конвейера аудит-логов по SLA — 99,99%. Если лог недоступен, система автоматически блокирует высокорисковые операции.

Когда НЕ нужно строить платформу медицинской визуализации

Есть три ситуации, когда кастомная разработка — не лучший выбор. Первая: одна больница без планов на продукт — проще купить Sectra, Visage или облачный PACS. Внедрение пройдёт быстрее, а поддержка будет «под ключ». Вторая: чисто AI-решения, которые уже есть на рынке и одобрены FDA — например, Aidoc для триажа инсультов и ТЭЛА или Qure.ai для анализа рентгена грудной клетки. Они сэкономят миллионы рублей на клинической валидации. Третья: всё, что требует сертификации FDA 510(к), но не связано со стратегическим продуктом. Затраты на регуляторные процедуры — от 37 до 150 млн ₽ — оправданы только тогда, когда искусственный интеллект — ваше ключевое преимущество, а не просто одна из функций.

Сценарии утечек — на чём больницы продолжают терять 75 млн ₽+

Если посмотреть на действия OCR в 2023–2025 годах против поставщиков и медицинских учреждений, работающих с визуализацией, можно выделить три повторяющихся сценария. Первый — незащищённый PACS, открытый напрямую в интернет: Vision Upright MRI, май 2025 года, 21 778 пациентов. OCR отметил, что не проводился предварительный анализ рисков. Второй — старый DICOM-сервер с учётными записями по умолчанию, которые так и не сменили: Northeast Radiology, около 298 тысяч пациентов, мировое соглашение на 26 млн ₽ и многолетний план исправлений. Третий — незашифрованный бакет S3 / GCS с исследовательским датасетом, содержащим DICOM-файлы. В таких случаях речь всегда шла о неправильной настройке, а не о кибератаке.

Общая нить: 76% утечек в облаках здравоохранения в 2023 году произошло из-за неправильной настройки или человеческой ошибки, а не из-за сложных кибератак. Решение — соблюдение операционных стандартов: автоматизация смены секретов, использование infrastructure-as-code для облачных бакетов, обязательное шифрование с ключами, управляемыми KMS, и еженедельная проверка изменений в конфигурации. Ничего из этого не стоит дорого. Но этим регулярно пренебрегают.

Почему Фора Софт для HIPAA-разработки ПО медицинской визуализации

Мы — команда из 50 человек, которая с 2005 года занимается разработкой видео, искусственного интеллекта и медицинского ПО. За это время наша практика разработки ПО на заказ реализовала более 200 проектов, а направление интеграции ИИ запустило продакшен-конвейеры инференса в здравоохранении, EdTech и видеостриминге. Среди релевантных проектов в сфере медицины — CirrusMED, Cloud Doctors и MyOnCallDoc.

Мы используем Agent Engineering на каждом проекте — это сокращает время на подготовку инфраструктуры, тестирование и документацию примерно на 30% в привычных для нас условиях. Поэтому наши оценки стоимости MVP и корпоративных платформ ниже средних по рынку — согласно отчётам за 2024 год. Также мы работаем по модели выделенной команды разработки для клиентов, которым нужны наши инженеры внутри их процессов. Отдельную практику у нас ведёт команда планирования продукта и аналитики — она работает над проектами с нуля, которые стартуют с этапа исследования, а не с написания кода.

FAQ

Что читать дальше

Готовы запустить HIPAA-совместимую платформу медицинской визуализации в 2026 году?

План на 2026 год понятен. Считайте, что NPRM HIPAA вступит в силу в конце 2025 года, и с самого начала закладывайте AES-256, TLS 1.3, MFA, задокументированный анализ рисков и протестированное реагирование на инциденты — с первого спринта. Используйте открытые стандарты — DICOMweb для медицинских изображений, FHIR R4 для клинических данных — чтобы информация клиентов оставалась переносимой. Выберите одну облачную платформу с подписанным BAA (AWS, GCP или Azure) и передайте ей тяжёлую инфраструктуру; оставьте инженерный бюджет на разработку ИИ, рабочих процессов и пользовательского интерфейса — то, что действительно отличает ваш продукт.

Бюджетируйте трезво: 2,6–4,8 млн ₽ на совместимый MVP, 13,5–33 млн ₽ на полноценную корпоративную платформу с ИИ и ЭМК, плюс 15–25% на ежегодную поддержку. Сравните эти цифры с недавними мировыми сделками по OCR (26–150 млн ₽+), и математика становится очевидной. Если нужна вторая точка зрения по дорожной карте — архитектуре, уровню соответствия требованиям, срокам и стоимости — проведём 30-минутный разговор и подготовим письменный план.