Skip to main content
Glama
maheshbalan

FHIR MCP Server

by maheshbalan

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MASTER_KEYNoMaster encryption key
FHIR_BASE_URLNoFHIR base path
LOINC_ENDPOINTNoLOINC API search endpoint
LOINC_PASSWORDNoLOINC account password
LOINC_USERNAMENoLOINC account username
TRANSPORT_MODENoTransport mode: stdio, http, or https
EMBEDDING_MODELNoHugging Face embedding model name
FHIR_SERVER_HOSTYesFHIR API host URL
PINECONE_API_KEYNoPinecone API key for vector search
FHIR_SERVER_CLIENT_IDYesOAuth2 client ID for FHIR
FHIR_SERVER_CLIENT_SECRETYesOAuth2 client secret for FHIR

Capabilities

Features and capabilities supported by this server

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
request_patient_resourceA

Makes an HTTP request to the FHIR server. Use this tool to perform CRUD operations only on the FHIR Patient resource. Rules: - When creating or updating a patient, use only the data explicitly provided by the user. - Do not guess, auto-fill, or assume any missing data. - When deleting a patient, ask the user for confirmation with details of the patient and wait for the user's confirmation. - Provide links to the app (not api) patient resource in the final response.

Args: method: HTTP method (GET, POST, PUT, DELETE) path: Resource path (e.g., "/Patient", "/Patient?name=John%20Doe") body: Optional JSON data for POST/PUT requests)

Returns: JSON response from the FHIR server

get_loinc_codesA

Get the most relevant LOINC codes for a given observation name.

The function automatically:

  • Filters for STATUS="ACTIVE" codes only

  • Sorts by COMMON_TEST_RANK (lower rank = more commonly used)

  • Returns codes in popularity order (most common first)

Your job is to:

  1. Analyze returned codes for semantic relevance to the search query

  2. Balance clinical popularity with semantic matching

  3. Select codes that best match the intended observation

Strategy:

  1. Start with default parameters (max_codes=5, max_fetch=50)

  2. Check if result contains "Error" key in first element

  3. If "Authentication failed" or "Authorization" error:

    • STOP using this tool immediately.

    • Do not retry with different parameters.

    • Report the authentication error to the user.

    • Suggest they check their LOINC API credentials.

    • Ask the user if they want to use your knowledge to find a LOINC code and wait for the confirmation. Add warning that this may cause wrong results.

  4. If "No active LOINC codes found in current fetch":

    • Increase max_fetch progressively (50→100→200→RecordsFound).

    • Keep trying until max_fetch >= RecordsFound or you find active codes.

  5. If "No LOINC codes found": Try alternative search terms or report failure.

  6. If you get codes but they don't semantically match your query:

    • Increase max_codes to see more options.

    • Look for better matches in COMPONENT, SHORTNAME, LONG_COMMON_NAME fields.

Rules:

  • Function returns codes sorted by popularity - YOU decide which are most relevant.

  • Don't automatically pick the first (most common) codes.

  • Prioritize semantic relevance: exact matches in COMPONENT > SHORTNAME > partial matches.

  • Balance popularity with relevance (very rare codes might not be clinically useful).

  • Keep increasing max_fetch until you exhaust all available records (max_fetch >= RecordsFound).

  • Increase max_codes only when you need more options to find better semantic matches.

Args: component_name: The name of the observation to get the LOINC code for (i.e. "glucose"). max_codes: The maximum number of LOINC codes to return. max_fetch: The maximum number of LOINC codes to fetch from the API. Returns: LOINC codes sorted by popularity - you must select the most semantically relevant ones.

request_observation_resourceA

Makes an HTTP request to the FHIR server. Use this tool to perform CRUD operations only on the FHIR Observation resource. Rules: - When creating or updating an observation, use only the data explicitly provided by the user. - Do not guess, auto-fill, or assume any missing data. - When deleting an observation, ask the user for confirmation with details of the observation and wait for the user's confirmation. - Provide links to the app (not api) observation resource in the final response.

Args: method: HTTP method (GET, POST, PUT, DELETE) path: Resource path (e.g., "/Observation", "/Observation?subject=Patient/123") body: Optional JSON data for POST/PUT requests)

Returns: JSON response from the FHIR server

request_condition_resourceA

Makes an HTTP request to the FHIR server. Use this tool to perform CRUD operations only on the FHIR Condition resource. Rules: - When creating or updating a condition, use only the data explicitly provided by the user. - Do not guess, auto-fill, or assume any missing data. - When deleting a condition, ask the user for confirmation with details of the condition and wait for the user's confirmation. - Provide links to the app (not api) condition resource in the final response.

Args: method: HTTP method (GET, POST, PUT, DELETE) path: Resource path (e.g., "/Condition", "/Condition?patient=Patient/123") body: Optional JSON data for POST/PUT requests)

Returns: JSON response from the FHIR server

request_allergy_intolerance_resourceA

Makes an HTTP request to the FHIR server. Use this tool to perform CRUD operations only on the FHIR AllergyIntolerance resource. Rules: - When creating or updating an allergy intolerance, use only the data explicitly provided by the user. - Do not guess, auto-fill, or assume any missing data. - When deleting an allergy intolerance, ask the user for confirmation with details of the allergy intolerance and wait for the user's confirmation. - Provide links to the app (not api) allergy intolerance resource in the final response.

Args: method: HTTP method (GET, POST, PUT, DELETE) path: Resource path (e.g., "/AllergyIntolerance", "/AllergyIntolerance?patient=Patient/123") body: Optional JSON data for POST/PUT requests)

Returns: JSON response from the FHIR server

request_encounter_resourceA

Makes an HTTP request to the FHIR server. Use this tool to perform CRUD operations only on the FHIR Encounter resource. Rules: - When creating or updating an encounter, use only the data explicitly provided by the user. - Do not guess, auto-fill, or assume any missing data. - When deleting an encounter, ask the user for confirmation with details of the encounter and wait for the user's confirmation. - Provide links to the app (not api) encounter resource in the final response.

Args: method: HTTP method (GET, POST, PUT, DELETE) path: Resource path (e.g., "/Encounter", "/Encounter?patient=Patient/123") body: Optional JSON data for POST/PUT requests)

Returns: JSON response from the FHIR server

request_immunization_resourceA

Makes an HTTP request to the FHIR server. Use this tool to perform CRUD operations only on the FHIR Immunization resource. Rules: - When creating or updating an immunization, use only the data explicitly provided by the user. - Do not guess, auto-fill, or assume any missing data. - When deleting an immunization, ask the user for confirmation with details of the immunization and wait for the user's confirmation. - Provide links to the app (not api) immunization resource in the final response.

Args: method: HTTP method (GET, POST, PUT, DELETE) path: Resource path (e.g., "/Immunization", "/Immunization?patient=Patient/123") body: Optional JSON data for POST/PUT requests)

Returns: JSON response from the FHIR server

request_medication_resourceA

Makes an HTTP request to the FHIR server. Use this tool to perform CRUD operations only on the FHIR Medication resource. Rules: - When creating or updating a medication, use only the data explicitly provided by the user. - Do not guess, auto-fill, or assume any missing data. - When deleting a medication, ask the user for confirmation with details of the medication and wait for the user's confirmation. - Provide links to the app (not api) medication resource in the final response.

Args: method: HTTP method (GET, POST, PUT, DELETE) path: Resource path (e.g., "/Medication", "/Medication?code=aspirin") body: Optional JSON data for POST/PUT requests)

Returns: JSON response from the FHIR server

request_document_reference_resourceA

Makes an HTTP request to the FHIR server. Use this tool to perform CRUD operations only on the FHIR DocumentReference resource. Rules: - When creating or updating a document reference, use only the data explicitly provided by the user. - Do not guess, auto-fill, or assume any missing data. - When deleting a document reference, ask the user for confirmation with details of the document and wait for the user's confirmation. - Provide links to the app (not api) document reference resource in the final response.

Args: method: HTTP method (GET, POST, PUT, DELETE) path: Resource path (e.g., "/DocumentReference", "/DocumentReference?patient=Patient/123") body: Optional JSON data for POST/PUT requests

Returns: JSON response from the FHIR server

add_document_to_pineconeB

IMPORTANT: Always inform the user at the beginning of your response that this search operation may take some time because the embedding model will be loaded into cache. Adds a document to the Pinecone vector index for the specified FHIR DocumentReference ID.

This tool should be used to ingest new documents into the Pinecone index.

Rules: - If you cannot determine the format of the document fitting the format from the list, provide the format as None. - After adding the document, the Pinecone index may take up to 1 minute to update before the document is searchable.

Args: url (str): The URL of the document to be added. fhir_document_id (str): The ID of the FHIR DocumentReference resource corresponding to the document. format (literal | None): The format of the document.

Returns: str: Confirmation message that the document was added or already exists. PineconeError: Error object with a message if the operation fails.

search_pineconeA

IMPORTANT: Always inform the user at the beginning of your response that this search operation may take some time because the embedding model will be loaded into cache. Searches the Pinecone vector index for information related to the given document by FHIR DocumentReference ID.

Use this tool when the user requests information from the documents, notes, etc.

Rules: - Firstly, prepare fhir_document_id by running the appropriate tool. - If the error message "Document does not exist in Pinecone index" is returned, automatically trigger the 'add_document_to_pinecone' tool to add the missing document to the index. - Translate the user's query into the language of the document before performing the search. - Base all answers strictly on the content found in the Pinecone index documents. - If the user's question is unrelated to the indexed documents, respond that the information is not available in the documents. - If the query is unclear or ambiguous, ask the user to clarify or provide more details. - You can modify the query to make it more specific and relevant to the document.

Args: query (str): The user's search query. fhir_document_id (str): The ID of the FHIR DocumentReference resource to search within - it is the same as the FHIR ID of the document. top_k (int, optional): The maximum number of search results to return. Defaults to 10.

Returns: list[PineconeSearchResponse]: List of search results matching the query. PineconeError: Error object with a message if the search fails.

request_family_member_history_resourceA

Makes an HTTP request to the FHIR server. Use this tool to perform CRUD operations only on the FHIR FamilyMemberHistory resource. Rules: - When creating or updating a family member history, use only the data explicitly provided by the user. - Do not guess, auto-fill, or assume any missing data. - When deleting a family member history, ask the user for confirmation with details of the family member history and wait for the user's confirmation. - Provide links to the app (not api) family member history resource in the final response.

Args: method: HTTP method (GET, POST, PUT, DELETE) path: Resource path (e.g., "/FamilyMemberHistory", "/FamilyMemberHistory?patient=Patient/123") body: Optional JSON data for POST/PUT requests)

Returns: JSON response from the FHIR server

request_generic_resourceA

Makes an HTTP request to the FHIR server. Use this tool to perform CRUD operations on any FHIR resource ONLY if the other tools are not applicable.

Rules: - When creating or updating a resource, use only the data explicitly provided by the user. - Do not guess, auto-fill, or assume any missing data. - When deleting a resource, ask the user for confirmation with details of the resource and wait for the user's confirmation. - Provide links to the app (not api) resource in the final response.

Args: method: HTTP method (GET, POST, PUT, DELETE) path: Resource path body: Optional JSON data for POST/PUT requests)

Returns: JSON response from the FHIR server

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/maheshbalan/fhir-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server