Revenue Cycle Support Services (RCM)

Where the money actually goes missing

The first leak can begin before the visit. Coverage is recorded but not verified for the date and service; patient demographics differ from the payer record; coordination of benefits is unclear; a referral or authorisation requirement is discovered after care. The encounter proceeds, but the claim begins with avoidable uncertainty.

The second leak appears in ageing accounts receivable. A claim rejects at the clearinghouse, a payer requests information, a denial needs correction, or payment does not arrive as expected. The item receives a note but no dated next action. At forty-five days, the important fact is not the number itself—it is whether anyone owns the reason, deadline and follow-up.

Practices should quantify these points from their own systems: charges not entered, rejected claims unresolved, denials by reason, no-response claims, underpayments subject to client review, unapplied payments, patient balances waiting and receivables by age and payer. We do not insert a general first-pass denial rate or claim-rework cost where a current, comparable source and definition have not been established.

Revenue-cycle leakage is work delivered and cost incurred without timely, correctly applied payment. The operational response is a chain in which every handoff has an input, owner, clock, evidence and exception route.

The revenue cycle as a chain of ownership

1. Registration and eligibility: front-end staff capture demographics and coverage; support verifies available payer information under the client’s procedure and returns discrepancies before service where feasible.
2. Prior authorisation and referral: the responsible team checks whether the planned service requires an authorisation or referral, tracks the administrative submission and records the result. Clinical justification and medical-necessity decisions stay with qualified clinical staff and the payer.
3. Charge capture and entry: authorised source documentation and client-approved codes or charge information enter the billing workflow completely and on time. Missing or contradictory source returns to the responsible client role.
4. Claim validation and submission: defined demographic, payer, identifier and format checks run before release; clearinghouse or front-end rejections return to a correction queue with an owner.
5. Payment and adjustment posting: remittance, payment and approved adjustment data are posted against the correct account, with variances and unidentified amounts held for review.
6. Denial management: denials are classified by payer and reason, deadlines identified, administrative correction or appeal support routed under client rules, and causes fed back upstream.
7. AR follow-up: unresolved payer balances are prioritised, worked through approved channels and assigned a next action based on actual status rather than repeated generic notes.
8. Patient balances: statements, approved communication and payment administration follow the client’s financial, privacy and patient-service policies.

Ownership often disappears between teams. Front desk assumes billing will discover the coverage problem; billing assumes the clinic obtained authorisation; posting identifies a variance but no one routes it; AR records a payer response but no owner corrects the upstream process.

The revenue-cycle register makes the transfer explicit. It does not make one outsourced team the clinical, coding, finance and compliance authority. Each decision remains with the role qualified and authorised to make it.

The two links many practices leave unowned

Eligibility and benefits before the visit: the work is repetitive, payer-specific and time-sensitive. If scheduling, registration and billing each think another group owns it, discrepancies reach the claim. A defined verification queue, evidence standard and escalation time make the responsibility visible.

Structured denial work after adjudication: posting the denial is not resolving it. The denial needs classification, deadline, source review, appropriate correction or authorised appeal path, next follow-up and upstream feedback. Without this loop, the same preventable reason returns.

What our revenue cycle support team does day to day

Scope is configured by workflow, payer, location, speciality, system and authority. A daily operating sequence may include:

• work scheduled eligibility queues through approved payer portals or electronic responses and attach permitted evidence;
• flag demographic, member, payer, plan, referral or authorisation discrepancies for the named client owner;
• enter client-approved charge information from authorised source documentation without choosing codes;
• run agreed front-end checks and release claims under the client’s approval rules;
• correct administrative clearinghouse rejections using verified source data or return coding and clinical questions;
• post payments, contractual adjustments and other transactions only under client-approved mappings and authority;
• triage denials by reason, payer, deadline, age, balance and required owner;
• perform documented payer portal, correspondence or telephone follow-up on prioritised AR;
• record payer status, reference, required action, deadline and next follow-up rather than “called payer”;
• route patient-balance work under the practice’s communication and financial policies; and
• close the day by reconciling worked, resolved, returned and outstanding items.

A claim rejection and a denial are not treated as the same event. A rejection commonly indicates that a claim did not pass an initial submission or clearinghouse edit and needs correction before payer adjudication. A denial follows payer adjudication and requires action appropriate to the reason and payer process. System labels can differ, so the client’s definitions govern reporting.

Practices needing deeper claim preparation and posting scope can review medical billing support services. A single named person working under the practice manager is a different model, covered by a remote medical billing assistant.

How we prioritise AR instead of working it top to bottom

An alphabetical list treats a small recent balance with no action deadline like a large older balance approaching a payer limit. A pure oldest-first list can spend the day on low-probability accounts while newer, recoverable items age. Revenue-cycle support uses an approved priority method.

The worklist can consider:

• ageing bucket and days since the last meaningful event;
• balance and total exposure across related claims;
• payer, plan and documented response pattern;
• denial or status reason and required action;
• filing, reconsideration or appeal deadline supplied by the client’s authoritative source;
• availability of documentation and the client role needed;
• prior follow-up and the payer’s stated processing window;
• patient or provider impact; and
• likelihood that administrative action can move the account.

The practice approves weighting and exclusions. High balance does not authorise an unsupported appeal; age does not justify ignoring a current payer response window. Accounts involving coding, clinical documentation, contract interpretation, legal issue or patient dispute return to the responsible client specialist.

Each worked account receives status, evidence, action, owner, deadline and next follow-up. The AR lead reviews stale notes, repeated “no response,” missed deadlines and accounts moving between queues without resolution.

Detailed payer follow-up methodology belongs under AR follow up support services. This page keeps AR in its whole-cycle context.

Denials, categorised and fed back upstream

Denial management is a recovery queue and a process-improvement dataset. Each denial is grouped using the payer’s reason, standard remittance information where applicable, client category, responsible process step and final disposition. Raw reason codes are preserved; the internal grouping makes patterns manageable.

Consider an administrative example. A payer indicates that required prior authorisation was absent. The first response is claim-specific: confirm the actual requirement and record, route clinical or payer-contract questions, identify the permitted correction or appeal path, assemble client-approved documentation and protect the stated deadline. OveliTHub does not invent an authorisation or assert medical necessity.

The second response is upstream. Review which location, service, payer and scheduling condition produced the pattern. Perhaps the scheduling checklist did not ask for a plan-specific rule, the authorisation reference was stored in a field the claim workflow did not read, or an approved service changed. The client owner decides the corrective control: verification step, system field, stop condition, staff guidance or interface change.

Future denials under that category are monitored after the change. A lower count is interpreted only against comparable claim volume and enough time; the team does not declare improvement from a small or incomplete sample.

Eligibility details and evidence standards belong on the dedicated insurance verification support page. Submission and tracking of authorisation requests belong under prior authorization support.

Reporting that tells you whether the cycle is improving

Every metric needs a formula, source, period and exclusions. OveliTHub reports trend and drivers rather than attaching a universal good or bad threshold.

• Days in AR: a client-approved measure of receivables relative to average daily charge or revenue activity under a stated formula; movement can reflect collections, charge volume, posting timing and write-offs, so drivers matter.
• AR over 90 days: receivables in the selected ageing category divided by total eligible AR; a rise may indicate follow-up delay, difficult payer mix, unresolved denials or ageing changes.
• Clean claim rate: claims accepted through the defined first-pass point without preventable correction divided by eligible submitted claims; the exact acceptance point and exclusions must be stated.
• Denial rate by reason: denied claims, lines or value under the agreed definition divided by adjudicated eligible activity, grouped by reason; this identifies where upstream correction deserves attention.
• Net collection rate: collected amount divided by the collectible amount after approved contractual adjustments under the client’s formula; write-offs, refunds, period alignment and credit balances need consistent treatment.

The weekly view controls work: queue volume, receipts, submissions, rejections, denials, follow-ups, resolutions, age movement, deadlines and decisions. The monthly view examines metric trend, payer and location concentration, root causes, forecast cash movement where the client supplies the method, and improvement actions.

Counts reconcile to the practice-management or billing system at an extraction time. A drop in denial count can result from fewer adjudicated claims; a lower old-AR percentage can result from write-offs. Reporting keeps numerator, denominator and operational event visible.

Working inside your PM and EHR, under your policies

The support team works in the client’s existing practice-management, billing, EHR, clearinghouse, payer and approved communication environments. Exact capability depends on system, edition, configuration, integration and permission. An unusual EHR is evaluated through workflow discovery and a controlled pilot rather than ruled out by brand name.

Staff receive named individual accounts with least-privilege roles. View, edit, claim release, posting, adjustment, export, reporting, user administration and configuration are separated. Multi-factor authentication, device conditions, session practice, access logging and remote-access controls follow the client’s security policy and system capability.

OveliTHub does not move protected health information into its own unapproved productivity tools. Work queues, documents, screenshots, notes and communication stay in client-approved locations. If a necessary workflow requires another system or transfer, the client privacy and security owners must assess and approve it before use.

The access checklist covers request, owner approval, identity, role, test, review, change and revocation. Offboarding closes accounts, transfers open work, addresses files and devices, and records completion.

Compliance, HIPAA and the paperwork that comes first

When a service provider creates, receives, maintains or transmits protected health information on behalf of a HIPAA covered entity in a way that meets the definition of a business associate, HIPAA requires appropriate written assurances. The US Department of Health and Human Services explains business-associate functions and the required contract provisions. Read HHS guidance on business associates.

Before the first shift, the parties determine their roles and execute the applicable business associate agreement and service terms. The documentation should address permitted use and disclosure, safeguards, incident and breach reporting, subcontractors where relevant, access and amendment support as applicable, return or destruction, termination and other required provisions. Qualified counsel should approve the arrangement.

The Security Rule requires covered entities and business associates to use appropriate administrative, physical and technical safeguards for electronic protected health information. HHS describes risk analysis, workforce access, security awareness, incident procedures, contingency planning and access controls among the standards. Read the HHS Security Rule summary.

Operational readiness includes role-based training, confidentiality, individual access, authentication, approved devices and locations, minimum-necessary handling, logging where supported, incident escalation, sanctions or corrective routes, periodic access review and offboarding. HIPAA is not reduced to signing a BAA.

This content is not legal, privacy, security, coding or compliance advice. The client remains responsible for determining applicable federal and state requirements, payer terms, professional rules and its risk controls.

What we do not do

OveliTHub does not:

• select, change or validate medical codes through independent coding judgement;
• make clinical, medical-necessity or patient-care decisions;
• create clinical documentation or attest on behalf of a provider;
• interpret payer contracts, law, regulation or professional obligations;
• determine credit, charity-care, refund, adjustment or write-off policy;
• submit information known to be incomplete or unsupported to clear a queue;
• guarantee authorisation, payment, appeal, recovery, collection rate or turnaround controlled by another party; or
• move PHI outside approved systems for convenience.

When a workflow reaches one of these boundaries, support assembles the relevant account, source, payer response, deadline and question for the authorised client role.

Onboarding a revenue cycle support team

1. Baseline the cycle. Reconcile AR by age, payer and location; review rejections, denial reasons, eligibility and authorisation queues, posting exceptions, patient balances, service definitions and current ownership. Use minimum necessary data during discovery.
2. Approve scope and governance. Identify systems, roles, BAA and service terms, privacy and security requirements, work locations, access, training, authority, escalation, reporting and excluded decisions.
3. Document the working method. Capture client policies, payer sources, queue fields, evidence, deadlines, templates, quality checks and responsible client specialists.
4. Pilot a bounded queue. Begin with one payer, location, denial group, ageing bucket or administrative workflow. Review early work fully, reconcile outputs and classify errors before expanding.
5. Extend by demonstrated control. Add payers, queues or stages only after access, quality, reporting and client response work at the pilot scale. Keep rare and high-risk cases under the approved review level.

A backlog-clearance date cannot be promised from total balance alone. Recoverability, account age, documentation, payer deadlines, response windows, staffing, system access and client decisions all affect pace. Discovery produces a prioritised inventory and throughput baseline before any projection.

If a prior outsourcing arrangement made AR worse, the review should inspect work notes, ownership, reason categories, deadlines, posting, handoffs, QA and reconciliation. The remedy may be a narrower scope or upstream process correction—not simply a larger team.

Healthcare experience without invented outcomes

OveliTHub has delivered more than 130 projects across its portfolio, identifies healthcare among its industry experience and lists Allegheny Health Network as a client relationship. We do not attach an unverified collection result, denial reduction or revenue figure to that relationship.

Those proof points support a conversation about healthcare operations.

Broader healthcare operations are available through healthcare BPO services. Readers who need an educational cycle map can review how the healthcare revenue cycle works.