Разработка приложений для здравоохранения со стороны выглядит как разработка программного обеспечения. Инструменты перекрываются, шаблоны знакомы, и код не отличается явно. За этой поверхностью он действует в соответствии с другим набором обязательств, которые определяют каждое принимаемое вами архитектурное решение, от того, как вы храните номер телефона до того, как вы регистрируете запрос к базе данных.
Данные пациентов существуют в рамках нормативной базы, которая точно определяет, кто может получить к ним доступ, как они должны быть защищены и что происходит, когда это не так. Ошибка не доставляет неудобств. Это ответственность, которая может положить конец компании, и она проявляется на поздних стадиях цикла разработки, если соблюдение требований не было частью исходной архитектуры.
В этом руководстве описывается, что командам разработчиков необходимо понимать при создании приложений, обрабатывающих защищенную медицинскую информацию: основы соответствия HIPAA, выбор стека медицинских технологий, интеграция носимых данных и стандарты совместимости, которые определяют, может ли ваше приложение действительно взаимодействовать с более широкой системой здравоохранения.
Почему разработка приложений для здравоохранения требует другого мышления
Самая распространенная ошибка при разработке приложений для здравоохранения — рассматривать соответствие требованиям HIPAA как функцию, которую необходимо добавить перед запуском. Разработчики, создающие программное обеспечение для других отраслей, часто полагают, что могут выпустить MVP и впоследствии обеспечить соответствие требованиям. Это предположение не соответствует действительности, поскольку соответствие требованиям — это структурное свойство архитектуры, а не слой объектов, который вы применяете в конце.
Подумайте о средствах контроля доступа. В стандартном приложении разрешения на основе ролей — это функция продукта, которая появляется после работы основных функций. В приложении для здравоохранения они являются обязательным требованием с самого первого дня. Правило безопасности HIPAA требует, чтобы только авторизованные пользователи могли получить доступ к защищенной медицинской информации (PHI), а в ваших журналах аудита должно регистрироваться каждое событие доступа с достаточной подробностью для поддержки проверки соответствия.
То же самое относится и к хранению, передаче и хранению данных. Каждое архитектурное решение пересекается с нормативными требованиями. Это форма проблемы, которую вы решаете, и строить с учетом этого с самого начала значительно дешевле, чем реструктуризировать в середине разработки.
Основы соответствия HIPAA для разработчиков
HIPAA действует на основе двух основных правил, касающихся технических групп: правила конфиденциальности и правила безопасности. Правило конфиденциальности определяет, что считается защищенной медицинской информацией и кто может ее использовать. Правило безопасности определяет технические, физические и административные меры безопасности, необходимые для защиты электронной PHI.
Для разработчиков Правило безопасности является более действенным документом. Это требует:
- Шифрование при хранении и передаче. Любой ePHI, хранящийся в базе данных, объектном хранилище или файловой системе, должен быть зашифрован. Любой ePHI, передаваемый по сети, требует шифрования при передаче (минимум TLS 1.2, предпочтительно TLS 1.3).
- Контроль доступа и аутентификация. Доступ на основе ролей с уникальными идентификаторами пользователей, многофакторной аутентификацией для систем, обрабатывающих ePHI, и автоматическим тайм-аутом сеанса.
- Аудиторский контроль. Журналы действий для всех доступов и изменений ePHI, защищены от несанкционированного доступа и хранятся в течение шести лет.
- Контроль целостности. Механизмы определения того, была ли ePHI изменена или уничтожена без разрешения.
Соглашения о деловых партнерствах
Каждый поставщик, который обрабатывает ePHI от вашего имени, должен подписать Соглашение о деловом партнерстве (BAA). Это не формальность. Если поставщик не предлагает BAA, его услугу нельзя использовать в потоках данных PHI, независимо от того, насколько безопасна их маркетинговая информация.
Это влияет на выбор поставщиков по всему вашему стеку. Прежде чем выбирать поставщика базы данных, облачный хостинг, службу электронной почты или сторонний API, подтвердите доступность BAA. Некоторые поставщики резервируют БАД для корпоративных планов, что имеет реальные последствия для продуктов на ранней стадии. А Контрольный список разработки программного обеспечения, соответствующего требованиям HIPAA помогает сопоставить эти требования с вашей архитектурой, прежде чем приступить к ее созданию.
Создайте свой стек технологий здравоохранения
Инфраструктура и хранение данных
AWS, Google Cloud и Azure предлагают услуги, соответствующие требованиям HIPAA, но не все сервисы на каждой платформе соответствуют требованиям. AWS поддерживает список сервисов, отвечающих требованиям HIPAA, который существенно короче полного каталога сервисов. Вам необходимо проверить, какие конкретные службы применимы к вашей архитектуре.
При выборе базы данных требования к шифрованию и контролю доступа отдают предпочтение управляемым сервисам, где шифрование в состоянии покоя используется по умолчанию, а управление ключами интегрируется с диспетчером секретов вашего облачного провайдера. Самоуправляемые базы данных не дисквалифицируются, но они полностью перекладывают бремя ротации ключей, ведения журнала аудита и шифрования резервных копий на вашу команду.
Средства связи
Клиническая коммуникация требует платформ, поддерживающих БАД. Стандартные Gmail, Slack Free и Pro, а также приложения для обмена сообщениями для потребителей не соответствуют критериям. Google Workspace (Business Starter и выше) и Microsoft 365 (Business Premium и выше) обеспечивают покрытие BAA при правильной настройке. В частности, для этих рабочих процессов PatientNow — AI-платформа для медсанчастей и оздоровительные клиники обеспечивают общение и запись пациентов в соответствии с требованиями.
Сбор форм и прием пациентов
Рабочим процессам приема пациентов необходимы инструменты, обеспечивающие соответствие требованиям HIPAA. Например, Typeform не предлагает BAA, что исключает его для любой формы сбора медицинской информации.
Варианты, совместимые с HIPAA, включают в себя Джотформ ИИкоторый позволяет создавать формы на основе искусственного интеллекта в рабочих процессах здравоохранения, одновременно поддерживая соглашения BAA и Google Forms в подписанной учетной записи Google Workspace. Эти платформы поддерживают условное ветвление, автоматическую маршрутизацию и логику приема, необходимую для рабочих процессов здравоохранения, без необходимости выбора между соответствием требованиям и возможностями.
Интеграция носимых данных
Носимые устройства теперь занимают центральное место в удаленном мониторинге пациентов, лечении хронических заболеваний, программах оздоровления и клинических исследованиях. Интеграция носимых данных в приложение здравоохранения создает категорию технических проблем, которых нет при разработке стандартного программного обеспечения.
Проблема нескольких провайдеров
Большинству медицинских приложений требуются данные с нескольких носимых устройств: Apple HealthKit, Google Health Connect, WHOOP, Oura, Garmin, Samsung Health и других. Каждый из них имеет свой API, разную схему данных и собственный поток аутентификации. Создание и поддержка индивидуальной интеграции с каждым из них обходится дорого.
Команда, интегрирующая десять платформ устройств, напрямую владеет десятью отдельными отношениями API. Каждый провайдер обновляется по своему графику. Когда поставщик отправляет критическое изменение, для вашей команды это становится инцидентом, связанным с обслуживанием. Со временем накладные расходы увеличиваются пропорционально количеству поставщиков, которые вы обязались поддерживать.
Инфраструктура носимых устройств с открытым исходным кодом
Open Wearables — это платформа с открытым исходным кодом, предназначенная для решения этой проблемы. Он предоставляет единый унифицированный API, охватывающий Apple Health, Google Health Connect, WHOOP, Oura, Garmin, Polar, Suunto, Samsung, Strava и других поставщиков, нормализует данные в согласованные схемы и вычисляет показатели здоровья (качество сна, восстановление, напряжение, ВСР, максимальное потребление кислорода) с использованием открытых алгоритмов, которые вы можете проверять и изменять.
Платформа размещается на собственном хостинге без платы за пользователя. Вы владеете инфраструктурой, потоками данных и алгоритмами. Для разработчиков интеграция носимых устройств в приложения здравоохраненияТакой подход сокращает время интеграции с месяцев до дней и устраняет текущие накладные расходы на обслуживание API отдельных поставщиков.
Совместимость медицинских данных с FHIR
Медицинское приложение, которое не может обмениваться данными с системами электронных медицинских записей (EHR), становится все более несостоятельным. Пациенты и врачи ожидают, что данные будут передаваться между системами. Нормативно-правовая база в США и ЕС начинает этого требовать.
FHIR (Ресурсы быстрого взаимодействия в сфере здравоохранения) — это текущий стандарт обмена медицинскими данными. Он определяет спецификацию RESTful API для представления клинических данных в виде структурированных ресурсов: состояний, наблюдений, лекарств, процедур и пациентов. Понимание FHIR необходимо для любого приложения, которому требуется чтение или запись в систему EHR.
Что FHIR дает на практике
Приложение с поддержкой FHIR может считывать записи пациентов с основных платформ EHR, таких как Epic, Cerner и Athenahealth, записывать структурированные клинические наблюдения обратно в записи пациента и участвовать в процессах авторизации SMART on FHIR, где пациенты контролируют, какие приложения могут получить доступ к их данным.
FHIR R4 — текущая целевая версия. Большинство основных поставщиков EHR поддерживают конечные точки R4 для доступа на чтение, причем поддержка записи зависит от поставщика и типа конечной точки. Реализация требует сопоставления ваших внутренних моделей данных с типами ресурсов FHIR, что требует знания как спецификации, так и особенностей реализации FHIR каждого поставщика. Руководство по совместимости FHIR и HL7 является полезной отправной точкой.
Уровень носимых данных и уровень FHIR соединяются естественным образом. Ресурсы наблюдения в FHIR могут представлять количество шагов, частоту сердечных сокращений, продолжительность сна и другие показатели, генерируемые портативными платформами. Архитектура, которая нормализует данные носимых устройств, а затем сопоставляет их с наблюдениями FHIR, создает основу, которая может поддерживать как клинические, так и потребительские продукты из одного и того же конвейера данных.
Работа с партнером по развитию здравоохранения
Разработка приложений для здравоохранения одновременно затрагивает соблюдение требований, клинические рабочие процессы, интеграцию EHR и подключение устройств. Команды, не имеющие предварительного опыта в сфере здравоохранения, часто недооценивают, насколько основа соблюдения требований влияет на остальную часть графика разработки и насколько рано необходимо принимать эти решения.
Есть два момента, когда работа со специалистом наиболее явно меняет результаты. Первый — это анализ архитектуры перед началом разработки, когда еще есть возможность правильно настроить инфраструктуру, модель управления доступом и схему данных. Второй — интеграция EHR, где детали реализации FHIR конкретного поставщика и соответствующие рабочие процессы аутентификации, включающие программное обеспечение для регистрации плательщиков регулярно продлевать сроки для команд без предварительного опыта.
Импульс работает с компаниями цифрового здравоохранения над разработкой приложений, соответствующих требованиям HIPAA, интеграцией EHR, инфраструктурой носимых устройств и внедрением искусственного интеллекта. Команды, создающие свой первый продукт для здравоохранения, больше всего выигрывают от раннего анализа архитектуры, еще до того, как будут приняты решения, от которых зависит соответствие инфраструктуры.
Контрольный список: запуск совместимого приложения для здравоохранения
Перед отправкой выполните следующие действия:
- Соглашение BAA подписано со всеми поставщиками, обрабатывающими ePHI.
- Шифрование всех хранилищ (база данных, объектное хранилище, резервные копии)
- TLS 1.2 или выше применяется для всех соединений.
- Внедрено и протестировано управление доступом на основе ролей.
- Ведение журнала аудита активно и защищено от несанкционированного доступа
- Для аутентификации используются уникальные идентификаторы пользователей; учетные записи администратора требуют MFA
- Таймауты сеансов настроены
- Документированные процедуры уведомления о нарушениях
- Политика хранения данных соответствует требованиям HIPAA (минимум шесть лет для большинства записей)
- Задокументировано обучение персонала HIPAA
- Запланирован тест на проникновение
Соответствие – это не то состояние, которого можно достичь один раз. Это постоянная оперативная практика. Руководство по соблюдению HIPAA для технических директоров HealthTech охватывает уровень управления, который находится над технической реализацией, включая оценки рисков и политическую документацию. Если путем сравнения вы хотите узнать, какие широко доступные инструменты соответствуют требованиям HIPAA, вы наверняка найдете яs Zoom соответствует требованиям HIPAA? Ваш путеводитель по соответствию стеку медицинских технологий пост, представляющий интерес.