Your Revenue Cycle Management Data Template

This attribute records the name of each activity performed within the lifecycle of a billing event. Examples include 'Charges Captured', 'Claim Submitted To Payer', and 'Payment Posted'. These activities form the nodes of the discovered process map.

Analyzing the sequence and frequency of activities is the core of process mining. This attribute helps identify the most common process paths, discover deviations from the standard procedure, and understand the operational flow of the revenue cycle.

It defines the steps in the process, allowing for the visualization of the process map and analysis of workflow patterns.

Typically derived from event logs, status change records, or specific transaction tables associated with different stages of the revenue cycle in Oracle Health.

The Billing Event acts as the primary case identifier, linking all activities from charge capture to account closure for a distinct billable item. Each Billing Event represents a unique instance of the revenue cycle process, allowing for comprehensive tracking of its journey through various stages like claim submission, payment posting, and potential denials or adjustments.

In process mining analysis, this attribute is fundamental for reconstructing the end-to-end process flow. It enables the visualization of process variants, calculation of cycle times between activities, and identification of bottlenecks or deviations associated with specific billable events.

This is the essential key for tracking the entire lifecycle of a billable service, enabling all process flow analysis and performance measurement.

This identifier should be a unique key present in the core billing or charge transaction tables within Oracle Health Revenue Cycle. Consult system documentation to identify the primary key for charge events.

This attribute provides the timestamp for each activity, marking the exact moment it occurred. It is essential for understanding the timing and sequence of events within the revenue cycle for a specific billing event.

In analysis, the Event Timestamp is used to order activities chronologically, calculate durations and cycle times between different steps, and perform bottleneck analysis. It is the foundation for all time-based process mining metrics, such as identifying delays between 'Claim Submitted' and 'Remittance Received'.

This timestamp is critical for ordering events, calculating all performance metrics like cycle times and durations, and identifying process bottlenecks.

Each transaction or event log table in Oracle Health Revenue Cycle should have a timestamp column indicating when the record was created or the event occurred.

This attribute captures the amount of any financial adjustment, such as contractual allowances, write-offs, or corrections, applied to the billing event. Adjustments directly reduce the expected revenue from a charge.

The 'Account Adjustment Impact' dashboard relies heavily on this attribute. Analyzing adjustment amounts and their associated reasons helps identify sources of revenue leakage, issues with contract management, or problems in the initial charge capture process. It is a key metric for financial health.

Quantifies revenue leakage due to write-offs or corrections, helping to identify and address root causes of financial erosion.

Found in financial transaction tables that log adjustments or write-offs against a patient account.

This attribute specifies the department, such as 'Charge Capture', 'Coding', or 'Collections', that performed the activity. It provides an organizational context to the process flow.

Analyzing the process from a departmental view is essential for understanding handoffs between teams and identifying cross-functional inefficiencies. It supports the 'Billing Department Workload' dashboard by allowing aggregation of activities and performance metrics at the department level.

Assigns activities to organizational units, which is key for analyzing inter-departmental handoffs, workload, and team performance.

This information might be stored directly with the user profile data in Oracle Health or derived based on the user or activity type.

When a payer denies a claim, they provide a reason code explaining the denial, such as 'Non-covered service' or 'Duplicate claim'. This attribute captures that code and its associated description.

Analyzing denial reasons is fundamental to improving the revenue cycle. It allows the organization to identify common patterns, such as issues with coding or patient eligibility, and implement corrective actions to prevent future denials. This directly impacts the clean claim rate and reduces the cost of rework.

Provides the root cause for claim denials, enabling targeted improvements to increase the clean claim rate and accelerate revenue collection.

This information is received in the electronic remittance advice (ANSI 835 file) from the payer and should be stored in the claim or remittance tables in Oracle Health.

This attribute shows the current outstanding amount owed for a billing event after all payments and adjustments have been applied. It represents the active accounts receivable for that specific charge.

This is a critical attribute for the 'Outstanding Balance Aging' dashboard. Analyzing this value over time helps in monitoring the velocity of cash flow, assessing the effectiveness of collection efforts, and calculating key financial KPIs like Days Sales Outstanding (DSO).

Tracks the current accounts receivable for each case, which is essential for managing cash flow and analyzing the effectiveness of collections.

This value is typically calculated from the sum of all financial transactions (charges, payments, adjustments) for a given billing event. It may exist as a field in an account summary table.

This attribute categorizes the type of patient visit or encounter that generated the charge. Common classifications include Inpatient, Outpatient, Emergency, and Recurring Patient. The patient class often dictates the entire billing and claims submission process.

Different patient classes follow distinct process paths and have different compliance requirements. Analyzing the process based on this attribute helps to understand these variations, tailor improvement initiatives, and ensure that the correct procedures are being followed for each class.

Separates distinct process flows (e.g., Inpatient vs. Outpatient) that have different complexities, timelines, and billing requirements.

This is a standard field associated with a patient encounter or admission record in Oracle Health.

This attribute identifies the entity, such as an insurance company or government program like Medicare, that is billed for the service. Payer information is fundamental to revenue cycle analysis.

Analyzing the process by payer can reveal significant variations in payment times, denial rates, and appeal success rates. It helps in identifying problematic payers that cause delays or revenue loss and is essential for managing payer contracts and relationships effectively.

Allows for segmentation of the process by payer, revealing different behaviors, denial rates, and payment speeds which is crucial for financial performance.

This information is stored in the patient's billing or insurance records within Oracle Health Revenue Cycle.

This attribute identifies the employee or automated system user responsible for executing a specific activity in the process. It is crucial for understanding workload distribution, resource performance, and identifying training needs.

In analysis, this attribute allows for filtering the process map by user or team, comparing performance across different resources, and analyzing workload for the 'Billing Department Workload' dashboard. It can help identify top performers or individuals who may require additional support or training.

Links process activities to specific users or teams, enabling workload analysis, performance comparison, and identification of training opportunities.

User ID fields (e.g., 'CREATED_BY', 'USER_ID') are typically present in transaction tables across Oracle Health modules.

This attribute represents the initial, undiscounted amount charged for a service before any adjustments, contractual allowances, or payments are applied. It is the starting financial value for the billing event.

Tracking the charge amount is crucial for financial analysis, such as calculating the total value of services rendered and understanding the financial impact of subsequent adjustments or write-offs. It serves as a baseline for measuring revenue realization.

Establishes the initial financial value of the case, which is fundamental for all subsequent financial analysis and impact assessment.

Located in the charge detail or charge transaction tables in Oracle Health.

This attribute is the unique ID assigned to a claim that is generated and sent to a payer for reimbursement. A single billing event may result in one or more claims over its lifecycle, for example if a correction is needed.

Using the Claim ID allows for tracing a specific submission to a payer and linking it directly to the response, such as a payment or denial. It provides a more granular level of tracking within the broader revenue cycle process.

Provides a specific identifier to track the journey of a claim with a payer, which is more granular than the overall billing event.

This ID is generated by Oracle Health when a claim is created and is stored in the primary claims table.

This attribute captures the reason why a patient or other responsible party has disputed a bill. Reasons can include incorrect charges, services not rendered, or issues with insurance processing.

This information is essential for the 'Invoice Dispute Resolution Metrics' dashboard. Understanding the most common reasons for disputes helps to identify systemic problems in the charge capture, coding, or billing processes. Addressing these root causes can significantly reduce the dispute rate and the administrative overhead required to resolve them.

Explains why invoices are being disputed, providing direct insight into issues with billing accuracy or clarity that need to be fixed.

This is likely stored in a case management or customer service module within Oracle Health, linked to the patient's account.

While StartTime marks the beginning of an activity, EventEndTime marks its conclusion. Not all activities have a distinct end time, as many are instantaneous events. However, for activities that have a duration, such as 'Denial Appealed' which might take time to process, this field is very useful.

This attribute allows for a more precise calculation of the processing time for individual activities. It helps differentiate between waiting time (time between activities) and processing time (time spent on an activity).

Enables the direct calculation of how long an activity takes to complete, separating processing time from waiting time.

Some transaction tables in Oracle Health Revenue Cycle may contain both a start and end timestamp for specific, long-running tasks.

This boolean attribute distinguishes between activities executed by software automation, such as bots or system batch jobs, and those performed manually by a user. For example, 'Claim Generated' might be an automated step, while 'Denial Appealed' is likely manual.

Analyzing this attribute helps in understanding the level of automation in the process and its impact on efficiency and error rates. It can be used to compare the performance of automated versus manual paths and identify opportunities for further automation.

Differentiates between human and system-driven activities, which is critical for analyzing automation effectiveness and identifying new automation opportunities.

This is typically derived based on the UserPerformingAction attribute. For example, activities performed by user IDs like 'SYSTEM' or 'RPA_BOT' are flagged as automated.

This calculated attribute flags activities that indicate a deviation from the ideal 'happy path' and constitute rework. Examples include 'Corrected Claim Submitted' or 'Denial Appealed', which would not occur if the process went perfectly the first time.

Identifying and quantifying rework is a key goal of process mining. This flag allows for easy filtering and analysis of all rework loops, helping to measure the frequency, cost, and causes of process inefficiencies. It is essential for understanding the true cost of quality in the revenue cycle.

Helps quantify the frequency and impact of rework loops, highlighting process inefficiencies and the cost of poor quality.

This is a derived attribute. It is calculated during data transformation by applying business logic that flags specific activity names as rework.

This attribute shows when the dataset was last updated. It provides context on the freshness of the data being analyzed, which is important for understanding the timeliness of the insights derived from the process mining analysis.

Users can check this attribute to confirm they are viewing the most current process information. It helps manage expectations about the data's recency and is a key component of data governance and quality assurance.

Indicates the freshness of the data, ensuring that analysis and decisions are based on up-to-date information.

This is a metadata field typically generated and populated during the ETL process that loads data into the process mining platform.

This attribute is the unique identifier for the patient who received the service, often known as the Medical Record Number (MRN). It links the financial transaction to a specific individual.

While not the case ID for the process, the Patient ID is useful for aggregating all billing events for a single patient to understand their entire financial journey. It also allows for segmentation based on patient demographics or history if joined with patient master data.

Links financial events to a specific patient, allowing for patient-centric analysis and aggregation of all their billing activities.

This identifier is a core element of the patient master record and will be present in all related transaction tables like charges, claims, and payments.

This attribute measures the active processing time for an event, calculated as the difference between its start and end timestamps. It helps distinguish between time spent actively working on a task versus time spent waiting for the next step.

This is a crucial metric for performance analysis, as it isolates the efficiency of the resource performing the task from systemic delays. It helps answer questions about how long it takes to code a claim or post a payment, independent of how long the item sat in a work queue.

Measures the actual work duration for an activity, separating it from idle or wait time to provide a clearer view of resource efficiency.

This is a calculated metric, derived by subtracting the EventTimestamp from the EventEndTime. It can only be calculated when both fields are available.

This attribute identifies the source application or module where the data originated. For this process, it will typically be 'Oracle Health Revenue Cycle', but it could also specify different modules within the system if data is integrated from multiple places.

This information is valuable for data governance and troubleshooting. It helps confirm data lineage and is important in environments where multiple systems contribute to a single end-to-end process.

Provides context on data origin, which is crucial for data validation, governance, and understanding process variations that might be system-dependent.

This is often a static value added during the data extraction, transformation, and loading (ETL) process to label the origin of the dataset.