Who asks it what, and why one database instead of six.

Written for manufacturers. Every question below is answerable from public sources — once the organizations behind them have been resolved to each other and held over time. The examples are illustrative of question shape, not extracts of any client's data.

Eight desks, one record.

Each of these teams currently answers its own questions from its own sources, with its own idea of what an account is. They disagree, and nobody can reconcile them, because none of the underlying identifiers match.

Market accessCHANNEL AND TRADE

  • Which covered entities added child sites in the last four quarters, and where?
  • What is our contract pharmacy exposure, rolled to corporate parent rather than site?
  • Which entities registered, terminated, or re-registered this quarter?
  • Which nongovernmental hospitals depend on a government contract for eligibility, and who is the counterparty?
  • Which entities are approaching the disproportionate share threshold from either direction?

WHY UNIFIEDExposure is a parent-level question answered from site-level sources. Without a resolved corporate hierarchy you are summing rows that may double-count one system and miss another entirely.

LegalLITIGATION AND DISCOVERY

  • What was this entity's registered status on the date in question?
  • What did it certify, on what date, and which cost reporting period did it name?
  • Which entities held which arrangements during a proposed class period?
  • Is this pattern isolated to one entity or systematic across the state?

WHY UNIFIEDA dated fact assembled in-house is a party document, created for the matter, with a methodology opposing counsel will characterise as self-serving. A third-party record built to a published methodology, before the question arose, for buyers with opposing interests, is a different object.

CompliancePROGRAM INTEGRITY

  • Was this arrangement listed on the date of the transaction we are reviewing?
  • Was the entity carved in or carved out of Medicaid on the dispense date?
  • Which of our policy exemptions map to entities whose status has since changed?
  • Where did a registry listing lapse and return, and over what interval?

WHY UNIFIEDEvery one of these is a question about a past date against a source that publishes only today and overwrites. Today's registry gives a confident wrong answer to all four.

Government affairsPOLICY AND STATE STRATEGY

  • Which entities in this state would be affected by the proposed access mandate?
  • How has participation in this state changed over the period under debate?
  • What does the record show about growth, and what can we evidence in a comment letter?

WHY UNIFIEDPolicy arguments are attacked at the data layer first. A cited figure whose provenance runs to a worksheet line survives a hearing; one whose provenance runs to an internal spreadsheet does not.

Commercial analyticsFORECASTING AND TERRITORY

  • What is the corporate rollup for this account, and when did it last change?
  • Which sites of care sit under which parent, at what scale?
  • Which accounts in the model refer to organizations that no longer exist under that name?

WHY UNIFIEDThis is the background-data case. Load persistent organization identifiers beneath the CRM, the forecast and the territory model and all three finally agree on what an account is — and every derived number traces back to a filing.

FinanceGROSS-TO-NET AND ACCRUAL

  • What is our channel exposure by entity class and by parent?
  • Which chargebacks reference entities or arrangements whose status we cannot verify for the transaction date?
  • How has the eligible population moved over the accrual period?

WHY UNIFIEDAn accrual assumption is only as defensible as the population count behind it, and that count moves daily in a source nobody archives.

Medical affairsSITE AND INSTITUTION

  • Which institutions treat this population, at what scale, under what ownership?
  • Where does federal research funding concentrate, and at which affiliated parent?
  • What is the actual legal entity behind this site, for engagement and transparency reporting?

WHY UNIFIEDTransparency reporting attaches to a legal entity. Engagement happens at a site. Those are different objects and the mismatch between them is a recurring reporting defect.

Corporate developmentSTRUCTURE AND CONSOLIDATION

  • Which systems have consolidated, and when did the registry reflect it?
  • Where is there real-estate or management-company exposure behind a nonprofit facade?
  • Did an organization's reported behaviour change after a transaction closed?

WHY UNIFIEDThe transaction is in one filing system, the consequences in another, and the lag between them is only visible if both are held on one timeline.

What goes wrong without it.

Two failures from our own build. Both are the kind that produce a confident answer, which is what makes them worth showing.

worked example — resolution

Two sources agreed. Both were right. The answer was wrong.

A hospital pricing file was resolved to a different hospital, in a different town, and labelled corroborated — the highest confidence tier available. Two independent identifiers had voted for the same answer.

Both votes came from the file's system-level identifiers. Both were accurate assertions about a health system. Neither was an assertion about a facility, which is what the question had asked. Two system-level votes outnumbered one correct facility-level vote.

Scoring agreement across mismatched levels manufactures confidence rather than measuring it — and the manufactured answer carries the highest label. That is worse than an unresolved answer, because an unresolved answer announces itself.

The fix was to the specification, not the code. An implementation could follow the original spec exactly and still be wrong. In a measured comparison on a 29-hospital cohort, name-and-address matching disagreed with the identifier route in 13% of cases where both fired, with the identifier route correct every time. That cohort is non-random and unusually compliant; treat the figure as illustrative of the mechanism, not as a population estimate.

worked example — the dated fact

A listing present on the 2nd, absent on the 3rd, and gone forever by the 5th.

A contract pharmacy arrangement appears in the registry one day and not the next. The registry publishes only current state, so by the time anyone reviews a transaction from that week, the arrangement simply does not exist and never visibly did.

With the record held, the statement becomes precise: on the 5th this pharmacy was not listed for this entity, and the listing ceased sometime between the 2nd and the 3rd. Not a date — an interval, because the source overwrites and we observe states rather than events.

That interval is the factual predicate. It is not a conclusion about any transaction, and we do not offer one. It is the fact neither party can currently establish, and both need.

This is also the case for daily rather than weekly capture. Daily bounds the change to a day. Weekly bounds it to a week — and loses entirely any listing that appeared and disappeared inside it.

Connecting it to your own models.

You already have an assistant, a copilot, or an internal agent. The reason it produces confidently wrong answers about healthcare organizations is not the model. It is that licensed data ships numbers without semantics. Every value in our feed carries a Sourceprint™ instead — the unit, grain, source line, period, observation date, null semantics and do-not-conclude statement, travelling with the number.

A field arrives as a column header and a value. Nothing tells the model that the number is a cost rather than a charge, that it is reported per fiscal year rather than per quarter, that a blank means the filer never filed rather than that the figure was zero, or that the adjacent column overlaps with it and the two must never be summed. The model fills those gaps the way models do — plausibly.

Every field in the feed carries that missing layer as its Sourceprint™. Unit, grain, source form and line, the period it describes, the capture it came from, what a blank means, and an explicit statement of what not to conclude from it. That is the part that turns retrieval into something a reviewer will sign.

It is a method, not a document dumpINTEGRATION

Your model calls the feed the way it calls any other tool — resolve an organization, fetch a field, pull a time series, list what changed. Constrained parameters rather than free-text query, so the model cannot ask for something the data cannot support.

Answers arrive pre-citedREVIEW

The citation comes back with the value, in a form your reviewers already accept — form, worksheet, line, period, observation date. An unsourced number cannot leave a regulated company. A pre-sourced one goes straight into the deck.

Never a silent matchRESOLUTION

The resolver returns candidates with confidence, not a single guess. Unresolved is a valid answer the model is expected to report rather than paper over.

Reproducible after the factAUDIT

Every answer names the capture behind it, so any past answer can be re-run and re-derived. Your team owns that audit trail; we never see the questions.

Your prompts do not rotSTABILITY

Field names never change meaning — they are only added to, and a rename ships as an alias with an overlap window. Work you build on the vocabulary keeps working.

We can supply an evaluation set: questions with known-correct answers and citations, including the ones designed to fail — overlapping fields, mismatched grain, blanks that are not zeros, and questions whose correct answer is that the data cannot support one. Run it against your current stack and against ours, in your environment, and compare. Nothing leaves your network.

Questions we get asked.

THE DATA

Is any of this proprietary or licensed from a third party?
No. Every input is a public filing or a public record. That means no upstream vendor can restrict how you use what you receive, and no exclusivity conflicts arise. The proprietary part is the construction — the resolution, the verified field addresses, the temporal record and the metadata.
If it is all public, why can't we assemble it ourselves?
You can. Three things make it expensive rather than impossible. The identifiers do not match and resolving them is the actual work. The field addresses are easy to get wrong in ways that produce plausible output — in our own build, most of an initial cost-report mapping was wrong and every figure looked reasonable. And the temporal record cannot be assembled retroactively at all: a team starting in January holds nothing from December.
What can't it answer?
Acquisition price paid by a specific entity. Per-prescription dispensing at prescriber level. Rebate flow through a specific contract. Anything at patient level. None of these exist in the public record at any price, and a vendor claiming them is inferring or has a source they should not have. We publish this boundary rather than leaving you to discover it.
How far back does the record go?
It depends on the source. Filings that agencies retain — cost reports, 990s, securities filings — go back as far as the agency publishes. The registry record begins on the first day we captured it, because nothing earlier exists anywhere retrievable. We state the start date rather than implying continuity we do not have.

SECURITY AND POSTURE

What data of ours do you hold?
None. The feed is built outward from public sources and delivered to you. We do not ingest client data, which means there is nothing of yours to leak, and your query patterns do not reveal what you are working on. It also removes most of what a security review is normally looking for.
Do you sell to organizations on the other side of our disputes?
The substrate is the same for every buyer and is not tuned to anyone's question. That is deliberate. A record built for one party's argument is worth nothing as evidence, and a record built for none of them is worth something to all of them. Commissioned analysis, if any, is kept structurally separate from the shared record.
Would we be exposed by the way you collect this?
Collection happens from our infrastructure, not yours. Records requests are filed in our name for research purposes, which matters more than it sounds — a request made by a party to a dispute creates a discoverable record of what that party was looking for and when.

COMMERCIAL

How is it priced?
An annual subscription to the feed, with onboarding into your environment. Not metered by entity, query or seat — metering the universe would turn a discovery tool into a confirmation tool, since you would have to know what to look at before you could look. Records-request coverage is scoped separately.
Can we evaluate it before committing?
Yes. A short, read-only evaluation against a frozen snapshot, with the success criterion agreed before it starts, using the evaluation set described above. Access expires at the end of the window unless converted.
What happens to what we built if we stop subscribing?
You keep what you have and it stops being current. That is the honest shape of the product: what renews is fidelity to a world that keeps changing, not access to a file.
Can we redistribute or embed the outputs?
Internal use and internal derived work are covered. External publication and redistribution are scoped in the agreement — mostly so that anything published carries its provenance intact, which protects both of us.

METHOD

How do you decide two records are the same organization?
From the organizations' own filings — the address on a cost report, the parent named in a 990, the identifier encoded in a pricing file. Every link records which source asserted it, on what date, and at what level of structure. Agreement between two sources only counts when both are describing the same level and neither derives from the other.
What happens when sources contradict each other?
We keep the disagreement. Two filings asserting different facts is a finding about the filer, not a defect to be collapsed into a winner. Collapsing it destroys the observation, which is often the most interesting thing in the record.
What if you get something wrong?
The raw archive is immutable and every derived layer is rebuilt from it, so a correction is a re-derivation rather than a patch — and the prior state remains inspectable. Methodology is versioned and dated, so any figure can be tied to the method in force when it was produced.
Is a model doing the matching?
For the fuzzy part — names written four ways, addresses that drift across decades of filings — yes, and it is straightforwardly better than the deterministic approaches that came before it. But the model only proposes. Whether a proposed link counts is decided by the level rule and the independence requirement, because the failure in our first worked example was a correct string match at the wrong level.

A question we have not listed here is usually still a dated one.

Send it and we will tell you whether the record supports it, what it would take, or that it is outside the boundary.

info@predicaterx.com

Predicate RX

← Predicate RX homeOverviewOne page