القاعدة CMS-0057-F وموعد 1 يناير 2027: واجهات API للجهات الدافعة في أنظمة المطالبات والموافقة المسبقة الداخلية

بحلول 1 يناير 2027، يجب على منظمات Medicare Advantage (شركات التأمين الخاصة التي تقدم تغطية Medicare)، وعلى برامج Medicaid (التأمين الصحي العام لذوي الدخل المحدود) وCHIP (التأمين الصحي للأطفال) التي تديرها الولايات بنظام الدفع مقابل الخدمة (fee-for-service، FFS)، أن تشغّل أربع واجهات FHIR API بموجب القاعدة النهائية للتشغيل البيني والموافقة المسبقة (CMS-0057-F) الصادرة عن CMS، الجهة الاتحادية المسؤولة عن Medicare وMedicaid: واجهة Patient Access API القائمة، بعد توسيعها لتحمل بيانات الموافقة المسبقة، وثلاث واجهات جديدة هي Provider Access API وPayer-to-Payer API وPrior Authorization API. أما خطط الرعاية المُدارة (managed care) في Medicaid، وجهات الرعاية المُدارة في CHIP، وجهات إصدار الخطط الصحية المؤهلة (Qualified Health Plan، QHP) في الأسواق الاتحادية للتأمين الصحي، فتلتزم بدءاً من أول فترة تسعير (rating period) أو سنة خطة (plan year) تبدأ في ذلك التاريخ أو بعده. وحتى 16 أكتوبر 2026، يفصلنا عن هذا الموعد أحد عشر أسبوعاً، ولم تغيّره CMS.

النصف التشغيلي من القاعدة سارٍ بالفعل. فمنذ 2026، أصبح على الجهات الدافعة المشمولة أن تذكر سبباً محدداً لكل رفض لطلب موافقة مسبقة، وأن تبتّ في الطلبات ضمن مهل زمنية ثابتة، وأن تنشر مؤشرات الموافقة المسبقة.

إن كانت أنظمة المطالبات وإدارة الاستخدام (utilization management، UM) والأعضاء لديك من مورّد يوفّر هذه الواجهات الأربع، فمعظم البناء يقع على عاتق المورّد. ويقتصر دورك على الإعداد، وتحويل قواعد الموافقة المسبقة إلى بيانات رقمية، وإشعارات الأعضاء، والاختبار مع الشركاء.

هذا المقال لمن تبقّى: الخطط والوكالات الحكومية التي يقع محرك المطالبات أو مسار عمل إدارة الاستخدام أو بيانات الأعضاء لديها في نظام تملكه، سواء طُوِّر داخلياً، أو خُصِّص إلى حدٍّ لم يعد معه قابلاً للترقية، أو كان نظام MMIS لإدارة معلومات Medicaid (Medicaid Management Information System) تراكمت عليه تعديلات محلية على مدى عقود. لا أحد يوفّر الواجهات لمثل هذه الأنظمة. نحن مهندسون لا محامون: يشرح هذا المقال ما تطلبه القاعدة من النظام، لا كيف تنطبق على عقودك.

المواعيد

نُشرت القاعدة النهائية في Federal Register (الجريدة الرسمية الاتحادية) بتاريخ 8 فبراير 2024 ودخلت حيز النفاذ في 8 أبريل 2024. وتحدد للواجهات الأربع جميعها مواعيد الامتثال نفسها: "بحلول 1 يناير 2027 لمنظمات MA وبرامج Medicaid وCHIP بنظام FFS في الولايات؛ وبحلول فترة التسعير التي تبدأ في 1 يناير 2027 أو بعده لخطط الرعاية المُدارة في Medicaid وجهات الرعاية المُدارة في CHIP؛ ولسنوات الخطة التي تبدأ في 1 يناير 2027 أو بعده لجهات إصدار خطط QHP في أسواق FFEs".

وعليه، فإن خطة الرعاية المُدارة في Medicaid التي تبدأ فترات التسعير لديها في 1 يوليو أمامها حتى 1 يوليو 2027. أما الخطة التي يتبع عقدها السنة الميلادية فليس لها ذلك.

ولا تزال CMS تذكر التاريخ نفسه. إذ تقول صفحة السياسات الخاصة بالقاعدة، التي عُدّلت آخر مرة في 8 أكتوبر 2026، إن "أمام الجهات الدافعة المشمولة مهلة تمتد في الأساس حتى 1 يناير 2027 لاستيفاء متطلبات واجهة برمجة التطبيقات (API) في هذه القاعدة النهائية".

التزامات 2026، كما تعرضها ورقة الحقائق الصادرة عن CMS، هي البتّ في الطلبات "خلال 72 ساعة للطلبات المستعجلة (أي العاجلة) وسبعة أيام تقويمية للطلبات العادية (أي غير العاجلة)" (وتُستثنى جهات إصدار خطط QHP في الأسواق من هذه المهل)، وذكر سبب محدد لكل رفض، ونشر مؤشرات للعموم، علماً بأنه "يجب الإبلاغ عن المجموعة الأولى من المؤشرات بحلول 31 مارس 2026". ويُرفع إلى CMS أيضاً تقرير سنوي عن استخدام Patient Access API بحلول 31 مارس. وإن لم يكن أي من ذلك يعمل بعد، فهو متأخر بالفعل، ويعتمد على البيانات نفسها التي تعتمد عليها الواجهات.

الأدوية خارج ذلك كله. فكل أحكام الموافقة المسبقة في CMS-0057-F تستثنيها.

من يشمله النطاق ومن لا يشمله

تطلق القاعدة على هذه الجهات اسم الجهات الدافعة المشمولة (impacted payers): منظمات Medicare Advantage (MA)، وبرامج Medicaid وCHIP في الولايات بنظام الدفع مقابل الخدمة (FFS)، وخطط الرعاية المُدارة في Medicaid، وجهات الرعاية المُدارة في CHIP، وجهات إصدار خطط QHP في الأسواق الاتحادية (Federally-facilitated Exchanges، FFEs). ويحصي تحليل الأثر الوارد فيها "365 منظمة أم، بما فيها وكالات Medicaid وCHIP في الولايات"، "مسؤولة عن تنفيذ ثلاث واجهات API جديدة وصيانتها"، ويشير إلى أن "75 في المئة من الجهات الدافعة في هذه الفئة لديها أقل من 500 موظف". وكثير منها خطط إقليمية لا تملك فريق منصات كبيراً.

ولا تدخل في النطاق، على الأقل بصورة مباشرة:

• خطط أصحاب العمل خارج هذه البرامج، وبرنامج Original Medicare (Medicare التقليدي). فهي ليست ضمن قائمة الجهات الدافعة المشمولة.
• مقدمو الرعاية. يقع الجانب الخاص بهم ضمن مقياس Electronic Prior Authorization (الموافقة المسبقة الإلكترونية) في برامج Promoting Interoperability التابعة لبرنامج Medicare، ويُستوفى عبر تقنية EHR (السجل الصحي الإلكتروني) معتمدة. وقد جعلته القاعدة النهائية لنظام IPPS لمدفوعات المستشفيات للسنة المالية 2027 الصادرة في 4 أغسطس 2026 مقياساً اختيارياً يمنح المستشفيات نقاطاً إضافية في 2027.
• جهات إدارة الاستخدام المفوَّضة وجهات الإدارة من الطرف الثالث (TPA). لا يقع عليها التزام خاص بها، لكن التزام الجهة الدافعة يمر عبر أنظمتها. وبالنسبة لجهات إصدار خطط QHP، تكرر القاعدة أنها "مسؤولة عن امتثالها الخاص وعن امتثال أي جهات مفوَّضة أو جهات لاحقة في السلسلة".

المخارج قليلة، ولا يفيد أيٌّ منها كثيراً في هذا الوقت المتأخر. يجوز للولاية أن تطلب تمديداً لمرة واحدة مدته سنة واحدة لبرنامج Medicaid أو CHIP بنظام FFS لديها، لكن الطلب يُقدَّم ضمن وثيقة التخطيط المسبق (Advance Planning Document، APD) ويجب أن "يُعتمد قبل موعد الامتثال". ويمكن للولاية التي يكون 90 في المئة على الأقل من المستفيدين من Medicaid فيها مسجلين في الرعاية المُدارة أن تطلب إعفاءً، ويمكن لجهات إصدار خطط QHP أن تطلب استثناءً من السوق. أما بشأن الخطط نفسها، فقد كتبت CMS: "لم نقترح تمديدات أو إعفاءات لمنظمات MA أو لخطط الرعاية المُدارة في Medicaid". ويمكن للولايات أيضاً أن تطالب بتمويل اتحادي مشترك مُعزَّز بنسبة 90 في المئة لبناء الواجهات، يُعتمد لكل حالة على حدة عبر وثيقة APD.

ما الذي يجب أن تؤديه كل واجهة

تعتمد الواجهات الأربع جميعها على شيء واحد كثيراً ما يفتقر إليه النظام المخصص: الموافقة المسبقة بوصفها بيانات منظَّمة لها سجل بتغيّرات حالتها. ابنِ ذلك مرة واحدة، فتقرأ منه الواجهات الأربع كلها.

واجهة Patient Access API: إضافة الموافقات المسبقة

تشغّل هذه الواجهة منذ 1 يناير 2021 للمطالبات وسجلات الزيارات (encounters) والبيانات السريرية. واعتباراً من 2027 يجب أن تحمل أيضاً كل موافقة مسبقة على المواد والخدمات: حالتها، وتاريخ الموافقة عليها أو رفضها، وتاريخ انتهائها، والمواد والخدمات المعتمدة، وسبباً محدداً في حال الرفض، والمستندات المنظَّمة ذات الصلة الواردة من مقدّم الرعاية. ويجب أن تكون البيانات متاحة "في موعد لا يتجاوز يوم عمل واحداً بعد" استلام الجهة الدافعة للطلب، وأن تُحدَّث خلال يوم عمل واحد من أي تغيير في الحالة، وأن تُحفظ طوال سريان الموافقة ولمدة سنة على الأقل بعد آخر تغيير فيها.

ونظام إدارة الاستخدام الذي يسجّل القرارات في ملاحظات نصية حرة، أو لا يرسل الحالة إلا بالفاكس، لا يمكنه تغذية ذلك دون تعديلات.

واجهة Provider Access API

يمكن لمقدمي الرعاية داخل الشبكة طلب بيانات المريض: المطالبات وسجلات الزيارات دون بيانات السداد لمقدمي الرعاية (remittances) أو حصة المريض من التكاليف (cost-sharing)، وفئات البيانات السريرية في USCDI (المجموعة الأمريكية الأساسية لبيانات التشغيل البيني)، ومعلومات الموافقة المسبقة، لتواريخ الخدمة اعتباراً من 1 يناير 2016. وتجيب الجهة الدافعة خلال يوم عمل واحد، لكن فقط عن المرضى الذين نسبتهم إلى مقدّم الرعاية هذا ولم يختاروا الانسحاب (opt-out).

ويتطلب ذلك ثلاثة أمور نادراً ما يملكها نظام قديم. أولها عملية إسناد (attribution) تربط الأعضاء بمقدمي الرعاية. وثانيها خيار انسحاب يستطيع العضو تغييره في أي وقت، مع إشعارات بلغة واضحة قبل أول استخدام، وخلال أسبوع من بدء التغطية، ثم كل عام. وثالثها التصدير المجمَّع، لأن المعايير المطلوبة تشمل FHIR Bulk Data Access لمقدّم الرعاية الذي يستعلم عن قائمة مرضاه كلها.

واجهة Payer-to-Payer API

عندما ينضم عضو، تطلب الجهة الدافعة الجديدة إذنه (فهذه الواجهة تتطلب موافقة صريحة من العضو، أي opt-in)، وتبدأ خلال أسبوع من بدء التغطية في تحديد الجهات الدافعة السابقة والمتزامنة. وبمجرد تحديدها، تطلب خلال أسبوع بيانات خمس سنوات: المطالبات وسجلات الزيارات دون بيانات السداد أو حصة المريض من التكاليف، وبيانات USCDI، والموافقات المسبقة باستثناء المرفوضة منها، مع مستنداتها غير المنظَّمة. وتجيب الجهة الدافعة السابقة خلال يوم عمل واحد. وفي حالة التغطية المتزامنة، يتكرر التبادل كل ربع سنة على الأقل.

الصعوبة ليست في الرد الصادر. بل في استقبال بيانات من جهات دافعة لم تختبر التبادل معها قط، ودمجها في سجل العضو لديك كما تشترط القاعدة.

واجهة Prior Authorization API

هذه هي الواجهة التي تصل إلى صميم نظام إدارة الاستخدام. يجب أن تعرض الواجهة المواد والخدمات المشمولة بالتغطية التي تتطلب موافقة مسبقة، وأن تحدد المستندات المطلوبة لكل منها، وأن تدعم طلباً ورداً متوافقين مع قانون HIPAA، وأن تبيّن ما إذا كانت الجهة الدافعة قد وافقت (مع تاريخ الانتهاء) أو رفضت (مع سبب محدد) أو تحتاج إلى مزيد من المعلومات.

توصي CMS هنا، دون أن تُلزم، بثلاثة أدلة تنفيذ من مشروع Da Vinci في HL7: Coverage Requirements Discovery (CRD)، وDocumentation Templates and Rules (DTR)، وPrior Authorization Support (PAS). وعملياً، يجب أن تصبح قواعد التغطية واستبيانات المستندات لديك قابلة للقراءة آلياً، لا دليل سياسات بصيغة PDF. وقد وضعت الجهات الدافعة المشاركة في استطلاع WEDI، وهي هيئة أمريكية معنية بتبادل البيانات الصحية إلكترونياً، "رقمنة سياسات الموافقة المسبقة" بين أكبر ثلاثة تحديات لديها.

أما المعاملة نفسها، فقد منحت فيها HHS الجهات الدافعة مرونة. ففي 28 فبراير 2024 أعلنت أنها ستمارس سلطتها التقديرية في الإنفاذ (enforcement discretion): وبحسب CMS، فإن National Standards Group التابعة لها "لن تتخذ إجراءات إنفاذ بموجب قواعد التبسيط الإداري في HIPAA بحق الجهات المشمولة بقانون 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، فاحسم الإصدارات التي تبني عليها قبل أن يبدأ أي شخص بكتابة المطابقة.

أين تقصّر الأنظمة الداخلية عادة

انطلاقاً مما تطلبه القاعدة، هذه هي الفجوات التي ينبغي البحث عنها أولاً:

• الموافقة المسبقة سجلاً لا مستنداً. يجب أن تكون الحالة والطوابع الزمنية ورموز أسباب الرفض وتاريخ الانتهاء حقولاً، تُكتب عند تغيّرها، مع سجل تاريخي. والقرار المرسَل بالفاكس يحتاج إلى نظير منظَّم.
• قواعد التغطية. أي الخدمات تحتاج إلى موافقة، وما المستندات التي تحتاجها كل منها: يجب أن يكون ذلك بيانات تستطيع الواجهة تقديمها. وفي كثير من الخطط يعيش هذا في ملفات PDF للسياسات وفي أذهان المراجعين.
• المطالبات بصيغة FHIR. يجب أن تخرج المطالبات وسجلات الزيارات في صورة موارد FHIR، مع حذف بيانات السداد وحصة المريض من التكاليف لمقدمي الرعاية والجهات الدافعة الأخرى، والإبقاء عليها للعضو.
• هوية العضو وسجله. مطابقة بيانات جهة دافعة أخرى مع عضوك، وتحديد الجهات الدافعة السابقة لعضو جديد، يتطلبان بيانات ديموغرافية وسجل تغطية قد لا تحتفظ بهما في مكان واحد.
• حالة الإذن (consent). خيار انسحاب لواجهة Provider Access وخيار موافقة صريحة لواجهة Payer-to-Payer، يمكن تغيير كل منهما في أي وقت ويُفحص مع كل طلب. ويجب على الولاية أيضاً أن تنقل موافقة المستفيد الصريحة إلى خطط الرعاية المُدارة في Medicaid التي ينتمي إليها.
• مهلة يوم العمل الواحد. المعالجة الليلية المجمَّعة على الحاسوب المركزي (mainframe) تكفي لبعض البيانات وتكون بطيئة جداً لغيرها. قِس الوقت من القرار حتى وصوله إلى الواجهة، لا مجرد ما إذا كانت الواجهة تستجيب.
• المورّدون المفوَّضون. إن كان مورّد مفوَّض لإدارة الاستخدام هو من يتخذ القرارات، فيجب أن تصلك بياناته في وقت يسمح لك بالوفاء بالتزام يوم العمل الواحد. وقد وضع استطلاع WEDI في فبراير 2026 "الأطراف الثالثة المفوَّضة التي تواجه تحديات في الاتصال بأنظمة مختلفة" في المرتبة الأولى بين تحديات الجهات الدافعة.

إلى أين وصل القطاع

وجد استطلاع WEDI الذي أُجري في فبراير 2026، ونُشر في 10 مارس 2026، أن "10% لم يبدؤوا عملهم بعد" فيما يخص متطلبات الواجهات، مقابل 33% في أكتوبر 2025. وأفاد أيضاً بحدوث "زيادة ملحوظة في نسبة من يقدّرون التكلفة بأكثر من 5 ملايين دولار، من 15% (أكتوبر 2025) إلى 25% (فبراير 2026)". والعينة صغيرة: 86 إجابة، 52% منها من جهات دافعة. فاقرأه مؤشراً لا إحصاءً شاملاً.

خطة من أحد عشر أسبوعاً حتى 1 يناير 2027

اعتباراً من منتصف أكتوبر، أمام منظمة MA أو برنامج FFS في إحدى الولايات نحو أحد عشر أسبوعاً. وهذا لا يكفي لبناء أربع واجهات من الصفر، لذا تدور الخطة حول التسلسل، وحول ما يمكنك إثباته في اليوم الأول.

1. هذا الأسبوع: تأكيد موعدك ونقطة انطلاقك. هل هو 1 يناير، أم فترة تسعير أو سنة خطة لاحقة؟ دوّن ما يعمل بالفعل: واجهتا Patient Access API وProvider Directory API، ومؤشرات 2026، وأسباب الرفض.
2. الأسبوعان 1 و2: ربط كل عنصر بيانات بمصدره. لكل واجهة، دوّن النظام الذي يحتفظ بالبيانات اليوم (المطالبات، وإدارة الاستخدام، والتسجيل، وشبكة مقدمي الرعاية، والبيانات السريرية) ومدى حداثتها.
3. من الأسبوع 1 إلى الأسبوع 3: تحديد مكان طبقة FHIR. خادم FHIR أو واجهة وسيطة (facade) أمام الأنظمة القديمة، تُغذّى بأحداث التغيير أو باستخراجات متكررة، أسرع عادة من تعليم النظام الأساسي التحدث بلغة FHIR. والمطابقة والتغذيات هي ما يستهلك الوقت.
4. من الأسبوع 2 إلى الأسبوع 7: بناء المكونات المشتركة أولاً. سجل الموافقة المسبقة، والإذن والإسناد، ومطابقة الأعضاء. فالواجهات الأربع كلها تعتمد عليها.
5. من الأسبوع 4 إلى الأسبوع 9: بناء الواجهات. إضافات Patient Access، وProvider Access مع التصدير المجمَّع، وPayer-to-Payer في الاتجاهين، وPrior Authorization API بعد تحميل قواعد التغطية لديك.
6. من الأسبوع 8 إلى الأسبوع 11: الاختبار مع أطراف حقيقية. مورّد نظام EHR لدى مقدّم رعاية، وجهة دافعة أخرى، ومورّد إدارة الاستخدام المفوَّض لديك. اختبر تغييرات الإذن، وحالة رفض مع سببها، وتغيير حالة يصل إلى العضو خلال يوم عمل.
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". وهذه هي الأنظمة التي ستتواصل معها واجهة Prior Authorization API لديك.

لا شيء من ذلك سبب للانتظار. فالقاعدة نهائية، والمواعيد واردة في نص اللائحة، وقد كررتها CMS في 8 أكتوبر.

أين تحصل على المساعدة

نعمل على الأنظمة التي تقف خلف الواجهات: مطابقة بيانات المطالبات والزيارات والموافقات مع FHIR، وتغذيات التغيير من منصات المطالبات وإدارة الاستخدام القديمة، ومنطق الإذن والإسناد، والاختبارات التي تثبت الالتزام بقواعد يوم العمل الواحد. وخدمة صيانة الأنظمة القديمة لدينا هي نقطة البداية حين يكون النظام الأساسي قديماً أو يكون من بنوه قد غادروا، وإن صادف الموعد النهائي منتصف عملية استبدال منصة، فاطّلع على تحديث أنظمة ERP.

إن كانت منصة المطالبات أو إدارة الاستخدام لديك من النوع الذي لن يوفّر له أي مورّد هذه الواجهات، فراسلنا على office@c9group.dev. نحن مهندسون لا محامون متخصصون في الرعاية الصحية: أسئلة النطاق والعقود من اختصاص مستشارك القانوني، ونحن نبني وفق إجابته.