Недавно я делал ежегодную прививку от гриппа в местной аптеке, и этот визит послужил микрокосмом ИТ-технологий здравоохранения на передовой. Моя прививка прошла беспрепятственно как в онлайн-системе аптеки, так и в государственном ГИЭ, ИТ работало как положено. Тем временем другая покупательница вела долгую дискуссию с фармацевтом по поводу несоответствий в продолжительности выписанных ей лекарств от хронических заболеваний, вызванных компьютеризированными правилами оплаты и, как следствие, путаницы в отношении доплаты. Чтобы прийти к какому-то квазиразумному решению, потребовалось несколько обращений к компьютеру фармацевта. Здесь явно отсутствовала современная совместимость. Можно легко представить себе несколько API-связей между EHR этого пациента, системой электронных рецептов, PBM и плательщиком, которые могли бы устранить это разочаровывающее взаимодействие.
Сегодня клиническая и финансовая сложность американской системы здравоохранения требует компьютеризированных коммуникаций, которые обеспечивают эффективное обслуживание без вмешательства человека. В любой другой крупной сфере услуг с этим разобрались: например, когда вам в последний раз приходилось разговаривать с кем-то в Amazon? Возникает вопрос: почему здравоохранение не достигло такого же уровня бесшовного цифрового взаимодействия?
Наша система оплаты была разработана так, чтобы отделить предоставление медицинской помощи от оплаты этой помощи – не буквально с рождения, а после принятия в 1942 году Закона о стабилизации во время Второй мировой войны, который сделал здравоохранение до уплаты налогов и, следовательно, оплачиваемым работодателем. Исключение пациента из числа прямых покупателей медицинских услуг привело к длительному разрыву между оказанием клинической помощи и рыночной дисциплиной в ценообразовании и доступе. Результатом стала балканизация ИТ в здравоохранении, поскольку участники экономики оптимизируют свои собственные условия возмещения расходов, а не приносят пользу пациентам. Сейчас мы видим, как крупные системы оказания услуг консолидируются, чтобы получить ценовое влияние на плательщиков, ПБМ ведут себя как ПБМ, а плательщики пытаются найти баланс между объемом и «ценностной» медицинской помощью (ценностью для плательщика, а не обязательно для пациента). Многие из этих бизнес-моделей фактически полагаются на фрагментированные ИТ для поддержания непрозрачной и порой антиконкурентной деловой практики.
Между тем, в остальной части нашей потребительской жизни конкуренция процветает за счет эффективных API, которые обеспечивают мгновенное обслуживание и связь – будь то покупки, путешествия, финансы или развлечения. В здравоохранении те же самые цифровые ожидания все чаще реализуются посредством государственной политики. 21ул. Например, Закон Century Cures Act от 2016 года требует API, которые обеспечивают доступ «без особых усилий» и запрещает «блокировку информации» между провайдерами, поставщиками EHR и сетями. Основываясь на этом фундаменте, агентства HHS, в том числе ONC и CMS, издали множество нормативных актов – от Окончательного правила Закона о лечении ONC 2020 года до правил CMS 9115 и 0057, а теперь и требований HTI4 – все из которых способствуют подлинному взаимодействию контрагентов посредством стандартизированных API.
В то время как некоторые действующие лица спорят и лоббируют законы и правила, требующие современной совместимости, более важной динамикой совместимости будут двойные клещи: общественное недовольство расходами на здравоохранение и растущая разница между ожиданиями потребителей, обусловленными мобильными телефонами, и работой системы здравоохранения. Можно ли вообще покупать средства по уходу на своем телефоне? Можно ли обжаловать неблагоприятное решение о предварительной авторизации приложения? Можете ли вы вести содержательный разговор со своим плательщиком с помощью приложения?
Говоря как пациент, я провожу около ста часов в год в режиме ожидания, пытаясь связаться с «колл-центрами». Слышать повторяющиеся сообщения «Мистер Дональд, мы ценим ваше терпение, пока мы…» каждые 15 минут от сотрудника аутсорсингового колл-центра на другом конце планеты, манипулирующего двумя или тремя другими клиентами, также находящимися в режиме ожидания, не приносит удовлетворения. Это особенно верно, поскольку, как инсайдер, я знаю, что лежащий в основе разговор является ненужным как с клинической, так и с экономической точки зрения.
Пока мы ждем реформы платежей и следующего пакета требований к совместимости для устранения подобных взаимодействий, поставщикам и плательщикам будет важно подумать о своей роли в современном цифровом мире, в котором все больше внимания уделяется API. Будь то планы с высокой франшизой, увеличение доплаты или требования к поставщикам и плательщикам включать приложения, потребители будут все чаще получать и использовать выбор. API затрагивают поставщиков и плательщиков во взаимодействиях поставщик-плательщик и плательщик-плательщик, поскольку у агентств HHS (CMS и ASTP/ONC) есть требования к ним, которые появятся чуть больше чем через год.
API, лежащие в основе современных коммуникаций, становятся все более доступными. Хорошо написанный код и хорошо спроектированное корпоративное программное обеспечение должны легко поддерживать множество бизнес-стратегий, основанных на API. Современная совместимость построена на RESTful API и JSON, а в здравоохранении — на конкретном экземпляре FHIR. Это хорошо изученные и широко применяемые технологии; действительно, вся экономика приложений для мобильных телефонов работает на RESTful API и JSON. Мы должны работать над устранением факсов и эквивалентных (или худших) технологий, таких как TEFCA, которые в конечном итоге предназначены для создания разногласий. Современные алгоритмы могут добиться гораздо большего, чем трения при распределении медицинской помощи.
Стратегии API, ориентированные на потребителя, сложны, и в конечном итоге их придется интегрировать с концепцией «подключенного я», поскольку пациенты становятся все более заинтересованы в поддержании своего здоровья. Однако контракты на основе стоимости поставщика-плательщика могут сразу же получить выгоду от современных API-интерфейсов RESTful, которые обеспечивают совместную связь между плательщиками и поставщиками в режиме реального времени или почти в реальном времени.
На фоне продолжающейся политической драмы о том, как платить за здравоохранение, многие федеральные политики, включая Medicare Advantage и управляемую Medicaid, вынуждают принимать активные решения по распределению медицинской помощи. Механизмы дифференцированной оплаты – проектирование сети, управление делами, измерение качества и предварительное разрешение – все больше полагаются на API, способные обрабатывать не только данные о претензиях, но, что более важно, клинические данные, имеющие решающее значение для принятия разумных решений. API-интерфейсы обеспечат и будут обеспечивать бесперебойную связь.
Здравоохранение США: добро пожаловать в современный мир, в котором API ориентирован на приоритет.
Фото: неварпп, Getty Images
Дональд Ракер, доктор медицины является директором по стратегии компании 1upHealthгде он помогает определить направление текущих инноваций компании в области вычислений с поддержкой FHIR и донести их до клиентов, чтобы помочь им удовлетворить растущие клинические, технические требования и требования к возмещению расходов на современные данные. До работы в 1upHealth д-р Ракер был национальным координатором по информационным технологиям здравоохранения в Министерстве здравоохранения и социальных служб США, где он руководил разработкой федеральной ИТ-стратегии здравоохранения и координировал федеральную политику, стандарты, программы и инвестиции в области ИТ в сфере здравоохранения. В рамках своего пребывания в ONC он руководил разработкой и изданием Заключительного правила Закона о лекарствах 21-го века, важнейшего мандата, поддерживающего доступ пациентов и совместимость медицинских данных.
Это сообщение появляется через Влиятельные лица MedCity программа. Любой может опубликовать свой взгляд на бизнес и инновации в здравоохранении в MedCity News через влиятельных лиц MedCity. Нажмите здесь, чтобы узнать, как.
2025-12-04 14:24:00
1765071157
#Современная #совместимость #как #API #могут #исцелить #фрагментированную #систему
По теме

