Part 2: Building the Engine — Tools, URIs, and the Art of Indexing FHIR

Part 2 of a three-part series on building our first MCP server for healthcare interoperability. Where We Left Off In Part 1 , we talked about why we built an MCP server for FHIR and the architectural decisions we made before writing code. Now we're going to get into the how — the implementation details, the patterns that emerged, and the places where the reality of FHIR made us rethink our approach. Phase 1: Turning Thousands of JSON Files Into a Searchable Index The Data Problem FHIR packages are distributed as folders of JSON files. A single core FHIR package (say, hl7.fhir.r4.core ) contains thousands of files: one for each StructureDefinition, ValueSet, CodeSystem, SearchParameter, OperationDefinition, and so on. Each file looks something like this (simplified): { "resourceType" : "StructureDefinition" , "id" : "Patient" , "url" : "http://hl7.org/fhir/StructureDefinition/Patient" , "name" : "Patient" , "title" : "Patient Resource" , "status" : "active" , "fhirVersion" : "4.0.1" , "