메디케어의 새로운 지급 모델은 AI를 위한 것이지만, 대부분의 기술 세계는 전혀 몰라

ACCESS(Ambulatory Care Coordination for Equity and Social Services)는 미국 메디케어가 새롭게 도입한 지불 모델로, 환자의 진료 사이(between-visit)에서 발생하는 AI 기반 케어 코디네이션 활동에 대해 처음으로 공식적인 청구 코드를 부여한다. 기존에는 의사가 환자를 직접 대면한 시점에만 보험 청구가 가능했지만, ACCESS는 AI 에이전트가 환자 상태를 원격 모니터링하고, 정기적인 체크인 통화를 수행하며, 주거 지원 같은 사회복지 서비스 연계, 복약 순응도 추적 등을 수행하는 일련의 자동화 워크플로우 자체를 보험금 청구 대상으로 인정한다. 기술적으로 이는 LLM 기반 대화형 에이전트, RPM(Remote Patient Monitoring) 디바이스 연동, FHIR/HL7 표준을 통한 EHR 통합, 그리고 사회적 결정 요인(SDOH) 데이터를 다루는 그래프 기반 환자 케이스 관리 시스템이 결합된 복합 스택을 전제로 한다. 즉, "AI가 의료 행위의 일부로서 청구 가능한 단위"가 된 최초의 정부 차원 메커니즘인 셈이다.

개발자/엔지니어 입장에서 이 변화의 핵심은 헬스케어 AI 시장의 비즈니스 모델이 근본적으로 바뀐다는 점이다. 그동안 의료 AI 스타트업이 직면한 가장 큰 장벽은 "기술은 작동하지만 누가 비용을 지불하느냐"였는데, ACCESS는 그 지불 흐름을 정부가 직접 보장한다. 결과적으로 voice AI 에이전트 플랫폼(예: Hume, Retell, Vapi 유형), 환자 코디네이션 워크플로우 엔진, EHR 통합 미들웨어(Redox, Particle Health 같은), HIPAA 호환 LLM 서빙 인프라에 대한 수요가 폭발할 가능성이 크다. 한국 개발자 관점에서는 카카오헬스케어·네이버 헬스케어·국내 디지털 치료기기 회사들이 미국 진출 시 참고할 레퍼런스 모델이 되며, 동시에 국민건강보험공단의 비대면 진료 수가 체계 논의에도 직접적인 영향을 줄 수 있다.

당장 액션 아이템 관점에서 짚어둘 것은 세 가지다. 첫째, **컴플라이언스 스택**: HIPAA BAA 체결 가능한 클라우드(AWS HIPAA-eligible, Azure for Healthcare)와 LLM 제공자(Anthropic, OpenAI의 HIPAA-eligible 티어) 선택이 진입 조건이며, 모든 AI 인터랙션은 감사 로그(audit trail)와 시간 기록(time-tracking)이 필수다 — ACCESS 청구 자체가 "AI가 무엇을, 언제, 얼마나 수행했는가"의 증빙을 요구한다. 둘째, **상호운용성**: FHIR R4 리소스(특히 CarePlan, Communication, ServiceRequest)와 SMART on FHIR 인증 흐름을 다룰 수 있어야 하고, SDOH 코딩(LOINC, SNOMED CT의 Z-code)에 대한 이해가 필요하다. 셋째, **에이전트 설계 패턴**: 단발성 챗봇이 아니라 며칠~몇 주에 걸친 장기 메모리, 사람 임상의로의 에스컬레이션 정책, 환각 시 환자 안전 영향을 고려한 가드레일이 핵심이며, LangGraph·CrewAI 같은 멀티 에이전트 프레임워크와 long-running task용 워크플로우 엔진(Temporal, Inngest)의 헬스케어 적용 패턴이 곧 표준이 될 가능성이 높다.