The Bizarre Half Price Genome at GENEDX (solved)

 A May 2026 posting by Alex Dickinson at Linked In about GeneDx reports that it is paid $2000 for genome and $4000 for exome, making the former a bad deal economically even as clinicians migrate to genome.

I think the answer is, you bill and receive $4000 for the Exome, but you bill more and have many more nonpayments for the genome.  For example, you bill Genome at $8000 and get paid one in four, presto, you have $2000.

###

https://www.linkedin.com/posts/alexgdickinson_gendx-activity-7457868325742698496-J3H7?utm_source=share&utm_medium=member_desktop&rcm=ACoAAAC8IsMBMg_Mu0JrhdieRHyFF6Tw_rXJ3Ns

He includes a ten page AI PDF about GeneDx finances.

Here's more about that half-price genome compared to exome.

##

https://chatgpt.com/c/6a04a85d-ac40-83e8-a54e-31708ad60585

Yes — the $4,000 outpatient exome / ~$2,000 outpatient genome statement is publicly verifiable, but with an important caveat: the primary source is GeneDx management on the Q1 2026 earnings call, not an independently audited payer-by-payer table. Independent market coverage then repeated the same point.

The key passage is from GeneDx CFO Kevin Feeley on the Q1 2026 call. He said GeneDx’s blended average reimbursement rate was about $3,300, and that the shortfall was driven by product mix, not by like-for-like price cuts. He then stated that in the outpatient channel, exome was “closer to a blended average of $4,000 per test after all denials,” while outpatient genome blended ARR was “about half that of exome” because genome payer coverage is less mature. (The Motley Fool)

That matches the report’s language almost exactly: outpatient exome about $4,000 after denials and adjustments; outpatient genome about $2,000; blended ARR about $3,300, with the mix shift from exome to genome pulling realized revenue below plan.

The company’s own Q1 2026 investor deck also triangulates the math. It reports 27,488 exome/genome tests and $90.6M of exome/genome revenue, which is about $3,296 per test, i.e., GeneDx’s stated ~$3,300 Q1 ARR. The same slide says blended ARR was lower because of higher genome mix and lower parental-sample mix, while pricing and collection rates were “relatively unchanged.”

A non-company source, Investor’s Business Daily, also reported the same interpretation: outpatient WGS pricing was about $2,000, roughly half of WES, and genome had risen to about 40% of outpatient volume, creating the revenue headwind. (Investors)

Your instinct that this looks odd against public fee schedules is right. Public schedules do not generally show genome at half of exome. For example, Maryland’s 2026 Medicaid lab schedule lists 81415 exome at $3,800.10, 81416 comparator at $954, 81425 genome at $3,999.80, and 81426 comparator genome at $2,154.40 — genome is not lower than exome there. (Maryland.gov Enterprise Agency Template) Children’s Hospital Colorado’s 2026 laboratory fee schedule similarly lists exome proband at $2,550, exome trio at $4,386, genome proband at $3,774, and genome trio at $5,610.

So the reconciliation is: GeneDx is not saying the fee schedule for genome is $2,000. It is saying its realized outpatient blended ARR for genome is about $2,000 after coverage gaps, denials, adjustments, payer mix, and likely zero-pay cases. That is a very different number from Medicare CLFS, Medicaid fee schedules, hospital chargemasters, or allowed amounts when a claim is cleanly covered. CMS itself describes CLFS rates as weighted medians of private-payer rates for the test, which is still not the same thing as a company’s net realized revenue across all submitted outpatient claims. (Centers for Medicare & Medicaid Services)

Bottom line: the report’s statement is real and traceable to GeneDx’s Q1 2026 call, and it is repeated by independent financial coverage. But I would phrase it carefully:

“GeneDx management stated that, in its outpatient channel, realized ARR for exome is about $4,000 after denials, while outpatient genome ARR is roughly half that level, or about $2,000, reflecting immature payer coverage rather than the nominal public fee schedule value of CPT 81425.”

###

yes, it starts as a puzzle but becomes trivial. bill $8000 for genome, get paid one in four, and that's your $2000. E-Z.

Exactly. The headline fee schedule comparison makes it look bizarre: “How can genome be worth half of exome?” But the operating math is not really price; it is realized yield per ordered test.

So the structure is more like:

Nominal allowed / billed / expected value: genome may look comparable to or higher than exome.
Coverage reality: many outpatient genome claims are not covered, denied, appealed, delayed, or written off.
Realized ARR: if the effective collection rate is much worse, the average collapses.

So your example is the right intuition:

Bill/allow/expect $8,000 for genome × 25% realized collection = $2,000 realized ARR.

Meanwhile, outpatient exome may have a decade of coverage-policy muscle memory behind it, so perhaps the exome claim is less exotic to payers, better covered, better preauthorized, and less often zero-paid. Thus:

Exome may not be “priced higher” than genome. It may simply be paid more often.

That also explains why the GeneDx issue is financially ugly but not scientifically mysterious. The company’s customers are migrating toward the biologically broader test, but the payer system is still treating outpatient genome as a less settled coverage category. So the clinical adoption curve and the revenue curve temporarily move in opposite directions.

A concise way to say it:

The GeneDx surprise was not that genome has a lower fee schedule value than exome. It was that outpatient genome has a lower realized cash yield because coverage is immature. In practice, a high nominal genome price multiplied by a weak collection rate can easily land at half the realized revenue of exome.

Chat GPT asks, WHAZZUP

 Subject: Chat GPT Asks: WHAZZUP with MOLDX

What appears to have gone wrong at MolDx: a management-evolution view

MolDx began as a necessary improvisation. In the early 2010s, Medicare was facing a molecular diagnostics problem that the legacy CPT and claims systems were not built to solve. One CPT code could hide many different tests. “Stacked” molecular codes did not identify the actual clinical service. Tumor panels, germline panels, expression classifiers, and later MRD assays were multiplying faster than Medicare’s normal coverage and coding apparatus could classify them. Public descriptions of the program still define its core mission as three linked functions: test identification, application review, and coverage/reimbursement determination. (Palmetto GBA)

That was the original brilliance of MolDx: it recognized that Medicare could not make rational payment decisions unless it first knew what test was actually being billed. The Z-code apparatus solved a real problem. It created test-specific identity in a world where CPT codes were often too broad, too old, or too generic. Other MACs later adopted the MolDx framework, and public MAC descriptions say the program identifies molecular diagnostic tests, establishes coverage and reimbursement, sets clinical utility expectations, completes technical assessments, and tracks utilization. (Medicare)

But the same feature that made MolDx innovative also created its long-term vulnerability. It was not merely a coding registry, not merely a coverage program, not merely a utilization-control program, and not merely a scientific review body. It became all of these at once. That is a hard hybrid to govern. It sits somewhere between a MAC, a payer technology-assessment committee, a claims-editing vendor, a scientific review board, and a quasi-national Medicare molecular diagnostics agency. Yet it does not have the transparent statutory architecture, appellate structure, staffing norms, performance metrics, or public accountability one would expect from a true national agency.

The result is an institution that appears to have outgrown its founding model.

1. The founder model worked when the problem was smaller

The early MolDx model seems to have depended heavily on a small number of unusually knowledgeable individuals. Dr. Elaine Jeter was publicly identified as the medical director of MolDx in the program’s formative period, and contemporaneous trade coverage described her as seeing the need to define what Medicare was actually paying for in molecular testing. (myadlm.org)

That kind of founder-led model can be extremely effective at birth. It allows rapid judgment, internal consistency, and a coherent philosophy. In 2012–2014, the molecular testing world was chaotic enough that even a rough but expert-controlled clearinghouse was better than the alternative. If the question was, “Is this a real test, what does it measure, what clinical use is claimed, and is there enough utility evidence to pay for it?” a small expert group could often answer.

But founder models usually fail at scale unless they are converted into institutional models. The founder knows the implicit rules. The founder remembers prior decisions. The founder can say, “This one is like that one, but different in these two ways.” The founder can make a judgment call without a written operating manual. That is efficient until volume rises, technologies diversify, and stakeholders begin to demand reproducibility.

At some point, tacit expertise has to become process architecture: clear evidentiary templates, review timelines, escalation pathways, reviewer calibration, written precedent, and public-facing decision logic. If that conversion does not happen, expansion simply produces more reviewers, more meetings, more files, and more elaborate controls—but not necessarily more throughput.

2. MolDx appears to have scaled staffing without fully scaling decisional architecture

The modern MolDx program is no longer a one-person intellectual shop. Dr. Gabriel Bien-Willner is publicly described as MolDx medical director and Palmetto GBA chief medical officer, and the program is described in industry forums as setting policy for affiliated MACs over a broad multistate footprint. (Trapelo)

That expansion should, in theory, have solved the bottleneck problem. More MDs and PhDs should mean more parallel review, more specialization, and more predictable cycle times. But stakeholder complaints suggest the opposite: the system may have gained staff without gaining decisional finality.

That is a classic management failure mode. Organizations often respond to backlog by adding expert reviewers. But if the underlying process has no clear standard for “enough evidence,” no binding decision clock, no structured endpoint, and no authority to say “approve, deny, or publish a noncoverage rationale,” the additional reviewers may increase review complexity rather than reduce it. Each reviewer can generate more questions. Each round can expose another uncertainty. Each uncertainty can justify another cycle.

The technical assessment process, by its nature, invites this. MolDx says technical assessments are required for certain molecular LDTs to determine compliance with policy. (Palmetto GBA) That is reasonable. But a technical assessment can become either a disciplined coverage review or an endless epistemology seminar. The difference lies in governance.

A disciplined review says: here is the question; here is the evidence standard; here is the submitted evidence; here are the remaining deficiencies; here is the decision. An undisciplined review says: here are two pages of questions; thank you for the ten-page response; here are six more pages of questions; thank you again; here are additional concerns; the file remains under review.

That is not merely slow. It changes the nature of the program. It turns MolDx from a coverage gateway into a perpetual uncertainty machine.

3. Broad LCDs plus test-specific technical assessments create a hidden bottleneck

One of MolDx’s most important structural choices is the use of broad LCDs and articles, with test-specific coverage often operationalized through Z codes, coding articles, or technical-assessment completion. The DEX/Z-code system identifies individual tests, and public descriptions say DEX is used as a critical business process in the MolDx program. (dexzcodes.com)

This architecture has advantages. It avoids writing a new LCD for every test. It allows a policy to cover a category—say, molecular tests for a cancer indication—while using test-specific review to decide which products qualify. That is administratively elegant.

But it also creates a submerged coverage process. The public LCD may say a class of tests is covered when reasonable and necessary. The real decision, however, happens in the private or semi-private technical assessment file. If dozens of specific tests remain in review, the practical effect is noncoverage, even though the LCD itself may appear broad and enabling.

This creates a legitimacy problem. Medicare coverage is supposed to be governed by public rules, public LCDs, reconsideration mechanisms, comment periods, and appealable claim decisions. But MolDx’s test-specific operational decisions can become the actual gatekeeping layer. That may be legally and administratively defensible in many cases, but from the stakeholder perspective it feels like being trapped in an unpublished administrative maze.

The worst version is: the LCD is broad, the evidentiary standard is elastic, the test-specific review is opaque, and the timeline is indefinite. In that setting, no one can plan. Investors cannot forecast coverage. Labs cannot decide whether to keep funding clinical studies. Clinicians cannot know when a useful test might become available. Patients become invisible casualties of procedural delay.

4. The program may have confused control with management

Dr. Bien-Willner’s apparent emphasis on protocols, best practices, and management controls is not inherently a flaw. A program like MolDx needs controls. Molecular diagnostics is filled with real risks: overutilization, weak evidence, bad coding, misleading claims, duplicate tests, poorly validated LDTs, and aggressive billing. A serious Medicare contractor cannot simply wave tests through.

The problem is that controls are not the same thing as management.

Controls ask: Did the applicant submit the required materials? Are the right boxes checked? Has each concern been answered? Is every risk closed?

Management asks: What is the purpose of the process? What throughput is required? What decisions must be made this quarter? Which files are stuck and why? Which standards are ambiguous? Which reviewers disagree? Which applicants deserve a final yes/no? Which recurring questions should be converted into public guidance?

A control culture can feel rigorous while performing poorly. Indeed, the more delayed the process becomes, the more a control-oriented organization may respond by adding more controls. More templates. More rounds. More internal signoffs. More “alignment.” More precision in the paperwork. But the output that matters is not the elegance of the internal protocol. The output is timely, consistent, explainable Medicare coverage decisions.

If new LCDs are rare and existing LCD pathways are clogged by endless test-specific review, the system may be optimized for not making mistakes, rather than for making accountable decisions. That is a different mission.

5. Conference visibility can become a symptom of role confusion

It is not wrong for a MolDx leader to speak at industry, policy, healthcare, or investor conferences. In fact, given the program’s importance, some public explanation is useful. The molecular diagnostics industry needs to hear what Medicare expects. Public engagement can reduce misunderstanding.

But when stakeholders experience operational gridlock, heavy conference visibility takes on a different meaning. It begins to look like external thought leadership has outrun internal execution.

That may or may not be fair to any individual. The director may be working extremely hard. The conference appearances may be only a small fraction of total effort. But organizationally, the optics matter. If applicants are waiting through repeated 60-day cycles, receiving expanding question sets, and seeing no final decision, they will not be reassured by polished conference presentations about rigorous process. They will ask: who is running the shop?

The deeper issue is not travel or speeches. The deeper issue is whether MolDx has a functioning chief operating discipline separate from its scientific and policy voice. A complex program needs someone accountable for cycle time, queue management, reviewer assignment, applicant communication, decision closure, and backlog reduction. That is an operations role, not a podium role.

6. The Z-code apparatus succeeded commercially but may have distorted the public mission

The Z-code/DEX infrastructure solved the “what test is this?” problem. It also became a licensed product used beyond Medicare. Public descriptions characterize DEX as a diagnostics exchange and molecular diagnostic test identification/policy management solution, and Optum markets Z-code data/registry products as a way to connect payers and labs and bring clarity to MDx testing. (dexzcodes.com)

That success creates another institutional ambiguity. Is MolDx primarily a Medicare coverage program? A payer-control architecture? A test registry? A data asset? A policy engine? A commercialized infrastructure?

The answer may be “all of the above,” but that is exactly the governance problem. When a public Medicare function becomes intertwined with proprietary identifiers, payer-facing data products, and multi-payer utilization management, stakeholders reasonably worry that the program’s incentives are no longer simple. The Medicare beneficiary and the reasonable-and-necessary standard should be central. But the broader business ecosystem may pull toward more registration, more classification, more control, more data capture, and more payer utility.

That does not mean improper conduct. It means mission creep. A tool built to support coverage can become a platform whose maintenance and expansion become ends in themselves.

7. The program’s authority is powerful but strangely hard to supervise

A central frustration is that there is no obvious line of command. MolDx is administered by Palmetto GBA, a Medicare Administrative Contractor. MACs operate under CMS contracts. Other MACs may adopt MolDx policies. CMS has national coverage authority and can issue NCDs, but day-to-day MolDx technical assessments are not run by the CMS Coverage and Analysis Group in the ordinary way. Labs can complain to MolDx. Associations can write to Palmetto, CMS, or HHS. Congress can inquire. But there is no clean lever that says: “Replace the operating model by July 1.”

This is one of the program’s most serious structural defects. MolDx has become quasi-national in effect but remains contractor-local in formal governance. That mismatch is tolerable when things work. It becomes intolerable when they do not.

The Agendia litigation history illustrates how controversial this structure can be. In a Supreme Court petition, Agendia characterized MolDx as a contractor-established assessment process that effectively determines whether certain molecular diagnostic tests can be approved for Medicare coverage and payment. That is one litigant’s framing, not a neutral judicial finding, but it captures the industry perception of concentrated contractor power. (Supreme Court)

The management problem is therefore not just inside MolDx. It is also above MolDx. CMS benefits from MolDx because it provides specialized molecular diagnostics capacity without CMS having to build a full national office for every rapidly changing technology. But if CMS relies on MolDx as a de facto national infrastructure, CMS also needs a way to impose performance standards, transparency, and corrective action.

8. What “collapse” probably means here

Collapse does not necessarily mean no one is working. In fact, collapsed bureaucracies are often full of hardworking people. The collapse is functional, not literal.

A functioning program converts inputs into outputs. MolDx receives test registrations, evidence packages, technical assessments, clinical utility arguments, and policy requests. The outputs should be timely Z-code determinations, coverage decisions, coding instructions, article updates, LCDs, denials, reconsideration decisions, or public explanations.

If inputs continue to enter but outputs slow dramatically, the program becomes a queue with scientific language attached. If question rounds multiply but decisions do not, the program becomes a review loop. If leadership explains standards at conferences but applicants cannot get closure, the program becomes a reputation-management enterprise. If broad LCDs exist but specific tests cannot get through, the program becomes a coverage mirage.

That is what appears to have gone wrong: not that MolDx lost its original purpose, but that its original purpose became too large for its governance, staffing model, operating discipline, and accountability structure.

Remedies: what could realistically be done?

The remedies are limited because the authority lines are muddy. Still, several paths exist.

1. MolDx could impose an internal decision-clock and closure rule

The most immediate remedy would be internal. MolDx could adopt a formal rule: after a complete technical assessment submission, MolDx has a defined period—say 90 or 120 days—to issue one of four outputs: approve, deny with rationale, request one consolidated set of additional information, or place the test in a named policy-development queue.

After the applicant responds, MolDx would get one further review cycle. Then it must decide. No indefinite rolling questions. No expanding interrogatories unless the applicant materially changes the claim.

This would not require CMS rulemaking. It would require MolDx leadership to value decisional finality as much as evidentiary rigor.

2. MolDx could publish test-category evidence templates

For categories like MRD, CGP, hereditary cancer, pharmacogenomics, infectious disease panels, transplant rejection, and Alzheimer’s biomarkers, MolDx could publish structured evidence templates. These would distinguish among analytical validity, clinical validity, clinical utility, intended-use population, comparator, outcome, intervention consequence, and minimum follow-up.

The point is not to lower standards. The point is to make standards previsible. Applicants should not discover the real standard through serial 60-day question letters.

3. CMS could require contractor performance metrics

CMS does not need to micromanage every technical assessment to require operational accountability. It could require reporting of median and 90th-percentile technical-assessment cycle time, number of pending applications by category, number pending over 180/365 days, number of approvals, number of denials, number of incomplete submissions, and reasons for delay.

This would convert stakeholder anecdote into governance data. If MolDx is performing well, the data will show it. If not, CMS will have evidence for corrective action.

4. CMS could create an escalation pathway for stalled molecular test reviews

There should be a defined escalation pathway when a test-specific review remains unresolved beyond a threshold. That pathway could involve Palmetto senior leadership, a multi-MAC MolDx oversight committee, or CMS coverage staff. The appeal should not be “please approve me.” It should be “please determine whether the process has become procedurally unreasonable.”

That distinction matters. CMS need not substitute its scientific judgment in every case. But CMS can supervise whether a contractor’s process is timely, clear, and administratively fair.

5. Associations could send a targeted operational letter, not a vague grievance letter

A lab association letter to HHS or CMS should avoid sounding like “we want easier coverage.” The stronger letter would say:

MolDx has become essential Medicare infrastructure, but its current operating model lacks transparent cycle times, closure rules, escalation pathways, and public performance metrics. We request CMS oversight of process reliability, not a weakening of evidence standards.

That is a more credible position. It preserves Medicare’s need for rigor while focusing on the real defect: operational accountability.

6. MolDx could separate scientific policy leadership from operations leadership

The program may need a visible chief operating officer function. Scientific leaders should set standards, review complex evidence, and speak externally. But someone else should own queue management, reviewer productivity, applicant communications, deadlines, dashboards, and backlog reduction.

In mature organizations, the best scientist is not automatically the best operating executive. MolDx may need both.

7. LCDs should be updated more often, but only where they reduce hidden review

More LCDs are not automatically better. A proliferation of LCDs could create even more bureaucracy. But when a category is generating dozens of applications and repeated review loops, that is a signal that the standard is not sufficiently public. In those areas, MolDx should either revise the LCD/article framework or publish detailed subregulatory guidance.

MRD is the obvious example. If many tests are seeking coverage for specific tumor types, surveillance settings, recurrence-risk scenarios, and therapy-monitoring claims, the program needs a transparent matrix. Otherwise, each application becomes a private negotiation over first principles.

8. CMS could nationalize certain high-impact categories

For areas like broad tumor CGP, MRD, or Alzheimer’s blood biomarkers, CMS may eventually need national coverage architecture. The NCD for NGS in cancer shows that CMS can intervene when a technology class becomes too important for fragmented local handling. The current NCD grew out of the rapid expansion of NGS oncology testing and FDA-approved companion diagnostics, with national policy taking shape around 2017–2018. (CMS)

The risk, however, is that NCDs can be rigid and slow. Nationalizing every molecular test category would be a mistake. A better approach may be selective: CMS should nationalize only those categories where MolDx’s quasi-national local process is producing high-stakes bottlenecks.

The core diagnosis

MolDx was built to solve a real Medicare problem, and for years it did. But the program appears to have evolved from an expert workaround into a de facto national molecular diagnostics infrastructure without a matching governance model.

The founding model was expert judgment. The mature model should have become transparent expert administration. Instead, the program may now sit awkwardly in between: too large for founder-style discretion, too opaque for national policy, too powerful for ordinary contractor informality, and too procedurally elastic for companies trying to bring specific tests through coverage.

The remedy is not simply “be nicer to labs” or “approve more tests.” Medicare must still reject weak evidence and control abuse. The remedy is to restore the basic features of a functioning public program: clear standards, defined timelines, consolidated questions, final decisions, public metrics, escalation rights, and accountable management.

In short, MolDx does not need less science. It needs more institution.

###

Sidebar: The current MolDx leader speaks frequently in praise of the management controls and protocols that have been developed over the last five years. Yet stakeholders have a very different conception of what they are experiencing "in real world." Discuss this situation and paths forward.

###

Sidebar: When “management controls” and stakeholder experience diverge

A striking feature of the current MolDx situation is the gap between internal managerial self-description and external stakeholder experience. Leadership may sincerely believe that the program has become more professional over the past five years: more protocols, more staff, more defined review steps, more documentation, more controls, more standardized evidence expectations, and more internal signoffs. From inside the program, that may look like maturation. From the outside, however, laboratories may experience the same apparatus as delay, opacity, repetitive questioning, moving targets, and no clear path to a final decision.

This is a familiar organizational failure mode. A process can become more controlled without becoming more effective. Indeed, in complex bureaucracies, controls can multiply precisely because performance is deteriorating. More forms are added because prior submissions were inconsistent. More review layers are added because decisions were controversial. More templates are added because reviewers asked different questions. More internal meetings are added because the organization wants alignment. Each addition may be rational in isolation. Taken together, they can produce a system that is more defensible on paper but less capable of delivering timely outcomes.

The key distinction is between process control and process performance. A leader may point to protocols: every file is logged, every question is documented, every review is assigned, every evidence domain is checked, every decision is internally vetted. Stakeholders are measuring something else: How long did it take? Were the standards clear at the start? Did the questions converge or expand? Did the reviewers understand the intended use? Did the program reach a decision? Was there an appealable rationale? Could the company plan around the result?

Both sides may be telling the truth. MolDx may indeed have more management controls than it had five years ago. And stakeholders may also be right that the real-world operating experience has worsened.

The deeper problem is that management controls often serve the organization before they serve the customer, applicant, beneficiary, or public mission. Internal controls reduce internal risk. They make the file look complete. They help defend against accusations of inconsistency. They allow leadership to say the process is rigorous. But if the controls do not also produce predictable cycle times, consolidated questions, clear endpoints, and final decisions, they are not a management system. They are a protective shell.

For MolDx, this distinction matters because the program is not merely an internal payer function. It is a gatekeeper for Medicare access to molecular diagnostics. A stalled technical assessment is not just an administrative inconvenience. It affects laboratory investment, clinical adoption, physician confidence, beneficiary access, and the credibility of Medicare’s coverage process. A review loop that feels internally rigorous may function externally as unannounced noncoverage by delay.

One path forward is for MolDx to redefine excellence around externally observable performance, not internal procedural sophistication. The program should not ask, “Do we have a protocol?” It should ask, “Does the protocol produce timely, consistent, explainable decisions?” That implies public or semi-public metrics: median time from complete submission to first response; median time from response to final decision; number of applications pending over 180 days; number pending over one year; number approved, denied, withdrawn, or still cycling; and the most common reasons for delay. Without such metrics, claims of good management remain largely self-referential.

A second path is to impose a consolidated-question discipline. Stakeholders complain most bitterly when questions expand over time: two pages, then six pages, then more. A mature review process should identify the core deficiencies early. There may be exceptions, especially when an applicant changes its intended-use claim or submits weak/confusing data. But the default should be one comprehensive request for additional information, one applicant response, and then a decision or a clearly defined final step. Endless rounds create the impression that MolDx itself does not know what standard it is applying.

A third path is to create decision closure categories. Not every test will be approved, and not every application deserves indefinite refinement. MolDx could use clearer endpoints: approved; denied because evidence is insufficient; not reviewable because intended use is unclear; deferred pending public LCD reconsideration; or held because a category-wide policy is under development. This would be far better than the current apparent limbo, where applicants may feel they are neither approved nor denied, but simply suspended.

A fourth path is to distinguish scientific disagreement from operational failure. Some stakeholder anger reflects disagreement with MolDx’s evidence standards. That is inevitable. Medicare should not cover every test a company believes is useful. But other anger reflects process pathology: unclear expectations, slow reviews, repeated questioning, and no final answer. MolDx should be willing to say, “We will not weaken our evidence standards, but we will improve the reliability and transparency of the process.” That would put the argument on firmer ground.

A fifth path is external oversight. Because MolDx has quasi-national importance, CMS should not treat complaints as ordinary contractor grumbling. CMS could require performance reporting, establish an escalation route for stalled reviews, audit technical-assessment cycle times, and ask whether broad LCDs plus private test-specific reviews are functioning as intended. This would not require CMS to approve individual tests. It would require CMS to supervise the fairness and efficiency of the contractor process.

Finally, industry should frame its response carefully. A letter saying “MolDx is too strict” is easy to dismiss. A letter saying “MolDx lacks transparent cycle times, decision endpoints, consolidated information requests, public performance metrics, and escalation procedures” is harder to ignore. The strongest critique is not that MolDx has standards. The strongest critique is that its standards are experienced as procedurally unstable and operationally indefinite.

The best summary is this: MolDx leadership may be proud of having built a more elaborate machine. Stakeholders are saying the machine does not reliably produce decisions. The path forward is not another layer of process, but a shift from control culture to performance culture: fewer loops, clearer standards, measurable timelines, accountable closure, and a public recognition that rigor without throughput is not good management.

##

The Wild West World of Digital Pathology Coding

 Many have heard the high level result on AMA CPT digital pathology coding:

1. For several years, PLA committee created 8-10 whole slide imaging codes.
2. Then they stopped. Either:
1. The slides included human reviewing, so PLA was "nix" due to physician work.
2. The slides were H&E, so PLA had "no new biomarker" to work with and refused to code.
3. In February and May 2026, AMA CPT began putting a few WSI codes (including H&E only) into Category III.

There are many nuances.

• Cat III CLFS Yes.  CMS may load the Cat III codes into the CLFS process (crosswalk gapfill) since FDA, CLIA, and CMS previously have categorized WSI as CLFS.  They have done this even under close review as ADLT.
• Cat III CLFS No.  CMS may NOT load the Cat Iii codes,
• Either because they no longer think they are CLFS, or
• Because Cat III codes are "temporary."
• There is little precedent for loading Cat III codes as CLFS, but CLFS tests have not been put into Cat III as may be happening.
• FDA WSI TEST = CODE TOO.  Under PAMA CMS (or AMA) is obligated to make new codes for FDA cleared or approved tests, so any given dig path code (assuming it is  CLFS) should demand a code, whether PLA or Cat III.
• Non destructive.  There is much less moat around glass slide algorithms, as imaging is non distrctive.  This is a huge difference from MAAA RNA tests built on disappearing and scarce FFPE archives from trials.
• Cat III not branded.  While PLA codes are proprietary (either to one lab or to one FDA mgfr), Cat III codse are NOT proprietary as long as another service fits the words of the code.
• CMAA?? Soon we will have a new AMA coding system CMAA and nobody knows the new rules.
• Broadband or Fed Ex?  Can Dig path assays be run on DICOM files are a new glass slide scanned?   
• The literature is confusing.  Some test 6 scanners and all work great on algorithm "X."  Some try 6 scanners and only the original validates the algorithm.  This is a big deal logistically.
• NCCN passed the Artera prostate FDA test.   What's next?  Breast?
• FDA online.  Artera Prostate has an online 24 page FDA review.    The new breast test will have that online in 1-3 months.  https://www.accessdata.fda.gov/cdrh_docs/reviews/DEN240068.pdf
• WSI as "non DOS."  If CMS doesn't class WSI as "a CLIA test" then the whole 14 day rule, DOS rule, doesn't apply and it's easy to unbundle as it is a local service by the generic DOS principal.

Harry Glorikian New Book on AI "Invisible Interface"

 TLDR — The Invisible Interface sample pages

https://www.simonandschuster.com/books/The-Invisible-Interface/Harry-Glorikian/9781646872480

Harry Glorikian’s The Invisible Interface argues that AI’s real business impact will not come from chatbots or better apps, but from a deeper interface shift: computing is moving from clicking and operating software to stating intent and letting AI orchestrate actions. The book’s central idea is the personal operating layer — or POL — an AI layer that sits between a person and their digital systems, remembers context, acts across tools, shows what it did, and remains under human control.

The opening example imagines a woman asking her system to book a cardiology visit, use her insurance plan, send labs, update calendars, message a colleague, suggest transportation, and log the whole workflow. The key point is not that AI answers a question. It executes a coordinated workflow. The “magic” is not silence alone; it is silence with guardrails, receipts, reversibility, and auditability.

Glorikian frames this as the next major interface transition after the command line, graphical desktop, web, mobile, and algorithmic feed. Each prior shift created new winners and stranded companies that judged the new era by old metrics. In this case, the winner may not be the company with the best visible app, but the one that owns the default layer of action, the trusted interface through which users delegate work.

The book distinguishes a POL from ordinary AI tools. A chatbot talks. A copilot helps inside one app. Robotic process automation follows brittle scripts. A true POL has persistent memory, cross-system reach, reasoning, transparency, and control. Glorikian offers a practical “smell test”: can the system Remember, Act, Show, and Stop? If not, it is probably a feature, not a platform.

The business implications are large. Much enterprise work is really coordination tax: gathering data, reconciling systems, routing decisions, documenting actions, and following up. A POL attacks that invisible overhead by turning workflows into intent. Instead of humans acting as the glue between email, calendars, CRM, documents, finance, and compliance systems, the machine does the scavenger hunt while humans retain judgment.

Glorikian is careful not to overstate current capabilities. As of 2026, he says most organizations are still between rule-based automation and intelligent assistance. The full open-world version of POL is not solved. But governed, narrow workflows are already plausible, and the strategic curve points toward more durable memory, more reliable action, better audit trails, and eventually portable agency.

The strategic warning is aimed at management and boards: this is not merely an IT upgrade. It is a fiduciary and competitive question. If customers can delegate outcomes through someone else’s trusted AI layer, then companies whose moats depend on complexity, clunky interfaces, or captive workflows may lose power. The core question becomes: Where does our business depend on friction, and what happens when that friction disappears?

###

###
Publisher Summary

I've had the opportunity to watch and experience decades of technology cycles eat industries that thought they were safe. Travel agencies didn't lose to better travel agencies. Bureau of Labor Statistics data shows travel agent employment dropped roughly 70 percent between 2000 and 2021 - not because travelers stopped traveling, but because a software layer got between the agent and the customer and never moved.

Banks didn't lose deposits to payment apps. The money stayed exactly where it was. What moved was the transaction moment - the behavioral data, the customer touchpoint, the ability to see and act on what customers do with their money in real time. The relationship didn't disappear. It became invisible to the bank that thought it owned it.

AI is doing the same thing. Right now. Across every industry simultaneously.

When Klarna reported in February 2024 that their AI assistant was handling the equivalent work of 700 customer service agents - two-thirds of all their customer service interactions - they weren't describing an efficiency gain. They were describing a customer relationship that had moved into a system that learns, compounds, and gets harder to displace every day. When Morgan Stanley announced that 98 percent of its financial advisor teams had adopted its AI assistant, they weren't describing a productivity tool. They were describing a new default - the layer every advisor now works through, every client interaction now flows across, every piece of institutional knowledge now passes through before it reaches a human hand.

That's not a technology story. That's a competitive architecture story.

The Invisible Interface is about what's at stake in that shift - and what separates the organizations that capture AI's value from the ones that fund it for everyone else.

The pattern holds across healthcare, financial services, and enterprise technology: most management teams are building AI strategies around capabilities that will commoditize. The model is not the moat. Data alone is not the moat - not when the models accessing it are available to everyone. The moat is whether your customers and your workforce delegate to your systems by habit - or someone else's. Once that habit forms, it compounds. Quietly. Structurally. In ways that don't show up in a quarterly review until it's too late.

This book gives boards and management teams - and those deciding where to place the next bet - the framework to get ahead of three questions most organizations aren't asking yet. Where are your defaults already being set by a competitor you haven't identified? What does it cost when a decision gets routed around you - competitively, operationally, and legally? And what specifically does it take to become the system people trust enough to delegate to?

Because delegation without accountability is its own risk. The organizations getting this right aren't just building capable AI systems. They're building systems their boards can govern, their regulators can audit, and their customers can trust when something goes wrong - and it will. That architecture is what creates durable advantage. Everything else is rented.

If you're treating AI as a faster version of what you already do, you've already misread the shift.

20260416 CMS PAMA CLASS - Audience Chat Questions Analyzed by AI

 

20260416 CMS CLASS ON PAMA

CHAT QUESTIONS (AI SUMMARY)

ORIGInAL CHAT AT BOTTOM

 

# # #

Below is an audience-question analysis of the CMS call’s chat/Q&A index. Since the file contains audience questions only, this is best read as a map of confusion, concern, operational friction, and perceived risk rather than a resolved CMS FAQ. Source:

 

# # #

Bottom-Line Interpretation

The audience’s core concern was not simply “how do we report?” It was “how do we know whether our particular organization is legally and operationally visible to CMS as an applicable laboratory?” The questions show a laboratory industry with highly varied billing models: physician offices, FQHCs, hospital outreach labs, independent labs, multi-hospital systems, CLIA-waived sites, ESRD labs, joint ventures, and specialty practices. CMS’s formal rules depend on NPI, TIN, CLFS revenue, PFS revenue, Medicare revenue, private payer rates, and final payment timing. The audience was trying to reconcile those formal categories with real revenue-cycle data.

The biggest unresolved puzzles were: what counts in the Medicare revenue denominator; whether Medicare Advantage counts; how to handle FQHC and hospital outreach structures; whether CLIA-waived or physician office labs are swept in; how to distinguish CLFS from PFS; what exact payer amount should be reported; and whether multiple private payer rates must be separately listed for each code. In short, the audience wanted practical boundary rules, worked examples, and source-of-truth links more than high-level statutory background.

 

 

# # #

Audience Q&A Analysis: What the Laboratory Community Was Worried About

The audience questions clustered around one central problem: labs were not primarily confused about how to type numbers into a CMS portal; they were confused about whether they were even in scope. The operational system questions were numerous, but the deepest anxiety concerned applicability: who must report, which revenues count, which billing structures matter, and how a lab can know with confidence that it is either included or excluded.

The most frequent theme was “Am I an applicable lab?” This came up in many forms: physician office labs, pediatric offices, FQHCs, hospital outreach labs, independent labs, CLIA-waived labs, ESRD/dialysis labs, pathology labs, GI anatomic pathology labs, urine drug testing labs, and labs embedded in larger organizations. The audience was trying to map CMS’s formal PAMA definition onto the messy real-world structures of billing NPIs, group practices, hospitals, joint ventures, and FQHC PPS arrangements. Many questions were not “what is the rule?” but rather “which version of my organization does the rule see?”

A major subtheme was CLIA-waived testing. Multiple participants asked whether a lab that only performs CLIA-waived tests, or that holds only a CLIA-waived certificate, must report. This suggests a widespread assumption that “simple” or low-complexity labs might be outside PAMA, and that CMS’s use of the word “laboratory” triggered concern among many small offices that do minimal testing. FQHCs and physician offices appeared especially worried about being pulled into a reporting regime designed, in their minds, for commercial clinical laboratories.

Another large cluster involved physician office laboratories and group practice billing. Many participants asked whether reporting applies when the lab has no unique laboratory NPI and bills under a physician group NPI, individual provider NPIs, or an organization NPI. These questions reveal a practical puzzle: CMS tells labs to start with the NPI, but many office-based labs do not experience themselves as freestanding entities. The audience was asking, in effect, whether the “lab” is the physical testing operation, the physician practice, the billing NPI, the TIN, or some combination.

The TIN-versus-NPI distinction was a major source of confusion. Participants asked whether applicability is reviewed at the TIN level, NPI level, lab level, hospital level, or system level. Multi-hospital systems asked whether each lab reports individually or whether the system submits collectively. Others asked what to do when they have both a lab NPI and an organization NPI. These questions show that the audience was struggling with the two-level architecture of the program: applicability seems to be tested at the NPI level, but reporting is organized at the TIN level. That is a naturally confusing structure, especially for large systems.

Hospital and hospital outreach billing questions formed another important cluster. Several questions focused on bill type 14X versus 13X/131/141, asking whether PAMA applies only to services billed on 14X claims or also to other outpatient hospital bill types. Others asked whether joint-venture lab services billed under hospital NPI and 14X still qualify if the lab’s Medicare revenue is below $12,500 or fails the 50% test. These questions suggest that hospital outreach labs were trying to understand whether CMS’s expanded definition captures them, and if so, how to isolate outreach lab economics from broader hospital Medicare revenue.

FQHCs were a visibly anxious audience segment. Questions asked whether FQHCs with CLIA-waived certificates must report, whether lab services billed under the FQHC’s primary group NPI are reportable, how FQHC PPS payments interact with fee-for-service lab payments, whether PPS revenue is excluded, and whether PPS and FFS revenue under different NPIs should be combined. The concern here is more than administrative. FQHCs operate under a payment model that does not map neatly onto conventional fee-for-service lab revenue. They were asking whether CMS intended to sweep them into PAMA reporting and, if so, how to calculate the denominator.

The 50% majority-of-Medicare-revenues test produced a large number of questions. Participants asked what “total Medicare revenues” means, whether it includes Medicare Advantage, Managed Medicare, Part A, Part B, Part D, beneficiary deductible/coinsurance, E&M revenue, inpatient revenue, emergency room revenue, PPS revenue, or only traditional Medicare fee-for-service. Several asked whether the 50% threshold is calculated across a TIN, across a 14X bill type, across an NPI, or across the whole hospital. These questions show that the denominator was probably the single most conceptually difficult calculation for the audience.

Relatedly, the $12,500 low-expenditure threshold caused uncertainty. Participants asked whether the threshold applies to the January 1–June 30, 2025 period, whether it is evaluated after the 50% test, and whether the three applicability criteria are mutually exclusive or cumulative. One question asked, “If we don’t meet the 50% threshold but we meet the $12,500, do we qualify?” This reveals a common misunderstanding: many attendees were not sure whether the criteria are a sequence of gates, independent triggers, or alternative ways to become reportable.

There was also substantial confusion about the time period. Several questions asked whether the data collection period is based on payment date, date of service, billed date, performance date, or a full calendar year. Others asked what revenue time frame should be used for determining qualification. This indicates that the audience understood there were two related but distinct temporal questions: first, the period for assessing applicability, and second, the period for reporting private payer rates. Both appear to have been unclear to many participants.

Another major area was what payment amount to report. Attendees asked whether the private payer rate means the payer’s allowed amount, the actual amount paid by the payer, the patient portion, the combined payer-plus-patient allowed amount, denied claims, primary payer amounts only, or secondary payments as well. This is a critical business question because claims systems may store “payment,” “allowed,” “contracted,” “write-off,” and “patient responsibility” differently. The audience was signaling that the term “private payer rate” is not self-executing in revenue cycle data.

Many participants were puzzled by multiple rates for the same code. One attendee asked whether, if they have 150 payers, they must report 150 different rates for a single HCPCS code. Another asked what rate to consider when the same HCPCS code is paid by multiple private payers. These questions suggest that the audience was still thinking in terms of a single rate per code, whereas PAMA requires rate-volume observations by private payer rate. This is a fundamental conceptual shift from ordinary fee schedule thinking.

The audience also had questions about which codes are reportable. Participants asked whether CMS means CPT codes or HCPCS codes, whether specific codes such as 83861, 87798, 80307, and 80305 are included, and where to find the official HCPCS list. The repeated requests for a direct link to the code list suggest that the webinar may have described the existence of the list without enough navigational clarity for a large audience trying to follow in real time.

There was a distinct cluster around CLFS versus PFS. Audience members asked for the difference between the Medicare Clinical Laboratory Fee Schedule and the Medicare Physician Fee Schedule, whether PFS revenue means only lab-related PFS revenue, and whether PFS codes should be reported. This is an important conceptual puzzle because the PFS matters for the applicability test but not for the data submission. That split is unintuitive and likely produced much of the confusion.

Several questions dealt with global, case-rate, bundled, or non-separately reimbursed services. One participant asked what to do when contracts are case-rate or global and the lab is reimbursed for E&M codes rather than all services provided. This is a sophisticated concern: many payment arrangements do not produce a clean payer-specific payment amount for each lab HCPCS code. Such arrangements create practical ambiguity about whether there is a reportable “private payer rate” at the test-code level.

The audience also asked about Medicare Advantage and Managed Medicare repeatedly. These questions appeared both in the applicability context and in revenue calculation. Participants wanted to know whether MA revenue counts as Medicare revenue, whether it belongs in the 50% threshold, and whether it belongs in the denominator. This is a predictable concern because operationally many labs treat Medicare Advantage as Medicare-like, but legally and for PAMA purposes, “Medicare revenues” may have a more specific meaning.

There were several questions about what to do if not applicable. Attendees asked whether labs that do not qualify must notify CMS, whether they must submit a “not applicable” report, and whether a non-applicable lab may voluntarily report. This suggests fear of noncompliance by omission. For many organizations, the compliance instinct is to document exclusion affirmatively, and the absence of a “no report required” filing creates uncertainty.

There were operational questions about registration, portal access, and user roles. Participants asked for the registration link, portal link, whether IDM access through PECOS or NGS Connex works, whether there is a registration deadline, whether two practices require separate logins, and whether there will be step-by-step upload instructions. These questions are less conceptual but show that attendees anticipated friction with CMS identity management and role assignment.

The submitter/certifier model generated its own questions. Participants asked whether the submitter and certifier can be the same person, whether employees of the TIN/NPI can serve, what organizational level is required for the certifier, whether the certifier must be a clinician, and whether the same individuals can serve in roles for different TINs. This indicates concern about governance, accountability, and internal delegation. Smaller practices likely worried they may not have enough administrative separation; larger systems worried about who has authority to certify.

Data template questions were fewer but important. Participants asked whether payer plan names must be listed, whether the template should include only tests performed in the lab, and how to list multiple private payer rates for the same HCPCS code. These questions suggest that audience members were beginning to translate the rule into a spreadsheet workflow and immediately saw gaps between CMS’s four-column template and the richer data structures in billing systems.

Several attendees asked about data sources for thresholds, especially whether PS&R reports or specific 145 reports could be used to determine applicability. This reflects a practical compliance concern: labs wanted an auditable source of Medicare revenue numbers. In other words, they were not just asking how to calculate the test; they were asking what documentary basis would satisfy a compliance review.

There were also questions about database transparency and market intelligence. One attendee asked whether participating labs would have access to the entire database of reported data by test, lab, and payer for analysis. This is an interesting business concern because PAMA data reporting is not merely a compliance burden; it is also potentially a massive private payer price dataset. The question suggests that at least some participants were thinking about whether the burden of reporting would yield usable market information in return.

A smaller but notable cluster involved closed laboratories and changed business circumstances, although this topic appears more clearly in the live Q&A than in the chat index. The underlying concern is likely whether reporting obligations survive closure, acquisition, restructuring, or changes in lab identity. This fits the broader pattern: participants were worried about how PAMA applies to organizations that do not fit the simple model of a single independent lab with one TIN, one NPI, and clean payer contracts.

Finally, there were many logistical and webinar-access questions: whether the slides would be shared, whether the recording would be posted, whether the session had started, where the website is, and repeated complaints that audio was too low or cutting in and out. These are not substantive PAMA issues, but they matter because they likely intensified confusion. A topic already dense with definitions, thresholds, billing structures, and dates was being delivered in a setting where many participants could not hear clearly or could not locate the resources being described.

Bottom-Line Interpretation

The audience’s core concern was not simply “how do we report?” It was “how do we know whether our particular organization is legally and operationally visible to CMS as an applicable laboratory?” The questions show a laboratory industry with highly varied billing models: physician offices, FQHCs, hospital outreach labs, independent labs, multi-hospital systems, CLIA-waived sites, ESRD labs, joint ventures, and specialty practices. CMS’s formal rules depend on NPI, TIN, CLFS revenue, PFS revenue, Medicare revenue, private payer rates, and final payment timing. The audience was trying to reconcile those formal categories with real revenue-cycle data.

The biggest unresolved puzzles were: what counts in the Medicare revenue denominator; whether Medicare Advantage counts; how to handle FQHC and hospital outreach structures; whether CLIA-waived or physician office labs are swept in; how to distinguish CLFS from PFS; what exact payer amount should be reported; and whether multiple private payer rates must be separately listed for each code. In short, the audience wanted practical boundary rules, worked examples, and source-of-truth links more than high-level statutory background.

 

 

20260416 PAMA Education Session at CMS / Bruce Docu Blog

20260416 PAMA education at CMS

###

This is a second set of notes - see main DIHP blog for my initial posting of detailed notes plus links to powerpoints etc.

###

 COPY SUMMARY

20260416 CMS PAMA 1 hr

Transcript

https://otter.ai/u/rRD0iboaRruzWyADpiS0CDoyG3c?view=summary

Overview (Notes from OTTER)

The webinar, led by Sarah Shiri losso and Sarah Harding from CMS, focused on the Clinical Laboratory Fee Schedule (CLFS) data collection and reporting process. The session covered the importance of the data for future Medicare payment rates, the updated data collection period from January 1, 2025, to June 30, 2025, and the need for applicable labs to report applicable information. Key steps include verifying lab status, registering submitters and certifiers, preparing data using the provided template, and submitting data via the CMS Enterprise Portal. The webinar also addressed common questions and provided resources for further assistance.

Action Items

• [ ] Post the recording of today’s CLFS/PAMA training webinar to the CLFS and PAMA reporting resources website immediately after the session ends.
• [ ] Respond to any outstanding questions submitted via the CLFS inquiries email address after the webinar, ensuring that all unanswered questions are addressed.
• [ ] Create and upload additional step-by-step user guide materials and short "YouTube-style" videos for submitter and certifier roles in the CLFS data collection system within the next few days.
• [ ] Publish quick reference guides on how to determine applicable laboratory status on the CLFS and PAMA reporting resources website.

Outline

Introduction and Overview of the Webinar

• Sarah Shiri losso introduces herself as the director of ambulatory services at CMS and welcomes participants to the webinar on the clinical laboratory fee schedule data collection system.
• The webinar is being recorded and will be posted on the CLFS and PAMA reporting Resources website.
• Participants are encouraged to use the Q&A button for questions, and frequently asked questions will be addressed during the second half of the session.
• Sarah Harding, the CMS Medicare policy lead on laboratory payment under Medicare, will provide an overview of the program and the CLFS data collection system.

Background and Purpose of the Webinar

• Sarah Harding explains the purpose of the webinar, which is to help participants prepare to register, submit accurate data, and understand the system and resources available.
• The webinar is focused on clearing up definitions and providing detailed instructions on the data collection process.
• The data collection period is from January 1, 2025, to June 30, 2025, and the data will be used to update Medicare clinical lab fee schedule payment rates for 2027 through 2029.
• The webinar aims to address common questions and provide resources to assist participants in the data collection process.

Detailed Instructions on Data Collection and Reporting

• Sarah Harding provides a detailed explanation of the data collection process, including the types of information that need to be reported.
• The data collection system includes the CMS Enterprise Portal, which hosts all CMS applications, and the fee for service data collection system.
• Participants need to verify their laboratory's applicable status and identify two individuals responsible for the data submission process.
• The data collection template is available online, and participants are advised not to make any changes to the template to avoid rejection.

Steps for Determining Applicable Laboratory Status

• Sarah Harding outlines the steps for determining whether a laboratory is an applicable laboratory, including evaluating the majority of Medicare revenues and calculating the threshold.
• The data collection period is from January 1, 2025, to June 30, 2025, and the data will be used to update Medicare clinical lab fee schedule payment rates for 2027 through 2029.
• Participants are advised to consult the CLFS and PAMA reporting Resources website for additional resources and guidance.
• The webinar includes detailed instructions on the data collection process, including the steps for registering, preparing data, and submitting data.

Q&A Session and Additional Resources

• Maria Durham provides a summary of key dates and upcoming tasks, including the deadline for data submission on July 31, 2026.
• Participants are encouraged to visit the CLFS and PAMA reporting Resources website for all available resources, including registration guides, user guides, and reporting templates.
• The webinar includes a Q&A session to address common questions and provide additional clarification on the data collection process.
• Participants are advised to contact the CLFS Help Desk for technical assistance and the CLFS mailbox for all other inquiries.

#####

NOTES FROM ChAT GPT

Below are detailed business meeting notes from the CMS education webinar on Clinical Laboratory Fee Schedule / PAMA private payer data reporting. Source transcript:

CMS Education Webinar Notes: CLFS / PAMA Laboratory Price Reporting

CMS opened the session by welcoming laboratory stakeholders to a training webinar on the Clinical Laboratory Fee Schedule data collection system and the associated PAMA reporting requirements. CMS noted that the high level of stakeholder interest had required a midstream platform change to increase webinar capacity. The session was recorded and CMS stated that the recording would be posted to the CLFS and PAMA reporting resources website. Participants were encouraged to use the webinar Q&A function, and CMS noted that many questions had already been received through the CLFS mailbox. CMS emphasized that the purpose of the session was to help laboratories understand the reporting requirement, determine whether they are “applicable laboratories,” prepare to register in the system, submit accurate data, and use available CMS resources.

CMS explained that the statutory basis for the reporting requirement is Section 1834A of the Social Security Act, established by Section 216 of the Protecting Access to Medicare Act of 2014, commonly referred to as PAMA. Under PAMA, applicable laboratories must report certain private payer information to CMS for clinical diagnostic laboratory tests paid under the Medicare CLFS. CMS noted that the first round of PAMA data collection and reporting occurred in 2017, and that for many laboratories and even some CMS staff, this current round may feel like a new process because there has been no reporting cycle for many years. CMS attributed the delay to a series of statutory delays and pandemic-related interruptions.

CMS highlighted an important recent legislative update. The Consolidated Appropriations Act enacted February 3, 2026, updated the reporting period and the relevant data collection period. CMS explained that prior delays had created concern that the next CLFS rates could be based on 2019 data, which by the 2027–2029 rate cycle would have been roughly ten years old. Congress therefore updated the data collection period to require laboratories to report private payer data from January 1, 2025 through June 30, 2025. CMS emphasized that this updated six-month window is the period from which applicable information must be drawn.

CMS defined the core item being collected as “applicable information.” This includes, for each relevant HCPCS code on the CLFS, the private payer rate for which final payment was made during the January–June 2025 data collection period, along with the associated test volume corresponding to that specific rate. CMS stressed repeatedly that laboratories should report each distinct private payer rate separately. If a lab receives multiple different rates for the same HCPCS code, each rate should be reported on a separate line with the volume associated with that specific rate. CMS was explicit that laboratories should not average rates, should not report only the highest or lowest rate, and should not report total expenditures for a code during the collection period. The agency wants the individual rate-and-volume pairings because those data are used to calculate future Medicare CLFS payment rates.

CMS advised laboratories to benchmark suspicious values against the existing Medicare CLFS. For example, if a lab’s internal data show a private payer rate of $1,000 for a test that Medicare pays at $10, the lab should review whether the data were extracted or formatted correctly. CMS also noted that the upload system has built-in warnings for rates that appear implausibly high, such as a value that may represent total expenditures rather than a single payment rate. These warnings are intended to prompt review before certification.

CMS then described the data reporting infrastructure. Reporting begins with the CMS Enterprise Portal, which is CMS’s broader system for accessing CMS applications. Users who already have a CMS Enterprise Portal account may be able to use their existing username and password. Within the Enterprise Portal, users must access the Fee-for-Service Data Collection System, or FFS DCS, which contains several data collection modules. Laboratories must select the Clinical Laboratory Fee Schedule module, not other modules such as ASP or ground ambulance reporting. CMS acknowledged that users may see internal roles such as CLFS admin or CLFS staff, but external laboratory users should request only the submitter or certifier role.

The first substantive step for laboratories is to determine whether they are an applicable laboratory. CMS described this as the “million dollar question” and emphasized that applicability is determined at the NPI level, while reporting is organized at the TIN level. An applicable laboratory must bill Medicare Part B either under its own National Provider Identifier, or, in the case of certain hospital outreach laboratories, on the Form CMS-1450 under bill type 14X. CMS emphasized that laboratory business structures can be complex, including shared NPIs, shared physician office arrangements, and hospital outreach relationships, but the legal analysis begins with the billing NPI or 14X bill type.

CMS described the majority of Medicare revenues threshold. For a laboratory with its own NPI, the lab must calculate whether its Medicare CLFS revenue plus Medicare Physician Fee Schedule revenue, divided by its total Medicare revenue, exceeds 50 percent during the January–June 2025 data collection period. CMS emphasized an important distinction: PFS revenue is included in the applicability calculation, but PFS codes are not included in the data reported to CMS. Only CLFS codes are reported. If a laboratory attempts to upload Physician Fee Schedule codes, the upload will be rejected.

CMS also discussed the low expenditure threshold. Even if a laboratory meets the majority-of-Medicare-revenue test, it is not considered an applicable laboratory if its Medicare CLFS revenue for the relevant billing NPI is less than $12,500 during the six-month data collection period. CMS explained that this threshold was intended to reduce the reporting burden on laboratories with limited CLFS activity.

CMS separately addressed hospital outreach laboratories that bill under the hospital’s NPI using 14X type of bill. CMS explained that this was an expansion of the applicable laboratory definition compared with the first PAMA reporting cycle. For hospital outreach laboratories in this category, the numerator is CLFS plus PFS revenue under the 14X bill type, and the denominator is total Medicare revenue under the 14X bill type. CMS observed that many such outreach labs are likely to meet the majority-of-Medicare-revenue threshold because the relevant 14X Medicare revenue may consist primarily, or entirely, of CLFS and/or PFS services.

CMS emphasized that it cannot make individual applicability determinations for specific laboratories. The agency explained that it may not have sufficiently current or complete information about each laboratory’s billing structure, ownership, revenue, NPI relationships, or business model. CMS therefore expects laboratories to make a good faith determination using CMS guidance and, where needed, legal counsel. CMS pointed attendees to FAQs, flow charts, quick reference guides, videos, and other materials on the CLFS and PAMA reporting resources website. CMS specifically mentioned that several FAQ pages address physician office laboratories with shared offices, shared spaces, and shared NPIs.

The webinar then turned to user roles. Each reporting entity must identify two separate individuals: a submitter and a certifier. The submitter is selected by the laboratory, creates or uses an account in the CMS Enterprise Portal, requests the submitter role in the CLFS module, uploads the data on behalf of the relevant TIN, and notifies the certifier once data have been submitted. There can be only one submitter per TIN, although one individual may submit data for multiple TINs. The certifier must be the laboratory’s president, CFO, or an individual designated by one of those officers. The certifier creates or uses an Enterprise Portal account, requests the certifier role, reviews the submitted data, and attests to its accuracy. There can be only one certifier per TIN, and the certifier may certify on behalf of multiple TINs. CMS stressed that the submitter and certifier must be two different people.

CMS explained that submitters and certifiers must complete identity management registration through CMS’s identity verification process. Users must create a username and password, establish multifactor authentication, request access to the FFS DCS application, and request the appropriate CLFS module role. CMS advised users to use their personal identifying information during identity verification rather than business information, because the identity management system is designed for personal credentialing and business information may cause delays. CMS stated that the CLFS policy team does not see this personal information; it is maintained within CMS’s broader enterprise identity system.

CMS then described the data preparation process. Laboratories should first review the CMS-provided list of reportable HCPCS codes on the CLFS. Labs should not report codes that are not on that list, including codes paid under the Physician Fee Schedule. Laboratories should then calculate, for each CLFS HCPCS code, each distinct private payer rate for which final payment was made during the January–June 2025 data collection period, along with the volume of tests paid at that rate. CMS emphasized that laboratories should not include blank rows, should not report codes they do not perform, and should not submit empty line items.

CMS presented the data reporting template, which consists of four data columns: HCPCS code, payment rate, test volume, and NPI. CMS emphasized several times that laboratories must not alter the Excel template. They should not change the formatting, add columns, remove columns, delete tabs, move tabs, insert blank rows, or otherwise modify the structure. CMS stated that modified templates may be rejected by the upload system. The template includes an instruction tab and a data entry tab, both of which must remain intact.

CMS explained that the same HCPCS code may appear repeatedly in the template if the laboratory received multiple private payer rates for that code. This repetition is expected and appropriate. CMS also clarified a somewhat counterintuitive NPI issue. Applicability is determined at the NPI level, and submitters must register all NPIs for which they are reporting. However, once the laboratory reports at the TIN level, CMS allows the data to be aggregated under a single representative NPI within the TIN. In other words, the NPI column in the data template does not need to identify the specific NPI associated with each data row, as long as all NPIs included in the reporting have been registered in the system.

CMS advised laboratories to prepare and review the data outside the CMS system before uploading. CMS specifically recommended that the certifier pre-review the completed template before formal upload, because this may reduce the need for corrections later. If the system identifies formatting errors, the submitter—not the certifier—must correct them. If the certifier identifies substantive errors after receiving the data, the submitter must log back into the system and correct the file before final certification.

CMS described the submitter workflow. After logging into the CMS Enterprise Portal and accessing the FFS DCS application, the submitter selects the CLFS module. The submitter’s home page includes a business process flow. The submitter must associate the laboratory TIN with the relevant NPI information, upload the data file using the provided template, and generate a one-time password for the certifier. This one-time password links the certifier to the submitted data and is intended as a security measure to ensure that only the appropriate certifier can view and certify the submission.

CMS described the certifier workflow. The certifier logs into the system, associates themselves with the relevant TIN and NPI information, enters the one-time password provided by the submitter, reviews the data, and certifies its accuracy. Certification must occur inside the CMS data collection system. CMS stated that a laboratory cannot certify its data by emailing CMS or the CLFS inquiries mailbox. Reporting is not complete until certification is completed in the system. Once data are certified, the submission is closed, and the laboratory will no longer be able to enter additional data for that TIN or view the data in the system. If corrections are needed after certification, the laboratory must contact the CLFS help desk.

CMS then reviewed key dates. Laboratories can begin determining applicable lab status, selecting submitters and certifiers, and preparing their data immediately. Submitters and certifiers can create CMS Enterprise Portal accounts now. The CLFS reporting link becomes available in the FFS DCS application tile on May 1, 2026, and submitters can begin uploading data at that time. All submissions are due by 11:59 p.m. Eastern Time on July 31, 2026. CMS strongly advised laboratories not to wait until the deadline. After the reporting window closes, CMS will analyze the data during summer 2026. CMS also noted that a public meeting and a FACA meeting will occur later in 2026, with proposed and final payment determinations in fall 2026. The resulting CLFS payment rates will be effective January 1, 2027.

CMS reviewed available resources. The CLFS and PAMA reporting resources website includes registration guides, submitter and certifier user guides, the HCPCS code list, reporting templates, system videos, FAQs, quick reference guides on applicable laboratory status, and forthcoming fact sheets. CMS noted that it has received a high volume of questions and is turning recurring questions into fact sheets in real time. CMS also described outreach efforts, including certified letters sent in March to potentially applicable laboratories, email communications, MLN Connects articles, social media posts, and engagement with professional organizations such as AACC, NILA, CLC, AAFP, AMA, PACDA, and MGMA. CMS encouraged laboratories that belong to these organizations to seek additional help and resources through them.

During the Q&A, CMS clarified that total Medicare revenues, for purposes of the denominator in the majority-of-Medicare-revenues test, means the sum of all Medicare fee-for-service payments under Parts A and B, prescription drug payments under Part D, and associated Medicare beneficiary deductible or coinsurance for services furnished during the collection period. However, for hospital outreach laboratories determining applicability under the 14X type of bill, the denominator is total Medicare revenue under the 14X bill type.

CMS clarified that the data collection period is based on the date final payment was made, not the date of service. Therefore, laboratories should report private payer rates for which final payment occurred between January 1 and June 30, 2025, regardless of whether the underlying service date occurred earlier.

CMS reiterated during Q&A that it cannot tell an individual laboratory whether it is an applicable lab. The agency stated that laboratories must make their own good faith determinations because applicability depends on entity-specific billing structure, revenue data, and operational information that CMS may not possess. CMS recommended that laboratories consult legal counsel if uncertainty remains after reviewing CMS guidance.

CMS was asked whether a laboratory that has closed must report. CMS responded that under the regulation at 42 CFR § 414, a reporting entity must report applicable information for each clinical diagnostic laboratory test furnished by its component applicable laboratories during the corresponding data collection period. CMS did not provide a definitive blanket answer for closed laboratories and recommended that such laboratories consult legal counsel to determine whether they must report.

CMS also clarified that laboratories that are not applicable laboratories should not report. In response to another question, CMS stated that CLIA-waived laboratories are not categorically exempt from the reporting requirement. A laboratory that performs only CLIA-waived tests must still evaluate whether it meets the applicable laboratory definition using the same steps described in the webinar.

Overall, the webinar’s main operational message was that laboratories should begin early, determine applicability carefully at the NPI level, identify separate submitter and certifier roles at the TIN level, use CMS’s unmodified reporting template, report each distinct private payer rate and associated volume separately, avoid including non-CLFS codes, and complete both upload and certification before the July 31, 2026 deadline. CMS repeatedly emphasized that most mistakes can be avoided by using the official template, consulting the HCPCS code list, reviewing CMS’s published FAQs and guides, and allowing enough time before the deadline to address registration, formatting, identity verification, and data correction issues.