AWS 기술 블로그

기업간 전자 문서 교환을 위한 AWS상에서의 EDI처리 자동화

EDI(전자 데이터 교환)는 기업 간에 비즈니스 문서와 정보를 표준화된 전자 형식으로 교환하는 시스템으로, 국내외에서도 다양한 분야에 도입되면서, 온라인 전자상거래, 주문 관리, ERP 등 다양한 시스템과의 연계도 활발해지고 있습니다. 하지만 아직도 많은 산업에서 내부 프로세스, 비용, 보안, 인력 부담, 그리고 기술적 문제등의 이유로 도입이 더딘 상태입니다. 대표적인 예시로 미국 건강보험품질위원회(CAQH)에 따르면 매년 보험금 청구의 약 10%, 수억 건이 여전히 종이 문서로 접수되고 있다고 추정됩니다. 이러한 종이 문서를 활용한 청구 방식은 처리 비용이 10배 더 많이 드는 반면, 환급 주기는 수 시간에서 수주까지 길어지면서 운영 비용과 리소스의 불균형을 초래합니다.

청구 운영팀은 현재 여러 가지 종이 양식(전문 서비스용의 CM-1500, 병원 서비스용의 UB-04, ADA Dental 양식 및 맞춤형 독점 양식)을 노동집약적인 워크플로우와 데이터의 수작업 입력을 통해 처리하고 있습니다. 표준화된 EDI(전자 데이터 교환) 파이프라인을 통해 처리되는 전자 청구와 달리, 종이 문서 청구를 처리하기 위해서는 OCR 기술과 이에 맞는 독자적인 포맷을 사용하는 별도의 시스템이 필요합니다. 이러한 처리 방식은 더 높은 오류율을 초래하고 HIPAA 규정 준수 위험을 증가시킵니다. 이런 비효율성으로 인해 연간 수백만 달러의 행정 비용이 발생하며, 이는 회원 서비스 및 케어 관리 이니셔티브에 투자할 수 있는 재원입니다.

이러한 종이 문서 처리로 발생하는 문제를 해결하기 위해, 수동 개입을 최소화하면서 기존 전자 청구 처리와 원활하게 통합되는 맞춤형 솔루션을 소개합니다. 이 게시물에서는 건강보험 문서를 처리할 때 AWS Transfer Family, Amazon Bedrock Data Automation(BDA), 그리고 AWS B2B Data Interchange을 사용하여 종이에서 전자 청구로 전환하는 프로세스를 자동화하는 방법을 설명합니다. 해당 솔루션은 UB-04 병원 청구 양식을 5010 X12 837 형식(HIPAA 의무 전자 청구 표준)으로 변환하는 데 중점을 두지만, 동일한 아키텍처를 보험, 공급망, 소매, 제조 등 기업이 실제 문서를 표준화된 전자 데이터 교환(EDI) 형식으로 변환해야 하는 다른 산업에도 적용할 수 있습니다.

솔루션 개요

솔루션은 아래 그림과 같이 AWS 서버리스 아키텍처를 활용한 3단계 워크플로우를 통해 종이로 된 보험 청구서를 표준화된 전자 거래로 변환합니다. 문서 처리, AI 기반 데이터 추출, EDI 변환 기능을 결합함으로써 건강보험 플랜은 HIPAA 규정을 준수하면서 수동 데이터 입력을 제거할 수 있습니다.

아래 다이어그램은 솔루션 아키텍처입니다.

[그림 1. 종이 청구 데이터를 837 포맷으로 변환하는 이벤트 기반 아키텍처 다이어그램]

엔드투엔드 워크플로우는 다음과 같습니다:

1단계: AWS Transfer Family를 활용한 안전한 파일 수집

1. 클레임운영팀은 Transfer Family 웹 앱 인터페이스를 통해 스캔된 종이 청구서를 업로드합니다. 이 인터페이스는 브라우저를 통해 Amazon S3 버킷에 안전하게 접근할 수 있는 기능을 제공합니다.

2단계: BDA를 통한 지능적인 데이터 추출

2. Amazon S3는 지정된 S3 버킷 접두사에 새로운 객체가 업로드되면 이를 감지하고 Amazon EventBridge 이벤트를 트리거합니다. EventBridge 규칙은 이러한 이벤트를 감지하여 AWS Lambda 함수를 호출하고, Lambda 한수는 클레임을 처리합니다.

3. Lambda 함수는 BDA를 호출해 클레임 양식에서 구조화된 데이터를 추출합니다.

3단계: AWS B2B Data Interchange를 통한 변환 및 EDI 생성

4. B2B Data Interchange는 S3 위치에서 새로운 JSON 문서를 모니터링하고 추출된 데이터를 표준화된 837 EDI 트랜잭션으로 자동 변환합니다.

5. 생성된 EDI 파일은 S3 버킷으로 전달되어 건강보험의 기존 청구 처리 시스템과 통합이 가능해집니다.

이 아키텍처는 의료 보험사의 수익에 직접적인 영향을 미치는 중요한 비즈니스 성과를 제공합니다:

  • 지능형 데이터 추출 및 자동화된 처리를 통해 청구 건당 처리 비용을 최대 80% 절감
  • 처리 시간이 며칠에서 몇 분으로 단축되어 환급 주기가 대폭 빨라짐
  • 수동 처리 대비 낮은 오류율로 데이터 정확도가 향상
  • 엔드투엔드 암호화, 세분화된 액세스 제어 및 감사 로깅을 통해 HIPAA 규정 준수 강화
  • 운영 효율성이 높아져 직원들은 데이터 입력 대신 더 가치 있는 회원 서비스에 집중 가능
  • 별도의 인력 증원 없이도 연간 수백만 건에서 수천만 건까지 원활하게 확장 가능

이 솔루션에 사용되는 모든 서비스는 HIPAA 적격 서비스로, AWS와의 사업자 협정 추가약정((BAA)이 체결된 경우 전자 보건 정보(ePHI)를 포함한 업무에 사용이 가능합니다.

기존 OCR 및 EDI 솔루션이 상당한 초기 투자를 요구하는 반면, 이 서버리스 접근 방식은 피크 처리 기간에도 일관된 성능을 제공하면서 인프라 관리 오버헤드를 크게 줄여 줍니다.

다음 섹션에서는 이 워크플로우의 각 단계를 자세히 살펴보며, AWS 서비스가 어떻게 유기적으로 작동하여 원활한 청구 처리 환경을 구현하고, 수동 처리 오류를 줄이며, 환급 주기를 단축하고, 비용을 절감하는 등 주요 운영 과제를 해결하는지 설명합니다.

1단계: AWS Transfer Family 웹 앱을 통한 안전한 파일 수집

종이 청구서 처리 자동화의 첫 번째 과제는 안전하고 사용자 친화적인 문서 수집입니다. 클레임운영팀은 종이 기반 청구서의 디지털 사본을 업로드할 수 있는 명확하고 안전한 방법이 필요합니다. Transfer Family 웹 앱은 코드가 필요 없는 완전 관리형 브라우저 기반 웹 앱으로, 인증된 사용자가 특정 Amazon S3 버킷에 파일을 나열, 업로드, 다운로드, 복사 및 삭제할 수 있도록 합니다. 이 솔루션은 클레임운영팀에 제로-코드 인터페이스를 제공하여 의료 양식을 안전하게 제출할 수 있도록 합니다.

이 서비스는 AWS Identity and Access Management(IAM) Identity Center를 통해 사용자를 인증하며, 직원이 업계 표준 프로토콜(SAML 2.0 또는 OIDC)을 통해 기존 조직 자격 증명을 사용할 수 있도록 합니다. 인증 후 사용자는 맞춤형 브랜드 웹 포털에 접속하여 [그림 2]와 같이 드래그 앤 드롭 기능으로 청구 양식(CMS-1500, UB-04, ADA 치과 또는 사용자 지정)을 업로드합니다.

[그림 2] 파일 관리 옵션이 표시된 Transfer Family 웹 앱 인터페이스

웹 인터페이스는 업로드 과정을 간소화할 뿐만 아니라, 각 작업을 포괄적인 감사 추적에 기록하여 HIPAA 준수 요구사항을 충족하는 감사 기능도 제공합니다. 사용자는 업무 상황에 맞게 개별 업로드나 일괄 업로드를 수행할 수 있습니다. [그림 3]은 업로드된 UB-04 양식이 어떻게 저장되는지를 보여줍니다.

[그림 3] inbound 폴더에 업로드된 UB-04 양식

아래 프로세스 전반에 걸쳐 보안이 철저히 유지됩니다: 모든 파일은 전송 중에는 SSL/TLS로, 저장 시에는 Amazon S3 내 AWS Key Management Service(AWS KMS)를 통해 암호화됩니다. 지정된 클레임 입력을 위한 접두사에 새 양식이 도착하면 EventBridge 규칙이 자동으로 감지해 Lambda 함수를 트리거하고, 파이프라인의 2단계(BDA를 활용한 지능형 데이터 추출)로 전달합니다.

2단계: BDA를 활용한 지능형 데이터 추출

안전한 데이터 수집 후에는 복잡한 의료 양식에서 구조화된 데이터를 정확히 추출하는 것이 중요한 과제입니다. Bedrock Data Automation(BDA)는 Amazon Bedrock 내의 완전관리형 기능으로, 문서, 이미지, 오디오, 비디오와 같은 비정형 멀티모달 콘텐츠에서 가치 있는 인사이트를 손쉽게 추출할 수 있도록 지원합니다. BDA는 여러 AI 모델과 서비스를 관리할 필요 없이 통합된 API 환경을 제공하며, 추출된 데이터를 검증할 수 있도록 내장된 시각적 근거와 신뢰도 점수를 함께 제공합니다.

문서 및 이미지 유형의 경우, BDA는 데이터가 있는 그대로 추출되야 할 때(standard)와 맞춤형으로 추론되어야 할 때(custom output)를 정의할 수 있도록 하여, 프로세스에 대한 완전한 제어를 제공합니다. 이러한 유연성은 블루프린트 구성(blueprint configurations)을 통해 제공됩니다.

BDA blueprints로 의료 데이터 추출

BDA에서 블루프린트(blueprints)는 문서에서 데이터를 어떻게 추출하고 처리할지 정의합니다. 각 블루프린트에는 다양한 의료 서식 유형에 맞게 조정할 수 있는 필드 정의, 지침, 검증 규칙, 출력 스키마 사양이 포함됩니다. 블루프린트는 콘솔에서 자연어 프롬프트로 생성하거나, 더 정밀한 제어를 위해 수동으로 정의할 수 있습니다.

기술 팀은 CMS-1500, UB-04, ADA 치과 양식 및 맞춤형 양식에 대해 별도의 블루프린트를 생성하고, 시간이 지남에 따라 필요에 맞게 개선해야 합니다. 각 블루프린트는 특정 양식 유형에서 정확히 추출할 데이터 요소와 어떻게 구조화되어야 하는지에 대한 방식을 지정합니다.

[그림 4]는 AWS 콘솔에서 UB-04 서식을 위한 블루프린트 구성을 보여주며, 여기서 환자 정보, 진단 코드, 시술 세부사항과 같은 필드를 정의할 수 있습니다.

[그림 4] AWS 콘솔 상에서 확인한 UB-04 양식 필드 수준 지침, 추출 결과 및 신뢰도 점수(Confidence)

청구 양식을 처리할 때 EventBridge에 의해 트리거된 Lambda 함수는 BDA API를 호출하여 문서를 분석하고 특정 양식 유형으로 분류한 후, 추출에 적합한 blueprint를 적용하고 관련 의료 데이터를 추출합니다. 이렇게 생성된 구조화된 JSON 문서는 원본 종이 청구서의 모든 정보를 포함하며, 후속 처리가 가능한 상태가 됩니다.

[그림 5]는 UB-04 양식에서 Amazon Bedrock Data Automation이 생성한 구조화된 JSON 출력을 보여줍니다. 이 비정형 문서 데이터를 기계 판독이 가능한 구조화된 필드로 변환하는 과정은 후속 처리에 필수적이며, 각 키-값 쌍은 종이 서식에서 추출된 핵심 청구 정보를 나타냅니다.

[그림 5] BDA를 활용한 UB-04양식에서 추출한 필드가 포함된 JSON 문서

아래 JSON은 예시 UB-04 문서에서 추출한 데이터 일부입니다.

{
    "claim": {
        "admit_diagnosis": "E871",
        "statement_covers_period": "01012024 through 03012024",
        "patient_birthdate": "08221967",
        "provider_address": "555 Main St",
        "npi": "0011002200"
    }
}

데이터 추출이 완료되면, Lambda 함수는 구조화된 JSON 문서를 B2B Data Interchange가 모니터링하도록 지정된 Amazon S3 접두사에 저장하여, 수동 개입 없이 EDI 변환 단계로 전달합니다.

3단계: AWS B2B Data Interchange를 통한 변환 및 EDI 생성

종이 청구서에서 추출한 구조화된 데이터는 기존 청구 시스템이 처리할 수 있는 표준화된 HIPAA 5010 X12 837 거래로 변환하는 최종 단계를 거칩니다. EDI(전자 데이터 교환)는 의료 분야 전반에서 제공자(의료 기관), 지불자(보험사) 및 기타 관계자 간 전자 거래에 사용되는 표준화된 포맷입니다.

B2B Data Interchange는 JSON 및 XML 데이터 형식과 EDI(전자 데이터 교환) 문서 간의 변환 및 생성을 자동화합니다. 이 서비스는 로우-코드 인터페이스와 사용량 기반 과금(pay-as-you-go) 방식을 제공하여, 조직 간 거래 데이터의 관리 및 교환에 수반되는 시간, 복잡성, 비용을 줄여줍니다.

EDI 변환 파이프라인 이해하기

B2B Data Interchange는 추출된 UB-04 JSON 데이터를 4가지 구성 요소를 통해 표준화된 837 기관 거래로 변환합니다:

  • 프로필(Profiles): 조직의 비즈니스 정보와 연락처 정보를 저장합니다. 이 정보는 거래 파트너와 공유됩니다.
  • 트랜스포머(Transformers): BDA에서 추출된 JSON 데이터가 837 포맷의 표준 EDI 세그먼트로 어떻게 매핑되는지 정의합니다.
  • 트레이딩 기능(Trading capabilities): S3 위치를 모니터링하고 변환을 트리거하는 자동화 처리 파이프라인을 구축합니다.
  • 파트너십(Partnerships): 각 구성 요소를 연결하여 자동 문서 교환이 가능하도록 합니다.

B2B Data Interchange의 중요한 혁신 중 하나는 Amazon Bedrock 기반의 생성형 AI 지원 EDI 매핑 기능입니다. [그림 6]에 표시된 “매핑 생성(Generate Mapping)” 기능은 추출된 청구 데이터와 샘플 EDI 거래를 분석하여 적절한 매핑을 자동으로 제안함으로써, 구현 시간을 며칠에서 몇 분으로 단축시키고, 전문적인 역량이 없는 팀도 EDI 변환을 쉽게 활용할 수 있도록 지원합니다.

[그림 6] AWS B2B Data Interchange서비스의 Generate Mapping기능

구성이 완료되면 그 후, 전체 변환 프로세스는 자동화됩니다:

  • B2B Data Interchange는 BDA에서 생성된 새로운 JSON 문서를 감지하기 위해 Amazon S3 접두사를 모니터링합니다.
  • 감지 후에는 구조화된 JSON 데이터를 X12 837 문서로 변환합니다.
  • 선택적으로 변환된 문서를 X12 표준에 따라 검증합니다.
  • 생성된 EDI 파일은 통합을 위해 지정된 아웃풋 디렉터리에 전달됩니다.

다음은 생성된 X12 파일의 샘플 세그먼트로, 표준화된 의료 청구의 주요 구성 요소를 보여줍니다:

ST*837*0001*005010~ (Transaction start segment)
BHT*0019*00*0123*20250422*2020*CH~ (Header information)
NM1*41*2*Acme Hospital*****46*12345~ (Provider data)
PER*IC*JOHN DOE*TE*1234567890~ (Contact information)

프로세스의 최종 결과물인 표준화된 EDI 파일 세트는 기존 청구 처리 시스템과의 통합을 위해 사용됩니다. 각 파일에는 원본 종이 양식에서 추출된 모든 구조화된 의료 정보가 포함되어 있습니다. 이러한 파일들은 표준 명명 규칙을 따르며, 거래 파트너 ID별로 정리되어 있어 손쉬운 통합이 가능합니다.

[그림 7] Amazon S3 버킷 접두사에 저장된 결과물

모든 변환 활동은 Amazon CloudWatch에 로그로 기록되고, Amazon EventBridge로 이벤트가 전송되어 문서의 양, 상태, 오류를 종합적으로 모니터링할 수 있습니다. 운영팀은 맞춤형 CloudWatch 대시보드를 구성하여 문서 처리량, 변환 상태, 처리 오류 등을 추적할 수 있습니다.

실습하기

위 설명을 통해 솔루션의 동작 방식을 이해했으므로 AWS 환경에서 직접 실습해볼 수 있습니다. CloudFormation 스택을 시작하기 전에 다음 사전 요구 사항을 완료하세요:

사전 요구 사항

  1. AWS IAM Identity Center 구성
    1. 문서에 따라 AWS IAM Identity Center를 구성합니다.
    2. AWS Managed 혹은 외부 IdP로 신원을 구성합니다.
    3. 가이드를 보고 ‘ClaimsOperationsTeam’ 그룹을 생성합니다.
    4. 기본 정보 섹션의 그룹 ID를 기록해둡니다.
    5. 필요 시, MFA 세팅을 구성합니다.
  2. 해당 리전에서 액세스 권한 부여를 활성화합니다.
    1. 문서에 따라 접속 권한 인스턴스를 생성하고 생성한 IdC ARN에 연결합니다.

솔루션 배포하기

“Launch Stack”을 클릭하여 AWS CloudFormation 템플릿을 AWS계정에 배포합니다.

진행 시, 아래 파라미터를 입력합니다.

  • BusinessName: 가상의 회사명
  • GranteeIdentifier: 위 사전 요구 사항에서 생성한 그룹의 그룹 ID (예: 1232148-46571-71ca-xxxx-xxxxxxxxxxxx)
  • IdentityCenterInstanceArn: Identity Center ARN (예: arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxx)
  • InboundPath: inbound/
  • NamePrefix: paper-claims
  • OutboundPath: outbound/

설치 확인하기

배포 완료 후, 아래와 같은 절차로 테스트합니다.

  1. ‘ClaimsOperationsTeam’ 그룹을 AWS Transfer Family console의 webapp에 연결(Assign)합니다.
  2. webapp상의 web app URL을 통해 접속하고 IAM Identity Center에 등록한 그룹의 사용자로 로그인합니다.
  3. 샘플 UB-04 파일 ‘inbound’ 폴더에 업로드합니다. (샘플 파일)
  4. ‘outbound’ 폴더에서 EDI 결과물을 확인합니다.

정리하기

향후 비용 발생을 방지하려면 CloudFormation 스택을 삭제하세요. 삭제 방법은 CloudFormation 콘솔에서 스택 삭제 안내를 참고하시기 바랍니다.

결론

이 글에서는 AWS 서비스를 활용해 종이 기반 보험 청구서를 전자 형식으로 변환하는 방법을 안내했습니다. 이 솔루션은 처리 비용을 최대 80%까지 절감하고, 처리 시간을 수일에서 몇 분으로 단축하며, 데이터 정확성을 향상시킬 수 있도록 도와줍니다. 또한 HIPAA 요건을 충족하면서도 이러한 노동 집약적 프로세스를 자동화함으로써, 조직이 소중한 자원을 수동 데이터 입력에서 회원 중심의 사업으로 전환할 수 있게 해줍니다.
CloudFormation 템플릿으로 손쉽게 배포하여 청구 자동화를 테스트하고 해당 솔루션이 여러분의 과제를 어떻게 해결할 수 있는지 경험해 보시기 바랍니다.

TaeHoon Kyeong

TaeHoon Kyeong

경태훈 솔루션즈 아키텍트는 미디어 및 엔터테인먼트 고객들이 비즈니스 목표를 달성할 수 있도록 최적의 클라우드 아키텍처를 설계할 수 있도록 돕습니다. 또한, 미디어 및 엔터테인먼트 산업 영역에 생성형AI 기술 적용 방안을 검토하는 워킹 그룹 활동을 하고 있습니다. 과거에는 SAP 데브옵스 개발자로 근무한 경험이 있습니다.