Loyal Health

A patient engagement platform with a conversational layer on it, where most of the commercial value sits in things that are not models.

The majority of the platform is data and workflow rather than intelligence. Provider data management across more than 80,000 provider and location profiles, listings synchronisation to external publishers, reputation and reviews management, real time scheduling and a customer relationship management layer are all substantial products and none of them needs a model to work. The company's own headline case study on the data side reports a complete elimination of transposition errors through one click synchronous updates, which is a data integrity result, not a machine learning one.

The model work is real and narrower. Guide is a hybrid live and artificial intelligence chat product described at launch as backed by a custom built neural network, and third party profiles describe conversational engagement using machine learning and natural language processing alongside clinical taxonomy. Care search is described as intelligent, matching consumer intent to services, and that intent matching against a clinical taxonomy is genuine model work and arguably the most defensible artificial intelligence claim on the record.

What holds this at C rather than higher is that a health system could buy the majority of this platform and never touch a model, and the chat itself is explicitly hybrid, with live agents in the same interface. What holds it at C rather than lower is that the conversational layer is the front door for the whole platform and carries the scheduling capability that makes the rest convert.

The design keeps a human available and the boundary of what the model does alone is undefined.

The genuine strength is the hybrid architecture. Guide was built from the start as a combined live and artificial intelligence chat product, so a human agent sits in the same interface and a conversation can move to a person without leaving the channel. That is a better structural answer than a pure bot with a phone number to call as a fallback, and it has been the design since 2018 rather than a recent addition.

The autonomy that does exist is mostly low stakes and correctly scoped. Finding a provider, comparing locations, answering questions about services and booking an appointment are consequential to a health system's revenue and rarely consequential to a patient's safety. A wrong answer produces an inconvenience, not a harm, which is a materially different risk profile from the triage products on the neighbouring records and is why this does not grade lower.

Three things are unaddressed. Nothing published defines when the model hands to a live agent, what triggers the handoff, or whether the patient can request one. Nothing describes what happens when someone describes an urgent symptom to a marketing oriented chat interface, which will happen because patients do not know which system they are talking to, and the pandemic risk assessment tool shows the product has been used for exactly that kind of routing before. And nothing describes live agent coverage hours, so a patient meeting the bot at midnight may have no fallback at all.

Graded C.

The artificial intelligence description on this record is the least current of any vendor built in this session, and that is the finding.

What exists is dated. The chat product was described at its 2018 launch as backed by a custom built neural network using artificial intelligence driven algorithms, and third party profiles describe machine learning and natural language processing with clinical taxonomy integration. Nothing located updates that picture. Given how completely conversational technology changed between 2018 and 2026, a description written in the language of a custom built neural network tells a buyer almost nothing about what is answering a patient today, and the company has not published anything that would.

No model architecture, no vendor or framework, no training data description, no evaluation method, no accuracy figure, no versioning and no update cadence were located for any component.

The clinical taxonomy is the one exception and it is described only as clinically validated, without naming who validated it, against what, or how it is maintained. That is a meaningful gap because the taxonomy is what turns a described need into a service line, and on the neighbouring records in this category the licensed clinical content is named to the level of authors and edition numbers.

The acquisition compounds the currency problem. A platform now being combined with an analytics business may well have a different technical roadmap, and nothing published describes the current or intended state.

Graded D: an artificial intelligence claim resting on eight year old language and nothing since.

Nothing upstream is disclosed. No model vendor, no framework, no hosted conversational service, no third party or open source component and no inventory of any kind was located for any part of the platform.

The only provenance statement available is the company's own, that the chat is backed by a custom built neural network, and it dates from 2018. Read literally it is a claim of in house development, which would be a supply chain disclosure of a sort, and eight years on it cannot be relied on as a description of the current system. A conversational product that has not restated its technical provenance since 2018 is either running something materially different from what it describes or has not updated, and neither possibility is established.

The clinical taxonomy is the second undisclosed dependency. It is described as clinically validated and nothing states whether it is licensed, purchased, derived from a standard terminology or built internally, nor who validated it. On the two neighbouring triage records the equivalent content is named to the level of licensor, authors and edition, which shows what disclosure looks like when a vendor chooses to make it.

A third dependency is implied and never named. A platform that synchronises provider data to external publishers and directories necessarily integrates with those publishers, so there is a distribution supply chain carrying customer data outward. None of those destinations is enumerated.

Graded D as an absence of disclosure rather than evidence of a problem.

The deployment evidence is the strongest in this part of the index and it is corroborated from outside the vendor, which is what lifts this above every other patient access record built in this session.

The LifePoint Health relationship is the anchor and it is documented by the customer rather than by the vendor. LifePoint's own publication states that all of its more than 80 hospitals use the chat and live chat solution for appointment scheduling and triage functions, that Loyal also manages provider data, search, and reviews and ratings across its locations, and that the relationship was extended into a five year partnership having begun in 2017. A customer publishing that on its own site, naming the scope and the duration, is materially better evidence than a vendor logo wall.

Other named systems include Northwestern Medicine and UCLA Health among more than 30 hospital systems as of 2020, a state hospital association affiliate partnership, and an acquirer statement of millions of patient searches and real time scheduling transactions annually across a nationwide customer base. A named customer at a health system also described the pandemic risk assessment deployment in operational terms.

What is missing keeps this from an A. Every outcome figure located is either a vendor claim or a scale count rather than a measured result: no conversion rate against a control, no measured effect on call volume, no appointment yield study and no peer reviewed evaluation of any kind. And the strongest customer documentation dates from 2021, so the current state of that relationship is not established.

Graded B on breadth, duration and independent corroboration of deployment, with the outcome question unanswered.

Nothing published addresses what happens to the data the platform collects, and the commercial model gives that omission more weight than it would carry elsewhere.

This platform exists to acquire and retain patients. It captures consumer search behaviour, chat conversations, scheduling activity, review responses and engagement across a health system's digital surface, and it feeds a customer relationship management layer built to re engage people at the right moment. That is a marketing data asset by design. Nothing located states retention periods, whether chat transcripts or search behaviour inform model development, whether data is segregated by customer, or whether any of it is aggregated across health systems to improve intent matching.

The cross customer question is the sharp one. Intent matching against a clinical taxonomy improves with volume, and a vendor operating across a nationwide base with more than 80,000 provider profiles has an obvious technical incentive to learn across tenants. Whether it does, and under what de identification standard, is unstated in either direction.

The live chat surface compounds it. A hybrid product where patients may reach a human agent in the same interface produces transcripts containing symptom descriptions written before any clinical encounter exists, and nothing describes how those are handled differently from marketing engagement data, if at all.

The acquisition adds a live question a buyer should ask directly. When a patient activation platform combines with a referral intelligence and quality analytics business, whether patient level data flows between the two, and under what basis, is exactly the kind of thing that changes after a transaction and is not addressed in any material located.

Graded D on the absence.

Compliance is claimed consistently over a long period and the contractual layer is unpublished.

What is stated is more than most records in this category offer. The company publishes a health privacy statute compliance commitment on its own site, describing it as reflected in core practices, daily processes and training initiatives, which at least gestures at operational implementation rather than asserting compliance as a status. The chat product has been described as compliant with the statute since at least 2018, including by a customer in its own publication, so the claim has been made consistently across eight years rather than added recently.

The data flows make the vendor unambiguously a business associate. The platform books directly into a health system's underlying scheduling system through record vendor interfaces, runs live chat where a patient may describe a symptom to a human agent, and carried a risk assessment tool during the pandemic. Appointment data and chat transcripts are protected health information, and the scheduling integration means the vendor both reads and writes.

What is absent is any document. No business associate agreement is offered or described, no protected data handling summary exists, no retention position is stated, and nothing describes what the vendor may do with chat transcripts or search behaviour. The last is not a minor point on a platform whose commercial purpose is patient acquisition, since consumer search and engagement data is exactly what a marketing oriented platform has an incentive to use.

Graded C on the strength of the sustained compliance claim and the security certification recorded on the adjacent axis, with the contractual and retention questions unanswered.

One real certification claim, published in the vendor's own voice, and nothing behind it.

The claim is specific enough to be useful. The company states service organisation control type 2 compliance and names the criteria it covers, security, availability and confidentiality, alongside a health privacy statute commitment described as embedded in core practices, daily processes and training. Type 2 matters because it tests whether controls operated over a period rather than existed on a date, and naming the trust criteria is more precise than the bare certification claims common in this category. That alone places this above the two triage records built in this session, which publish no certification at all.

What is missing is everything a security reviewer would do next. No trust centre exists, no process is described for requesting the report under agreement, no audit period or auditor is named, no penetration testing statement, no vulnerability disclosure policy, no subprocessor list and no incident notification commitment were located. There is no evidence of the certification beyond the sentence asserting it.

The website embedding surface deserves specific mention. Because this platform runs inside a health system's own public pages, its client side security posture is part of the customer's attack surface rather than adjacent to it, and nothing published addresses script integrity, content security policy expectations or what third party services load alongside.

Graded C: a genuine and specific certification claim, unaccompanied by any means of verifying it.

No clearance is claimed and none is required for the product as described. Provider search, scheduling, listings, reputation management and a customer relationship layer are not clinical software under any reading, and a chat interface that routes a consumer to a service line sits comfortably outside device regulation. This is the least regulated product in this part of the index and correctly so.

One historical episode sits closer to the boundary than the rest. During the pandemic the chat carried a risk assessment tool used to direct patients toward telehealth or in person care and, in a customer's own words, to keep healthy patients at home. Assessing risk from reported symptoms and recommending whether to stay home is triage, and it was delivered through a platform whose regulatory posture is otherwise that of a marketing product. Software of that kind was covered by enforcement discretion at the time, so it was legitimate then; nothing published describes whether the capability persists, under what constraints, or what analysis was applied when the discretion period ended.

The wider exposure is not federal device regulation but consumer protection and privacy law. A platform whose purpose is patient acquisition, which places listings on external publishers and runs tracking across a health system's digital front door, sits squarely in the area regulators have been most active on in recent years regarding online tracking technologies on provider websites. Nothing published addresses that posture.

Graded C: correctly positioned for the current product, with an unexamined historical capability and an unaddressed regulatory surface that is real for this business model.

Nothing was located. No model card, no training data description, no accuracy figures, no subgroup analysis and no bias statement.

The exposure here is different from the triage records and is worth stating precisely, because it is easy to dismiss a marketing platform as low stakes on this axis. This system decides which providers a patient sees when they search, which services get surfaced for a described need, and who gets re engaged and when. Those are allocation decisions. A model that matches intent to a clinical taxonomy is deciding which door opens, and a customer relationship layer that targets re engagement is deciding whose care gets a nudge and whose does not.

Two mechanisms deserve naming. Intent matching depends on interpreting how a consumer describes a need, and that description varies with language, literacy and cultural framing in the same way symptom descriptions do, so the patients least well served by the interpretation layer are the ones already least well served by the system. And a re engagement engine optimised on conversion will learn to prioritise the patients most likely to book, which correlates with insurance status, transport and time flexibility, so an optimisation that looks purely commercial can quietly widen an access gap.

Nothing published addresses either, and nothing describes whether provider ranking in care search is influenced by anything other than clinical fit.

Graded D on the absence.

Nothing published addresses responsibility for an automated outcome, and the failure modes here are commercial and reputational rather than clinical, which does not make them small.

The consequences run in two directions. A patient misrouted by care search books the wrong specialty, wastes an appointment slot and delays their own care. A patient who cannot get an answer from the chat abandons and goes elsewhere, which is the revenue outcome the platform is sold to prevent. Provider data errors propagate outward to external publishers and directories, so a wrong address or a stale affiliation reaches the public internet under the health system's name rather than the vendor's.

That last point is the distinctive exposure on this record and it goes unaddressed. This platform publishes on the health system's behalf, into the system's own website and into third party listings, so the vendor's errors appear as the customer's errors and are corrected on the customer's reputation. Nothing published describes accuracy commitments on provider data, correction timelines, or who bears the consequence of a listing error that misdirects patients.

The hybrid chat architecture carries a similar unaddressed question. When a conversation moves between the model and a live agent, whose statement to the patient is whose, and nothing describes how transcripts are retained or produced if a patient later disputes what they were told.

No indemnity, limitation, performance warranty or recourse route was located for any of it. Graded D.

One capability here is genuinely strong and it has been in place longer than most competitors have existed.

The company joined the Epic App Orchard in 2018 specifically to enable direct scheduling through chat, using the record vendor's application programming interfaces so that a patient on a health system website can see real availability and book into the underlying scheduling system without leaving the conversation. Booking into a live scheduling system from a chat interface is the hard part of the digital front door, it is where most conversational products stop and hand off, and this vendor solved it early. The acquirer describes millions of real time scheduling transactions annually, which is the volume claim that makes the integration credible rather than nominal.

Provider data management extends interoperability outward rather than inward, synchronising provider and location records across external publishers and directories, with a customer reported elimination of transposition errors through one click updates. That is a different interoperability problem from the record integration and it is one health systems consistently fail at.

What holds this at B is direction and currency. Everything flows toward acquisition and scheduling; nothing described writes clinical information back into the chart, so a chat conversation where a patient describes a symptom does not become part of the record the way a triage encounter does on the Keona Health record. And the marketplace evidence is from 2018, with no current listing status, no second record vendor named and no mention of the modern interoperability standards that replaced the interfaces in use then.

Nothing published. No deployment model, no hosting platform, no region, no residency option, no subprocessor list, no retention or export position and no availability commitment.

The architecture is inferable and inference is not disclosure. A platform delivering chat widgets, provider search, listings synchronisation and scheduling across a nationwide customer base is a vendor hosted multi tenant service, and the security certification recorded on the adjacent axis implies a controlled hosting environment behind it. A buyer still cannot learn where their patients' conversations and search behaviour are processed from anything the vendor publishes.

One characteristic of this product makes the omission more material than usual. The platform runs on the health system's own public website, embedding chat, search and scheduling into pages the system controls, which means the vendor's code executes in the health system's domain and browser context. That is a data path question as much as a hosting question, and it is the exact configuration that has drawn regulatory attention over tracking technologies on provider sites. Nothing published describes what is collected client side, what is transmitted to the vendor, or what third party services are loaded alongside.

The acquisition adds a further unknown. Where the combined company will run the activation platform, and whether patient level data crosses into the acquirer's analytics infrastructure, is unaddressed and is a reasonable question for any buyer signing in the next year.

Graded D on the absence.

Nothing is published. No price, no unit of charge, no module or tier structure across the platform's several products, no implementation cost, no contract term and no minimum. The only route offered is a demo booking form.

The absence is more consequential here than on a single product record because of how the platform is packaged. Provider data management, listings, care search, scheduling, reputation and reviews, the customer relationship layer and chat are described as separate solutions within one platform, and a buyer reading the marketing has no way to determine which of them any given quote covers or how adding one later would be priced. Where a vendor sells a suite and publishes nothing, the module boundary becomes the negotiation, and buyers routinely discover after signature that the capability they were shown in a demo sits in a tier they did not buy.

One contract fact is public and it came from the customer rather than the vendor: the LifePoint relationship is described as a five year partnership. That tells a prospective buyer the expected commitment shape in this market is multi year, which is genuinely useful and is not something the vendor discloses itself.

The acquisition adds a second uncertainty. With the platform now positioned as the activation half of a combined intelligence and activation offering, whether it continues to be sold standalone and on what terms is unsettled, and nothing published addresses it.

Graded D. This is the floor, and it is correct rather than harsh.

Organisational reach is broad and clinical depth is deliberately shallow, which is the correct trade for what this product is.

The reach is real. More than 80,000 provider and location profiles under management, deployment across an 80 hospital national system, named academic and university health systems, a state hospital association affiliate partnership, and a nationwide customer base. That spans community hospitals, academic medical centres and multi site systems, and the provider data and listings products are inherently system wide rather than departmental, so coverage is enterprise by construction rather than by expansion.

Channel coverage is complete for the digital front door: health system website, chat, live chat, search, listings on external publishers, scheduling and follow up. The clinical taxonomy underneath care search is described as clinically validated and covers the service line breadth a health system needs to route a consumer to the right department.

The depth limit is the point of the product rather than a shortfall. This routes people to services, so its clinical coverage is a taxonomy of what a health system offers, not a protocol library of what a symptom means. Compared with the 600 topic adult and paediatric triage library behind Keona Health, the clinical substance here is thin, and the pandemic risk assessment tool is the only acuity work located.

Graded B: excellent organisational and channel coverage, minimal clinical coverage, with the caveat that a buyer expecting triage in the clinical sense will not find it here.