Last EHR
Related Servers
Alternatives to Last EHR
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityCmaintenanceEnables LLM agents to query de-identified FHIR-shaped hospital data through audited, read-only tools for patients, encounters, conditions, observations, medications, and interaction checks, while any medication write stays a draft that a clinician must confirm out-of-band.MIT
- AlicenseAqualityCmaintenanceGives AI agents read-only access to patient context on any FHIR R4 server, including journey timelines of encounters and appointments, open booking slots, and discharged patients whose follow-ups were never booked. Search, appointment, and follow-up tools return compact summaries, so agents can answer front-desk and outreach questions without write access.5MIT
- FlicenseNot gradedqualityAmaintenanceEnables LLM-based agents and MCP-compatible clients to query and manipulate clinical data on a FHIR-compliant backend through CRUD resource tools, document ingestion, semantic search, and terminology lookup.-
- FlicenseNot gradedqualityAmaintenanceEnables LLM-based agents and MCP-compatible clients to query and manipulate FHIR resources through full CRUD tools, with document ingestion, semantic search, LOINC terminology lookup, and OAuth2-authenticated FHIR API integration.-
- AlicenseNot gradedqualityCmaintenanceA clean-room SHARP-on-MCP compliant FHIR R4 MCP server that enables AI agents to interact with any FHIR R4 endpoint using SHARP context headers, without server-side OAuth. It provides clinical tools, lab results, imaging, and interactive MCP-UI dashboards.MIT
- AlicenseNot gradedqualityCmaintenanceEnables AI agents to discover a configured FHIR R4 endpoint, search and page within a single trusted patient, read exact resources, and inspect retained results as FHIR-shaped JSON with provenance, coverage signals, and byte limits.Apache 2.0
TDQS
Scored across 4 tools
The tools mostly have distinct purposes: search_patients finds patients, show_patient_info retrieves a chart, read_chart_section reads a filtered section, and read_document retrieves a specific document body. The main potential confusion is between read_chart_section and show_patient_info, since both surface chart content, but the descriptions clarify scope and filter differences.
All four names follow a clear verb_noun pattern: read_chart_section, read_document, search_patients, and show_patient_info. The verbs are meaningful and consistently snake_case.
Four tools is well-scoped for a focused read-only EHR surface. Each tool covers a distinct step in the lookup-and-read workflow, and none feels redundant.
The surface covers patient search, chart overview, section-level reads, and document text retrieval, which supports common chart-review workflows. Minor gaps exist, such as broader patient lookup filters or explicit section enumeration, but these are likely workable through existing tools.