CMS-0057-F와 2027년 1월 1일: 자체 청구·사전승인 시스템에서 보험자 API를 구현하는 법

CMS(미국 메디케어·메디케이드 서비스센터)의 상호운용성 및 사전승인 최종 규칙(CMS Interoperability and Prior Authorization final rule, CMS-0057-F)에 따라 Medicare Advantage 조직(MA organization, 메디케어 급여를 민간 플랜으로 제공하는 보험사)과 주(州) Medicaid(저소득층 공공의료보험) 및 CHIP(아동 건강보험 프로그램)의 행위별 수가제(fee-for-service) 프로그램은 2027년 1월 1일까지 네 가지 FHIR API를 가동해야 합니다. 사전승인 데이터까지 담도록 확장된 기존 Patient Access API와 새로 도입되는 Provider Access API, Payer-to-Payer API, Prior Authorization API입니다. Medicaid 관리의료(managed care) 플랜, CHIP 관리의료 기관, 연방 건강보험 거래소에서 Qualified Health Plan(QHP, 적격 건강보험 플랜)을 판매하는 보험사는 그날 또는 그 이후에 시작하는 첫 rating period(요율 산정 기간)나 플랜 연도부터 적용됩니다. 2026년 10월 16일 기준으로 남은 기간은 11주이며, CMS는 일정을 미루지 않았습니다.

규칙의 운영 부분은 이미 시행 중입니다. 2026년부터 적용 대상 보험자(impacted payers)는 사전승인을 거절할 때마다 구체적인 사유를 제시하고, 정해진 기한 안에 결정을 내리고, 사전승인 지표를 공개해야 합니다.

청구, 이용도 관리(utilization management, UM), 가입자 시스템이 이 네 가지 API를 제공하는 벤더의 제품이라면 개발의 대부분은 벤더의 몫입니다. 귀사가 할 일은 설정, 사전승인 규칙의 디지털화, 가입자 안내문, 그리고 파트너와의 테스트입니다.

이 글은 그 밖의 경우를 위한 것입니다. 청구 처리 엔진, UM 워크플로, 가입자 데이터가 직접 소유한 시스템에 있는 플랜과 주 기관으로, 자체 개발한 시스템이든, 업그레이드가 불가능할 만큼 커스터마이징한 시스템이든, 수십 년 동안 자체 수정이 쌓인 Medicaid Management Information System(MMIS, 주 Medicaid 관리 정보 시스템)이든 마찬가지입니다. 이런 시스템에 맞는 API는 누구도 만들어 주지 않습니다. 저희는 변호사가 아니라 엔지니어입니다. 이 글은 규칙이 시스템에 무엇을 요구하는지 설명할 뿐, 그것이 귀사의 계약에 어떻게 적용되는지는 다루지 않습니다.

일정

최종 규칙은 2024년 2월 8일 연방 관보(Federal Register)에 게재되었고 2024년 4월 8일에 발효되었습니다. 네 가지 API의 준수 기한은 모두 같으며, 규칙은 이를 “MA 조직과 주 Medicaid 및 CHIP FFS 프로그램은 2027년 1월 1일까지, Medicaid 관리의료 플랜과 CHIP 관리의료 기관은 2027년 1월 1일 또는 그 이후에 시작하는 rating period까지, FFE의 QHP 보험사는 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(입원 진료 선지불 제도) 최종 규칙은 2027년에 이를 병원의 선택적 보너스 항목으로 바꾸었습니다.
• UM 위탁 기관과 TPA(제3자 관리 기관). 자체 의무는 없지만, 보험자의 의무가 이들의 시스템을 거쳐 이행됩니다. QHP 보험사에 대해 규칙은 이들이 “자신의 준수와 모든 위탁 기관 또는 하위 기관의 준수에 책임을 진다”고 거듭 밝히고 있습니다.

빠져나갈 길은 거의 없고, 이 시점에서는 어느 것도 큰 도움이 되지 않습니다. 주는 Medicaid 또는 CHIP FFS 프로그램에 대해 1회에 한해 1년 연장을 신청할 수 있지만, 신청은 Advance Planning Document(APD, 연방 자금 지원을 위한 주의 사전 계획서)에 담아야 하고 “준수 기한 전에 승인”받아야 합니다. Medicaid 수급자의 90퍼센트 이상이 관리의료에 가입한 주는 면제를 신청할 수 있고, QHP 보험사는 거래소에 예외를 요청할 수 있습니다. 플랜 자체에 대해 CMS는 “MA 조직이나 Medicaid 관리의료 플랜에 대해서는 연장이나 면제를 제안하지 않았다”고 적었습니다. 주는 API 구축 비용에 대해 90퍼센트의 상향된 연방 매칭 자금(enhanced federal matching funds)을 청구할 수도 있으며, APD를 통해 건별로 승인됩니다.

각 API가 해야 하는 일

네 가지 모두 맞춤형 시스템에 흔히 없는 한 가지에 의존합니다. 상태 이력을 갖춘 구조화 데이터로서의 사전승인입니다. 이것을 한 번 만들면 네 API가 모두 여기서 데이터를 읽습니다.

Patient Access API: 사전승인 추가

귀사는 2021년 1월 1일부터 청구, 진료 기록(encounter), 임상 데이터에 대해 이 API를 운영해 왔습니다. 2027년부터는 물품과 서비스에 대한 사전승인도 건별로 제공해야 합니다. 상태, 승인 또는 거절 날짜, 종료일, 승인된 물품과 서비스, 거절된 경우 구체적인 사유, 의료 제공자가 제출한 관련 구조화 문서입니다. 데이터는 보험자가 요청을 받은 뒤 “늦어도 1영업일 후까지” 제공되어야 하고, 상태가 바뀌면 1영업일 안에 갱신되어야 하며, 승인이 유효한 동안과 마지막 변경 후 최소 1년 동안 보관되어야 합니다.

결정을 자유 형식 메모로 기록하거나 상태를 팩스로만 보내는 UM 시스템은 수정 없이는 이 데이터를 공급할 수 없습니다.

Provider Access API

네트워크 내 의료 제공자는 환자의 데이터를 요청할 수 있습니다. 대상은 2016년 1월 1일 이후 진료일의 데이터로, 의료 제공자 지급 내역(remittance)과 본인부담을 뺀 청구 및 진료 기록, USCDI(미국 상호운용성 핵심 데이터 세트) 임상 데이터 클래스, 사전승인 정보입니다. 보험자는 1영업일 안에 응답하되, 그 의료 제공자에게 귀속(attribution)된 환자 중 옵트아웃하지 않은 환자에 대해서만 응답합니다.

이를 위해서는 레거시 시스템에 거의 없는 세 가지가 필요합니다. 첫째, 가입자를 의료 제공자와 연결하는 귀속 프로세스입니다. 둘째, 가입자가 언제든 바꿀 수 있는 옵트아웃이며, 최초 이용 전, 보장 개시 후 1주일 이내, 그리고 매년 쉬운 말로 된 안내문을 보내야 합니다. 셋째, 대량 내보내기입니다. 필수 표준에 환자군(panel) 전체를 조회하는 의료 제공자를 위한 FHIR Bulk Data Access가 포함되어 있기 때문입니다.

Payer-to-Payer API

가입자가 새로 들어오면 새 보험자는 허락을 구하고(이쪽은 옵트인 방식입니다), 보장 개시 후 1주일 안에 이전 보험자와 동시 가입 보험자를 확인하기 시작합니다. 확인이 끝나면 1주일 안에 5년 치 데이터를 요청합니다. 지급 내역과 본인부담을 뺀 청구 및 진료 기록, USCDI 데이터, 거절된 건을 제외한 사전승인과 그 비구조화 문서입니다. 이전 보험자는 1영업일 안에 응답합니다. 동시 가입이 있으면 이 교환을 적어도 분기마다 반복합니다.

어려운 부분은 내보내는 응답이 아닙니다. 한 번도 테스트해 본 적 없는 보험자에게서 데이터를 받아, 규칙이 요구하는 대로 귀사의 가입자 기록에 통합하는 일입니다.

Prior Authorization API

UM의 핵심까지 손이 닿는 것이 바로 이 API입니다. 이 API는 사전승인이 필요한 보장 대상 물품과 서비스를 나열하고, 각각에 필요한 문서를 명시하고, HIPAA(미국의 의료정보 보호 및 전자거래 관련 법)를 준수하는 요청과 응답을 지원하고, 보험자가 승인했는지(종료일 포함), 거절했는지(구체적 사유 포함), 추가 정보가 필요한지를 알려야 합니다.

CMS는 여기서 HL7 Da Vinci 프로젝트의 구현 가이드 세 가지를 권고하지만 의무화하지는 않습니다. 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 리소스로 나와야 하며, 의료 제공자와 다른 보험자에게는 지급 내역과 본인부담을 빼고, 가입자에게는 남겨 두어야 합니다.
• 가입자 식별과 이력. 다른 보험자의 데이터를 귀사의 가입자와 매칭하고 신규 가입자의 이전 보험자를 찾으려면 인구통계 정보와 보장 이력이 필요한데, 이를 한곳에 모아 두지 않았을 수도 있습니다.
• 동의 상태. Provider Access는 옵트아웃, Payer-to-Payer는 옵트인이며, 둘 다 언제든 바꿀 수 있고 요청마다 확인해야 합니다. 주는 수급자의 옵트인을 그 사람의 Medicaid 관리의료 플랜에도 전달해야 합니다.
• 1영업일 시한. 메인프레임 야간 배치로 충분한 데이터도 있고, 그것으로는 너무 느린 데이터도 있습니다. API가 응답하는지만 보지 말고, 결정부터 API에 반영되기까지의 시간을 측정하십시오.
• 위탁 벤더. UM 위탁 벤더가 결정을 내린다면 그 데이터가 귀사의 1영업일 의무에 맞춰 도착해야 합니다. WEDI의 2026년 2월 조사에서는 “위탁받은 제3자가 서로 다른 시스템과의 연결에 어려움을 겪는 문제”가 보험자들의 과제 중 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주입니다. API 네 개를 처음부터 만들기에는 부족하므로, 이 계획의 핵심은 순서, 그리고 첫날 무엇을 보여 줄 수 있느냐입니다.

1. 이번 주: 기한과 출발점 확인. 기한이 1월 1일입니까, 아니면 그 뒤에 시작하는 rating period나 플랜 연도입니까? 이미 가동 중인 것을 목록으로 만듭니다. Patient Access API와 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 위탁 벤더입니다. 동의 변경, 사유가 붙은 거절, 1영업일 안에 가입자에게 도달하는 상태 변경을 테스트합니다.
7. 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일 현재 연방 관보에 최종 규칙은 게재되지 않았습니다. 2024년 규칙에 맞춰 구축하되, 가이드 버전은 설정으로 바꿀 수 있도록 한곳에 모아 두십시오.

버전. Da Vinci 가이드는 계속 바뀌고 있습니다. FY 2027 IPPS 최종 규칙은 ONC(미국 보건복지부의 의료 IT 담당 기관)의 새 사전승인 인증 기준으로 인증받은 EHR에 대해 “Da Vinci IG 버전 2.2의 사용이 요구될 것”이라고 적고 있습니다. 귀사의 Prior Authorization API가 상대할 시스템이 바로 이것들입니다.

어느 것도 기다릴 이유는 되지 않습니다. 규칙은 확정되었고, 기한은 규칙 본문에 적혀 있으며, CMS는 10월 8일에도 이를 다시 확인했습니다.

도움이 필요하시면

저희는 API 뒤에 있는 시스템을 다룹니다. 청구, 진료, 승인 데이터의 FHIR 매핑, 오래된 청구 및 UM 플랫폼에서 나오는 변경 피드, 동의와 귀속 로직, 그리고 1영업일 규칙이 지켜진다는 것을 보여 주는 테스트입니다. 핵심 시스템이 오래되었거나 그것을 만든 사람들이 떠났다면 레거시 시스템 유지보수 서비스가 출발점이 되고, 기한이 플랫폼 교체 도중에 닥친다면 ERP 현대화를 참고하십시오.

귀사의 청구 또는 UM 플랫폼에 이 API를 제공해 줄 벤더가 없다면 office@c9group.dev로 연락 주십시오. 저희는 의료 전문 변호사가 아니라 엔지니어입니다. 적용 범위와 계약 문제는 귀사의 법률 자문이 판단할 일이며, 저희는 그 답에 맞춰 구축합니다.