smart-fhir
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FHIR_ISS | No | Base FHIR server URL (ISS). Must be in the allowlist. | https://launch.smarthealthit.org/v/r4/fhir |
| FHIR_SCOPE | No | OAuth scope override for JWT mode. Defaults to five system/*.rs types. | |
| FHIR_WRITE | No | Write mode. Writes are always off in v1. | off |
| FHIR_JWT_KID | No | Key ID for Backend Services JWT. Required when FHIR_AUTH_MODE=backend_jwt. | |
| FHIR_VERSION | No | FHIR version. Only R4 is supported. | R4 |
| FHIR_JWKS_URL | No | Optional JWKS URL for the JWT `jku` header. | |
| FHIR_AUTH_MODE | No | Authentication mode: open, bearer, or backend_jwt. | open |
| FHIR_CLIENT_ID | No | Client ID for SMART Backend Services. Required when FHIR_AUTH_MODE=backend_jwt. | |
| FHIR_AUDIT_PATH | No | Path for the append-only audit log. | ./audit/audit.jsonl |
| SMART_CLIENT_ID | No | Alias of FHIR_CLIENT_ID. | |
| FHIR_ACCESS_TOKEN | No | Bearer access token. Required when FHIR_AUTH_MODE=bearer. | |
| FHIR_REDIRECT_URI | No | Reserved for future App Launch; currently unused. | |
| FHIR_PRIVATE_KEY_PEM | No | Private key PEM for Backend Services JWT. Required when FHIR_AUTH_MODE=backend_jwt. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| smart_discoverA | GET {iss}/.well-known/smart-configuration (SMART App Launch 2.2.0). Optional iss must be v1-allowlisted. Does not invent endpoints. |
| fhir_auth_statusA | Report mode, ISS, R4 lock, write=off, token_present, discovery_ok. Never prints token or PEM. |
| fhir_searchA | GET {iss}/{resourceType} as FHIR R4 searchset. resourceType allowlist: Patient, Observation, Condition, MedicationRequest, Encounter. _count default 10 max 50. One page only. Does not invent Patients. |
| fhir_readB | GET {iss}/{resourceType}/{id} as FHIR R4. 404 is not found, not a made-up resource. Same resourceType allowlist as search. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool targets a distinct function: smart_discover retrieves server metadata, fhir_auth_status reports client-side authentication state, fhir_search performs list queries, and fhir_read fetches individual resources. There is no overlap or ambiguity between the four operations.
Tools use a consistent prefix pattern (smart_ for auth/discovery, fhir_ for data operations) and each suffix clearly indicates the action (discover, auth_status, search, read). While the prefixes differ by domain, the overall structure is predictable and not chaotic.
Four tools is on the lower end but appropriate for a narrowly scoped read-only FHIR access server focused on discovery and basic querying. It avoids bloat while covering the primary use cases.
The server covers read and search for a limited set of resources, but lacks pagination (only one page), search parameters beyond resource type, and a capability statement. Given the explicit read-only nature, core operations are present but notable gaps exist in search depth and server metadata.