Каковы основные стандарты и правила в области информационных технологий для здравоохранения?

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

Тем не менее, несмотря на множество доступных коммуникационных технологий, не существует универсального способа управления и передачи медицинских данных.

Главным препятствием, препятствующим беспрепятственному обмену данными, является беспорядочное принятие стандартов медицинских данных для хранения, кодирования и обмена клинической информацией.

В то время как федеральное правительство продвигается вперед в интеграции систем здравоохранения, необходимость ориентироваться во многих медицинских ИТ-стандартах остается неизменной.

В этом сообщении блога перечислены жизненно важные ИТ-стандарты и правила для здравоохранения [компаний-разработчиков программного обеспечения для здравоохранения] (https://itrexgroup.com/services/healthcare-software-development/) и медицинских организаций, которые следует учитывать при разработке и развертывании технологий здравоохранения. Давайте погрузимся!

Стандарты ИТ в сфере здравоохранения, регулирующие безопасность данных

HIPAA

То, что когда-то начиналось как закон о защите медицинского страхования для рабочих, потерявших работу, HIPAA или [Закон о переносимости и прибыльности медицинского страхования] (https://www.cdc.gov/phlp/publications/topic/hipaa.html), теперь теперь, вероятно, самый известный законодательный акт, защищающий информацию о здравоохранении. Он устанавливает стандарты для хранения, обмена, управления и записи информации о здоровье, позволяющей установить личность (PHI).

Таким образом, любая организация, участвующая в работе с медицинскими данными или предоставляющая программное обеспечение для работы с такими данными, должна обеспечить соблюдение необходимых правил информационных технологий в области здравоохранения. HIPAA состоит из нескольких компонентов:

• Правило безопасности

• Правило конфиденциальности

• Правило уведомления о нарушении

• Правило омнибуса

• Правило исполнения

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

Правило безопасности HIPAA

Правило безопасности описывает меры защиты PHI и состоит из трех частей: технических, физических и административных мер безопасности.

Технические меры безопасности:

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

• Контроль доступа (обязательно) гарантирует, что каждый пользователь, имеющий доступ к PHI, имеет уникальное имя и пароль. Стандарт медицинских данных также требует внедрения процедур, регулирующих выпуск и раскрытие PHI в случае чрезвычайной ситуации.

• Аутентификация ePHI (адресная) требует создания механизмов для подтверждения того, была ли PHI изменена или саботирована.

• Шифрование и дешифрование (адресуемое) устанавливает функциональные возможности для шифрования и дешифрования сообщений, отправляемых за пределы внутреннего сервера.

• Журналы действий и элементы управления аудитом (обязательно) регистрируют попытки доступа к PHI и записывают изменения, внесенные в данные после доступа к ним.

• Автоматический выход из системы (адресный) предотвращает компрометацию личной медицинской информации, когда устройство остается без присмотра.

Физические меры безопасности:

Физические меры защиты сосредоточены на обеспечении физического доступа к PHI и излагают меры по обеспечению безопасности мобильных устройств и рабочих станций. Медицинские организации обязаны осуществлять:

• Контроль доступа к объекту (адресный)

• Руководство по размещению и использованию рабочих станций (обязательно)

• Процедуры использования мобильных устройств (обязательно)

• Политики инвентаризации и оборудования (адресуемые)

Административные меры безопасности:

Административные гарантии устанавливают меры высокого уровня для защиты PHI. Они требуют:

• Проведение оценки рисков (обязательно)

• Внедрение политики управления рисками (обязательно)

• Обучение сотрудников безопасному обращению с данными о здоровье (адресные)

• Разработка плана на случай непредвиденных обстоятельств (обязательно)

• Проверка плана на случай непредвиденных обстоятельств (адресный)

• Ограничение стороннего доступа к данным (обязательно)

• Сообщения об инцидентах безопасности (адресуемые)

Правило конфиденциальности HIPAA:

Правило конфиденциальности стандарта медицинских данных HIPAA описывает меры, касающиеся того, как PHI может использоваться и раскрываться. В соответствии с Правилом конфиденциальности медицинские организации должны:

• Обучите сотрудников, чтобы убедиться, что они знают, какая информация может и не может быть передана за пределы механизма безопасности организации.

• Принимать соответствующие меры для поддержания целостности PHI.

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

Правило уведомления о нарушении HIPAA

Правило уведомления о нарушении требует, чтобы организации здравоохранения уведомляли пациентов о компрометации их PHI. Он также требует, чтобы организации незамедлительно уведомляли Департамент здравоохранения и социальных служб о нарушениях PHI и направляли уведомление в средства массовой информации, если нарушение затрагивает более пятисот пациентов.

ПЕРЕДОВЫЕ ТЕХНОЛОГИИ

В 2009 г. был подписан Закон об информационных технологиях здравоохранения для экономического и клинического здравоохранения. Новое постановление об информационных технологиях здравоохранения направлено на содействие «принятию и осмысленному использованию информационных технологий здравоохранения» и устанавливает более строгое соблюдение HIPAA. Закон требует, чтобы поставщики медицинских услуг проводили проверки безопасности, чтобы выяснить, соблюдают ли они правила конфиденциальности и безопасности HIPAA.

Таким образом, HITECH можно считать подразделением по обеспечению соблюдения HIPAA. Регулирование ИТ в сфере здравоохранения также предоставляет финансовые стимулы для организаций здравоохранения, чтобы свести на нет затраты на переход на EHR и более строгие требования к безопасности данных и штрафы как для поставщиков медицинских услуг, так и для поставщиков программного обеспечения. Согласно HITECH, пациенты должны быть уведомлены о несанкционированном доступе к их данным, а личная медицинская информация может передаваться только безопасными методами.

GDPR

Общий регламент по защите данных — это один из важнейших регламентов в области ИТ в сфере здравоохранения, который контролирует все данные о проблемах в ЕС, и медицинская информация подпадает под его действие.

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

• Назначение специального сотрудника по защите данных

• Оценка рисков, связанных с данными, путем проведения оценки воздействия на защиту данных (DPIA)

• Разработать и внедрить стратегию безопасности данных

• Уведомлять об утечке данных в течение 72 часов.

Правила ИТ в сфере здравоохранения, регулирующие медицинские устройства и программное обеспечение как медицинское устройство (SaMD)

Управление по санитарному надзору за качеством пищевых продуктов и медикаментов

[Управление по санитарному надзору за качеством пищевых продуктов и медикаментов США] (https://www.fda.gov/) регулирует все, от продуктов питания до лекарств и косметики. Что представляет интерес для поставщиков ИТ в сфере здравоохранения, так это то, что организация проверяет и устанавливает медицинские ИТ-стандарты для медицинских устройств и программных приложений, которые функционируют как медицинские устройства. Таким образом, если ваше программное обеспечение используется для выполнения медицинских задач и непреднамеренное использование этого программного обеспечения сопряжено с высокими рисками, вам необходимо получить разрешение FDA.

Пример программного обеспечения, подпадающего под действие правил FDA, может включать в себя приложение, помогающее контролировать надувание и сдувание манжеты для измерения артериального давления, или мобильное приложение, управляющее подачей инсулина с помощью инсулиновой помпы. Вы можете проверить все функции, которые делают ваш продукт одобренным FDA [здесь] (https://www.fda.gov/media/80958/download).

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

• Классифицируйте свое устройство или программное обеспечение.

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

Класс, к которому относится устройство, зависит от его предполагаемого использования и, что более важно, связанных с ним рисков. Класс I охватывает устройства с наименьшим риском, а класс III — с самым высоким. Чтобы определить класс продукта, вы можете перейти непосредственно в [базу данных классификации] (https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfpcd/classification.cfm) и найти устройство по имени.

Кроме того, вы можете перейти к [списку панелей] (https://www.fda.gov/medical-devices/classify-your-medical-device/device-classification-panels) и выполнить поиск по панели или медицинской специальности вашего устройства. принадлежит. Кроме того, поскольку до 74 % устройств класса I не подлежат предварительному уведомлению, проверьте, относится ли это к вашему продукту, выполнив поиск в разделе [Исключения для медицинских устройств] (https://www.accessdata.fda.gov). /scripts/cdrh/cfdocs/cfpcd/315.cfm).

И если вы разрабатываете медицинское устройство или программное обеспечение как медицинское изделие с совершенно новым предполагаемым использованием, мы рекомендуем напрямую связаться с FDA, чтобы обсудить, какие правила информационных технологий в области здравоохранения могут применяться.

• Реализовать необходимые элементы управления

Медицинские изделия I класса требуют осуществления общих средств контроля, а именно:

1. Регистрация учреждения и перечень медицинских устройств (21 CFR Part 807)

1. Регулирование системы качества (21 CFR Part 820)

1. Требования к маркировке (21 CFR Part 801)

1. Отчетность по медицинским устройствам (21 CFR Part 803)

1. Предпродажное уведомление (21 CFR Part 807)

1. Сообщение об исправлениях и удалениях (21 CFR Part 806)

1. Требования об исключении для клинических исследований исследуемых устройств (21 CFR Part 812)

Устройства класса II требуют реализации общих средств контроля, указанных выше, специальных средств контроля и предпродажное уведомление. Устройства класса III требуют внедрения общих средств контроля и [предпродажного утверждения] (https://www.fda.gov/medical-devices/premarket-submissions-selecting-and-preparing-correct-submission/premarket-approval-pma). После того, как вы подготовите необходимую документацию, отправьте ее на рассмотрение. Примечание. По состоянию на начало 2022 года организация разрабатывает [руководство, регулирующее цифровые медицинские технологии для удаленного сбора данных и клинических исследований] (https://www.fda.gov/regulatory-information/search-fda-guidance-documents). /цифровые-медицинские-технологии-удаленный-сбор-данных-клинические-исследования). Руководство еще не доработано, но мы будем следить за ним.

Стандарты структуры контента для здравоохранения

HL7

Разработанный Health Level Seven International, некоммерческой организацией, которая обеспечивает структуру и соответствующие правила в отношении медицинской информации, HL7 занимается обменом медицинскими данными между разрозненными системами здравоохранения. Стандарт является основой EHR. Поскольку EHR — это распределенная система, которая зависит от плавного взаимодействия между несколькими подсистемами для создания конкретного процесса здравоохранения, HL7 служит связующим звеном между этими подсистемами. Существует две версии ИТ-стандарта здравоохранения HL7.

• HL7 версии 2: HL7 v2 подходит для централизованных систем ухода за пациентами и распределенных сред, в которых данные о пациентах хранятся в подсистемах отделений. С подписанием контракта с HITECH версия 2.5.1 HL7 специально выбрана в качестве стандарта для соответствия определенным сертификатам.

• HL7 версии 3: HL7 v3 использует новый подход к обмену клинической информацией, основанный на сообщениях, написанных в синтаксисе XML. Цели HL7 v3 заключались в том, чтобы увеличить распространение стандарта HL7 во всем мире, устранить неопределенность и создать более точный стандарт, свободный от устаревших проблем. Таким образом, по сравнению с HL7 версии 2, HL7 версии 3 имеет согласованную модель данных и четко определенные роли для приложений и сообщений, используемых для различных клинических функций.

HL7 версии 3 был принят в первую очередь для приложений без устаревших требований к связи, без исторического использования HL7 версии 2 или в регионах со строгими государственными требованиями к использованию HL7 v3. Обе версии стандарта медицинских данных сосуществуют, и довольно часто в одном и том же учреждении одновременно развертывается несколько версий стандарта.

Стандарты передачи сообщений

ФХИР

Созданные на основе стандарта HL7 ресурсы Fast Healthcare Interoperability Resources описывают форматы данных и API-интерфейсы для электронных медицинских карт. Стандарт предоставляет набор API-интерфейсов RESTful на основе HTTP, позволяющих поставщикам медицинских услуг обмениваться данными в форматах XML и JSON. Стандарт применим в различных условиях, от мобильных приложений до облачных приложений и обмена данными на основе электронных медицинских карт. Существенным элементом FHIR является ресурс.

В зависимости от типа ресурс может содержать данные о демографических данных пациентов, лекарствах, планах лечения, аллергиях и многом другом.

В сочетании ресурсы образуют разнообразные клинические и административные рабочие процессы. Несмотря на [смешанную реакцию поставщиков медицинских услуг на зрелость FHIR] (https://ehrintelligence.com/news/api-adoption-slow-widespread-fhir-uptake-expected-by-2024), FHIR, по прогнозам, возьмет на себя другие данные здравоохранения. обменные стандарты к 2024 году.

Причина в том, что FHIR предлагает возможность создавать стандартизированные приложения для доступа к медицинским данным — независимо от того, какой EHR лежит в основе инфраструктуры.

DICOM

DICOM, или цифровые изображения и коммуникация в медицине, облегчает обмен медицинскими изображениями и соответствующими данными между программным и аппаратным обеспечением. По сравнению со стандартными файлами изображений, такими как JPEG или TIFF, которые не содержат данных о контексте изображения, файлы DICOM имеют более сложную структуру.

Они содержат метаданные, которые дают представление о пациенте и параметрах получения изображения. Системы, к которым применяется DICOM, разнообразны: от КТ- и МРТ-сканеров до систем архивирования и передачи изображений (PACS) и радиологических информационных систем (RIS).

Ключевые моменты, о которых следует помнить при работе с технологическими решениями для здравоохранения

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

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

Советы поставщикам медицинских технологий:

• Разработка нового технологического решения требует глубокого понимания сложностей и специфики системы здравоохранения. Итак, прежде чем углубляться в дизайн продукта, убедитесь, что понимаете контекст, в котором продукт будет использоваться, включая организационные настройки, соответствующие группы заинтересованных сторон и отношения с заинтересованными сторонами. Также важно оценить риски, связанные с использованием разрабатываемой вами медицинской технологии. Знание рисков поможет вам определить необходимые ИТ-стандарты для здравоохранения.

• Чтобы получить одобрение вашего продукта, вам необходимо предоставить все виды документации в регулирующие органы. Итак, придумывая, проектируя и разрабатывая решение, документируйте процесс разработки. Чтобы определить, какой документации и процедурам вам необходимо следовать, обратитесь к [Министерству здравоохранения и социальных служб, Генеральному инспектору (OIG)] (https://www.hhs.gov/regulations/index.html), [Управление по борьбе с наркотиками (DEA)] (https://www.dea.gov/) и [Управление по санитарному надзору за качеством пищевых продуктов и медикаментов (FDA)] (https://www.fda.gov/).

• Прежде чем выйти на рынок, рассмотрите возможность проведения внешнего тестирования на соответствие. Сотрудничество с поставщиком, который хорошо знает нормативные акты в отношении программного обеспечения для здравоохранения, может помочь снизить риски при выводе вашего продукта на рынок.

Советы для организаций здравоохранения:

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

• Для этого создайте междисциплинарный комитет и назначьте директора по соблюдению нормативных требований (CCO), который будет руководить усилиями по соблюдению нормативных требований.

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

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

• Чтобы максимизировать ваши усилия по соблюдению требований, разверните надежную программу обучения сотрудников и убедитесь, что ваши сотрудники обучены последовательному соблюдению соответствующих медицинских ИТ-стандартов.

• Наконец, убедитесь, что ваши усилия приносят плоды, регулярно оценивая эффективность вашей программы соответствия.

Вместо заключения

По мере того, как медицинские технологии набирают обороты, появляются инновационные технологии, такие как медицинский ИИ, IoMT. -solutions/) и RPA привлекают больше внимания, регулирующие органы работают над разработкой установленных стандартов ИТ для здравоохранения.

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

Итак, если вы хотите разработать решение для здравоохранения, отвечающее всем необходимым требованиям, обратитесь к экспертам ITRex. Мы поможем вам достичь максимальной безопасности и бескомпромиссной безопасности.

Совместно опубликовано [здесь] (https://itrexgroup.com/blog/healthcare-it-standards-and-regulations/)