수익 주기 관리 데이터 템플릿
수익 주기 관리 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- Oracle Health Revenue Cycle 데이터 추출 안내
수익 주기 관리 속성
| 이름 | 설명 | ||
|---|---|---|---|
| 이벤트 타임스탬프 EventTimestamp | 시스템에 활동이 기록된 정확한 날짜와 시간입니다. | ||
| 설명 이 속성에는 각 활동의 타임스탬프가 기록되어 발생 시점을 정확히 알 수 있습니다. 특정 청구 이벤트의 수익 주기에서 이벤트가 발생한 시점과 순서를 파악하는 데 필요합니다. 분석 시 이벤트 타임스탬프를 기준으로 활동을 시간순으로 정렬하고, 단계 간 소요 시간과 주기를 계산하며, 병목을 분석합니다. '청구서 제출'부터 '지급 내역 수신'까지의 지연을 파악하는 등 시간 기반 process mining 지표를 산출하는 토대입니다. 중요한 이유 이 타임스탬프는 이벤트 순서를 정하고 주기와 소요 시간 등 성과 지표를 계산하며 프로세스 병목을 찾는 데 중요합니다. 확보 방법 Oracle Health Revenue Cycle의 각 거래 또는 이벤트 로그 테이블에는 레코드 생성 시점이나 이벤트 발생 시점을 나타내는 타임스탬프 열이 있어야 합니다. 예시 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-05-02T11:25:10Z | |||
| 청구 이벤트 BillingEvent | 요금이 발생하는 서비스 또는 제품 제공 건을 식별하는 고유 ID입니다. 수익 주기 프로세스에서 사례 식별자로 사용됩니다. | ||
| 설명 청구 이벤트는 기본 사례 식별자로, 특정 청구 대상 항목의 요금 입력부터 계정 종료까지 모든 활동을 연결합니다. 각 청구 이벤트는 수익 주기 프로세스의 개별 사례를 나타내므로 청구서 제출, 지급 반영, 거부 또는 조정과 같은 여러 단계의 진행 상황을 추적할 수 있습니다. process mining 분석에서 이 속성은 전체 프로세스 흐름을 재구성하는 데 기본이 됩니다. 프로세스 변형을 시각화하고 활동 간 소요 시간을 계산하며 특정 청구 이벤트와 관련된 병목이나 기준 이탈을 파악할 수 있습니다. 중요한 이유 청구 대상 서비스의 전체 진행 과정을 추적하는 데 필요한 식별자입니다. 이를 바탕으로 프로세스 흐름을 분석하고 성과를 측정할 수 있습니다. 확보 방법 이 식별자는 Oracle Health Revenue Cycle의 기본 청구 또는 요금 거래 테이블에 있는 고유 키여야 합니다. 청구 이벤트의 기본 키는 시스템 문서에서 확인합니다. 예시 BEVNT-987654321BEVNT-987654322BEVNT-987654323 | |||
| 활동 이름 ActivityName | 수익 주기 프로세스에서 발생한 특정 단계나 이벤트의 이름입니다. | ||
| 설명 이 속성에는 청구 이벤트의 전체 진행 과정에서 수행된 각 활동의 이름이 기록됩니다. 예를 들면 '요금 입력', '지급자에게 청구서 제출', '지급 반영' 등이 있습니다. 이러한 활동은 발견된 프로세스 맵의 노드를 구성합니다. 활동의 순서와 빈도를 분석하는 것은 process mining의 기본입니다. 이 속성을 활용하면 가장 흔한 프로세스 경로를 파악하고 표준 절차에서 벗어난 사례를 찾아 수익 주기의 운영 흐름을 이해할 수 있습니다. 중요한 이유 프로세스의 단계를 정의하므로 프로세스 맵을 시각화하고 워크플로 패턴을 분석할 수 있습니다. 확보 방법 일반적으로 이벤트 로그, 상태 변경 기록 또는 Oracle Health의 수익 주기 각 단계와 관련된 특정 거래 테이블에서 가져옵니다. 예시 청구 생성지급 내역 수신청구 거부 이의 제기계정 종료 | |||
| 미결 잔액 OutstandingBalance | 특정 시점에 청구 이벤트에서 아직 결제되지 않은 잔액입니다. | ||
| 설명 이 속성은 모든 결제와 조정을 반영한 후 청구 이벤트에서 아직 받아야 하는 금액을 보여줍니다. 해당 청구 건의 현재 매출채권 잔액을 나타냅니다. '미결 잔액 경과 분석' 대시보드에서 중요한 속성입니다. 시간에 따른 잔액을 분석하면 현금 흐름 속도와 수금 활동의 효과를 살펴보고, 매출채권 회수일수(DSO)와 같은 주요 재무 KPI를 계산할 수 있습니다. 중요한 이유 사례별 현재 매출채권 잔액을 추적해 현금 흐름 관리와 수금 효과 분석을 지원합니다. 확보 방법 일반적으로 해당 청구 이벤트의 모든 재무 거래(청구, 결제, 조정)를 합산해 계산합니다. 계정 요약 테이블의 필드로 제공될 수도 있습니다. 예시 75.000.00550.80 | |||
| 사용자 UserPerformingAction | 활동을 수행한 사람의 사용자 ID 또는 이름입니다. | ||
| 설명 이 속성은 프로세스의 특정 활동을 수행한 직원이나 자동화된 시스템 사용자를 식별합니다. 업무량 배분과 리소스 성과를 파악하고 교육이 필요한 부분을 찾는 데 중요합니다. 분석 시 이 속성을 기준으로 사용자나 팀별 프로세스 맵을 필터링하고, 리소스별 성과를 비교하며, '청구 부서 업무량' 대시보드의 업무량을 분석할 수 있습니다. 성과가 높은 직원을 파악하거나 추가 지원 또는 교육이 필요한 직원을 찾는 데도 도움이 됩니다. 중요한 이유 프로세스 활동을 특정 사용자나 팀과 연결해 업무량을 분석하고 성과를 비교하며 교육 기회를 파악할 수 있습니다. 확보 방법 Oracle Health의 여러 모듈에 있는 거래 테이블에는 일반적으로 사용자 ID 필드(예: 'CREATED_BY', 'USER_ID')가 포함됩니다. 예시 j.doeasmithBillingBot_AUTOk.williams | |||
| 조정 금액 AdjustmentAmount | 계정 잔액에 적용된 조정 금액입니다. | ||
| 설명 이 속성은 계약상 공제, 대손 처리 또는 정정 등 청구 이벤트에 적용된 재무 조정 금액을 기록합니다. 조정은 청구 금액에서 예상 수익을 직접 차감합니다. '계정 조정 영향' 대시보드는 이 속성을 주요 데이터로 활용합니다. 조정 금액과 사유를 분석하면 수익 누수, 계약 관리 문제 또는 최초 청구 입력 과정의 오류를 파악할 수 있습니다. 재무 건전성을 평가하는 주요 지표입니다. 중요한 이유 대손 처리나 정정으로 인한 수익 누수를 수치화해 재무 손실의 원인을 파악하고 해결하는 데 도움이 됩니다. 확보 방법 환자 계정에 적용된 조정이나 대손 처리를 기록하는 재무 거래 테이블에서 확인할 수 있습니다. 예시 -50.25-120.0025.00 | |||
| 지급자 이름 PayerName | 지급을 담당하는 보험사 또는 제3자 지급자의 이름입니다. | ||
| 설명 이 속성은 서비스 비용을 청구하는 보험사나 Medicare와 같은 정부 프로그램 등의 기관을 식별합니다. 지급자 정보는 수익 주기 분석의 기본 요소입니다. 지급자별로 프로세스를 분석하면 지급 시간과 거부율, 이의 제기 성공률의 차이를 확인할 수 있습니다. 지연이나 수익 손실을 일으키는 지급자를 파악하고 지급자 계약 및 관계를 효과적으로 관리하는 데도 필요합니다. 중요한 이유 지급자별로 프로세스를 구분해 행동 양상과 거부율, 지급 속도의 차이를 파악할 수 있습니다. 이는 재무 성과를 분석하는 데 중요합니다. 확보 방법 Oracle Health Revenue Cycle의 환자 청구 또는 보험 기록에 저장됩니다. 예시 AetnaBlue Cross Blue ShieldUnitedHealthcareMedicareCigna | |||
| 청구 거부 사유 코드 DenialReasonCode | 보험 지급자가 청구를 거부한 사유를 나타내는 표준 코드입니다. | ||
| 설명 보험 지급자는 청구를 거부할 때 '보장 대상이 아닌 서비스' 또는 '중복 청구'와 같은 사유 코드를 제공합니다. 이 속성에는 해당 코드와 설명이 기록됩니다. 거부 사유 분석은 수익 주기 개선의 기본입니다. 코딩이나 환자 자격 확인 문제처럼 반복되는 원인을 찾아 시정 조치를 시행하고 향후 거부를 예방할 수 있습니다. 이를 통해 오류 없는 청구 비율을 높이고 재작업 비용을 줄일 수 있습니다. 중요한 이유 청구 거부의 근본 원인을 파악해 오류 없는 청구 비율을 높이고 수익 회수를 앞당길 수 있도록 개선 방향을 제시합니다. 확보 방법 이 정보는 보험 지급자가 보내는 전자 지급 명세서(ANSI 835 파일)에 포함되며, Oracle Health의 청구 또는 지급 명세 테이블에 저장해야 합니다. 예시 CO-16: 심사에 필요한 청구 또는 서비스 정보가 누락되었습니다.PR-96: 보장 대상이 아닌 비용입니다.CO-18: 중복 청구 또는 서비스입니다. | |||
| 청구 부서 BillingDepartment | 활동을 담당하는 부서 또는 기능별 팀입니다. | ||
| 설명 이 속성은 활동을 수행한 부서를 지정합니다. 예를 들면 '요금 입력', '코딩', '수금' 등이 있습니다. 이를 통해 프로세스 흐름을 조직 관점에서 파악할 수 있습니다. 부서별로 프로세스를 분석하면 팀 간 업무 인계와 부서 간 비효율을 파악할 수 있습니다. 활동과 성과 지표를 부서 단위로 집계할 수 있어 '청구 부서 업무량' 대시보드에도 활용됩니다. 중요한 이유 활동을 조직 단위에 연결합니다. 부서 간 업무 인계와 업무량, 팀 성과를 분석하는 데 중요합니다. 확보 방법 이 정보는 Oracle Health의 사용자 프로필 데이터에 직접 저장되거나 사용자 또는 활동 유형을 기준으로 도출될 수 있습니다. 예시 환자 접수코딩청구수금 | |||
| 환자 분류 PatientClass | 입원 또는 외래와 같은 환자 방문의 분류입니다. | ||
| 설명 이 속성은 요금이 발생한 환자 방문 또는 진료 유형을 분류합니다. 일반적인 분류로는 입원, 외래, 응급, 반복 방문이 있습니다. 환자 분류에 따라 청구 및 청구서 제출 절차 전체가 달라지는 경우가 많습니다. 환자 분류별로 프로세스 경로와 규정 준수 요건이 다릅니다. 이 속성을 기준으로 분석하면 이러한 차이를 파악하고 개선 활동을 조정하며 각 분류에 맞는 절차가 준수되는지 확인할 수 있습니다. 중요한 이유 복잡도와 처리 일정, 청구 요건이 서로 다른 프로세스 흐름(예: 입원과 외래)을 구분합니다. 확보 방법 Oracle Health의 환자 방문 또는 입원 레코드에 포함되는 표준 필드입니다. 예시 입원외래응급반복 | |||
| 마지막 데이터 업데이트 LastDataUpdate | 이벤트 데이터가 마지막으로 갱신되거나 추출된 시점을 나타내는 타임스탬프입니다. | ||
| 설명 이 속성은 데이터 세트가 마지막으로 업데이트된 시점을 보여줍니다. 분석에 사용되는 데이터의 최신성을 파악하는 데 도움이 되며, process mining 분석에서 도출한 인사이트가 얼마나 시의성 있는지 판단할 수 있습니다. 사용자는 이 속성을 확인해 최신 프로세스 정보를 보고 있는지 확인할 수 있습니다. 데이터가 얼마나 최근에 갱신되었는지 파악하는 데 도움이 되며, 데이터 거버넌스와 품질 보증에도 중요합니다. 중요한 이유 데이터의 최신성을 나타내므로 최신 정보를 바탕으로 분석하고 의사결정할 수 있습니다. 확보 방법 일반적으로 데이터를 process mining 플랫폼에 적재하는 ETL 과정에서 생성하고 입력하는 메타데이터 필드입니다. 예시 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| 원천 시스템 SourceSystem | 이벤트 데이터를 추출한 시스템입니다. | ||
| 설명 이 속성은 데이터가 발생한 원천 애플리케이션이나 모듈을 식별합니다. 이 프로세스에서는 일반적으로 'Oracle Health Revenue Cycle'이지만, 여러 곳의 데이터를 통합하는 경우 시스템 내의 개별 모듈을 지정할 수도 있습니다. 이 정보는 데이터 거버넌스와 문제 해결에 유용합니다. 데이터 계보를 확인할 수 있으며, 여러 시스템이 하나의 전체 프로세스에 데이터를 제공하는 환경에서 특히 중요합니다. 중요한 이유 데이터 출처를 파악할 수 있어 데이터 검증과 거버넌스, 시스템에 따라 달라질 수 있는 프로세스 변형을 이해하는 데 도움이 됩니다. 확보 방법 데이터 추출, 변환, 적재(ETL) 과정에서 데이터 세트의 출처를 표시하기 위해 추가하는 고정값인 경우가 많습니다. 예시 OracleHealth-RCMOracleHealth-CernerOH-RevCycle-PROD | |||
| 이벤트 종료 시간 EventEndTime | 사용 가능한 경우 활동이 완료된 시점을 나타내는 타임스탬프입니다. | ||
| 설명 StartTime이 활동의 시작을 나타낸다면 EventEndTime은 활동이 끝난 시점을 나타냅니다. 많은 활동은 순간적으로 발생하는 이벤트이므로 별도의 종료 시간이 기록되지 않을 수 있습니다. 하지만 처리에 시간이 걸리는 '청구 거부 이의 제기'와 같은 활동에는 이 필드가 유용합니다. 이 속성을 사용하면 개별 활동의 처리 시간을 더 정확하게 계산할 수 있습니다. 활동 사이의 대기 시간과 활동 자체에 소요된 처리 시간을 구분하는 데 도움이 됩니다. 중요한 이유 활동 완료까지 걸린 시간을 직접 계산하고 처리 시간과 대기 시간을 구분할 수 있습니다. 확보 방법 Oracle Health Revenue Cycle의 일부 거래 테이블에는 오래 걸리는 특정 작업의 시작 및 종료 타임스탬프가 모두 포함될 수 있습니다. 예시 2023-04-15T09:05:14Z2023-04-18T16:00:00Z | |||
| 이의 제기 사유 DisputeReason | 고객이나 환자가 청구서 또는 청구 금액에 이의를 제기한 사유입니다. | ||
| 설명 이 속성은 환자나 기타 책임자가 청구서에 이의를 제기한 이유를 기록합니다. 잘못된 청구, 제공되지 않은 서비스, 보험 처리 문제 등이 사유에 포함될 수 있습니다. '청구서 이의 제기 해결 지표' 대시보드에 필요한 정보입니다. 자주 발생하는 이의 제기 사유를 파악하면 청구 입력, 코딩 또는 청구 처리 과정의 구조적 문제를 찾을 수 있습니다. 근본 원인을 해결하면 이의 제기 비율과 처리에 필요한 행정 업무를 크게 줄일 수 있습니다. 중요한 이유 청구서에 이의가 제기되는 이유를 보여주어 청구의 정확성이나 명확성 문제를 파악하고 해결할 수 있습니다. 확보 방법 환자 계정과 연결된 Oracle Health의 사례 관리 또는 고객 서비스 모듈에 저장되어 있을 가능성이 높습니다. 예시 서비스가 잘못 청구됨중복 청구보험 청구 오류서비스 미제공 | |||
| 자동화 여부 IsAutomated | 활동을 자동화 시스템이 수행했는지 사용자가 수행했는지 나타내는 플래그입니다. | ||
| 설명 이 불리언 속성은 봇이나 시스템 일괄 작업과 같은 소프트웨어 자동화가 수행한 활동과 사용자가 수동으로 수행한 활동을 구분합니다. 예를 들어 '청구 생성'은 자동화 단계일 수 있지만, '거부에 이의 제기'는 수동으로 처리될 가능성이 높습니다. 이 속성을 분석하면 프로세스의 자동화 수준과 효율성 및 오류율에 미치는 영향을 파악할 수 있습니다. 자동화 경로와 수동 경로의 성과를 비교하고 추가 자동화 기회를 찾는 데 활용할 수 있습니다. 중요한 이유 사람이 수행한 활동과 시스템이 처리한 활동을 구분해 자동화 효과를 분석하고 추가 자동화 기회를 찾을 수 있습니다. 확보 방법 일반적으로 UserPerformingAction 속성을 기준으로 산출합니다. 예를 들어 'SYSTEM' 또는 'RPA_BOT'과 같은 사용자 ID가 수행한 활동은 자동화된 것으로 표시합니다. 예시 truefalse | |||
| 재작업 여부 IsRework | 재작업이나 반복 작업에 해당하는 활동을 표시하는 플래그입니다. | ||
| 설명 이 계산 속성은 이상적인 '정상 경로'에서 벗어나 재작업이 발생했음을 나타내는 활동을 표시합니다. 예를 들어 프로세스가 처음부터 문제없이 진행됐다면 발생하지 않았을 '청구 정정 후 재제출'이나 '거부에 이의 제기'가 이에 해당합니다. 재작업을 식별하고 수치화하는 것은 process mining의 주요 목표입니다. 이 플래그를 사용하면 재작업이 발생한 모든 경로를 쉽게 필터링하고 분석해 빈도와 비용, 프로세스 비효율의 원인을 측정할 수 있습니다. 수익 주기에서 품질 저하로 발생하는 실제 비용을 파악하는 데 필요합니다. 중요한 이유 재작업 경로의 빈도와 영향을 수치화해 프로세스 비효율과 품질 저하 비용을 파악할 수 있습니다. 확보 방법 파생 속성입니다. 데이터 변환 과정에서 특정 활동 이름을 재작업으로 표시하는 비즈니스 로직을 적용해 계산합니다. 예시 truefalse | |||
| 청구 ID ClaimId | 보험 지급자에게 제출한 보험 청구의 고유 식별자입니다. | ||
| 설명 이 속성은 환급을 받기 위해 생성해 보험 지급자에게 보낸 청구에 부여되는 고유 ID입니다. 하나의 청구 이벤트에서 정정이 필요한 경우처럼 처리 과정 중 청구가 하나 이상 발생할 수 있습니다. 청구 ID를 사용하면 보험 지급자에게 제출한 건을 추적하고 결제나 거부와 같은 응답에 직접 연결할 수 있습니다. 전체 수익 주기 안에서 청구 건별로 세밀하게 추적할 수 있습니다. 중요한 이유 보험 지급자와 주고받는 청구의 처리 과정을 개별적으로 추적할 수 있는 식별자로, 전체 청구 이벤트보다 세밀한 분석을 지원합니다. 확보 방법 청구 생성 시 Oracle Health에서 이 ID를 부여하며, 기본 청구 테이블에 저장합니다. 예시 CLM-2023-55489CLM-2023-55490CLM-2023-55491-C1 | |||
| 청구 금액 ChargeAmount | 청구 대상 서비스 또는 제품의 총 금액입니다. | ||
| 설명 이 속성은 조정, 계약상 공제 또는 결제가 적용되기 전 서비스에 청구된 최초 금액을 나타냅니다. 청구 이벤트의 재무 분석을 시작하는 기준 금액입니다. 청구 금액을 추적하면 제공된 서비스의 총액을 계산하고 이후 조정이나 대손 처리의 재무 영향을 파악하는 등 재무 분석에 도움이 됩니다. 실제 수익을 측정하는 기준으로도 활용됩니다. 중요한 이유 사례의 최초 재무 가치를 설정하며, 이후 재무 분석과 영향 평가의 기준이 됩니다. 확보 방법 Oracle Health의 청구 상세 또는 청구 거래 테이블에서 확인할 수 있습니다. 예시 150.001250.7585.50 | |||
| 환자 ID PatientId | 청구 이벤트와 관련된 환자의 고유 식별자입니다. | ||
| 설명 이 속성은 서비스를 받은 환자의 고유 식별자로, 일반적으로 의료 기록 번호(MRN)라고 합니다. 재무 거래를 특정 환자와 연결합니다. 프로세스의 사례 ID는 아니지만, 환자 ID를 사용하면 환자 한 명의 모든 청구 이벤트를 모아 전체 재무 흐름을 파악할 수 있습니다. 환자 기본 데이터와 결합하면 인구통계 정보나 이력에 따라 데이터를 구분할 수도 있습니다. 중요한 이유 재무 이벤트를 특정 환자와 연결해 환자별 분석과 청구 활동 전체의 집계를 지원합니다. 확보 방법 이 식별자는 환자 기본 기록의 주요 항목이며, 청구, 보험 청구, 결제 등 관련 거래 테이블에 포함됩니다. 예시 MRN-1002345MRN-1002346MRN-1002347 | |||
수익 주기 관리 활동
| 활동 | 설명 | ||
|---|---|---|---|
| 계정 종료 | 계정 잔액이 0이 되어 더 이상 활동이 없을 것으로 예상되는 최종 단계입니다. 계정 잔액이 0에 도달했는지 확인해 추정하는 경우가 많습니다. | ||
| 중요한 이유 수익 주기가 성공적으로 완료되었음을 나타냅니다. 이 상태에 도달하는 데 걸리는 시간은 전체 프로세스 효율성을 측정하는 주요 지표입니다. 확보 방법 모든 지급과 조정이 반영된 뒤 미결제 잔액이 처음 0이 되고 계속 0으로 유지되는 시점을 찾아 추정하는 경우가 많습니다. 기록 모든 요금과 지급 내역을 반영한 뒤 계정 잔액이 처음 0이 되는 시점에 계산합니다. 이벤트 유형 calculated | |||
| 지급 반영 | 지급자로부터 받은 대금을 환자 계정의 해당 요금 항목에 반영하는 것을 나타냅니다. 사용자가 직접 처리하거나 자동화된 프로세스가 수행하며, 재무 거래로 기록됩니다. | ||
| 중요한 이유 지급 반영의 효율성은 매출채권의 정확도에 영향을 줍니다. 이 단계가 지연되면 재무 현황이 왜곡되고 2차 청구도 늦어질 수 있습니다. 확보 방법 지급 거래 테이블에서 확인할 수 있습니다. 지급 반영 건마다 고유한 거래 ID와 관련 타임스탬프가 기록됩니다. 기록 지급금이 계정에 반영되면 재무 거래가 기록됩니다. 이벤트 유형 explicit | |||
| 지급자에게 청구서 제출 | 생성된 청구서를 보험사나 지급자에게 전자 또는 서면으로 제출하는 것을 나타냅니다. 시스템에는 전송 날짜와 시간이 기록되어야 합니다. | ||
| 중요한 이유 이 활동을 시작으로 지급 주기가 시작됩니다. 제출부터 지급까지 걸리는 시간을 분석하면 지급자별 처리 성과와 매출채권 회수일수(DSO)를 파악할 수 있습니다. 확보 방법 전송 이벤트를 기록하는 청구 관리 모듈에서 가져옵니다. 제출 타임스탬프나 청구 이력의 상태가 '제출 완료'로 변경된 기록을 확인합니다. 기록 청구서가 중계기관을 통해 정상적으로 전송되면 이벤트가 기록됩니다. 이벤트 유형 explicit | |||
| 청구 생성 | 개별 요금 항목을 UB-04 또는 CMS-1500과 같은 정식 청구서로 취합하는 시점을 나타냅니다. 시스템에서 생성되는 이벤트로, 최초 청구서가 만들어집니다. | ||
| 중요한 이유 지급자에게 청구할 준비가 되었음을 나타내는 주요 단계입니다. 내부 요금 입력부터 청구까지 걸리는 시간을 측정할 때 종료 시점으로 사용합니다. 확보 방법 청구 생성 로그나 테이블에 명시적으로 기록된 이벤트입니다. 해당 방문과 연결된 기본 청구 레코드의 생성 타임스탬프를 확인합니다. 기록 청구 레코드 생성 시 이벤트가 기록됩니다. 이벤트 유형 explicit | |||
| 환자 방문 생성 | 특정 방문이나 서비스에 대한 환자 계정이 생성된 시점을 나타냅니다. 일반적으로 등록 시스템이나 입원·퇴원·전원(ADT) 데이터 피드가 명시적인 이벤트를 발생시킵니다. | ||
| 중요한 이유 해당 청구 이벤트의 전체 수익 주기가 시작되는 지점입니다. 이를 기준으로 전체 프로세스 소요 시간과 등록 정확도를 분석할 수 있습니다. 확보 방법 환자 등록 또는 ADT 모듈의 로그에서 가져옵니다. 방문 생성 이벤트나 해당 방문 또는 재무 번호와 연결된 가장 이른 타임스탬프를 확인합니다. 기록 환자 등록 또는 입원 시 이벤트가 기록됩니다. 이벤트 유형 explicit | |||
| 계정 조정 | 계약상 허용액, 상각 또는 할인과 같이 계정 잔액에 적용된 재무 조정을 나타냅니다. 조정 건마다 별도의 재무 거래로 기록됩니다. | ||
| 중요한 이유 조정은 수익에 직접 영향을 줍니다. 빈도와 유형, 금액을 분석하면 수익 누수와 청구 오류를 파악할 수 있습니다. 확보 방법 재무 거래 테이블에서 확인할 수 있습니다. 조정 건마다 특정 거래 코드와 타임스탬프가 포함된 별도 항목으로 기록됩니다. 기록 특정 조정 코드와 함께 재무 거래가 기록됩니다. 이벤트 유형 explicit | |||
| 수금 절차 시작 | 미납으로 인해 환자 계정이 수금 절차로 이관된 것을 나타냅니다. 일반적으로 계정의 재무 분류나 상태 분류가 변경된 기록으로 확인합니다. | ||
| 중요한 이유 대손 관리를 위한 중요한 단계입니다. 이 단계에 이르는 원인과 수금 성공률을 분석하는 일은 재무 건전성 관리에 중요합니다. 확보 방법 계정 상태가 '수금 중' 또는 '대손'으로 변경된 기록을 통해 추정합니다. 상태 변경 타임스탬프가 있어야 합니다. 기록 계정 상태가 '수금 중' 또는 이와 유사한 상태로 변경된 기록을 통해 추정합니다. 이벤트 유형 inferred | |||
| 수정 청구서 제출 | 거부 또는 추가 정보 요청에 따라 수정하거나 정정한 청구서를 지급자에게 제출하는 것을 나타냅니다. 정정 표시가 있는 새 청구서 제출로 확인합니다. | ||
| 중요한 이유 이 활동은 거부 관리 과정에서 발생하는 재작업의 주요 단계입니다. 빈도가 높다면 최초 청구의 정확도에 문제가 있을 수 있습니다. 확보 방법 청구 제출 로그에서 확인합니다. 기존 방문에 대해 새로 제출된 청구서를 찾고, 재제출 코드나 더 높은 반복 번호가 있는지 확인합니다. 기록 청구서 재제출 이벤트로 기록되며, 특정 청구 빈도 유형 코드로 확인할 수 있는 경우가 많습니다. 이벤트 유형 explicit | |||
| 요금 입력 | 청구 대상 서비스나 항목이 환자 계정에 입력된 것을 나타냅니다. 임상 시스템에서 자동으로 입력되거나 직원이 직접 입력할 수 있습니다. | ||
| 중요한 이유 이 활동은 서비스 제공부터 청구 시작까지의 시간인 '요금 입력 지연'을 측정하는 데 중요합니다. 이 시간은 현금 흐름과 수익의 정확성에 직접 영향을 줍니다. 확보 방법 요금 거래 테이블에서 각 요금 항목의 생성 타임스탬프를 기준으로 확인합니다. Oracle Health에서는 요금 관련 테이블에 기록되는 경우가 많습니다. 기록 새 요금 항목마다 거래 로그가 생성됩니다. 이벤트 유형 explicit | |||
| 요금 코드 입력 | 의료 코더가 입력된 요금에 CPT 또는 ICD-10과 같은 표준 코드를 지정하는 과정입니다. 요금이나 방문의 상태 변경으로 추적하는 경우가 많습니다. | ||
| 중요한 이유 코딩 지연은 흔한 병목입니다. 이 활동을 추적하면 코딩 워크플로의 비효율과 청구 일정에 미치는 영향을 파악할 수 있습니다. 확보 방법 환자 방문이나 요금 배치의 상태가 '미코딩'에서 '코딩 완료'로 바뀌는 등의 기록을 통해 추정하는 경우가 많습니다. 상태 변경 타임스탬프가 필요합니다. 기록 방문 또는 요금 상태가 '코딩 완료'나 '청구 준비 완료'로 변경된 기록을 통해 추정합니다. 이벤트 유형 inferred | |||
| 지급 내역 수신 | 지급자로부터 전자 지급 내역 통지(ERA) 또는 서면 지급 설명서(EOB)를 수신한 것을 나타냅니다. 문서에는 지급, 거부 또는 조정된 요금 항목이 명시됩니다. | ||
| 중요한 이유 지급자의 첫 응답으로, 지급 속도를 파악하고 거부 추세를 조기에 확인하는 데 중요합니다. 확보 방법 지급 내역 처리 모듈에 기록됩니다. 청구와 연결된 835 거래 파일과 같은 ERA 파일의 가져오기 또는 생성 타임스탬프를 확인합니다. 기록 지급자의 지급 내역 파일(예: ANSI 835)을 가져와 처리할 때 이벤트가 기록됩니다. 이벤트 유형 explicit | |||
| 청구 거부 수신 | 지급자가 청구서나 특정 항목을 거부한 시점을 나타내며, 지급 내역 통지에 기록됩니다. 지급 내역 데이터의 거부 코드로 추정하는 경우가 많습니다. | ||
| 중요한 이유 거부를 추적하면 코딩 오류나 자격 요건 문제와 같은 원인을 파악하고 오류 없는 청구 비율을 높일 수 있습니다. 확보 방법 지급 내역(ERA/835) 데이터로 추정합니다. 청구서나 항목에 0이 아닌 거부 금액과 해당 거부 사유 코드가 있으면 이벤트가 발생한 것으로 처리합니다. 기록 거부 사유 코드(CARCs/RARCs)가 포함된 지급 내역 데이터로 추정합니다. 이벤트 유형 inferred | |||
| 청구 거부 이의 제기 | 거부된 청구에 대해 사용자나 시스템이 이의 제기를 시작한 것을 나타냅니다. 일반적으로 상태 업데이트나 작업 대기열에 생성된 특정 작업으로 기록됩니다. | ||
| 중요한 이유 이 활동을 시작으로 재작업이 발생합니다. 이의 제기 빈도와 성공률을 분석하면 수익 회수 활동을 개선하는 데 도움이 됩니다. 확보 방법 사용자가 직접 시작한 이벤트로 기록하거나, 청구 상태가 '이의 제기' 또는 '검토 중'으로 변경된 기록을 통해 추정할 수 있습니다. 기록 사용자가 거부된 청구에 대한 이의 제기를 시작하면 상태 변경이나 이벤트가 기록됩니다. 이벤트 유형 explicit | |||
| 환자 청구서 발송 | 환자가 부담할 잔액에 대한 청구서가 생성되어 환자에게 발송된 시점을 나타냅니다. 환자 청구 모듈에 명시적인 작업으로 기록됩니다. | ||
| 중요한 이유 이 단계부터 수익 주기 중 환자 지급 절차가 시작됩니다. 이를 추적하면 환자 수금의 효과를 분석할 수 있습니다. 확보 방법 환자 청구 또는 서신 로그에서 가져옵니다. 시스템에는 각 청구서의 생성일이나 발송일이 기록되어야 합니다. 기록 환자 청구서가 생성되어 인쇄되거나 전자 발송되면 이벤트가 기록됩니다. 이벤트 유형 explicit | |||
데이터 추출 안내
단계
- 데이터베이스 접근 권한 요청: Oracle Health Revenue Cycle 데이터베이스의 읽기 전용 계정 정보를 받습니다. 환자, 내원, 청구, 재무 거래 데이터가 포함된 스키마에 접근해야 합니다. 일반적으로 IT 보안팀과 데이터베이스 관리팀의 승인이 필요합니다.
- 스키마 및 테이블 이름 확인: 데이터베이스 관리자 또는 시스템 분석가와 협력해 Oracle Health 환경에서 사용하는 정확한 스키마 및 테이블 이름을 확인합니다. 쿼리에 제시된 이름은 일반적인 예시이므로 실제 환경에 맞게 매핑해야 합니다.
- SQL 클라이언트 설치: Oracle SQL Developer 또는 DBeaver 같은 호환 SQL 클라이언트를 워크스테이션에 설치합니다. 이 도구로 데이터베이스에 연결하고 추출 스크립트를 실행합니다.
- 데이터베이스 연결 설정: 제공된 호스트, 포트, 서비스 이름, 계정 정보를 사용해 SQL 클라이언트에서 새 데이터베이스 연결을 구성합니다. 연결을 테스트해 정상적으로 접속되는지 확인합니다.
- SQL 쿼리 수정: 제공된 SQL 스크립트를 새 쿼리 편집기에 복사합니다.
[START_DATE]및[END_DATE]같은 자리표시자를 찾아 분석할 날짜 범위로 바꿉니다(예: '2023-01-01'). 특정 Patient Class만 조회하는 등 분석 목적에 맞게 필터 조건을 조정합니다. - 추출 스크립트 실행: 수정한 SQL 스크립트를 실행합니다. 쿼리 범위와 데이터베이스 크기에 따라 완료까지 몇 분에서 몇 시간이 걸릴 수 있습니다.
- 초기 결과 검토: 쿼리가 끝나면 SQL 클라이언트의 결과 그리드에서 처음 수백 개 행을 확인합니다. 모든 값이 null인 열이나 잘못된 데이터 형식 등 명백한 오류가 없는지 살펴봅니다.
- 데이터를 CSV로 내보내기: 전체 결과를 CSV 파일로 내보냅니다. 문자 깨짐을 방지하려면 UTF-8 인코딩을 사용합니다. 쿼리 별칭에 지정된 열 이름(예: "BillingEvent", "ActivityName")이 머리글 행에 포함되어야 합니다.
- 업로드 전 확인: process mining 도구에 업로드하기 전에 CSV 파일을 열어 무결성을 확인합니다. 타임스탬프 형식이 일관되고 열 머리글이 필수 속성과 정확히 일치하는지 확인합니다. 이제 파일을 업로드할 수 있습니다.
구성
- 날짜 범위: 쿼리에는
[START_DATE]및[END_DATE]자리표시자가 있습니다. 데이터 규모를 관리할 수 있도록 구체적이고 적절한 날짜 범위를 지정해야 합니다. 초기 분석에는 3~6개월 범위를 권장합니다. - 필터링: 초기 데이터셋은
RelevantEncounters섹션에서 내원 등록 날짜(reg_dt_tm)를 기준으로 필터링됩니다. 범위를 좁히려면 이 섹션에WHERE절을 추가할 수 있습니다. 예를 들어e.patient_class_code IN ('INPATIENT', 'OUTPATIENT')를 사용해 특정 내원 유형을 대상으로 지정할 수 있습니다. - 성능: 운영 시스템에서 데이터베이스를 직접 조회하면 성능에 영향을 줄 수 있습니다. 사용량이 적은 시간에 추출을 실행하거나, 가능한 경우 운영 데이터베이스의 읽기 전용 복제본을 사용하는 것이 좋습니다.
- 사전 요건: 이 방법을 사용하려면 쿼리에서 참조하는 모든 테이블에
SELECT권한이 있는 데이터베이스 사용자 계정이 필요합니다. 해당 테이블에는 내원, 청구, 청구 금액, 보험 청구, 지급 내역, 재무 거래 테이블이 포함됩니다. - 테이블 및 열 매핑: 제공된 스크립트에는 일반적으로 사용되는 테이블 및 열 이름이 예시로 들어 있습니다. 이를 조직의 Oracle Health 데이터베이스 스키마에 실제로 존재하는 이름과 대조하고 매핑해야 합니다. 예를 들어 시스템에 따라
FINANCIAL_TRANSACTION이AR_TRANSACTIONS라는 이름일 수 있습니다.
샘플 쿼리 sql
WITH RelevantEncounters AS (
SELECT
e.billing_event_id
FROM ENCOUNTER e
WHERE e.reg_dt_tm BETWEEN TO_DATE('[START_DATE]', 'YYYY-MM-DD') AND TO_DATE('[END_DATE]', 'YYYY-MM-DD')
)
SELECT
e.billing_event_id AS "BillingEvent",
'Patient Encounter Created' AS "ActivityName",
e.reg_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.reg_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cd.billing_event_id AS "BillingEvent",
'Charges Captured' AS "ActivityName",
cd.charge_entry_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cd.charge_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CHARGE_DETAIL cd
JOIN ENCOUNTER e ON cd.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cd.entry_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cd.performing_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
ch.billing_event_id AS "BillingEvent",
'Charges Coded' AS "ActivityName",
ch.coded_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CODING_HISTORY ch
JOIN ENCOUNTER e ON ch.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ch.coder_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON e.primary_payer_id = pyr.payer_id
UNION ALL
SELECT
cl.billing_event_id AS "BillingEvent",
'Claim Generated' AS "ActivityName",
cl.create_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM cl
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON cl.create_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Claim Submitted To Payer' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'INITIAL'
UNION ALL
SELECT
ra.billing_event_id AS "BillingEvent",
'Remittance Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM REMITTANCE_ADVICE ra
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Payment Posted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'PAYMENT'
UNION ALL
SELECT
rd.billing_event_id AS "BillingEvent",
'Denial Received' AS "ActivityName",
ra.remit_received_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
rd.denial_reason_code AS "DenialReasonCode"
FROM REMITTANCE_DETAIL rd
JOIN REMITTANCE_ADVICE ra ON rd.remit_id = ra.remit_id
JOIN ENCOUNTER e ON ra.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ra.processed_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ra.processing_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ra.payer_id = pyr.payer_id
WHERE rd.denial_reason_code IS NOT NULL
UNION ALL
SELECT
at.billing_event_id AS "BillingEvent",
'Denial Appealed' AS "ActivityName",
at.appeal_filed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
e.total_account_balance AS "OutstandingBalance",
at.related_denial_code AS "DenialReasonCode"
FROM APPEAL_TRACKING at
JOIN ENCOUNTER e ON at.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON at.appeal_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
LEFT JOIN PAYER pyr ON at.payer_id = pyr.payer_id
UNION ALL
SELECT
csl.billing_event_id AS "BillingEvent",
'Corrected Claim Submitted' AS "ActivityName",
csl.submission_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
cl.claim_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM CLAIM_SUBMISSION_LOG csl
JOIN CLAIM cl ON csl.claim_id = cl.claim_id
JOIN ENCOUNTER e ON cl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON csl.submit_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON cl.billing_entity_org_id = org.organization_id
LEFT JOIN PAYER pyr ON cl.payer_id = pyr.payer_id
WHERE csl.submission_type = 'CORRECTED'
UNION ALL
SELECT
psl.billing_event_id AS "BillingEvent",
'Patient Statement Sent' AS "ActivityName",
psl.statement_sent_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
psl.statement_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM PATIENT_STATEMENT_LOG psl
JOIN ENCOUNTER e ON psl.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON psl.sent_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON p.default_org_id = org.organization_id
UNION ALL
SELECT
ash.billing_event_id AS "BillingEvent",
'Collection Activity Started' AS "ActivityName",
ash.status_change_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
ash.account_balance AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ACCOUNT_STATUS_HISTORY ash
JOIN ENCOUNTER e ON ash.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ash.change_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ash.responsible_org_id = org.organization_id
WHERE ash.new_status_code = 'COLLECTIONS'
UNION ALL
SELECT
ft.billing_event_id AS "BillingEvent",
'Account Adjusted' AS "ActivityName",
ft.transaction_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
pyr.payer_name AS "PayerName",
e.patient_class_code AS "PatientClass",
ft.transaction_amount AS "AdjustmentAmount",
ft.ending_balance AS "OutstandingBalance",
ft.adjustment_reason_code AS "DenialReasonCode"
FROM FINANCIAL_TRANSACTION ft
JOIN ENCOUNTER e ON ft.encntr_id = e.encntr_id
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON ft.post_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON ft.post_dept_org_id = org.organization_id
LEFT JOIN PAYER pyr ON ft.payer_id = pyr.payer_id
WHERE ft.transaction_type_code = 'ADJUSTMENT'
UNION ALL
SELECT
e.billing_event_id AS "BillingEvent",
'Account Closed' AS "ActivityName",
e.account_closed_dt_tm AS "EventTimestamp",
p.name_full_formatted AS "UserPerformingAction",
org.organization_name AS "BillingDepartment",
NULL AS "PayerName",
e.patient_class_code AS "PatientClass",
NULL AS "AdjustmentAmount",
0 AS "OutstandingBalance",
NULL AS "DenialReasonCode"
FROM ENCOUNTER e
JOIN RelevantEncounters re ON e.billing_event_id = re.billing_event_id
LEFT JOIN PERSONNEL p ON e.closed_by_prsnl_id = p.person_id
LEFT JOIN ORGANIZATION org ON e.reg_facility_org_id = org.organization_id
WHERE e.total_account_balance = 0 AND e.account_closed_dt_tm IS NOT NULL; 시작할 준비가 되셨나요?
이 템플릿을 활용해 분석에 필요한 데이터를 준비하세요. 지금 수익 주기 관리 프로세스 개선을 시작해 보세요.
수익 주기를 개선해 대금 지급을 앞당기세요
병목을 해소하고 처리 시간을 30% 단축해 현금 흐름을 개선하세요.
신용카드가 필요하지 않습니다. 몇 분이면 설정할 수 있습니다.