CMS-0057-F ve 1 Ocak 2027: Şirket İçi Talep ve Ön Onay Sistemlerinde Payer API'leri

1 Ocak 2027'ye kadar Medicare Advantage kuruluşları ile eyaletlerin hizmet başına ödeme (fee-for-service) esaslı Medicaid ve CHIP programları, CMS Interoperability and Prior Authorization nihai kuralı (CMS-0057-F) kapsamında dört FHIR API'sini çalışır durumda tutmak zorunda: ön onay verilerini de taşıyacak şekilde genişletilen mevcut Patient Access API ile yeni Provider Access, Payer-to-Payer ve Prior Authorization API'leri. Medicaid yönetilen bakım planları, CHIP yönetilen bakım kuruluşları ve federal borsalardaki Qualified Health Plan sağlayıcıları ise bu tarihte veya sonrasında başlayan ilk derecelendirme dönemlerinden ya da plan yıllarından itibaren bu yükümlülüğe tabi. 16 Ekim 2026 itibarıyla bu tarihe on bir hafta kaldı ve CMS tarihi ertelemedi.

Kuralın operasyonel yarısı zaten yürürlükte. Kapsamdaki ödeyiciler 2026'dan bu yana reddedilen her ön onay talebi için somut bir gerekçe vermek, belirlenmiş süreler içinde karar vermek ve ön onay metriklerini yayımlamak zorunda.

Talep, kullanım yönetimi (UM) ve üye sistemleriniz bu dört API'yi hazır sunan bir tedarikçiden geliyorsa, geliştirme işinin büyük kısmı tedarikçiye düşer. Size kalan kısım yapılandırma, ön onay kurallarının dijitalleştirilmesi, üye bildirimleri ve iş ortaklarıyla testlerdir.

Bu makale geri kalanlar için: talep motoru, UM iş akışı veya üye verisi kendilerine ait bir sistemde duran planlar ve kurumlar. Bu sistem şirket içinde geliştirilmiş, güncellenemeyecek ölçüde özelleştirilmiş ya da onlarca yıllık yerel değişiklik birikmiş bir Medicaid Management Information System (MMIS) olabilir. Bu sistemler için API'leri kimse hazır getirmiyor. Biz hukukçu değil, mühendisiz: burada kuralın bir sistemden ne yapmasını istediğini anlatıyoruz, sözleşmelerinize nasıl uygulandığını değil.

Tarihler

Nihai kural 8 Şubat 2024'te Federal Register'da yayımlandı ve 8 Nisan 2024'te yürürlüğe girdi. Dört API'nin her biri için aynı uyum tarihlerini belirliyor: MA kuruluşları ile eyaletlerin Medicaid ve CHIP FFS programları için “1 Ocak 2027'ye kadar; Medicaid yönetilen bakım planları ve CHIP yönetilen bakım kuruluşları için 1 Ocak 2027'de veya sonrasında başlayan derecelendirme döneminden itibaren; FFE'lerdeki QHP sağlayıcıları için 1 Ocak 2027'de veya sonrasında başlayan plan yıllarından itibaren.”

Dolayısıyla derecelendirme dönemleri 1 Temmuz'da başlayan bir Medicaid yönetilen bakım planının 1 Temmuz 2027'ye kadar süresi var. Takvim yılı esaslı sözleşmesi olan bir planın ise yok.

CMS hâlâ aynı tarihi veriyor. Kurala ilişkin, en son 8 Ekim 2026'da güncellenen politika sayfası, “kapsamdaki ödeyicilerin bu nihai kuraldaki uygulama programlama arayüzü (API) gerekliliklerini karşılamak için ağırlıklı olarak 1 Ocak 2027'ye kadar süreleri olduğunu” belirtiyor.

CMS bilgi notunun ifadesiyle 2026 yükümlülükleri şunlar: “ivedi (yani acil) taleplerde 72 saat, standart (yani acil olmayan) taleplerde yedi takvim günü içinde” karar (borsalardaki QHP sağlayıcıları bu sürelerin dışında), her ret için somut bir gerekçe ve kamuya açık metrikler; bu metrikler için “ilk metrik setinin 31 Mart 2026'ya kadar raporlanması gerekir.” Patient Access API kullanımı da her yıl 31 Mart'a kadar CMS'e raporlanıyor. Bunlardan herhangi biri henüz çalışmıyorsa zaten gecikmiş durumdadır ve API'lerle aynı verilerden beslenir.

İlaçlar bunların hiçbirine dahil değil. CMS-0057-F'deki ön onay hükümlerinin tamamı ilaçları kapsam dışında bırakıyor.

Kimler Kapsamda, Kimler Değil

Kural bunları kapsamdaki ödeyiciler (impacted payers) olarak adlandırıyor: Medicare Advantage (MA) kuruluşları, eyaletlerin hizmet başına ödemeli (FFS) Medicaid ve CHIP programları, Medicaid yönetilen bakım planları, CHIP yönetilen bakım kuruluşları ve Federally-facilitated Exchanges (FFE) üzerindeki QHP sağlayıcıları. Kuralın etki analizi, “üç yeni API'yi uygulamak ve sürdürmekten sorumlu” olan “eyalet Medicaid ve CHIP kurumları dahil 365 ana kuruluş” sayıyor ve “bu kategorideki ödeyicilerin yüzde 75'inin 500'den az çalışanı olduğunu” not ediyor. Bunların çoğu büyük bir platform ekibi olmayan bölgesel planlar.

Kapsam dışında olanlar (en azından doğrudan):

• Bu programların dışındaki işveren planları ve Original Medicare. Kapsamdaki ödeyiciler listesinde yer almıyorlar.
• Sağlık hizmeti sunucuları. Onların tarafı, Medicare'in Promoting Interoperability programlarındaki Electronic Prior Authorization ölçütü ve bu ölçüt sertifikalı EHR teknolojisiyle karşılanıyor. 4 Ağustos 2026 tarihli FY 2027 IPPS nihai kuralı, bunu hastaneler için 2027'de isteğe bağlı bir bonus ölçütü haline getirdi.
• Yetki devredilen UM kuruluşları ve TPA'lar. Kendilerine ait bir yükümlülükleri yok, ancak ödeyicinin yükümlülüğü onların sistemlerinden geçiyor. Kural, QHP sağlayıcıları için “kendi uyumlarından ve yetki devredilen veya alt kademedeki tüm kuruluşların uyumundan sorumlu oldukları” ifadesini yineliyor.

Çıkış yolu az ve bu kadar geç bir aşamada hiçbiri pek işe yaramıyor. Bir eyalet, Medicaid veya CHIP FFS programı için bir defaya mahsus bir yıllık uzatma talep edebilir; ancak talep Advance Planning Document (APD) içinde yapılmalı ve “uyum tarihinden önce onaylanmalıdır.” Medicaid yararlanıcılarının en az yüzde 90'ı yönetilen bakımda olan bir eyalet muafiyet talep edebilir; QHP sağlayıcıları da borsadan istisna isteyebilir. Planların kendisi hakkında ise CMS şunu yazdı: “MA kuruluşları veya Medicaid yönetilen bakım planları için uzatma ya da muafiyet önermedik.” Eyaletler ayrıca API'lerin geliştirilmesi için yüzde 90 oranında artırılmış federal eşleştirme fonu talep edebilir; bu fon APD üzerinden vaka bazında onaylanıyor.

Her API'nin Ne Yapması Gerekiyor

Dördü de özel geliştirilmiş sistemlerde çoğu zaman eksik olan tek bir şeye dayanıyor: durum geçmişiyle birlikte yapılandırılmış veri olarak tutulan ön onay. Bunu bir kez kurduğunuzda dört API de buradan okur.

Patient Access API: ön onayların eklenmesi

Bu API'yi talepler, karşılaşmalar (encounters) ve klinik veriler için 1 Ocak 2021'den beri çalıştırıyorsunuz. 2027'den itibaren ürün ve hizmetlere ilişkin her ön onayı da taşıması gerekiyor: durumu, onaylandığı veya reddedildiği tarih, bitiş tarihi, onaylanan ürün ve hizmetler, reddedildiyse somut gerekçe ve sağlık hizmeti sunucusundan gelen ilgili yapılandırılmış belgeler. Veriler, ödeyicinin talebi almasından “en geç 1 iş günü sonra” erişilebilir olmalı, her durum değişikliğinden sonra bir iş günü içinde güncellenmeli ve onay geçerli olduğu sürece ve son değişikliğinden sonra en az bir yıl saklanmalı.

Kararları serbest metin notları olarak kaydeden ya da durumu yalnızca faksla gönderen bir UM sistemi, değişiklik yapılmadan bu veriyi sağlayamaz.

Provider Access API

Ağ içi sağlık hizmeti sunucuları bir hastanın verilerini talep edebilir: sunucu ödeme bildirimleri (remittance) ve maliyet paylaşımı bilgileri çıkarılmış talepler ve karşılaşmalar, USCDI klinik veri sınıfları ve ön onay bilgileri; hepsi 1 Ocak 2016'dan itibaren hizmet tarihleri için. Ödeyici bir iş günü içinde yanıt verir, ancak yalnızca o sunucuya atadığı ve paylaşımı reddetmemiş (opt-out yapmamış) hastalar için.

Bu da eski bir sistemde nadiren bulunan üç şey gerektiriyor. Üyeleri sağlık hizmeti sunucularıyla eşleştiren bir atama (attribution) süreci. Üyenin istediği zaman değiştirebileceği bir ret (opt-out) seçeneği; ilk kullanımdan önce, kapsamın başlamasından sonraki bir hafta içinde ve her yıl gönderilen sade dilde bildirimlerle birlikte. Ve toplu dışa aktarım, çünkü zorunlu standartlar arasında bütün bir hasta grubunu soran sunucular için FHIR Bulk Data Access da var.

Payer-to-Payer API

Bir üye katıldığında yeni ödeyici izin ister (burada açık onay, yani opt-in esastır) ve kapsamın başlamasından sonraki bir hafta içinde önceki ve eş zamanlı ödeyicileri belirlemeye başlar. Bunları belirledikten sonra bir hafta içinde beş yıllık veri talep eder: ödeme bildirimi ve maliyet paylaşımı bilgileri çıkarılmış talepler ve karşılaşmalar, USCDI verileri ve reddedilenler dışındaki ön onaylar ile bunların yapılandırılmamış belgeleri. Önceki ödeyici bir iş günü içinde yanıt verir. Eş zamanlı kapsam varsa bu alışveriş en az üç ayda bir tekrarlanır.

Zor olan giden yanıt değil. Zor olan, daha önce hiç test etmediğiniz ödeyicilerden gelen verileri almak ve kuralın gerektirdiği şekilde üye kaydınıza işlemek.

Prior Authorization API

UM çekirdeğine uzanan API bu. Ön onay gerektiren kapsam içi ürün ve hizmetleri listelemeli, her biri için gereken belgeleri belirtmeli, HIPAA uyumlu bir talep ve yanıtı desteklemeli ve ödeyicinin talebi onayladığını (bitiş tarihiyle), reddettiğini (somut gerekçeyle) ya da ek bilgiye ihtiyaç duyduğunu bildirmeli.

CMS burada üç Da Vinci uygulama kılavuzunu öneriyor ama zorunlu tutmuyor: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) ve Prior Authorization Support (PAS). Pratikte kapsam kurallarınızın ve belge soru formlarınızın PDF bir politika kılavuzu değil, makine tarafından okunabilir hale gelmesi gerekiyor. WEDI anketindeki ödeyiciler “ön onay politikalarının dijitalleştirilmesini” en büyük üç zorluk arasında gösterdi.

İşlemin kendisi konusunda HHS ödeyicilere esneklik tanıdı. 28 Şubat 2024'te uygulamada takdir yetkisi kullanacağını duyurdu: CMS'e göre National Standards Group, “elektronik bir FHIR ön onay sürecinin parçası olarak X12 278 standardını kullanmamayı tercih eden HIPAA kapsamındaki kuruluşlara karşı HIPAA Administrative Simplification yaptırımı uygulamayacak.” Yalnızca FHIR ile ya da FHIR ve X12 birlikte geliştirebilir, yanında yalnızca X12 kullanan bir işlemi de sürdürebilirsiniz.

Standartlar

Zorunlu standartlar HL7 FHIR Release 4.0.1, US Core, SMART App Launch, Bulk Data Access ve OpenID Connect Core; ödeyiciler belirli koşullarla güncel sürümleri gönüllü olarak kullanabilir. 2024 kuralı US Core 3.1.1 ve SMART App Launch 1.0.0 sürümlerini 1 Ocak 2026 geçerlilik sonu tarihiyle listeliyordu; bu yüzden kimse eşleme (mapping) yazmaya başlamadan hangi sürümlere göre geliştireceğinizi netleştirin.

Şirket İçi Sistemler Genellikle Nerede Yetersiz Kalıyor

Kuralın istediklerine bakınca önce aranması gereken eksikler şunlar:

• Belge değil, kayıt olarak ön onay. Durum, zaman damgaları, ret gerekçesi kodları ve bitiş tarihi; değiştikçe yazılan ve geçmişi tutulan alanlar olmalı. Faksla iletilen bir kararın yapılandırılmış bir karşılığı olmalı.
• Kapsam kuralları. Hangi hizmetlerin onay gerektirdiği ve her birinin hangi belgeleri istediği, API'nin sunabileceği veriler olmalı. Birçok planda bu bilgi politika PDF'lerinde ve değerlendiricilerin aklında duruyor.
• FHIR olarak talepler. Talepler ve karşılaşmalar FHIR kaynakları olarak dışarı aktarılmalı; ödeme bildirimi ve maliyet paylaşımı bilgileri sağlık hizmeti sunucuları ve diğer ödeyiciler için çıkarılmalı, üye için korunmalı.
• Üye kimliği ve geçmişi. Başka bir ödeyicinin verilerini üyenizle eşleştirmek ve yeni bir üyenin önceki ödeyicilerini bulmak, tek bir yerde tutmuyor olabileceğiniz demografik bilgileri ve kapsam geçmişini gerektirir.
• Onay durumu. Provider Access için bir ret (opt-out), Payer-to-Payer için bir açık onay (opt-in); her biri istendiği zaman değiştirilebilir ve her talepte kontrol edilir. Bir eyalet ayrıca yararlanıcının açık onayını o kişinin Medicaid yönetilen bakım planlarına iletmek zorunda.
• Bir iş günü saati. Gece çalışan bir ana bilgisayar (mainframe) toplu işi bazı veriler için yeterli, bazıları için fazla yavaş. Yalnızca API'nin yanıt verip vermediğini değil, karardan API'ye kadar geçen süreyi ölçün.
• Yetki devredilen tedarikçiler. Kararları yetki devredilmiş bir UM tedarikçisi veriyorsa, onun verileri bir iş günü yükümlülüğünüzü karşılayacak zamanda size ulaşmalı. WEDI'nin Şubat 2026 anketi, ödeyicilerin zorlukları arasında ilk sıraya “farklı sistemlere bağlanmakta zorlanan yetki devredilmiş üçüncü tarafları” koydu.

Sektör Ne Aşamada

WEDI'nin 10 Mart 2026'da yayımlanan Şubat 2026 anketi, API gereklilikleri için katılımcıların “%10'unun henüz çalışmaya başlamadığını” buldu; Ekim 2025'te bu oran %33'tü. Anket ayrıca “tahmini maliyeti 5 milyon doları aşanların oranında %15'ten (Ekim 2025) %25'e (Şubat 2026) belirgin bir artış” olduğunu bildirdi. Örneklem küçük: 86 yanıt ve bunların %52'si ödeyicilerden. Bunu bir sayım değil, bir sinyal olarak okuyun.

1 Ocak 2027'ye On Bir Haftalık Plan

Ekim ortasından itibaren bir MA kuruluşunun veya bir eyalet FFS programının yaklaşık on bir haftası var. Bu süre dört API'yi sıfırdan geliştirmeye yetmez; dolayısıyla plan sıralamayla ve ilk gün neyi gösterebileceğinizle ilgili.

1. Bu hafta: tarihinizi ve başlangıç noktanızı netleştirin. 1 Ocak mı, yoksa daha sonraki bir derecelendirme dönemi ya da plan yılı mı? Halihazırda çalışanları listeleyin: Patient Access ve Provider Directory API'leri, 2026 metrikleri, ret gerekçeleri.
2. 1-2. haftalar: her veri öğesini kaynağıyla eşleştirin. Her API için verinin bugün hangi sistemde durduğunu (talepler, UM, kayıt, sağlık hizmeti sunucusu ağı, klinik) ve ne kadar güncel olduğunu yazın.
3. 1-3. haftalar: FHIR katmanının nerede duracağına karar verin. Eski sistemlerin önünde duran ve değişiklik olaylarıyla ya da sık aralıklı veri çekimleriyle beslenen bir FHIR sunucusu veya cephesi (facade), çekirdek sisteme FHIR konuşmayı öğretmekten genellikle daha hızlıdır. Zamanın asıl harcandığı yer eşleme ve veri akışlarıdır.
4. 2-7. haftalar: önce ortak parçaları kurun. Ön onay kaydı, onay ve atama, üye eşleştirme. Dört API de bunlara dayanıyor.
5. 4-9. haftalar: API'leri geliştirin. Patient Access eklemeleri, toplu dışa aktarımlı Provider Access, iki yönlü Payer-to-Payer ve kapsam kurallarınızın yüklendiği Prior Authorization API.
6. 8-11. haftalar: gerçek karşı taraflarla test edin. Bir sağlık hizmeti sunucusunun EHR tedarikçisi, başka bir ödeyici, yetki devrettiğiniz UM tedarikçisi. Onay değişikliklerini, gerekçesiyle birlikte bir reddi ve üyeye bir iş günü içinde ulaşan bir durum değişikliğini test edin.
7. 1 Ocak 2027: canlıya geçin ve ölçün. İlk günden itibaren gecikmeyi bir iş günü kurallarına göre takip edin ve bitmemiş işlerin tarihli bir listesini tutun.

On bir hafta yetmiyorsa bunu Aralık'ta değil şimdi uyum ekibinize ve hukuk danışmanınıza götürün; 1 Ocak'ta neyin canlıda olacağını ve gerisinin ne zaman geleceğini gösteren bir planla birlikte.

Derecelendirme dönemi 1 Temmuz 2027'de başlayan bir Medicaid yönetilen bakım planı ya da plan yılı daha geç başlayan bir QHP sağlayıcısı, aynı adımları daha geniş bir zaman aralığıyla izleyebilir. Yine de şimdi başlayın: test yapacağınız ödeyiciler ve sağlık hizmeti sunucuları 1 Ocak'ta canlıya geçiyor.

Neler Hâlâ Değişebilir

CMS-0062-P. CMS, 14 Nisan 2026'da bir takip kuralı taslağı yayımladı. Bu taslak, şu anda önerilen uygulama kılavuzlarını 1 Ekim 2027'den itibaren zorunlu hale getirecek, aynı tarihten itibaren ilaçları elektronik ön onaya dahil edecek ve HHS'nin ön onay işlemleri için X12 278 yerine FHIR'ı HIPAA standardı olarak benimsemesini sağlayacak. Mevcut son tarihler hakkında ise şunu söylüyor: “Bu öneri söz konusu uyum tarihlerini değiştirmeyecektir.” Görüş süresi 15 Haziran 2026'da kapandı ve 16 Ekim 2026 itibarıyla Federal Register'da nihai bir kural yayımlanmadı. 2024 kuralına göre geliştirin ve kılavuz sürümlerinizi yapılandırılabilir tek bir yerde tutun.

Sürümler. Da Vinci kılavuzları değişmeye devam ediyor. FY 2027 IPPS nihai kuralı, yeni ONC ön onay kriterlerine göre sertifikalandırılan EHR'lerin “Da Vinci IG'lerinin 2.2 sürümünü kullanmasını gerektireceğini” belirtiyor. Prior Authorization API'nizin konuşacağı sistemler de bunlar.

Bunların hiçbiri beklemek için bir neden değil. Kural kesinleşti, tarihler yönetmelik metninde yer alıyor ve CMS bunları 8 Ekim'de yineledi.

Nereden Destek Alabilirsiniz

API'lerin arkasındaki sistemler üzerinde çalışıyoruz: talep, karşılaşma ve onay verilerinin FHIR eşlemesi, eski talep ve UM platformlarından değişiklik akışları, onay ve atama mantığı ve bir iş günü kurallarının tuttuğunu gösteren testler. Çekirdek sistem eskiyse ya da onu geliştiren kişiler ayrıldıysa işe eski sistem bakımı hizmetimizle başlıyoruz; son tarih bir platform değişiminin ortasına denk geliyorsa ERP modernizasyonu sayfasına göz atın.

Talep veya UM platformunuz, hiçbir tedarikçinin bu API'leri hazır getirmeyeceği bir sistemse office@c9group.dev adresine yazın. Biz sağlık hukuku uzmanı değil, mühendisiz: kapsam ve sözleşme soruları hukuk danışmanınızın alanında; biz onların yanıtına göre geliştiririz.