emtelligent

The medical language engine is the entire company. Purpose built models trained on what the vendor describes as billions of clinical data points, developed by computer scientists working with physicians, and every product in the suite is a surface on that one engine. Infrastructure sold as an engine rather than as a finished application does not reduce centrality: Corti sits in the ambient scribe category on the same reasoning, graded A for owning the model despite selling through an SDK.

Oversight is the stated design goal rather than an afterthought. The chief executive frames the problem the product solves as prior systems having difficulty referencing source data reliably enough to allow proper human review, and the company markets auditable answers. Clinical Workflow is explicitly an AI assisted review interface for clinicians, coders and reviewers, so human review is the product surface rather than a step bolted on after generation.

Uncertainty detection is itself a form of calibrated output, since a system that marks a hedged finding as hedged is telling the reviewer where to look. Held at B for two reasons. No confidence threshold, routing rule, abstention behaviour or error rate is published.

And when the engine runs as embedded infrastructure inside someone else's platform, emtelligent does not control what oversight the downstream integrator applies, or whether the end user knows a third party engine produced the structured data. That is the same limitation this index recorded for SimboAlphus: a good primitive is not an oversight mechanism once someone else is holding it.

The best technical capability disclosure in this category, and it is checkable rather than atmospheric. Instead of claiming AI powered summaries, the company names the specific tasks its engine performs: entity linking to clinical ontologies, polarity and uncertainty detection, experiencer detection, measurement and temporality, relations, and medication identification with follow up detection. Those are the right things to name.

Polarity determines whether no evidence of pneumonia becomes pneumonia in a summary, and experiencer determines whether a mother's breast cancer becomes the patient's. They are the two failure modes most likely to corrupt a chart summary without anyone noticing, and no other vendor in this lane names either. Held at B rather than A because none of it is quantified: no accuracy figure, no benchmark result, no model card and no published evaluation exists for any of the named capabilities.

The marketing also carries unfalsifiable superlatives, the most accurate and feature rich medical AI platform on the market and unparalleled accuracy, and clinical grade is a coinage with no standard behind it. Publishing per capability accuracy, particularly on negation and experiencer, would move this to A immediately and would set the benchmark for the category.

The deployment architecture is the substantive answer here and it is a good one for one of the routes on offer. Products can be deployed in the vendor's environment, in the customer's own environment, or in a private cloud, so an organisation can process clinical text without it leaving infrastructure it controls, and that is engineered privacy rather than a policy promise, in the same class as the on premises options credited elsewhere in this index.

It is the strongest structural position located in this category. The limit is that it is one option among three and the vendor hosted default carries none of the protection, so a buyer's actual exposure depends entirely on which line of the order form they signed, and two customers of the same vendor can be in completely different positions. Establish which deployment applies to your contract before relying on anything here.

On enumeration there is nothing for the hosted routes: no model or model family named, no hosting provider, no sub processor list, no retention period and no statement on whether customer data is used to train or improve models, which matters for an engine whose named capabilities are the sort that improve with more annotated clinical text. Ask which deployment, and for the hosted route ask for the provider, sub processors, retention and the training position.

Commercial traction stated without a published measure of benefit, which this index grades C. Optum is described as a beta customer, which is a meaningful named reference given its scale, and the company reports traction with real world evidence companies and data resellers serving pharma. Against that, no accuracy benchmark, no peer reviewed evaluation, no independent assessment and no named health system deployment with outcome data was located.

For a product whose whole claim is superior extraction accuracy against general purpose models, the absence of a published comparison is the gap that matters. Ask for a head to head on a held out corpus with the error taxonomy broken out.

The deployment architecture is the substantive privacy answer here and it is a good one. Products can be deployed in the vendor's environment, in the customer's own environment, or in a private cloud, which means an organisation can process clinical text without it leaving infrastructure it controls.

That is engineered privacy rather than a policy promise, in the same class as on device or on premise processing elsewhere in this index, and it is the strongest structural PHI position in this category so far. Held at B rather than A because no retention period, no statement on whether customer data is used to train or improve models, and no de identification posture was located, and because the default vendor hosted option carries none of the protection the customer hosted option does. Establish which deployment applies to your contract, because the PHI posture differs completely between them.

A second pass again located no compliance statement and no business associate agreement terms. The two complications the earlier assessment identified both stand, and the second pass adds a third that changes who the counterparty is.

The vendor sells to health insurance carriers as well as providers, and describes giving them a view of the health and risk of their members that was previously obtainable only through manual chart review. That is a materially different relationship from serving a health system. A payer processing member records for risk assessment is operating under its own basis for use, the permitted purposes differ from treatment, and the sensitivities are different: information read to establish a member's risk profile affects payment and enrolment economics rather than the care in front of a clinician.

So a buyer cannot read across from one side of this business to the other. Establish which relationship applies to you, and what the agreement permits for each.

The cross border question remains and is not resolved. A Canadian company processing United States protected health information is a permitted arrangement that must be papered, and where any processing or support access happens outside the United States a buyer should see how.

The embedded chain question also remains. Where the engine sits inside another vendor's platform, the agreement runs through that platform rather than directly, so ask who signed what and with whom, and what happens to your data if that supplier relationship ends.

Ask for the agreement, the processing and support locations, and the position on payer side use.

A second pass located no attestation and no trust centre.

The deployment point from the earlier assessment is the substance of this axis and should be pressed exactly as framed: with multiple deployment modes including a customer hosted option, the vendor's controls cover different ground in each, and an attestation shown for the hosted service describes a boundary a self hosting customer is not inside. Establish which controls the vendor attests to per mode rather than treating the answer as uniform.

Two features of the business enlarge what an examination would need to cover.

The engine processes at volume across whole record estates rather than per encounter, with the company describing throughput in millions of reports a day. Scale of that kind changes the character of a breach: the exposure is a corpus rather than a caseload.

And the customer base spans providers, payers, researchers and other software companies embedding the engine. Each brings different access patterns and different data flows, and an attestation scoped to one may say little about the others.

The company has operated since 2016 with named clinical and academic leadership and sells to enterprise health systems and insurance carriers. Buyers of that kind run their own security reviews as a matter of course, so assessments of this vendor almost certainly exist privately. The gap is publication rather than, most likely, posture.

One clarification worth making: the auditability and source traceability the vendor markets are product capabilities that support clinical review. They are not security controls and should not be counted on this axis.

Ask which report is held, its scope, and which deployment modes it covers.

No clearance, device authorisation or pathway statement was located, and the earlier assessment named the right place to press. The second pass adds one genuine credit and sharpens the boundary.

The credit is a design principle the vendor states plainly and repeats: its applications always offer clinicians links back to the source data in the patient's record, and it describes its assistant as producing auditable answers. That is the condition the conditional exemption for clinical decision support actually turns on. Software qualifies where a professional can independently review the basis for a recommendation rather than relying primarily on it, and traceability to the source document is precisely how that is achieved. Most vendors in this index leave the condition unaddressed; this one has built for it, whether or not it framed the decision in regulatory terms.

The boundary still needs establishing for the radiology applications, and it is finer than it looks. Extracting and structuring what a radiologist wrote, including their own statement that a finding is abnormal, is structuring. Determining that a finding is abnormal would be interpretation, and that is regulated territory. A follow up detector sits somewhere else again: identifying recommended follow up in a report and surfacing it is a recognised patient safety intervention, since lost follow up recommendations cause delayed diagnoses, and its failure mode is a missed recommendation rather than a wrong one.

Those three warrant different answers and a buyer should not accept one for all.

Ask which analysis the company has performed for the radiology applications specifically, and to see it written down rather than inferred from the platform's general positioning.

Credit first, because the framing is genuinely more honest than the category norm. The company states plainly that unaligned generative models are not accurate enough for medical use, names hallucination and non determinism as real problems rather than competitor problems, and identifies unreliable source referencing as an obstacle to human review. Very few vendors describe the weaknesses of their own technology class in their own marketing.

Against that, no fairness, subgroup or demographic performance disclosure of any kind was located, no error analysis is published, and the accuracy claims are superlatives rather than measurements. One structural point specific to infrastructure vendors deserves recording: when this engine sits inside a data aggregator feeding downstream analytics used in payer and life sciences decisions, any systematic extraction error propagates into decisions made by parties who may not know the engine is in the stack and cannot evaluate it. The absence of published subgroup performance matters more in that position, not less.

Naming the specific failure modes a system handles is a form of limitation disclosure, and this vendor does it better than anyone else in its category. Rather than claiming summaries powered by artificial intelligence, it names the tasks its engine performs: entity linking to clinical ontologies, polarity and uncertainty detection, experiencer detection, measurement and temporality, relations, and medication identification with follow up detection.

Two of those are the right things to name. Polarity determines whether no evidence of pneumonia becomes pneumonia in a summary, and experiencer determines whether a mother's breast cancer becomes the patient's. Those are the two errors most likely to corrupt a chart summary without anyone noticing, because both produce fluent plausible text, and naming them tells a reviewer exactly what to check. No other vendor in this lane names either.

Held at C because none of it is quantified: no accuracy figure, benchmark result, model card or published evaluation exists for any named capability. The same material carries unfalsifiable superlatives about being the most accurate platform on the market and offering unparalleled accuracy, and clinical grade is a coinage with no standard behind it, so the disciplined technical description and the marketing sit awkwardly together. Publishing per capability accuracy, particularly on negation and experiencer, would set the benchmark for this category. Ask for exactly that.

Interoperability here means standards and formats rather than EHR embedding, and on that measure it is solid. Extracted concepts are mapped to clinical ontologies with ICD-10 and SNOMED searchable directly, structured output is designed to feed downstream systems, and Document Manager ingests bundled PDFs, paper forms and complex documents rather than requiring clean structured input. The engine is proven as an embedded layer inside larger aggregator platforms.

Held at B because no EHR vendor is named anywhere, no EHR integration mechanism is described, and this is not a product a clinician opens inside the chart. For a health system evaluating the summarisation offering rather than the engine, establish how output actually reaches the care team.

The first A on this axis in this category and the only vendor here offering real choice. Products can be deployed inside the vendor's environment, inside the customer's own environment, or in a private cloud. That means an organisation can decide that clinical text never leaves infrastructure it controls, which is the property this index credits as the ambient instance of the where does the data go frame, and which Corti holds in the scribe lane.

Every other product reviewed in this category is hosted software with no alternative. Two gaps keep this from being a complete answer and should be raised in diligence: no residency regions are named for the vendor hosted option, and no portability commitment is described, so a buyer should confirm what happens to extracted structured data and ontology mappings if the relationship ends.

No price, tier or pricing mechanism is published for any product in the suite.

Pricing is likely to vary substantially across the three deployment modes and between direct and embedded distribution, so a buyer should establish which model applies before comparing this to anything else in the category.

Broad by buyer type rather than by clinical specialty, which is the correct shape for an engine. Four distinct markets are served: payers, health systems, pharmaceutical and life sciences companies, and health technology and data services providers. Named use cases span chart review, care gap identification, patient transitions, quality improvement, coding support, actuarial analysis, population cohort work and real world evidence.

Radiology specific applications exist in the developer suite. Graded B rather than A because the specialty depth stops at radiology and because the breadth comes from a general engine applied across markets rather than from instrument level behaviour in any one of them.