매출 주기 관리 데이터 템플릿

R1 RCM
매출 주기 관리 데이터 템플릿

매출 주기 관리 데이터 템플릿

이 데이터 템플릿은 매출 주기 관리 프로세스 분석에 필요한 정보를 수집하는 방법을 안내합니다. 수집해야 할 주요 속성과 추적할 활동을 확인할 수 있습니다. R1 RCM에서 데이터를 추출하는 방법도 안내하므로 process mining을 시작하기 전에 데이터를 준비할 수 있습니다.
  • 수집 권장 속성
  • 프로세스 탐색을 위해 추적할 주요 활동
  • R1 RCM 데이터 추출 안내
이벤트 로그가 처음이신가요? 알아보기 process mining 이벤트 로그 만드는 방법.

매출 주기 관리 속성

매출 주기 관리 프로세스를 분석할 때 이벤트 로그에 포함할 것을 권장하는 데이터 필드입니다.
5 필수 6 권장 8 선택 사항
이름 설명
이벤트 시간
EventTime
특정 활동이나 이벤트가 발생한 시점을 나타내는 타임스탬프입니다.
설명

이벤트 시간은 시스템에 활동이 기록된 날짜와 시각을 정확하게 나타냅니다. 시간에 따른 프로세스 분석을 위해 반드시 필요한 정보입니다.

process mining에서는 이벤트를 시간순으로 정렬하고 활동 간 소요 시간을 계산하는 데 이 타임스탬프를 사용합니다. 이를 바탕으로 주기 시간, 처리 시간, 대기 시간과 같은 주요 지표를 계산할 수 있으며, 병목을 찾고 효율성을 측정하는 데 활용됩니다.

중요한 이유

주기 시간 계산, 병목 파악, SLA 기준에 따른 프로세스 성과 모니터링 등 시간 관련 분석의 기반이 됩니다.

확보 방법

일반적으로 R1 RCM에서 각 거래 또는 상태 변경 기록에 연결된 'Creation Date', 'Timestamp' 또는 'Last Update Date' 필드에 있습니다.

예시
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:12:45Z
청구 이벤트
BillingEvent
청구 대상 서비스 또는 항목 하나를 식별하는 고유 ID로, 전체 수익 주기를 추적하는 기본 케이스 식별자입니다.
설명

청구 이벤트 ID는 비용이 발생하는 서비스 또는 제품 제공 건을 고유하게 식별합니다. 서비스 제공과 비용 기록부터 청구서 제출, 지급금 반영, 계정 종료까지 관련된 모든 활동을 연결하는 기준이 됩니다.

process mining에서는 각 청구 이벤트의 전체 흐름을 분석해 수익 주기를 처음부터 끝까지 파악할 수 있습니다. 단일 청구 건의 진행 과정을 추적하고, 자주 나타나는 경로를 찾으며, 주요 단계 사이의 처리 시간을 측정하고, 지연이나 매출 누수로 이어지는 변동을 파악하는 데 사용됩니다.

중요한 이유

이 식별자를 기준으로 관련 활동을 하나의 케이스로 묶을 수 있어, 청구 이벤트별 수익 주기를 빠짐없이 정확하게 분석할 수 있습니다.

확보 방법

환자 진료, 비용, 청구 및 지급 관련 여러 테이블을 연결하는 기본 키입니다. 구체적인 필드는 R1 RCM 문서를 확인하세요. 진료 또는 청구 식별자와 관련된 필드인 경우가 많습니다.

예시
BE-2023-0012345BE-2023-0054321BE-2024-0098765
활동명
ActivityName
수익 주기 프로세스에서 특정 시점에 발생한 업무 이벤트 또는 작업의 이름입니다.
설명

이 속성은 특정 청구 이벤트의 수익 주기 관리 과정에서 수행된 단계나 주요 시점을 나타냅니다. 활동은 '비용 기록', '청구서 제출', '지급금 반영'처럼 실제로 수행된 업무를 의미합니다.

활동 순서를 분석하는 것은 process mining의 기본입니다. 이를 통해 실제 프로세스 흐름을 파악하고, 활동 시작까지 지나치게 오래 걸리는 병목을 찾으며, '청구 거부' 후 '거부 건 재처리 시작'처럼 불필요하게 반복되는 재작업을 확인할 수 있습니다.

중요한 이유

프로세스의 단계를 정의하므로 프로세스 맵을 시각화하고, 단계 간 소요 시간을 계산하며, 프로세스 이탈과 재작업을 파악할 수 있습니다.

확보 방법

일반적으로 이벤트 로그, 상태 변경 기록 또는 R1 RCM의 여러 모듈에 있는 거래 코드에서 가져옵니다. 기술 코드를 업무 담당자가 이해하기 쉬운 이름으로 매핑해야 할 수 있습니다.

예시
비용 입력 완료청구 제출지급자 심사 결과 수신지급금 입력계정 종료
소스 시스템
SourceSystem
이벤트 데이터를 추출한 기준 시스템입니다.
설명

이 속성은 특정 이벤트의 데이터를 생성한 소스 애플리케이션 또는 모듈을 식별합니다. 의료처럼 복잡한 환경에서는 EMR, 청구 모듈, 청구 중계 기관 또는 추심 플랫폼에서 데이터가 들어올 수 있습니다.

소스 시스템을 파악하면 데이터 검증에 도움이 되며, 특정 시스템에서만 나타나는 프로세스 차이도 분석할 수 있습니다. 데이터 불일치의 원인을 찾고 프로세스의 기술 환경을 이해하는 데 유용합니다.

중요한 이유

데이터의 출처를 식별합니다. 데이터 거버넌스와 검증에 중요하며, 전체 프로세스에서 시스템들이 어떻게 연동되는지 파악하는 데 도움이 됩니다.

확보 방법

데이터 추출 과정에서 추가하는 고정값인 경우가 많으며, 데이터가 시작된 시스템(예: 'R1 RCM')을 나타냅니다.

예시
R1 RCMCernerEpic
최종 데이터 업데이트
LastDataUpdate
소스 시스템에서 데이터를 마지막으로 새로 고치거나 추출한 시점의 타임스탬프입니다.
설명

이 속성은 process mining 분석에 사용되는 데이터가 마지막으로 업데이트된 시점을 나타냅니다. 분석 대상 데이터가 얼마나 최신인지 파악할 수 있습니다.

보고서와 대시보드에서 이 정보는 중요합니다. 사용자가 프로세스 분석 결과가 어느 시점까지의 데이터인지 확인할 수 있기 때문입니다. 데이터의 최신성에 대한 기대치를 조정하고, 데이터 기준 시점을 이해한 상태에서 의사결정을 내리는 데 도움이 됩니다.

중요한 이유

데이터의 최신성을 파악할 수 있어 분석가와 이해관계자가 프로세스 분석 결과가 얼마나 최신인지 확인할 수 있습니다.

확보 방법

이 타임스탬프는 데이터 추출, 변환 및 적재(ETL) 과정에서 생성되며, 일반적으로 전체 데이터셋에 적용됩니다.

예시
2024-05-20T08:00:00Z2024-05-21T08:00:00Z
담당 사용자
AssignedUser
활동을 수행한 직원의 사용자 ID 또는 이름입니다.
설명

이 속성은 프로세스에서 특정 작업을 수행한 담당자를 식별합니다. 청구서를 작성한 청구 담당자, 지급 거부 건을 재처리한 분석가, 지급금을 반영한 전문가 등이 해당합니다.

사용자별로 분석하면 업무량 배분, 개인별 성과, 교육 필요성을 파악할 수 있습니다. 처리 효율이 높은 사용자나 오류율이 높은 사용자를 확인해 맞춤형 관리와 프로세스 개선에 활용할 수 있습니다.

중요한 이유

팀과 개인의 성과 및 업무량 배분을 분석하고, 교육 기회나 사용자별 프로세스 이탈을 파악하는 데 도움이 됩니다.

확보 방법

일반적으로 R1 RCM의 거래 로그에서 'UserID', 'Processor' 또는 'UpdatedBy' 필드로 확인할 수 있습니다.

예시
jdoeasmithp.jonesBOT_RPA01
지급 거부 사유 코드
DenialReasonCode
청구가 거부된 이유를 지급자가 설명하는 표준 코드입니다.
설명

지급자가 청구를 거부하면 결정 사유를 설명하는 CARC(청구 조정 사유 코드)와 같은 코드를 제공합니다. 이 표준 코드는 '서비스 보장 대상 아님' 또는 '중복 청구'와 같은 문제를 나타냅니다.

이 속성은 지급 거부 관리에 매우 중요합니다. 지급 거부 사유 코드별 발생 빈도를 분석하면 환자 자격, 코딩 오류 또는 의학적 필요성 부족 등 거부의 근본 원인을 찾아 해결할 수 있습니다. 이를 통해 재작업을 줄이고 현금 흐름을 개선할 수 있습니다.

중요한 이유

청구가 거부된 구체적인 사유를 제공해 근본 원인을 분석하고, 향후 지급 거부와 재작업을 줄이며 최초 청구 지급률을 높일 수 있습니다.

확보 방법

이 정보는 지급자가 보내는 전자 지급 내역서(ERA 또는 835 파일)에 포함되며, R1 RCM의 청구 관리 모듈에 저장됩니다.

예시
CO-16: 심사에 필요한 정보가 청구 또는 서비스에 누락되었습니다.PR-97: 이 서비스의 혜택은 다른 서비스의 지급액 또는 허용 금액에 포함됩니다.CO-22: 보험 급여 조정에 따라 다른 지급자가 이 진료 비용을 보장할 수 있습니다.OA-18: 청구 또는 서비스가 완전히 중복됩니다.
지급자명
PayerName
지급 책임이 있는 보험사, 정부 기관 또는 환자의 이름입니다.
설명

이 속성은 청구 건의 주요 지급자를 식별합니다. Aetna와 같은 민간 보험사, Medicare와 같은 정부 지급자 또는 본인 부담금의 지급자인 환자가 해당할 수 있습니다.

지급자별 프로세스 분석은 수익 주기 관리의 기본입니다. 특정 지급자의 지급 거부율이 높거나 지급 주기가 길고 제출 요건이 복잡한지 확인할 수 있습니다. 이러한 분석 결과를 바탕으로 지급자별 특성에 맞게 프로세스와 리소스를 조정할 수 있습니다.

중요한 이유

지급자별로 프로세스를 구분해 지연, 지급 거부 유형, 지급 행태를 파악할 수 있습니다. 수익 최적화에 중요한 분석입니다.

확보 방법

R1 RCM에서 청구 건에 연결된 환자의 보험 또는 인구통계 정보에서 확인할 수 있습니다.

예시
MedicareUnitedHealthcareBlue Cross Blue ShieldAetna본인 부담
청구 금액
InvoiceAmount
청구서 또는 청구 건에 포함된 비용의 총액입니다.
설명

이 속성은 특정 청구 이벤트에서 제공한 서비스에 대해 청구한 총액을 나타냅니다. 청구를 통해 기대하는 수익을 보여줍니다.

청구 금액 분석은 재무 프로세스 분석에 중요합니다. 금액이 큰 청구 건의 우선순위를 정하고, 프로세스 지연이나 지급 거부가 재무에 미치는 영향을 파악하며, 금액에 따라 프로세스를 구분할 수 있습니다. 예를 들어 일정 금액을 초과하는 청구 건은 수작업이 더 많이 필요한 별도의 경로를 따르는 것으로 나타날 수 있습니다.

중요한 이유

프로세스에 재무적 맥락을 더해 프로세스 차이가 수익에 미치는 영향을 분석하고, 개선이 필요한 고액 케이스의 우선순위를 정할 수 있습니다.

확보 방법

R1 RCM의 기본 청구 또는 청구서 헤더 테이블에 있으며, 필드명은 'TotalBilledAmount' 또는 이와 유사한 이름일 수 있습니다.

예시
150.002500.7585.5012000.00
청구 부서
BillingDepartment
활동을 수행하는 부서 또는 기능별 팀입니다.
설명

이 속성은 '비용 입력', '청구서 제출', '지급 거부 관리'와 같이 특정 프로세스 단계를 수행한 조직 단위를 나타냅니다. 팀 간 업무 인계가 어떻게 이루어지는지 파악하는 데 도움이 됩니다.

부서별 처리량을 분석하고 부서 간 병목을 찾는 데 중요합니다. 부서별로 프로세스 맵을 필터링하면 업무 인계가 원활한 구간과 지연이 발생하는 구간을 확인할 수 있어, 리소스 배분과 조직 프로세스 개선에 활용할 수 있습니다.

중요한 이유

조직 단위별 프로세스 성과를 분석해 팀별 병목, 리소스 제약 또는 모범 사례를 파악할 수 있습니다.

확보 방법

R1 RCM의 사용자 프로필에서 가져오거나 거래 데이터의 'Department Code'로 저장할 수 있습니다.

예시
비용 기록보험 청구 관리지급 거부 및 이의 제기지급금 반영
청구 상태
InvoiceStatus
수명 주기에서 청구서 또는 청구 건의 현재 상태입니다.
설명

이 속성은 청구 이벤트의 마지막으로 확인된 상태를 나타냅니다. 예를 들어 '제출 완료', '지급 완료', '지급 거부' 또는 '추심 진행 중'이 있습니다. 특정 시점에 청구서가 프로세스의 어느 단계에 있는지 보여줍니다.

청구 상태는 미수금 경과 기간 보고서를 작성하고 매출채권 상태를 모니터링하는 데 중요합니다. process mining에서는 특정 상태에 머물러 있는 케이스를 필터링하거나, '지급 완료'와 '지급 거부' 청구 건의 경로를 비교하는 등 프로세스 유형별 결과를 분석할 수 있습니다.

중요한 이유

각 케이스의 현재 상태를 보여줍니다. 미수금 경과 기간 보고서를 작성하고 프로세스 경로별 최종 결과를 분석하는 데 필요합니다.

확보 방법

일반적으로 R1 RCM의 기본 청구 또는 계정 레코드에 있는 상태 필드입니다.

예시
제출 대기지급자에게 제출지급 거부전액 지급 완료추심 진행 중
서비스 제공부터 지급까지의 주기 시간
ServiceToPaymentCycleTime
서비스 제공 시점부터 최종 지급금 반영 시점까지의 총 계산 시간입니다.
설명

이 지표는 단일 청구 이벤트의 수익 주기 전체에 걸리는 시간을 측정합니다. 제공한 서비스를 현금으로 회수하기까지 걸리는 총 시간을 나타냅니다.

재무 건전성을 보여주는 주요 KPI입니다. 이 시간을 분석하면 프로세스 단축이 필요한 주요 영역을 찾을 수 있습니다. '청구까지 걸린 시간'과 '지급까지 걸린 시간'처럼 주기 시간을 구성 요소별로 나누면 현금 흐름을 개선할 기회가 가장 큰 구간을 파악할 수 있습니다.

중요한 이유

현금 전환 주기의 전반적인 효율성을 측정하는 주요 KPI로, 조직의 현금 흐름에 직접 영향을 미칩니다.

확보 방법

계산 지표입니다. 특정 청구 이벤트에서 '서비스 제공' 활동과 '지급금 반영' 활동의 타임스탬프 차이로 계산합니다.

예시
35일 8시간92일 4시간15일 12시간
서비스 코드
ServiceCode
제공한 특정 서비스 또는 시술의 청구 코드입니다. CPT 또는 HCPCS 코드 등이 해당합니다.
설명

CPT(Current Procedural Terminology) 코드와 같은 서비스 코드는 의료, 수술 및 진단 절차와 서비스를 지급자에게 청구할 때 사용하는 표준 의료 코드입니다.

서비스 코드별 프로세스 분석은 특정 진료 유형과 관련된 청구 문제를 찾는 데 중요합니다. 어떤 시술이 지급 거부를 가장 자주 당하는지, 지급 주기가 가장 긴지, 재작업이 가장 많이 필요한지 확인해 코딩 및 청구 업무를 집중적으로 개선할 수 있습니다.

중요한 이유

제공한 서비스 유형에 따라 프로세스를 분석할 수 있어, 특정 시술과 관련된 지급 거부 유형이나 지급 지연을 파악하는 데 도움이 됩니다.

확보 방법

R1 RCM에서 각 비용 또는 청구 건의 개별 항목 수준에서 확인할 수 있습니다.

예시
992139928573560
자동화 여부
IsAutomated
활동을 자동화 시스템이 수행했는지, 사용자가 직접 수행했는지를 나타내는 플래그입니다.
설명

이 불리언 속성은 청구서 제출용 RPA 봇과 같은 소프트웨어 자동화가 수행한 작업과 직원이 수작업으로 수행한 작업을 구분합니다.

이 속성을 분석하면 자동화 도입의 효과와 영향을 파악할 수 있습니다. 자동화와 수작업 프로세스의 속도, 비용, 오류율을 비교해 추가 자동화 기회를 찾고 기존 봇의 ROI를 측정할 수 있습니다.

중요한 이유

사람이 수행한 활동과 시스템이 수행한 활동을 구분합니다. 자동화가 프로세스 효율성, 비용 및 품질에 미치는 영향을 측정하는 데 중요합니다.

확보 방법

'AssignedUser' 필드에서 확인할 수 있습니다. 특정 사용자 ID를 봇 전용으로 지정하는 경우가 있습니다(예: 'BOT_RPA01'). 일부 시스템에는 자동화된 거래를 표시하는 전용 필드가 있습니다.

예시
truefalse
재작업 여부
IsRework
거부된 청구서를 다시 제출하는 것처럼 재작업이 반복되는 흐름에 포함된 활동을 식별하는 계산 플래그입니다.
설명

이 속성은 불리언 플래그로, 일반적으로 process mining 분석 중에 계산됩니다. 활동이 이전 단계를 반복하거나 오류를 수정하는 흐름의 일부인 경우 'true'로 설정됩니다. 예를 들어 '청구 거부' 이후의 활동이 해당할 수 있습니다.

재작업을 파악하는 것은 process mining의 주요 기능 중 하나입니다. 프로세스에서 낭비되는 노력, 시간, 리소스의 규모를 수치로 확인할 수 있습니다. 재작업을 표시하면 이를 유발하는 오류를 사전에 방지하는 데 개선 노력을 집중해 효율성을 높일 수 있습니다.

중요한 이유

청구 거부와 같은 재작업의 빈도와 영향을 수치로 파악해 비효율과 불필요한 업무를 줄이는 데 필요한 분석을 지원합니다.

확보 방법

소스 시스템에 있는 필드가 아닙니다. process mining 도구가 활동 순서를 바탕으로 계산합니다. 예를 들어 같은 케이스에서 '청구서 제출' 활동이 두 번 이상 발생했는지 확인합니다.

예시
truefalse
조정 금액
AdjustmentAmount
계정 잔액에 적용한 조정 금액입니다.
설명

이 속성은 최초 청구 후 환자 계정에 적용한 재무 조정 금액을 기록합니다. 조정액은 양수 또는 음수일 수 있으며, 계약상 감액, 상각 또는 정정이 포함됩니다.

조정 금액을 추적하는 것은 수익의 정확성을 파악하는 데 중요합니다. 음수 조정이 많으면 비용 기록 오류나 회수 불가능한 채무로 인한 매출 누수를 나타낼 수 있습니다. 이 데이터를 분석하면 청구 오류와 추심 비효율이 재무에 미치는 영향을 파악할 수 있습니다.

중요한 이유

매출 누수와 재무 조정 규모를 수치로 파악해 청구 오류, 계약상 의무 또는 대손이 금액에 미치는 영향을 확인할 수 있습니다.

확보 방법

R1 RCM에서 계정 조정 또는 지급금 반영과 관련된 거래 로그에 있습니다.

예시
-50.2520.00-1200.00
조정 사유
AdjustmentReason
'계약상 감액' 또는 '대손 상각'과 같이 재무 조정 사유를 나타냅니다.
설명

이 속성은 계정에 재무 조정을 적용한 이유를 설명합니다. 조정 유형을 분류하는 표준 코드나 설명을 사용하는 경우가 많습니다.

조정 사유를 분석하면 매출 누수의 근본 원인을 진단할 수 있습니다. 예를 들어 '소액 잔액 상각'이 자주 발생하면 소액 채권 추심이 비효율적일 수 있습니다. 반면 '계약상 감액'이 자주 발생하는 것은 지급자와의 계약에서 예상되는 결과일 수 있습니다. 이 분석은 청구 조정 및 규정 준수 감사 대시보드에 활용됩니다.

중요한 이유

수익 조정의 사유를 설명해 계약 문제, 청구 오류 또는 추심 실패와 같은 수익 손실의 근본 원인을 파악할 수 있습니다.

확보 방법

일반적으로 R1 RCM에서 AdjustmentAmount와 같은 거래 레코드에 있는 코드 또는 텍스트 필드입니다.

예시
계약상 감액대손 상각소액 잔액 상각청구 오류 정정
추심 결과
CollectionOutcome
미결 잔액에 대한 추심 활동의 최종 결과입니다.
설명

이 속성은 연체 계정의 지급금을 회수하기 위한 활동의 결과를 나타냅니다. 가능한 결과로는 '전액 지급 완료', '감액 합의', '대손 처리' 또는 '미해결'이 있습니다.

추심 결과를 추적하면 추심 프로세스의 효과를 평가할 수 있습니다. 어떤 활동이 어떤 결과로 이어지는지 분석해 추심 전략을 개선하고 회수율을 높일 수 있으며, 추심을 중단하고 잔액을 상각할 시점도 근거를 바탕으로 결정할 수 있습니다. 이 정보는 추심 활동 성과 대시보드에 활용됩니다.

중요한 이유

연체 계정의 최종 해결 결과를 추적해 추심 프로세스의 효과를 측정하고 추심 전략을 개선할 수 있습니다.

확보 방법

R1 RCM의 환자 계정 상태 필드 또는 전용 추심 모듈에 있을 수 있습니다.

예시
전액 지급 완료감액 합의외부 추심 대행사에 이관대손 상각 처리
환자 ID
PatientId
서비스를 받은 환자를 식별하는 고유 ID입니다.
설명

이 속성은 의료 시스템에서 환자에게 부여하는 고유 ID이며, 흔히 의무기록번호(MRN)라고 합니다.

개별 환자 진료 자체가 분석 대상은 아니지만, 환자 ID를 사용하면 같은 환자에게 시간이 지나면서 반복되는 청구 문제를 분석할 수 있습니다. 다른 환자 데이터와 연결하면 환자의 인구통계나 이력에 따라 프로세스를 구분해 특정 환자 집단에 영향을 미치는 시스템 문제를 찾을 수도 있습니다.

중요한 이유

환자별 청구 이벤트를 분석해 여러 진료에 걸쳐 특정 환자에게 반복되는 문제나 패턴을 파악할 수 있습니다.

확보 방법

R1 RCM에서 모든 진료 및 청구 건에 연결되는 환자 인구통계 데이터의 기본 식별자입니다.

예시
MRN837262MRN937281MRN103847
필수 권장 선택 사항

매출 주기 관리 활동

매출 주기 관리 프로세스를 정확히 파악하려면 이벤트 로그에 주요 단계와 마일스톤을 기록해야 합니다.
6 권장 8 선택 사항
활동 설명
계정 종료
청구 이벤트가 잔액 0으로 완전히 해결되고 계정이 공식적으로 종료됩니다. 해당 진료 건의 수익 주기가 성공적으로 완료되었음을 나타냅니다.
중요한 이유

프로세스가 정상적으로 완료되는 대표적인 종료 이벤트입니다. 계정 종료 주기를 측정하면 행정 업무가 효율적으로 완료되고 기록이 최종 확정되는지 확인할 수 있습니다.

확보 방법

계정 잔액이 0이 되고 최종 상태가 ‘종료’ 또는 ‘완납’으로 설정되면 추정합니다. 잔액을 0으로 만든 마지막 재무 거래의 타임스탬프를 사용합니다.

기록

계정 잔액이 0이 되고 ‘종료’ 상태가 설정된 시점과 최종 활동 타임스탬프를 기준으로 추정합니다.

이벤트 유형 inferred
비용 입력 완료
환자 진료에서 청구할 서비스, 시술, 소모품을 공식적으로 기록하는 활동입니다. 임상 활동을 재무 거래로 전환하는 중요한 데이터 입력 단계입니다.
중요한 이유

임상 운영에서 재무 운영으로 업무가 넘어가는 시점을 나타냅니다. 송장 및 청구 생성 주기 시간을 측정하는 시작점이며, 비용 입력 적체를 찾는 데 도움이 됩니다.

확보 방법

R1 RCM의 비용 입력 모듈에서 기록하거나 EHR 인터페이스를 통해 수신합니다. 일반적으로 특정 거래 로그나 비용 기록의 생성 타임스탬프로 표시됩니다.

기록

청구 테이블에 있는 비용 거래 기록의 생성 타임스탬프로 확인합니다.

이벤트 유형 explicit
서비스 제공 완료
환자에게 청구할 서비스나 시술이 완료된 시점을 나타냅니다. 이 이벤트는 임상 또는 일정 관리 시스템에서 기록되는 경우가 많으며 수익 주기의 시작점이 됩니다.
중요한 이유

서비스 제공부터 지급까지 걸리는 시간을 측정하는 KPI의 시작점입니다. 이 이벤트까지 걸린 시간을 분석하면 수익 주기 초반의 지연을 찾을 수 있습니다.

확보 방법

일반적으로 R1 RCM과 연동된 전자의무기록(EHR) 또는 진료 관리 시스템에서 가져옵니다. 환자 기록의 ‘서비스 날짜’ 또는 ‘시술 완료’ 타임스탬프를 기준으로 추정하는 경우가 많습니다.

기록

환자 진료와 연결된 ‘진료일’ 타임스탬프를 기준으로 추정합니다.

이벤트 유형 inferred
지급금 수령
지급자 또는 환자로부터 지급금을 받습니다. 자금이 들어온 시점을 나타내지만, 아직 특정 계정이나 서비스 항목에 적용되지는 않은 상태입니다.
중요한 이유

현금 유입을 나타냅니다. ‘지급금 수령’부터 ‘지급금 입력’까지의 시간 차이는 백오피스 효율과 현금 대사 지연을 파악하는 주요 지표입니다.

확보 방법

지급자의 전자 지급 내역 파일이나 환자 지급금 처리 기록에서 가져옵니다. 입금일 또는 파일 수신일에 해당합니다.

기록

ERA 파일의 지급 효력 발생일이나 환자 지급 거래일을 기준으로 기록합니다.

이벤트 유형 explicit
지급금 입력
받은 지급금을 환자 계정에 공식적으로 적용해 미결 잔액을 줄입니다. 청구한 서비스와 지급금을 대사하는 마지막 단계입니다.
중요한 이유

서비스 제공부터 지급까지 걸리는 시간과 지급금 입력 주기를 계산하는 종료 시점입니다. 수익이 인식되고 계정 정보가 정확히 갱신되었음을 확인할 수 있습니다.

확보 방법

R1 RCM 환자 회계 모듈에 명시적인 재무 거래로 기록됩니다. 입력 내역마다 날짜, 금액, 출처가 포함됩니다.

기록

사용자나 자동화된 프로세스가 지급금을 적용할 때 입력일과 함께 별도의 거래로 기록됩니다.

이벤트 유형 explicit
청구 제출
생성된 청구 건을 보험사 등 해당 지급자에게 전자 방식으로 제출합니다. 이는 지급을 받기 위한 청구 프로세스의 첫 외부 소통 단계입니다.
중요한 이유

지급자의 환급 처리 기간이 시작되는 중요한 시점입니다. 제출 현황을 추적하면 제출 적체를 파악하고 지급자별 제출 기한을 준수할 수 있습니다.

확보 방법

청구 건을 중계 기관으로 전송할 때 명시적인 거래로 기록됩니다. 시스템은 제출 시각과 확인 정보를 저장합니다.

기록

중계 기관을 통해 청구 건을 전송할 때 제출 타임스탬프와 함께 거래로 명시적으로 기록됩니다.

이벤트 유형 explicit
거부 청구 재작업 시작
사용자 또는 자동화된 워크플로가 거부된 청구 건을 조사하고 해결하기 시작합니다. 코딩 수정, 증빙 서류 제출, 지급자 결정에 대한 이의 제기 등이 포함될 수 있습니다.
중요한 이유

거부 청구에 따른 비용이 큰 재작업이 시작되는 시점을 나타냅니다. 이 단계에 걸리는 시간을 측정하면 거부 청구 관리팀의 효율성을 파악할 수 있습니다.

확보 방법

R1 RCM 작업 대기열이나 거부 청구 관리 모듈에서 거부된 청구의 상태가 ‘재작업 진행 중’ 또는 ‘검토 중’으로 변경된 시점을 기준으로 추정하는 경우가 많습니다.

기록

거부 청구 관리 작업 대기열의 상태 변경이나 거부된 청구에 대한 첫 사용자 작업을 기준으로 추정합니다.

이벤트 유형 inferred
계정 대손 처리
모든 수금 노력을 다했지만 계정 잔액을 회수할 수 없다고 판단했습니다. 잔액을 대손으로 상각하며, 이는 최종적인 수익 손실을 의미합니다.
중요한 이유

부정적인 프로세스 결과이자 직접적인 수익 손실입니다. 대손으로 끝나는 사례를 분석하면 미지급 패턴과 수금 개선 기회를 찾을 수 있습니다.

확보 방법

일반적으로 R1 RCM에서 미결 잔액을 특정 대손 항목으로 옮기는 명시적인 거래입니다. 사용자가 처리하거나 자동 연체 규칙이 실행할 수 있습니다.

기록

잔액을 상각하는 특정 재무 거래로 기록되며, 외부 수금 대행사로 이관하는 경우가 많습니다.

이벤트 유형 explicit
계정 조정
잔액을 변경하기 위해 지급이 아닌 거래를 계정에 입력합니다. 지급자 계약에 따른 계약 조정, 소액 잔액 상각, 정정 등이 포함될 수 있습니다.
중요한 이유

조정 건수가 많으면 수가표, 계약 관리, 청구 오류에 문제가 있을 수 있습니다. 수익의 정확성을 분석하려면 조정 내역을 추적해야 합니다.

확보 방법

R1 RCM 환자 회계 모듈에 특정 거래 유형으로 기록됩니다. 조정마다 코드, 금액, 입력일이 포함됩니다.

기록

고유한 거래 코드로 식별할 수 있는 별도의 조정 거래로 기록됩니다.

이벤트 유형 explicit
수금 활동 시작
환자 계정이 연체되면 선제적인 수금 활동을 시작합니다. 자동 안내문 발송부터 수금 담당자에게 계정 배정까지 다양한 조치가 포함될 수 있습니다.
중요한 이유

비용이 많이 드는 수금 프로세스의 시작을 나타냅니다. 수금 활동의 효과와 처리 시간을 분석하면 대손 회수 전략을 개선할 수 있습니다.

확보 방법

계정이 수금 작업 대기열로 이동하거나 R1 RCM에서 수금 상태 코드가 지정될 때 이벤트로 기록되거나 해당 상태 변경을 기준으로 추정할 수 있습니다.

기록

계정 상태가 ‘수금 중’ 또는 ‘연체’로 변경된 시점을 기준으로 추정합니다.

이벤트 유형 inferred
지급자 심사 결과 수신
시스템은 제출한 청구 건에 대한 지급자의 응답을 받습니다. 응답은 전자 지급 내역서(ERA) 파일로 전달되는 경우가 많으며, 지급·거부·조정 내역이 포함됩니다.
중요한 이유

이 이벤트에 따라 다음 단계가 지급금 입력인지 거부 청구 관리인지 결정됩니다. 이를 분석하면 지급자의 처리 방식과 지급 속도를 파악할 수 있습니다.

확보 방법

ANSI 835 파일과 같은 지급자의 전자 지급 내역 파일을 R1 RCM에서 처리할 때 기록합니다. 파일 처리 타임스탬프가 이벤트 시각으로 표시됩니다.

기록

전자 지급 내역(ERA/835) 파일을 수신하고 처리할 때 기록합니다.

이벤트 유형 explicit
청구 거부
지급자가 청구 건 전체 또는 특정 항목의 지급을 거부했습니다. 거부 사유가 기록되고 재작업 및 이의 제기 절차가 시작됩니다.
중요한 이유

이 활동은 수익 누수와 프로세스 비효율을 보여줍니다. 거부 사유를 분석하면 근본 원인을 찾고 최초 제출 시 청구 승인율을 높일 수 있습니다.

확보 방법

별도의 이벤트로 기록되는 것이 아니라 처리된 ERA 파일의 세부 정보에서 추정하는 상태입니다. 지급 내역 데이터에 특정 거부 코드가 있으면 청구 상태가 변경됩니다.

기록

처리된 ERA 파일에 포함된 거부 코드로 추정합니다. 해당 코드가 있으면 청구 상태가 ‘거부’로 변경됩니다.

이벤트 유형 inferred
청구 생성
입력된 비용을 바탕으로 시스템에서 공식 청구 건을 생성합니다. 환자 인구통계 정보, 보험 정보, 서비스 코드를 표준 형식으로 취합합니다.
중요한 이유

외부 제출 전에 거치는 중요한 내부 단계입니다. 이 단계의 지연은 코딩, 데이터 검증, 시스템 설정 문제를 나타낼 수 있으며 전체 청구 프로세스를 늦춥니다.

확보 방법

R1 RCM 내부에서 발생하는 시스템 이벤트입니다. 청구 계정의 상태 변경이나 청구 항목 자체의 생성 타임스탬프로 기록될 수 있습니다.

기록

상태가 ‘청구 생성’으로 변경된 시점이나 청구 기록의 생성 타임스탬프를 기준으로 추정합니다.

이벤트 유형 inferred
환자 명세서 생성
보험 심사가 끝나면 환자가 부담할 잔액을 안내하는 명세서를 생성합니다. 본인 부담금, 공제액, 보장 제외 서비스 비용 등이 포함될 수 있습니다.
중요한 이유

이 활동부터 수익 주기에서 환자 지급 단계가 시작됩니다. 환자 수금과 현금 흐름을 관리하려면 발생 시점과 빈도를 분석하는 것이 중요합니다.

확보 방법

환자 명세서를 생성해 인쇄하거나 전자 방식으로 발송하는 일괄 작업이 실행될 때 이벤트로 기록되는 경우가 많습니다. R1 RCM에는 명세서 생성일이 저장됩니다.

기록

환자 명세서를 생성하는 일괄 작업이 실행될 때 거래로 기록됩니다.

이벤트 유형 explicit
권장 선택 사항

데이터 추출 가이드

R1 RCM에서 데이터 가져오기

시작할 준비가 되셨나요?

이 템플릿으로 데이터 수집을 간소화하고 매출 주기 관리 최적화를 시작하세요. 진행 과정에서 필요한 지원을 제공해 드립니다.

지금 R1 RCM을 최적화해 매출 주기 효율을 높이세요

RCM 병목을 해소하고 처리 주기를 30% 단축해 현금 흐름을 개선하세요.

무료 체험 시작

신용카드 없이 몇 분 만에 시작할 수 있습니다.