When a medical record request goes out, someone has to track when it was sent, whether the records came back, what reference number was assigned, and what the follow-up process looks like if nothing arrives. When a prior authorization is pending with a payer, someone has to contact the payer, document what was said, and know when to escalate. When a billing specialist closes accounts in a day, a manager needs to know how many were worked and what moved.
Neither the EHR nor the billing platform was primarily designed to manage that operational work.
Healthcare organizations have invested significantly in the systems that manage the clinical record and the financial record. The EHR tracks the patient encounter: clinical documentation, care coordination, the record that follows a patient through their care. The billing platform tracks the revenue cycle: claims submission, payment, denial management. Both are purpose-built, heavily embedded, and not going anywhere. The operational layer that exists between them is not their primary job. The question is whether it is managed as a system or reconstructed daily from spreadsheets, email threads, and individual memory.
What Your EHR and Billing Platform Were Built to Do
EHR systems are primarily built for clinical documentation, patient records, care coordination, and regulatory reporting around the clinical encounter. They are designed for clinicians who need to document and access patient health information in a standardized, auditable way. Managing the operational workflow of a billing department, an authorization team, or an administrative coordinator tracking record requests is not what EHR systems were primarily designed to do.
Billing platforms are primarily built for claims submission, payment tracking, denial management, and revenue cycle reporting. They track the financial outcomes of clinical encounters. Tracking the work activity of the billing team itself, how many follow-up calls were made on which accounts, which authorization requests have been pending without response, what the status of each record request is, is not the primary function these systems were built to perform.
The boundary between what these systems manage and what they don't shows up in specific operational situations. The argument here is about design purpose, not technical impossibility. These are the workflows that fall outside the primary job of each system.
Record request lifecycle. The billing platform tracks the claim. Tracking when the medical record supporting that claim was requested, whether the records arrived, what reference number was assigned, and how many follow-up contacts have been made are not the primary jobs of the billing system. The billing team managing outbound record requests needs visibility into every active request: which ones are pending, which have gone weeks without a response, and who is responsible for the next follow-up contact. That operational picture is not what the billing platform was built to surface. It records claim outcomes rather than the retrieval workflow that supports them.
Authorization workflow. Prior authorization exists at the intersection of clinical necessity and payer approval. The surrounding workflow (when the request was submitted, which payer was contacted and when, whether additional documentation was requested, when a decision is expected) is not the billing platform's primary job. Under CMS regulations effective January 2026, Medicare Advantage and Medicaid managed care plans must issue standard prior authorization decisions within seven calendar days and expedited decisions within 72 hours. [CMS-0057-F, cms.gov] That regulatory clock makes authorization tracking a time-sensitive operational requirement. The billing team managing that workflow needs to know which authorizations are approaching or past the expected decision window and who is responsible for follow-up. That kind of operational visibility sits outside the primary purpose of the billing platform.
Staff activity and accountability. Billing platforms record claim outcomes. Tracking how many accounts a billing specialist worked, how many calls were made, and what moved in their queue that day is a management visibility function that sits alongside claim-outcome tracking but is not the primary job billing platforms were built to perform.
Referral coordination. An EHR may record that an incoming referral was received. The work of assigning it to a coordinator, scheduling the appointment, confirming the patient's attendance, and notifying the referring provider of the outcome, what healthcare quality organizations call closing the referral loop, happens in a coordination process that runs alongside the EHR. The National Committee for Quality Assurance includes referral loop closure (CMS 50) as a specific care coordination measure in its Patient-Centered Medical Home criteria. [NCQA PCMH standards, ncqa.org] That status means referral coordination is a recognized operational standard, not just an internal efficiency goal.
Across these workflows, the pattern is consistent: the clinical and financial systems retain their primary roles while operational work still needs ownership, follow-up, aging logic, and history.
Where the Operational Gap Actually Costs You Control
Knowing the gap exists is one thing. Understanding where it creates real organizational problems is another. The consequences of unmanaged operational work accumulate in five specific ways.
Visibility. The organization cannot see the state of its operational work without asking someone to compile it. How many record requests are currently outstanding? Which authorizations have been pending longer than the decision window? What is the current state of the referral queue? If those questions require opening multiple spreadsheets or asking multiple staff members, the organization does not have operational visibility. It has the capacity to eventually reconstruct it. The distinction matters: reconstruction gives management a snapshot, not continuous operational visibility.
Ownership. When operational work is distributed across email threads and individual spreadsheets, who owns the next action on any specific item can be genuinely unclear. A record request appears in a shared spreadsheet. Who is responsible for following up on it? When does that follow-up happen? If the person who entered it is out or has moved to a different task, does anyone else know the item is sitting without action? Distributed tracking produces records; it does not automatically produce accountability.
Aging. Some operational items become more consequential the longer they wait. A prior authorization request pending past the payer's decision window needs follow-up before it becomes a delay in care or a billing problem. A medical record request that has gone without a response needs follow-up before the missing documentation creates a downstream problem for the billing cycle. A referral where the referring provider has heard nothing is a loop that has not been closed. When surfacing aging items depends on someone remembering to sort and review the data, early intervention depends on that manual step happening consistently, every time, not just when someone notices.
Continuity. The operational process depends on individual knowledge. When critical follow-up knowledge lives primarily in one person's head, turnover becomes an operational risk. The organization may retain the spreadsheet while losing the context required to use it: payer-specific requirements, productive contacts, prior conversations, and the reasoning behind the next action. A process that depends on a spreadsheet plus individual memory is not yet an organizational system.
Management control. When the billing platform records claim results but not the effort and follow-up that produced them, managers cannot see the relationship between what the team does and what the team achieves. A billing manager who cannot see how many accounts each specialist worked today, which authorizations received follow-up, or which record requests are aging without action is managing by outcomes alone, discovering gaps only when they show up in the numbers, not before.
These five failure modes are not failures of individual effort. They are structural risks created when operational work depends on tools that store information without providing the coordination the process requires.
Why Tracking Fails When It Becomes Coordination
Knowing what to track is only the first problem. A spreadsheet can contain the right fields and still leave the team responsible for coordinating what happens next. The problem is not the data. It is what the data needs to do.
A spreadsheet can hold information. The problem begins when the information needs to assign work, trigger follow-up, preserve history, and change status without relying on somebody remembering what happens next.
That is the distinction this section is about: not whether a spreadsheet can contain the right fields, but whether containing the right fields is sufficient to coordinate the work.
Information without assignment. A spreadsheet row can show that a prior authorization was submitted three weeks ago and has not received a decision. Recording that fact is different from assigning the follow-up call to a specific person with a deadline, tracking whether they made the call, and surfacing the item to a manager when they haven't. The more the process depends on assignment logic, deadline tracking, and escalation, the more coordination infrastructure has to be built around the spreadsheet itself. At that point, the problem is no longer tracking information. It is managing a workflow.
Status without aging logic. A status field can record "pending." Surfacing pending items that have crossed the team's follow-up threshold, making their age visible to a manager without a manual sort, and routing the next action to the right person: those behaviors require coordination logic that goes beyond what a status cell provides on its own. The age of each item exists implicitly in the submission date. Making that age visible and actionable requires the system to do something with it, not just store it.
Records without structured history. A spreadsheet row reflects the current state of an item. A structured operational history records the sequence of what happened before that state: each follow-up contact made, each status change, each document submitted, each response received. Current status tells you where something is. Structured history tells you how it got there and gives the context needed for the next action: who spoke to the payer last, what was promised, what documentation is still outstanding. A handoff, an audit, or a manager's review depends on the second, not the first.
The point is not that spreadsheets are incapable. A well-maintained spreadsheet with consistent discipline can track a great deal. The problem appears when the volume of active items grows, when staff turn over, when follow-up deadlines start to matter, and when the manager needs to see everything at once. At that point, the question stops being whether the data exists and starts being whether the system does anything with it.
What a Managed Operational Layer Needs to Do
Teams that have moved beyond spreadsheets for healthcare operations tracking are not all using the same tool. But the systems that work share a common set of capabilities: requirements that follow directly from the operational problems described above. These are the things any healthcare operations platform needs to do, written as buyer evaluation criteria rather than as product features.
1. Track the full lifecycle of each operational item. A prior authorization request, a medical record request, a referral: each needs a record that follows it from initiation through resolution. Current status tells you where something is. Full lifecycle tracking tells you how it got there: when each action was taken, who took it, what the response was, and what the next step is. Status and lifecycle are different capabilities. A managed operational layer needs both.
2. Route work to the right person with a deadline. When a follow-up is required, the system should assign it to a named person with a due date. The assignment should be visible, tracked, and reflected in that person's workload. Not a reminder email that sits in an inbox. A tracked state that changes when action is taken and escalates to a manager when it hasn't been.
3. Flag exceptions automatically. As the number of active record requests and authorizations grows, relying on individuals to identify every item requiring attention increases the coordination burden. The system should flag exceptions: items past a defined age, authorizations approaching or past the decision window, record requests without a recent follow-up contact, without requiring someone to sort a spreadsheet first.
4. Connect work activity to outcomes. Activity data becomes useful when managers can connect workload and follow-up activity to movement through the operational queue. A productivity layer records how many accounts were worked, how many calls were made, how many items moved to resolution in a given period. That data can expose bottlenecks, uneven workloads, and capacity constraints that outcome reporting alone cannot explain: the difference between knowing that claims are aging and understanding why.
5. Preserve structured operational history. Current status is not enough for operational accountability. A manager, an auditor, or a successor needs to know what happened before an item reached its present state: prior contacts, status changes, assignments, documentation sent, responses received. Structured operational history is what makes a handoff possible without a briefing session, what makes an audit reviewable without reconstruction, and what makes a pattern across cases visible when individual memory cannot hold it.
6. Maintain security appropriate to the environment. Healthcare operations can involve sensitive information. An operational platform needs configurable access controls that reflect role, responsibility, and legitimate need, alongside security and compliance capabilities appropriate to the information it will handle. Access should be configured to match the sensitivity of the work rather than exposing every operational record to every user.
7. Work alongside existing clinical and financial systems. The operational layer fills the gap. It does not replace what is already working. The EHR and billing platform stay in place. Adding an operational tracking system should not require migrating clinical or financial data away from the systems that manage them. The requirement is that the operational layer connects where integration is useful and stands independently where it is not, without disrupting the systems the organization already depends on.
8. Expand without requiring a technical rebuild. When the organization needs to add another operational workflow, the system should accommodate it without rebuilding what already exists. New operational needs should extend the system, not restart it.
Kintone can be configured around these requirements. One medical billing services organization provides a concrete example of what that looks like when an initial operational workflow expands to meet additional needs.
What This Looks Like in Practice
A medical billing services company managing several hundred active medical record requests tracked those requests in a spreadsheet that could not show which ones were overdue, which had received recent follow-up, or how much contact had been made with each records source. A billing specialist knew what they had worked. Their manager had no view into the full picture without pulling the spreadsheet and sorting it manually.
After moving to Kintone, the team built a record request tracking application. Each request now captures when it was sent, what reference number was assigned, when records came back, and how many follow-up contacts had been made. The data that had lived in a spreadsheet now lives in a system where the state of every active request is visible without requiring anyone to compile it. A manager can see which requests are aging and who is responsible for each one. A billing specialist can see their own queue and document follow-up contacts in the same record.
Authorization tracking and staff productivity logging followed as additional workflows in the same system. The expansion pattern of building the next operational workflow in the same platform rather than starting another spreadsheet is what made each addition possible without rebuilding what already worked.
This is one organization's experience. The broader point is structural: active work needs ownership, visibility, aging logic, and history. Those requirements are structural rather than specific to this organization's implementation. What varies is whether there is a system in place to meet them.
The Operational Workflows Healthcare Teams Track
The operational layer contains multiple workflows, each with its own lifecycle, tracking requirements, and failure mode when it goes unmanaged. Below are five workflows that billing teams, specialty clinics, and healthcare administrative organizations track as part of the operational layer.
Medical record requests
Request sent to the records holder. Reference number assigned. Records pending. Follow-up contact made at defined intervals. Records received and status updated. Case complete.
Key tracking fields: request date, recipient organization, reference number, follow-up log (date and outcome of each contact), received date, document status. The gap without a system: no view of which requests are past the follow-up threshold, which have gone weeks without contact, or who is responsible for the next action. For a billing team managing active requests, the operational requirement is to know which requests are oldest, what follow-up has occurred, and who owns the next step.
Prior authorization tracking (see HC-S1: Prior Authorization Tracking for a full workflow breakdown)
Authorization request submitted. Payer acknowledgment. Status pending. Additional documentation requested or decision issued. Approval or denial. Appeal where applicable. Case closed.
Key tracking fields: submission date, payer, procedure or service requested, current status, follow-up log, additional documentation submitted, decision date, outcome. Under CMS regulations effective January 2026, Medicare Advantage and Medicaid managed care plans must issue standard prior authorization decisions within seven calendar days and expedited decisions within 72 hours [CMS-0057-F, cms.gov], a regulatory clock that makes authorization tracking a time-sensitive operational requirement for billing teams working with those plan types. The gap without a system: an authorization can sit pending without anyone tracking how long it has been there or whether follow-up has been made. See HC-S1 for the full lifecycle and field detail.
Claim follow-up and denial management
Claim submitted. Payment received or denial issued. Denial reason documented. Appeal submitted. Resolution.
Key tracking fields: claim ID, denial reason (using the payer's specific denial language), appeal status, resolution outcome. The gap without a system: the team can see the denial outcome in the billing platform without the same visibility into who owns the follow-up, what action has been taken, and which cases remain unresolved.
Healthcare referral tracking (see HC-S2: Healthcare Referral Tracking for a full workflow breakdown)
Referral received. Assigned to coordinator. Scheduling and confirmation activities. Coordination endpoint reached.
Key tracking fields: referral source, receiving provider, date received, date assigned, appointment date, patient confirmation status, referring provider notification status, closure date. Referral loop closure (the point at which the coordination workflow is complete) is included as a care coordination measure (CMS 50) in NCQA's Patient-Centered Medical Home criteria [ncqa.org] and defined in IHI/NPSF's published framework for closed-loop referral management [ihi.org]. The gap without a system: a referral can be received, logged, and drift without a named owner. See HC-S2 for the full lifecycle definition and field detail.
Staff productivity and accountability
Daily activity logged per staff member. Calls made, accounts worked, items moved to resolution. Aggregate visible at team and individual level.
Key tracking fields: staff name, date, activity type, count, notes. The gap without a system: the billing platform records the outcome without necessarily giving management the same visibility into the work activity that produced it.
Those workflows differ in purpose and lifecycle, but they create the same evaluation question: can one operational layer manage their distinct requirements without turning each new need into another disconnected tracker? That is what the next section addresses.
How to Evaluate an Operational Layer Alongside Your Existing Systems
A billing manager or practice administrator evaluating operational tracking software is not necessarily asking "what is the best operations tool in the abstract." They are asking something more specific: does this work alongside what I already have, and does it actually solve the coordination problems my team faces every day?
These six questions function as evaluation tests: not criteria to read off a features list, but prompts to use in an actual vendor conversation or demo.
Does it complement rather than replace what you already have? Ask the vendor to walk through what happens to data that currently lives in your EHR or billing platform. If the conversation requires contemplating a migration of clinical or financial records away from the systems that manage them, the tool is solving a different problem. The test is simple: can the operational layer be added without changing how existing systems work?
Can different workflows share records where appropriate, and restrict them where they shouldn't? A prior authorization and a record request may involve the same patient account. Ask the vendor to show how two workflows that reference the same patient information can be connected in the system, and then ask how access to each is restricted by role. Seeing both in the same workflow demonstrates whether connection and access control can coexist in practice, not just in the pitch.
Can managers see aging, ownership, and exceptions without assembling a report? Ask the vendor to show you, using live workflow data, how a manager identifies active items past a follow-up threshold, who owns each one, and which need immediate action. Ask whether those views can be saved, shared, and returned to as part of normal management work. If identifying exceptions requires rebuilding the analysis each time, the system is storing the information without making the management view persistent.
Can the people responsible for the workflow make changes without a development project? Ask who in the organization would adjust the workflow if a payer added a new authorization step next quarter. If every workflow change requires vendor development, ask how much operational control the team actually retains. Governance is one thing. Dependency is another.
Can access be configured to match the sensitivity of the work? Ask to see how permissions are set for a specific role: a billing specialist who should see their own queue but not another team's records. Role-based access should be demonstrable in the system itself, not described as a capability.
Can the organization add a new workflow without starting a new standalone system? This is the long-term test. A billing team that starts with record request tracking and later needs authorization tracking, then productivity logging, should be able to build each addition in the same platform. Ask the vendor for evidence that customers have expanded from one workflow to several on the same platform, whether through a reference customer, a documented case study, or a demonstrated implementation pattern. The format is less important than the proof that it has happened.
A Note on Security and Compliance
Healthcare-adjacent organizations handle sensitive information. An operational tracking system that runs alongside an EHR or billing platform needs to be built on a platform that takes data security seriously in environments where that is not optional.
Kintone is HIPAA compliant, SOC 2 Type II certified, and ISO/IEC 27001 certified. Organizations that need to process or store protected health information in Kintone do so after executing a Business Associate Agreement (BAA).
For organizations with specific compliance requirements, the relevant question is not only whether a platform holds certifications but whether it can be configured to match the access, audit, and data-handling requirements of the work it will support. That is an operational and legal question. Organizations with complex compliance environments should confirm the fit with their own counsel alongside any vendor evaluation.
The Operational Layer Is Already There
You do not create an operational layer by buying software. The layer already exists in every record request, authorization, referral, follow-up, handoff, and exception your team manages today. Software determines whether that work remains distributed across people and tools or becomes visible as one managed system.
That is the evaluation question: not whether you need another system, but whether the operational system you already depend on has been designed on purpose.
For teams ready to see what a managed operational layer looks like in practice, the prior authorization tracking guide and the healthcare referral tracking guide show how two specific workflows can be managed inside that layer. See Kintone in action with a demo built around your specific operational workflow.
About the Author
