Huma

A regulated platform that hosts intelligence, shipping some intelligence of its own.

The distinguishing asset is stated plainly by the company and is not algorithmic. What makes this platform valuable is that it is cleared as a configurable framework across six jurisdictions and can be assembled into a working regulated product with no code in weeks. A partner buys the clearance and the configurability. The platform is described as regulated to accept artificial intelligence and machine learning models, which is precisely the language of infrastructure that carries someone else's models.

Huma does ship its own intelligence, and it is real rather than nominal. A generative clinical documentation product and an agentic layer are named offerings, validated algorithms are referenced, and a triage application is deployed in a hospital emergency department. Those are genuine model driven products.

But a health system deploying a configured disease management pathway on this platform may be running data collection, thresholds and workflow with little inference involved, and the same platform serves that customer as serves one running generative documentation. The intelligence is optional to the product in a way it is not for the imaging and sensing vendors graded higher in this index.

Graded C rather than lower because proprietary models ship and are deployed, and rather than higher because the regulatory wrapper, not the algorithms, is what the company leads with and what partners are buying.

Clinical behaviour is configured by the partner, which relocates the oversight question rather than answering it.

The platform's defining property is that partners assemble their own regulated tools from modules with no code. What a deployed application does, when it escalates, what thresholds it applies and what a clinician sees are therefore set by the configuring organisation, not by Huma. That is a coherent model and it means the vendor cannot describe a single oversight posture, because there are as many as there are configurations.

What that architecture requires, and what is not published, is the guardrail layer. Nothing describes what configurations are permitted, what clinical safety review a partner's configuration undergoes before going live under the inherited clearance, or what the platform prevents a partner from building. Inherited clearance is only as safe as the weakest configuration deployed under it.

Two named products sharpen the question. An emergency department triage application makes acuity relevant suggestions in a setting where error is time critical, and an agentic layer implies software taking actions rather than presenting information. Neither carries a published description of what it decides autonomously, what a clinician must confirm, or what it is prevented from doing.

No operating point, sensitivity, escalation protocol or human review requirement was located for any Huma model.

Ask what clinical safety review a partner configuration undergoes, what the agentic layer is permitted to do unaided, and the triage application's operating characteristics.

The platform architecture is described clearly and the models running on it are not.

Architectural disclosure is good. Five layers are named covering remote monitoring, decentralised trials, clinical documentation, an agentic layer and consumer virtual care. The configuration mechanism is described concretely as no code assembly from a library of pre built modules with device connectivity, a development kit is offered for embedding, and the hosting framework is characterised as cloud agnostic. A technical buyer can understand how the platform is put together.

The model layer is characterised only by label. Validated algorithms are referenced without a single performance figure. The generative documentation product and the agentic layer are named without architecture, evaluation or accuracy data, and no base or foundation model is identified for the generative component, which for a clinical documentation tool is the first question a reviewer asks. No model card exists for anything.

One disclosure would be more informative here than a model card and is absent. Because the platform hosts partner models, what the platform requires of a model before it may run, what validation evidence a partner must present, and what monitoring the platform performs on hosted models would describe the governance of the whole ecosystem rather than one algorithm.

Graded C because architecture is genuinely transparent while every model claim is unquantified.

Ask for performance data on Huma's own algorithms, the base model behind the documentation product, and the requirements placed on hosted partner models.

The infrastructure layer is partly named and the model layer is not, in a product explicitly built to run other people's models.

What is established is real. A major cloud provider is named as host for a documented deployment, the framework is described as cloud agnostic so provider dependency is deliberately loose, and device connectivity to named categories of third party instrument is a designed capability. A quality management certification implies documented supplier controls.

What is undisclosed is the model chain, and it has two halves here rather than one. Huma's own generative documentation product almost certainly rests on a third party foundation model, since building one is implausible at this scale, and none is named, so a partner cannot determine which provider processes clinical conversations. And the platform is expressly regulated to host artificial intelligence models supplied by partners, which means the supply chain for any given deployment includes parties Huma did not choose and may not disclose.

No sub processor register was located, and no statement addresses whether data collected across the platform contributes to development of Huma's own models, which matters given more than 1.8 million active users and 650,000 research participants.

The inheritance model makes this more consequential than usual, because a partner adopting the platform inherits its dependencies alongside its clearance without a published list of either.

Ask for the sub processor register, the base model behind the documentation product, and whether platform data trains Huma models.

An enormous deployment footprint and a substantial research record, most of which evidences the platform as a vehicle rather than the platform as a treatment.

The scale is not in doubt. Company material reports more than 3,000 hospitals and clinics, over 1.8 million active users in care delivery and more than 650,000 research participants, with software built on the platform across more than 70 countries. Named deployments include an emergency department triage system in a London hospital and disease management programmes in national health service settings.

The research portfolio is genuinely impressive and independently anchored. A decade long oncology real world evidence study translated longitudinal data into peer reviewed output. A lung cancer screening programme used the platform to validate an established risk model, work described as forming a national screening blueprint in Germany for 2026. A non interventional insomnia study ran across two countries for a pharmaceutical sponsor. A kidney and diabetes programme recruited 4,500 patients a full year ahead of schedule, which is a concrete operational result rather than an impression.

The distinction that holds this at B is what those studies demonstrate. They show the platform reliably captures data at scale and accelerates recruitment, which is real and valuable. They largely do not show that Huma's own algorithms improve clinical outcomes, because in most cases the platform is the instrument and something else is the subject.

No performance figure for any Huma model was located.

Ask for outcome evidence attributable to Huma's own algorithms, and for triage performance data from the emergency department deployment.

Genuinely detailed controls, documented where a buyer would never look.

The substance is strong. A clinical trial protocol sets out that data collected on the platform is hosted in the United Kingdom on a named major cloud provider, that all communications are secured by transport layer encryption, that encryption at rest follows recognised national cryptographic standards, that key management runs through the cloud provider's service with key rotation performed, and that least privileged permissions are applied to services. Alongside sit a national health service data security certification with a checkable organisational code and a quality management certification whose risk management plan covers data security, business continuity, disaster recovery and corrective action.

That is a more complete picture than most vendors in this index publish anywhere.

The problem is findability. Every element above appears in a research protocol filed for a specific study, not in customer facing material, and no trust centre, security page or data handling statement exists on the company's own site. This index grades disclosure, and disclosure a prospective buyer cannot locate during diligence is disclosure that only partly counts.

One substantive gap remains regardless of location. Nothing addresses whether data collected through the platform contributes to model development, which matters more here than usual because the platform hosts artificial intelligence models and the company also ships its own.

Ask for a customer facing data handling statement, confirmation that the documented controls apply platform wide, and the training data position.

A well documented European and United Kingdom position, and no United States posture despite substantial United States presence.

What exists is specific and verifiable. Certification under the national health service data security and protection toolkit is held with an organisational code that can be checked against a public register, which is a stronger form of disclosure than a badge because a third party can confirm it independently. European operation across multiple member states implies compliance with European data protection law, and the platform holds European medical device certification requiring documented data governance. A quality management certification carries a risk management plan explicitly covering data security and protection, business continuity and disaster recovery.

What is absent is the United States. The company holds United States clearance, maintains New York operations and serves United States health systems, and no federal health privacy statement, business associate agreement template or execution requirement was located.

The configurable model creates a further question this index has not encountered elsewhere. When a partner configures the platform for its own patients under inherited clearance, whether Huma is a business associate, a subcontractor, or outside the chain entirely depends on architecture and contract, and nothing published resolves it. A partner assuming the clearance transfers may also assume the privacy posture transfers.

Ask for the agreement template, the United States privacy position, and how obligations divide between Huma and configuring partners.

Two real certifications, one of which is frequently mistaken for something it is not, and no information security attestation.

What is held is genuine. Certification under the national health service data security and protection toolkit carries an organisational code verifiable in a public register, which is stronger than an unattributed claim and is a meaningful credential for United Kingdom public sector deployment. A quality management certification is also held, with a risk management plan documented as covering data security and protection, business continuity and disaster recovery.

The distinction this index insists on applies directly. That quality management certification governs medical device design, development and manufacturing discipline. It is not an information security standard, and its presence alongside a data security toolkit certification can read as two security credentials where there is one and a half.

What is absent is the credential international buyers expect. No information security management certification and no service organisation controls report was located, despite United States clearance, New York operations and deployment across more than 70 countries. The health service toolkit does not travel outside the United Kingdom.

No trust centre, security page, penetration testing statement or vulnerability disclosure policy exists on the company's own site, and the clearest security documentation available sits inside a clinical trial protocol.

One pre emptive note: further regulatory clearances cannot move this grade, since device regulation and information security are different regimes.

Ask whether an information security certification is held or in progress, and what documentation is available under agreement.

Simultaneous clearance in six jurisdictions for a configurable platform, which is a regulatory structure no other record in this index approaches.

The holdings are United States Class II under the 510(k) route, European Union Class IIb under the current medical device regulation, United Kingdom Class IIb registration, plus Australian, Saudi and Indian approvals, with a Canadian Class II licence obtained subsequently. European Class IIb is a high risk software classification, and the current European framework is materially heavier than the directive it replaced.

The more interesting achievement is what was cleared. Regulators authorised a disease agnostic, device agnostic, configurable framework rather than a fixed product, permitting monitoring of patients of any age with any condition including paediatrics and pregnancy, and explicitly regulated to host artificial intelligence and machine learning models. Persuading multiple regulators to clear a configurable container is a substantially harder argument than clearing a single indication, because the applicant must demonstrate that safety holds across configurations it has not yet built.

The commercial consequence is the inheritance model: partners deploy under Huma's clearance instead of running their own programme.

That model also carries the unresolved question worth asking. Where responsibility sits when a partner configures the platform into something unsafe, and who is the manufacturer of record for that configuration, is not described publicly and is the central governance question of this architecture.

Ask for the clearance numbers and indications, and how configurations are controlled under the inherited clearance.

Regulatory review across six jurisdictions constitutes governance of a kind, and no fairness evidence accompanies it.

What supports the grade is structural rather than analytical. Clearance in six jurisdictions means six regulators examined the platform's risk management, and a quality management certification carries a documented risk management plan with corrective and preventive action processes. Algorithms are described as validated. That is more institutional oversight than most vendors here are subject to.

What is absent is measurement. No fairness testing, no performance broken down by any subgroup, no calibration data, no drift monitoring and no external algorithmic audit was located.

The platform architecture creates a governance question that is specific to this vendor and larger than its own models. Because the platform is regulated to host artificial intelligence models and partners configure their own tools, models built by third parties run under Huma's clearance. Whether those partner models are assessed for bias, what evidence a partner must supply before deploying one, and who is accountable for a partner model that performs unevenly across populations are all unaddressed. Inherited clearance without inherited governance is the gap.

The breadth compounds it. A platform cleared for all ages, all conditions and more than 70 countries spans populations differing in ancestry, language, comorbidity and device access, and a configurable tool validated in one setting carries no assurance in another.

Ask what bias assessment partner models undergo before deployment, and for subgroup performance on Huma's own algorithms.

Nothing contractual is published, and the inheritance model raises an allocation question this index has not seen before.

A dedicated pass located no service level agreement, no accuracy warranty, no uptime commitment, no indemnity and no remediation position.

The novel question is who is responsible for a configured product. Partners deploy their own tools under Huma's clearance, so when a configured application harms a patient, responsibility could rest with the partner that designed the pathway, with Huma as the cleared platform holder, or be divided in a way no public material describes. Regulatory clearance ordinarily attaches to a manufacturer with defined post market obligations, and the whole commercial proposition is that partners avoid becoming that manufacturer. Where the duty actually lands is the central unanswered question of the model.

The hosted model layer compounds it. Partner artificial intelligence runs on the platform under the same clearance, so a partner model performing badly is operating inside a regulated envelope Huma holds.

Availability is a further gap. A platform carrying remote monitoring for over a million users, emergency department triage and active clinical trials has real time dependencies, and no uptime commitment or availability history is published.

One pre emptive note: further clearances or deployments cannot move this grade. Only contractual terms, or a published allocation of responsibility between platform and partner, will.

Ask who is the manufacturer of record for a partner configuration, how liability divides, and the availability commitment.

Device interoperability is a designed and cleared property, and record system integration is unaddressed.

The device side is genuine and unusually strong. The platform is device agnostic as a matter of regulatory scope rather than marketing, connecting to third party instruments including heart rate monitors, glucose monitors and smart inhalers, and device connectivity is described as a built in platform capability rather than a per deployment integration. A development kit allows partners to embed functionality into their own applications, which is an interoperability posture in the other direction. One case study describes unifying fragmented systems into a single care flow in a hospital emergency department, which implies real integration work in a demanding environment.

The clinical record side is absent. No electronic health record is named, no interface standard such as HL7 or FHIR is described, no marketplace or validated integration listing was located, and nothing states whether monitoring data, triage outputs or generated documentation post to the patient record.

That gap matters most for the documentation product. A clinical documentation tool that does not write into the record is a drafting aid requiring transcription, and whether it writes back is the difference between the two.

The configurable model may explain the silence, since integration is plausibly a partner responsibility, and that would itself be worth stating.

Ask which record systems are integrated in production, through what standard, whether the platform or the partner builds those interfaces, and whether generated documentation writes to the chart.

Hosting flexibility is a stated platform property and one regional deployment is documented concretely.

The cloud agnostic framework is described as a designed capability rather than an aspiration, meaning the platform is not bound to a single provider, and that is the right architecture for a company operating under six regulatory regimes with divergent data location requirements. A documented instance confirms it works in practice: a national health service deployment is recorded as hosted in the United Kingdom on a named major cloud provider, with the physical infrastructure managed by that provider.

Operation across more than 70 countries with clearances spanning North America, Europe, the Middle East and South Asia implies regionalised deployment as a matter of necessity, since several of those jurisdictions impose data localisation.

What is missing is a general commitment rather than an instance. No published residency policy states where data sits by default or by region, no tenancy or segregation model is described for a platform serving many partners, and no continuity or recovery position is published outside a research protocol.

One question follows from the model and is unanswered. Whether a partner configuring its own application chooses its own hosting region, or inherits Huma's, determines who carries the residency obligation, and a partner inheriting clearance may reasonably assume it inherits compliant hosting too.

Ask for the residency policy by region, the tenancy model, and whether partners select hosting location.

Cost is absent from every published surface, against a commercial proposition that is explicitly an economic argument.

Two dedicated passes located no pricing page, no unit of charge, no range, no tiering, no implementation fee position and no minimum commitment.

The omission bites harder here than for most vendors because the pitch is avoided cost. The platform is sold on partners inheriting regulatory clearance instead of running their own approval programmes, and on configuration taking weeks where independent development and certification would take years. Both halves of that trade are unquantified: neither what the platform costs, nor what the regulatory programme it displaces would have cost. A partner is asked to accept a saving whose size is not stated against a price that is not stated.

The buyer spread makes a single unit implausible. Hospitals, national health systems, pharmaceutical sponsors and research programmes price on entirely different bases, and the platform serves all of them across monitoring, trials, documentation, triage and consumer care.

The development kit adds another axis, since a partner embedding functionality into its own product is a different relationship from one deploying a configured application.

One structural factor probably explains the silence. The value of inherited clearance scales with how many jurisdictions a partner needs, so the same platform is worth very different sums to a single country health service and a global sponsor, which points to negotiated pricing.

Ask for the unit of charge by buyer type, development kit licensing, and the minimum term.

The broadest coverage in this index, and unusually it is guaranteed by regulatory scope rather than asserted in marketing.

The clearance itself is the coverage claim. United States Class II status was granted for a disease agnostic platform permitted to monitor patients of any age with any condition, explicitly including paediatric patients and pregnancy, and the platform is device agnostic, connecting to third party instruments such as heart rate monitors, glucose monitors and smart inhalers. Most vendors in this index list the conditions they address; this one holds an authorisation that does not enumerate them.

Geographic reach matches. Six jurisdictions carry simultaneous clearance across North America, Europe, the United Kingdom, Australia, the Middle East and South Asia, with a Canadian licence added subsequently, and software built on the platform operates in more than 70 countries. Very few health technologies in this index have satisfied more than two regulators.

Use case coverage is equally wide and evidenced rather than claimed, spanning remote monitoring, decentralised clinical trials, clinical documentation, emergency department triage and direct to consumer virtual care, with published case work in oncology, lung cancer screening, insomnia, neonatal and paediatric critical care, kidney disease, diabetes and cardiology.

The honest qualification is that breadth is the product rather than a proof of depth, and configurability means a partner supplies the clinical specificity.

Ask which therapeutic areas have the deepest deployed footprint, and what a partner must supply to reach clinical quality in a new one.