An AI symptom triage API can support two very different jobs. Patient-facing products interview a patient and recommend a care route. Clinician-facing products help a licensed professional organize case data, develop a differential, plan next steps, and document the encounter. The right category depends on who uses the system and what must happen after the result.
The Glass Developer API lists triage alongside patient-data summarization, evidence-based questions, differential diagnosis, treatment planning, and documentation. The key distinction is product form: Glass supplies clinical capabilities through an API, while the customer application owns the interview, end-user experience, local routing rules, scheduling or handoff, monitoring, and human-review policy.
Quick comparison
| Platform | Intended user | Core workflow | Main output | Best fit |
|---|---|---|---|---|
| Glass Health | Product teams building a custom triage workflow | Apply API-based clinical capabilities to the context supplied by the customer application | Triage workflow support alongside cited answers, summaries, differentials, plans, and clinical documents | Products that need a broader clinical API and will own routing and review logic |
| Isabel Self-Triage | Patients using a health-system digital front door | Collect symptoms through a short self-triage interview | Recommended level and venue of care | Patient routing, scheduling, and consumer access |
| EndlessMedical | Licensed clinicians and clinical software builders | Add symptoms, signs, labs, imaging, and exam findings to a live reasoning session | Ranked differential, red flags, next steps, specialty or acuity routing, and documentation | Developer-led clinical reasoning and triage applications |
| Microsoft Healthcare Agent Service | Healthcare organizations building virtual assistants | Add built-in Infermedica triage to a configurable conversational flow | Symptoms, risk factors, possible causes, triage results, and suggested next actions | Branded patient access and routing on Microsoft infrastructure |
The Glass Developer API lists triage alongside broader reasoning and documentation capabilities. Isabel Self-Triage centers a short patient interview that returns a recommended care level and venue. EndlessMedical positions its API as clinical decision support for licensed clinicians, while also supporting products built on the same engine. Microsoft documents Healthcare Agent Service as a platform for healthcare virtual assistants, with built-in triage and symptom checking powered by Infermedica.
Decide whether the user is a patient or a clinician
The phrase symptom triage API is broad enough to hide a fundamental product decision.
A patient-facing flow must work for someone who may be worried, sick, distracted, or using a phone. It needs plain-language questions, a clear stopping point, a safe escalation path, and an understandable next action. Its output is usually a care route: schedule a visit, speak with a nurse, use telemedicine, find a clinic, or seek more urgent evaluation.
A clinician-facing flow starts from a different assumption. The user already knows how to interview and assess a patient. The system should help that professional synthesize available context, keep important alternatives visible, identify useful next steps, and create documentation that can be reviewed and edited. Its output may include a structured summary, a differential diagnosis, diagnostic next steps, an assessment and plan, or a note.
These workflows can connect, but they should not be treated as interchangeable. A health system may use a patient-facing product to collect symptoms and route the case, then give the resulting information to a clinician-facing system for review. Buying one platform to perform both jobs requires evidence that it supports both users, both interfaces, and both safety models.
Six criteria for comparing triage APIs
1. Intended user
Start with the person who will interact with the product. A patient, call-center agent, nurse, physician, and software developer each need a different interface and level of explanation. A vendor’s use of the word triage is not enough to establish fit.
Ask the vendor to demonstrate the exact workflow with the intended user. A patient-facing demo should show question wording, incomplete interviews, escalation, and the handoff to care. A clinician-facing demo should show how case context is entered, how the reasoning changes as new information arrives, and how the clinician reviews the output.
2. Input model
Patient self-triage usually begins with demographics, symptoms, duration, severity, and risk factors. Clinician-side systems may also accept notes, medications, laboratory results, imaging findings, examination findings, and prior history.
Input breadth matters only when it matches the workflow. A digital front door can fail if it asks too much of a patient. A clinician tool can fail if it ignores the chart context required for a useful assessment. Define the minimum data needed for the decision before comparing feature lists.
3. Output and disposition
A triage result should be operational, not merely interesting. For patient-facing systems, determine which care levels are available, how the recommendation maps to local services, and whether the user can schedule, call, or escalate without starting over.
For clinician-facing systems, define the clinical object the workflow needs. That may be a concise case summary, a ranked differential, suggested diagnostic next steps, a plan for clinician review, or structured documentation. Confirm the response format and how it enters the receiving workflow.
4. Evidence and validation
Ask what has been validated, on which population, for which task, and against what reference standard. Condition-list accuracy, top-ranked diagnosis accuracy, care-disposition accuracy, high-acuity recall, interview completion, and documentation quality are different measures. One headline percentage cannot stand in for all of them.
Vendor-published metrics can help form a test plan, but they do not replace an evaluation on the cases, ages, languages, and settings your organization expects to serve. Define failure cases before the pilot, especially for high-acuity presentations and incomplete information.
5. Human handoff
The receiving person should not have to reconstruct the interview. A useful handoff carries forward the relevant symptoms, risk factors, questions, answers, candidate causes, recommended route, and any uncertainty the system exposed.
Microsoft’s triage documentation is unusually concrete on this point: the result object can include user details, symptoms, risk factors, questions and responses, possible causes, triage results, and suggested-care messages. Other platforms may use different objects, so request a real payload and trace it through the destination system.
6. Deployment, privacy, and governance
Confirm authentication, data flow, retention, logging, incident handling, availability, localization, accessibility, and the contract that applies to the exact service. A business associate agreement addresses protected-health-information handling between parties. It does not establish clinical accuracy or safe routing.
The privacy and safety reviews should therefore remain separate. Security teams review the data path and contractual controls. Clinical leaders review intended use, output quality, escalation, and oversight. Product and engineering teams review integration, observability, and failure recovery.
Platform profiles
Glass Health: a clinical API for customer-defined triage workflows
The Glass Health Developer API is designed for clinical products and workflows. It accepts clinical queries and patient data supplied by the customer application, then returns structured responses with in-text citations and citation metadata. Its listed capabilities include triage, evidence-based questions, patient-data summarization, differential diagnosis, treatment planning, clinical documentation, and ambient scribing.
Glass supplies the clinical API layer. The product team defines the patient or clinician experience, decides which information to collect, maps outputs to local policies and destinations, and establishes the escalation and human-review model.
Choose Glass in this group when the team is building the experience and needs triage intelligence that can continue into clinical reasoning, evidence review, planning, or documentation. The application still owns the interview design, user interface, local care destinations, scheduling or handoff, monitoring, and human-review policy. Teams can start with the API documentation to evaluate the request and response model for their application.
Isabel Self-Triage: short patient routing flows
Isabel is purpose-built for patient self-triage. Its current product page describes an 11-question flow, with seven standard questions covering onset, severity, and duration. The result presents a recommended level and venue of care that a health system can map to its own services.
The product page also describes API and browser deployment across websites, conversational interfaces, call centers, and provider-finding experiences. That makes Isabel a practical candidate when the business goal is a short digital-front-door flow that moves a patient toward scheduling or another care route.
Isabel publishes engagement and accuracy figures on its own site. Treat those as vendor-reported claims that define what to test, not as a substitute for an independent pilot on your population and workflow.
EndlessMedical: a developer-first clinical reasoning engine
EndlessMedical describes decision support for licensed clinicians, with more than 2,000 clinical inputs across symptoms, signs, laboratory results, imaging, history, and examination findings. The API returns a ranked differential, red-flag candidates, suggested next tests or questions, specialty or acuity routing, and structured documentation.
The same engine can support a consumer symptom checker and a clinician-facing provider application, but the API itself is framed around a live clinical reasoning session. EndlessMedical belongs on the shortlist when a development team wants granular control over a ranked differential and next-step workflow.
Because this is a clinical reasoning product, buyers should test the disease coverage, calibration, red-flag behavior, and handling of missing or conflicting inputs. The vendor’s current documentation provides a useful starting model for that evaluation.
Microsoft Healthcare Agent Service: configurable virtual-assistant triage
Microsoft’s Healthcare Agent Service is a broader virtual-assistant platform with built-in medical intelligence. Its documented triage flow uses Infermedica and can be inserted into a custom scenario with steps before and after the assessment.
The result object can support downstream branching, scheduling, clinic finding, or live-nurse handoff. Microsoft also documents localization and configuration controls, which matter for organizations that want triage inside a larger branded assistant rather than as a standalone API purchase.
This option is most relevant when the organization already wants a Microsoft-hosted conversational platform and has the engineering and governance capacity to configure the surrounding experience. The triage engine is one component of that platform.
Where Glass fits in a triage architecture
Glass can power a patient-facing or provider-facing triage experience, but the API is not the complete digital front door by itself. The product team supplies the conversation design, local routing, scheduling or live-care handoff, interface, analytics, and operating controls around the clinical output.
Glass fits when a clinical product needs more than a fixed care route. Examples include:
- A patient intake flow that carries submitted context into a customer-defined scheduling or clinician-review path.
- A tele-triage clinician who needs a concise summary, differential, next steps, and documentation.
- An urgent-care intake workflow that carries submitted context into a clinician review queue.
- A clinical operations product that needs evidence-cited reasoning and structured clinical documents from one API.
- A health platform that already has the interface and routing logic but needs a broader clinical intelligence layer.
This distinction makes the buying decision clearer. Glass belongs in an AI triage API evaluation when the builder wants flexible clinical intelligence. Isabel and Microsoft may be better starting points when a prebuilt interview or virtual-assistant platform is the primary requirement.
A practical pilot plan
Use a small, explicit evaluation packet rather than a generic demo.
- Define the user and the decision. State whether the workflow is patient routing, clinician reasoning, or a handoff between the two.
- Create representative cases. Include common presentations, incomplete interviews, conflicting information, language needs, and high-acuity cases that test escalation.
- Define the expected output. Specify the fields, disposition, clinical artifact, and human-review step before testing vendors.
- Trace the handoff. Confirm what reaches scheduling, a call center, a clinician queue, the EHR, or another application.
- Score separate dimensions. Measure task completion, routing quality, high-acuity behavior, reasoning usefulness, documentation quality, latency, and integration reliability independently.
- Review governance. Verify the exact data flow, contract, retention policy, access controls, logging, and incident path for the production service.
- Set a stop rule. Decide in advance which safety, quality, or operational failures end the pilot.
The result should make the purchase decision obvious. If the primary requirement is a prebuilt patient interview and configurable care route, start with a patient-facing platform. If the team is building the experience and needs structured triage support that can extend into reasoning and documentation, evaluate Glass. If the primary user is a clinician and the team wants granular control over a differential engine, evaluate clinician-focused APIs as well.
FAQ
What is an AI symptom triage API?
An AI symptom triage API accepts symptoms and other health information, asks or supports follow-up questions, and returns information used to route or assess a case. Patient-facing products usually return a recommended care level or next action. Clinician-facing products may return a summary, differential diagnosis, suggested next steps, or documentation for professional review.
Can Glass Health power a patient symptom checker?
The Glass Developer API lists triage as a supported use case. It is an API rather than a complete consumer interface, so the product team remains responsible for the interview, local routing logic, user experience, monitoring, escalation policy, and human-review model.
Which API is best for a digital front door?
Isabel Self-Triage is the clearest packaged interview and care-routing option in this comparison. Microsoft supports built-in triage inside a configurable virtual assistant. Glass is relevant when a team is building its own experience and wants a broader clinical intelligence API. The better fit depends on channel, integration, localization, scheduling, governance, and the desired operating model.
Which API is best for clinician triage?
Glass is a strong fit when the clinician workflow needs evidence-cited reasoning, patient-data summarization, differential diagnosis, treatment planning, and documentation. EndlessMedical is relevant when a developer wants a granular clinical reasoning session with a ranked differential, red flags, next steps, and specialty or acuity routing. Test both against the exact clinical task rather than comparing broad feature counts.
Does a BAA make a triage API clinically safe?
No. A BAA addresses protected-health-information handling between contracting parties. Clinical safety requires a separate review of intended use, validation, escalation, failure modes, handoff, and human oversight.
What should a triage handoff include?
At minimum, preserve the information needed to understand how the result was reached: symptoms, risk factors, follow-up questions and answers, candidate causes, the recommended route or next step, and any uncertainty or escalation signal. The receiving clinician or system should not have to repeat the entire intake.
Bottom line
Start with the user. Patient-facing symptom checkers are designed to interview and route patients. Clinician-facing APIs are designed to help professionals synthesize clinical context and act on it.
Evaluate Isabel when the priority is a packaged patient interview and care route. Evaluate Microsoft when the organization wants triage inside a configurable Azure virtual-assistant platform. Evaluate Glass when a custom patient-facing or provider-facing product needs triage support plus reasoning, evidence, planning, and documentation. Evaluate EndlessMedical when a developer wants a granular differential and triage engine for clinical applications.
For a custom implementation, review the Glass Developer API and API documentation, then test the response structure against the real interview, escalation, handoff, and review workflow.