Kennar Health

The models are the product. There is no record system, services organization or prior platform underneath them.

Every stated output is model produced: a scribe that listens to the patient interaction and structures clinical data in real time, an analysis layer that surfaces open quality measures and risk adjustment opportunities during the visit, and a transitions of care function that pulls discharge data, builds clinical summaries and creates follow up tasks. The company sells this as an artificial intelligence workforce working alongside clinicians rather than as software a team operates, and the commercial claim, staff time returned and work captured without extra clicks or extra staff, is a claim about what the models do instead of people.

Remove them and there is no product left to sell. What would remain is an interface and a set of connections with nothing to put through them, since the capture layer everything else depends on is the model.

One boundary is worth testing rather than assuming. Quality measure logic is deterministic by construction, and gap detection over already structured data can be built as a rule set rather than a learned model. What cannot be built that way is the part this product is sold on, which is capturing the conversation and structuring it as the visit happens, and the gap analysis here is described as running on what the scribe captures rather than on a claims extract.

Two absolute claims about capture sit on the home page, and no review step is published anywhere.

The product is described as working alongside every clinician so that there are no extra clicks, no extra staff, and no work left uncaptured, and quality gaps that used to slip through are said to get closed in the room, in real time, every time. Those are claims that nothing is missed. A claim about what is absent cannot be checked by looking at the output, because a missed item never appears in it, so believing it removes the reason to build the review step that would catch the failure.

Nothing published describes a gate. No confidence signal, routing threshold, abstention behavior or required verification step was published for either the scribe output or the surfaced risk and quality opportunities, and the stated design goal runs the other way: providers can act on insights immediately within their existing workflow, in one click.

The compliance architecture does supply an indirect control, since tying every code to a face to face encounter with an approved provider type constrains what can be submitted. That is an eligibility rule rather than an accuracy check, and it says nothing about whether the condition surfaced is the right one.

The stakes are set by what the tool does at the moment it acts. It surfaces coding opportunities during the encounter, and what gets recorded determines payment, so an unchecked prompt becomes a submitted diagnosis rather than a draft someone edits later.

None of the four published figures comes with a method, and the one named standard is a documentation criterion rather than a model disclosure.

What is published: a 70 percent capture rate, half of quality measures closed autonomously, a 0.2 risk adjustment factor lift stated as an annual estimate derived from two additional condition codes per encounter, and two hours a day returned. None carries a denominator, a baseline, a population or a measurement approach, and no accuracy figure for coding or gap detection exists.

What is named is the criteria the documentation output is written to satisfy, the standard a reviewer applies when deciding whether a record supports a condition. That shows what the coding support is aiming at, which is more than a general claim to be compliant, and it describes an output standard rather than the thing producing the output.

Nothing describes the models. No model or model family is named, no architecture, no training data characterization, no version or update practice, and no evaluation methodology. For a product whose scribe runs during the encounter and whose analysis layer fires in the same flow, nothing states whether those are one model or two, or whether they optimize for the same objective.

That last question is the one with consequences, because a single model asked to both document the visit and surface billable conditions has an objective a clinician reading the note later cannot see.

Nothing identifies any party between a patient record and an answer.

No model or model family, no foundation model provider, no hosting arrangement, no cloud region and no subprocessor list is published. Nothing states whether captured content informs model development, and nothing describes the capture path itself: whether audio is recorded at all as against processed in real time, what is held, and for how long.

One thing is named. The documentation criteria the output is written to satisfy are identified explicitly, which pins down the standard the coding support is aimed at. That is a standard, not a supplier, and it says nothing about who handles the content on the way.

The scope flowing through that unnamed chain is wide. The platform combines encounter capture with quality measure and risk adjustment analysis, so it holds both conversation derived content and the coded conclusions drawn from it, and the second category is what an auditor would later examine. An interface is also offered to digital health companies with published specifications, which means structured clinical data leaves the platform to third parties that are never named.

The trust center publishes a data protection policy and a controls inventory, which describes how the company governs data rather than who else touches it.

Four figures are published, one of them attributed to deployed networks, and no customer is named anywhere.

The headline is a 70 percent quality measure capture rate across deployed networks, set against an industry typical figure of about 25 percent. Alongside it: half of quality measures closed autonomously, a 0.2 risk adjustment factor lift described as an annual estimate derived from an average of two additional condition codes per encounter, and two hours a day returned to physicians and support staff. The vendor presents these as coming from its own deployments, and the estimate is at least honest about being one.

None of them can be tested. No customer, network or site is named, no denominator, no baseline, no measurement period and no method. The comparison figure for the industry carries no source either. No case study, reference deployment, funding disclosure or independent evaluation was published, and the public footprint is minimal for a company selling into provider networks and health plans.

Capture rate is the figure that matters most, because it is the one most easily read as quality improvement when it may only describe volume. Capture of what, measured against which reference standard, and judged by whom are all unstated, and a capture rate that rises because more conditions are recorded is a different thing from one that rises because more true conditions are found.

General privacy and security assurances that do not answer the questions this product raises.

What is published is a privacy policy describing collection, use and disclosure, and a trust center carrying a data protection policy and a controls inventory. Neither states a retention period for any data type, a position on whether customer content is used to train or improve models, or a de-identification posture. Nothing in the published material says whether the scribe records audio at all or processes it in the moment, and nothing says what happens to a recording if one is made.

For a product that listens during clinical encounters, those are the first three questions, and none of them is answered anywhere.

The combination the platform sells makes the stewardship question sharper than retention alone. The scribe listens to the patient interaction while the analysis layer surfaces quality measure gaps and condition capture opportunities in the same flow, with improved scores and increased revenue named as the outcomes. A documentation tool that surfaces coding opportunities during the encounter is not summarizing afterward what happened, it is shaping what gets recorded while it is being recorded, and what gets recorded determines payment. That is lawful and it is what the customer is buying, and it means the record carries a commercial objective at the moment of its creation that a reader years later cannot see.

No published material addresses safety engineering, guardrails or how a failure is handled.

The privacy policy acknowledges the rule applies and never states the company's status under it.

What is published is substantive on its own terms. The policy states that the company may receive protected health information when users use the services, explains that certain demographic and health information it receives may be protected health information as the rule defines it, and describes the restrictions the rule places on use and disclosure. It sets out disclosure categories, including to contractors and service providers used to support the business in compliance with the rule. The document reaches the service that handles patients rather than covering only the website, and it distinguishes provider account holders from patient account holders.

What is absent is any statement of that status. The phrase business associate appears nowhere in the published material, terms of service included. No agreement is offered, referenced or published, no execution path is described, and no scope statement says which parts of the platform fall inside one. Customers are provider organizations and health plans, which are covered entities, so agreements very likely exist contractually. None of that is visible from outside.

The architecture and the buyers named raise one structural point. Where an independent practice association or accountable care organization contracts on behalf of participating practices, nothing published says which entity holds the agreement, which entity is the covered entity for each patient, or how data is separated between participants who may compete with one another.

A trust center exists, opens without asking, and names one attestation without the detail needed to place it.

The company announces on its home page that it has achieved SOC 2, and links a hosted trust center from the footer. The portal is readable rather than a shell: it lists SOC 2 under compliances, carries a controls inventory grouped into product, data, network, application, endpoint and corporate security with more than thirty controls named, and publishes its own policy documents including a data protection policy and a code of business conduct. That is more than a badge and it is the company's own material rather than a cloud provider's.

What is missing is what a security reviewer would check first. The portal records SOC 2 as compliant, which is not how an attestation is described: no type is stated, so whether this is a Type I snapshot or a Type II covering a period is unknown, and no observation window, assessor or report is published. The report itself is not retrievable from the portal, which carries policies rather than the attestation.

Tenant separation matters most here, and the company's own description shows why. It deploys across large provider networks through a multi tenant architecture serving health systems, independent practice associations, accountable care organizations and management services organizations. Organizations of those types in one geography frequently compete for the same physicians and the same attributed patients, so a platform holding encounter level clinical data and coding analysis for several at once holds commercially sensitive material, not merely confidential material.

Kennar Health makes no device claim and scopes the product accordingly, which is the ordinary position for documentation and coding support.

The product captures the encounter, surfaces quality measure gaps and risk adjustment opportunities, and builds transition of care summaries. It does not diagnose, triage or direct treatment, and a clinician decides what to accept. No clearance is claimed and none appears in the public databases, which is appropriate rather than a gap.

The regime that actually governs is not a regulatory pathway. Federal risk adjustment rules and audit determine what may be submitted and what may be clawed back, and the company addresses that directly: it describes capturing conditions prospectively at face to face encounters, ties every code to an approved provider type, and states that its output meets encounter level evidentiary standards. Naming the rules it answers to counts in its favor, but no stated pathway is in progress and no clearance exists.

The real exposure is not a device question. Liability for a submitted diagnosis sits with the organization that submits it, not with the software that surfaced it, and the surfacing happens during the encounter rather than after it. No external accreditation, audit result or third party examination of the coding output was published, so the compliance argument rests on the company's own description of its method.

The compliance argument is the most useful thing published here, and it is an argument rather than evidence.

Asked how customer data survives a risk adjustment audit, the company answers with a mechanism. It captures conditions prospectively at face to face encounters with documentation support written to the criteria a reviewer applies, states plainly that retrospective chart review is the primary driver of clawback risk, and argues that a point of care model removes that exposure by design. It adds that every code traces to an encounter with an approved provider type, meeting encounter level evidentiary standards, and that output is standardized supplemental data rather than a manual submission. The distinction between capturing at the visit and mining records afterward is the one that matters most in this market, and the company states it plainly.

Three problems remain.

The company markets a specific risk score outcome, a 0.2 risk adjustment factor lift, published as derived from an average of two additional condition codes captured per encounter. That states the coding gradient as a target rather than a consequence, and a target expressed in codes per encounter is a number the product is being asked to reach.

Eliminating exposure by design is an absolute, and no audit outcome supports it. Nothing published records a customer whose submissions were tested in an actual audit.

And no fairness, subgroup or demographic performance disclosure of any kind was published, which matters on a product that also decides which quality gaps get surfaced and to whom.

A traceability mechanism is published and nothing stands behind the output.

What exists is real and it is aimed at the test this product will actually face. The company states that every code traces back to a face to face encounter with an approved provider type, that documentation support is written to satisfy the criteria a reviewer applies when deciding whether a record supports a condition, and that output is standardized audit ready supplemental data rather than a manual submission. That gives a payer, an auditor or the practice itself a defined path from a submitted code back to the encounter and the documentation behind it, which is what lets someone challenge an output rather than accept it.

What does not exist is any commitment or any measure. No accuracy figure for coding or gap detection, no error rate, no published limitations, no evaluation methodology, and no warranty, indemnity or remediation obligation was published. Four figures are published and none carries a denominator, baseline, population or measurement approach. Capture rate is the emptiest of them, because capture of what, against what reference standard and as judged by whom are all unstated, so the number can describe better documentation or simply more of it.

The structural point matters more than any single figure. The tool surfaces coding opportunities while the encounter is happening, and what gets recorded determines payment, so the record now carries a commercial objective at the moment of its creation that a clinician reading it years later cannot see.

Integration is claimed through a mechanism rather than through a named system, and nothing can be verified.

What is published: integration described as agnostic to the record system, seamless integration with leading record systems asserted in general terms, and an interface offered to digital health companies with published specifications so partners can consume structured clinical data captured at the point of care. The transitions of care function is described as pulling discharge data automatically and delivering summaries and follow up tasks back into the workflow, which implies a two way path. Supplemental data output is described as standardized and audit ready, which implies a defined submission format for payers.

What is absent is every particular. No record system vendor is named anywhere, no standard is cited, no marketplace listing exists, no interface documentation is published, and no customer deployment is identified, so an organization cannot establish whether its own systems are supported or what integration would involve. Naming the buyer types a platform deploys across is not the same as naming a system it connects to.

The partner interface is the one concrete mechanism and it points outward rather than inward: it describes how third parties consume data from the platform, not how the platform reaches into a record system.

A multi tenant hosted architecture is stated, which settles the delivery model and nothing else.

The company describes deploying across large provider networks through a multi tenant architecture serving health systems, independent practice associations, accountable care organizations and management services organizations. That establishes shared hosted infrastructure and rules out a customer hosted option, so a buyer knows the shape of what they would be joining.

Nothing further is published. No cloud provider, no region, no residency commitment, no tenancy isolation detail and no sub processor list appears on the home page, in the trust center, in the privacy policy or in the terms. The trust center names device encryption and network controls among its inventory, which describes control categories rather than where the platform runs.

Multi tenancy stated as a feature is honest and it makes the isolation question concrete rather than hypothetical. The tenants named compete with one another in many markets, so separation here protects commercially sensitive information as well as patient information: encounter level clinical data and coding opportunity analysis for rival networks would sit in the same platform.

A mobile application is also operated alongside the web platform, which adds a second client surface holding clinical content with nothing published about how it is provisioned or wiped.

No price, tier or pricing mechanism is published, and the route to finding out is a demand for a demonstration.

Nothing states whether the product is sold per provider, per encounter, per attributed patient, per network, or as a flat subscription, and no minimum or term is given. Before contact, the published material covers only the delivery model, a hosted multi tenant platform deployed across networks, and the buyer types served.

The way the product is marketed matters here. It is sold on a specific risk adjustment factor lift, published as derived from an average of two additional condition codes captured per encounter, which makes contingent pricing the live commercial question. No published term says whether any component of the fee varies with risk score movement, capture rate, codes captured or quality bonus. Where it does, the vendor earns more the more conditions are recorded, and the party paying is a plan or a network whose own revenue moves the same way.

That structure is not improper. A fee tied to capture volume and a product that surfaces capture opportunities during the encounter point the same direction, and the control that would balance it, a measured precision figure, is not published.

Coverage is described by who buys rather than by where the product works or what it treats.

Four audiences are named with a described offering each: clinicians and practices, independent practice associations and accountable care organizations and provider networks, health plans and payers, and digital health companies consuming the data through an interface. That is a coherent value based care footprint and it now reaches both sides of the transaction, since the same platform is sold to the organizations capturing conditions and to the plans paying on them. Transitions of care is the one named clinical workflow beyond the encounter itself, described as pulling discharge data and creating follow up tasks.

What is not stated is the setting. No specialty is named, no care setting is identified, and the ambulatory point of care focus is implied by the description of capture during a visit rather than stated anywhere. The site adds that segments not listed are also served, which widens the claim without supporting it.

Nothing validates any of it. No deployment is named in any segment, so a buyer cannot establish that the product has run in an environment resembling theirs.

The gap that matters most for this product is condition mix rather than specialty. Risk adjustment behavior differs sharply between a primary care panel, a complex specialty practice and a post acute population, and nothing says which the product has been used in.