Hey there, We’re Shivang & Tania. Each week, we write in plain English (and some sass) about how health insurance works, why claims get denied, and how patients and healthcare teams can get paid or reimbursed. If you’re new here, we recommend you start with RCM 101: How Healthcare Gets Paid, Eventually, Maybe

He exists only for this issue, so we are not adding another corgi to the permanent family tree. We just need him for a controlled comparison.

Imagine that Biscuit and his brother have the same clinically relevant history. Their maternal aunt had ovarian cancer at 46. Neither brother has a personal cancer diagnosis. Dr. Singh recommends the same hereditary-cancer panel for both of them, from the same laboratory, for the same clinical reason, during roughly the same period.

Then change one thing: their insurance.

From Biscuit’s perspective, that should not change very much. Dr. Singh is asking the same medical question for two people with the same relevant family history, and the same laboratory would perform the same test. It would be reasonable to assume that whatever happens after Dr. Singh places the order should look roughly the same too. It may not.

Once each order reaches the people responsible for figuring out the reimbursement path, the cases have to be worked separately. One brother’s insurance product may point toward one coverage policy and authorization process, while the other product may require a different set of checks. Depending on the plan, the differences could involve benefits, medical policy, prior authorization, documentation, laboratory or network requirements, or even a separate company that manages part of the authorization process.

That does not mean one brother is automatically covered and the other is denied. Nobody has necessarily made either decision yet. The important thing is that the reimbursement paths can begin to separate even though the medicine has not changed.

Later, when Biscuit asks why the office still cannot simply tell him what his insurance will do, his question is hard to argue with:

That is this week’s issue.

TL;DR

Healthcare does not suffer from a complete absence of reimbursement information. Payers publish medical policies and provider guidance. Physicians create clinical records. Laboratories know which tests they perform. Health plans hold benefit information. Billing and reimbursement teams maintain authorization and operational workflows. The problem is that the answer for one specific patient may depend on several of those sources at once.

To understand what is likely to happen with Biscuit’s test, somebody may need to connect his exact insurance product with the right policy, Dr. Singh’s clinical documentation, the exact test and laboratory, any authorization requirements, and the rules in effect at that point in time. Sometimes something is genuinely missing. Other times the correct information already exists but is sitting in a place, format, or workflow where the next person cannot effectively use it.

That gives us this week’s distinction: Missing information is not the same thing as unusable information.

Precision medicine makes the problem especially visible because the medicine itself can depend on very specific information about the patient and the test. That specificity still has to survive the administrative trip from one organization to another.

We are following the work that usually happens outside Biscuit’s view: why two clinically similar patients can enter different reimbursement pathways, why finding a payer policy does not necessarily answer the patient-level question, what happens when detailed information becomes less useful as it crosses organizational boundaries, and why reimbursement teams spend so much time connecting things that already exist.

Readers of this series already know that “covered” does not describe one single decision. A plan may have to consider whether a service falls within the patient’s benefits, whether the patient satisfies clinical criteria, whether prior authorization is required, and whether the eventual claim satisfies the rules for payment. Depending on the payer and service, those questions may be handled together or at different points in the process.

That distinction matters here.

When Sage receives the first brother’s case, she cannot safely begin with a generic question like, “Does this insurer cover genetic testing?” She first has to establish which insurance product applies and then determine which administrative pathway belongs to the test Dr. Singh ordered.

The second brother arrives with the same relevant history, the same physician, the same test, and the same laboratory. But if his insurance is different, Sage cannot assume that everything she learned from the first case carries over. The benefit structure may differ. A different medical policy may apply. One plan may require prior authorization where another does not, or the authorization may be handled through a different channel.

This is not about declaring one plan better than the other. Insurance rules attach to particular plans and products, so changing the coverage context can change the process even when the clinical facts stay still.

The medicine can stay the same while the reimbursement context changes.

Biscuit usually does not see most of this work. He may hear that the office is “checking insurance” or “working on the authorization.” Those phrases sound like single tasks. Behind them may be several different questions being answered by people and systems he will never encounter.

This is the obvious next response. If Sage needs to know the payer’s rules, and the payer publishes those rules, why not find the policy and be done?

Because a medical policy is important, but it is not necessarily the complete coverage answer for a particular member.

Aetna provides a useful real-world example because it says this explicitly. Its Clinical Policy Bulletins describe Aetna’s clinical-policy determinations, but Aetna also says those bulletins do not constitute a description of plan benefits. Each benefit plan determines what is covered, excluded, or limited, and if the policy bulletin conflicts with the member’s benefit plan, the benefit plan governs. (Aetna)

That is not evidence that the policy is hidden. Quite the opposite: the policy is public.

The problem is that Sage still has to connect that policy to the right member, the right insurance product, the right service, and the right point in time.

Publishing the rule solves the publication problem. It does not automatically answer the patient-level question.

From Biscuit’s point of view, the question still sounds simple: Does my insurance cover this test?

For Sage, the first job is not to predict the payer’s final decision. It is to figure out which reimbursement process actually applies to the order Dr. Singh just placed.

She may start by confirming Biscuit’s actual insurance plan or product rather than assuming the insurer’s name alone tells her which rules apply. Then she needs to know what Dr. Singh ordered, which laboratory will perform the test, whether the service requires prior authorization, and—if it does—where the request needs to go and what information has to accompany it.

Depending on the payer and the arrangement, some of that work may happen through the payer’s own portal. Another plan may route the process through a delegated authorization company. In some practices, an internal authorization team handles most of the work; in others, the laboratory or another reimbursement team may handle part of it.

UnitedHealthcare’s current genetic and molecular testing process is one example. For tests that require prior authorization under the applicable program, UHC says the request must be submitted by the ordering care provider, while the laboratory can check whether authorization is required. UHC also requires laboratories to register test-specific information, including the test name, a laboratory-assigned identifier, and the associated CPT code. (UHC Provider) Cigna offers a different example: precertification for certain molecular laboratory tests is currently handled through EviCore. (Cigna)

Those are examples of current payer workflows, not universal rules.

Sage is also not deciding whether Biscuit should receive the test. That remains Dr. Singh’s clinical role. Her operational job is to help make sure the request contains the information the payer or authorization vendor says it needs to evaluate the service.

For Biscuit, that could mean making sure the request carries the relevant family history Dr. Singh documented rather than reducing it to “family history of cancer.”

And this is where the information problem becomes visible.

The payer’s policy may be on its website. Biscuit’s insurance information may be in the practice-management system. Dr. Singh’s clinical reasoning lives in the medical record. The laboratory has detailed information about the test. Authorization instructions may live in a payer portal or delegated-vendor workflow.

None of those sources has to be wrong for Sage to have work to do. Her job is to make sure the pieces that matter to this particular case reach the right place in a form the next organization can use.

That is why a reimbursement answer often has to be assembled, not simply looked up.

The easiest way to see what can go wrong is to follow one fact we already know.

In our earlier medical-necessity issue, Dr. Singh had a fairly precise piece of information about Biscuit:

His maternal aunt had ovarian cancer at 46.

That detail matters because a payer evaluating hereditary-cancer testing may care about which relative had cancer, how that person is related to the patient, the cancer type, the age at diagnosis, and other specific elements of the history.

But the initial request reduced Biscuit’s story to:

Family history of cancer.

Nothing in those four words was false. The problem was that they discarded much of the information the payer needed to apply its criteria. In our fictional BHC example, Otis could evaluate only what reached the payer; he could not reconstruct the full clinical conversation from information that remained elsewhere.

Last time, we used that example to explain documentation and medical necessity. This time, notice something different: the detailed information already existed.

Sometimes information really is missing. Perhaps nobody recorded the relative’s age at diagnosis. Maybe the current insurance information was never collected. Perhaps the exact test has not yet been selected.

Those problems require someone to obtain information that genuinely is not there.

But reimbursement teams also encounter another situation: the information exists somewhere, yet it is not usable at the point where the next decision is being made.

A payer may update a policy while an internal checklist still reflects the older version. Dr. Singh’s note may contain the exact clinical fact the reviewer needs while the authorization request captures only a broad summary. A medical record may technically be attached to the request, but the relevant fact is buried inside several pages of documentation.

Another version appears when different descriptions of the same service stop lining up. The order identifies one test, the authorization references a particular service or laboratory, and the eventual performed or billed service no longer matches what was originally reviewed.

These are examples, not formal categories, and they will not happen in every organization. They simply show why an information problem does not always mean healthcare lacks the information.

Sometimes healthcare has the right information in the wrong place, at the wrong level of specificity, or disconnected from the rule that gives it meaning.

Before going further, it helps to explain what precision medicine actually means, because the phrase can sound like another name for genetic testing.

It is broader than that.

Much of medicine necessarily learns from groups of patients. Clinical studies and treatment guidelines identify patterns among people with similar diseases, symptoms, or characteristics. Precision medicine asks whether additional differences among individual patients can help make prevention, diagnosis, or treatment more specific.

NIH describes precision medicine as an approach that takes individual variation in genes, environment, and lifestyle into account. (National Institutes of Health (NIH)) Genetics is therefore part of precision medicine, but it is not the whole definition.

Molecular and genomic diagnostics are simply one place where that specificity becomes particularly visible.

A hereditary-cancer test may depend on detailed family history and the clinical question Dr. Singh is trying to answer. Other molecular tests may depend on tumor characteristics, previous testing, a particular variant, the genes included in a panel, the methodology used, or the intended clinical use of the result.

Not every test depends on every one of those variables. That is exactly why specificity matters. “Genetic testing” can describe services that are clinically very different.

The more precisely medicine distinguishes among patients and tests, the more important it becomes that reimbursement workflows preserve the distinctions that actually matter.

Before we throw another acronym at you, it helps to understand the corner of Medicare we are entering.

Traditional Medicare does not process every physician and hospital claim from one giant national claims office. For Medicare Fee-for-Service, CMS contracts with regional organizations called Medicare Administrative Contractors, or MACs. These private insurers process Medicare claims and perform other administrative functions within assigned jurisdictions. (Centers for Medicare & Medicaid Services)

MACs also have a role in local Medicare coverage policy. So depending on the service, a provider may be working with a national Medicare coverage rule, a local rule administered through a MAC, associated coding guidance, or some combination of those sources.

Now add molecular diagnostics.

/blocA molecular test can be difficult to identify using only the information traditionally found on a claim. Two laboratories can perform different assays, looking at different genes or using different methodologies, while the billing information alone may not tell the payer everything it needs to know about the exact test.

This is where MolDX comes in.

MolDX is a molecular-diagnostics program administered by Palmetto GBA. Palmetto describes the program’s purpose as identifying molecular diagnostic tests and determining coverage and reimbursement on behalf of Medicare. (Palmetto GBA Files)

Other MACs participate as well. As of Palmetto’s August 31, 2026 program guidance, MolDX operates in specified jurisdictions administered by Palmetto GBA, Noridian, WPS Government Health Administrators, and CGS Administrators. Palmetto explicitly says the program is not national in scope. (Palmetto GBA Files)

So MolDX is not “the way Medicare handles every molecular test.” It is a specialized framework operating within participating parts of Medicare Fee-for-Service.

One of the tools inside that framework is the DEX Diagnostics Exchange, or DEX Registry.

DEX maintains information about individual molecular tests so MolDX and participating payers can distinguish one registered test from another. Palmetto says the registry is used to track accurate test information and apply the appropriate payer controls during claim adjudication. (Palmetto GBA Files)

A registered test can also receive a DEX Z-Code.

The Z-Code is a unique identifier tied to the particular test. Palmetto says it allows the payer to identify which test was actually performed and connect that identity with registered information such as intended use, methodology, and performance. (Palmetto GBA Files)

That does not mean the Z-Code replaces CPT coding. Palmetto describes it as additional information, not a billing code. (Domino Apps)

Why would an additional identifier be useful if the claim already contains a CPT code?

Because for some molecular diagnostics, the billing code can describe the category of service without uniquely identifying the exact assay underneath it.

And now MolDX fits directly into the larger story of this issue.

The laboratory knows which test it performed. Medicare has billing codes. Coverage policies exist. But the reimbursement process may still need another piece of information to connect those things reliably.

MolDX and DEX are one real-world example of the healthcare system creating extra structure because knowing the general billing category and knowing the exact test are not always the same thing.

There is much more to MolDX: registration, technical assessment, coverage policies, coding rules, claim requirements, and jurisdiction-specific details, and we are deliberately leaving most of that for another issue.

MolDX also points toward a broader Medicare lesson. Different reimbursement information often lives in different official sources because those sources perform different jobs.

The Medicare Coverage Database contains National Coverage Determinations, Local Coverage Determinations, and contractor articles. CMS explains that, for most local coverage, coding information is now found in Billing and Coding Articles rather than inside the LCD itself. (Centers for Medicare & Medicaid Services)

CMS makes a similar distinction for national coverage. It says NCDs do not contain claims-processing information such as diagnosis or procedure codes or tell providers exactly how to bill Medicare. Those operational instructions can instead appear in Change Requests and the Medicare Fee-for-Service Claims Processing Manual. (Centers for Medicare & Medicaid Services)

There is a sensible reason for that separation. A coverage determination and a claims-processing instruction are doing different jobs.

For the person trying to operationalize the rule, though, the practical consequence is that sometimes the answer requires knowing which authoritative sources need to be read together.

This interface problem is not limited to molecular testing.

CMS’s Interoperability and Prior Authorization Final Rule is pushing parts of prior authorization toward more structured electronic exchange. The rule applies to specified payer groups and requires new FHIR-based APIs. One is a Prior Authorization API that must be able to identify covered items and services, communicate documentation requirements, and support authorization requests and responses. Certain operational requirements began in 2026, while the principal API requirements generally begin in 2027. Drug prior authorization is excluded from these particular API provisions. (Centers for Medicare & Medicaid Services)

An API is essentially a structured way for computer systems to exchange information. Instead of requiring a person to search one portal, copy information into another system, and wait for a response somewhere else, some of that exchange can happen directly between software systems.

That can reduce friction, but it does not decide medical necessity, guarantee that documentation proves a patient satisfies a policy, or reconcile every test, contract, and billing rule.

What it does show is that making payer requirements more usable inside the workflows where people actually need them has become an explicit policy priority.

Now return to Sage.

Dr. Singh creates the clinical reasoning and orders the test. The laboratory performs the test. The payer evaluates coverage and payment.

Depending on the arrangement, the laboratory or reimbursement team may be responsible for moving the case forward while depending on information created by everybody else.

Sage may need clinical facts from Dr. Singh’s organization, insurance information about Biscuit, technical information about the laboratory’s test, and requirements established by a payer or authorization vendor. She did not create all those systems, and she does not control all their rules.

Biscuit generally sees only the result of that work. He hears that the office is still working on the authorization, that another record is needed, or that the insurance company wants additional information.

A sentence that takes five seconds to say to the patient can represent a substantial amount of work behind the scenes.

Sometimes there really was a simple mistake. Other times the delay reflects several organizations trying to make their versions of the same case line up well enough for the next step to happen.

The American Clinical Laboratory Association, or ACLA, gives us the laboratory industry’s perspective on some of this.

ACLA describes itself as the national trade association representing leading clinical laboratories. It is an advocacy organization, so its policy positions should be understood as the laboratory industry making its case to policymakers rather than as neutral rules governing every payer or laboratory. (American Clinical Laboratory Association)

In 2025, ACLA published recommendations to Congress specifically addressing prior authorization and medical-documentation reform. (American Clinical Laboratory Association)

The relevance here is structural. A laboratory may ultimately need to obtain reimbursement for a test even though much of the clinical information supporting that test originated in somebody else’s chart, while the coverage and authorization requirements were created by somebody else entirely.

That does not mean every laboratory operates the same way, or that laboratories have no responsibility for their own reimbursement processes. It helps explain why diagnostic reimbursement can involve considerably more than attaching a billing code to a claim.

Sometimes the answer is fairly clear.

A payer’s guidance may be difficult to match to the right insurance product. A physician’s documentation may leave out a fact needed for the review. A laboratory may still be working from an old internal checklist. A billing team can apply the wrong rule. A software connection can fail. A delegated vendor can receive less information than the organization sending the request thought it had provided.

Those situations have identifiable causes, and the response depends on what actually went wrong.

The harder cases are the ones where there is no single obvious error.

Look again at our hypothetical brothers. Dr. Singh can document the history correctly. The payer can publish a current policy. The laboratory can identify the right test. A delegated vendor can ask a reasonable question based on what it received. Each organization can be doing something sensible within its own workflow, while the case still develops a problem where those workflows meet.

That is different from saying nobody is responsible. Organizations still control their own processes, and handoffs can be designed well or badly.

Healthcare is full of organizations that know their piece. Reimbursement depends on those pieces lining up.

For Biscuit, most of this architecture is invisible. He does not know which policy version Sage reviewed, whether an authorization went through a separate vendor, or which clinical detail failed to appear in a request. He experiences the problem as a delay, another phone call, uncertainty about whether the test can proceed, or concern about what he may ultimately owe.

Dr. Singh experiences a different version of the problem. A clinical decision made during an appointment can generate documentation requests and administrative work long after the visit ends.

The laboratory may depend on clinical information it did not create and reimbursement rules it does not control.

For RCM, prior-authorization, reimbursement, and market-access teams, the work is much more involved than simply “checking the policy.” Someone has to identify the relevant source, determine whether it applies, understand when it became effective, translate its requirements into the information needed for the case, and reconcile those requirements with what was actually ordered and performed.

Payers see the other side of the same interface. When a request arrives incomplete or inconsistent, somebody there may have to seek additional documentation or determine whether the submitted information is enough to apply the rule.

Different organizations experience the fragmentation differently, but everybody ends up spending time on it.

Patients should not be expected to run this process themselves.

Most of what we have described happens among providers, laboratories, payers, vendors, and administrative systems. Biscuit should not have to know how Sage searches for policy versions or how a particular molecular test is represented in a payer workflow.

But when a problem reaches the patient, a little precision can help.

If someone says, “Insurance doesn’t cover this test,” a useful follow-up is:

“Do you mean this test is excluded from my benefits, or that the payer says I don’t meet its coverage criteria?”

Another useful question is:

“Which policy or plan rule is that based on?”

Those questions do not create coverage or guarantee that the answer will change. They simply help establish which reimbursement problem is actually being discussed.

There are several rabbit holes sitting just outside this issue, and we are leaving them there on purpose.

We are not teaching the full MolDX and DEX process, molecular CPT coding, PLA codes, PAMA rate setting, crosswalk and gapfill, FDA regulation of laboratory-developed tests, state biomarker mandates, laboratory benefit managers, every prior-authorization structure, detailed FHIR architecture, appeals, network contracting, or every reason a molecular test can be denied.

Several of those deserve their own issue.

It would be tempting to answer: put everything in one place.

That is not quite enough.

Sage does not need every policy, plan document, Medicare article, laboratory specification, contract, and clinical note dumped into one very large folder. More documents can create more searching without creating more certainty.

What she actually needs is context. Which rule applies to this case, and why? Where did it come from? When did it become effective? What does it require? Which patient facts matter? Does the organization already have those facts? Which test and laboratory does the rule concern? What still needs to happen?

The original sources matter too. A useful reimbursement answer should be traceable back to the policy, plan, contract, or other rule that supports it.

The goal is not simply to collect more information. It is to make the relevant information usable when somebody needs to act.

This brings us back to Biscuit’s original question.

If Dr. Singh knows his history, the laboratory knows the test, the payer publishes its rules, and the healthcare system already has his insurance information, where exactly did the reimbursement answer disappear?

Mostly, it did not disappear.

Dr. Singh had the clinical story. The laboratory had information about the test. The payer had its coverage and benefit rules. Sage could access some of those pieces and had to retrieve or reconcile others. Different systems held different representations of the same case.

Biscuit’s original assumption—same family history, same physician, same test, therefore the same reimbursement process—was missing the administrative context around the medicine: which insurance product, which rule, which version of that rule, which laboratory, which documentation, and which date.

He should not have to personally assemble any of that.

But somebody does.

That may be the most useful way to understand reimbursement fragmentation. The problem is not always that healthcare knows too little. Sometimes the difficult part is getting what healthcare already knows to meet in the right place, at the right time, without losing the details that made the information useful in the first place.

Medicine is getting better at distinguishing one patient, one disease, and one test from another. The reimbursement system has to get better at carrying those distinctions through everything that happens next.

That is also the problem behind Converus.

We did not start Converus because payer policies do not exist. They clearly do.

What we kept seeing was the work required to connect those policies with the other information that drives reimbursement: LCDs and NCDs, MolDX requirements, prior-authorization rules, contracts, mandates, documentation requirements, and internal guidance.

Converus is an intelligence layer for reimbursement operations. It centralizes sources such as payer policies, LCDs/NCDs, MolDX, mandates, contracts, and internal guidance; translates reimbursement requirements into structured rules; and makes that logic usable across billing and operational systems. (Converus)

The boundaries are important. Converus does not replace Dr. Singh’s clinical judgment. It does not make the payer’s coverage decision, and it does not guarantee reimbursement.

The goal is more specific: make reimbursement information easier for the people responsible for acting on it to find, trace, connect, understand, and use.

That's it for this issue. Hit reply. I read everything.

A note on the workflow. The acknowledgment sequence (TA1, 999, 277CA) and the 837-out, 835-back round trip described here are the standard electronic-billing workflow under the HIPAA transaction standards, and they match CMS's own description: the TA1 validates the interchange (the ISA/IEA envelope), the 999 validates implementation-level syntax and replaced the older 997, and the 277CA reports claim-level acceptance or rejection for processing. None of the three means the claim was adjudicated or paid. In real-world practice the flow is layered rather than tidy, because the claim moves through a clearinghouse: a provider often receives multiple 277CAs (from the clearinghouse and from the payer), most software surfaces these as a status trail instead of raw transaction files, and some trading partners return a TA1 only when there is an interchange-level error. Terminology varies by payer, clearinghouse, and vendor. Biscuit's numbers ($1,000 billed, $600 allowed, $450 paid, $150 patient responsibility) are illustrative, not any real plan's figures. Always work from your own clearinghouse's and payers' current documentation.

Disclaimer: The content published by preimbursed (the "Newsletter") is provided for general informational and educational purposes only and reflects the opinions and commentary of the author. It does not constitute, and should not be relied upon as, medical, legal, financial, tax, insurance, or other professional advice. No physician-patient, attorney-client, fiduciary, or other professional relationship is created by reading the Newsletter or by corresponding with the author. The Newsletter is not a substitute for individualized advice from a qualified professional. Before making any healthcare, coverage, insurance, financial, or legal decision, you should consult your own physician, attorney, benefits administrator, or other licensed advisor and review your specific plan documents, policies, and applicable law. The author is not responsible for any action taken or not taken in reliance on the content herein, and you assume full responsibility for your use of the information provided. Information in the Newsletter is believed to be accurate as of the date of publication and is drawn from the sources cited. Laws, regulations, coverage rules, corporate ownership, market data, and other facts change frequently and may have changed since publication. Certain statements describe pending, recently enacted, or phased-in legal and regulatory changes whose scope, interpretation, and effective dates may shift. The author makes no representation or warranty, express or implied, regarding the accuracy, completeness, timeliness, or reliability of any content, and disclaims all liability for any errors or omissions to the fullest extent permitted by law. References to any company, organization, product, government program, or individual are made solely for purposes of news reporting, commentary, analysis, and criticism, and do not imply any endorsement, sponsorship, affiliation, or partnership. All trademarks, service marks, and trade names are the property of their respective owners and are used only for identification and descriptive purposes. Where a named party disputes a characterization or finding, the Newsletter notes that dispute. Statements concerning identified companies reflect cited reporting and the author's opinion and analysis of matters of public concern. Certain characters, organizations, and scenarios in the Newsletter, including but not limited to Biscuit, Dr. Singh, and composite payer and provider names, are fictional and used for illustration. Any resemblance to actual persons or entities is coincidental.

Disclosure: The authors are the co-founders of Converus.ai, a company that organizes payer policy information for healthcare providers, and therefore has a commercial interest in the subject matter discussed. References to Converus.ai are made only where relevant and are not paid placements. To the fullest extent permitted by applicable law, the author and preimbursed disclaim all warranties and shall not be liable for any direct, indirect, incidental, consequential, or other damages arising out of or in connection with your use of, or reliance on, the Newsletter.