Если вы когда-нибудь выкатывали фичу, которая хранит персональные данные - почтовые адреса, заметки в свободной форме, API-токены, идентификационные номера - у вас наверняка возникала та же неприятная мысль: врядли стоит доверять базе данных. Бэкапы копируются на ноутбуки. Снапшоты оседают на файловых ресурсах. Галочка “encryption at rest” в облачной консоли защищает только от одного конкретного вида кражи - от того, что кто-то унесет диск.

Зашифровать данные до того, как они попадут в базу, на слайде звучит просто - AES, ключ, готово. В реальном коде простая версия ломается ровно в тот момент, когда вы пытаетесь ротировать ключ, найти запись по email, или объяснить ревьюверу, каким именно ключом зашифрована конкретная строка.

Fast Healthcare Interoperability Resources (FHIR) - это прокотол для обмена медицинскими данными. Стандарт очень объемный, одних только ресурсов более полутора сотен, и цель данной статьи - дать стартовую точку для его изучения.

Это первый из запланированной серии постов посвященных FHIR технологиям, далее планирую добавить статьи с шагами регистрации и подключения к EPIC EHR, загрузки FHIR данных, их использования для формирования карты пациента и особенностями использования FHIR данных в AI чат-ботах.

FHIR (Fast Healthcare Interoperability Resources) - это стандарт обмена медицинскими данными, разработанный HL7. Сегодня он является основой для взаимодействия между EHR-системами, мобильными приложениями и медицинскими сервисами. Последние актуальные версии стандарта - R4 (2019) и R5 (2023).

Если очень коротко: FHIR описывает ресурсы (Patient, Observation, Encounter, MedicationRequest и т. д.), которые доступны через REST API в JSON или XML. Поверх этого можно строить и пациентские приложения, и интеграции между медицинскими организациями.

На этой базе появились так называемые patient-facing API - интерфейсы, через которые сам пациент или доверенные приложения могут получить доступ к медицинским данным: диагнозам, назначениям, результатам лабораторных анализов, изображениям, выпискам. Для США эту модель дополнительно закрепили регуляторы (ONC Cures Act), а для разработчиков удобные инструменты предлагает инициатива SMART on FHIR (OAuth2, scopes вида patient/*.read, PKCE и рефреш-токены).

Однако реальность заметно сложнее, чем стандарты на бумаге. Даже если два провайдера «поддерживают FHIR R4», API у них могут радикально отличаться:

Обзор возможностей по управлению фрагментацией блобов в Azure Storage Account и ее влияние на скорости доступа к ним.