CMS-0057-F и 1 януари 2027 г.: API на платците върху собствени системи за искове и предварително разрешение

До 1 януари 2027 г. организациите по Medicare Advantage и щатските програми Medicaid и CHIP на принципа „такса за услуга“ трябва да имат работещи четири FHIR API съгласно окончателното правило на CMS за оперативна съвместимост и предварително разрешение (CMS-0057-F): съществуващия Patient Access API, разширен с данни за предварителните разрешения, и новите Provider Access, Payer-to-Payer и Prior Authorization API. Плановете за управлявани грижи по Medicaid, субектите за управлявани грижи по CHIP и издателите на квалифицирани здравни планове (QHP) на федералните борси ги следват от първия си период на тарифиране или планова година, започващи на или след тази дата. Към 16 октомври 2026 г. до нея остават единадесет седмици и CMS не я е отложила.

Оперативната половина на правилото вече се прилага. От 2026 г. засегнатите платци са длъжни да посочват конкретна причина за всеки отказ на предварително разрешение, да се произнасят в определени срокове и да публикуват показатели за предварителните разрешения.

Ако системите ви за искове, управление на използването на услугите (UM) и членове идват от доставчик, който предлага тези четири API, по-голямата част от разработката е негова. Вашата част е конфигурацията, дигитализираните правила за предварително разрешение, уведомленията до членовете и тестовете с партньорите.

Тази статия е за останалите: планове и агенции, чийто механизъм за искове, UM процес или данни за членове са в система, която им принадлежи, независимо дали е разработена вътрешно, променена дотолкова, че вече не може да се надгражда, или е Medicaid Management Information System (MMIS) с десетилетия местни промени. За такива системи никой не доставя готови API. Ние сме инженери, не юристи: тук обясняваме какво правилото изисква от една система, а не как то се прилага към вашите договори.

Датите

Окончателното правило е публикувано във Federal Register на 8 февруари 2024 г. и влиза в сила на 8 април 2024 г. За всеки от четирите API то определя едни и същи срокове за съответствие: „до 1 януари 2027 г. за организациите по MA и щатските програми Medicaid и CHIP FFS; до периода на тарифиране, започващ на или след 1 януари 2027 г., за плановете за управлявани грижи по Medicaid и субектите за управлявани грижи по CHIP; и за плановите години, започващи на или след 1 януари 2027 г., за издателите на QHP на FFE.“

Следователно план за управлявани грижи по Medicaid, чиито периоди на тарифиране започват на 1 юли, има време до 1 юли 2027 г. План с договор по календарна година няма.

CMS продължава да посочва същата дата. Нейната страница за правилото, последно променена на 8 октомври 2026 г., гласи, че „засегнатите платци имат време основно до 1 януари 2027 г., за да изпълнят изискванията за приложни програмни интерфейси (API) в това окончателно правило.“

Задълженията от 2026 г., както ги формулира информационният лист на CMS, са решения „в рамките на 72 часа за ускорени (т.е. спешни) искания и седем календарни дни за стандартни (т.е. неспешни) искания“ (издателите на QHP на борсите са изключени от сроковете), конкретна причина за всеки отказ и публични показатели, като „първоначалният набор от показатели трябва да бъде докладван до 31 март 2026 г.“ Използването на Patient Access API също се докладва на CMS всяка година до 31 март. Ако нещо от това все още не работи, то вече закъснява, а и черпи от същите данни като API.

Лекарствата са извън всичко това. Всички разпоредби за предварително разрешение в CMS-0057-F ги изключват.

Кой е обхванат и кой не

Правилото ги нарича засегнати платци: организациите по Medicare Advantage (MA), щатските програми Medicaid и CHIP на принципа „такса за услуга“ (FFS), плановете за управлявани грижи по Medicaid, субектите за управлявани грижи по CHIP и издателите на QHP на федерално администрираните борси (FFE). Анализът на въздействието му отчита „365 компании майки, включително щатските агенции за Medicaid и CHIP“, които „отговарят за внедряването и поддръжката на три нови API“, и отбелязва, че „75 процента от платците в тази категория имат под 500 служители.“ Много от тях са регионални планове без голям платформен екип.

Не са обхванати, поне не пряко:

• Работодателските планове извън тези програми и Original Medicare. Те не са в списъка на засегнатите платци.
• Доставчиците на медицински услуги. Тяхната страна е мярката Electronic Prior Authorization в програмите Promoting Interoperability на Medicare, която се изпълнява чрез сертифицирана EHR технология. Окончателното правило IPPS за ФГ 2027 от 4 август 2026 г. я превръща в незадължителна бонус мярка за болниците през 2027 г.
• Делегираните UM субекти и администраторите (TPA). Те нямат собствено задължение, но задължението на платеца минава през техните системи. За издателите на QHP правилото повтаря, че те „отговарят за собственото си съответствие и за съответствието на всички делегирани субекти или субекти надолу по веригата.“

Изходите са малко и нито един не помага особено толкова късно. Един щат може да поиска еднократно удължаване с една година за своята програма Medicaid или CHIP FFS, но искането се подава в неговия Advance Planning Document (APD) и трябва да бъде „одобрено преди срока за съответствие.“ Щат, в който поне 90 процента от бенефициерите на Medicaid са в управлявани грижи, може да поиска освобождаване, а издателите на QHP могат да поискат изключение от борсата. За самите планове CMS пише: „Не предложихме удължавания или освобождавания за организациите по MA или плановете за управлявани грижи по Medicaid.“ Щатите могат също да поискат завишено федерално съфинансиране от 90 процента за изграждането на API, одобрявано за всеки отделен случай чрез APD.

Какво трябва да прави всеки API

И четирите зависят от едно нещо, което собствените системи често нямат: предварителното разрешение като структурирани данни с история на статуса. Изградете го веднъж и и четирите ще четат от него.

Patient Access API: добавете предварителните разрешения

Този API работи при вас от 1 януари 2021 г. за искове, контакти и клинични данни. От 2027 г. той трябва да съдържа и всяко предварително разрешение за изделия и услуги: статуса му, датата на одобрение или отказ, кога изтича, одобрените изделия и услуги, конкретна причина при отказ и свързаната структурирана документация от доставчика. Данните трябва да са достъпни „не по-късно от 1 работен ден след“ като платецът получи искането, да се актуализират в рамките на един работен ден след всяка промяна на статуса и да се пазят, докато разрешението е активно, и поне година след последната му промяна.

UM система, която записва решенията като бележки в свободен текст или изпраща статуса само по факс, не може да подава такива данни без промени.

Provider Access API

Доставчиците от мрежата могат да поискат данните на даден пациент: искове и контакти без плащанията към доставчиците и самоучастието, клиничните класове данни на USCDI и информация за предварителните разрешения, за дати на услугата от 1 януари 2016 г. нататък. Платецът отговаря в рамките на един работен ден, но само за пациенти, които е приписал на съответния доставчик и които не са се отказали.

Това изисква три неща, които старата система рядко има. Процес на приписване, който свързва членовете с доставчиците. Възможност за отказ, която членът може да промени по всяко време, с уведомления на ясен език преди първото използване, в рамките на седмица от началото на покритието и всяка година. И групов експорт, защото изискваните стандарти включват FHIR Bulk Data Access за доставчик, който пита за цял списък пациенти.

Payer-to-Payer API

Когато член се присъедини, новият платец иска разрешение (тук съгласието е изрично) и в рамките на седмица от началото на покритието започва да установява предишните и паралелните платци. След като ги има, в рамките на седмица иска данни за пет години: искове и контакти без плащанията и самоучастието, данни по USCDI и предварителните разрешения без отказаните, заедно с неструктурираната им документация. Предишният платец отговаря в рамките на един работен ден. При паралелно покритие обменът се повтаря поне веднъж на тримесечие.

Трудната част не е изходящият отговор. Тя е да приемете данни от платци, с които никога не сте тествали, и да ги включите в записа на члена, както изисква правилото.

Prior Authorization API

Това е API, който стига до ядрото на UM. Той трябва да изброява покритите изделия и услуги, за които се изисква предварително разрешение, да посочва необходимата документация за всяко от тях, да поддържа съвместими с HIPAA искане и отговор и да съобщава дали платецът е одобрил (с крайната дата), отказал (с конкретна причина) или се нуждае от още информация.

Тук CMS препоръчва, но не изисква, три ръководства за внедряване на Da Vinci: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) и Prior Authorization Support (PAS). На практика правилата ви за покритие и въпросниците за документация трябва да станат машинночетими, а не PDF наръчник с политики. Платците в проучването на WEDI поставят „дигитализирането на политиките за предварително разрешение“ сред трите си най-големи предизвикателства.

По самата трансакция HHS даде свобода на платците. На 28 февруари 2024 г. обяви, че няма да прилага санкции: според CMS нейната National Standards Group „няма да предприема действия по прилагане на HIPAA Administrative Simplification срещу обхванатите от HIPAA субекти, които решат да не използват стандарта X12 278 като част от електронен процес за предварително разрешение по FHIR.“ Можете да изградите само FHIR или FHIR с X12 и да запазите паралелно трансакция само с X12.

Стандартите

Изискваните стандарти са HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access и OpenID Connect Core; платците могат доброволно да използват по-нови версии при определени условия. Правилото от 2024 г. посочва US Core 3.1.1 и SMART App Launch 1.0.0 с краен срок 1 януари 2026 г., така че уточнете към кои версии изграждате, преди някой да е започнал съпоставянето на данните.

Къде собствените системи обикновено не достигат

Според изискванията на правилото това са пропуските, които да потърсите първо:

• Предварителното разрешение като запис, а не като документ. Статусът, времевите отпечатъци, кодовете за причина на отказ и крайната дата трябва да са полета, които се записват при промяна, с история. Решение, изпратено по факс, се нуждае от структуриран двойник.
• Правилата за покритие. Кои услуги изискват разрешение и каква документация е нужна за всяка трябва да са данни, които API може да връща. В много планове те стоят в PDF документи с политики и в главите на проверяващите.
• Исковете във FHIR. Исковете и контактите трябва да излизат като FHIR ресурси, като плащанията и самоучастието се премахват за доставчиците и другите платци, но се запазват за члена.
• Самоличност и история на члена. Съпоставянето на данните от друг платец с вашия член и установяването на предишните платци на нов член изискват демографски данни и история на покритието, които може да не държите на едно място.
• Състоянието на съгласието. Възможност за отказ при Provider Access и изрично съгласие при Payer-to-Payer, всяко от които може да се промени по всяко време и се проверява при всяко искане. Щатът трябва също да предаде изричното съгласие на бенефициера на неговите планове за управлявани грижи по Medicaid.
• Срокът от един работен ден. Нощна групова обработка на мейнфрейм е достатъчна за някои данни и твърде бавна за други. Измервайте времето от решението до API, а не само дали API отговаря.
• Делегираните доставчици. Ако решенията ги взема делегиран UM доставчик, данните му трябва да стигат до вас навреме за вашето задължение от един работен ден. Проучването на WEDI от февруари 2026 г. поставя на първо място сред предизвикателствата на платците „делегираните трети страни, които срещат трудности при свързването с различни системи“.

Докъде е стигнал секторът

Проучването на WEDI от февруари 2026 г., публикувано на 10 март 2026 г., установява, че по изискванията за API „10% все още не са започнали работа“ при 33% през октомври 2025 г. То отчита и „забележимо увеличение на прогнозните разходи над 5 милиона долара от 15% (окт. ’25) до 25% (февр. ’26).“ Извадката е малка: 86 отговора, 52% от тях от платци. Приемете го като сигнал, а не като преброяване.

План за единадесет седмици до 1 януари 2027 г.

От средата на октомври организация по MA или щатска програма FFS разполага с около единадесет седмици. Това не стига, за да се изградят четири API от нулата, така че планът е за последователността и за това какво можете да покажете в първия ден.

1. Тази седмица: потвърдете датата си и отправната си точка. 1 януари или по-късен период на тарифиране или планова година? Избройте какво вече работи: Patient Access и Provider Directory API, показателите за 2026 г., причините за отказ.
2. Седмици 1 до 2: съпоставете всеки елемент от данните с източника му. За всеки API запишете коя система държи данните днес (искове, UM, записване, мрежа от доставчици, клинични данни) и колко актуални са те.
3. Седмици 1 до 3: решете къде ще бъде слоят FHIR. FHIR сървър или фасада пред старите системи, захранвани от събития за промяна или чести извличания, обикновено е по-бързо решение, отколкото да научите основната система да говори FHIR. Времето отива в съпоставянето и захранващите потоци.
4. Седмици 2 до 7: изградете първо общите части. Записа за предварително разрешение, съгласието и приписването, съпоставянето на членове. И четирите API зависят от тях.
5. Седмици 4 до 9: изградете API. Допълненията към Patient Access, Provider Access с групов експорт, Payer-to-Payer в двете посоки и Prior Authorization API със заредени правила за покритие.
6. Седмици 8 до 11: тествайте с реални партньори. Доставчика на EHR на някой доставчик на услуги, друг платец, вашия делегиран UM доставчик. Тествайте промени в съгласието, отказ с причината му и промяна на статуса, която стига до члена в рамките на един работен ден.
7. 1 януари 2027 г.: пуснете и измервайте. Следете закъснението спрямо правилата за един работен ден от първия ден и водете датиран списък на недовършеното.

Ако единадесет седмици не стигат, обсъдете това с екипа си по съответствие и с юристите сега, а не през декември, с план, който показва какво ще работи на 1 януари и какво следва и кога.

План за управлявани грижи по Medicaid с период на тарифиране от 1 юли 2027 г. или издател на QHP с по-късна планова година може да следва същите стъпки с повече време. Въпреки това започнете сега: платците и доставчиците, с които ще тествате, започват работа на 1 януари.

Какво още може да се промени

CMS-0062-P. На 14 април 2026 г. CMS публикува проект на последващо правило. То би направило задължителни препоръчваните в момента ръководства за внедряване от 1 октомври 2027 г., би добавило лекарствата към електронното предварително разрешение от същата дата и би накарало HHS да приеме FHIR като стандарт по HIPAA за трансакциите за предварително разрешение вместо X12 278. За съществуващите срокове проектът гласи: „Това предложение не би променило тези срокове за съответствие.“ Коментарите са приключили на 15 юни 2026 г. и към 16 октомври 2026 г. във Federal Register не е публикувано окончателно правило. Изграждайте според правилото от 2024 г. и дръжте версиите на ръководствата на едно конфигурируемо място.

Версиите. Ръководствата на Da Vinci продължават да се променят. Окончателното правило IPPS за ФГ 2027 отбелязва, че EHR системите, сертифицирани по новите критерии на ONC за предварително разрешение, „ще изискват използването на версия 2.2 на Da Vinci IG.“ Това са системите, с които ще комуникира вашият Prior Authorization API.

Нищо от това не е причина да чакате. Правилото е окончателно, датите са в текста на регламента и CMS ги повтори на 8 октомври.

Къде да потърсите помощ

Работим по системите зад API: FHIR съпоставяне на данни за искове, контакти и разрешения, потоци от промени от по-стари платформи за искове и UM, логика за съгласие и приписване и тестовете, които показват, че правилата за един работен ден се спазват. Нашата услуга за поддръжка на наследени системи е мястото, откъдето започва тази работа, когато основната система е стара или хората, които са я изградили, са напуснали, а ако срокът се падне по средата на подмяна на платформа, вижте модернизация на ERP.

Ако вашата платформа за искове или UM е от тези, за които никой доставчик няма да предложи тези API, пишете на office@c9group.dev. Ние сме инженери, не юристи в здравеопазването: въпросите за обхвата и договорите са за вашите юристи, а ние изграждаме според техния отговор.