Core Idea

A FHIR server is a standards-aware interoperability layer for healthcare data. It combines FHIR resource storage with validation, search, versioning, references, profiles and standardized API behavior, rather than acting as a simple CRUD database.

WSO2 FHIR Server takes a focused approach: a lightweight FHIR R4 server built with Go and PostgreSQL, using typed search indexes generated when resources are written. It provides the core persistence and search layer while expecting capabilities such as authentication, authorization, TLS, terminology services and some advanced FHIR features to be handled by surrounding platform components.

Standards-Aware Interoperability Layer —> “A layer that understands FHIR rules and uses them to let different healthcare systems exchange data consistently.”

Research boundary and evidence quality

This note reflects the documentation and repositories available on 2026-09-16. FHIR servers change quickly. Capability statements, release notes, edition restrictions and deployment configuration are more authoritative than marketing pages.

Evidence labels used below:

Documented: stated in official documentation or a source repository.

Vendor claim: a product claim that still needs workload-specific validation.

Verify: depends on release, edition, plugin, configuration or an external service.

The original announcement is a LinkedIn post by Nirmal Fernando published on 2026-09-16:

LinkedIn announcement

WSO2 FHIR Server repository

WSO2 FHIR Server documentation

FHIR Servers

1. What problem does a FHIR server solve?

Healthcare data is distributed across EHRs, laboratory systems, pharmacies, claims platforms, imaging systems, registries, patient apps and research systems. These systems often use different schemas, identifiers, vocabularies, transport protocols and access-control models. This is the same integration and governance problem explored in REST API design and identity and OAuth security.

Without a common interoperability layer, every application needs a separate integration for every source:

flowchart TD
    A[Patient app] --> I[Custom integrations]
    C[Lab system] --> I
    D[Claims system] --> I
    I --> E[Many mappings and APIs]
    E --> F[Fragile data exchange]

FHIR, or Fast Healthcare Interoperability Resources, addresses this by defining:¹

Resources: standard information models such as Patient, Observation, MedicationRequest, Encounter and DiagnosticReport.
Representations: commonly JSON, XML and sometimes RDF.
Relationships: references between resources.
Profiles and Implementation Guides: constraints for a country, payer, programme or clinical use case.
REST interactions: create, read, update, patch, delete, search, history, transactions and operations.
Conformance metadata: a CapabilityStatement at /metadata.
Terminology hooks: CodeSystem, ValueSet, ConceptMap and terminology operations.
Security integration points: commonly OAuth 2.0 and SMART-on-FHIR, although security implementation is not identical across servers.

HL7 describes FHIR as a standard for exchanging healthcare information. Its design uses resources and well-defined APIs to make information easier to exchange while retaining extensibility and clinical meaning.

The important distinction

FHIR is an interoperability specification, not a complete hospital information system. A FHIR server usually does not provide all of these things by itself:

Clinical workflows and user interfaces.
Identity proofing and enterprise IAM.
Consent policy for every local legal context.
A complete terminology business and licensing model.
Analytics, data warehouse and AI governance.
HL7 v2 and CDA transformation for every source.
Backup, disaster recovery and operational support.

A production architecture normally combines a FHIR server with gateways, identity, terminology, eventing, audit, analytics and integration services.

2. Problem statement

A production healthcare platform needs a reliable, searchable and governed canonical data layer that can:

Ingest data from different sources without losing provenance.
Preserve the original clinical meaning and resource history.
Validate structure, cardinality, references, profiles and terminology.
Support predictable searches across nested and referenced data.
Expose standard APIs to mobile, web, payer, provider and research applications.
Enforce patient, organisation, tenant and user-level access controls.
Handle transactions and asynchronous bulk movement of data.
Emit audit, metrics, logs and change events.
Operate at the required volume, latency and availability.
Support the FHIR versions and Implementation Guides used by partners.
Permit safe AI access without exposing uncontrolled PHI or write operations.

The engineering challenge is not just storing JSON. It is maintaining the relationship between resource bodies, versions, search indexes, references, profiles, terminology and authorization while the data is updated concurrently.

A useful target architecture is:

flowchart TD
    S[Source systems] --> X[Integration and mapping]
    X --> G[API gateway / IAM]
    G --> F[FHIR server]
    F --> P[FHIR persistence]
    F --> T[Terminology Srv.]
    F --> E[Subscriptions]
    F --> A[observability]

Why use FHIR instead of a normal REST API?

A normal REST API can expose healthcare data, but it does not provide a shared healthcare contract. Each team would need to define its own resource names, fields, identifiers, terminology, versioning, search semantics, error format and authorization model.

FHIR adds a domain standard above HTTP. It gives different organizations a common vocabulary and a predictable interaction model while still allowing extensions through profiles and Implementation Guides.¹

Concern	Normal REST API	FHIR API
Data model	Defined by one application or organization	Shared resource model such as `Patient`, `Observation` and `MedicationRequest`
Meaning	Hidden in custom documentation and code	Defined by HL7 resources, datatypes, profiles and terminology
Search	Custom query parameters and response shapes	Standard search parameters, modifiers, chaining and Bundle results
Version history	Must be designed by each team	`meta.versionId`, `vread` and `_history` are standardized interactions
Validation	Custom JSON Schema or application logic	Base FHIR validation plus profiles, invariants and terminology bindings
Interoperability	Every consumer learns a different API	Clients can reuse FHIR SDKs, validators, test suites and Implementation Guides
References	Often informal IDs or nested objects	Typed FHIR references such as `Patient/123` with defined search behavior
Transactions	Custom bulk endpoints or database semantics	Standard batch and transaction Bundles
Capability discovery	OpenAPI or custom documentation	`/metadata` CapabilityStatement describes supported FHIR behavior
Ecosystem	General web tooling	Healthcare-specific tooling, registries, terminology services and compliance profiles

FHIR is not automatically better for every API

Use a normal REST API for a private internal service with a narrow domain, no external interoperability requirement and a simple data lifecycle. FHIR adds modeling, validation, terminology and operational complexity.

Use FHIR when data must cross organizational boundaries, when clients need a standard clinical model, when an Implementation Guide is mandatory, or when the platform must support patient, provider, payer, research or public-health interoperability.

The practical pattern is often both:

flowchart LR
    A[External healthcare systems] --> B[FHIR API]
    B --> C[Canonical clinical model]
    C --> D[Internal REST or domain APIs]
    D --> E[Product workflows]

FHIR should be the interoperability boundary. Internal services can still use simpler domain-specific APIs behind that boundary. This connects to REST API design and identity and OAuth security.

3. What a FHIR server actually does

Core request path

sequenceDiagram
    participant C as FHIR client
    participant G as Gateway/IAM
    participant F as FHIR server
    participant V as Validator
    participant D as Database
    participant T as Terminology

    C->>G: HTTPS request with token
    G->>G: Authenticate and bind tenant
    G->>F: Authorized FHIR request
    F->>V: Parse and validate
    V->>T: Optional terminology check
    T-->>V: Code result
    V-->>F: Valid or OperationOutcome
    F->>D: Store resource and indexes
    D-->>F: Version and search state
    F-->>C: FHIR response

Main internal responsibilities

Responsibility	Why it matters
Resource parsing	Reject malformed JSON/XML and preserve FHIR semantics.
Base validation	Enforce the base FHIR StructureDefinitions.
Profile validation	Enforce an Implementation Guide such as US Core.
Search indexing	Make searches predictable without scanning every resource document.
Versioning	Preserve current and historical resource states.
Referential integrity	Detect missing or unsafe local references.
Transactions	Apply related writes atomically when the server supports them.
CapabilityStatement	Tell clients what this deployment really supports.
Terminology	Validate codes and expand or query value sets.
Authorization boundary	Ensure a caller sees only permitted resources.
Observability	Provide evidence for availability, latency and audit.

A FHIR server should be evaluated by its actual CapabilityStatement and tested behavior, not by the number of resource types it accepts.

4. Existing solution families

4.1 Open-source embeddable or self-hosted servers

Examples include:

HAPI FHIR: mature Java library and JPA server, Apache 2.0.
WSO2 FHIR Server: new Go and PostgreSQL server, Apache 2.0, currently R4-focused.
Medplum: Apache 2.0 FHIR-native developer platform with hosted and self-hosted options, currently R4-centered.
Microsoft FHIR Server for Azure: open-source .NET server that underpins or relates to Microsoft offerings, but the managed product lifecycle must be checked separately.
Blaze and other focused servers: useful for particular R4 data and API use cases, but feature coverage and operational maturity vary.

These options provide control over deployment, data locality and extension. They also transfer more responsibility to the engineering team for upgrades, security, database operations, backups and support.

4.2 Commercial self-hosted platforms

Examples include:

Firely Server: .NET-based, standards-focused, plugin-oriented and commercial.
Aidbox: commercial PostgreSQL-based healthcare platform with a free developer tier and paid production licensing.
Smile CDR: commercial enterprise distribution and platform built around HAPI FHIR and additional interoperability modules.

These products usually add support, certifications, administration, security integration, higher-level workflows and enterprise modules. The trade-off is licensing cost and dependency on a vendor roadmap.

4.3 Managed cloud FHIR services

Examples include:

Azure Health Data Services FHIR service.
Google Cloud Healthcare API FHIR stores.
AWS HealthLake.

Managed services reduce infrastructure work and integrate with the provider’s IAM, storage, logging, analytics and AI services. The trade-offs are cloud coupling, region and data-residency constraints, service-specific behavior, quota models and less access to the underlying database.

4.4 FHIR facade and gateway solutions

A facade exposes FHIR over a non-FHIR source without necessarily becoming the system of record. It is useful when data must remain in an EHR or legacy system.

A gateway can unify several FHIR endpoints, translate versions, enforce authorization and provide a single entry point. It does not automatically fix inconsistent source semantics, missing terminology or poor upstream data quality.

4.5 Application platforms built around FHIR

Aidbox, Medplum and Smile CDR are broader than a storage server. They may include identity, UI, SDKs, bots, workflows, eventing, analytics, custom operations or integration modules.

This is useful when the team wants to build a healthcare product quickly. It is less useful when the requirement is only a small standards-compliant persistence layer.

5. Main FHIR server options

The matrix below is a first screening tool. It is not a certification matrix. A check mark means that the capability is documented somewhere in the product ecosystem. It does not mean that the capability is included in every edition or enabled by default.²

Option	Type and architecture	FHIR coverage	Security position	Bulk/events	Main advantage	Main risk
WSO2 FHIR Server	Open-source Go binary with PostgreSQL	Current docs focus on R4	Gateway or ingress expected for auth, authorization and TLS	Bulk Data and subscriptions are not in the current eight-operation list; verify releases	Small, stateless, PostgreSQL-native, typed write-time indexes	New project, R4 only, external security boundary
HAPI FHIR JPA	Open-source Java library and JPA server	Mature multi-version modules including R4/R4B/R5, version dependent	Extensible interceptors and external IAM; deployment team owns security	Bulk export/import, subscriptions and partitioning available with configuration/modules	Mature ecosystem, extensibility and deep FHIR feature coverage	Java/JPA operational complexity, database indexing and tuning burden
Firely Server	Commercial .NET pipeline with plugins	STU3/R4 and newer-version support depends on release/edition	SMART v1/v2, RBAC/ABAC and plugins documented	Bulk Data, subscriptions and terminology modules; some features separately licensed	Strong FHIR expertise, validation and plugin model	Commercial licensing, version and edition constraints
Aidbox	Commercial PostgreSQL platform with JSONB and app layer	Vendor docs advertise R3 through R5 and R6 ballot support	OAuth/OIDC, SMART, RBAC/ABAC and physical or logical multi-tenancy	Bulk import/export and topic-based subscriptions	Broad platform, developer tools, SQL-on-FHIR, GraphQL and AI/MCP	Proprietary production licensing and configuration complexity
Medplum	Apache 2.0 TypeScript platform, hosted or self-hosted	R4 is the main documented production surface	OAuth2, SMART, access policies and MFA options	Bulk Data, FHIR subscriptions, WebSockets and bots	Fast product development and strong TypeScript experience	R5 support and very large-scale behavior need current verification
Smile CDR	Commercial enterprise HAPI-based platform	Multi-version support depends on modules and release	Full SMART, gateway and partition security features	Bulk, subscriptions, MDM, gateway and integration modules	Enterprise support, MegaScale, interoperability modules	Commercial cost and platform complexity
Azure Health Data Services	Managed PaaS, SQL-backed FHIR service	Current managed service documentation lists R4	Entra ID, SMART integration, RBAC, audit	System/group/patient `$export`, ADLS Gen2 and integrations	Managed operations and Azure ecosystem	Azure lock-in, managed API limits and retirement/migration boundaries
Google Cloud Healthcare API	Managed FHIR stores	DSTU2/STU3/R4/R5 store versions, version-specific	Google Cloud IAM and service accounts	GCS/BigQuery export and Pub/Sub/streaming integrations	Strong analytics integration and managed operations	Cloud-specific APIs and FHIR Bulk Data distinction must be checked
AWS HealthLake	Managed R4 data store plus analytics and NLP	FHIR R4 is the main documented surface	IAM, SigV4 and SMART options, depending on tier/configuration	Bulk export and AWS analytics; medical NLP and transformation features	AI/analytics integration and managed scale	AWS coupling, tier restrictions and product-specific behavior

Choose WSO2 when the core requirement is a lightweight, self-hosted R4 API and the organization already operates IAM, gateways, PostgreSQL and external terminology.
Choose HAPI when implementation depth, community adoption, Java extensibility and broad FHIR features matter more than a small binary.
Choose Firely when standards expertise, .NET integration, validation and vendor support are high priorities.
Choose Aidbox or Medplum when the FHIR server is also the application platform.
Choose Smile CDR when a supported enterprise interoperability suite is required.
Choose Azure, Google or AWS when managed operations and deep cloud analytics are more valuable than portability.

WSO2 FHIR Server in depth

Current architecture

The current WSO2 repository describes a FHIR R4 REST server written in Go and backed by PostgreSQL. It presents a single binary plus database deployment model.³

WSO2 FHIR Server architecture

The central storage idea is:⁴

flowchart TD
    A[FHIR request] --> B[Parse and validate]
    B --> C[Resource JSON]
    B --> D[Extract searchable values]
    C --> E[(Resource and history tables)]
    D --> F[(Typed search tables)]
    E --> G[Search result resources]
    F --> G

The resource body remains JSON. Searchable values are extracted into typed index tables such as string, token, date, number, quantity, URI and reference indexes. A write, history snapshot and index update commit together.

This is similar in broad shape to HAPI’s resource-plus-search-index approach, but the implementation, schema and query planner are different. It is not accurate to assume that two systems will have the same performance just because both use typed indexes.

Documented capabilities

The current documentation lists:⁵

CRUD, patch, versioned reads and history.
Conditional interactions.
Batch and atomic transaction Bundles.
Rich R4 search, including chaining, reverse chaining, _include and _revinclude.
Base validation and optional profile validation.
Implementation Guide packages loaded at startup.
Referential integrity checks on writes and deletes.
JSON, XML and RDF Turtle representations.
Patient, Encounter and Practitioner compartment search.
$validate, $everything, $lastn, $document, $convert, $meta, $meta-add and $meta-delete.
Physical or shared multi-tenancy.
Prometheus metrics, structured logs and health endpoints.
Helm deployment and PostgreSQL Row-Level Security in shared tenancy designs.

Important boundaries

The architecture documentation explicitly places these concerns outside the server:⁶

TLS termination.
Authentication and token validation.
Authorization and tenant binding.
Rate limiting and network policy.
Security audit integration.
Terminology reasoning and ValueSet expansion.

The server documentation also warns that system-level and type-level $meta currently aggregate across the whole database in a multi-tenant deployment. Those scopes should be blocked for tenants at the gateway until their tenant behavior is safe.

The deployment documentation describes an important timeout behavior. A long transaction Bundle can continue after the HTTP write timeout closes the connection. The database transaction may commit even when the client receives EOF. A client must reconcile state before retrying.⁷

Performance claims

The announcement and README claim:

Around a 20 MB binary.
A container image under 25 MB.
Cold start in under one second.
A stateless and Helm-deployable service.

The current README also links to a third-party performance benchmark. That benchmark is not a neutral benchmark of WSO2: the public Health Samurai benchmark currently compares Aidbox, HAPI, Medplum and Microsoft FHIR Server, not WSO2. It is useful evidence about benchmark methodology, but it does not validate the WSO2 headline numbers.

The correct production approach is to benchmark WSO2 using:

The same Synthea or real-shaped dataset used by the target workload.
The required FHIR profiles and terminology configuration.
Cold start and warm start measurements.
CRUD, transaction Bundle, search, history and validation workloads.
Tenant isolation tests under concurrency.
PostgreSQL storage growth and index maintenance.
p95 and p99 latency, not only average requests per second.

WSO2 versus HAPI FHIR

Architectural comparison

Dimension	WSO2 FHIR Server	HAPI FHIR JPA Server
Runtime	Go, single binary	Java, Spring/Hibernate/JPA ecosystem
License	Apache 2.0	Apache 2.0
Primary storage	PostgreSQL	Relational databases through JPA, especially PostgreSQL
Resource body	JSON document model	Resource master/version tables with stored content
Search model	Typed index tables and query-plan selection	Typed HFJ search-index tables and DAO query planning
FHIR focus	R4	Multiple FHIR versions through modules, version dependent
IG/profile model	Packages loaded at startup	Package, validation and runtime configuration options
Transactions	Documented atomic transactions	Mature transaction and batch support, with many configuration options
Bulk Data	Not in current documented operation list	Available in JPA server modules/configuration
Subscriptions	Not in current documented operation list	JPA subscription module supports several delivery modes
SMART	Expected outside the server	Usually supplied through interceptors, deployment components or commercial distributions
Multi-tenancy	Shared PostgreSQL RLS or dedicated deployment models	Partitioning and interceptors, with known configuration limitations
Extensibility	Go codebase and external gateway/services	Java providers, interceptors, modules and custom storage extensions
Operational footprint	Smaller by design	Heavier but feature-rich and mature
Project maturity	New and changing	Long-running ecosystem with broad adoption

Decision summary

Choose WSO2 over HAPI when:

R4 is sufficient for the whole integration boundary.
A small Go binary and simple deployment are strategic requirements.
PostgreSQL is the standard database platform.
The team prefers a focused server over a broad Java framework.
IAM, gateway, terminology and eventing are already separate platform capabilities.
The team can accept a newer project and perform deeper conformance testing.

Choose HAPI over WSO2 when:

Multiple FHIR versions or older integrations are needed.
You need mature subscriptions, Bulk Data, MDM, CQL, CDS Hooks or broad modules.
The organization already operates Java and Spring platforms.
You need deep custom server behavior through providers and interceptors.
The project has a long-lived HAPI community and commercial support path.

Neither choice removes the need for an enterprise security model, data governance, terminology operations, backup and disaster recovery.

AI integration and MCP servers

What MCP adds

The Model Context Protocol is a JSON-RPC-based protocol for connecting an AI host to external tools, resources and prompts. It does not make an LLM clinically safe and it does not replace OAuth, SMART-on-FHIR, audit or consent.⁸ This follows the vault’s three-tier MCP architecture and AI-native platform governance patterns.

For FHIR, MCP is an adapter layer:

flowchart LR
    U[User] --> H[AI host]
    H --> M[MCP server]
    M --> I[IAM and policy]
    I --> F[FHIR server]
    F --> D[(Clinical data)]
    M --> R[Redaction and FHIRPath filtering]
    R --> H

The FHIR server remains the system that understands resource validation, search semantics, history and authorization. The MCP server should translate carefully bounded tool calls into FHIR requests.⁸

WSO2 FHIR MCP Server

WSO2 publishes a separate wso2/fhir-mcp-server project. It is a general MCP bridge that can expose any compatible FHIR server, not only the WSO2 Go server. The repository includes examples using HAPI FHIR.

Documented capabilities include:⁹

MCP transports: stdio, SSE and Streamable HTTP.
SMART-on-FHIR or OAuth 2.0 authorization support.
FHIR CapabilityStatement discovery through a get_capabilities tool.
search, read, create, update and delete tools.
Custom FHIR operations such as $everything, $lastn and $expand where the upstream server supports them.
get_user support when the token includes suitable fhirUser and OpenID scopes.
Optional FHIRPath filtering on read and search responses to reduce payload size and LLM context use.
Docker and Python package deployment options.
Compatibility with MCP clients such as VS Code, Claude Desktop and MCP Inspector.

The conceptual flow is:

sequenceDiagram
    participant L as LLM host
    participant M as WSO2 FHIR MCP
    participant O as OAuth or SMART
    participant F as Any FHIR server

    L->>M: tools/list
    M-->>L: capabilities and bounded tools
    L->>M: search Patient or Observation
    M->>O: obtain or use scoped token
    O-->>M: access token
    M->>F: FHIR search with scope
    F-->>M: Bundle
    M->>M: Apply FHIRPath field filter
    M-->>L: Reduced FHIR result

MCP capability comparison

Platform	Native or companion AI/MCP path	What it is good for	Important boundary
WSO2 FHIR Server	Separate WSO2 FHIR MCP Server adapter	Expose WSO2 or another FHIR API to MCP clients; discovery, search, read, bounded CRUD and operations	The adapter is not a clinical reasoning engine. Secure the upstream FHIR server and default to read-only.
HAPI FHIR	JPA server starter has an MCP configuration path; external adapters also work	MCP tools over HAPI operations and, in emerging work, CDS Hooks	Check the exact starter release. An MCP bridge must preserve search parameters and patient scopes. A reported starter issue shows why this must be tested for PHI isolation.
Aidbox	Native Aidbox MCP module and AI documentation	CRUD, search, conditional operations, validation and direct connections from MCP clients	Production endpoints require strict AccessPolicy and token controls. Native MCP exposes write capabilities, so approval gates are essential.
Firely Server	Plugin and API ecosystem, SMART and custom integrations	Standards-heavy applications and controlled .NET extensions	No equivalent native MCP capability was confirmed in the reviewed official sources. Use a separate adapter and verify licenses.
Medplum	Bots, TypeScript SDK, GraphQL and external MCP adapters	Build application-specific agents and workflows around FHIR data	Agent behavior is application code. Enforce AccessPolicy, audit and least privilege.
AWS HealthLake	AWS AI/NLP, Data Transformation Agent and AWS agent tooling	Convert unstructured data, analytics and model workflows around managed FHIR R4	AI services do not automatically give an LLM safe FHIR access. Use IAM, SMART and a controlled tool layer.
Azure / Google	Azure AI or Vertex AI integrations and cloud APIs	Managed data, analytics and AI pipelines	Cloud AI integration is broader than a native FHIR MCP surface. Build and govern the adapter.

Safe MCP reference design

For clinical or PHI-bearing environments, use this pattern. The same read-only-first and human-approval approach appears in AI agent operations and Kubernetes safety and agent context boundaries:

flowchart TD
    A[Approved AI application] --> B[MCP host]
    B --> C[MCP gateway]
    C --> D[Tool policy engine]
    D --> E[SMART/OAuth token exchange]
    E --> F[FHIR API gateway]
    F --> G[FHIR server]
    G --> H[(PHI store)]
    C --> I[Audit and redaction]
    D --> J[Human approval for writes]

Recommended policy:

Start with CapabilityStatement discovery.
Allow only named resource types and operations.
Use user/*.read, patient/*.read or narrowly scoped system scopes.
Keep create, update, patch, delete and transaction tools disabled by default.
Require a human confirmation step for every write.
Limit _count, pagination, _include, _revinclude and expensive chained searches.
Return only the FHIRPath fields needed for the task.
Do not send entire patient histories to the model when a smaller result is sufficient.
Treat narrative, DocumentReference text and attachments as untrusted data, not instructions.
Record the original user request, tool arguments, authorization context, upstream response status and final action.

AI is not an authorization boundary

A model can select the wrong patient, infer a broader search than intended, or follow malicious instructions embedded in clinical text. The MCP host and upstream FHIR authorization layer must enforce policy independently of the model’s reasoning.

Recommendation by use case

Use case	Best starting options	Reason
Small self-hosted R4 persistence layer	WSO2, HAPI, Medplum	Control and low infrastructure cost. WSO2 is the smallest focused option; HAPI is more mature.
Java enterprise integration platform	HAPI or Smile CDR	Strong Java ecosystem, extension points and support paths.
.NET and standards consultancy	Firely Server	Deep Firely expertise, .NET and plugin model.
Rapid healthcare application development	Aidbox or Medplum	FHIR plus identity, UI, SDK, events and application tooling.
Managed cloud with minimal operations	Azure, Google or AWS	Managed availability, IAM, storage and analytics integrations.
Large enterprise interoperability fabric	Smile CDR, HAPI, Firely or cloud service	Evaluate support, certifications, integration modules and operations.
FHIR-enabled AI assistant	Any server plus a controlled MCP adapter	MCP should be a policy-controlled adapter, not a replacement for FHIR security.

Practical decision for WSO2

WSO2 is compelling if all of the following are true:

The target interface is FHIR R4.
The team wants Apache 2.0 source ownership.
PostgreSQL is acceptable and well operated.
The server is placed behind an existing gateway and IAM platform.
Terminology can be supplied by a separate service.
Bulk export, subscriptions and advanced workflow features are not immediate blockers.
The team accepts a new project and will run its own conformance, scale and recovery tests.

HAPI is the safer default when feature breadth, multi-version support and ecosystem maturity are more important than binary size and operational minimalism.

Conclusions

FHIR server selection is an architecture decision. It affects data ownership, security, terminology, events, analytics, upgrades and AI access.
**WSO2's strongest idea is its storage model and operational simplicity.** It is not automatically the best choice for a complete healthcare platform.
HAPI is the benchmark for open-source breadth and extensibility. Its cost is JVM/JPA complexity and greater operator responsibility.
Firely, Aidbox and Smile CDR are platform choices. Their commercial modules can shorten delivery but must be evaluated by edition and license.
Cloud services solve operations, not all interoperability. Managed FHIR still requires profiles, terminology, IAM, consent, audit and data-quality work.
AI integration is a separate safety problem. MCP makes tool access easier; it does not make PHI access safe by itself.
The /metadata response and a reproducible workload matter more than marketing claims. Benchmark the exact release, configuration, profiles, terminology and dataset used in production.

HL7 FHIR overview explains the resource model, extensibility and interoperability goals. ↩ ↩²
HL7 FHIR HTTP API requires servers to publish a CapabilityStatement describing supported behavior. ↩
WSO2 FHIR Server repository documents the Go, PostgreSQL, R4, Apache 2.0 and cloud-native positioning. ↩
WSO2 storage model documents JSON resource storage, history and typed search indexes. ↩
WSO2 operations documentation lists the currently documented native operations. ↩
WSO2 architecture documentation places identity, policy and terminology integrations outside the core server. ↩
WSO2 deployment documentation documents timeout behavior, gateway responsibilities and deployment controls. ↩
MCP specification defines hosts, clients, servers, tools and user-consent safety principles. ↩ ↩²
WSO2 FHIR MCP Server documents FHIR discovery, search, read, bounded CRUD, SMART authentication, transports and FHIRPath response filtering. ↩

Nimendra's Notes 🪴

Explorer

FHIR Servers and WSO2 FHIR

FHIR Servers

1. What problem does a FHIR server solve?

The important distinction

2. Problem statement

Why use FHIR instead of a normal REST API?

FHIR is not automatically better for every API

3. What a FHIR server actually does

Core request path

Main internal responsibilities

4. Existing solution families

4.1 Open-source embeddable or self-hosted servers

4.2 Commercial self-hosted platforms

4.3 Managed cloud FHIR services

4.4 FHIR facade and gateway solutions

4.5 Application platforms built around FHIR

5. Main FHIR server options

WSO2 FHIR Server in depth

Current architecture

Documented capabilities

Important boundaries

Performance claims

WSO2 versus HAPI FHIR

Architectural comparison

Decision summary

AI integration and MCP servers

What MCP adds

WSO2 FHIR MCP Server

MCP capability comparison

Safe MCP reference design

Recommendation by use case

Practical decision for WSO2

Conclusions

Table of Contents

Graph View

Nimendra's Notes 🪴

Explorer

FHIR Servers and WSO2 FHIR

FHIR Servers

1. What problem does a FHIR server solve?

The important distinction

2. Problem statement

Why use FHIR instead of a normal REST API?

FHIR is not automatically better for every API

3. What a FHIR server actually does

Core request path

Main internal responsibilities

4. Existing solution families

4.1 Open-source embeddable or self-hosted servers

4.2 Commercial self-hosted platforms

4.3 Managed cloud FHIR services

4.4 FHIR facade and gateway solutions

4.5 Application platforms built around FHIR

5. Main FHIR server options

WSO2 FHIR Server in depth

Current architecture

Documented capabilities

Important boundaries

Performance claims

WSO2 versus HAPI FHIR

Architectural comparison

Decision summary

AI integration and MCP servers

What MCP adds

WSO2 FHIR MCP Server

MCP capability comparison

Safe MCP reference design

Recommendation by use case

Practical decision for WSO2

Conclusions

Footnotes

Table of Contents

Graph View