CMS-0057-Fと2027年1月1日：自社開発の請求・事前承認システムで保険者APIを動かす

ワシントンD.C.のヒューバート・H・ハンフリー・ビル。米国保健福祉省（HHS）の本部が置かれている

CMS（米国メディケア・メディケイド・サービスセンター）の相互運用性・事前承認最終規則（CMS Interoperability and Prior Authorization final rule、CMS-0057-F）により、Medicare Advantage組織（MA organization、メディケアの給付を民間プランで提供する保険会社）と、州のMedicaid（低所得者向けの公的医療保険）およびCHIP（児童向け医療保険プログラム）の出来高払い（fee-for-service）プログラムは、2027年1月1日までに4つのFHIR APIを稼働させなければなりません。事前承認データも扱えるよう拡張された既存のPatient Access APIと、新設のProvider Access API、Payer-to-Payer API、Prior Authorization APIです。Medicaidのマネージドケアプラン、CHIPのマネージドケア事業体、連邦の医療保険取引所でQualified Health Plan（QHP、適格医療保険プラン）を提供する保険会社は、この日以降に始まる最初のrating period（料率設定期間）またはプラン年度から対象になります。2026年10月16日時点で残りは11週間ですが、CMSは期限を動かしていません。

規則のうち運用面の半分は、すでに施行されています。2026年以降、対象となる保険者には、事前承認を却下するたびに具体的な理由を示すこと、定められた期間内に判断すること、事前承認に関する指標を公表することが義務づけられています。

請求処理、利用管理（utilization management、UM）、加入者管理のシステムが、この4つのAPIを提供するベンダーの製品なら、開発の大半はベンダーの仕事です。自社でやるべきことは、設定、事前承認ルールのデジタル化、加入者への通知、そして連携先とのテストです。

この記事は、それ以外の方々に向けたものです。請求処理エンジン、UMのワークフロー、加入者データが自社で保有するシステムにあるプランや州の機関で、自社開発のもの、アップグレードできないほどカスタマイズを重ねたもの、数十年分の独自改修を抱えたMedicaid Management Information System（MMIS、州のMedicaid管理情報システム）などがこれにあたります。こうしたシステム向けのAPIは、誰も用意してくれません。当社はエンジニアであり、弁護士ではありません。ここで説明するのは規則がシステムに何を求めているかであって、それが自社の契約にどう当てはまるかではありません。

日程

最終規則は2024年2月8日にFederal Register（米国の官報）で公布され、2024年4月8日に発効しました。4つのAPIのいずれについても遵守期限は同じで、「MA組織および州のMedicaid・CHIPのFFSプログラムについては2027年1月1日まで、MedicaidマネージドケアプランおよびCHIPマネージドケア事業体については2027年1月1日以降に開始するrating periodまで、FFEのQHP保険会社については2027年1月1日以降に開始するプラン年度について」とされています。

対象	運用ルールの施行	APIの稼働
Medicare Advantage組織	2026年1月1日	2027年1月1日
州のMedicaidおよびCHIPの出来高払い（FFS）プログラム	2026年1月1日	2027年1月1日（1年の延長が可能な場合あり）
Medicaidマネージドケアプラン、CHIPマネージドケア事業体	2026年1月1日以降に始まるrating period	2027年1月1日以降に始まるrating period
連邦運営の医療保険取引所（Federally-facilitated Exchanges）のQHP保険会社	2026年1月1日以降に始まるプラン年度	2027年1月1日以降に始まるプラン年度

したがって、rating periodが7月1日に始まるMedicaidマネージドケアプランには、2027年7月1日まで猶予があります。暦年契約のプランにはありません。

CMSが示す日付も変わっていません。2026年10月8日に最終更新されたこの規則の政策ページには、「対象保険者が本最終規則のアプリケーション・プログラミング・インターフェース（API）要件を満たす期限は、主として2027年1月1日である」と書かれています。

CMSのファクトシートの表現を借りれば、2026年からの義務は、「迅速（すなわち緊急）の申請については72時間以内、標準（すなわち非緊急）の申請については暦日で7日以内」に判断すること（取引所のQHP保険会社はこの期間の対象外）、却下のたびに具体的な理由を示すこと、そして指標を公表することです。指標については「最初の指標セットは2026年3月31日までに報告しなければならない」とされています。Patient Access APIの利用状況も、毎年3月31日までにCMSに報告します。このうちまだ動いていないものがあれば、すでに遅れています。しかも、使うデータはAPIと同じです。

医薬品は、これらすべての対象外です。CMS-0057-Fの事前承認に関する規定は、いずれも医薬品を除外しています。

対象になるところ、ならないところ

規則ではこれらを対象保険者（impacted payers）と呼びます。Medicare Advantage（MA）組織、州のMedicaidおよびCHIPの出来高払い（FFS）プログラム、Medicaidマネージドケアプラン、CHIPマネージドケア事業体、そして連邦運営の医療保険取引所（Federally-facilitated Exchanges、FFE）のQHP保険会社です。規則の影響分析は、「州のMedicaidおよびCHIP機関を含む365の親組織」が「3つの新しいAPIの実装と維持に責任を負う」と数え、「この区分の保険者の75パーセントは従業員500人未満である」と記しています。その多くは、大きなプラットフォームチームを持たない地域のプランです。

対象外のもの（少なくとも直接の対象ではないもの）は次のとおりです。

これらのプログラムに属さない雇用主プランと、Original Medicare（従来型のメディケア）。対象保険者の一覧に入っていません。
医療提供者。医療提供者側の対応は、MedicareのPromoting InteroperabilityプログラムにあるElectronic Prior Authorization measure（電子事前承認の評価項目）で、認定EHR技術を使って満たします。2026年8月4日のFY 2027 IPPS最終規則（IPPSは入院医療の包括支払制度）は、2027年についてこれを病院向けの任意のボーナス項目にしました。
UMの委託先とTPA（第三者管理機関）。自らの義務はありませんが、保険者の義務は委託先のシステムを通じて果たされます。QHP保険会社について、規則は改めて、QHP保険会社は「自らの遵守と、委託先または下流のあらゆる事業体の遵守に責任を負う」と述べています。

逃げ道はほとんどなく、この時期になってはどれもあまり役に立ちません。州は、MedicaidまたはCHIPのFFSプログラムについて1回限り、1年間の延長を申請できますが、申請はAdvance Planning Document（APD、連邦資金を受けるための州の計画書）に盛り込む必要があり、「遵守期限より前に承認」されていなければなりません。Medicaid受給者の90パーセント以上がマネージドケアに加入している州は免除を申請でき、QHP保険会社は取引所に例外を求めることができます。プランそのものについて、CMSは「MA組織またはMedicaidマネージドケアプランについては、延長も免除も提案しなかった」と書いています。また州は、APIの構築費用について90パーセントの連邦負担率の引き上げ（enhanced federal matching funds）を請求でき、APDを通じて案件ごとに承認されます。

各APIに求められること

4つとも、独自開発のシステムに欠けがちなものに依存しています。ステータス履歴を持つ構造化データとしての事前承認です。これを一度作れば、4つのAPIすべてがそこから読み出します。

Patient Access API：事前承認を追加する

このAPIは、請求、受診（encounter）、臨床データを対象に、2021年1月1日からすでに運用されています。2027年からは、物品とサービスの事前承認も1件ごとに提供しなければなりません。内容は、ステータス、承認または却下の日付、終了日、承認された物品とサービス、却下の場合は具体的な理由、そして医療提供者から提出された関連する構造化文書です。データは、保険者が申請を受け取ってから「遅くとも1営業日後」までに利用できるようにし、ステータスが変わったら1営業日以内に更新し、承認が有効な間と、最後の変更から少なくとも1年間は保持しなければなりません。

判断を自由記述のメモで記録しているUMシステムや、ステータスをファクスでしか送らないUMシステムでは、改修なしにこのデータを供給できません。

Provider Access API

ネットワーク内の医療提供者は、患者のデータを要求できます。対象は2016年1月1日以降の診療日の分で、医療提供者への支払情報（remittance）と患者の自己負担を除いた請求・受診データ、USCDI（米国の相互運用性のための標準データセット）の臨床データクラス、そして事前承認情報です。保険者は1営業日以内に応答しますが、対象はその医療提供者に紐付け（attribution）済みで、オプトアウトしていない患者に限られます。

そのためには、レガシーシステムがほとんど備えていないものが3つ必要です。1つ目は、加入者を医療提供者に紐付けるattributionの仕組みです。2つ目は、加入者がいつでも変更できるオプトアウトで、初回利用の前、保険適用の開始から1週間以内、そして毎年、平易な言葉で通知しなければなりません。3つ目は一括エクスポートです。必須の標準に、担当患者全体（パネル）について問い合わせる医療提供者のためのFHIR Bulk Data Accessが含まれているためです。

Payer-to-Payer API

加入者が新たに加わると、新しい保険者は許可を求め（こちらはオプトイン方式です）、保険適用の開始から1週間以内に、以前の保険者と並行して加入している保険者の特定を始めます。特定できたら、1週間以内に5年分のデータを要求します。支払情報と自己負担を除いた請求・受診データ、USCDIデータ、却下されたもの以外の事前承認とその非構造化文書です。以前の保険者は1営業日以内に応答します。重複加入がある場合、このやり取りを少なくとも四半期ごとに繰り返します。

難しいのは、外へ返す応答ではありません。一度もテストしたことのない保険者からデータを受け取り、規則の求めるとおり自社の加入者記録に取り込むことです。

Prior Authorization API

UMの中核にまで手が入るのが、このAPIです。APIは、事前承認が必要な給付対象の物品とサービスを一覧にし、それぞれに必要な文書を示し、HIPAA（米国の医療情報の保護と電子取引に関する法律）に準拠した申請と応答に対応し、保険者が承認したのか（終了日付き）、却下したのか（具体的な理由付き）、追加情報を必要としているのかを示さなければなりません。

CMSはここで、HL7のDa Vinciプロジェクトによる3つの実装ガイドを推奨していますが、義務にはしていません。Coverage Requirements Discovery（CRD）、Documentation Templates and Rules（DTR）、Prior Authorization Support（PAS）です。実際には、給付ルールと文書の質問票を、PDFのポリシーマニュアルではなく機械可読な形にする必要があります。WEDI（米国の医療データ交換の業界団体）の調査で、保険者は「事前承認ポリシーのデジタル化」を課題の上位3つに挙げています。

トランザクションそのものについては、HHSが保険者に余地を与えました。2024年2月28日、HHSは執行裁量（enforcement discretion）を発表しています。CMSによれば、CMSのNational Standards Groupは「電子的なFHIR事前承認プロセスの一部としてX12 278標準を使わないことを選んだHIPAA対象事業者に対し、HIPAA Administrative Simplificationに基づく執行措置をとらない」としています。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を、有効期限を2026年1月1日として挙げていました。マッピングを書き始める前に、どのバージョンに合わせて構築するかを決めておいてください。

自社開発システムに足りないことが多いもの

規則の要求から考えると、まず確認すべきギャップは次のとおりです。

文書ではなくレコードとしての事前承認。ステータス、タイムスタンプ、却下理由コード、終了日は、変更時に書き込まれ、履歴を持つフィールドでなければなりません。ファクスで送った判断には、構造化された対のデータが必要です。
給付ルール。どのサービスに承認が必要で、それぞれにどんな文書が要るのかは、APIが返せるデータになっていなければなりません。多くのプランでは、それがポリシーのPDFと審査担当者の頭の中にあります。
FHIRとしての請求データ。請求と受診のデータはFHIRリソースとして出力し、医療提供者と他の保険者向けには支払情報と自己負担を除き、加入者向けには残す必要があります。
加入者の本人特定と履歴。他の保険者のデータを自社の加入者と照合し、新規加入者の以前の保険者を見つけるには、属性情報と加入履歴が必要です。それが1か所にまとまっていないこともあるでしょう。
同意の状態。Provider Accessのオプトアウトと、Payer-to-Payerのオプトインです。どちらもいつでも変更でき、要求のたびに確認されなければなりません。州は、受給者のオプトインを、その人が加入するMedicaidマネージドケアプランにも引き継ぐ必要があります。
1営業日という期限。メインフレームの夜間バッチで足りるデータもあれば、それでは遅すぎるデータもあります。APIが応答するかどうかだけでなく、判断からAPIに反映されるまでの時間を測ってください。
委託先ベンダー。UMの委託先ベンダーが判断を下している場合、そのデータは自社の1営業日の義務に間に合うよう届かなければなりません。WEDIの2026年2月の調査では、「委託先の第三者が、異なるシステムとの接続で課題を抱えていること」が、保険者の課題の1位でした。

業界の進み具合

2026年3月10日に公表されたWEDIの2026年2月の調査によると、API要件について「10%がまだ作業に着手していない」とのことです。2025年10月には33%でした。また、「推定費用が500万ドルを超えるとの回答が15%（2025年10月）から25%（2026年2月）へと顕著に増加した」とも報告しています。サンプルは小さく、回答は86件、そのうち52%が保険者です。全数調査ではなく、傾向を示すものとして読んでください。

2027年1月1日までの11週間計画

10月中旬の時点で、MA組織や州のFFSプログラムに残されているのは約11週間です。4つのAPIをゼロから作るには足りません。ですから、この計画で大事なのは順序と、初日に何を示せるかです。

今週：自社の期限と出発点を確認する。期限は1月1日か、それとも後に始まるrating periodやプラン年度か。すでに稼働しているもの、つまりPatient Access APIとProvider Directory API、2026年の指標、却下理由を書き出します。
第1〜2週：すべてのデータ要素を出所に対応づける。APIごとに、そのデータを現在どのシステムが持っているか（請求、UM、加入資格、医療提供者ネットワーク、臨床）と、データがどれだけ新しいかを書き留めます。
第1〜3週：FHIRレイヤーをどこに置くかを決める。レガシーシステムの前にFHIRサーバーやファサードを置き、変更イベントや高頻度の抽出でデータを流し込むほうが、基幹システムそのものをFHIRに対応させるより、たいてい早く済みます。時間がかかるのは、マッピングとデータフィードです。
第2〜7週：共通部品から先に作る。事前承認レコード、同意とattribution、加入者照合です。4つのAPIはすべて、これらに依存しています。
第4〜9週：APIを構築する。Patient Accessへの追加、一括エクスポートを備えたProvider Access、双方向のPayer-to-Payer、そして給付ルールを読み込んだPrior Authorization APIです。
第8〜11週：実際の相手とテストする。医療提供者のEHRベンダー、他の保険者、UMの委託先ベンダーです。同意の変更、理由付きの却下、そして1営業日以内に加入者に届くステータス変更をテストします。
2027年1月1日：稼働させて測定する。初日から1営業日ルールに対する遅延を追跡し、終わっていないものを日付付きの一覧にしておきます。

11週間で足りないなら、12月ではなく今のうちに、コンプライアンス担当チームと弁護士に相談してください。その際は、1月1日に何が稼働し、残りがいつ続くのかを示す計画を持っていきます。

rating periodが2027年7月1日に始まるMedicaidマネージドケアプランや、プラン年度がもっと後に始まるQHP保険会社は、同じ手順を余裕を持って進められます。それでも、今すぐ始めてください。テストの相手になる保険者や医療提供者は、1月1日に稼働するからです。

まだ変わりうること

CMS-0062-P。CMSは2026年4月14日、後続の規則案を公表しました。現在は推奨にとどまる実装ガイドを2027年10月1日から義務化し、同じ日から医薬品を電子事前承認の対象に加え、HHSが事前承認トランザクションのHIPAA標準としてX12 278に代えてFHIRを採用する、という内容です。既存の期限については「本提案は、これらの遵守期限を変更するものではない」としています。意見募集は2026年6月15日に締め切られ、2026年10月16日時点で、Federal Registerに最終規則は掲載されていません。2024年の規則に合わせて構築し、ガイドのバージョンは設定で変えられるよう1か所にまとめておいてください。

バージョン。Da Vinciのガイドは更新が続いています。FY 2027 IPPS最終規則は、ONC（米国保健福祉省の医療IT担当部局）の新しい事前承認認証基準で認証されたEHRについて、「Da Vinci IGのバージョン2.2の使用が求められる」と記しています。自社のPrior Authorization APIがやり取りするのは、まさにこうしたシステムです。

どれも、待つ理由にはなりません。規則は確定しており、期限は規則の条文に書かれていて、CMSは10月8日にもそれを繰り返しています。

ご相談先

当社が手がけるのは、APIの裏側にあるシステムです。請求、受診、承認データのFHIRマッピング、古い請求処理・UMプラットフォームからの変更フィード、同意とattributionのロジック、そして1営業日ルールが守られていることを示すテストです。基幹システムが古い場合や、作った人がもう社内にいない場合は、レガシーシステムの保守サービスが入口になります。期限がプラットフォームの入れ替えの最中に重なるなら、ERPモダナイゼーションもご覧ください。

請求処理やUMのプラットフォームに、これらのAPIを提供してくれるベンダーがいないなら、office@c9group.devまでご連絡ください。当社は医療分野の弁護士ではなく、エンジニアです。対象範囲や契約の問題は顧問弁護士に委ね、当社はその回答に沿って構築します。