Your Revenue Cycle Management Data Template

The Activity Name describes a step in the revenue cycle process, such as 'Claim Submitted To Payer' or 'Payment Received'. This attribute is fundamental to process mining, as it defines the nodes in the process map.

By analyzing the sequence and frequency of activities, organizations can visualize the actual process flow, identify deviations from the standard procedure, and pinpoint common rework loops. This analysis is key to understanding process inefficiencies and compliance issues.

This attribute defines the individual steps of the process, forming the basis of the process map and enabling all flow-based analysis.

This is typically derived from event logs, status change records, or specific transaction codes within Optum360's operational tables.

The Billing Event serves as the primary case identifier, linking all activities related to a single service provided or product delivered that generates a charge. This allows for comprehensive tracking of the revenue generation and collection lifecycle for each distinct billable item or service.

In process mining, analyzing the process by Billing Event allows organizations to see the full end-to-end journey from service delivery to final payment or account closure. This view is crucial for identifying bottlenecks, measuring cycle times, and understanding variations in how different claims or invoices are handled.

This is the essential Case ID that connects all related revenue cycle activities, enabling a complete, end-to-end process view for analysis.

This is the primary key linking records in Optum360's core billing and claims tables. Consult Optum360 documentation for specific table and field names.

Event Time is the timestamp associated with each activity, marking the precise date and time of its occurrence. This temporal data is essential for constructing the chronological sequence of events for each case.

In analysis, Event Time is used to calculate cycle times between activities, measure case duration, and identify bottlenecks where significant time is spent waiting. It is the backbone of any time-based process analysis and performance measurement.

This timestamp is critical for sequencing events correctly and calculating all duration-based metrics, such as cycle times and bottlenecks.

This information is typically stored alongside each transaction or status change record in Optum360's database tables.

The Adjusted Amount represents the portion of the billed amount that is not expected to be collected due to contractual agreements with payers, billing corrections, or other write-offs. This is a direct reduction of revenue.

This attribute is critical for the 'Revenue Adjustment Impact' dashboard and the 'Revenue Adjustment Rate' KPI. Analyzing adjustments helps identify the financial impact of payer contracts and find opportunities to minimize revenue leakage through improved billing accuracy or contract negotiation.

Directly measures revenue leakage and is critical for calculating financial performance KPIs and understanding profitability.

This information is found in adjustment transaction records within Optum360's financial system.

Billed Amount represents the gross charge for the services rendered, before any payments, adjustments, or write-offs. It is the initial value of the account receivable for the billing event.

This attribute is fundamental for financial analysis within process mining. It is used to calculate key KPIs like the Revenue Adjustment Rate, and it allows for segmenting cases by value to see if high-value claims are processed differently or experience more delays than low-value claims.

Provides the financial context for each case, enabling value-based analysis and the calculation of critical financial KPIs.

This is a standard field on every claim or patient account within Optum360's financial tables.

The Billing Department attribute identifies the specific team or functional area within the revenue cycle operations responsible for an activity. For example, different teams might handle coding, claims submission, and denial management.

This attribute is essential for performance benchmarking, as requested by the 'Billing Department Performance Benchmarks' dashboard. It allows leadership to compare the efficiency, speed, and accuracy of different teams, identify best practices, and allocate resources effectively to address performance gaps.

Enables performance comparison across different billing teams, helping to identify high-performing groups and areas needing improvement.

This may be derived from the user performing the task or a field on the account that indicates ownership. Consult Optum360 documentation.

When a payer denies a claim, they provide a Denial Reason Code that explains the issue, such as 'Service Not Covered' or 'Duplicate Claim'. These codes are crucial for understanding the root causes of revenue delays and rework.

Analyzing these codes allows the denial management team to prioritize their work, identify trends, and implement corrective actions. For example, a high frequency of denials for 'Missing Information' may point to a problem in the claims creation process. This analysis is central to reducing the denial rate and accelerating cash flow.

Provides the root cause for claim denials, enabling targeted interventions to prevent future denials and reduce costly rework.

This code is included in the Electronic Remittance Advice (ERA) files received from payers and is stored in the claim management module of Optum360.

The Patient ID is a unique identifier assigned to each patient within the healthcare system. It links multiple billing events to a single patient, allowing for patient-centric analysis.

By using the Patient ID, analysts can investigate patterns related to specific patients, such as frequent readmissions or a history of claim denials. It also enables segmentation of the process based on patient demographics or history, which can reveal important insights for improving patient financial experience.

Allows for patient-centric analysis, helping to understand the end-to-end financial journey and identify patterns for specific patient populations.

This identifier is a core field in patient master data and transaction tables within Optum360. Consult Optum360 documentation for details.

The Payer ID identifies the specific insurance company, government program like Medicare or Medicaid, or other entity responsible for paying the claim. Each payer often has its own set of rules, submission requirements, and payment behaviors.

Analyzing the process by Payer ID is critical for RCM. It helps identify which payers have the longest payment cycles, highest denial rates, or most complex appeal processes. This insight allows billing departments to tailor their strategies for different payers to improve collection speed and reduce administrative burden.

Segmenting the process by payer is essential for identifying which payers cause delays or denials, enabling targeted improvements in payer management.

This information is stored on each claim record within Optum360. Consult Optum360 documentation for payer-related table and field names.

Account Status provides a snapshot of where a billing event stands in the overall process, for example, 'Pending Payer', 'Paid in Full', or 'In Collections'. This attribute gives context to the activities being performed.

This is useful for filtering and segmenting cases to focus on specific parts of the process. For instance, analyzing all accounts currently 'In Collections' can help understand the drivers and volume for that specific, costly part of the process, supporting the 'Collection Activity Volume & Drivers' dashboard.

Provides high-level context of a case's current state, allowing for filtering and analysis of specific case populations like those in collections.

This is typically a summary field on the main patient account or claim record in Optum360.

Case Duration measures the total time elapsed from the very first event to the very last event for a single Billing Event. This is a key high-level KPI for assessing overall process efficiency.

This metric directly supports the 'RCM End-to-End Cycle Time Overview' dashboard and the 'Average RCM Cycle Time' KPI. Tracking this over time allows leadership to see the impact of improvement initiatives on the entire revenue cycle.

Represents the end-to-end cycle time of the process, a critical KPI for measuring overall process speed and efficiency.

This is calculated by subtracting the timestamp of the first event from the timestamp of the last event for each unique 'BillingEvent' case ID.

The End Time marks the completion of an activity. While Start Time indicates when an event occurred, End Time is necessary for calculating the duration of activities that have a distinct processing time, such as 'Denial Rework Started' and its completion.

In process analysis, comparing Start Time and End Time for activities allows for the calculation of processing time. This helps distinguish between active work time (processing time) and idle time (waiting time between activities), providing a more detailed view of process efficiency.

Enables the calculation of precise activity processing times, helping to differentiate active work time from idle waiting time in the process.

For some activities, this may be a separate timestamp field in the source system. For others, it may need to be inferred from the start time of the subsequent activity.

Is Rework is a boolean flag that identifies activities considered to be non-value-added rework, such as 'Denial Rework Started' or 'Appeal Submitted'. These activities typically occur when the process deviates from its ideal 'happy path'.

This attribute helps to quantify the amount of rework in the process, which is a direct indicator of inefficiency and cost. It is used to calculate the 'Billing Error Rework Rate' KPI and supports the 'Bottleneck Identification & Rework Loops' dashboard by making it easy to filter for and visualize these inefficient loops.

Helps quantify process inefficiency by flagging activities that represent rework, making it easier to measure and target waste.

This is typically derived using business logic within the process mining tool. For example, any activity following a 'Denial Received' event could be flagged as rework.

This attribute records the date and time when the data was last extracted from the source system and loaded into the process mining tool. It provides context about the freshness of the data being analyzed.

This is important for analysts and business users to understand if they are viewing the most current information. It helps manage expectations about data latency and is a key piece of metadata for any analysis project.

Provides crucial context on data freshness, ensuring users understand how up-to-date the analysis is.

This timestamp is typically generated and stored by the data extraction, transformation, and loading (ETL) process.

The Paid Amount is the cumulative sum of all payments posted to the account for a specific billing event. This represents the actual cash collected and is a primary measure of the success of the revenue cycle.

In process analysis, tracking the paid amount is essential for understanding cash flow and overall financial performance. It can be used to analyze payment velocity and to compare billed amounts to collected amounts, highlighting issues with underpayments or uncollectible debt.

Represents the actual cash collected, which is a key outcome metric for the RCM process and essential for cash flow analysis.

This value is typically stored in payment transaction tables or summarized at the account level in Optum360.

Processing Time measures the duration of an individual activity, representing the 'touch time' or active work performed. This is typically calculated as the difference between an activity's End Time and Start Time.

This calculated metric is crucial for distinguishing between time spent actively working on a task versus time spent waiting for the next step. In bottleneck analysis, understanding processing times helps determine if a delay is due to a long task or a long queue, leading to more effective process improvements.

Measures the active 'touch time' for activities, helping to distinguish value-added work from wasteful waiting time in bottleneck analysis.

This is calculated by subtracting the 'EventTime' (StartTime) from the 'EndTime' for a given activity record.

The Service Code is a standardized medical code that precisely identifies the procedure or service provided to the patient. These codes are required for billing and are a primary determinant of reimbursement.

Analyzing the process by Service Code can reveal that certain procedures are more prone to denials, require more documentation, or have longer payment cycles. This enables a more granular understanding of process challenges and can inform coding and billing policies for specific types of services.

Allows for analysis based on the type of medical service, which can reveal patterns in denials or payment delays specific to certain procedures.

This code is a fundamental part of the charge entry and claim detail records in Optum360.

This attribute identifies the specific provider, such as a physician, therapist, or hospital department, responsible for delivering the service. Different providers may have different billing patterns or documentation habits that affect the revenue cycle.

Analyzing by Service Provider can help pinpoint issues related to charge capture, coding accuracy, or documentation quality that originate at the point of care. It can highlight opportunities for provider education or process improvement to ensure clean claims are generated from the start.

Helps trace billing issues back to the source, enabling targeted feedback and training for clinical staff to improve charge capture and documentation.

This information is a key part of the charge or claim record in Optum360, often linked to provider master data.

This attribute identifies the source system from which the data for a particular event was extracted. In a complex IT landscape, RCM data might come from the core Optum360 platform, an interfaced Electronic Health Record (EHR) system, a clearinghouse, or a patient portal.

Understanding the source system is useful for data validation, troubleshooting integration issues, and analyzing process variations that may be caused by different system behaviors or data entry practices.

Identifies the origin of the data, which is crucial for data governance, quality assessment, and understanding process variations across different systems.

This may be a static value set during data extraction or a field within the source tables that indicates the data's origin.

The User attribute identifies the specific person, team, or automated bot responsible for executing a given activity. This allows for analysis of performance at the individual or group level.

Understanding which user or team performed an action is valuable for assessing productivity, quality, and adherence to standard procedures. It can help identify training needs or recognize high-performing individuals and teams. It also helps in distinguishing between tasks performed manually versus those handled by automation.

Assigns accountability for process steps and enables performance analysis by individual or team, which is key for resource management and training.

User IDs are typically captured in the audit logs or transaction history for records in Optum360.