수익 주기 관리 데이터 템플릿

이벤트 타임스탬프는 활동이 발생했거나 기록된 시점을 나타냅니다. 사례 내 모든 이벤트의 시간 순서를 보여주며, 수익 주기의 시작부터 종료까지 타임라인을 구성합니다.

타임스탬프는 process mining에서 성과를 분석하는 기반입니다. 전체 처리 시간, 특정 활동 간 소요 시간, 대기 시간과 같은 주요 KPI를 계산하는 데 사용됩니다. 타임스탬프를 분석하면 사례가 가장 오래 머무는 병목을 찾고 서비스 수준 협약 준수 여부를 측정하며 프로세스의 시간적 특성을 파악할 수 있습니다.

프로세스의 처리 시간 계산, 병목 식별, 성과와 효율성 분석에 필요한 시간순 데이터를 제공합니다.

이 정보는 일반적으로 거래 로그나 감사 추적에 기록되며, 이벤트 테이블의 '생성일' 또는 '상태 변경일' 필드로 제공되기도 합니다.

청구 이벤트 ID는 최초 청구 항목 포착부터 최종 지급 또는 대손 상각까지 청구 가능한 각 서비스 건에 부여되는 고유 키입니다. 특정 진료 건과 관련된 청구 건 생성, 제출, 거부, 지급 내역 반영 등의 활동을 연결하는 기준이 됩니다.

process mining에서는 이 속성을 사용해 각 청구 이벤트의 전체 흐름을 재구성합니다. 관련 활동을 하나의 청구 이벤트 ID로 묶으면 분석 담당자가 프로세스 흐름을 시각화하고 병목을 찾으며 처리 시간을 측정하고 사례별 처리 방식의 차이를 파악할 수 있습니다. 수익 주기에서 사례 단위 분석을 수행하는 기반이 됩니다.

관련 활동을 하나로 연결하는 필수 사례 식별자입니다. 이를 통해 청구 가능한 각 서비스의 수익 주기 전체를 재구성하고 분석할 수 있습니다.

일반적으로 청구 거래 또는 재무 이벤트 테이블의 기본 키입니다.

활동명은 수익 주기에서 발생한 개별 작업이나 이정표를 나타냅니다. 예를 들면 '서비스 제공', '청구 건 제출', '지급 내역 수신', '지급 내역 반영', '계정 대손 상각' 등이 있습니다. 각 활동은 시간과 리소스가 투입되는 프로세스 단계입니다.

이 속성은 프로세스 맵의 노드를 정의하므로 process mining의 기본 요소입니다. 활동의 순서와 빈도, 소요 시간을 분석하면 실제 프로세스 흐름을 시각화하고 설계된 모델과 비교할 수 있습니다. 또한 청구 거부와 같은 이탈 및 재작업, 비효율을 찾아낼 수 있습니다.

이 속성은 프로세스의 단계를 정의합니다. 프로세스 맵을 발견하고 시각화하며 재작업을 찾고 프로세스 적합성을 분석하는 데 필요합니다.

이벤트 로그나 거래 테이블에서 확인하거나 청구 또는 청구 건 모듈의 상태 변경 기록을 바탕으로 생성하는 경우가 많습니다.

원천 시스템 속성은 특정 이벤트 데이터의 출처를 나타냅니다. 복잡한 IT 환경에서는 매출 주기 프로세스가 여러 시스템에 걸쳐 진행되는 경우가 많습니다. 예를 들어 진료 서비스 제공에는 전자의무기록(EHR) 시스템을, 청구 제출에는 별도의 청구 시스템을, 미수금 회수에는 별도의 회수 플랫폼을 사용할 수 있습니다.

원천 시스템을 파악하면 데이터를 검증하고 문제를 해결하며 프로세스가 여러 시스템에 분산된 양상을 이해하는 데 도움이 됩니다. 시스템 간 불일치를 찾거나 서로 다른 애플리케이션에서 관리되는 프로세스 단계를 확인할 수 있으며, 이는 데이터 전송 지연이나 오류의 원인이 될 수 있습니다. 이러한 분석을 통해 프로세스를 지원하는 전체 IT 아키텍처의 통합 수준과 효율성을 평가할 수 있습니다.

서로 다른 IT 시스템에 분산된 프로세스를 파악하고, 데이터를 검증하며 시스템별 병목을 식별하는 데 중요합니다.

데이터 추출본의 표준 필드로 제공되는 경우가 많으며, 데이터가 추출된 원본 테이블이나 파일을 기준으로 확인할 수도 있습니다.

이 속성은 원천 시스템에서 데이터를 마지막으로 가져온 시각을 기록합니다. 분석 대상 데이터가 얼마나 최신인지, 적시에 제공되는지 파악하는 데 중요한 메타데이터입니다. 데이터 파이프라인의 지연 시간을 보여 주며, process mining 분석이 어느 시점의 데이터를 반영하는지 나타냅니다.

process mining 대시보드와 분석에서 최종 데이터 업데이트 시각은 데이터의 최신성을 판단할 수 있는 기준을 제공합니다. 화면에 표시된 프로세스 상태가 5분 전인지 전날 밤인지 확인하는 것은 운영 모니터링에 필수적입니다. 이를 통해 사용자의 기대치를 조정하고, 데이터의 기준 시점을 알고 의사결정을 내릴 수 있습니다.

데이터의 최신성과 적시성에 관한 정보를 제공하므로, 분석과 의사결정의 기준 시점을 명확히 할 수 있습니다.

일반적으로 데이터 추출, 변환, 적재(ETL) 과정에서 추가하며 이벤트 로그의 메타데이터 열에 저장합니다.

이 속성은 특정 프로세스 단계와 관련된 조직 단위를 나타냅니다. 예를 들어 '환자 접수', '코딩', '청구', '미수금 회수' 등이 있습니다. 업무가 팀 간에 어떻게 배분되고 인계되는지 파악하는 데 도움이 됩니다.

부서별로 프로세스를 분석하면 부서 간 협업을 이해하고 팀 간 인계 지점에서 발생하는 병목을 찾을 수 있습니다. 관리자는 특정 프로세스 변형에 어떤 부서가 관여하는지 확인하고, 부서별 효율성을 측정하며, 리소스를 더 효과적으로 배분할 수 있습니다. 또한 매출 주기 전체에 영향을 미치는 부서 내 구조적 문제를 발견할 수 있습니다.

부서 간 병목을 찾고 기능 영역별 성과를 분석해 팀 간 협업을 개선할 기회를 파악할 수 있습니다.

거래 데이터에 포함되어 있거나 담당 사용자와 연결된 기준 데이터를 바탕으로 확인할 수 있습니다.

담당 사용자 속성은 프로세스 단계를 해당 작업을 수행한 사람이나 시스템과 연결합니다. 의료 코딩을 완료한 코더, 청구를 제출한 청구 담당자, 결제를 등록한 자동화 봇 등이 여기에 해당합니다. 사용자를 추적하면 프로세스를 사람 또는 시스템 중심으로 분석할 수 있습니다.

사용자나 팀별 프로세스 성과를 분석하면 교육이 필요한 부분을 찾고, 성과가 높은 직원을 파악하며, 업무량을 적절히 배분할 수 있습니다. 또한 규정 준수와 감사에 필요한 책임 소재를 명확히 할 수 있습니다. 이 속성을 활용하면 리소스의 성과와 활용도를 자세히 분석할 수 있습니다.

팀과 개인의 성과, 업무량 배분, 자동화 비율을 분석해 리소스 효율성을 파악하고 교육이 필요한 부분을 찾을 수 있습니다.

일반적으로 거래 로그나 감사 추적의 '사용자 ID', '직원 ID' 또는 '처리자' 필드에서 확인할 수 있습니다.

서비스 유형은 환자에게 제공한 진료나 서비스의 종류를 분류합니다. '입원'과 '외래' 같은 상위 분류일 수도 있고, '수술', '응급', '검사실' 같은 구체적인 부서별 분류일 수도 있습니다. 서비스 유형에 따라 청구 규정, 지급자 요건, 프로세스 흐름이 달라지는 경우가 많습니다.

서비스 유형별로 매출 주기 프로세스를 구분해야 의미 있는 분석이 가능합니다. 예를 들어 수술과 상담의 청구 거부율을 비교하는 등 서비스 분야별 성과를 비교할 수 있습니다. 이렇게 세분화하면 문제를 분리해 파악하고 각 서비스 영역의 운영 상황에 맞는 개선 과제를 수립할 수 있습니다.

서비스 분야별 성과를 비교해 진료 유형에 따른 효율성, 청구 거부율, 지급 주기의 차이를 파악할 수 있습니다.

일반적으로 비용 상세 기록에서 확인할 수 있으며, 환자 유형, 부서 또는 시술 코드를 바탕으로 확인할 수도 있습니다.

조정 금액은 계약, 할인 또는 대손 처리 등의 사유로 지급자나 환자에게서 회수할 것으로 예상하지 않는 청구 금액의 일부입니다. 이러한 조정은 미수금을 줄이며 매출 주기에서 일반적으로 발생합니다.

조정 금액과 사유를 분석하면 매출의 정확성을 파악할 수 있습니다. 조정 금액이 지나치게 크거나 예상과 다르면 비용 입력, 코딩 또는 계약 관리에 문제가 있을 수 있습니다. process mining을 활용하면 조정률이 높은 프로세스 변형이나 특정 활동을 찾아 원인을 집중적으로 분석하고 매출 회수를 높일 수 있습니다.

대손 처리와 계약상 공제를 추적해 매출 누수를 분석하고, 계약이나 청구 프로세스의 잠재적 문제를 찾을 수 있습니다.

일반적으로 재무 조정 테이블이나 지급 등록 모듈에 기록됩니다.

지급자명은 보험금을 청구하는 주요 기관을 나타냅니다. Aetna나 UnitedHealthcare 같은 민간 보험사, Medicare나 Medicaid 같은 정부 프로그램, 그 밖의 기관이 지급자에 해당할 수 있습니다. 지급자마다 규정, 제출 요건, 지급 방식이 다릅니다.

이 속성은 매출 주기 성과를 분석하는 데 중요합니다. 지급자별로 프로세스를 구분하면 청구 거부율이 높거나 지급 주기가 길거나 추가 정보 요청이 잦은 지급자를 찾을 수 있습니다. 분석 결과를 바탕으로 계약을 재협상하고, 지급자별 제출 절차를 조정하며, 필요한 곳에 청구 거부 관리 노력을 집중할 수 있습니다.

지급자별 청구 거부율과 지급 소요 시간 등의 지표를 비교할 수 있어, 개선 과제와 계약 협상에 필요한 근거를 마련할 수 있습니다.

일반적으로 환자 등록, 보험 또는 청구 데이터에서 청구 이벤트와 연결된 정보로 확인할 수 있습니다.

지급자가 제출된 청구를 거부하면 미지급 사유를 설명하는 청구 거부 사유 코드를 제공합니다. 이 코드는 청구 조정 사유 코드(CARC) 같은 업계 표준을 따르는 경우가 많으며, '서비스 보장 대상 아님', '중복 청구', '추가 정보 필요'와 같은 구체적인 문제를 나타냅니다.

이 속성은 매출 주기의 근본 원인을 분석하는 데 매우 유용합니다. 청구 거부 사유별 발생 빈도와 재무 영향을 분석하면 거부로 이어진 이전 단계의 문제를 찾을 수 있습니다. 예를 들어 '환자 정보 오류'로 인한 거부가 많다면 환자 등록 과정에 문제가 있을 수 있습니다. 이를 바탕으로 데이터에 근거한 개선을 추진해 청구 거부를 예방하고 최초 청구 지급률을 높일 수 있습니다.

청구 거부의 근본 원인을 분석해 향후 매출 손실을 막도록 초기 단계와 중간 단계의 프로세스를 개선하는 데 중요합니다.

지급자가 보내는 전자 지급 통지서(ERA) 또는 급여 설명서(EOB) 파일에서 가져옵니다.

청구 금액은 제공한 서비스에 대해 청구서나 송장으로 제출한 총액입니다. 청구 이벤트의 최초 금액으로, 이후 발생하는 지급과 조정 등 모든 금융 거래를 비교하는 기준이 됩니다.

process mining에서 청구 금액을 분석하면 프로세스 비효율성이 재무에 미치는 영향을 파악할 수 있습니다. 사례를 고액과 저액으로 나누어 특정 프로세스 문제가 고액 청구에 더 큰 영향을 미치는지 확인할 수 있습니다. 이 금액을 처리 시간이나 청구 거부율 같은 지표와 함께 분석하면 재무 영향이 큰 문제부터 개선할 수 있습니다.

사례의 최초 재무 금액을 기준으로 삼아 지연이나 청구 거부 같은 프로세스 비효율성의 재무 영향을 분석할 수 있습니다.

일반적으로 비용 입력, 청구 또는 청구 거래 테이블에서 확인할 수 있는 주요 재무 속성입니다.

계정 상태는 특정 시점에 청구 이벤트가 진행 과정의 어디에 있는지 보여 줍니다. 가장 최근 활동의 결과를 반영하며, 계정이 미결 상태로 지급을 기다리는지, 종료되었는지, 미수금 회수 단계로 넘어갔는지 등을 나타냅니다.

process mining은 활동 흐름을 재구성하고, 계정 상태 속성은 현재 상태에 따라 사례를 필터링하고 구분하는 데 유용합니다. 특히 단계별 계정 수와 금액을 보여 주는 운영 모니터링 대시보드에 적합합니다. 예를 들어 지급자의 응답을 기다리는 미수금 총액이나 최근 회수 대행사에 이관된 계정 수를 확인할 수 있습니다.

사례의 현재 상태를 보여 주므로 운영 대시보드에서 확인하거나 계정의 진행 단계별로 분석을 구분하는 데 유용합니다.

일반적으로 환자 회계 시스템의 기본 환자 계정 또는 청구 이벤트 레코드에 있는 상태 필드입니다.

미수 잔액은 청구 이벤트에서 아직 회수해야 하는 금액입니다. 일반적으로 청구 금액에서 지급 금액과 조정 금액을 뺀 값으로 계산합니다. 사례가 진행되는 동안 지급과 조정이 등록되면 이 금액도 달라집니다.

이 속성은 미수금 상태를 보여 주는 주요 지표입니다. process mining에서 프로세스의 여러 단계별 미수 잔액을 분석하면 미수금 경과 기간을 관리하고 회수 활동의 우선순위를 정하는 데 도움이 됩니다. 잔액이 많이 남는 사례 유형이나 프로세스 경로를 찾아 지급 또는 청구 거부 해결 과정의 문제를 확인할 수 있습니다.

미수금과 회수 효과를 측정하는 주요 지표로, 후속 조치의 우선순위를 정하고 미수금 경과 기간을 분석하는 데 도움이 됩니다.

청구 금액, 지급 금액, 조정 금액을 바탕으로 계산하는 경우가 많습니다. 미수금 시스템이나 환자 회계 시스템의 필드에 저장되기도 합니다.

청구 거부 사유와 마찬가지로 조정 사유는 청구 금액의 일부를 대손 처리하거나 조정한 이유를 설명합니다. 지급자와의 계약상 의무, 자선 진료 정책, 소액 잔액 대손 처리, 청구 오류 수정 등 조정의 배경을 확인할 수 있습니다.

조정 사유를 분석하면 매출의 정확성과 재무 성과를 파악할 수 있습니다. 예상된 계약상 조정과 내부 오류로 인한 예방 가능한 대손 처리를 구분하는 데 도움이 됩니다. 특정 조정 사유를 기준으로 프로세스 맵을 필터링하면 불필요한 매출 손실을 일으키는 프로세스의 취약점을 찾아 개선에 집중할 수 있습니다.

재무 조정의 배경을 파악해 계약상 의무와 프로세스 오류로 인한 예방 가능한 매출 손실을 구분할 수 있습니다.

청구 시스템이나 환자 회계 시스템의 재무 거래 테이블에서 확인할 수 있으며, 조정 또는 대손 처리 거래와 연결되는 경우가 많습니다.

지급 금액은 특정 청구 이벤트에 등록된 모든 지급액의 합계입니다. 주 지급자와 보조 지급자의 보험금뿐 아니라 환자가 낸 금액도 포함하며, 제공한 서비스에 대해 실제로 회수한 금액을 나타냅니다.

지급 금액을 분석하면 매출 주기의 재무 성과와 효율성을 측정할 수 있습니다. 지급 금액과 청구 금액을 비교하면 순매출과 회수율을 파악할 수 있습니다. process mining에서는 이 속성을 통해 프로세스 경로별 재무 결과를 측정하고, 전액을 제때 지급받은 청구와 그렇지 않은 청구의 특성을 찾을 수 있습니다.

사례별 실제 회수 금액을 측정하므로 회수 효과와 프로세스 전반의 재무 성과를 평가하는 데 중요합니다.

지급 등록 또는 현금 적용 거래 테이블에서 확인할 수 있습니다.

청구 ID는 보험사에 보낸 청구서의 고유 식별자입니다. 하나의 청구 이벤트에서 주 지급자, 보조 지급자, 제3 지급자에게 각각 청구하거나 청구서를 수정해 다시 제출하면 여러 개의 청구가 발생할 수 있습니다.

청구 ID를 추적하면 지급자와의 상호작용 과정을 자세히 파악할 수 있습니다. 청구서를 다시 제출하는 재작업 반복을 분석하고, 지급자에게 보낸 특정 청구서의 상태를 추적할 수 있습니다. 청구 ID별 분석은 청구 이벤트만 볼 때보다 청구 제출과 해결 과정을 더 세밀하게 보여 줍니다.

청구 제출과 재제출을 자세히 추적해 지급자와의 상호작용 및 재작업 반복을 세밀하게 분석할 수 있습니다.

청구 생성 시 청구 시스템에서 발급하며 청구 관리 테이블에 저장합니다.

환자 ID는 의료 시스템의 환자 통합 색인에서 개인 환자에게 부여하는 고유 키입니다. 이 식별자를 통해 시간에 따른 환자의 모든 임상 및 재무 기록을 연결할 수 있습니다.

단일 서비스의 사례를 나타내는 청구 이벤트 ID와 달리, 환자 ID를 사용하면 한 환자의 여러 진료 기록을 함께 분석할 수 있습니다. 이를 통해 반복되는 등록 오류나 서비스 이용 패턴을 찾을 수 있습니다. 환자의 전체 재무 여정을 분석해 환자 부담금과 충성도를 이해하는 데도 활용할 수 있습니다.

동일 환자의 여러 청구 이벤트를 함께 분석해 반복되는 문제를 찾고 환자의 전반적인 재무 여정을 파악할 수 있습니다.

거의 모든 임상 및 재무 시스템에서 사용하는 기본 식별자로, 환자 등록 시스템이나 EHR 시스템에서 가져옵니다.