의료 청구 팀이 여전히
EOB 데이터를 수동으로 입력하는 이유

책상 앞의 청구 담당자

화요일 아침에 중소 규모 청구 사무소에 가 보면 항상 같은 풍경을 볼 수 있습니다. 한 직원이 한쪽 화면에는 PDF 더미를, 다른 쪽 화면에는 진료 관리 시스템을 열어 두고, 자를 급여 설명서(EOB) 양식 위에 줄 단위로 움직이며 읽고 있습니다. 그 자는 비유가 아닙니다. 일부 청구 담당자가 조밀하고 다중 열로 구성된 보험사 문서에서 위치를 추적하기 위해 여전히 사용하는 실제 도구입니다.

EOB(Explanation of Benefits, 급여 설명서)는 보험사가 의료 청구를 처리한 후 발송하는 문서입니다. 청구된 금액, 플랜이 보장한 항목, 보험사가 지급한 금액, 조정 또는 거부된 금액, 환자가 부담해야 할 금액을 세부적으로 보여줍니다. 이는 임상 청구의 재정적 대응물로, 이것이 없으면 의료 기관은 지급을 조정하거나, 조정 사항을 입력하거나, 환자에게 청구할 금액을 알 수 없습니다. 모든 EOB는 열고, 읽고, 진료 관리 시스템에 수동으로 입력해야만 다음 단계를 진행할 수 있습니다.

의료 지급 업체 OrboGraph가 상세히 문서화한 수동 입력 프로세스는 모든 EOB의 모든 청구 항목에 대해 최소 10단계 절차를 따릅니다: 책임 당사자 찾기, 환자 ID 입력, 서비스 날짜 확인, 올바른 서비스 항목 선택, 지급 금액 입력, 수표 또는 EFT 번호 입력, 조정 금액 입력, 잔액 청구 금액 입력, 추가 서비스 항목마다 반복, 다음 청구로 이동. 청구 항목당 10단계, EOB당 수십 개의 청구, 월 수백 개의 EOB가 있습니다.

OrboGraph의 분석에 따르면 입력 담당자는 전체 필드의 최대 2%를 잘못 입력합니다. 청구당 15~25개 필드가 있으므로 청구 4건 중 약 1건에는 어떤 형태의 오류가 존재합니다. 월 10,000건의 종이 청구를 처리하는 중간 규모 제공자의 경우, 매월 2,500건의 청구 오류에 노출되는 셈입니다. 백서의 결론은 단호합니다: "대부분의 병원, 의사 그룹 및 제공자는 이 영역에서 평범함을 감수하기로 결정했습니다. 그것이 '표준'으로 간주되기 때문입니다."

그 숫자—2% 필드 오류율, 청구 4건 중 1건 영향—은 기술 실패가 아닙니다. 수십 년 동안 변하지 않은 워크플로우의 구조적 결과입니다. 청구 담당자가 약한 고리가 아닙니다. 인간이 밀도 높은 보험사 문서를 문자 하나하나 필사해야 한다는 요구 사항이 약한 고리입니다.

ERA가 이 문제를 해결하지 못한 이유

의료 청구 분야에서 일한 지 얼마 안 되었더라도 이런 반론을 들어봤을 것입니다. EOB는 구식 문제라는 주장입니다. 전자 보상 통지(ERA, Electronic Remittance Advice)—HIPAA가 의무화한 ASC X12 835 거래로, 기계가 읽을 수 있는 보상 데이터를 진료 관리 시스템에 직접 전달합니다—는 수동 입력을 없애기 위한 것이었습니다. HIPAA는 모든 건강보험사가 제공자 요청 시 ERA를 제공하도록 요구했고, CMS는 2014년 1월 1일부터 EFT 및 ERA 운영 규칙을 의무화했습니다. 10년이 넘게 지났는데도 왜 아직도 수동 입력을 하고 있을까요?

그 답은 규정이 요구하는 것과 시장이 제공하는 것 사이의 간극에 있습니다. HIPAA는 건강보험사가 ERA를 제공할 것을 요구합니다. 제공자가 이를 수신할 것을 요구하지 않으며, PM 소프트웨어 업체가 소규모 진료소를 위한 저렴한 ERA 자동 입력 기능을 구축할 것을 요구하지도 않습니다. 또한 전자 도입만으로는 완전히 흡수할 수 없는 이차 지불자 잔여 업무도 해결하지 못합니다.

이러한 분열은 잘 문서화되어 있습니다. 의료재무관리협회(Healthcare Financial Management Association)가 2025년 9월 의료 경영진 241명을 대상으로 실시한 설문조사에 따르면, 의료 기관의 41% 이상이 여전히 지급 조정에 주로 수동 워크플로우에 의존하고 있습니다. 대형 의료 시스템은 일차 지불자에 대해 80~90%의 전자 도입률을 달성했습니다. 더 작고 지역적인 제공자—얇은 마진으로 운영되며 청구 담당자가 1~3명인 곳—은 여전히 EOB의 50% 이상을 종이나 PDF로 받습니다. 이들은 현대화를 거부하는 낙오자가 아닙니다. 이들은 산재보험, 자동차보험, 주별 메디케이드 프로그램을 지불자 구성에 포함하는 진료소들입니다—이 중 어느 것도 전자 ERA를 보내지 않습니다. BCBS, UnitedHealthcare, Aetna에 ERA 등록을 한 진료소도 매달 다른 수십 개의 지불자 유형에서 종이 EOB를 받습니다.

또한 대부분의 논의가 건너뛰는 소프트웨어 현실이 있습니다. 835 파일을 처리하려면 진료 관리 시스템에 내장된 변환 소프트웨어—또는 835를 수신하고 변환하여 구조화된 데이터를 전달할 수 있는 중개 청구소(clearinghouse)—가 필요합니다. 뉴멕시코 블루크로스 블루실드(Blue Cross Blue Shield of New Mexico)의 ERA 동반 가이드는 "제공자는 진료 관리 소프트웨어 공급업체와 청구 서비스 및/또는 청구소에 연락하여 ERA 호환성과 자동 입력 소프트웨어 가용성을 확인해야 합니다"라고 명시합니다. 규정은 파일을 파이프라인에 넣을 뿐입니다. PM 시스템에 넣어주지는 않습니다.

가장 작은 진료소—개인 의사, 독립 치료사, 농촌 클리닉—의 경우 월 400달러 이상의 PM 구독료, 청구소 수수료, 835 설정의 기술적 부담이 결합되어 완전 전자 보상 처리는 손이 닿지 않는 영역이 됩니다. 종이 EOB는 우편으로 도착하거나 지불자 포털에서 PDF로 다운로드되며, 청구 담당자는 항상 해왔던 일을 합니다. 문서를 읽고 입력하는 것입니다.

형식 분산 기계

EOB(Explanation of Benefits, 급여 설명서)를 하나 보았다면, 정확히 하나만 본 것이다. 이 문서를 동일한 형식으로 만드는 보험사는 두 곳이 없다. Blue Cross가 오른쪽 상단 모서리에 인쇄하는 청구 번호를 Aetna는 왼쪽 헤더 블록에 인쇄한다. UnitedHealthcare가 표의 열에 나열하는 CPT 코드를 Medicare는 같은 줄에 여섯 개의 다른 데이터 포인트와 함께 "서비스 세부 정보" 섹션에 묻어 둔다. 일부 보험사는 가로 표를 사용하고, 다른 곳은 세로 섹션을 사용한다. 일부는 환자 부담금을 네 개의 하위 열로 나누고, 다른 곳은 한 줄로 압축한다. 900개 이상의 미국 건강 보험사의 6,000개 이상의 EOB 레이아웃에 걸친 변형을 곱하면, 표준 해결책이 없는 문서 처리 문제가 된다.

이 변형은 우연이 아니다. 보험사는 회원 대상 자료(EOB 포함)를 차별화하는 데 많은 투자를 한다. 이는 브랜드 접점이자 회원 경험의 일부다. Blue Cross EOB는 Blue Cross 문서처럼 보인다. UnitedHealthcare EOB는 UnitedHealthcare 문서처럼 보인다. 보험사는 시각적 레이아웃을 표준화할 유인이 없다. EOB는 커뮤니케이션 도구로서 규제 기능뿐만 아니라 경쟁력 있는 브랜딩 기능도 수행하기 때문이다. CAQH CORE 운영 규칙은 건강 플랜과 제공자 간에 전송되는 데이터를 표준화한다. 청구 담당자 책상에 도착하는 PDF는 표준화하지 않는다.

그리고 보험사는 예고 없이 레이아웃을 변경한다. 단일 필드 재배치("허용 금액"을 1페이지 4열에서 2페이지 2열로 이동)는 해당 보험사를 위해 구축된 모든 추출 템플릿을 조용히 깨뜨린다. 청구 전문가는 며칠 또는 몇 주 후에 조정 수치가 맞지 않을 때까지 이를 알아차리지 못한다.

이것이 템플릿 기반 추출이 EOB에 실패하는 핵심 이유다. 템플릿은 고정 좌표 집합이다. "1페이지의 (x, y) 위치에 있는 청구 번호." 20개의 다른 보험사가 20개의 다른 좌표를 사용하면 20개의 템플릿이 필요하다. 보험사가 레이아웃을 변경하면(그리고 그들은 일상적으로 변경한다) 해당 템플릿은 조용히 잘못된 데이터를 생성한다. 보험사별 템플릿의 유지 관리 부담은 일회성 구성 비용이 아니다. 지속적인 운영 세금이며, 진료소에 추가되는 모든 새 보험사마다 증가한다.

볼륨은 형식 문제를 악화시킨다. 진료소가 월 60건의 EOB를 처리할 때, 한 명의 청구 담당자는 마찰 없이 6개의 보험사 형식을 정신적으로 해독할 수 있다. 팀이 15개 이상의 보험사에서 수백 건의 EOB를 일괄 처리할 때도 마찬가지지만, 인지 부하만 감당하기 어려워진다. 한 달에 20개 보험사에서 500건의 EOB를 처리하는 청구 담당자는 시간당 20번의 맥락 전환을 한다. 각 전환은 새로운 레이아웃, 새로운 열 구조, 새로운 약어 집합을 정신적으로 파싱해야 한다. 오류 곡선은 추가 보험사마다 가팔라진다.

나타나지 않은 클리어링하우스

대부분의 진료 관리자에게 클리어링하우스가 무엇을 하는지 물어보면, 대답은 대체로 "청구를 처리한다"는 식입니다. 클리어링하우스는 청구 전송에 탁월합니다—제공자로부터 837 전자 청구를 받아 오류를 검토하고 올바른 지불자에게 전달합니다. 또한 835 ERA 파일을 제공자에게 다시 라우팅하여 자동 게시를 지원합니다. Waystar, Availity, Office Ally 및 경쟁사들은 수십 년 동안 이 파이프라인을 최적화해 왔습니다.

클리어링하우스가 하지 않는 일—애초에 하도록 설계되지 않은 일—은 PDF 또는 종이 EOB에서 구조화된 데이터를 추출하는 것입니다. 우편으로 도착하는 종이 EOB나 지불자 포털에서 다운로드한 PDF는 클리어링하우스 워크플로우에서 완전히 벗어나 있습니다. 클리어링하우스는 이를 볼 수 없습니다. 청구 소프트웨어도 읽을 수 없습니다. 청구 직원이 이를 열어 읽고 입력합니다.

이것은 클리어링하우스 모델의 결함이 아닙니다. 범주상의 차이입니다. 청구 제출(837)과 보상 라우팅(835)은 전자 데이터 교환 문제입니다. 종이 EOB 추출은 문서 이해 문제입니다. 이들은 근본적으로 다른 기술을 요구합니다. 동일한 문서—EOB—가 전자(835 ERA) 및 종이(PDF) 형태로 모두 도착할 수 있다는 사실은 각 형식을 처리하는 데 완전히 다른 인프라가 필요하다는 점을 모호하게 만듭니다.

그 결과 대부분의 청구 회사가 보지 못하는 기술 스택 격차가 발생합니다. 대안을 본 적이 없기 때문입니다. 한쪽에는: PM 시스템(Tebra 월 제공자당 $150-500, AdvancedMD $429-729)이 클리어링하우스(Waystar 청구당 $0.20-0.35, Office Ally 월 $35)에 연결되어 있습니다. 이 스택은 전자 청구를 종단 간 처리합니다. 다른 쪽에는: 사람이 읽고 해석하고 입력해야 하는 종이 및 PDF EOB 더미가 있습니다. 수익 주기의 양측은 결코 만나지 않으며, 그 격차의 인건비—청구 건당 EOB 데이터 입력 비용 분석에서 자세히 설명한 대로—는 적은 규모에서도 연간 수만 달러에 달합니다.

이 격차에서 활동하는 전문 공급업체가 있습니다. OrboGraph, Anatomy Financial 등은 스캔한 EOB를 받아 자동 게시용 보상 파일을 생성하는 종이-835 변환 서비스를 제공합니다. 그러나 이들은 별도의 제품, 별도의 계약, 별도의 통합입니다—대부분의 진료소가 이미 비용을 지불하는 핵심 PM+클리어링하우스 번들의 일부가 아닙니다. "내 PM 시스템이 지불을 처리한다"고 가정하는 청구 회사 소유자는 PDF EOB가 그 주장의 예외라는 사실을 들은 적이 없습니다.

업계가 어떻게 이를 받아들이게 되었는가

OrboGraph의 10년 전 백서에서 가장 시사하는 바가 큰 문장은 오류율 데이터가 아닙니다. 바로 "평범함을 감수하기로 결정했다"는 표현입니다. 수동 EOB 입력은 너무 오랫동안, 그리고 너무 보편적으로 기본 방식이 되어 왔기 때문에 대부분의 청구 운영팀은 이를 해결 가능한 문제로 보지 않게 되었습니다. 이는 운영 기준선에 너무 깊이 내재된 비용으로, 손익계산서에 별도 항목으로 나타나지도 않습니다. 그저 사업을 운영하는 데 드는 비용일 뿐입니다.

이러한 관성을 강화하는 요인은 여러 가지입니다. 첫 번째는 비용의 비가시성입니다. 연봉 5만 달러의 청구 담당자는 하루의 40~65%를 EOB 데이터 입력에 사용하지만, 청구 회사는 업무 시간이 아닌 징수액의 일정 비율로 고객에게 청구합니다. 수동 입력의 인건비는 고객에게 보이지 않으며, 청구 회사는 이를 최적화해야 할 개별 비용이 아닌 마진 감소로 내부화합니다. 건당 2.75~4.65달러의 인건비는 CAQH Index 벤치마크와 BLS 임금 데이터에서 일관되게 확인되지만, 청구서에는 결코 나타나지 않습니다.

두 번째는 수동 입력에 내재된 정상화 효과입니다. 시장의 모든 청구 회사가 인건비 예산의 동일한 비율을 EOB 데이터 입력에 사용한다면, 어느 누구도 이를 개선해야 할 경쟁적 인센티브를 갖지 못합니다. 경쟁의 장은 평평합니다. 자동화된 대안과 비교하여 운영을 벤치마킹할 때만 비용이 가시화됩니다.

세 번째는 더 미묘합니다. 수동 EOB 입력은 일자리를 창출합니다. 청구 담당자 10명을 둔 청구 회사에서 EOB 데이터 입력은 정규직 4~6명에 해당하는 인력을 소비합니다. 추출 단계를 자동화한다고 해서 그 청구 담당자들이 사라지는 것은 아닙니다. 단지 그들의 업무 시간이 데이터 입력에서 징수율을 직접적으로 개선하는 더 높은 가치의 업무, 즉 거절 분석, 과소 지급 회수, 지불자 계약 대사, 환자 잔액 후속 관리로 이동할 뿐입니다. 그러나 이러한 전환을 위해서는 경영진이 직원을 데이터 입력 작업자가 아닌 수익 보호자로 인식해야 하며, 이는 대부분의 소규모 청구 회사가 아직 이루지 못한 문화적 전환입니다.

MGMA에 따르면 의료 기관은 지급된 청구 건의 7~15%에서 과소 지급을 수용하고 이의를 제기하지 않습니다. 청구 담당자가 키 입력 수준의 데이터 입력에 묻혀 있으면 과소 지급 분석은 이루어지지 않습니다. 10단계 수동 입력 절차는 주의력 세금과 같습니다. 익숙하지 않은 EOB 레이아웃에서 "허용 금액"을 찾는 데 쓰는 모든 1분은 허용 금액이 계약된 요율과 일치하는지 묻지 않는 1분입니다. 추출을 자동화하는 청구 회사는 비용 분석에서 보여주듯 연간 12,000~18,000달러의 인건비를 절약할 뿐만 아니라, 수동 워크플로가 남겨두는 수익도 회수하고 있습니다.

격차를 해소할 수 있는 지점

문제를 명확히 보면 해결책도 분명해집니다. PM 시스템을 교체하는 것이 아닙니다. 모든 지불자를 ERA에 등록하는 것도 아닙니다. 이차 지불자(secondary payer)의 꼬리는 완전히 전환되지 않을 것이기 때문입니다. 클리어링하우스가 EOB 추출 기능을 추가하기를 기다리는 것도 아닙니다. 문서 이해와 전자 데이터 교환은 서로 다른 역량이기 때문입니다. 해결책은 추출 단계입니다. 즉, 어떤 지불자의 어떤 레이아웃의 EOB PDF든 읽어서 빌러가 검토하고 가져올 수 있는 구조화된 스프레드시트로 데이터를 출력하는 도구입니다. 문자 하나하나 입력하는 대신 말입니다.

이것이 바로 AI 기반 추출, 특히 비전 언어 모델을 사용하는 방식이 이 분야에서 실패해 온 지불자별 템플릿 방식과 다른 점입니다. AI는 각 지불자의 고정 페이지 좌표를 매핑하는 대신 EOB를 의미적으로 읽습니다. 각 섹션이 어디에 있는지가 아니라 무엇을 의미하는지 이해하는 것입니다. 필요한 출력 열을 정의하면 됩니다: 환자 이름, 청구 번호, 서비스 날짜, CPT 코드, 청구 금액, 허용 금액, 지급 금액, 공제액, 본인 부담금(Coinsurance), 공동 부담금(Copay), 환자 책임액, 조정 코드, 수표 번호. AI는 문서 구조를 이해하여 페이지 어디에서든 각 값을 찾아냅니다. 인간 빌러가 익숙하지 않은 레이아웃을 훑어보고, 상단 근처에서 환자 이름을 찾고, 열 헤더를 따라 허용 금액을 찾는 것과 같은 방식입니다. ImageToTable.ai가 열 이름 추출이라고 부르는 이 방식은 하나의 열 정의로 Blue Cross EOB, Aetna EOB, Medicare 보상 통지서, 산재보험 EOB를 같은 배치에서 처리할 수 있습니다. 지불자별 템플릿이 필요 없습니다. 레이아웃이 바뀌어도 다시 구축할 필요가 없습니다.

출력물은 Excel 스프레드시트 또는 CSV 파일로, 검토 후 PM 시스템에 가져올 수 있는 상태입니다. 빌러의 역할은 데이터 입력 작업자—청구 라인당 10단계, 월 15,000회 작업—에서 데이터 검토자로 바뀝니다. 추출된 스프레드시트에서 이상 징후를 살펴보고, 플래그가 지정된 항목을 확인하고, 배치를 가져오는 것입니다. 키보드에서 키보드로의 전사 단계가 제거됩니다. 나머지는 모두 그대로입니다.

청구 건당 경제성도 그에 따라 달라집니다. EOB 하나당 5~8분의 수작업 입력 대신, 빌러는 추출된 데이터를 검토하는 데 1~2분을 사용합니다. ERP와 클리어링하우스 스택은 그대로 유지됩니다. 이것은 시스템 교체가 아닙니다. 현재 기술 스택이 해결할 수 없는 단 하나의 격차, 즉 PDF EOB가 수익 주기에 들어가기 전에 스프레드시트의 행이 되어야 하는 순간을 연결하는 다리입니다.

청구 관리자가 물어야 할 질문은 "이 기술이 존재하는가?"가 아닙니다. 존재합니다. 진짜 질문은 "월간 EOB 처리량이 어느 수준이 되면 수동 입력이 구조적으로 더 이상 정당화될 수 없는가?"입니다. 대부분의 소규모 청구 대행사의 회수 기준점은 월 300~400건의 종이 및 PDF EOB입니다. 그 이하의 처리량에서는 기존 인력으로 인건비를 감당할 수 있습니다. 그 이상에서는 수동 입력 비용과 추출 절감액 간의 격차가 빠르게 벌어지며, 확보된 추가 청구 담당자 시간은 수익 보호 업무에 투입되어 회수율을 직접적으로 개선합니다.

EOB 데이터 입력이 수십 년간 수동으로 유지된 구조적 이유에는 해답이 있습니다. 형식의 파편화는 템플릿 기반 도구로는 해결할 수 없었습니다. ERA 도입은 2차 지불자의 롱테일까지 도달하지 못했습니다. 클리어링하우스는 문서 이해가 아닌 청구 라우팅을 위해 구축되었습니다. 이러한 것들이 하룻밤 사이에 바뀌지는 않습니다. 그러나 10년 전에는 불가능했던 추출 단계, 즉 지불자별 설정 없이 모든 지불자의 EOB 레이아웃을 읽는 것이 이제는 해결된 기술적 문제입니다. 병목 현상은 더 이상 기술이 아닙니다. 병목 현상이 존재한다는 인식의 부재입니다.

자주 묻는 질문

클리어링하우스가 종이 EOB를 자동으로 처리하지 못하는 이유는 무엇인가요?

클리어링하우스는 전자 데이터 교환, 즉 837 클레임 전송과 835 ERA 파일을 제공자와 지불자 간에 라우팅하기 위해 구축되었습니다. 이는 표준화된 디지털 형식입니다. 종이 또는 PDF EOB는 시각적 이해가 필요한 비정형 문서입니다. 두 문제는 근본적으로 다른 기술을 요구합니다. 일부 클리어링하우스는 종이-to-835 변환 서비스를 제공하기 시작했지만, 이는 일반적으로 핵심 클리어링하우스 번들에 포함되지 않는 별도의 제품과 별도의 가격으로 제공됩니다.

대부분의 의료 기관이 이미 전자 ERA를 받고 있지 않나요?

모두가 그런 것은 아닙니다. 전담 IT 인력을 갖춘 대형 의료 시스템은 1차 지불자에 대해 80~90%의 ERA 도입률을 달성하는 경우가 많습니다. 소규모 의원, 농어촌 제공자, 그리고 산재보험, 자동차보험 또는 주별 메디케이드 프로그램에 청구하는 모든 기관은 여전히 상당한 비율의 EOB를 종이 또는 PDF로 받고 있습니다. 2025년 HFMA 설문조사에 따르면 의료 기관의 41% 이상이 지급 조정에 여전히 주로 수동 워크플로에 의존하고 있습니다.

AI가 교육 없이도 어떤 보험사의 EOB 형식도 정말 읽을 수 있나요?

네, AI가 템플릿 매칭이 아닌 의미론적 이해를 사용할 때 가능합니다. 비전 언어 모델은 인간 청구 담당자가 하는 방식으로 EOB를 읽습니다. 즉, "허용 금액(Allowed Amount)"이 해당 필드가 페이지 어디에 있든 보험사의 계약 요율을 의미한다는 것을 이해합니다. 보험사별 또는 레이아웃별로 교육할 필요가 없습니다. 이는 사전 정의된 필드 좌표가 필요한 OCR 도구와 근본적으로 다릅니다. 한계는 심하게 손상된 스캔, 희미한 팩스, 또는 빽빽한 손글씨 여백 메모가 있는 경우 추출 신뢰도가 낮아져 사람의 검토가 필요할 수 있다는 점입니다.

자동 EOB 추출이 진료 관리 시스템을 대체하나요?

아니요. 추출 도구는 PDF EOB를 수신한 후 PM 시스템에 구조화된 데이터가 준비되기까지의 단계를 처리합니다. 그 외의 모든 것—청구 생성, 전자 제출, 거절 추적, 환자 명세서, 자격 인증—은 기존 PM 시스템에 남아 있습니다. 추출 결과물은 일반적으로 검토 후 가져올 수 있는 Excel 또는 CSV 파일입니다. 청구 담당자의 역할은 수동 입력에서 검토 및 예외 처리로 전환됩니다.

추출 도구 사용 시 HIPAA 규정 준수는 어떻게 되나요?

EOB 데이터를 처리하는 모든 도구는 보호 건강 정보(PHI)를 처리합니다. 주요 요구 사항: 전송 중 및 저장 시 암호화, 처리 기간 이후 업로드된 문서의 영구 저장 금지, 그리고 적용 대상 기관을 위한 업무 제휴 계약(BAA) 제공입니다. ImageToTable.ai는 추출 중 파일을 처리하며 이후에는 보관하지 않습니다. 청구 팀은 추출 공급업체의 특정 규정 준수 인증을 조직의 요구 사항과 대조하여 확인하고, 실제 PHI를 처리하기 전에 비식별화된 샘플 EOB로 테스트해야 합니다.

청구 회사 소유자가 이 분석으로 가장 유용하게 할 수 있는 일은 즉시 실행하는 것이 아니라 측정하는 것입니다. 한 명의 청구사가 여러 보험사의 EOB 10건을 처리하는 시간을 측정하세요. 월간 볼륨을 곱하세요. 전사 단계를 대체하는 추출 도구의 비용을 빼세요. 계산 결과는 전환을 정당화하거나 그렇지 않을 것입니다—하지만 최소한 결정은 EOB를 수동으로 입력하는 것이 "그냥 일"이라는 가정이 아닌 숫자에 기반하여 내려질 것입니다.