Skip to main content
Glama
rkirkendall

Medplum MCP Server

by rkirkendall

updateEncounter

Modify encounter details in healthcare workflows by specifying the encounter ID and updating fields such as status. Facilitates accurate and timely record management within Medplum FHIR servers.

Instructions

Updates an existing encounter. Requires the encounter ID and the fields to update.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
encounterIdYesThe unique ID of the encounter to update.
statusNoNew status for the encounter.

Implementation Reference

  • Core handler function that performs the updateEncounter tool logic: authenticates, validates inputs, reads existing Encounter, applies updates (with class handling), and updates via Medplum.
    export async function updateEncounter(encounterId: string, updates: UpdateEncounterArgs): Promise<Encounter> {
      await ensureAuthenticated();
    
      if (!encounterId) {
        throw new Error('Encounter ID is required to update an encounter.');
      }
      if (!updates || Object.keys(updates).length === 0) {
        throw new Error('Updates object cannot be empty for updating an encounter.');
      }
    
      const existingEncounter = await medplum.readResource('Encounter', encounterId);
      if (!existingEncounter) {
        throw new Error(`Encounter with ID ${encounterId} not found.`);
      }
    
      const { resourceType, id, ...safeUpdates } = updates as any;
      
      // Handle class conversion
      if (typeof safeUpdates.class === 'string') {
        safeUpdates.class = mapEncounterClass(safeUpdates.class);
      }
      if (updates.classCode) {
        safeUpdates.class = mapEncounterClass(updates.classCode);
        delete safeUpdates.classCode; // Remove the convenience field
      }
      
      const encounterToUpdate: Encounter = {
        ...existingEncounter,
        ...safeUpdates,
        resourceType: 'Encounter',
        id: encounterId,
      };
    
      return medplum.updateResource(encounterToUpdate);
    }
  • Detailed input schema definition for the updateEncounter tool, including properties for encounterId and updates object with examples for common fields like status, class, period.
    {
      name: 'updateEncounter',
      description: 'Updates an existing encounter. Requires the encounter ID and an object containing the fields to update.',
      input_schema: {
        type: 'object',
        properties: {
          encounterId: {
            type: 'string',
            description: 'The unique ID of the encounter to update.',
          },
          updates: {
            type: 'object',
            description: "An object containing the encounter fields to update. Refer to the Encounter FHIR resource definition for possible fields. For example, to update status: { \"status\": \"in-progress\" }. For fields like 'class' or 'type', you can provide a simple code (e.g., { \"class\": \"IMP\" }) or the full FHIR Coding/CodeableConcept structure if needed for precision.",
            properties: {
              // Define common, simple updatable fields here to guide the LLM.
              // More complex structures can be passed, and the description guides the LLM.
              status: {
                type: 'string',
                description: "Update the status of the encounter (e.g., planned, in-progress, finished). Optional.",
                enum: ['planned', 'arrived', 'triaged', 'in-progress', 'onleave', 'finished', 'cancelled', 'entered-in-error', 'unknown'],
              },
              class: {
                type: ['string', 'object'], // Can be a simple code string or a FHIR Coding object
                description: "Update the class of the encounter (e.g., AMB, IMP, EMER as a string, or a FHIR Coding object). Optional.",
              },
              // For 'type' (CodeableConcept[]), it's harder to simplify for LLM updates via simple properties.
              // The main 'updates' description guides it to provide FHIR structure or simple type code string within the type array.
              // Example: updates: { type: [{ coding: [{ system: 'some-system', code: 'XYZ' }] }] } or potentially simplified if handled by util.
              periodStart: {
                type: 'string',
                format: 'date-time',
                description: "Update the start date and time of the encounter (ISO8601 format). Optional.",
              },
              periodEnd: {
                type: 'string',
                format: 'date-time',
                description: "Update the end date and time of the encounter (ISO8601 format). Optional.",
              },
              // Add other commonly updated simple fields as necessary.
              // For complex fields like 'participant', 'reasonCode', 'hospitalization', the LLM should provide them
              // directly in the 'updates' object matching FHIR structure, guided by the main description.
            },
            additionalProperties: true, // Allows other FHIR fields not explicitly listed here
          },
        },
        required: ['encounterId', 'updates'],
      },
  • src/index.ts:415-433 (registration)
    MCP tool registration in mcpTools array, providing name, description, and simplified inputSchema for listTools request.
    {
      name: "updateEncounter",
      description: "Updates an existing encounter. Requires the encounter ID and the fields to update.",
      inputSchema: {
        type: "object",
        properties: {
          encounterId: {
            type: "string",
            description: "The unique ID of the encounter to update.",
          },
          status: {
            type: "string",
            description: "New status for the encounter.",
            enum: ["planned", "arrived", "triaged", "in-progress", "onleave", "finished", "cancelled"],
          },
        },
        required: ["encounterId"],
      },
    },
  • src/index.ts:33-37 (registration)
    Import of the updateEncounter handler function from encounterUtils into the main index.ts for use in toolMapping.
      createEncounter,
      getEncounterById,
      updateEncounter,
      searchEncounters,
    } from './tools/encounterUtils.js';
  • src/index.ts:950-988 (registration)
    Maps the string 'updateEncounter' to the imported handler function in toolMapping object used by the CallToolRequest handler.
    const toolMapping: Record<string, (...args: any[]) => Promise<any>> = {
      createPatient,
      getPatientById, 
      updatePatient,
      searchPatients,
      searchPractitionersByName,
      createPractitioner,
      getPractitionerById,
      updatePractitioner,
      searchPractitioners,
      createOrganization,
      getOrganizationById,
      updateOrganization,
      searchOrganizations,
      createEncounter,
      getEncounterById,
      updateEncounter,
      searchEncounters,
      createObservation,
      getObservationById,
      updateObservation,
      searchObservations,
      createMedicationRequest,
      getMedicationRequestById,
      updateMedicationRequest,
      searchMedicationRequests,
      createMedication,
      getMedicationById,
      searchMedications,
      createEpisodeOfCare,
      getEpisodeOfCareById,
      updateEpisodeOfCare,
      searchEpisodesOfCare,
      createCondition,
      getConditionById,
      updateCondition,
      searchConditions,
      generalFhirSearch,
    };
  • TypeScript interface defining the arguments for updateEncounter, extending partial Encounter while omitting resourceType and id, with extra classCode convenience field.
    export interface UpdateEncounterArgs extends Omit<Partial<Encounter>, 'resourceType' | 'id'> {
      // If specific simplified fields are needed, they can be added here,
      // but Partial<Encounter> provides flexibility.
      // Example: classCode?: string; to simplify updating class via a code.
      classCode?: string; // Added for convenience - will be converted to Coding
    }
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It states this is an update operation (implying mutation) and requires an encounter ID, but doesn't disclose critical behavioral traits: whether this requires specific permissions, what happens to unspecified fields (partial vs full updates), if changes are reversible, rate limits, or what the response contains. For a mutation tool with zero annotation coverage, this leaves significant gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise with two sentences that directly state the tool's function and requirements. There's no unnecessary verbiage, and it's front-loaded with the core purpose. However, it could be slightly more structured by explicitly listing updatable fields or separating requirements from behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given this is a mutation tool with no annotations, no output schema, and 2 parameters, the description is incomplete. It doesn't explain what happens on success/failure, what data is returned, error conditions, or behavioral constraints. For an update operation in a healthcare context (encounters), more contextual information about permissions, validation, or side effects would be expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents both parameters (encounterId and status with enum values). The description adds minimal value beyond the schema: it mentions 'fields to update' which hints at the status parameter, but doesn't provide additional semantic context like valid status transitions or field dependencies. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Updates') and resource ('an existing encounter'), making the purpose unambiguous. It distinguishes from sibling tools like 'createEncounter' by specifying it updates existing records rather than creating new ones. However, it doesn't specify what fields can be updated beyond the general 'fields to update' phrase.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides minimal guidance: it mentions requiring encounter ID and fields to update, but offers no explicit when-to-use rules, no alternatives (like when to use updateCondition vs updateEncounter), and no prerequisites beyond the ID requirement. It doesn't help the agent choose between this and other update tools in the sibling list.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Related Tools

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/rkirkendall/medplum-mcp'

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