Particle Health

The durable asset is the interoperability network: connections to national health information networks, identity resolution, and record retrieval at a reported 320 million record scale. That is infrastructure, not inference. The AI is a real and growing layer on top, covering summarization through Snapshot, discharge summary generation, and model based clinical document parsing that the company argues outperforms template based CCDA extraction. A customer buys the data access first and the enrichment second, which is what this grade describes. This is the same pattern as Helix, where the network is the moat and the models are the layer.

The oversight question for this product is unusual and has nothing to do with clinical supervision. This is infrastructure: it retrieves records across national exchange networks on behalf of customers. The judgement it makes is about who may ask, not about what an answer means.

So the control that matters is customer vetting. The company states that its customers commit to a rigorous onboarding process, must adhere to the framework's standards, and are removed immediately if they do not, and that it assists in investigations where complaints arise. That is a stated oversight model and it is more than many intermediaries publish.

The documented 2024 framework resolution found that onboarding diligence had been performed on the customers at issue and had not surfaced inaccurate information they supplied. That is the structural limitation of any vetting regime rather than a finding unique to this company: diligence tests what an applicant says, and an applicant who misstates their use case can pass it.

The questions therefore concern what operates after onboarding. Ask what ongoing monitoring exists on query patterns, what triggers a review, whether anomalous querying is detected proactively or only on complaint, and what the company can see about how retrieved records are used downstream.

Unusually candid engineering disclosure for a data vendor. Published writing explains why template based CCDA parsing drops clinically important medications and what was built instead, and argues that discharge alerting fails on identity resolution rather than event delivery. Naming your own failure modes in public is a stronger transparency signal than a capability list. Held back from A because no model detail, benchmark, or accuracy measurement for the summarization and parsing products was retrieved.

The company operates under the interoperability and information blocking rules and handles the query attribution requirements health information networks impose, which is a real compliance function and is credited as such. Against that, the platform explicitly positions retrieved clinical data as a resource for training artificial intelligence models, and no disclosure was retrieved covering the consent scope for that secondary use, the de identification standard applied, or what controls a customer has over it.

For a vendor whose product is bulk access to identified clinical records, that is the disclosure a buyer most needs and it is absent. The route by which the data arrives is what makes the gap acute rather than ordinary. Records reached through national interoperability networks were contributed by provider organisations for treatment, payment and operations purposes, under participation agreements that patients were never party to and mostly do not know exist, and the framework was built to move a record to the clinician treating a patient.

Repositioning that flow as a training corpus is a different use with a different basis, and the contributing organisations are not the ones stating it. Ask what basis supports model training on retrieved records, whether contributing networks have agreed to it, whether customers can require that their queries never feed a corpus, and what de identification is applied and verified by whom.

No clinical evidence exists and none is required. The product does not diagnose, predict or recommend, so the trial and validation literature this index looks for elsewhere has no application here.

The evidence that would matter for infrastructure is operational, and little of it is published in a form a buyer can rely on. The useful measures are retrieval coverage and quality: what proportion of queries return records, how completeness varies by region and by record system, latency, and what happens when a patient's records sit with an organisation that is not reachable. Those determine whether the product delivers what a customer is buying, and they vary considerably across the country.

One contextual figure is public and worth knowing. Exchange under the newer federal framework has passed a billion records, so the underlying networks are operating at genuine scale. That says something about the ecosystem rather than about this participant's performance within it.

A buyer evaluating this category should ask for coverage statistics against their own patient population rather than national aggregates, since a national average conceals wide regional variation.

Ask for match and retrieval rates by region, and for a pilot measured against the customer's own panel.

The company operates under the interoperability and information blocking rules and handles the query attribution requirements that health information networks impose, which is a real compliance function. However the platform explicitly positions retrieved clinical data as a resource for training AI models, and no disclosure was retrieved covering consent scope for that secondary use, de identification standard, or customer controls over it. For a vendor whose product is bulk access to identified clinical records, that is the disclosure a buyer most needs and it is absent.

No agreement terms or subprocessor disclosure were located, and for this vendor the substantive question is not whether agreements exist but how permitted purpose is governed. A publicly documented dispute makes that concrete, and it should be described factually because litigation is ongoing.

In 2024 a major record system vendor complained to one of the national exchange frameworks that customers of this company were querying records under treatment purpose when their actual use was different, and it cut off access. The framework investigated and published a redacted resolution. Its findings included that this company had conducted onboarding diligence on the three customers concerned, and that the diligence did not reveal inaccurate information those customers had provided. The company terminated those contracts, and the customers were removed from the framework for a period. Both parties publicly characterised the resolution as supporting their position. A separate antitrust suit brought by this company continues, with some claims allowed to proceed and others dismissed.

What a buyer should take from that is not a verdict. It is that purpose of use is the operative control in network based exchange, that it is asserted by the querying party, and that an intermediary's diligence is what stands between an assertion and the record.

Ask how purpose is verified now, what changed after 2024, and what the agreement says about attestation and audit.

No attestation, certification or trust centre was located.

One obligation makes the gap determinate rather than open ended, as this index has recorded for other network participants. The newer national exchange framework carries a healthcare specific security certification requirement for participating networks, so where a company participates or is pursuing participation, the certification arrives as part of that package rather than as an optional credential. Establish where the company sits in that process.

What an examination would need to cover is unusual and follows from the business rather than the technology. The company holds credentials and query rights that reach records held by organisations across the country which have no relationship with it. That capability is the most sensitive thing it possesses, more so than any single customer's data, because misuse reaches across institutions rather than within one. The documented 2024 dispute concerned exactly that surface, though the question there was authorisation rather than intrusion.

So the questions are about control of querying itself: how customer credentials are issued and revoked, how queries are logged and retained, whether a responding organisation can see who ultimately received its records, and what the company retains from a query it fulfilled.

No clearance or device authorisation exists and none should. This is data exchange infrastructure. It makes no clinical claim, reaches no clinical conclusion, and no device framework attaches, so this axis should not read as an absence.

What governs is substantial and unusually active. Information blocking rules reach practices likely to interfere with access, exchange or use of electronic health information, and both sides of an access dispute can invoke them. The participation agreements of the national exchange frameworks are the operative rulebook, with their own investigation and dispute resolution machinery, which was used here and produced a published resolution. Federal oversight of those networks is tightening, with funding directed specifically at enforcing network compliance as exchange volumes pass a billion records.

Competition law has now entered the same territory through this company's own antitrust action, which is testing whether access decisions by a dominant record system vendor are actionable. Some claims have been permitted to proceed and others dismissed.

A buyer does not need to predict that outcome. What matters is that the rules governing who may query a national network are being settled now, through regulators, framework governance and courts at once.

Ask which frameworks the company participates in today and whether any access remains restricted.

No governance framework, fairness statement or responsible AI documentation was located, and the axis needs scoping before it can be read, because artificial intelligence is not what this product principally is. It is exchange infrastructure, and most of what it does is querying, matching and normalisation rather than inference.

The component where the question genuinely applies is patient matching. Deciding that a record held by one organisation belongs to the same person as a record held by another is a probabilistic judgement, and it is the operation on which everything else depends.

Matching is known to perform unevenly. It relies on name, date of birth, address and identifiers, and it degrades where names are transliterated or hyphenated, where address history is unstable, where records were created under a former name, and where demographic fields were entered inconsistently. Those conditions correlate with population groups, so match failure is not randomly distributed. A missed match means a clinician sees an incomplete history for a patient whose records exist but were not found, and nothing in the interface reveals the omission.

Ask what the match rate is, how it was measured, whether it has been examined across demographic groups, and what a false match rate looks like.

Naming your own failure modes in public is a stronger transparency signal than a capability list, and this company does it in technical detail. Published engineering writing explains why template based parsing of clinical document standards drops clinically important medications and what was built instead, and argues that discharge alerting fails on identity resolution rather than on event delivery.

Both are statements against interest in the sense that matters here: they concede that a widely used approach, including one the company could have shipped, produces incomplete clinical data, and they name the specific consequence rather than gesturing at quality. A reader can take those claims to a competitor and ask whether their parser has the same problem, which is exactly what a transparency disclosure should enable.

It also tells a buyer where to look during evaluation, since medication list completeness and patient matching are now identified as the hard parts rather than left to be discovered in production. Held below the top grade because no model detail, benchmark or accuracy measurement was retrieved for the summarisation and parsing products, so the failure analysis is published and the resulting performance is not, and no warranty, indemnity or remediation commitment attaches. Ask for medication capture completeness against a reference, the identity resolution false match and missed match rates, and what a clinician sees when the system knows a record set is incomplete.

This is the product and the coverage is specific: a single bidirectional API spanning CommonWell, Carequality, and eHealth Exchange plus ADT feeds and prescription data, reaching a reported 70,000 healthcare organizations and locating roughly 90 percent of patients nationally, returned in structured FHIR.

Particle for Platforms additionally handles the query permission and attribution burden for health IT vendors who lack a direct treatment relationship with patients, which is a genuine regulatory constraint rather than a feature.

No hosting model, region, tenancy or residency statement was located. Delivery is an interface consumed by customer applications.

The question that matters most for this architecture is not where the platform runs but what it keeps. A record retrieval intermediary can operate as a pass through, returning results to the requesting customer and retaining nothing beyond transaction metadata, or it can persist retrieved records to serve later requests and improve matching. Those are very different propositions for the organisations whose records travel through it, and nothing published establishes which applies.

That distinction acquired public significance in the 2024 dispute, during which the complaining vendor asked this company to delete and confirm deletion of data obtained through the framework. Whatever the merits, the episode establishes that retention by an intermediary is a live question that responding organisations care about and may act on.

So a buyer should establish it explicitly: what is retained after a query is fulfilled, for how long, whether retrieved clinical content persists or only identifiers and audit records, and whether a responding organisation can require deletion.

Ask for the hosting region, the retention policy for retrieved records, the subprocessor list, and the deletion mechanism.

No public pricing. Contact the vendor. Sold to health technology companies, payers, and care organizations, with a platform tier for health IT vendors serving many downstream clients. Buyers should establish whether pricing is per query, per patient record, or subscription, since retrieval volume drives cost in very different ways under each.

Coverage is national and setting agnostic by design, which is the correct shape for infrastructure of this kind. The company participates in the major national exchange frameworks and retrieves records wherever participating organisations hold them, so its reach is defined by network membership rather than by clinical specialty or care setting.

What varies is the customer side, and that is the more useful thing to describe. The company serves digital health companies, provider organisations and, since expanding into that segment, payers. Those customers pursue different purposes, and the framework rules treat those purposes differently. A provider querying for treatment sits in the clearest position; a payer querying is where the permitted purpose analysis becomes contested, as the documented 2024 dispute showed.

So coverage should be read in two dimensions rather than one. Geographic and institutional reach is broad and genuinely national. Permitted use is narrower than reach, and is set by the purpose a customer asserts and the rules of the framework carrying the query.

A buyer should establish which customer category they fall into and what they may lawfully do with retrieved records, which is a different question from what the network can technically return.