Предлагаемое правило ONC будет связывать людей с их помощью

Сегодня я рад объявить о выпуске предложенного ONC правила для реализации положений Раздела IV Закона о лечении 21 st века (Закон о лечении). Мы также выпустили серию образовательных ресурсов, посвященных областям правила, включая доступ для пациентов, блокировку информации, новые условия сертификации и роль прикладных программных интерфейсов (API), которые будут играть в новой информационной технологии здравоохранения (IT Health). пейзаж, созданный Законом о лечении. В течение следующих нескольких недель мы проведем несколько открытых веб-семинаров, на которых подробно расскажем о предлагаемом правиле.

Давайте поговорим немного об этом мире API и о том, что он значит для людей в этой стране. Американская общественность наводнена программными приложениями. Когда я езжу в метро, ​​по крайней мере половина моих товарищей по водителю сидят за своими смартфонами. Я предполагаю, что только у некоторых из них есть приложения, которые позволяют им заниматься своим здоровьем. Что потребуется, чтобы получить ориентированные на пациента приложения, которые помогут нам управлять здоровьем и обслуживанием на наших смартфонах?

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

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

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

Конгресс потребовал от ИТ-разработчиков здравоохранения, участвующих в программе сертификации ONC Health IT Certification Program (Программа сертификации), публиковать API-интерфейсы и обеспечивать доступ, обмен и использование медицинской информации, полученной с помощью таких технологий, без особых усилий. Предлагаемое нами правило направлено на обеспечение безопасного и беспрепятственного доступа пациентов к информации о своем здоровье через API-интерфейсы и облегчит пациентам использование приложений для получения электронной медицинской информации дома или в кабинете врача.

API-интерфейсы теперь являются центральным элементом любого обмена данными между компьютерами. API-интерфейсы — это программные протоколы, которые работают с оборудованием и программным обеспечением Интернета, чтобы позволить компьютерам общаться друг с другом. Но одного лишь API недостаточно. API, созданные без стандартов, вынуждают разработчиков изучать новые инструменты для каждого продукта EHR. API-интерфейсы, созданные без стандартов, могут заставить пациентов и разработчиков быть привязанными к конкретному поставщику медицинских услуг или разработчику программного обеспечения EHR. Можете ли вы представить себе, если бы у каждой железной дороги в США была разная ширина колеи? Так было на протяжении большей части 1800-х годов, пока Конгресс не потребовал во время Гражданской войны, чтобы трансконтинентальная железная дорога была построена с одной стандартной шириной колеи.

Законом о лечении Конгресс постановил, что API можно использовать «без особых усилий». Возникает вопрос: «Что является нашим эквивалентом стандартного калибра для медицинских API?» Несмотря на то, что существует множество соответствующих медицинских стандартов для подключения лабораторий, изображений, систем обработки заявок и других частей мира поставщиков, когда мы смотрим на экономику приложений и четкие тенденции в современных вычислениях, кажется, что один подход API явно проявляется — Стандарты Fast Healthcare Interoperability Resources (FHIR®) Health Level Seven’s (HL7®).

Программа сертификации была разработана для тестирования и сертификации ИТ в сфере здравоохранения, например API-интерфейсов, на соответствие согласованным стандартам и критериям сертификации в целях установления и продвижения взаимодействия на рынке здравоохранения. В предлагаемом нами правиле мы предлагаем принять FHIR в качестве стандарта, по которому разработчики должны сертифицировать свои API-интерфейсы, и предложить язык для поддержки экосистемы для безопасного потока информации. Мы считаем, что такой подход может привести к появлению стандартных отраслевых интерфейсов — интерфейсов, с помощью которых разработчики приложений могут разрабатывать эффективные приложения, использующие технологию API, без особых усилий для доступа к данным пациента.

Возникает вопрос: «Что является нашим эквивалентом стандартного индикатора для медицинских API-интерфейсов?»

Важно понимать, что «открытые API-интерфейсы» в здравоохранении используют ту же самую современную систему безопасности, которую используют другие отрасли, чтобы пациенты могли строго контролировать, какие приложения могут получать доступ к их данным и использовать их. Например, стандарты OAuth 2 требуют от пациента определенных действий для авторизации приложения, чтобы получить свои данные в соответствии с процессами авторизации, позволяя пациентам контролировать свои данные с индивидуализированным конкретным согласием. Хотя API-интерфейсы будут защищены и будут соответствовать индивидуальным предпочтениям пациентов, то как эти данные будут защищены после того, как они попадут в приложение, — это совсем другое дело.

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

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

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

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

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

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

Большая часть современной американской системы здравоохранения зачастую сложна и непрозрачна. Закон Конгресса о лечении 21 века и современные компьютеры позволяют нам пересмотреть многие предположения о том, какой должна быть медицинская помощь. Предложенное ONC правило требовать безопасные открытые API, определять разумные и необходимые действия, которые являются исключениями для блокировки информации, и обновлять программу сертификации, может служить одним из важнейших шагов, необходимых для повышения прозрачности и доступности здравоохранения для пациентов.