Read-only MCP server for licensed Healthpoint HL7 FHIR API access.
A read-only MCP server providing access to a licensed Healthpoint HL7 FHIR API via Rust-first tooling. It centers on a typed client and includes a CLI, while the MCP server focuses on read-only operations for FHIR API access. Users supply their own Healthpoint API key/licence.
🛠️ Key Features
Read-only MCP server for Healthpoint HL7 FHIR API access
Rust-first typed client and CLI
Topics include fhir, healthcare, api-client, rust, mcp, cli
🚀 Use Cases
Querying Healthpoint HL7 FHIR data through MCP
Integrating FHIR access into developer workflows using a typed client
⚡ Developer Benefits
Typed client approach for HL7 FHIR API usage
Code-first, data-light repository model
Synthetic FHIR fixtures in crates/healthpoint-testkit/fixtures/
⚠️ Limitations
Read-only access only
Requires users to bring their own Healthpoint API key/licence
No real Healthpoint API payloads are committed as fixtures
Install through Smithery from the published listing: edithatogo/healthpoint-rs. The Smithery package starts in synthetic mode unless live Healthpoint credentials are supplied.
Usage
First commands
bash
cp .env.example .env$EDITOR .env
bin/conductor-setup
cargo run -p healthpoint-cli -- doctor
cargo run -p healthpoint-cli -- fixture services --format json
cargo run -p healthpoint-cli -- inspect search-url --text "cervical screening" --snomed 171149006
cargo run -p healthpoint-cli -- search services --text "cervical screening" --format json
cargo run -p healthpoint-cli -- search services --snomed 171149006 --format json
cargo run -p healthpoint-cli -- get service <id> --format json
cargo run -p healthpoint-cli -- get uri healthpoint://service/<id> --format json
cargo run -p healthpoint-mcp
The MCP server is a separate binary so CLI and MCP can evolve independently while sharing the same crates. It starts in synthetic fixture mode when no API key is supplied; set HEALTHPOINT_MODE=live and provide HEALTHPOINT_API_KEY for licensed live API calls.
Healthpoint portal validation on 2026-06-30 confirmed UAT calls use the x-api-key header against https://uat.healthpointapi.com/baseR4/. See docs/healthpoint-api-access.md for observed endpoint and license notes.
Show redacted runtime mode, configuration, and readiness.
healthpoint.access.notes
Show non-secret endpoint, auth, and documentation notes.
healthpoint.access.policy
Show the conservative access/export policy before reuse.
healthpoint.services.search
Search HealthcareService records by text, codes, region filters, cursor, and limit.
healthpoint.services.search_snomed
Search HealthcareService records by SNOMED CT code in type, category, or specialty.
healthpoint.services.nearby
Find HealthcareService records near a latitude/longitude point.
healthpoint.service.get
Read one HealthcareService by FHIR id.
healthpoint.location.get
Read one Location by FHIR id.
healthpoint.organization.get
Read one Organization by FHIR id.
healthpoint.resource.read
Read a supported healthpoint:// resource URI.
The MCP server also exposes 3 static resources, 4 resource templates, and 2 prompts. See docs/mcp-tools.md and docs/integrations/mcp-client-configs.md for launch examples.
Those schemas are intended to help future integration with open_social_data, MCP clients, and any cross-repo data catalogue layer without prematurely forcing Healthpoint's FHIR graph into a dataframe-first shape.
Offline readiness tools
These commands work before any live Healthpoint validation and are useful in sandboxes or CI metadata jobs:
This visible marker is required for Cargo/crates.io ownership verification by the official MCP Registry.
Safety boundary
This is not a clinical decision-support system. It retrieves and formats directory/service information from Healthpoint for licensed users. Any downstream use should preserve Healthpoint attribution, currency, caveats, and licensing obligations.
Current status
Implementation spike after initial scaffold. Synthetic mapping exists for HealthcareService, Location, and Organization, including richer service fields such as eligibility, availability, service provision codes, characteristics, comments, endpoints, identifiers, and response provenance. The public Healthpoint material confirms HL7 FHIR and SNOMED CT orientation, but full endpoint/auth details are intentionally treated as configurable until validated against licensed API documentation.