수익 주기 관리 데이터 템플릿
수익 주기 관리 데이터 템플릿
- 수집 권장 속성
- 추적할 주요 활동
- 데이터 추출 안내
수익 주기 관리 속성
| 이름 | 설명 | ||
|---|---|---|---|
| 이벤트 타임스탬프 EventTimestamp | 특정 활동이나 이벤트가 발생한 정확한 날짜와 시각입니다. | ||
| 설명 이벤트 타임스탬프는 활동이 발생한 시점을 기록합니다. 이 시간 데이터는 매출 주기에서 이벤트의 시점과 순서를 파악하는 데 중요합니다. 분석 시 타임스탬프를 사용해 청구 항목 포착 지연이나 지급 내역 반영 시간처럼 활동 간 소요 시간을 계산합니다. 이를 통해 병목을 찾고, 주기 시간을 측정하며, 기간별 프로세스 성과를 분석할 수 있습니다. 시간 기반 KPI와 대시보드를 분석하려면 정확한 타임스탬프가 필요합니다. 중요한 이유 주기 시간과 소요 시간을 비롯한 모든 시간 기반 지표를 계산하는 데 필요한 속성입니다. 지연과 비효율을 찾는 데도 중요합니다. 확보 방법 Epic Resolute의 거래 또는 이벤트 로그 테이블에서 각 활동과 연결된 값을 찾을 수 있습니다. 필드명은 흔히 Dt, DTTM, Time 등의 접미사로 끝납니다. 예시 2023-04-15T09:30:00Z2023-04-16T11:05:21Z2023-05-01T14:00:00Z | |||
| 청구 이벤트 BillingEvent | 청구가 발생하는 단일 서비스 또는 제품 제공 건을 식별하는 고유 식별자이며, 기본 케이스 식별자로 사용됩니다. | ||
| 설명 청구 이벤트는 특정 청구 항목의 매출 주기 내 모든 활동을 연결하는 기본 식별자입니다. 서비스가 제공될 때 시작해 계정이 완전히 정산되거나 마감될 때 끝납니다. process mining 분석에서는 이 속성을 사용해 각 청구 항목의 전체 처리 과정을 재구성합니다. 개별 청구 이벤트의 청구 항목 포착, 청구 제출, 지급 내역 반영, 거부 관리 등의 활동을 추적해 프로세스 흐름과 편차를 명확히 파악할 수 있습니다. 중요한 이유 각 서비스의 매출 발생과 수금 전 과정을 분석할 수 있도록 관련된 모든 프로세스 단계를 연결하는 기본 Case ID입니다. 확보 방법 Epic Resolute에서 병원 계정(HAR)이나 특정 청구 세션을 식별하는 고유 식별자인 경우가 많습니다. HAR 또는 Charge Session 레코드와 같은 구체적인 테이블은 Epic Resolute 문서를 참조하세요. 예시 BE10098765BE20012345BE30054321 | |||
| 활동명 ActivityName | 매출 주기 관리 프로세스에서 수행한 특정 이벤트 또는 작업의 이름입니다. | ||
| 설명 매출 주기의 개별 단계를 나타내는 속성입니다. 예를 들어 '청구 항목 포착', '지급자에게 청구 제출', '지급 수령' 등이 있습니다. 각 활동은 서비스 청구와 지급 수금 과정에서 발생하는 개별 이정표입니다. 활동 분석은 process mining의 기반입니다. 프로세스 맵을 시각화하고, 일반적인 경로를 파악하며, 단계 사이의 병목을 찾고, 표준 운영 절차 준수 여부를 측정할 수 있습니다. 중요한 이유 프로세스 맵의 단계를 정의해 매출 주기의 업무 흐름을 시각화하고 분석하며 최적화할 수 있습니다. 확보 방법 일반적으로 Epic Resolute의 청구 및 청구 관리 모듈에 있는 이벤트 로그, 감사 추적 또는 상태 변경 기록에서 가져옵니다. 예시 청구 항목 포착지급자에게 청구 제출지급 수령계정 마감 | |||
| 거부 사유 코드 DenialReasonCode | 지급자가 제출된 청구를 거부한 이유를 나타내는 표준 코드입니다. | ||
| 설명 지급자가 청구를 거부하면 '보장 대상이 아닌 서비스', '중복 청구', '추가 정보 필요'와 같은 사유 코드를 제공합니다. 이러한 코드는 청구 조정 사유 코드(CARC)로 표준화되는 경우가 많습니다. 이 속성은 '청구 거부율 및 사유' 대시보드의 기반입니다. 거부 코드별 발생 빈도를 분석하면 자격 인증 문제, 코딩 오류, 사전 승인 누락 등 근본 원인을 찾아 개선 조치를 집중할 수 있습니다. 중요한 이유 청구가 거부되는 이유를 직접 보여줍니다. 거부율과 매출 손실을 줄이고 지급을 앞당기는 데 필요한 실행 가능한 정보를 제공합니다. 확보 방법 지급자로부터 받은 청구 응답 거래(예: ANSI 835 파일)에 이 데이터가 있으며, Epic Resolute의 청구 관리 모듈에 저장됩니다. 예시 CO-16: 청구 또는 서비스 정보 누락OA-18: 중복 청구 또는 서비스PR-96: 보장되지 않는 청구 항목 | |||
| 담당 사용자 ResponsibleUser | 활동을 수행한 사용자 또는 직원의 식별자입니다. | ||
| 설명 매출 주기의 특정 작업을 담당한 사람의 사용자 ID, 이름 또는 직원 번호를 기록합니다. 청구 항목을 입력한 임상의, 청구서를 제출한 담당자, 거부 건에 후속 조치를 한 수금 담당자가 해당할 수 있습니다. 사용자별로 분석하면 성과가 높은 직원을 파악하고, 교육이 필요한 영역과 업무량 분포를 확인할 수 있습니다. 성과 관리에 활용할 수 있으며, 특정 개인이나 역할과 관련된 프로세스 편차를 조사할 때도 유용합니다. 중요한 이유 개인이나 역할별 성과를 분석해 교육 기회, 업무량 불균형, 리소스 관련 병목을 파악할 수 있습니다. 확보 방법 일반적으로 Epic Resolute의 감사 추적이나 거래 로그에서 찾을 수 있으며, 사용자 마스터 데이터 테이블(예: EMP 레코드)과 연결되는 경우가 많습니다. 예시 j.doebsmith123User7890 | |||
| 미결제 잔액 OutstandingBalance | 청구 이벤트와 관련해 지급자나 환자가 지급해야 하는 남은 금액입니다. | ||
| 설명 특정 청구 이벤트에서 활동이 발생한 시점의 매출채권 잔액입니다. 케이스의 전체 처리 기간에 걸친 재무 상태를 보여줍니다. 미결제 잔액은 재무 보고와 '미결제 잔액 경과 기간 보고서'에 중요합니다. 시간의 흐름과 지급자 또는 부서별 잔액을 분석하면 수금 우선순위를 정하고, 현금 흐름을 관리하며, 재무 위험을 평가할 수 있습니다. 중요한 이유 프로세스 지연이 재무에 미치는 영향을 직접 측정합니다. 수금 우선순위 설정, 현금 흐름 관리, 매출채권 파악에 필요합니다. 확보 방법 Epic Resolute의 환자 계정 또는 병원 계정(HAR) 레코드에 있는 주요 필드입니다. 재무 거래에 따라 갱신되는 누적 잔액입니다. 예시 1500.00250.750.00 | |||
| 서비스 유형 ServiceType | 제공된 의료 서비스의 범주 또는 유형입니다. | ||
| 설명 이 속성은 청구 대상 서비스를 '영상의학', '수술', '진료 상담', '응급실 방문' 등으로 분류합니다. 재무 데이터에 임상적 맥락을 더해 줍니다. 서비스 유형별로 수익 주기를 분석하면 특정 진료 분야에서 발생하는 프로세스 차이를 파악할 수 있습니다. 예를 들어 수술은 일반 외래 진료보다 복잡한 비용 입력 및 사전 승인 절차가 필요할 수 있어 프로세스 진행 방식과 과제가 달라질 수 있습니다. 중요한 이유 재무 데이터에 임상적 맥락을 더해 의료 서비스 유형별로 수익 주기 프로세스와 효율성에 미치는 영향을 분석할 수 있습니다. 확보 방법 Epic에서 비용 거래와 연결된 비용 설명 마스터(CDM), 진료 서비스 라인 또는 부서를 기준으로 산출합니다. 예시 입원 수술외래 영상의학응급 서비스 | |||
| 조정 사유 AdjustmentReason | 환자 계정 잔액을 수동 또는 자동으로 조정한 사유입니다. | ||
| 설명 표준 지급이나 청구 외의 사유로 계정 잔액이 변경된 이유를 나타냅니다. 지급자와의 계약상 허용액, 소액 잔액 상각, 게시 오류 수정 등이 해당할 수 있습니다. 이 속성은 '유형별 계정 조정 건수' 대시보드에 필요합니다. 조정 사유를 분석하면 매출 누수 원인을 찾고, 지급자 계약의 영향을 파악하며, 청구 프로세스의 비효율이나 오류를 발견할 수 있습니다. 중요한 이유 계정 잔액이 변경된 이유를 보여줘 매출 누수와 청구 정확도를 파악하고 불필요한 상각을 줄이는 데 도움이 됩니다. 확보 방법 Epic Resolute 환자 회계 모듈의 조정 거래 상세 정보에서 확인할 수 있습니다. 예시 계약상 허용액소액 잔액 상각중복 청구 수정 | |||
| 청구 부서 BillingDepartment | 청구 이벤트나 활동을 담당하는 부서 또는 기능 팀입니다. | ||
| 설명 청구 이벤트와 연결되거나 특정 활동을 수행한 조직 단위를 나타냅니다. 예를 들어 '입원 청구', '외래 청구', '거부 관리팀' 등이 있습니다. 이 차원은 '청구 부서 성과 지표' 대시보드에 필요합니다. 부서별 거부율이나 청구 항목 포착 시간 등의 주요 지표를 나란히 비교할 수 있습니다. 이를 통해 관리자는 성과가 높은 부서를 찾고, 모범 사례를 표준화하며, 리소스를 효과적으로 배분할 수 있습니다. 중요한 이유 부서별 성과를 비교해 모범 사례를 찾고 개선이나 추가 리소스가 필요한 영역을 파악할 수 있습니다. 확보 방법 Epic Resolute의 사용자 레코드, 환자 계정 또는 서비스 위치 정보와 연결되어 있을 수 있습니다. 예시 심장내과 청구영상의학과 RCM중앙 청구 사무소 | |||
| 결제 기한 PaymentDueDate | 청구된 서비스 대금을 결제해야 하는 날짜입니다. | ||
| 설명 이 속성은 청구서에 명시되거나 보험 지급자 계약에 따라 정해진 결제 기한을 나타냅니다. 적기 결제 여부를 측정하는 기준으로 사용됩니다. 결제 기한은 '미결 잔액 경과 기간 보고서'를 작성할 때 필요합니다. 미결 잔액의 결제 기한과 현재 날짜를 비교하면 미수금을 경과 기간별로 분류할 수 있습니다(예: 기한 경과 0 중요한 이유 미수금 경과 기간 분석의 기준이 됩니다. 미납 청구서에 따른 재무 위험을 관리하고 회수 우선순위를 정하는 데 중요합니다. 확보 방법 이 날짜는 Epic의 지급자 계약 또는 환자 계정 정보에 저장된 청구서 날짜와 결제 조건을 기준으로 계산하는 경우가 많습니다. 예시 2023-05-302023-06-152023-07-01 | |||
| 마지막 데이터 업데이트 LastDataUpdate | 이벤트 데이터가 소스 시스템에서 마지막으로 새로 고침되거나 추출된 시각입니다. | ||
| 설명 데이터의 최신 상태를 나타냅니다. 레코드가 Epic Resolute에서 process mining 데이터 세트로 마지막으로 가져온 시점을 보여줍니다. 분석의 최신성을 파악하고 데이터를 검증하는 데 중요합니다. 사용자는 현재 확인 중인 정보가 최신인지 알 수 있으며, 데이터 새로 고침 주기를 관리할 때도 참고할 수 있습니다. 중요한 이유 분석 중인 데이터가 얼마나 최신인지 사용자가 파악할 수 있도록 합니다. 정확하고 최신인 업무 의사결정을 내리는 데 필요한 정보입니다. 확보 방법 데이터를 적재할 때 ETL(추출, 변환, 적재) 프로세스에서 이 타임스탬프를 추가합니다. 예시 2023-06-10T02:00:00Z2023-06-11T02:00:00Z | |||
| 소스 시스템 SourceSystem | 데이터가 생성된 정보 시스템입니다. | ||
| 설명 이 속성은 레코드의 소스 시스템을 나타내며, 여기서는 Epic Resolute를 가리킵니다. 여러 시스템이 연동된 환경에서는 데이터 출처를 구분하는 데 사용합니다. 단일 시스템만 사용하는 경우에는 중복 정보처럼 보일 수 있지만, 데이터 거버넌스와 확장성을 고려하면 설정하는 것이 좋습니다. 나중에 별도의 수금 대행사 플랫폼 등 다른 시스템의 데이터를 통합하더라도 출처를 명확히 구분할 수 있습니다. 중요한 이유 데이터 계보와 맥락을 제공해 데이터 출처를 명확히 파악할 수 있습니다. 데이터 거버넌스와 문제 해결에 필요한 정보입니다. 확보 방법 일반적으로 데이터 추출 및 변환 과정에서 데이터 세트의 출처를 표시하기 위해 추가하는 고정값입니다. 예시 Epic ResoluteEpicResolute_V2023 | |||
| 이벤트 종료 시각 EventEndTime | 활동이 완료된 시각을 나타내는 타임스탬프입니다. 활동 소요 시간을 계산할 때 사용합니다. | ||
| 설명 이 속성에는 활동이 완료된 시각이 기록됩니다. 시작 시각과 종료 시각이 같은 즉시 처리 이벤트도 많지만, 거부 건 후속 연락처럼 소요 시간을 측정할 수 있는 작업도 있습니다. 종료 시각이 있으면 활동 처리 시간을 직접 계산할 수 있습니다('EndTime' - 'StartTime'). 다음 활동의 시작 시각으로 소요 시간을 추정하는 것보다 정확하며, 단계 사이의 대기 시간도 반영합니다. 'ProcessingTime' 속성을 계산하는 데 필요한 항목입니다. 중요한 이유 각 활동의 완료까지 걸리는 시간을 정확히 계산할 수 있어 비효율적인 작업을 찾고 리소스 생산성을 측정하는 데 중요합니다. 확보 방법 작업 시작 및 종료를 추적하는 일부 Epic Resolute 모듈에서 확인할 수 있습니다. 예를 들어 작업 큐 또는 활동 관리 로그에 기록될 수 있지만, 명시적으로 추적되지 않는 경우가 많습니다. 예시 2023-04-15T09:45:00Z2023-04-16T11:15:30Z2023-05-01T14:02:00Z | |||
| 자동화 여부 IsAutomated | 활동을 시스템 또는 자동화된 프로세스가 수행했는지 나타내는 불리언 플래그입니다. | ||
| 설명 이 플래그를 사용하면 자동 청구 생성이나 자격 확인처럼 시스템이 자동으로 수행한 작업과 사용자가 직접 수행한 작업을 구분할 수 있습니다. 이 속성을 분석하면 프로세스의 자동화 수준을 파악할 수 있습니다. 자동화된 활동과 수동 활동의 효율성 및 오류율을 비교하고, 추가 자동화 기회를 찾으며, 기존 봇이나 시스템 규칙의 성능을 모니터링하는 데 활용할 수 있습니다. 중요한 이유 시스템이 수행한 활동과 사람이 수행한 활동을 구분합니다. 자동화의 효과를 평가하고 추가 자동화 기회를 찾는 데 중요합니다. 확보 방법 활동의 'ResponsibleUser'가 시스템 또는 서비스 계정인지 확인하거나, 자동화된 것으로 알려진 특정 활동 이름에 플래그를 지정해 산출하는 경우가 많습니다. 예시 truefalse | |||
| 조정 금액 AdjustedAmount | 계정 조정 거래의 금액입니다. | ||
| 설명 이 필드에는 계정 조정의 구체적인 금액이 기록됩니다. 계정 잔액에 대한 대변 또는 차변을 나타내며, 양수 또는 음수일 수 있습니다. 이 금액은 '유형별 계정 조정 규모' 대시보드의 주요 지표입니다. 조정 사유별 금액을 합산하면 계약상 의무로 상각된 수익과 수정 가능한 오류로 손실된 수익을 비교하는 등 조정 유형별 재무 영향을 명확히 파악할 수 있습니다. 중요한 이유 계정 조정의 재무 영향을 수치로 보여 주므로 수익 누수와 청구 오류 비용을 측정할 수 있습니다. 확보 방법 Epic Resolute의 재무 거래 상세 테이블에서 조정 유형 거래와 연결된 항목으로 확인할 수 있습니다. 예시 -1250.45-50.0025.10 | |||
| 지급자명 PayerName | 지급을 담당하는 보험사, 정부 기관 또는 기타 당사자의 이름입니다. | ||
| 설명 청구 이벤트의 주요 지급자를 나타냅니다. 예를 들어 'Blue Cross Blue Shield', 'Medicare', 'Aetna' 등이 있습니다. 환자가 직접 부담하는 경우 환자를 지급자로 표시할 수 있습니다. 지급자별로 프로세스를 구분해 분석하면 특정 지급자의 거부율이 높거나 지급 주기가 길고 요구 사항이 복잡한지 확인할 수 있습니다. 이 정보를 바탕으로 지급자별 청구 전략을 조정해 효율과 지급 속도를 높일 수 있습니다. 중요한 이유 지급자별 성과를 분석해 거부율이 높거나 지급 주기가 긴 지급자를 파악하고, 대상에 맞는 후속 조치 전략을 세울 수 있습니다. 확보 방법 이 정보는 환자의 보장 내역에 포함되며, Epic Resolute의 병원 계정(HAR)과 연결됩니다. 예시 Medicare Part BUnitedHealthcareAetna PPO | |||
| 청구 ID ClaimId | 지급자에게 제출한 보험 청구에 부여되는 고유 식별자입니다. | ||
| 설명 이 속성은 지급자에게 제출한 청구서(예: CMS-1500 또는 UB-04)의 고유 ID입니다. 서비스를 재청구하거나 이의를 제기하면 하나의 청구 이벤트에 여러 청구가 연결될 수 있습니다. 청구 ID를 기준으로 추적하면 청구 제출 및 거부 관리 하위 프로세스를 상세히 분석할 수 있습니다. 이를 통해 최초 청구와 동일한 서비스에 대해 나중에 다시 제출한 청구의 활동을 구분할 수 있습니다. 중요한 이유 개별 청구 제출 건의 전체 진행 과정을 세부적으로 추적할 수 있는 식별자입니다. 재제출 및 이의 제기 분석에 중요합니다. 확보 방법 청구가 생성될 때 Epic Resolute의 청구 관리 모듈에서 생성되며, 청구 데이터 테이블에 저장됩니다. 예시 CLM-2023-98765CLAIM-0012345623189A4567 | |||
| 총 수익 주기 소요 시간 TotalRevenueCycleTime | 최초 서비스 이벤트부터 최종 결제 또는 계정 종료까지 계산한 총 소요 시간입니다. | ||
| 설명 이 사례 단위 KPI는 단일 청구 이벤트의 수익 주기 전체 소요 시간을 측정합니다. 일반적으로 '서비스 제공' 활동부터 최종 '결제 수령' 또는 '계정 종료' 활동까지의 시간 차이로 계산합니다. 이 지표는 RCM 프로세스의 전반적인 효율성을 보여 줍니다. 시간에 따른 KPI 변화를 추적하면 프로세스 개선 활동의 효과를 측정하고 현금 회수 속도를 파악할 수 있습니다. 중요한 이유 프로세스 효율성을 처음부터 끝까지 개괄적으로 보여 주며, 서비스 제공 후 대금을 회수하기까지 걸리는 시간을 직접 측정합니다. 확보 방법 process mining 도구에서 각 사례의 첫 이벤트와 마지막 이벤트를 필터링한 뒤 시간 차이를 계산합니다. 예시 259200038880005184000 | |||
| 환자 ID PatientId | 서비스를 받는 환자의 고유 식별자입니다. | ||
| 설명 이 속성은 환자의 의무기록번호(MRN) 또는 기타 고유 식별자입니다. 재무 청구 이벤트를 특정 환자와 연결합니다. 환자 개인정보 보호를 위해 일반적으로 주요 분석 차원으로 사용하지는 않지만, 데이터 검증에 필요합니다. 또한 환자 한 명의 모든 청구 이벤트를 집계해 전체 재무 여정을 파악하는 데 사용할 수 있습니다. 임상 프로세스 데이터와 통합할 때도 중요합니다. 중요한 이유 재무 데이터를 특정 환자와 연결해 데이터 검증과 환자 여정 전반에 대한 분석을 지원합니다. 개인정보 보호에 유의해 처리해야 합니다. 확보 방법 Epic 전반에서 사용하는 기본 식별자로, 환자 등록 및 계정 기록과 연결됩니다. 예시 MRN-1234567MRN-8765432MRN-5551234 | |||
수익 주기 관리 활동
| 활동 | 설명 | ||
|---|---|---|---|
| 계정 마감 | 마지막 활동으로, 청구 이벤트의 미결제 잔액이 0이 되고 더 이상 대기 중인 활동이 없음을 나타냅니다. 전액 지급, 조정 또는 상각으로 마감될 수 있습니다. | ||
| 중요한 이유 청구 이벤트의 매출 주기가 성공적으로 완료되었음을 나타냅니다. 서비스 제공부터 계정 마감까지의 전체 소요 시간은 프로세스 효율을 보여주는 주요 KPI입니다. 확보 방법 일반적으로 추정하는 이벤트입니다. 청구 이벤트의 계정 잔액이 0이 된 뒤 계속 0으로 유지되는 시점을 확인해 판단합니다. 기록 계정 잔액의 누계를 계산해 잔액을 0으로 만든 마지막 거래의 타임스탬프를 찾습니다. 이벤트 유형 inferred | |||
| 계정에 지급 내역 반영 | 수령한 지급액을 환자 계정의 특정 청구 항목에 적용하거나 배분하는 이벤트입니다. 이 작업으로 청구 이벤트의 미결제 잔액이 줄어듭니다. | ||
| 중요한 이유 지급 내역을 효율적으로 반영하면 계정 잔액을 정확히 유지하고 청구 이벤트를 마감할 수 있습니다. 남은 잔액을 정확히 파악해 2차 청구나 수금 절차를 진행할 수 있습니다. 확보 방법 Resolute에 명시적으로 기록되는 거래입니다. 지급 내역 반영 시 지급 거래가 하나 이상의 청구 거래와 연결되며, 거래 상세 테이블에 기록됩니다. 기록 지급액을 청구 항목에 적용하는 거래 레코드를 가져옵니다. 특정 거래 유형으로 식별할 수 있습니다. 이벤트 유형 explicit | |||
| 서비스 제공 | 환자에게 임상 서비스가 제공되어 청구 이벤트가 시작되는 시점입니다. 임상의가 진료나 시술을 완료 처리할 때 Epic EHR(EpicCare)에 기록되는 경우가 많습니다. | ||
| 중요한 이유 매출 주기의 주요 시작 이벤트입니다. 이 시점부터 청구 항목 포착까지 걸리는 시간을 분석하면 청구 시작 지연과 잠재적인 매출 누수를 파악할 수 있습니다. 확보 방법 일반적으로 청구 계정과 연결된 임상 모듈의 서비스 또는 방문 타임스탬프를 바탕으로 추정합니다. 청구 거래의 서비스 날짜가 주요 데이터 항목입니다. 기록 청구 이벤트의 첫 청구 거래에 기록된 서비스 날짜를 바탕으로 추정합니다. 이벤트 유형 inferred | |||
| 지급 수령 | 지급자나 환자로부터 지급을 받는 이벤트입니다. 전자 지급 명세서(ERA)를 불러오거나 수표를 시스템에 수동으로 입력할 때 기록되는 경우가 많습니다. | ||
| 중요한 이유 매출이 유입되기 시작했음을 보여주는 주요 이정표입니다. 청구 제출부터 지급 수령까지 걸리는 시간은 매출채권 성과를 측정하는 주요 지표입니다. 확보 방법 Resolute에 지급 거래로 명시적으로 기록됩니다. 거래에는 날짜, 출처, 금액이 저장되며, 개별 청구 항목에 완전히 반영되기 전에 기록되는 경우가 많습니다. 기록 재무 거래 로그에서 지급 거래를 가져옵니다. 거래 유형을 기준으로 식별하는 경우가 많습니다. 이벤트 유형 explicit | |||
| 지급자에게 청구 제출 | 청구서를 심사하도록 보험 지급자에게 공식 전송하는 이벤트입니다. Epic에서는 전자 청구 파일이 결제 정보 교환 기관 또는 지급자에게 전송될 때 추적해 기록합니다. | ||
| 중요한 이유 이 시점부터 지급자의 지급 처리 기간이 시작되므로 중요한 이정표입니다. 이를 분석하면 청구 전송 효율을 측정하고 '송장에서 지급자 전달까지 걸린 시간' KPI를 확인할 수 있습니다. 확보 방법 Resolute에 명시적으로 기록되는 이벤트입니다. 청구 레코드에는 제출 상태와 전송 시각이 저장됩니다. 기록 청구 상태가 'Submitted' 또는 'Transmitted'로 변경된 시각을 가져옵니다. 이벤트 유형 explicit | |||
| 지급자의 청구 거부 | 지급자로부터 청구 거부 통지를 받는 이벤트입니다. Epic에서 전자 지급 명세서(835 파일)를 처리하거나 사용자가 거부 내역을 수동으로 등록할 때 기록됩니다. | ||
| 중요한 이유 이 활동을 계기로 중요한 재작업 과정이 시작됩니다. 거부 사유와 건수를 분석하면 근본 원인을 찾아 최초 지급률을 높이고 수금 지연을 줄일 수 있습니다. 확보 방법 청구 거래 또는 상태 업데이트로 명시적으로 기록됩니다. 사유 코드 등 거부 정보는 일반적으로 전자 방식으로 수신되어 계정에 등록됩니다. 기록 거부를 나타내는 특정 거래 유형이나 청구 상태 업데이트를 필터링합니다. 이벤트 유형 explicit | |||
| 청구 항목 포착 | 제공된 서비스에 대해 청구 가능한 항목을 공식적으로 기록하는 단계입니다. Epic에서는 일반적으로 환자 계정에 거래 내역으로 명시적으로 등록됩니다. 임상 활동에 따라 자동 생성되거나 수동으로 입력될 수 있습니다. | ||
| 중요한 이유 중요한 첫 번째 이정표입니다. 청구 항목 포착의 속도와 정확도를 측정하면 청구 처리를 앞당기고 제공된 모든 서비스가 청구되도록 관리할 수 있습니다. 확보 방법 Resolute의 거래 로그에 명시적으로 기록됩니다. 각 청구 항목은 게시 날짜, 서비스 날짜, 금액이 포함된 개별 항목이며, ARPB_TRANSACTIONS와 같은 테이블에서 확인할 수 있습니다. 기록 시스템의 재무 거래 로그에서 청구 항목 게시 거래를 가져옵니다. 이벤트 유형 explicit | |||
| 거부 후속 조치 시작 | 거부된 청구를 검토하고 해결하는 내부 절차가 시작되는 단계입니다. 사용자가 작업 대기열에서 거부된 청구를 맡거나 상태를 변경할 때 기록되는 경우가 많습니다. | ||
| 중요한 이유 이 단계를 추적하면 거부 관리팀의 대응 속도를 측정할 수 있습니다. 거부 통지부터 후속 조치 시작까지 지연되면 매출 주기가 불필요하게 길어질 수 있습니다. 확보 방법 일반적으로 Epic 작업 대기열의 청구 상태나 담당자 지정 이력 변경을 바탕으로 추정합니다. 예를 들어 청구 상태가 'Denied'에서 'In Review'로 바뀔 수 있습니다. 기록 청구 상태 변경이나 사용자가 거부 건을 처리하기 시작했음을 보여주는 감사 로그 항목을 바탕으로 추정합니다. 이벤트 유형 inferred | |||
| 계정 조정 | 계약상 조정, 소액 잔액 상각, 고객 배려 할인 등 지급과 무관하게 계정 잔액을 변경하는 거래입니다. 특정 거래 유형으로 기록됩니다. | ||
| 중요한 이유 조정 내역을 분석하면 매출 누수를 파악할 수 있습니다. 특정 유형의 조정이 많다면 수가표, 계약 조건 또는 내부 정책에 문제가 있을 수 있습니다. 확보 방법 Resolute의 재무 로그에 조정 거래로 명시적으로 기록됩니다. 각 조정에는 특정 유형이나 사유 코드가 연결됩니다. 기록 재무 조정이나 상각에 해당하는 거래 유형을 필터링합니다. 이벤트 유형 explicit | |||
| 미수 잔액을 수금 절차로 이관 | 미납 계정 잔액이 내부 또는 외부 수금 절차로 넘어가는 시점입니다. 계정이나 청구 이벤트의 상태 변경으로 명시적으로 기록되는 경우가 많습니다. | ||
| 중요한 이유 미수 잔액 회수의 마지막 단계가 시작되는 활동입니다. 대손을 줄이려면 수금 절차의 성공률과 처리 기간을 추적해야 합니다. 확보 방법 일반적으로 명시적인 이벤트로 기록됩니다. Epic에서 계정을 수금 대행사로 이관하면 로그 항목이나 계정 상태 변경이 생성됩니다. 기록 계정이 수금 대행사에 이관되었음을 나타내는 상태 변경이나 거래를 찾습니다. 이벤트 유형 explicit | |||
| 청구 생성 | 포착된 청구 항목을 바탕으로 시스템이 공식 청구서 또는 송장을 생성하는 단계입니다. 보험 지급자나 환자에게 청구서를 보내기 전에 진행됩니다. | ||
| 중요한 이유 청구 생성을 추적하면 청구 항목 포착부터 제출 준비까지의 지연을 구분해 파악할 수 있습니다. 전체 청구 처리 시점에 영향을 주는 주요 내부 단계입니다. 확보 방법 일반적으로 청구 또는 청구서 생성 배치 작업이 실행될 때 기록됩니다. 특정 계정의 청구 파일(예: 837 파일)이 생성된 시각이 시스템에 저장됩니다. 기록 청구서가 취합되어 제출 준비를 마쳤음을 나타내는 로그 항목이나 상태 변경을 찾습니다. 이벤트 유형 explicit | |||
| 청구 재제출 | 거부된 청구를 수정한 뒤 지급자에게 다시 보내는 이벤트입니다. 최초 제출과 구분되는 제출 이벤트이며 원래 청구와 연결됩니다. | ||
| 중요한 이유 재작업 과정의 주요 단계입니다. 재제출까지 걸리는 시간과 재제출 청구의 성공률을 측정하면 거부 해결 절차의 효과를 파악할 수 있습니다. 확보 방법 최초 제출과 마찬가지로 명시적으로 기록되지만, 재제출로 표시되는 경우가 많습니다. 청구 레코드에 새 제출 시각이 표시되며 재제출 코드가 포함될 수 있습니다. 기록 수정 또는 재제출로 표시된 청구 제출의 타임스탬프를 가져옵니다. 이벤트 유형 explicit | |||
데이터 추출 가이드
단계
- 데이터베이스 연결 설정: Epic Clarity 데이터베이스에 대한 읽기 전용 계정 정보를 받습니다. DBeaver 또는 Microsoft SQL Server Management Studio와 같은 표준 SQL 클라이언트로 데이터베이스 서버에 연결합니다.
- 주요 테이블 확인: 추출에 사용할 주요 테이블은 사례 정보의
HSP_ACCOUNT, 재무 이벤트의HSP_TRANSACTIONS, 청구 상태의CLP_CLAIM_INFO, 결제 입력 상세 정보의F_ARHB_TX_SET_POST_HX입니다. 사용자 정보는CLARITY_EMP와 같은 마스터 파일을 조인해 가져옵니다. - 분석 범위 설정: 쿼리를 작성하기 전에 분석 범위를 정합니다. 일반적으로 3~6개월의 날짜 범위를 지정하고, 포함하거나 제외할 병원 서비스 영역(
SERV_AREA_ID) 또는 계정 분류를 선택합니다. - SQL 쿼리 작성: 먼저 공통 테이블 식(CTE)을 사용해 설정한 범위에 해당하는
HSP_ACCOUNT_ID값을 조회하는 SQL 쿼리를 작성합니다. 이 값이 청구 이벤트의 기본 모집단이 됩니다. - 활동별 쿼리 작성: 필요한 12개 활동마다 관련 테이블에서 데이터를 가져오는 별도의
SELECT문을 작성합니다. 초기 CTE와 다시 조인해 지정한 계정만 분석하도록 합니다. - UNION ALL로 쿼리 결합:
UNION ALL연산자로 각 활동 쿼리의 결과를 하나의 이벤트 로그로 결합합니다. 각 쿼리의 행이 세로로 이어집니다. - 표준 스키마에 맞게 매핑: 각
SELECT문에서 열 이름을BillingEvent,ActivityName,EventTimestamp,ResponsibleUser등 ProcessMind 스키마에 맞게 별칭으로 지정합니다. 특정 활동에 해당하지 않는 속성에는NULL을 사용합니다. - 쿼리 실행 및 조정: 완성된 쿼리를 Clarity 데이터베이스에서 실행합니다. 테이블 크기에 따라 상당한 시간이 걸릴 수 있습니다. 성능 문제가 있으면 날짜 범위를 줄이거나 초기 CTE에 더 구체적인 필터를 추가합니다.
- 결과 검토: 쿼리가 완료되면 결과의 처음 몇백 행을 확인합니다. 모든 열이 있는지, 타임스탬프 형식이 일관적인지, 예상한
ActivityName값이 표시되는지 검증합니다. - CSV로 내보내기: SQL 클라이언트에서 전체 결과를 CSV 파일로 내보냅니다. UTF-8 인코딩을 사용하고 올바른 열 이름이 포함된 헤더 행을 넣습니다.
- 업로드 준비: ProcessMind에 업로드하기 전에 CSV 파일을 열어 서식 오류가 없는지 확인합니다. 예를 들어 타임스탬프 형식이
YYYY-MM-DD HH:MI:SS로 일관적인지 점검합니다. 이제 파일을 가져올 수 있습니다.
구성
- 데이터베이스 연결: Epic Clarity 데이터베이스에 접근할 수 있는 읽기 전용 사용자 계정이 필요합니다.
- 날짜 범위 매개변수: 제공된 쿼리에는
@StartDate및@EndDate변수가 사용됩니다. 분석 기간을 지정하려면 값을 설정해야 합니다. 데이터 양과 성능의 균형을 위해 3~6개월 범위를 권장합니다. - 테이블 및 열 매핑: 쿼리는 Clarity의 표준 테이블 및 열 이름을 전제로 합니다. 조직의 Epic 구성이나 버전에 따라 이름이 다를 수 있으므로 테이블 이름, 열 이름 또는 조인 조건을 조정해야 할 수 있습니다.
- 거래 및 상태 코드: 쿼리에는
[Your Denial Tx Type]및[Your Collections Status Code]와 같은 자리표시자가 포함되어 있습니다. 해당 Epic 시스템의 올바른 코드를 확인하려면 Epic 시스템 관리자에게 문의하거나ZC_TX_TYPE,ZC_ACCOUNT_STATUS와 같은 관련 마스터 파일을 검토해야 합니다. - 필터링: 성능을 높이고 분석 범위를 구체화하려면 초기
BaseAccountsCTE에 필터를 추가합니다. 일반적으로SERV_AREA_ID로 병원 서비스 영역을 제한하거나ACCOUNT_CLASS_C로 입원 또는 외래 청구를 선택할 수 있습니다.
샘플 쿼리 sql
DECLARE @StartDate DATE = '2023-01-01';
DECLARE @EndDate DATE = '2023-06-30';
WITH BaseAccounts AS (
SELECT DISTINCT
HA.HSP_ACCOUNT_ID
FROM
HSP_ACCOUNT HA
WHERE
HA.ADM_DATE_TIME >= @StartDate
AND HA.ADM_DATE_TIME <= @EndDate
-- Add additional filters here if needed, for example:
-- AND HA.SERV_AREA_ID = [Your Service Area ID]
)
-- 1. Service Rendered
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Service Rendered' AS ActivityName,
tx.SERVICE_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
AND tx.ORIG_REV_TX_ID IS NULL -- Not a reversal
UNION ALL
-- 2. Charges Captured
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Charges Captured' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
proc.PROC_NAME AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EAP proc ON tx.PROC_ID = proc.PROC_ID
WHERE tx.TX_TYPE_C = 1 -- Charge Transaction Type
UNION ALL
-- 3. Claim Generated
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Generated' AS ActivityName,
claim.GENERATED_TIME AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.GENERATED_TIME IS NOT NULL
UNION ALL
-- 4. Claim Submitted to Payer
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
claim.XMIT_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- Often a system process
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE claim.XMIT_DATE IS NOT NULL
UNION ALL
-- 5. Claim Denied by Payer
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
remit.REMIT_CODE_ID AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN F_ARHB_TX_SET_POST_HX remit ON tx.TX_ID = remit.TX_ID
WHERE tx.TX_TYPE_C IN ([Your Denial Tx Type]) -- Placeholder for denial transaction type codes
UNION ALL
-- 6. Denial Follow-Up Initiated (assumes status change on account)
SELECT
hist.HSP_ACCOUNT_ID AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
NULL AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCT_STATUS_HX hist
INNER JOIN BaseAccounts ba ON hist.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON hist.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE hist.ACCOUNT_STATUS_C = [Your Denial Followup Status Code] -- Placeholder for a status indicating follow-up
UNION ALL
-- 7. Claim Resubmitted
SELECT
claim.HSP_ACCOUNT_ID AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
claim.RESUBMIT_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM CLP_CLAIM_INFO claim
INNER JOIN BaseAccounts ba ON claim.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON claim.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON claim.RESUBMIT_USER_ID = emp.USER_ID
WHERE claim.RESUBMIT_DATE IS NOT NULL
UNION ALL
-- 8. Payment Received & 9. Payment Posted to Account (combined for this query)
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE tx.TX_TYPE_C IN ([Your Payer Payment Tx Type], [Your Patient Payment Tx Type]) -- Placeholder for payment transaction types
UNION ALL
-- 10. Account Adjustment Made
SELECT
tx.HSP_ACCOUNT_ID AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
tx.POST_DATE AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
zcar.NAME AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_TRANSACTIONS tx
INNER JOIN BaseAccounts ba ON tx.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN HSP_ACCOUNT acct ON tx.HSP_ACCOUNT_ID = acct.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_EMP emp ON tx.POSTING_USER_ID = emp.USER_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN ZC_ADJ_REASON zcar ON tx.ADJ_REASON_C = zcar.ADJ_REASON_C
WHERE tx.TX_TYPE_C IN ([Your Adjustment Tx Type]) -- Placeholder for adjustment transaction types
UNION ALL
-- 11. Balance Sent to Collections
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
hist.CHANGE_AUDIT_DTTM AS EventTimestamp,
emp.USER_ID AS ResponsibleUser,
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
INNER JOIN HSP_ACCT_STATUS_HX hist ON acct.HSP_ACCOUNT_ID = hist.HSP_ACCOUNT_ID AND hist.ACCOUNT_STATUS_C = [Your Collections Status Code]
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
LEFT JOIN CLARITY_EMP emp ON hist.CHANGE_AUDIT_USER_ID = emp.USER_ID
WHERE acct.ACCOUNT_STATUS_C = [Your Collections Status Code] -- Placeholder for collections status
UNION ALL
-- 12. Account Closed
SELECT
acct.HSP_ACCOUNT_ID AS BillingEvent,
'Account Closed' AS ActivityName,
acct.CLOSED_DATE AS EventTimestamp,
NULL AS ResponsibleUser, -- System or Final transaction user
dep.DEPARTMENT_NAME AS BillingDepartment,
NULL AS DenialReasonCode,
NULL AS AdjustmentReason,
acct.ACCT_FIN_BALANCE AS OutstandingBalance,
NULL AS ServiceType
FROM HSP_ACCOUNT acct
INNER JOIN BaseAccounts ba ON acct.HSP_ACCOUNT_ID = ba.HSP_ACCOUNT_ID
LEFT JOIN CLARITY_DEP dep ON acct.DEPARTMENT_ID = dep.DEPARTMENT_ID
WHERE acct.ACCT_FIN_BALANCE = 0
AND acct.CLOSED_DATE IS NOT NULL
AND acct.CLOSED_DATE BETWEEN @StartDate and @EndDate
ORDER BY
BillingEvent,
EventTimestamp; 단계
- 계정, 비용, 청구, 거부, 결제, 조정, 회수 및 종료 이력을 확인하는 데 필요한 원천 테이블과 뷰를 포함해 Epic Clarity 수익 주기 데이터에 대한 승인된 접근 권한이 있는지 확인합니다. Epic 조직마다 사용할 수 있는 테이블과 열 이름이 다르므로 쿼리의 각 자리표시자를 해당 환경의 Clarity 객체에 매핑합니다.
- [Start date parameter] 및 [End date parameter]를 사용해 추출 기간을 정합니다. 처음에는 3~6개월을 사용하고, 쿼리 성능과 이벤트 누락 여부를 확인한 뒤에만 기간을 늘립니다.
- BillingEvent 매핑을 설정합니다. 쿼리에서는 사용 가능한 경우
HSP_ACCOUNT.HSP_ACCOUNT_ID를 기본 사례 식별자로 사용합니다. 조직에서 청구 이벤트를 비용, 청구 또는 진료 단위로 정의한다면 승인된 식별자로 매핑을 바꾸고 모든 활동 원천에서 동일하게 유지합니다. - 각 원천 활동을 신뢰할 수 있는 타임스탬프 및 원천 속성에 매핑합니다. Service Rendered에는 문서화된 서비스 또는 진료 완료 시각을 사용합니다. Charges Captured에는 비용 입력 시각을 사용합니다. Claim Generated 및 Claim Submitted to Payer에는 해당 청구 생애주기 시각을 사용합니다. 거부, 후속 조치, 재제출, 결제, 조정, 회수 및 종료에는 문서화된 거래 또는 상태 시각을 사용합니다.
- 쿼리에 대괄호로 표시된 모든 원천 자리표시자를 실제 값으로 바꿉니다. 여기에는 [Your service source table], [Your charge source table], [Your claim source table], [Your denial source table], [Your follow-up source table], [Your payment source table], [Your adjustment source table], [Your collections source table], [Your account closure source table]이 포함됩니다. 문서화되지 않은 거래 코드를 임의로 사용하지 마세요. Epic 보고 팀이 승인한 거래 또는 상태 값을 사용합니다.
- 조직에서 승인한 SQL 클라이언트 또는 보고 플랫폼에서 쿼리를 실행합니다. 12개 활동 레이블이 모두 개별 행으로 반환되는지 확인합니다. ProcessMind는 잔액, 상태 또는 이벤트 순서를 바탕으로 누락된 생애주기 이벤트를 추정하지 않습니다.
- 결과 스키마를 검토합니다. 결과에는 BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType가 포함되어야 합니다. 시간대 또는 현지 시각에 대한 설명과 함께 타임스탬프를 보존하고, 허용되는 경우 내부 감사용 추출본에 원천 식별자를 유지합니다.
- 각 BillingEvent 내 시간순 정렬, 중복 처리, NULL 비율, 활동 수 및 원천 시스템 보고서와의 대사를 검증합니다. 보고 기간 전에 시작했거나 이후에 끝나는 사례를 해석하는 데 필요한 기간 외 이벤트도 확인합니다.
- 결과를 ProcessMind에서 지원하는 구분자 파일 또는 데이터베이스 연결로 내보냅니다. 이벤트당 한 행을 사용하고, 열 이름을 일관되게 유지하며, 타임스탬프 형식을 통일하고, UTF-8 인코딩을 적용합니다. 병합된 셀이나 보고용 합계 행은 포함하지 않습니다. 업로드할 때 BillingEvent를 사례 식별자, ActivityName을 활동, EventTimestamp를 이벤트 시각으로 지정합니다.
구성
- 원천 매핑: Epic Clarity 구현 환경마다 구성이 다릅니다. 대괄호로 표시된 원천 객체 및 열 자리표시자를 해당 환경에서 문서화된 테이블, 뷰 또는 승인된 보고 계층으로 바꿉니다. 다른 Epic 환경에서 흔히 사용된다는 이유만으로 테이블이나 필드가 있다고 가정하지 마세요.
- 사례 식별자: 기본 쿼리는
HSP_ACCOUNT.HSP_ACCOUNT_ID를 사용합니다. 조직에서 BillingEvent를 계정, 진료, 청구, 비용 또는 다른 승인된 업무 키로 정의하는지 확인합니다. - 날짜 범위: 처음에는 3~6개월로 설정합니다. 사례가 보고 기간 전에 시작될 수 있으면 이전 기간을 포함하고, 서비스 날짜 이후에 청구, 거부, 결제 또는 종료가 발생할 수 있으면 후속 기간도 포함합니다.
- 활동 타임스탬프: 각 활동에 신뢰할 수 있는 타임스탬프를 하나씩 지정합니다. 추출 시각, 파일 로드 시각 또는 현재 상태 시각을 실제 업무 이벤트 시각 대신 사용하지 마세요. 단, 해당 값이 문서화된 원천 시스템 이벤트 시각인 경우는 예외입니다.
- 필터: [Company Code filter], [Document Type filter], [Department filter], 지급자, 서비스 영역 및 계정 분류 필터는 정의가 문서화되어 있고 분석에 필요한 경우에만 적용합니다. 모든 UNION ALL 분기에서 필터를 일관되게 유지합니다.
- 거래 및 상태 매핑: 비용 입력, 청구 생성, 청구 제출, 거부, 후속 조치, 재제출, 결제 수령, 결제 입력, 조정, 회수 및 종료에 조직에서 승인한 값을 설정합니다. Epic 구현 환경마다 거래 값과 원천 구조가 다르므로 쿼리에는 의도적으로 자리표시자를 사용했습니다.
- NULL 처리: 활동에 해당하지 않는 속성은
NULL로 유지합니다. 누락된 거부 사유, 조정 사유, 사용자, 부서 또는 서비스 유형에 임의의 값을 넣지 마세요. - 성능: 인덱스가 적용된 날짜 열과 승인된 조직 필터를 사용해
HSP_ACCOUNT와 조인하기 전에 원천 행을 제한합니다. 조건식에서 인덱스가 적용된 타임스탬프 열에 함수를 적용하지 마세요. 원시 이력 데이터가 많으면 승인된 보고 뷰에서 원천 활동별 데이터를 미리 구체화하는 방안을 검토합니다. - 중복 제거: 문서화된 규칙 없이 중복 이벤트를 제거하지 마세요. 하나의 BillingEvent에 여러 결제, 조정, 제출 또는 상태 변경이 발생하는 것은 정상일 수 있습니다.
- 사전 요건: Epic Clarity 보고 권한, 수익 주기 및 계정 이력 데이터 접근 권한, 승인된 SQL 실행 환경, 보호 대상 건강 정보에 대한 조직의 승인 등이 필요할 수 있습니다. 청구, 지급 명세, 작업 큐, 회수 및 종료 이력의 제공 여부는 라이선스와 Epic 모듈 및 인터페이스의 구현 상태에 따라 달라집니다.
샘플 쿼리 sql
WITH
service_rendered AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Service Rendered' AS ActivityName,
CAST(s.[Service rendered timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(s.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(s.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(s.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(s.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your service source table] s
ON s.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE s.[Service rendered timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND s.[Service rendered timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND [Your company code filter]
),
charges_captured AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Charges Captured' AS ActivityName,
CAST(t.[Charge captured timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(t.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(t.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(t.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(t.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN AR_PB_TRANSACTIONS t
ON t.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE t.[Charge captured timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND t.[Charge captured timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND t.[Charge transaction filter]
AND [Your company code filter]
),
claim_generated AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Generated' AS ActivityName,
CAST(c.[Claim generated timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim generated timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim generated timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim generated status filter]
AND [Your company code filter]
),
claim_submitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Submitted to Payer' AS ActivityName,
CAST(c.[Claim submitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim submitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim submitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim submitted status filter]
AND [Your company code filter]
),
claim_denied AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Denied by Payer' AS ActivityName,
CAST(d.[Denial timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(d.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(d.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(d.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(d.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(d.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your denial source table] d
ON d.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE d.[Denial timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND d.[Denial timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND d.[Denial status filter]
AND [Your company code filter]
),
denial_follow_up AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Denial Follow-Up Initiated' AS ActivityName,
CAST(f.[Follow-up timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(f.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(f.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(f.[Denial reason code column] AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(f.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(f.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your follow-up source table] f
ON f.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE f.[Follow-up timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND f.[Follow-up timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND f.[Follow-up status filter]
AND [Your company code filter]
),
claim_resubmitted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Claim Resubmitted' AS ActivityName,
CAST(c.[Claim resubmitted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(c.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(c.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(c.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(c.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your claim source table] c
ON c.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE c.[Claim resubmitted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND c.[Claim resubmitted status filter]
AND [Your company code filter]
),
payment_received AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Received' AS ActivityName,
CAST(p.[Payment received timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment received timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment received timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment received status filter]
AND [Your company code filter]
),
payment_posted AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Payment Posted to Account' AS ActivityName,
CAST(p.[Payment posted timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(p.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(p.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(p.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(p.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your payment source table] p
ON p.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE p.[Payment posted timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND p.[Payment posted timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND p.[Payment posted status filter]
AND [Your company code filter]
),
account_adjustment AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Adjustment Made' AS ActivityName,
CAST(x.[Adjustment timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(x.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(x.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(x.[Adjustment reason column] AS VARCHAR(100)) AS AdjustmentReason,
CAST(x.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(x.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your adjustment source table] x
ON x.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE x.[Adjustment timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND x.[Adjustment timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND x.[Adjustment transaction filter]
AND [Your company code filter]
),
balance_collections AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Balance Sent to Collections' AS ActivityName,
CAST(k.[Collections timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(k.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(k.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(k.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(k.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your collections source table] k
ON k.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE k.[Collections timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND k.[Collections timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND k.[Collections status filter]
AND [Your company code filter]
),
account_closed AS (
SELECT
CAST(a.HSP_ACCOUNT_ID AS VARCHAR(100)) AS BillingEvent,
'Account Closed' AS ActivityName,
CAST(z.[Account closed timestamp column] AS TIMESTAMP) AS EventTimestamp,
CAST(z.[Responsible user column] AS VARCHAR(100)) AS ResponsibleUser,
CAST(z.[Billing department column] AS VARCHAR(100)) AS BillingDepartment,
CAST(NULL AS VARCHAR(100)) AS DenialReasonCode,
CAST(NULL AS VARCHAR(100)) AS AdjustmentReason,
CAST(z.[Outstanding balance column] AS DECIMAL(18,2)) AS OutstandingBalance,
CAST(z.[Service type column] AS VARCHAR(200)) AS ServiceType
FROM HSP_ACCOUNT a
INNER JOIN [Your account closure source table] z
ON z.[Billing event join column] = a.HSP_ACCOUNT_ID
WHERE z.[Account closed timestamp column] >= CAST('[Start date parameter]' AS TIMESTAMP)
AND z.[Account closed timestamp column] < CAST('[End date parameter]' AS TIMESTAMP)
AND z.[Account closed status filter]
AND [Your company code filter]
)
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM service_rendered
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM charges_captured
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_generated
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_submitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_denied
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM denial_follow_up
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM claim_resubmitted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_received
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM payment_posted
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_adjustment
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM balance_collections
UNION ALL
SELECT BillingEvent, ActivityName, EventTimestamp, ResponsibleUser, BillingDepartment, DenialReasonCode, AdjustmentReason, OutstandingBalance, ServiceType FROM account_closed
ORDER BY BillingEvent, EventTimestamp, ActivityName; 시작할 준비가 되셨나요?
정확한 데이터를 바탕으로 수익 주기 관리 프로세스를 개선하세요. 지금 효율성과 재무 성과를 높이기 위한 첫걸음을 시작하세요.
RCM 효율성을 높이세요. 지금 수익 주기 관리를 최적화하세요
Epic Resolute RCM의 비효율을 파악하고 주기 소요 시간을 30% 단축하세요.
신용카드 없이 지금 최적화를 시작하세요.