// the find
Vermonster/fhir-kit-client
Node.js FHIR client library
A Node.js FHIR R4 client library that wraps the FHIR REST API with typed methods for reads, writes, search, operations, batch/transaction, pagination, and SMART App Launch discovery. v2 dropped all polyfills in favor of native fetch (Node 18+) and is ESM-only. Aimed at backend developers building health data integrations in TypeScript.
- Clean API surface: every FHIR interaction has a dedicated typed method with sensible parameter objects, and the `Client.httpFor()` escape hatch gives you raw Request/Response when you need headers, status codes, or ETags without fighting the library.
- Minimal dependency footprint—only `agentkeepalive` and `debug` at runtime. No bundled polyfills, no heavy XML parsers sitting around.
- Reference resolution handles the annoying edge cases: absolute URLs, relative references, in-bundle references, and contained resources (#fragment), which most homegrown FHIR clients miss or get wrong.
- The `requestSigner` hook is a practical design choice—the AWS SigV4/HealthLake example in the README is exactly the kind of thing teams hit in production and normally have to monkey-patch themselves.
- ESM-only with no CJS fallback will break any project still on CommonJS or using a bundler/test runner that doesn't handle pure ESM well. That's a real-world adoption barrier that the README acknowledges but doesn't soften.
- Return types are generic (`FhirResource` / `unknown`) and rely on the caller doing their own narrowing or reaching for `@types/fhir`. The library could use discriminated union overloads keyed on `resourceType` to give you `fhir4.Patient` from `client.read({ resourceType: 'Patient', ... })` without any extra cast.
- SMART support is discovery-only—you get the authorize/token URLs, but there's no built-in OAuth flow, token refresh, or session management. Fine if you're stitching together your own auth, but the CDS Hooks and SMART examples in `/examples` are standalone scripts that don't demonstrate how to close that gap in a real app.
- The test directory still has both the old `.js` test files and new `.ts` rewrites side-by-side (e.g., `client-test.js` and `client.test.ts`), which suggests an in-progress migration and means you can't be sure which tests are actually running or authoritative.