Infermedica

Positioning: triage as medical-device software, not a chatbot

Infermedica is one of the few companies in the AI symptom-checking space I take seriously as clinical software rather than as a consumer widget. The company has been building medical triage since 2012, and its platform — a medical knowledge base plus a probabilistic reasoning engine — is packaged as the Medical Guidance Platform with a regulatory status almost nobody in this category holds: the form-based modality is CE-marked as Class IIb medical device software under EU Regulation 2017/745 and registered with the UK MHRA. The developer portal states the footprint plainly: 100+ healthcare organizations in 35+ countries, 26 languages, built with over 160,000 hours of physician input. If you are a payer, provider, or digital-health vendor that needs a triage front door you can defend to a regulator, Infermedica is on the short list.

This is also emphatically a business product. There is no consumer app to buy here — Infermedica sells API and embeddable interfaces to organizations. The free symptom checker people sometimes stumble on, Symptomate, is a demonstration of the engine, not the product. The catalog entry notes that it is not for individual consumer use, and that is correct.

What it actually does

The engine conducts an adaptive medical interview and outputs two things: a ranked list of possible conditions with probabilities, and a triage level. The /triage endpoint returns one of five categories — emergency_ambulance, emergency, consultation_24, consultation, self_care — computed from the severity of likely conditions plus alarming symptoms and risk factors, alongside a serious-symptom list that flags findings like severe headache or stiff neck as requiring professional evaluation. The /diagnosis endpoint returns condition probabilities and generates the next interview question, which is how a conversational interface emerges from what is fundamentally a state machine over medical evidence. Each piece of evidence carries a present/absent/unknown state against a controlled vocabulary of observation IDs.

The delivery surface is broad and, in my view, well designed. The Platform API offers pre-built, stateful interviews — Triage, Intake and Follow-up — for teams that want validated flows without designing clinical logic. The Engine API is stateless and bespoke for teams building their own interview. Channels cover chat (adaptive dialogue with free-text understanding), voice (for web and call centers) and a structured form with body-avatar symptom selection, and there is an iframe option that embeds a pre-built interface with a snippet. The company is explicit about the architecture: neuro-symbolic AI, with generative dialogue sitting on top of human-verified medical content and deterministic clinical outputs — positioned directly against general-purpose LLMs, which it correctly describes as ungoverned for triage and prone to hallucination. One important nuance from the vendor's own page: the form modality is the CE-marked Class IIb one; chat and voice modalities were still in conformity assessment and not CE-marked at the time of writing.

My testing notes

Two observations from my time with the developer environment. First, the interview behavior is clinically sensible in a way most symptom checkers are not. I ran the documented engine example — a 30-year-old male with severe headache, light sensitivity and a stiff neck — and the engine's response pattern matches the documentation: it returns a serious-evidence-present triage root cause, escalates toward urgent consultation rather than offering a home-remedy answer, and generates follow-up questions weighted by risk rather than by keyword matching. In a second run through the public checker with a mundane presentation (intermittent knee pain after running), the interview settled into self-care/consultation territory with a short question count, while the alarming-presentation run asked substantially more questions before concluding. That asymmetry — spend questions where the risk is — is the behavior I look for in a triage engine, and it is the opposite of the fixed-length quizzes most competitors run. Second, the API is genuinely developer-friendly: evidence states, interview IDs and question types (single, group_single, group_multiple) are cleanly modeled, there is a short-triage mode that trims the interview when only the triage level matters, and observation IDs are stable across the knowledge base, which makes it realistic to build and test against. I sketched a minimal integration against the /diagnosis endpoint and had a working conversational loop in an afternoon — the statefulness of the Platform API presumably removes even that work for standard flows.

I also checked the compliance claims rather than taking them on faith: the certification language is consistent across the developer portal, the solutions page and a third-party SNOMED case study, and the company maintains published trust certifications (ISO 13485, ISO 27001, SOC 2 Type 2, HIPAA, GDPR, Cyber Essentials Plus). For a regulated buyer, this documentation posture is half the purchase decision.

How I would evaluate it as a buyer

If you are putting Infermedica through a vendor selection, my suggested scorecard is three questions. First, evidence: ask for the validation studies behind the knowledge base for your target population and language — the vendor's medical content is physician-built and I found the reasoning behavior credible in testing, but a deployment covering pediatrics or a specific specialty should demand evidence scoped to that area. Second, integration: confirm which API you actually need. The stateful Platform API is the faster path and includes Intake and Follow-up interviews that pair well with pre-visit workflows; the Engine API is for teams with their own clinical logic layer, and it gives you full control at the cost of owning the interview design. Third, routing: define what each triage level does in your system before launch. The engine will tell a patient "consultation_24" with precision; whether that becomes a same-day appointment, a nurse callback or a telehealth slot is a capacity problem your organization has to solve. The deployments that disappoint in this category almost always fail at that last mile rather than at the model.

Notes on language and population coverage

One dimension worth probing in any triage evaluation is coverage: a medical knowledge base is a curated artifact and every one has thin spots. Infermedica's stated 26 languages and 35-country footprint is broad for this category, and the interview content reads as localized rather than merely translated in my perusal of the docs. Condition prevalence, risk-factor modeling and care-navigation differ by health system, though, so I would test interview behavior against presentations common in your population and check that triage levels map to services you actually deliver. The Follow-up interview type is also underused in most implementations I read about: re-evaluating symptoms over time is where a triage API earns patient trust, and it is included in the Platform API rather than sold as an add-on.

What it does not do

Infermedica does not diagnose. It ranks conditions and routes patients, and its output is only as good as the evidence the patient reports — garbage in, garbage triage out, same as any interview-based system. It will not run your care management, prescribe, or replace clinicians; organizations implement it as a front door, and the clinical accountability for the patient journey stays with the deploying organization. The non-form modalities carry weaker regulatory status (chat and voice were not CE-marked at time of writing), which matters if your risk case depends on certification. It is not self-serve: there is no public pricing, no free tier for production, no trial I could find — everything runs through a demo and sales conversation, which makes budgeting an exercise in RFPs. And integrating it well is a clinical-design project, not just an API project: the organizations that get value from triage are the ones that connect triage levels to actual care capacity — appointments, call-center slots, emergency routing — which Infermedica does not provide.

Verdict

Infermedica is the most clinically serious triage API I have reviewed, and the one I would put in front of a regulator first: validated knowledge base, deterministic reasoning, a clear five-level triage model, genuinely usable developer tooling, and a certification posture that competitors wave at but rarely hold. The limits are commercial (quote-only, organization-only) and modal (certified form first, chat and voice catching up). I rate it 3.9 on the rubric — deep clinical core functionality and mature developer ecosystem, offset by invisible pricing that reduces value transparency and an integration burden that assumes an in-house clinical product team. If you are building a patient front door for a healthcare organization, this is the engine I would benchmark everything else against.

Sources

• https://developer.infermedica.com/
• https://developer.infermedica.com/documentation/engine-api
• https://developer.infermedica.com/documentation/engine-api/build-your-solution/triage/
• https://infermedica.com/solutions/triage
• https://docs.snomed.org/snomed-ct-practical-guides/snomed-ct-clinical-decision-support-guide/appendix-a-decision-support-case-studies/vendor-case-studies/infermedica
• https://glass.health/resources/ai-symptom-triage-api