Sporo Health

A multi agent architecture built on fine tuned medical language models is the product, and the company frames its differentiation explicitly as not using general purpose models. The chart review and cardiology workflow agents are further model work rather than software wrapped around one.

The oversight expectation is published in terms, which is more than an assertion that a human is in the loop.

The vendor's customer facing artificial intelligence policy states that its systems assist rather than replace clinicians, and sets out what the clinician must do: exercise professional judgment, review and verify outputs, review and confirm every generated output before it enters the clinical record, maintain independent judgment, and report errors and discrepancies. It names overreliance on the system as a risk for the customer to manage rather than a problem it has solved.

An escalation path exists and is described. Users report issues through a feedback mechanism, and errors escalate to an incident response team identified by officer role for root cause analysis and mitigation. A route with named owners is a control; a support address is not.

The system's own limits are published alongside it: errors in ambiguous or edge cases, fabricated information in complex ones, and dependence on input quality.

One part is missing. Nothing published states the condition under which the system itself stops, declines or flags low confidence. The oversight described is entirely the clinician's duty to check, with no threshold at which the product routes a case to a person on its own initiative. For a product that generates a note in under two minutes, the practical question is whether anything in the system distinguishes a routine encounter from one it handled badly.

Explicit about method, and gated about substance.

The architecture is described in real terms as a multi agent system of fine tuned medical language models running on private instances per client, with the vendor arguing openly against general foundation models as too resource intensive, too generic and prone to fabrication. Two comparative evaluations set out the metrics used, the ground truth and the quality instrument, so the basis of the vendor's performance claims can be read rather than taken.

More is stated to exist and not published. The customer facing artificial intelligence policy says training data documentation covering sources, diversity, limitations and gaps in language coverage is available, that performance metrics including accuracy, false positive and false negative rates and confidence intervals are maintained, and that version histories with impact assessments are kept. All three are offered for review on request or to regulators rather than published. That is a real posture, but it is a promise of documentation rather than documentation.

No base model or family is named, so what the models were fine tuned from is unknown. No provider, version, update cadence or model card is published.

The central commitment is architectural: private model instances for each client, so one customer's content does not commingle with another's model. That is the strongest structural answer available short of self hosting, and it resolves what would otherwise be a tension in the design, because the system learns from clinician edits and those edits improve the client's own instance rather than a shared model.

What crosses between customers is foreclosed by architecture rather than by promise. The architecture is also described in real terms as a multi agent system of fine tuned medical language models, which tells a buyer the shape of what is running even without naming it. Yet nothing is enumerated, and the central claim is asserted rather than evidenced.

No base model, provider, version or hosting arrangement is named, no subprocessor list is published, the specialized training data is characterized only in general terms, and the per client isolation is a statement rather than something covered by an attestation a buyer could read.

Real evidence with a comparator problem.

There are two published papers. The first, arXiv 2410.15528 from October 2024, compares the vendor's scribe against OpenAI's GPT-4o Mini. The second, arXiv 2411.06713, compares it against four models at once: GPT-4o, GPT-3.5, Gemma-9B and Llama-3.2-3B. Both use de identified patient transcripts from partner clinics with clinician written notes as ground truth, scored on clinical content recall, precision and F1, supplemented by satisfaction ratings on a modified version of a validated documentation quality instrument.

The broader study includes a frontier model, and the vendor leads the aggregate rating in it.

The limitation is that every comparator in both papers is a general purpose language model prompted to write a note. None is a competing medical scribe. Outperforming an unspecialized model is close to the expected result for a fine tuned medical system, and neither paper establishes anything about how this product compares with the scribes it competes against.

One detail in the vendor's own published table cuts against the summary claim. On the hallucination dimension of the quality instrument, the vendor's scores are level with or below several of the models it beats overall. It leads on the total and does not lead on that item.

Both studies are vendor authored preprints, not peer reviewed, and the satisfaction ratings come from two raters, one a medical student.

The strength is the documented method, the named instrument and readable results, not the finding.

One architectural commitment does real work here: private model instances for each client, which means one customer's content does not commingle with another's model. That also resolves what would otherwise be a tension, since the system learns from clinician edits. Those edits improve the client's own instance rather than a shared model, which is a coherent design rather than a training pipeline. HIPAA and GDPR compliant architecture with end to end encryption is claimed alongside.

Neither a retention schedule for audio or transcripts nor a de identification practice appears in the published policies, and the per client isolation claim is stated rather than evidenced by an attestation.

What is published is a compliance claim rather than a statement of the relationship.

The vendor states it employs a health privacy and European data protection compliant architecture with end to end encryption, secure storage and access controls, and displays a health privacy badge graphic on its site. None of that establishes the contractual position. Business associate status is nowhere stated, no business associate agreement is offered, referenced or described, and no scope or tier is given.

The badge looks like more than it is. There is no certification against the United States health privacy rule, so a compliance badge for it is a graphic a company applies to itself rather than an assessment anyone performed. The same is true of the compliant architecture phrasing: it describes a design intention, not a signed obligation.

The site footer carries terms and conditions, a privacy policy, a customer facing artificial intelligence policy and a separate publisher privacy policy. The business associate agreement is not among them, and the customer facing policy addresses clinician responsibilities rather than the vendor's obligations as a business associate.

This is a young company, and the absence is more likely an early stage gap than a considered position.

No attestation of any kind is named or dated. There is no report against a recognized framework, no certification, no trust portal and no independent assessment of controls anywhere in the vendor's published material.

What the vendor publishes instead is architectural rather than examined: a health privacy and European data protection compliant architecture, end-to-end encryption, secure storage, access controls, and private model instances for each client. The last of those is the most substantive claim. A dedicated model instance per customer is a real isolation posture if implemented as described, and a strong structural statement for a company of this size. It remains a description of a design rather than an examination of controls.

The compliance badge graphics displayed in the footer are not assurance. There is no certification against the United States health privacy rule, so that badge is self-applied, and the European one describes a regime rather than an audit.

One thing does point the other way. The company has put its documentation quality through comparative evaluation in published papers using a validated instrument, and publishes a policy naming its own failure modes. That is evidence about product quality and candor rather than about security posture, a separate question, but it indicates a company willing to be measured.

The stage of the company matters: it was founded in 2024, and a full attestation program is a material cost at that size. The gap is in what a counterparty can verify before contracting, which is not the same as controls being absent.

The documentation product claims no clearance, and none is published. No United States device pathway attaches to a note the clinician reviews and signs.

A second source confirms how the cardiology workflow is described: it covers echo interpretation, note generation and risk stratification. Echo interpretation is diagnostic and risk stratification is prognostic. Neither is documentation, and both sit in territory where software is ordinarily regulated as a device rather than treated as a productivity tool. Nothing published resolves it: no clearance, no statement scoping the cardiology functions as clinician performed with the software assisting, and no description of what the system actually produces for an echo study. Interpreting the study and organizing a clinician's interpretation of it are different regulatory objects wearing similar marketing language.

Markets are the second open question, and they matter more here than for a pure scribe precisely because of that module. The company is United States based and recently founded, multilingual support is claimed, and third party listings enumerate European languages including German and Greek. Ambient documentation is treated as software as a medical device in the United Kingdom and European Union, and a cardiology interpretation function would classify higher there than a scribe would. Nothing published says which markets are actually served, so the United States position may be only part of the picture.

Third party material about this product is unreliable on identity. At least one directory attributes it to a different company entirely, and a similarly named scribe comes from an unrelated vendor, so material carrying the name may describe someone else.

The vendor publishes a customer facing artificial intelligence policy in its site footer, written for the people who have to evaluate the product. It names what each system does and states plainly that the tools assist rather than replace clinical judgment. It then names its own failure modes rather than describing benefits: outputs may contain errors in ambiguous or edge cases, the system may generate fabricated information in complex cases, models trained on biased data may reflect or amplify those biases, and output quality depends on input quality. It separately lists the risks that follow, including falsified information, missed critical details, inequity across patient demographics and clinician overreliance.

A named process sits behind it. User reported errors escalate to an incident response team identified by officer role, with root cause analysis and mitigation. Training data documentation covering sources, diversity, limitations and gaps in language coverage, performance metrics with confidence intervals, and version histories with impact assessments are each stated to exist and to be available for review on request.

The evaluation itself is not published. Fairness tests and subgroup analyses are stated to be conducted; no method, no subgroup breakdown and no result appears. For a product marketed across English, German, Spanish, Hindi, Greek and Arabic, recognition performance by language and accent is the specific number that is missing.

The document was last modified in January 2025.

The vendor has published how it measures itself, and said what the measurement was.

Two comparative evaluations describe the architecture as a multi agent system of fine tuned medical language models and assess output against clinician written notes as ground truth, using clinical content recall, precision and F1, supplemented by satisfaction ratings on a validated documentation quality instrument. Naming the metric, the ground truth and the instrument is a different order of disclosure from publishing a percentage: it says what was measured, and therefore what the result would mean if it were reproduced or contradicted. It also gives a customer something specific to hold the vendor to and something specific to run again.

The published artificial intelligence policy adds to this rather than repeating it. It states outright that outputs may contain errors in ambiguous cases, that the system may generate fabricated information in complex ones, and that models trained on biased data may reflect those biases. A vendor writing its own failure modes down in a customer facing document has made a falsifiable statement about its product.

Three limits remain. Both papers are preprints rather than peer reviewed work, so the method has not been through external scrutiny. No ongoing accuracy figure for the shipping product is published, so the evaluations describe versions at a point in time rather than what a customer receives today. And none of it is a commitment: no warranty, indemnity or remediation obligation attaches to any published figure.

A named record system integration is shipping as a product rather than being claimed in the abstract.

The vendor is a published athenahealth Solution Partner and sells two athenahealth specific products in its own product menu: a Google Calendar sync and a Microsoft 365 Outlook Calendar sync. Those are named, specific and purchasable, which is a different thing from the record system logo wall the marketing site also carries. The company additionally publishes an API service and a substantial run of practical athenahealth workflow material on its blog, detail that very likely comes from people who work inside that system rather than adjacent to it.

The verified integration is scheduling and calendar data. It is not the clinical note path. How the scribe's output reaches athenahealth or any other record system, whether that write is automated or copied by the clinician, and whether any of it is bidirectional are all undocumented.

Elsewhere the position is a claim. The platform is described as record system agnostic and the site displays logos for Epic, Cerner, eClinicalWorks, NextGen and Meditech. A logo is not an integration, and none of those carries a marketplace listing, integration documentation or a named deployment.

That leaves one named system with a real shipped integration and a partner listing, and the clinical write path unevidenced everywhere, athenahealth included.

Private model instances per client is a deployment architecture rather than a policy, and it is the substantive claim here: as described, isolation is structural rather than a promise to keep data separate inside a shared system. No hosting region, residency option or subprocessor detail is published, and GDPR compliance is claimed without a stated European hosting arrangement.

Pricing is not published: there is no rate card, tier structure or pricing model, though self serve account creation exists. For a vendor otherwise willing to publish evaluation methodology, the absence of any published price is an odd asymmetry.

Specialty adaptation is the design rather than a template library: agents are described as adapting to each clinician's specialty, with primary care, rheumatology and emergency medicine named as target settings chosen for high turnover and constrained conditions, and cardiology addressed through a separate workflow. Language coverage names English, German, Spanish, Hindi, Greek and Arabic among others. No specialty count is published, and the named settings are aspirations as much as documented deployments.