HAPI FHIR vs Smile CDR: when the open-source server is enough
If your team needs a FHIR server and has no contractual obligation to buy commercial support, the open-source HAPI FHIR project is a credible starting point. HAPI FHIR is licensed under the Apache Software License 2.0, and its JPA server covers FHIR DSTU2, DSTU3, R4, R4B and R5, with terminology services, validation, MDM and partitioning. Smile CDR is the commercial clinical data repository from the same company, and Smile states that it is built on the HAPI FHIR core engine. The two are not separate code bases with a feature gap you can read off a single page, so the decision turns on what you must run, who answers for it and what your auditors or buyers expect to see.
The free edition is usually sufficient when your team has Java and database operations skills, can accept responsibility for patching, upgrades and monitoring, and has an access-control design it can implement itself. HAPI FHIR does not ship a single security layer. It provides building blocks such as authentication interceptors, the AuthorizationInterceptor, consent and search narrowing interceptors, CORS support and BALP audit logging, so you must assemble and test them. Smile says its product includes a complete access-control mechanism built around SMART scopes. If you need that out of the box, or need a vendor to stand behind the access model in a contract, the commercial product becomes worth pricing. Ask Smile to show how the SMART scope model maps to your roles and consent rules before you assume it covers your case.
Support is the other lever. The HAPI FHIR README points to Smile for commercial support, so an open-source deployment does not come with a service-level commitment from the maintainers. Before you decide, confirm with Smile which support tiers, release cadence and upgrade assistance are included, and compare its paired quarterly releases with your own patch window. Also verify which HAPI FHIR version your chosen Smile release is built on, and check the JDK requirement, since HAPI FHIR 8.2.0 requires JDK 17. If your organization can absorb those obligations internally, staying on open-source HAPI is a reasonable choice. If it cannot, budget for the commercial license and support in writing before committing.
HAPI FHIR vs Smile CDR feature split
This table compares HAPI FHIR and Smile CDR row by row across FHIR versions, JPA server, terminology, validation, MDM, partitioning, security, audit logging and support. Where the supplied facts do not confirm a Smile CDR capability, the cell says what to confirm, so treat the open-source column as documented and the commercial column as a checklist for your vendor call.
| Capability | HAPI FHIR (open source) | Smile CDR (commercial) |
|---|---|---|
| FHIR versions | JPA server covers DSTU2, DSTU3, R4, R4B and R5 | Built on the HAPI FHIR core, so confirm the exact version set for your release |
| JPA server | Database-backed server using the JPA API, with PostgreSQL and Microsoft SQL Server for production | Built on the HAPI FHIR core engine; confirm supported databases with Smile Digital Health |
| Terminology, validation and MDM | Terminology services, validation and MDM are listed in the JPA server documentation | Confirm which of these are included in your licensed feature set |
| Partitioning | Resources placed in partitions for multitenancy, separate data sources or regional grouping | Confirm partitioning scope and licensing with Smile Digital Health |
| Security building blocks | Authentication interceptors, AuthorizationInterceptor, consent and search narrowing, CORS; no single built-in security layer | Includes a complete access-control mechanism built around SMART scopes, per Smile's FAQ |
| BALP audit logging | BALP audit logging is available as a building block you configure | Confirm whether BALP is included and how it is configured in the commercial product |
| SMART-scope access control | Assemble from the AuthorizationInterceptor and your identity provider | SMART-scope access control is documented by Smile; confirm the full paid feature list with Smile Digital Health before relying on it |
| Commercial support and releases | Community support; the README points to Smile CDR for commercial support; releases are maintained by the project | Commercial support from Smile; paired quarterly releases with HAPI FHIR, for example Smile CDR 2024.02.R01 with HAPI FHIR 7.0.0 |
What Smile CDR builds on the HAPI FHIR core
The most important fact for a team already running HAPI is that Smile CDR is built on the HAPI FHIR core engine. Smile Digital Health states this in its FAQ, describing the core as one of the reference implementations of the FHIR specification. HAPI FHIR itself is also a product of Smile Digital Health, and the HAPI README points to Smile CDR for commercial support. So the question is not whether these are unrelated products. The question is which layers Smile adds around a shared engine, and whether your team needs those layers enough to pay for them.
For a team already on HAPI, the practical work is to map the Smile additions onto your own gaps. Smile's FAQ describes a complete access-control mechanism built around SMART scopes, which is a different starting point from assembling authorization yourself from HAPI's building blocks such as the AuthorizationInterceptor. Check which of Smile's packaged controls, administration features and operational tooling you would otherwise build, and compare that list with the engineering time you would spend on them. Ask Smile for a written description of each added layer so you can see exactly what sits outside the open-source core.
Before you assume feature parity or drift, confirm which HAPI FHIR version a given Smile CDR release includes. Smile publishes paired quarterly releases, for example Smile CDR 2024.02.R01 alongside HAPI FHIR 7.0.0, but the pairing for your target release is the detail to verify in the release notes and with the vendor. Also confirm whether your existing HAPI customizations, interceptors and database configuration carry over unchanged. Treat that version check as the first gate in any migration or upgrade plan, because it decides how much of your current code and testing still applies.
How access control differs between open-source HAPI and Smile CDR
HAPI FHIR gives you components, not a finished access-control model. Its documentation describes authentication interceptors, the AuthorizationInterceptor, consent and search narrowing interceptors, CORS support and BALP audit logging. Your team chooses how these fit together, writes the rules that decide who can read or write which resources, and owns the result. This path suits organizations with strong Java and security engineering capacity that want full control over the policy model and are willing to keep it under review as the FHIR API grows.
- Identity provider integration: Your team connects HAPI to the identity provider, validates tokens, maps claims to roles or scopes, and handles key rotation and token lifetimes.
- Scope and policy design: You decide how SMART-style scopes, roles and patient or organization relationships translate into AuthorizationInterceptor rules, including compartment and search narrowing.
- Consent handling: If consent records drive access, you build the data model and the logic that the consent interceptor enforces.
- Audit and logging: You configure BALP audit logging, decide where audit events are stored, and set retention to match your policies.
- Testing and regression: Every rule change needs negative tests, such as a user reading a patient outside their relationship, plus periodic review after upgrades.
Before committing, ask your security team to write the access matrix for your top ten resource and operation combinations and check whether HAPI's building blocks can express it without custom code.
Smile Digital Health states that Smile CDR is built on the HAPI FHIR core engine and includes a complete access-control mechanism built around SMART scopes. For teams that want a single documented model for SMART-based access instead of assembling one, this is the main difference from the open-source project. The vendor-supplied mechanism still needs your identity design, your scope decisions and your testing, but the framework for enforcing scopes is already part of the product.
- Scope model in the product: SMART scopes are enforced by a built-in mechanism rather than by rules your developers write from scratch on each resource type.
- Identity provider integration: Your team still connects the identity provider and confirms that token claims map correctly to the scopes you intend to grant.
- Policy design: Your clinical and security owners still decide which applications, users and patient contexts receive which scopes, and document the reasons.
- Verification: Your testers still run negative cases for each application and scope, and check the product's behavior after each quarterly release.
- Support path: Commercial support is the route for questions about the mechanism. Ask Smile Digital Health what support, documentation and release notes cover access control, and what is included in your contract.
Before committing, ask for the access-control documentation and a walkthrough of how the SMART scope mechanism handles your highest-risk applications.
HAPI FHIR vs Smile CDR licensing and support terms
HAPI FHIR and Smile CDR share a core engine, but they carry different license terms, support channels and release obligations. The cards below separate what the open-source project gives you by default from what a commercial agreement must state in writing before you sign.
Open-source license terms
HAPI FHIR is licensed under the Apache Software License 2.0, which lets you use, modify and redistribute the library within your own platform under that license's terms. Your legal team should confirm how the license applies to the exact artifacts you deploy, including the JPA server starter and any custom interceptors you write. Smile CDR is not covered by that license and is governed by Smile's commercial terms, so the two cannot be assumed interchangeable on paper.
Commercial license scope for Smile CDR
Smile CDR is a commercial product, and its license scope is set by the contract rather than by an open-source license. Ask what the subscription covers: the number of environments, production versus non-production use, named deployments, and whether you may modify or extend the product. Confirm any restrictions on sharing the software with your own contractors or affiliates before your implementation partner starts work.
Community support for HAPI
HAPI FHIR support runs through its public GitHub project, where issues and releases are visible to everyone. Response time depends on maintainers and community contributors, and no contract guarantees a fix date. Teams that need a defined escalation path for production incidents usually need to add paid support from a commercial source, so decide early who owns triage when a bug affects patient data access.
Commercial support through Smile
HAPI FHIR's own project directs commercial support requests to Smile CDR, so Smile is the vendor-backed route for the same core engine. Ask in writing which severity levels, response targets, support hours and named contacts are included, and whether support covers the HAPI FHIR version embedded in Smile CDR or only the product as a whole. Support scope for customizations you build on top of the engine is often excluded, so confirm that explicitly.
Paired quarterly release model
Smile publishes paired quarterly releases of Smile CDR and HAPI FHIR, so a Smile CDR release arrives with a matching HAPI FHIR version. This gives a predictable upgrade rhythm if you subscribe, but it also sets the pace you must follow to stay supported. On open-source HAPI, you choose when to adopt each release, and you own the regression testing for every upgrade. Ask Smile how long each release line receives fixes and what the deprecation window is.
Update obligations on each side
With HAPI FHIR, you carry all upgrade work, including JDK requirements, database migrations and interceptor changes, unless you buy services. With Smile CDR, the contract may require you to adopt a release within a window to keep receiving support. Ask for the minimum supported release, the end-of-life notice period, and whether security patches are backported to older release lines. Get these answers in writing before signing.
How paired quarterly releases affect upgrades and planning
Smile Digital Health publishes paired quarterly releases of Smile CDR and HAPI FHIR, so each Smile CDR release ships alongside a matching HAPI FHIR version. The documented example is Smile CDR 2024.02.R01 released with HAPI FHIR 7.0.0. For a team staying on open-source HAPI, this means the upstream project is the release train to track. HAPI publishes its own versions on GitHub, and the current line moves independently of any Smile schedule. Before adopting a new HAPI version, check the HAPI FHIR versions page for the Java requirement. HAPI FHIR 8.2.0, for example, requires JDK 17, so a JDK upgrade may need to land before the library upgrade. Also review the database support in the JPA server starter, since the H2 default is for evaluation and production deployments use PostgreSQL or Microsoft SQL Server.
For a team on Smile CDR, the planning unit is the quarterly release. Each quarter, the HAPI core under Smile CDR changes, so the team should map its upgrade windows against that cadence rather than improvising patches. Plan for regression testing of custom interceptors, the AuthorizationInterceptor configuration and any SMART scope rules, because these sit on top of the HAPI core and can be affected by core changes. Teams that skip releases will need a larger jump later, which raises test effort. Teams that upgrade every release spend steady effort on smaller changes. Either way, ask Smile for the support window for each release line, including how long a given version receives fixes and what the end-of-support path looks like. Confirm those windows in writing before you commit to a release schedule, because the public material supplied for this page does not state them.
What HAPI FHIR vs Smile CDR costs to own
This table lays out who gets paid for each cost component when running HAPI FHIR or Smile CDR, and which items are one-time versus recurring. Smile CDR pricing is not in the supplied facts, so the last rows list what to request in a written quote before comparing totals.
| Cost component | HAPI FHIR (open source) | Smile CDR (commercial) |
|---|---|---|
| Software license | Apache Software License 2.0, so no license fee for the library or JPA server starter | Commercial terms from Smile Digital Health; confirm the license model, term and what it covers in writing |
| Commercial support subscription | None from the project; support comes from your own staff, a consultant or a partner you contract | Commercial support is offered by Smile; confirm hours, response commitments and recurrence in the quote |
| Database and infrastructure hosting | Recurring: your own PostgreSQL or Microsoft SQL Server, compute, storage and backups, since production use excludes the embedded H2 default | Recurring: similar database and compute footprint, plus any hosting or environment tiers named in the quote |
| Build and integration effort | One-time: assembling the server, configuring resource providers, terminology and partitioning to fit your use case | One-time: deployment, configuration and integration on the commercial distribution; confirm which services are included |
| Ongoing engineering and operations | Recurring: your team owns patching, monitoring, on-call and tuning for the lifetime of the server | Recurring: smaller share of platform maintenance may fall to Smile depending on support scope; confirm the split |
| Security and audit work | Recurring: you build and evidence access control from building blocks such as the AuthorizationInterceptor, consent interceptors and BALP audit logging | Recurring: Smile states its access control is built around SMART scopes; you still own the evidence your assessors need |
| Upgrade effort | Recurring: you test each release, and HAPI FHIR 8.2.0 requires JDK 17, so JDK and dependency upgrades fall to you | Recurring: paired quarterly Smile CDR and HAPI FHIR releases; confirm how many supported releases and what upgrade assistance is included |
| What to request in a Smile CDR quote | Not applicable | Written scope, support hours, supported releases, upgrade assistance, license term, renewal and price escalation rules, and the exact deliverables for implementation |
Moving from open-source HAPI to Smile CDR, or back
This sequence gives a team a documented, reversible path between HAPI FHIR and Smile CDR, so the move is decided on evidence from a non-production copy rather than on assumptions about compatibility. Each step ends with an artifact that the next step depends on.
Inventory the current HAPI version, JDK and database
The platform or engineering lead records the exact HAPI FHIR version in use, the JDK it runs on, the database engine and version, the FHIR versions being served (DSTU2, DSTU3, R4, R4B or R5), and how the server is deployed, whether as the hapiproject/hapi Docker image, a WAR on a servlet container, Spring Boot or Kubernetes. HAPI FHIR 8.2.0 requires JDK 17, so the inventory must confirm the runtime against the target version. Note that the JPA starter supports PostgreSQL and Microsoft SQL Server for production but not MySQL. The inventory is done when every item has a recorded value and an owner. Confirm with Smile which HAPI core version and JDK each Smile CDR release expects, since that mapping is not in the supplied facts.
Map custom interceptors and resource providers
The integration architect lists every custom AuthorizationInterceptor, consent or search narrowing interceptor, CORS rule, BALP audit configuration, and resource provider in the current build. Each one is then mapped to the access-control model Smile CDR provides, which is built around SMART scopes. HAPI FHIR itself offers building blocks rather than a single security layer, so some custom logic may translate directly, some may be replaced by product configuration, and some may need to be retired after a security review. The output is a mapping table with one row per component and a decision of keep, replace or retire. Confirm with Smile how custom interceptors and providers are supported in its product before assuming any can be carried over.
Test data and partitioning in a non-production copy
The data engineer restores a copy of the production database into a non-production environment and loads it into the target product in parallel. The team checks resource counts by type, search results for a sample of critical queries, and terminology and validation outcomes. If the current deployment uses JPA partitioning for multitenancy, data separation or regional grouping, the partition layout must be reproduced and verified, because each resource sits in a partition. Done means the reconciliation report shows matching counts and query results, and every discrepancy has a recorded cause. Ask Smile for its documented migration tooling and whether it guarantees compatibility with the data layout, because neither is covered by the supplied facts.
Validate access control and audit with test identities
The security engineer runs a scripted set of test identities and client applications against the non-production target, covering each SMART scope the clients request, consent-based restrictions, and denial cases. Audit logging is checked against the BALP configuration the current server uses. The result is a signed test report that shows expected and actual outcomes for each case. Any gap blocks the cutover until the mapping in the previous step is corrected. Confirm with the vendor how audit output is formatted and retained, since those details must align with the organization's own records requirements.
Plan the cutover and freeze the write window
The platform lead writes a cutover runbook that names the owner for each action, the order of DNS, client configuration and data synchronization changes, the point at which writes stop on the source, and the checks that confirm the target is serving correctly. Client applications are listed with their configuration changes, such as base URLs and token endpoints. The runbook is approved by the application owners and the change board before the window is scheduled. It is complete when every client has a tested configuration and a named contact for the window. Confirm the vendor's recommended sequence and any supported live-sync approach before fixing the window length.
Execute the cutover with a final reconciliation
The operations team stops writes on the source, runs the final data load, repeats the reconciliation checks from the test environment, and then switches client traffic to the target. Monitoring watches error rates, authentication failures and query latency during the first business cycle. The cutover is done when reconciliation passes, clients authenticate against the target, and the source is set to read-only and kept intact for the rollback window.
Define and rehearse the rollback path
Before the cutover, the operations lead writes the rollback procedure: the conditions that trigger it, who approves it, how client configuration is reverted, and how writes made on the target after cutover are either replayed to the source or accepted as lost. The rollback is rehearsed in the non-production environment, and the timing and steps are recorded. Keep the source database and its HAPI deployment running and unchanged until the business agrees the rollback window has closed. Moving back to open-source HAPI follows the same sequence in reverse, so the inventory and mapping steps apply in both directions.
Questions teams ask before choosing HAPI FHIR or Smile CDR
What does Smile CDR cost, and how do I get a quote?
Smile CDR is commercial, and the supplied facts do not include a price, so confirm pricing directly with Smile Digital Health. Smile publishes no figure in the material we reviewed, and the HAPI FHIR project points to Smile for commercial support. Ask for the license basis (deployment size, environments, modules), what support tier is included, whether upgrades and quarterly releases are covered, and whether the quote is one-time, annual or per environment. Compare that against your own build and run costs, which are the staff time, cloud hosting and testing you carry with HAPI FHIR.
How much effort does HAPI FHIR need to reach production?
HAPI FHIR is free to use under the Apache Software License 2.0, so the effort sits in engineering rather than licensing. The main work is choosing a database (the JPA starter defaults to an embedded H2 database and supports PostgreSQL and Microsoft SQL Server for production), setting up authentication and authorization with the AuthorizationInterceptor, configuring audit logging, validation and terminology, and building your own deployment, monitoring and backup. The project states it does not provide a single one-size-fits-all security layer, so expect to design and test that layer yourself. Scope these items in a written plan before you estimate hours.
Can our team run HAPI FHIR without a commercial vendor?
Yes, if your engineers can operate a Java service and a supported production database. The JPA server starter can run as the hapiproject/hapi Docker image, with Docker Compose, under Spring Boot, as a WAR on Tomcat, Jetty or Wildfly, or on Kubernetes with a Helm chart. The starter needs JDK 17 for HAPI FHIR 8.2.0, so confirm your runtime versions before you pick a release. Your team owns patching, upgrades, incident response and security review. If those responsibilities are not staffed, a commercial support contract or an outside retainer is the usual way to cover them.
How long does a migration to HAPI FHIR take, and what drives that time?
No migration duration is supplied for this comparison, so treat any figure you hear as unverified until it is written into a scope. The main drivers are the number and complexity of source systems, the FHIR versions you must support (DSTU2 through R5 are available), how much terminology and validation work is needed, how data is mapped and loaded, and how much consent and access logic must be rebuilt. Ask any implementation partner for a fixed-scope plan with deliverables and milestones, since most DeployOpen engagements are agreed in writing before work starts.
What does the work need from our staff?
Plan for named owners across architecture, security, data and operations. Your security team needs to define the access-control model, including SMART scopes if you need them, and approve the audit approach. Your data team must agree on partitioning if you plan to separate tenants, regions or data sources. Your platform team owns the database, backups, certificates and environments. Your clinical or business stakeholders should sign off on the resource types and workflows in scope. Ask for a role-by-role responsibility list in the written scope so the gaps are visible before work starts.
Can we switch from HAPI FHIR to Smile CDR later, or the other way around?
Smile CDR is built on the HAPI FHIR core engine, so the FHIR API surface and much of the data model are closely related, which can make a move between the two simpler than a move to an unrelated server. That is a starting point, not a guarantee. Confirm with Smile which configuration, access-control and storage settings carry over, and test with a copy of your real data. Check the database you chose, your custom interceptors and any Java extensions, because those are where moves usually stall. Keeping your authorization logic and data mappings documented makes any future switch cheaper.
How DeployOpen scopes and supports either option
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For HAPI FHIR vs Smile CDR, that means we start from your deployment constraints and FHIR requirements, then agree a written scope before any work begins.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope names the FHIR versions, resource types, identity model and data store you need, whether HAPI FHIR or Smile CDR.
- Quotes follow from the written scope, so ask for line items covering licensing, build, testing and handover.
How we build
- We deploy the chosen server into your environment, using the packaging your platform team already operates.
- SMART scopes, the AuthorizationInterceptor, consent and search narrowing are configured against your access rules, not assumed.
- Database, partitioning and audit logging choices are documented and tested before the server carries clinical data.
How we hand over
- Handover covers configuration, runbooks, upgrade steps and the evidence your compliance team needs for assessments.
- Security testing of the API and infrastructure can be scoped alongside the build and reported in writing.
- Your staff receive the documentation to run the server, with the open questions about commercial support called out.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades to new quarterly or patch releases are planned and tested in staging before production changes.
- Confirm response expectations, release-tracking duties and who owns vendor escalation in the retainer terms.
