Kyruus Health

A provider data business with models inside it, which is a different proposition from a model business.

The foundation is data work: ingesting, standardizing and cleansing provider and location records from multiple sources into a single directory, then distributing it to health system websites, scheduling systems, search engines, listings, record systems and payer directories. That is data engineering, integration and governance, and it keeps its value with every model removed. Health plans buy it partly because directory accuracy is a regulatory obligation, and an obligation is satisfied by correct data rather than by intelligent data.

Three model claims are specific. The data management product describes AI driven maintenance that proactively identifies and resolves data quality problems with minimal staff intervention, and AI driven suggestions for profile optimization. The payer search product sells a conversational experience that interprets a member's natural language question rather than keywords, alongside the traditional keyword search it sits beside. And ranking is described as advanced ranking models that surface the most relevant and high value options.

The products those models improve exist without them: a filter and keyword directory, self scheduling into the record system, listings distribution, check in and payment. The company's own argument supports that reading, since it markets accurate data as the precondition for artificial intelligence rather than the other way round.

Low inherent risk by design, with one consequential decision taken automatically and nothing published about how it is made.

Nothing here diagnoses, triages or advises. The models rank providers, flag suspect directory records and interpret a search query; a person chooses from the results. A patient who dislikes the matches scrolls, refines or calls, so the ordinary failure mode is friction rather than harm.

The consequential decision is ranking. Which clinicians appear, and in what order, in response to a described need determines who patients actually reach, and most people choose from the first few results. The payer product describes surfacing the most relevant, high value and actionable options through advanced ranking models, and guiding members to high value care, so the ordering is explicitly optimized toward something beyond clinical fit. Nothing published describes what governs it: whether availability, network economics, panel capacity, cost tier or referral value weigh alongside specialty and language, or whether a health system can tune it toward employed providers over independent ones. Nothing says whether a patient is told the order is personalized.

The data quality models raise a smaller version and the company is clear about it: maintenance is described as identifying and resolving issues with minimal staff intervention while the product still routes changes through a user interface where staff edit and bulk update, so a flagged record is a recommendation rather than a silent rewrite.

The functional description is specific and the mechanisms are entirely undisclosed.

Three capabilities are named with what each does: AI driven maintenance that identifies and resolves provider data quality problems and suggests profile improvements, matching that routes on specialty, location, insurance, language and availability rather than keywords, and a conversational search that interprets natural language questions in place of filters. Advanced ranking models are named as the mechanism behind which options surface first. The platform architecture is laid out module by module, with published interfaces for provider search, availability and scheduling, so a technical buyer can see the integration surface without a sales conversation.

Below that there is nothing. No architecture, no training data, no accuracy or precision figure for any model, no evaluation method, no versioning and no update cadence. For conversational search no language model or provider is named, and nothing says whether interpretation runs on a commercial foundation model or on in house work, which also decides where a member's question travels.

The largest omission is the weighting. Knowing that matching considers five attributes says nothing about how they are traded off, and the trade off is the product.

The infrastructure is named and the model layer is not.

What is named: the website privacy policy lists the service providers the company contracts with, including Amazon Web Services, Aptible, Google Cloud Platform, Looker, Mailgun and Twilio, which covers hosting, a healthcare platform layer, analytics, email and messaging. Naming hosts matters for residency and breach scope, and says nothing about the models.

What is not named is anything producing an output. Nothing states whether the matching engine, the data quality models or the conversational search are built in house, licensed, or assembled on commercial foundation models, and for the conversational capability, the newest and the one interpreting a member's own words, no provider is identified. That is the layer where an outside party would most likely sit and where member queries would flow to it.

The assembled history compounds it. The platform joins the original provider data and matching business, a payer transparency business acquired in 2021 and a patient engagement business acquired in 2022, with the whole acquired again in 2025. Each brought its own stack and dependencies, and nothing describes how far they are unified, so what runs underneath a given module probably differs by module.

One upstream category is data rather than models: provider information is ingested from multiple sources, implying external reference data and public registries, none enumerated. For a product whose value is data accuracy, that provenance matters.

Large scale, named customers, and no measurement with a method behind it.

The company's own figures are 1,400 hospitals, 550 medical groups and 100 health plan brands, with a connected provider count displayed without a unit. Named customers carry real detail: Banner Health built a single source of provider information for 12,000 physicians and uses the interfaces to power its mobile app, and case studies name Catholic Health, Intermountain Health and Shore Physicians Group. Scale of use is not evidence of benefit.

The published figures are vendor reported and unqualified. The Banner figures are a 35 percent increase in organic traffic to its find a provider site and a 99.8 percent accuracy rate on appointments, with no period, baseline or definition; the payer side carries an up to 114 percent increase in member interactions from enhanced profiles. None states what was compared or over how long.

What is missing is any evaluation of the intelligence, which is the product's central claim. No matching accuracy, no study of whether patients routed by the model reach a more appropriate clinician than those using filters, no precision or recall for the data quality detection, and no independent assessment of conversational search. For a platform that sells a better match, match quality is the missing figure.

The individual customer case studies may carry the periods and comparators these summary figures lack.

General documentation exists, one clause takes a clear position on secondary use, and the questions the models raise are still open.

The terms of service grant the company the right to de identify customer data and to use or disclose de identified data in any manner for any purpose, with protected health information carved out to applicable law and any business associate agreement. That is a published position on secondary use, and a permissive one: it is a route by which platform content can feed anything the company chooses to build. The website privacy policy names the service providers behind the site, including Amazon Web Services, Aptible, Google Cloud Platform, Looker, Mailgun and Twilio, and describes de identification and aggregation in similar terms.

What is unanswered is everything time bound and product specific. No retention schedule appears for search queries, booking records, intake responses or payment data, and no deletion process is described. Provider search queries are the overlooked category here: a description of a symptom typed into a health system or plan directory reveals what a person believes is wrong with them, is created before any encounter or consent exists, and the conversational product deliberately invites a richer, more narrative version of it. Nothing states whether those queries are retained, linked to an identity, or used to improve matching.

The cross customer question follows: matching improves with volume, and nothing states whether models are trained per customer or across the network. Nor is it said whether queries are treated as protected information.

A status that appears only as a conditional clause, with no agreement published and one certification that belongs to an acquired component.

What the site says: the terms of service state that where customer data constitutes protected health information under HIPAA, the company's rights and obligations are governed by applicable law and by any applicable business associate agreement to which it is a party, and that such an agreement controls over the terms. That acknowledges the role without asserting it, and no agreement, template or scope statement is published anywhere. The privacy policy covers the website rather than the platform.

The certification evidence is dated and narrow. The digital patient engagement business acquired in 2022 was described at acquisition as HIPAA compliant and HITRUST certified. That attached to one company at one point, four years and a further change of ownership ago, and nothing states whether it now covers the data management foundation, the payer business or the modules a given buyer would license.

One point works in the vendor's favor. Most of what moves through this platform is provider directory data, which is business information rather than protected health information. The exposure concentrates in scheduling, check in and payment, and in what a patient types into a search box. Nothing addresses whether search queries are treated as protected information or as analytics.

One real certification, attached to one acquired component at one point in time, and no current platform level position anywhere on the site.

The documented fact is that the digital patient engagement business acquired in 2022 was described at acquisition as HIPAA compliant and HITRUST certified. HITRUST is the strongest credential in this market and the claim appeared in a transaction announcement rather than in marketing copy, so it is more substantial than an assertion.

Everything about its current applicability is unestablished. That certification belonged to a separate company in 2022; it has since been absorbed into a larger platform, and the parent was itself acquired in 2025. Nothing states whether HITRUST covers the combined platform today, whether it reaches the data management foundation or the payer business, or what its scope is. For a company assembled from three businesses under two ownership changes, scope is the whole question.

Nothing current appears at all: no security or trust page in the site navigation or footer, no service organization control report, no penetration testing statement, no vulnerability disclosure policy and no incident notification commitment. The infrastructure providers named in the privacy policy are hosts rather than assurances.

The scale makes the silence conspicuous. An incumbent serving 1,400 hospitals and 100 plan brands has very likely been through many security reviews, so artifacts probably exist and are shown to prospects privately.

No clearance is claimed and none is required, and the company engages directly with the regulation that does govern its buyers.

On devices the position is clean: provider directory management, search, matching, scheduling and check in make no clinical claim and approach no device question.

The regime that applies is directory and transparency regulation. Health plans carry federal and state obligations to maintain accurate provider directories, surprise billing protections attach consequences to directory errors, and price transparency and interoperability rules impose their own duties. The company has built product against all of it and names it: provider data management with attestation for plans, a public ready directory feature described as supporting CMS compliance, cost estimation described as going beyond price transparency requirements, and interoperability services sold as accelerating compliance. It also publishes research on the state of plan directory data.

What is not published is any position on accuracy guarantees, or on how automated data quality judgments interact with a plan's own attestation, which is where the vendor's model meets the customer's regulatory filing.

Nothing published shows how the models are evaluated or governed: no method, no accuracy figures for matching or data quality detection, no performance across groups, no bias statement and no external review.

The exposure runs two ways here.

On the patient side, matching routes on language among other attributes, so language handling is itself an equity mechanism: a member searching in Spanish either surfaces Spanish speaking clinicians reliably or does not. Conversational search compounds it, because interpreting a narrative description of a need depends on how the need is phrased, and phrasing varies with literacy, first language and cultural framing. No performance by language or phrasing is published.

On the provider side the ranking model decides which clinicians receive patient volume, and volume is income and referral pattern. If ordering is influenced by profile completeness, review counts, historical booking rates or anything correlated with time in the network, it will systematically advantage established providers over new ones, and may disadvantage clinicians whose patients book by phone. The payer product's stated optimization toward high value care makes this sharper, since a cost or quality tier is doing part of the ordering and nothing describes how it is calculated or audited.

The data quality models carry a third: whether detection performs evenly across practice types, or flags small independent practices more often than large employed groups.

Nothing published allocates responsibility for an automated outcome, and the terms of service push responsibility the other way.

The terms make the customer responsible for its own data and its accuracy, state that all users access and use that data at their own risk, and disclaim liability for loss arising from it. No accuracy commitment, service level, performance warranty, indemnity or remediation route appears for matching, data quality detection, conversational search or scheduling, and the ranking that decides which clinicians a patient sees carries nothing at all.

The distinctive exposure is regulatory. Health plans carry statutory obligations for accurate directories, and surprise billing protections attach consequences when a patient relies on a directory that wrongly shows a provider as in network. This vendor supplies the directory and its models decide which records look suspect. If detection misses an outdated record and a member is billed as a result, the loss lands on the plan, and nothing describes detection service levels or how the vendor's automated judgment meets the plan's attestation. That interaction is the sharpest unaddressed question on the record.

A second follows from matching: a member routed to a clinician who does not treat their condition loses time and an appointment, with no published recourse. A third follows from scale: when the platform is the booking path for 1,400 hospitals, an availability failure is a regional operational event, and no service commitment is published.

Integration is the product rather than a supporting feature, and it is named, two way and documented.

Four record systems have their own integration pages: Epic, Oracle Health, MEDITECH and athenahealth, which covers effectively the entire United States market. The Epic integration is described concretely: single sign on, Kyruus Search embedded inside MyChart, provider data flowing into operations including the Epic provider record, and self scheduling that books directly into the record system rather than into a queue for staff to rekey, which is the hard half of the problem.

Published interfaces are the distinguishing feature. The company sells application programming interfaces for provider search, availability and scheduling, with a product page describing how customers build their own experiences on their own provider data, and Banner Health is named using them to power its mobile app across its network. A vendor that publishes interfaces rather than only consuming them lowers the risk of a customer being locked out of its own directory.

Distribution runs outward too: provider data is pushed to health system websites, scheduling systems, search engines, listings and payer directories, and the payer side connects plan directories to provider scheduling.

None of this touches clinical data. Everything moving is provider information, availability and appointments, which is the right scope for this product.

Hosting is named in the website privacy policy and nothing else about the deployment is committed.

What is published: the privacy policy lists the service providers the company contracts with for data collection, naming Amazon Web Services, Aptible, Google Cloud Platform, Looker, Mailgun and Twilio. That tells a buyer the platform runs on commercial cloud infrastructure with a healthcare platform layer in the mix. No region, no residency commitment, no tenancy or segregation model, no backup or disaster recovery position and no availability commitment appears, and the policy itself is scoped to the website rather than the platform.

Two characteristics make the gap material. The platform distributes data outward by design, pushing provider information to health system websites, search engines, listings and payer directories, so the data path extends to destinations that are never enumerated and a customer cannot map where its provider data ends up. And the search and scheduling experiences run embedded in customer websites and inside MyChart, so vendor code executes in the customer's own domain, which is a client side data question as well as a hosting one.

Availability deserves a line of its own: when the platform is the booking path for 1,400 hospitals, an outage is a health system that cannot book patients, and no uptime commitment or status history is published.

Every module is described and none is priced.

The catalog is split by buyer. Provider organizations buy Provider Data Management, APIs for search, availability and scheduling, Analytics, and the Reach, Search, Schedule and Check-In modules. Health plans buy Provider Data Solutions with attestation, payer APIs, Analytics, Search with the conversational experience, Guide, Cost, Reviews, Rewards, Price Transparency and Interoperability Services. Each module has a described function, so a buyer can tell which ones a project needs and that the data foundation is what the rest depends on.

What no page answers is the unit of charge, and the candidates diverge sharply here: per provider under management, per hospital or location, per member, per booking, or a platform fee. At the stated scale a per provider basis would be a very different conversation from a flat fee. Nothing indicates whether the data foundation is licensed separately from the modules that sit on it, which is what decides whether a buyer can start small, and no implementation fee, term or minimum appears.

One structural point matters. Directory accuracy is a regulatory obligation for health plans rather than a discretionary improvement, and an incumbent holding the authoritative directory has real renewal leverage; no exit terms or data export rights are published.

Coverage is named specifically on both sides of the market and supported by named deployments.

Organization types have their own pages: health systems and hospitals, medical groups, management services organizations and independent practice associations, primary care practices, surgical specialties and women's health practices, plus health plans and government plans. Serving provider organizations and payers from one platform follows from the payer business the company acquired.

Scale supports the claim at both ends: 1,400 hospitals, 550 medical groups and 100 health plan brands, with record system integrations named for Epic, Oracle Health, MEDITECH and athenahealth, which covers effectively the whole United States market rather than one or two systems. Named customers span an academic system, a large multi state group (Banner Health, 12,000 physicians), a community hospital system (Catholic Health) and a 60 location medical group.

Journey coverage is complete for patient access: listings reach a consumer before they have chosen anywhere, search and matching route them, scheduling books into the record system, and digital intake, payment and check in handle arrival. On the payer side it extends to cost estimates, reviews and rewards.

Clinical coverage is inherited from the specialty taxonomy under the matching engine rather than built as clinical content, which is the right depth for this product: the question is how finely a clinician's expertise can be described, not whether protocols exist.