Averbis

Language processing is the entire business. There is no record system, workflow platform or service layer underneath, and every product in the portfolio is a different way of buying the same extraction engine, whether on premise, through an interface or embedded in someone else's software.

Two things hold it below A. A curated terminology containing millions of medical terms is a substantial asset that is not a model, and the moat is the dataset precedent applies to it directly: mapping a finding to the right code depends as much on that curation as on the extraction. And part of the portfolio is enterprise search infrastructure, which is ordinary software that would function with far less intelligence behind it.

The output is structured data handed to another system rather than a recommendation made to a clinician, so autonomy in the usual sense barely applies. Nothing here decides anything about a patient.

The exception deserves attention. Automated billing in hospitals is a stated application, and coding derived from extracted text without a human reading the underlying note is a consequential act with financial and compliance implications, as this index has recorded elsewhere in revenue cycle. Nothing published describes a confidence threshold, a review step or how an extraction error surfaces once it has become a code on a claim.

Considerably more technical disclosure than this index usually encounters. The company names the underlying text mining engine it builds on rather than describing an unnamed proprietary system, names its indexing technique, states the number of ready made annotators, and describes the semantic interpretation returned alongside each extraction, including negation detection and out of range laboratory flagging.

The linguistic engineering is specified rather than gestured at, with medical stemming and decompounding named explicitly, which is the right emphasis because German medical vocabulary forms compound words that defeat naive processing. A free tier on the cloud interface lets a prospective buyer test the extraction on their own text before any commitment, which is a form of transparency no marketing page can substitute for.

Held below A because no accuracy figure is published for any annotator, and a platform offering more than 50 of them will not perform uniformly across all of them.

This vendor does the thing this axis asks for and almost nobody does: it names the underlying engine it builds on rather than presenting an unnamed proprietary system. The text mining engine it is built upon is identified, the indexing technique is named, the number of ready made annotators is stated, and the semantic interpretation returned alongside each extraction is described including negation detection and out of range laboratory flagging.

The linguistic engineering is specified rather than gestured at, with medical stemming and decompounding named explicitly, which is the right emphasis for a language whose medical vocabulary forms compound words that defeat naive processing. Naming the substrate lets a buyer read that project's own documentation and licence terms rather than taking a vendor's word for what is inside.

The deployment architecture adds a second answer: an on premise option means text can be processed inside the hospital's own estate, so for that route the chain is bounded by the customer's own perimeter. Held below the top grade because the cloud route is undescribed, with no hosting provider named, no sub processor list located and no position on whether customer text contributes to model development.

One practical caution belongs here: a buyer trying the free cloud tier should establish what happens to submitted text before pasting anything real into it. Ask for the cloud terms, a sub processor list, and the training position.

The scientific standing is real and it is not the same thing as product evidence, which is the distinction this index drew on Layer Health and it applies again here.

What exists: origin as a spin out from a university medical centre, a stated contribution to well over 100 publications on language processing, terminologies and semantics, academic relationships including a chair of medical informatics at a major technical university, and more than 100 hospital and partner deployments across 15 years. That is a serious record.

What is absent: any published measurement of how well the product performs. No extraction accuracy, no comparison against manual coding or abstraction, no evaluation of the automated billing application. The publication record concerns the methods rather than the shipped system, and long deployment is not accepted here as evidence of benefit.

Graded on an honest basis. No published retention schedule, encryption detail or position on whether customer text contributes to model development was located in this pass.

The architecture answers part of the question implicitly, since an on premise platform processing text inside the hospital's own estate is a materially narrower exposure than a hosted service, and that option is offered. The cloud interface is the other half and its terms are not described. A buyer running the free tier should establish what happens to text submitted through it before pasting anything real into it.

Graded on an honest basis, and the axis fits awkwardly here in a way worth stating rather than papering over. This is a German company whose customer base is principally European, so the governing framework is European data protection law rather than United States health privacy law, and a business associate agreement is not the instrument that would apply to most of its customers.

No compliance documentation of either kind was located. A buyer outside Europe should establish what the company offers for their regime specifically rather than assuming European compliance transfers.

Recorded honestly: the dedicated trust and security search this index requires was not run in this pass, so the grade is provisional and should not be quoted until it has been.

One factor points upward. A vendor whose software is embedded inside hospital information systems sold by other manufacturers will have been assessed by those manufacturers as a component supplier, which is a more searching review than a direct customer usually performs. Nothing about it is public.

No device authorisation in any jurisdiction and none claimed. Extracting structured facts from text is infrastructure rather than a clinical determination, and it sits outside device regulation on that basis.

The boundary is worth naming because the company's own stated applications approach it. Clinical decision support and rare disease detection are listed uses, and in Europe software intended to inform a clinical decision can fall inside the medical device regulation depending on how the output is presented and relied upon. Where the extraction is embedded inside another manufacturer's product, that manufacturer carries the regulatory obligation, which is a reason the component supplier position is commercially attractive and a reason a buyer should establish who holds it.

Nothing published on evaluation methodology, monitoring, error rates or performance variation.

The variation that matters here is linguistic and institutional rather than demographic, and it is substantial. Extraction quality depends on language, on local documentation conventions, on abbreviation habits that differ between departments and between hospitals, and on document type, so a system performing well on discharge letters at one university hospital may perform quite differently on nursing narratives at a community one. The company clearly understands this, since its engineering emphasis is precisely on handling linguistic variation, and none of the resulting performance data is published.

One mechanism here is unusual and genuinely useful, and it belongs on this axis rather than only on transparency. A free tier on the cloud interface lets a prospective buyer run the extraction on their own text before any commitment, which means a customer can measure the system themselves rather than relying on a published figure or the absence of one.

Self verification before purchase is a stronger position than most published accuracy claims, because it is performed on the buyer's own documents in their own language and specialty rather than on a vendor selected corpus, and it cannot be gamed by choosing a favourable sample. Held at C because nothing is published and nothing is committed.

No accuracy figure exists for any annotator, and a platform offering more than fifty of them will not perform uniformly across all of them, so a buyer testing one capability learns nothing about the others. There is no evaluation methodology, no error taxonomy, and no warranty, indemnity or remediation commitment.

The free tier is also the caution as well as the credit, since the terms governing text submitted through it are not described, so it should be exercised with synthetic or de identified documents until those terms are established. Ask for per annotator accuracy, and for the terms covering the free tier.

Interoperability is the product rather than a feature attached to it. A dedicated product converts documents into a standard structured exchange format, which is the direct expression of what this company does: take unstructured text and emit something another system can consume.

The commercial position reinforces it. A substantial part of the customer base is other software companies, including a named hospital information system manufacturer, embedding the extraction inside their own products. That makes this a component supplier to the systems a hospital already runs rather than another application competing for the clinician's attention, and it is the second instance of that shape in this sweep after Aignostics. Held at B because no named record vendor certification or interface detail beyond the exchange format was located.

The customer chooses, which is unusual and valuable. The flagship platform is offered on premise, so a hospital can process its own text inside its own infrastructure, while a hosted interface exists for those who prefer it, with a free tier for evaluation.

For a European hospital handling patient text that choice is the whole question, and offering both rather than insisting on one is the right posture. Held at B because no hosting region, retention schedule or residency statement was located for the hosted option, and because the split of capability between the two, if any, is not described.

Better than the enterprise norm at the bottom of the range and silent above it. A free tier on the cloud interface is published with its limits stated, covering German medical text and a restricted entity set, so a developer can begin without a conversation and can establish whether the extraction works on their documents at zero cost.

Above that nothing is published: no rate for the full interface, no licence price for the on premise platform, and no indication whether embedding the engine inside another manufacturer's product is priced by volume, by seat or by royalty. Given that three quite different commercial relationships exist here, a buyer needs to establish which one they are in before any figure means anything.

Broad in every direction except geography. Document types span nursing narratives, pathology reports and physician letters; applications span decision support, research, billing and coding, rare disease detection and trial recruitment; and buyers span hospitals, software manufacturers, health portals, medical publishers and pharmaceutical companies.

That buyer spread is the notable part, because selling the same engine to a hospital and to the company that builds the hospital's record system are different businesses. Specialty coverage follows the terminology rather than a clinical focus, so the system is specialty agnostic by construction. Concentration is in Germany and the German speaking region, with multilingual and cross lingual support stated and international presence described only in general terms.