Build an agentic AI healthcare claims pipeline with Amazon Bedrock and AWS HealthLake

🖼️ 인포그래픽

Build an agentic AI healthcare claims pipeline with Amazon Bedrock and AWS HealthLake 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

이 글은 CMS-1500 의료 청구서를 S3 업로드부터 문서 추출, HealthLake 검증, FHIR 청구 리소스 생성, SNS 알림까지 자동화하는 에이전트형 청구 처리 파이프라인을 설명한다.

📌 핵심 요약

의료 업계에서는 종이 기반 청구 양식 처리 비용이 여전히 크며, 스캔 문서의 데이터 추출 기술이 발전했더라도 입력 오류나 낮은 신뢰도의 추출 결과를 사람이 보정해야 하는 문제가 남아 있다.
제안된 솔루션은 CMS-1500 PDF가 S3 버킷에 업로드되면 Lambda가 트리거되고, Bedrock Data Automation이 문서에서 구조화 데이터를 추출한 뒤 AgentCore에서 실행되는 Strands 에이전트가 HealthLake의 환자·보험자·의료인·보장 정보를 조회해 검증하는 흐름이다.
검증이 통과되면 에이전트는 표준 FHIR 청구 리소스를 HealthLake에 생성하고, 청구 처리자를 위한 기술적 요약과 환자에게 전달할 수 있는 상태 설명을 JSON 응답 및 SNS 알림 형태로 만든다.
실패 시나리오에서는 필요한 Coverage 리소스를 누락시켜 보험 보장 정보를 찾지 못하는 상황을 만들고, 에이전트가 이를 감지해 환자가 이해할 수 있는 오류 안내 메시지를 생성하는 과정을 보여준다.
성공 시나리오에서는 보험자 ID에 문자 O와 숫자 0의 불일치 같은 데이터 차이가 있어도 에이전트가 다른 검색 기준을 사용해 일치 항목을 찾고, 청구 항목·진단·시술·금액·보장 확인 내용을 요약해 사람 검토자가 빠르게 확인할 수 있도록 한다.

🧩 주요 포인트

의료 업계에서는 종이 기반 청구 양식 처리 비용이 여전히 크며, 스캔 문서의 데이터 추출 기술이 발전했더라도 입력 오류나 낮은 신뢰도의 추출 결과를 사람이 보정해야 하는 문제가 남아 있다.
제안된 솔루션은 CMS-1500 PDF가 S3 버킷에 업로드되면 Lambda가 트리거되고, Bedrock Data Automation이 문서에서 구조화 데이터를 추출한 뒤 AgentCore에서 실행되는 Strands 에이전트가 HealthLake의 환자·보험자·의료인·보장 정보를 조회해 검증하는 흐름이다.
검증이 통과되면 에이전트는 표준 FHIR 청구 리소스를 HealthLake에 생성하고, 청구 처리자를 위한 기술적 요약과 환자에게 전달할 수 있는 상태 설명을 JSON 응답 및 SNS 알림 형태로 만든다.
실패 시나리오에서는 필요한 Coverage 리소스를 누락시켜 보험 보장 정보를 찾지 못하는 상황을 만들고, 에이전트가 이를 감지해 환자가 이해할 수 있는 오류 안내 메시지를 생성하는 과정을 보여준다.
성공 시나리오에서는 보험자 ID에 문자 O와 숫자 0의 불일치 같은 데이터 차이가 있어도 에이전트가 다른 검색 기준을 사용해 일치 항목을 찾고, 청구 항목·진단·시술·금액·보장 확인 내용을 요약해 사람 검토자가 빠르게 확인할 수 있도록 한다.

🧠 상세 정리

1. 수작업 청구 처리의 문제와 자동화 목표

글은 의료 청구 처리에서 종이 기반 양식이 여전히 큰 비용 요인이라는 문제의식에서 출발한다. 스캔 문서와 이미지에서 데이터를 추출하는 기술이 발전했지만, 양식을 작성한 사람의 입력 오류나 디지털화 과정에서 낮은 신뢰도로 추출된 값은 여전히 보정이 필요하다고 설명한다. 따라서 목표는 단순히 문자를 읽어내는 것이 아니라, 추출된 값이 실제 환자·보험·의료 제공자 데이터와 맞는지 검증하고 오류 상황을 처리할 수 있는 자동화 흐름을 만드는 것이다. 이 글의 솔루션은 수작업 시간을 줄이면서도 자동 검증을 통해 정확도를 유지하는 청구 처리 파이프라인을 제시한다.

2. 전체 아키텍처와 처리 흐름

솔루션은 의료 제공자가 CMS-1500 청구 양식 PDF를 S3 버킷에 업로드하는 순간 시작된다. 파일 도착 이벤트가 Lambda를 트리거하고, Lambda는 문서 처리와 에이전트 호출을 조율하는 감독자 역할을 한다. Bedrock Data Automation은 청구서에서 구조화된 정보를 추출해 JSON 형태로 내보내며, 이후 Lambda가 AgentCore를 호출해 해당 문서를 처리하게 한다. AgentCore는 HealthLake를 조회하고 청구 리소스를 생성한 뒤 요약 JSON 응답을 만들며, Lambda는 최종적으로 SNS를 통해 성공 또는 오류 응답을 전달한다.

3. 문서 추출 단계와 Bedrock Data Automation의 역할

문서 처리 단계에서는 Bedrock Data Automation이 전통적인 OCR, 머신러닝 모델, 생성형 AI를 결합해 청구 양식에서 필요한 데이터를 추출한다. 글은 Blueprints를 사용해 어떤 데이터를 어떤 방식으로 추출할지 지정할 수 있으며, 사전 구축된 템플릿이나 사용 사례에 맞춘 커스텀 구성을 사용할 수 있다고 설명한다. 출력에는 추출 필드와 표에 대한 신뢰도 점수와 바운딩 박스 데이터가 포함된다. 이 예제에서는 CMS-1500 청구 양식의 다양한 형식 변형에도 예측 가능한 JSON 표현을 만들도록 커스텀 출력이 구성된다.

4. AgentCore와 Strands 에이전트의 HealthLake 검증

AgentCore는 Strands 에이전트를 호스팅하며, 에이전트는 HealthLake와 상호작용하기 위해 create_fhir_claim과 search_fhir_resources라는 두 도구를 사용한다. 에이전트의 첫 단계는 청구 양식의 참조 정보로 사용할 Insured, Patient, Practitioner, Coverage 정보를 HealthLake에서 찾는 것이다. 첫 시도는 직접 메서드 호출과 기본 검색 매개변수를 사용하고, 일치 항목이 없으면 이전 도구 호출을 확인한 뒤 청구 JSON의 고신뢰도 속성을 바탕으로 다른 검색 조건을 두 차례 더 시도한다. 참조 리소스를 찾으면 에이전트는 청구의 FHIR 표현을 생성해 HealthLake에 보낸다.

5. Lambda의 결정적 감독과 응답 생성

이 아키텍처에서 Lambda는 단순한 트리거를 넘어 에이전트형 워크플로의 결정적 감독자 역할을 맡는다. 문서가 S3에 생성되면 Lambda가 실행되고, 각 문서가 정상 처리되었는지 또는 예외 처리를 위해 데드 레터 큐로 보내져야 하는지 확인한다. 에이전트는 명시적인 도구 호출을 관찰하고 FHIR 리소스를 생성한 뒤 Lambda에 결과를 돌려준다. 결과 JSON에는 청구 ID가 생성된 경우 해당 ID, 청구 처리자를 위한 응답, 환자를 위한 응답이 포함되며, 처리자 응답은 경고나 관찰 내용으로 쓰이고 환자 응답은 수정이 필요한 오류를 제출자에게 알리는 역할을 한다.

6. 배포 준비와 실행 절차

솔루션 배포 전에는 관리자 권한이 있는 AWS 계정, Amazon Bedrock의 Anthropic Claude Sonnet 4.6 접근 권한, NodeJS 24 이상, npm 11.5 이상, Python 3.13 이상, AWS CDK 2.1025 이상이 필요하다고 제시된다. 배포는 GitHub 저장소를 복제한 뒤 npm 설치, Python 가상환경 생성, requirements 설치, AgentCore 설정과 실행, Lambda 패키징, CDK bootstrap 및 deploy 순서로 진행된다. 배포 후에는 SNS 콘솔에서 Agent-Notifications 토픽을 선택하고 이메일 구독을 만든 뒤 확인 메일 링크를 눌러 알림을 받을 수 있게 한다. 이 절차는 문서 업로드 후 처리 결과를 이메일로 확인하는 데 필요한 운영 경로까지 포함한다.

7. 실패 시나리오: 누락된 참조 리소스 감지

첫 번째 사용 예시는 HealthLake에 필요한 참조 리소스 중 하나를 의도적으로 누락해 실패 상황을 만드는 것이다. 샘플 데이터 폴더의 load_sampledata.py를 사용해 Patient, Insured, Practitioner만 로드하고 Coverage는 로드하지 않은 상태에서 sample1_cms-1500-P.pdf를 S3 버킷의 input 폴더 아래에 업로드한다. 이 경우 에이전트는 보험 보장 정보를 시스템에서 찾지 못해 청구를 처리할 수 없다고 판단한다. SNS 메시지는 AnyHealth Plus Medicare plan의 정책 번호 G4683A를 보험사에 확인하거나 사무실에 연락해 보장 정보를 갱신하라는 식의 환자 친화적인 설명을 제공한다.

8. 성공 시나리오: 데이터 불일치 보정과 청구 요약

두 번째 사용 예시는 누락된 Coverage 리소스를 HealthLake에 추가해 성공 처리가 가능하도록 만든 뒤, 보험자 ID의 마지막 문자가 숫자 0과 문자 O처럼 서로 다르게 기록된 불일치를 에이전트가 극복하는 상황을 보여준다. PDF를 다시 처리하면 에이전트는 처음 ID 검색에 실패했지만 이름 검색을 통해 보험자를 식별했다는 사실을 요약에 포함한다. 또한 환자 John Doe, 진단 Back Pain M54.9, 생년월일 기반 환자 식별, Dr. Jane Smith 식별, Medicare 정책 G4683A 보장 확인, 네 개의 CPT 시술과 총액 660달러를 함께 요약한다. 이 메시지는 사람 검토자가 청구 성공 여부와 관찰된 데이터 차이를 빠르게 파악할 수 있도록 돕는다.

9. 모범 사례, 비용 고려, 결론

글은 설계 시점의 AI 활용이 실행 시점의 AI 활용보다 낫다는 모범 사례를 강조한다. 이 솔루션에서는 문서 처리 단계와 HealthLake 초기 쿼리 패턴이 미리 알려져 있으므로, 런타임에 작업 순서를 추론하게 하기보다 로직을 명시적으로 인코딩해 신뢰성과 유지보수성을 높였다고 설명한다. 또한 S3와 Lambda를 사용해 에이전트를 결정적으로 감독하고, 에이전트는 도구 호출 관찰과 FHIR 리소스 생성에 집중하게 했다. 비용 측면에서는 AgentCore 런타임, Bedrock Data Automation 페이지당 비용, 모델 토큰 비용, HealthLake 저장 비용이 언급되며, Lambda·S3·SNS 비용은 이 구조에서 문서당 미미하다고 정리한다.

🧾 핵심 주장 / 시사점

핵심 설계 포인트는 에이전트에게 모든 흐름을 맡기는 것이 아니라, Lambda가 성공·실패 판정을 감독하고 에이전트는 검증·검색·FHIR 생성 같은 제한된 역할을 수행하게 한 점이다.
문서 추출 결과의 신뢰도와 HealthLake의 기존 리소스 조회를 결합하면, 단순 OCR 자동화보다 입력 오류와 데이터 불일치를 더 현실적으로 다룰 수 있다.
성공 사례에서 문자 O와 숫자 0의 차이를 다른 검색 기준으로 우회한 부분은, 의료 청구 자동화에서 완전한 데이터 일치보다 설명 가능한 예외 처리와 사람 검토용 요약이 중요하다는 점을 보여준다.

✅ 액션 아이템

S3 업로드 후 Lambda 트리거, Bedrock Data Automation 추출, Strands 에이전트 검증, HealthLake 기록·SNS 알림까지 단계별 책임 구간을 고정한다.
검증이 통과한 경우에만 표준 FHIR 청구 리소스를 생성하고, 성공 요약에 진단·시술·금액·보장 항목이 모두 반영되었는지 점검한다.
Coverage 누락 실패와 보험자 ID O/0 불일치 사례를 포함해 환자 안내 메시지와 처리자용 JSON 요약의 예외 분기 포맷을 정합성 있게 정비한다.