건강관리 데이터 및 청구 관리 단순화: Databricks X12 EDI Ember 소개

EDI와 건강관리 생태계에서의 역할

전자 데이터 교환(EDI)은 지불자, 제공자 등과 같은 건강관리 조직이 중요한 거래 정보를 전자적으로 원활하게 공유할 수 있게 해주는 반정형 데이터 교환 방법입니다. 그 표준화된 접근 방식은 건강관리 운영 전반에 걸쳐 정확성과 일관성을 보장합니다. 다양한 건강관리 운영에 사용되는 EDI 거래에는 다음이 포함됩니다:

• 청구 제출, 환불, 그리고 혜택 등록 (837, 835, 834)
• 자격 확인 (270, 271)
• 전자 자금 이체 (EFTs)

청구 제출 증가, API의 채택, 그리고 규제 요구사항에 의해 2029년까지 글로벌 건강관리 EDI 시장이 70억 달러를 초과할 것으로 예상되므로, 효율적인 EDI 워크플로우는 청구 제출을 확장하고, 규제 요구사항을 충족하고, 실시간 건강관리 협업을 지원하는 데 있어서 이제까지보다 더욱 필수적입니다. 건강관리 조직은 서비스와 지불에 대한 핵심 운영적 금융 기능을 수행하기 위해 EDI를 활용합니다. 또한, 청구, 환불, 그리고 등록 정보는 지불 무결성 작업 흐름, 가치 기반 관리 (VBC), 그리고 좁은 네트워크 구성, 그리고 건강 효과 데이터 및 정보 세트 (HEDIS) 및 메디케어 스타 등급과 같은 품질 측정치와 같은 많은 하류 분석 프로그램을 구동합니다. 중요한 것은, 더 많은 제공자들이 VBC에 참여함에 따라, 그들은 EDI를 원활하게 수집하고 분석할 수 있는 더 큰 필요성을 가지게 됩니다.

지속적인 기술 발전에도 불구하고, 의료기관이 EDI 데이터와 상호작용하는 방식에는 여전히 주요한 도전 과제가 남아 있습니다. 첫째, 교환 및 판정 과정 - 청구 제출에서 지불까지 - 은 여전히 길고 파편화되어 있습니다. 둘째로, 반정형화된 EDI 정보는 그 형식, 복잡성, 그리고 분석 준비 데이터로 변환하는 데 필요한 도구의 한계로 인해 접근하기 어렵습니다. 마지막으로, EDI 데이터의 대부분은 소유권을 가진 판정 시스템의 하류에서만 소비되며, 이는 투명성을 제한하고 조직이 재무 및 임상 성과에 대한 적시적이고 실행 가능한 통찰력을 얻는 것을 제한합니다.

EDI 처리에 대한 도전

EDI 형식을 처리하는 것은 본질적으로 다음과 같은 이유로 도전적입니다:

• 복잡하고 이질적인 데이터 소스는 맞춤형 파서의 개발을 필요로 합니다
• 맞춤 스크립트와 레거시 시스템의 높은 유지비용
• 오류가 발생하기 쉬운 수동 프로세스는 데이터의 부정확성을 초래합니다
• 증가하는 데이터 볼륨에 대해 전통적인 솔루션을 확장하는 데 어려움

효과적인 X12 파서의 구현은 운영을 간소화하고, 데이터 보안과 무결성을 강화하며, 통합 프로세스를 단순화하고, 더 큰 유연성과 확장성을 제공하는 데 중요합니다. 이 기술에 투자하면 비용을 크게 줄이고 시스템 내의 전반적인 효율성을 향상시킬 수 있습니다. 건강관리 조직은 다음을 수행하기 위해 이러한 도전 과제를 직접 해결하는 강력하고 효율적인 파서가 필요합니다:

• 처리 시간을 크게 줄입니다
• 데이터 변환의 정확성을 향상시킵니다
• 대량의 거래량에 대한 확장 가능한 성능 제공

솔루션: Databricks의 X12 EDI Ember

Databricks는 오픈 소스 코드 저장소인 x12-edi-parser, 또는 EDI Ember를 개발하여 Spark 워크플로우를 사용하여 EDI 데이터를 파싱함으로써 가치와 통찰력을 빠르게 얻을 수 있게 하였습니다. 우리는 파트너인 CitiusTech와 함께 작업하여 저장소 기능에 기여하고, 기업이 EDI 및/또는 청구 기반 기능을 확장하는 데 도움이 될 수 있습니다:

• 거래 유형 발견: 기관 청구 (837I), 전문 청구 (837P), 또는 다른 X12 거래 세트로 기능 그룹을 자동으로 감지하고 분류합니다
• 풍부한 청구 세그먼트 추출: 금융 및 임상 데이터 - 청구 금액, 절차 코드, 서비스 라인, 수익 코드, 진단 등을 추출합니다
• 계층적 루프 인식: EDI의 중첩 루프를 보존하기 위해, 각 청구서가 어떤 루프에 속하는지 식별하고, 청구 제공자, 가입자, 부양 가족을 추출하고, 송수신 파트너를 캡처합니다
• JSON 변환 및 하류 준비: 모든 세그먼트를 깨끗하고, 스키마-읽기 JSON 객체로 평탄화하고 정규화하여 분석, 데이터 레이크, 또는 하류 시스템에 대비시킵니다

주요 장점

• 더 빠른 가치 창출: 더 이상 제3자 파서나 취약한 사용자 정의 스크립트와 싸울 필요가 없습니다
• 엔드 투 엔드 거버넌스: Unity 카탈로그로 청구 테이블의 계보를 추적하고, 품질 검사를 집행하고, 모니터링 기능을 추가합니다
• 페타바이트 규모에서 확장 가능: Spark의 분산 엔진을 활용하여 수백만 건의 청구 거래를 분 단위로 파싱합니다

EDI Ember는 기능적 오케스트레이션을 사용하여 EDI 전송을 구조화되고 관리 가능한 계층으로 분해합니다. EDI 객체는 원시 인터체인지를 파싱하고 세그먼트를 기능 그룹 객체로 구성하며, 이는 개별 건강보험 청구서를 나타내는 트랜잭션 객체로 분할됩니다.

이러한 기본 구성 요소 외에도, HealthcareManager와 같은 특수 클래스는 건강관리 특정 표준 (예: 837 청구)에 대한 파싱 로직을 조정하며, MedicalClaim 클래스는 서비스 라인, 진단, 지불자 정보와 같은 주요 청구 데이터를 더욱 평탄화하고 해석합니다.

모듈식 아키텍처는 파서를 매우 확장 가능하게 만듭니다: 새로운 거래 유형 (예: 835 환불, 834 등록)에 대한 지원을 추가하는 것은 핵심 파싱 엔진을 다시 작성하지 않고도 새로운 핸들러 클래스를 도입하는 것만으로 가능합니다. 건강관리 EDI 표준이 계속 발전함에 따라, 이 디자인은 조직이 기능을 유연하게 확장하고, 파싱 워크플로우를 모듈화하고, 분석 중심의 건강관리 솔루션을 효율적으로 확장할 수 있도록 보장합니다.

 

청구 테이블 구축

파서를 설치하고 실행하는 단계는 저장소의 README에 있습니다. 그 단계를 실행한 후, 우리는 특히 두 개의 Spark 테이블 - claim_header 와 claim_lines 를 구축하는 데에서 claims Spark DataFrame을 구축할 수 있습니다.

• claim_header 테이블은 EDI 청구 봉투에서 고수준 및 루프 수준 데이터를 캡처합니다, 예를 들어 청구 ID, 제공자 세부 정보, 환자 인구 통계, 진단 코드, 지불자 식별자, 그리고 청구 금액 등입니다.
• claim_lines 테이블은 각 청구에서 서비스 라인 배열을 터뜨려 생성됩니다. 이 세부 테이블에는 개별 절차, 라인 요금, 수익 코드, 진단 포인터, 서비스 날짜에 대한 세부 정보가 포함되어 있습니다.

837 claim_header 예시 (청구 당 한 행):

데이터를 쿼리하면 거래 유형, 청구 헤더 메타데이터, 그리고 혜택 조정에 대한 정보가 드러납니다:

그리고 그들의 해당 837 claim_lines 행들 (청구 당 여러 행, 서비스 라인 당 하나)은 다음과 같을 것입니다:

그것은 환경에서 이 샘플 테이블에 해당합니다:

데이터를 이 두 테이블로 구조화함으로써, 의료기관은 집계된 청구 수준 메트릭스와 상세한 서비스 라인 데이터 모두에 대한 명확한 가시성을 얻게 되어, 청구 분석 및 보고를 종합적으로 가능하게 합니다.

Databricks X12 EDI Ember (그리고 샘플 Databricks 노트북이 함께 제공됩니다)은 건강관리 EDI 거래를 파싱하는 복잡한 작업을 크게 간소화합니다. 데이터 추출, 변환, 관리를 단순화함으로써, 이 접근 방식은 건강관리 조직이 더 깊은 분석 통찰력을 해제하고, 청구 처리 정확성을 향상시키고, 운영 효율성을 향상시키는 데 도움이 됩니다.

이 저장소는 다른 거래 유형으로 쉽게 확장할 수 있는 프레임워크로 설계되었습니다. 추가 파일 유형을 처리하려는 경우, GitHub 이슈를 생성하고 저희에게 연락하여 저장소에 기여해 주세요!

 

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)