Theo CMS-0057-F, các payer thuộc phạm vi phải có Prior Authorization API dựa trên FHIR chạy thật trước 1/1/2027, xây trên bộ Da Vinci CRD, DTR và PAS. Hạn ra quyết định (72 giờ với yêu cầu khẩn, 7 ngày với yêu cầu tiêu chuẩn) đã áp dụng từ tháng 1/2026. Payer hay hãng EHR chưa có endpoint PAS đã test chỉ còn khoảng bảy tuần.
Prior authorization (ủy quyền trước của bảo hiểm) đã chuyển từ một cuộc tranh luận chính sách thành một deadline kỹ thuật. Ba quy định đang chồng lên nhau: quy định cuối cùng về interoperability và prior authorization của CMS năm 2024, tiêu chí chứng nhận HTI-4 của ONC cho EHR, và quy định IPPS năm tài chính 2027 cập nhật phiên bản implementation guide. Một đề xuất năm 2026 sẽ thêm thuốc vào phạm vi. Bài này trình bày các mốc thời gian, chuẩn kỹ thuật, câu hỏi về X12 278, và những gì payer hay hãng EHR thực sự phải xây.
CMS-0057-F yêu cầu gì và hạn khi nào?
Quy định yêu cầu Medicare Advantage, Medicaid và CHIP (cả fee-for-service lẫn managed care) và các QHP issuer trên sàn liên bang trả lời yêu cầu prior authorization nhanh hơn, giải thích lý do từ chối, công bố chỉ số, và dựng bốn FHIR API. Các điều khoản vận hành bắt đầu từ 1/1/2026; các API nói chung đến hạn 1/1/2027.
Theo fact sheet của CMS và bản tổng hợp các quy định ePA của CMS:
| Mốc | Yêu cầu | Áp dụng cho |
|---|---|---|
| 1/1/2026 | Quyết định trong 72 giờ (khẩn) và 7 ngày lịch (tiêu chuẩn); nêu lý do cụ thể cho mọi lần từ chối | MA, Medicaid, CHIP (thời hạn không áp dụng cho QHP issuer) |
| 31/3/2026 | Công bố chỉ số prior authorization công khai hằng năm lần đầu | Mọi payer thuộc phạm vi |
| 1/1/2027 | Prior Authorization API, Provider Access API, Payer-to-Payer API, Patient Access API có dữ liệu PA | Mọi payer thuộc phạm vi (ngày cụ thể tùy loại payer) |
| Năm 2027 | Chỉ số Electronic Prior Authorization là tùy chọn với bác sĩ MIPS (10 điểm thưởng) và bệnh viện | Nhà cung cấp dùng health IT được chứng nhận |
| Năm 2028 | Chỉ số Electronic Prior Authorization bắt buộc với bác sĩ MIPS và với bệnh viện để được coi là meaningful EHR user | Nhà cung cấp |
Thuốc nằm ngoài CMS-0057-F. Phần lớn bảo hiểm thương mại và do chủ doanh nghiệp mua cũng không thuộc phạm vi, dù theo cùng bản tổng hợp của CMS, 58 công ty bảo hiểm đã ký một cam kết tự nguyện vào tháng 6/2025 để chuẩn hóa prior authorization điện tử trên FHIR API.
Prior Authorization API nên dùng implementation guide nào?
Nền bắt buộc là FHIR R4.0.1, US Core và SMART App Launch. Bên trên, CMS khuyến nghị ba guide Da Vinci: Coverage Requirements Discovery (CRD), Documentation Templates and Rules (DTR) và Prior Authorization Support (PAS). Các phiên bản liên bang đang áp dụng là CRD 2.2.1, DTR 2.2.0 và PAS 2.2.1.
Câu chuyện phiên bản khá rối, nên đây là thứ tự:
- CMS-0057-F (2024) khuyến nghị, nhưng không bắt buộc, CRD, DTR và PAS. Trang chuẩn API của CMS liệt kê phiên bản 2.0.1 và 2.1.0, và ghi chú US Core 3.1.1 và SMART 1.0.0 cũ đã hết hiệu lực từ 1/1/2026.
- HTI-4 (7/2025) tạo ba tiêu chí chứng nhận ONC cho EHR: 45 CFR 170.315(g)(31) cho CRD, (g)(32) cho DTR và (g)(33) cho PAS.
- Quy định cuối cùng IPPS năm tài chính 2027 (31/7/2026) thay các phiên bản đã áp dụng bằng CRD 2.2.1, DTR 2.2.0 và PAS 2.2.1, hiệu lực từ 1/10/2026, như ONC xác nhận.
- CMS-0062-P (đề xuất 4/2026) sẽ biến các guide được khuyến nghị thành bắt buộc với payer từ 1/10/2027.
Lời khuyên thực tế: xây theo 2.2.x ngay bây giờ. Đó là bản EHR được chứng nhận phải hỗ trợ cho chỉ số năm 2027, và cũng là hướng yêu cầu với payer đang đi tới.
CRD, DTR và PAS ghép với nhau thế nào?
CRD cho bác sĩ biết, ngay lúc ra chỉ định, có cần authorization không. DTR thu thập tài liệu payer cần, điền sẵn từ bệnh án. PAS gửi yêu cầu và nhận quyết định. Ba trao đổi API này thay cho vòng "gọi điện, fax, portal".
1. Coverage Requirements Discovery (CRD)
EHR gọi CDS Hooks (order-select, order-sign, appointment-book và tương tự) đến dịch vụ CRD của payer. Payer trả về card: "không cần auth", "cần auth", hoặc "cần tài liệu, mở DTR". Thách thức kỹ thuật là độ trễ. Hook chạy khi bác sĩ đang ký chỉ định, nên dịch vụ payer chậm là chặn luôn quy trình. Hãy dự trù cache quy tắc chi trả và timeout gọn gàng, rơi về trạng thái "chưa rõ, kiểm tra sau".
2. Documentation Templates and Rules (DTR)
DTR gửi một FHIR Questionnaire kèm logic CQL. App DTR phía nhà cung cấp chạy CQL trên hồ sơ bệnh nhân để điền sẵn câu trả lời, và người hoàn thiện phần còn lại. Phần khó là chạy CQL trên dữ liệu US Core thật, vốn lộn xộn, và quyết định câu nào bác sĩ phải xác nhận thay vì chấp nhận auto-fill.
3. Prior Authorization Support (PAS)
PAS gửi một FHIR Claim bundle kèm QuestionnaireResponse và các resource hỗ trợ, và nhận về ClaimResponse. Nếu payer chưa quyết định được ngay, phản hồi ở trạng thái "pended", và nhà cung cấp nhận cập nhật sau qua subscription hoặc polling. Xử lý pended là chỗ phần lớn pilot đổ vỡ: state machine, gửi lại idempotent, và đối soát các cập nhật đến sai thứ tự.
Còn cần giao dịch X12 278 không?
Không, trong một luồng prior authorization FHIR tuân thủ. Tháng 2/2024, HHS công bố enforcement discretion: không xử phạt HIPAA với covered entity bỏ qua X12 278 trong một Prior Authorization API FHIR đáp ứng CMS-0057-F. CMS nói discretion này không có ngày kết thúc, nhưng chỉ áp dụng cho đúng con đường đó.
Chi tiết nằm ở FAQ về enforcement discretion giao dịch HIPAA của CMS và thư ngày 28/2/2024. Hai hệ quả với kiến trúc:
- Thiết kế PAS ban đầu đi qua một trung gian dịch FHIR sang X12 278. Với discretion này, payer có thể nhận FHIR từ đầu đến cuối. Nhiều payer vẫn giữ đường 278 cho đối tác chưa lên FHIR, nên hãy thiết kế cho cả hai.
- CMS-0062-P đề xuất HHS áp dụng FHIR cho các giao dịch HIPAA về prior authorization thay cho X12N 278, với thời hạn tuân thủ 24 tháng (36 tháng cho gói bảo hiểm nhỏ) khi được chốt. Tính đến tháng 11/2026, đây vẫn là đề xuất, chưa phải quy định cuối cùng.
Payer cần xây gì trước tháng 1/2027?
Một dịch vụ CRD production, nội dung DTR (Questionnaire và CQL) cho mọi dịch vụ cần authorization, một endpoint PAS xử lý được quyết định pended, phân quyền dựa trên SMART cho hệ thống của nhà cung cấp, và báo cáo chỉ số. Phần lớn payer sẽ mua nền tảng cho một phần; phần nội dung quy tắc thì không mua được.
- Nội dung quy tắc mới là backlog thật. Mỗi dịch vụ trong danh sách cần authorization phải có logic chi trả cho CRD và một Questionnaire kèm CQL cho DTR. Đó là chính sách lâm sàng dịch thành code, và cần chuyên gia lâm sàng duyệt.
- Đồng hồ quyết định. Bộ đếm 72 giờ và 7 ngày bắt đầu khi yêu cầu đến. Hệ thống PAS phải theo dõi từng yêu cầu và cảnh báo trước khi quá hạn.
- Lý do từ chối. Mỗi lần từ chối cần một lý do cụ thể mà nhà cung cấp hành động được, nằm trong ClaimResponse.
- Chỉ số. CMS-0062-P đề xuất thêm số lượng bên cạnh tỉ lệ phần trăm và chỉ số sử dụng API mới, dữ liệu 2027 báo cáo năm 2028. Hãy log mọi yêu cầu và quyết định kèm timestamp ngay từ ngày đầu.
- Danh bạ endpoint. CMS-0062-P cũng sẽ yêu cầu payer báo endpoint API cho CMS trong 60 ngày sau khi quy định đó có hiệu lực.
Hãng EHR cần xây gì?
Một CDS Hooks client cho CRD, một app DTR hoặc hỗ trợ DTR native chạy CQL trên dữ liệu của bạn, một PAS client xử lý phản hồi pended, và cơ chế tìm endpoint của payer. Nếu khách hàng của bạn báo cáo MIPS hay Promoting Interoperability cho bệnh viện, bạn cần chứng nhận (g)(31), (g)(32) và (g)(33) trên bản 2.2.
Theo bản tổng hợp của CMS, chỉ số năm 2027 là tùy chọn và chỉ cần ít nhất một module được chứng nhận; từ 2028 là bắt buộc và cần cả ba. Điều đó cho hãng EHR một thứ tự rõ ràng: PAS trước (mang điểm thưởng năm 2027), rồi CRD và DTR. Phần kỹ thuật khó nằm ở DTR: chạy CQL của payer an toàn trên data model của bạn, map sang US Core khi model nội bộ khác, và giữ bác sĩ trong vòng duyệt cho mọi câu trả lời auto-fill. Trang dịch vụ tích hợp EHR mô tả cách chúng tôi map FHIR trên hệ thống có sẵn.
AI giúp được gì trong prior authorization, và nên dừng ở đâu?
AI hữu ích khi soạn câu trả lời DTR từ ghi chú không cấu trúc, tóm tắt bằng chứng lâm sàng cho người duyệt, và định tuyến các yêu cầu pended. AI không nên ra quyết định từ chối. Mô hình WISeR của CMS trong Original Medicare, dùng AI hỗ trợ xét duyệt ở sáu bang từ 2026, nêu rõ khuyến nghị không chi trả do chuyên gia lâm sàng có giấy phép quyết định.
Phía nhà cung cấp, giá trị nằm ở DTR: nhiều câu payer hỏi bị chôn trong ghi chú tự do mà CQL không đọc được. Model có thể đề xuất câu trả lời kèm trích dẫn ghi chú nguồn, và bác sĩ xác nhận. Phía payer, model có thể phân loại và tóm tắt, nhưng trang mô hình WISeR nói rõ chuyên gia lâm sàng quyết định việc không chi trả. Hãy thiết kế mỗi bước AI sao cho người duyệt kết quả và audit log thể hiện bằng chứng. Mô hình này được mô tả trong AI có người giám sát cho ngành tuân thủ, cách kiểm thử trong kiểm thử LLM cho ngành tuân thủ. Mọi model nhìn thấy bệnh án phải nằm trong chuỗi BAA của bạn; xem AI agent tuân thủ HIPAA.
Tiếp theo là gì: thuốc và CMS-0062?
CMS-0062-P, đề xuất ngày 10/4/2026, sẽ mở rộng prior authorization điện tử sang thuốc từ 1/10/2027: thuốc thuộc quyền lợi y tế đi qua Prior Authorization API, và thuốc thuộc quyền lợi nhà thuốc đi qua NCPDP SCRIPT, Formulary and Benefit, và Real-Time Prescription Benefit với một số payer. Đề xuất chưa được chốt.
Theo fact sheet CMS-0062-P, đề xuất cũng đặt thời hạn quyết định cho thuốc (24 giờ với Medicaid và CHIP; 72 giờ tiêu chuẩn và 24 giờ khẩn với QHP issuer) và đưa QHP issuer vào thời hạn 7 ngày và 72 giờ cho dịch vụ không phải thuốc. Nếu đang thiết kế hệ thống PAS, hãy giữ data model của yêu cầu đủ tổng quát cho yêu cầu thuốc, vì sửa lại sau khó hơn tính trước.
BeevR làm việc này thế nào
Chúng tôi xây phần tích hợp FHIR và lớp AI cho các đội health IT: dịch vụ CDS Hooks, app SMART on FHIR, điền sẵn DTR có bác sĩ xác nhận, và hạ tầng audit, chỉ số mà cơ quan quản lý yêu cầu. Chúng tôi đang vận hành một EHR multi-tenant chạy thật ở bốn phòng khám tại Mỹ, khoảng 300 bệnh nhân mỗi ngày, nên đã làm việc với dữ liệu US Core thật, không chỉ server test. BeevR ký BAA với vai trò business associate, và các thành phần AI có thể chạy trong tài khoản AWS của bạn dưới AWS BAA.
Chúng tôi làm theo từng giai đoạn giá cố định, từ $10K mỗi giai đoạn, demo chạy được mỗi thứ Sáu, và bạn sở hữu code và IP từ ngày đầu. Xem phát triển AI agent cho y tế để biết phạm vi, hoặc đặt lịch gọi 30 phút để rà kế hoạch 2027 của bạn.