HAPI FHIR cost of ownership services

What does HAPI FHIR cost of ownership actually include?

HAPI FHIR is licensed under the Apache Software License 2.0, so there is no license fee to pay. The ongoing cost of running it comes from hosting, the database, Java runtime upkeep, security controls and day-to-day operations. A cost-of-ownership review usually starts in one of three situations. The first is a build-versus-buy decision, where an internal team weighs a self-hosted FHIR server against a commercial product. The second is a new health data program that needs a FHIR API before its operating model is settled. The third is a move away from a commercial FHIR product, where the saved license fee is the first thing leadership notices. Each trigger asks a different question. Build-versus-buy needs a full run cost, the new program needs a named owner after go-live, and the migration needs a list of what the commercial product did that the replacement must now do itself.

The database and Java layers are the two components teams most often underestimate. The JPA server starter defaults to an embedded H2 database, which is suitable for trying the server but not for production. Production deployments use PostgreSQL or Microsoft SQL Server, and the starter does not support MySQL. Someone must license, patch, back up, tune and restore that database service, and those tasks recur for the life of the system. On the Java side, the server runs on a JDK that must match the HAPI FHIR release. For HAPI FHIR 8.2.0 the requirement is JDK 17. Confirm the requirement for the exact version you select, because the runtime changes between releases and each change becomes engineering work.

Security is the largest recurring item that teams leave out of early estimates. HAPI FHIR states that it does not provide a single one-size-fits-all security layer. It provides building blocks instead, including authentication interceptors, the AuthorizationInterceptor, consent and search narrowing interceptors, CORS support and BALP audit logging. Someone must design the access rules, test them after every change, keep TLS certificates current, review audit output and produce evidence for assessors. Operations add monitoring, backups, on-call coverage, incident response, capacity planning and environments for testing upgrades before production. Ask every estimate to show these items as separate lines with a stated owner, so the recurring work is visible before the system goes live.

On sourcing, the HAPI FHIR README points to Smile CDR for commercial support. The public demonstration server at hapi.fhir.org is useful for checking API behavior and client code during evaluation, but it is shared and is not a production model, so it should not be used to size infrastructure or staffing. Most teams split the work. They keep knowledge of their data model, interceptors and runbooks in-house, and they buy build, hardening or support from a partner or vendor where internal capacity is thin. When you request a quote, ask it to separate one-time work from recurring retainers, name who is paid for each item, and state which Java and database versions it assumes.

What a HAPI FHIR cost of ownership review covers

A fixed-scope cost of ownership review ends with four connected deliverables: a cost model, a list of internal skills, a support decision record and a runbook outline. DeployOpen produces the model from the written scope and does not publish prices, so every figure in it comes from your own rates and your cloud or data center costs.

Infrastructure cost model

The cost model lists each recurring infrastructure category on its own line: compute for the HAPI FHIR server, storage, load balancing, network traffic, backups and the non-production environments your release process needs. Each line states its unit basis and the rate you supply from your cloud account or data center. Check whether test and training environments are costed, because they often recur as much as production. Ask which line changes most if load grows.

Database platform and licensing

The model treats the database as a separate cost. The JPA server starter defaults to an embedded H2 database, which is not a production choice. For production, the starter supports PostgreSQL and Microsoft SQL Server, and it does not support MySQL. Cost depends on whether you run the database yourself or use a managed service, on any SQL Server licensing you choose, and on storage growth, backup retention and the database administration time needed for tuning and restores.

Java engineering and runtime

Running the server means owning a Java runtime and build chain. HAPI FHIR 8.2.0 requires JDK 17. The current release, v8.8.2, was published on 25 September 2026, and its own requirements should be checked before sizing. Recurring work includes rebuilding custom interceptors, updating dependencies, patching the JDK and keeping continuous integration pipelines working. Price this as engineer time at your own rates, and name the skills (Java, Spring Boot or servlet container, FHIR profiling) that cover it.

Security controls and their upkeep

HAPI FHIR does not provide a single security layer. It offers building blocks: authentication interceptors, the AuthorizationInterceptor, consent and search narrowing interceptors, CORS support and BALP audit logging. Each control you adopt adds recurring work: writing and reviewing access rules, retaining audit logs, rotating credentials and repeating security testing after each upgrade. Ask that the rule set and the audit retention assumption be written into the model so the reviewer can test them.

Operations, backups and upgrades

Day-to-day operation covers monitoring, on-call response, backup and restore testing, certificate renewal and log management. Upgrades add recurring cost because a release can change the database schema and affect custom interceptors, so regression testing has to be repeated each time. The runbook outline should name who performs restores, how often restores are rehearsed, and which upgrade events are budgeted in the model.

Support model decision record

The decision record compares running HAPI FHIR with your own staff against buying commercial support. The project's README points to Smile CDR for commercial support. Record the incident response times you need, the skills you can hire or keep, and the cost of key-person absence. The Apache Software License 2.0 governs use of the software, so confirm with your legal team which obligations apply. Request written support terms from any vendor before comparing totals.

Which factors push HAPI FHIR running costs up or down

This table lists the choices that most change the effort and running cost of a self-hosted HAPI FHIR server, with the reason each one matters and one practical way to keep it contained. Read each row as a question to answer before requesting a quote, since most rows multiply work across environments and upgrades. The main takeaway is that scope decisions made early, especially FHIR versions, database and deployment target, usually matter more to ongoing cost than the server software itself.

Driver	Why it changes effort	How to keep it down
FHIR versions and resource types in use	The JPA server covers DSTU2, DSTU3, R4, R4B and R5, so each version you enable adds profiles, validation rules and test cases to maintain.	Start with one FHIR version your partners actually exchange, and add others only when a named integration requires them.
Data volume and partitioning need	Larger datasets raise database sizing, backup windows and reindexing time. Partitioning adds configuration and access rules for each partition.	Confirm expected record counts and growth early, and use partitions only where tenancy, regional separation or source separation is a real requirement.
Terminology, validation and MDM features	Terminology services, validation and MDM each need their own configuration, reference data loading and regression testing after upgrades.	Enable only the modules your use cases need, and document which ones are switched on so upgrades test the right behavior.
Number of environments	Each environment (development, test, staging, production) needs its own database, configuration, secrets and deployment pipeline, and changes must be promoted through them.	Standardize one deployment definition and vary only configuration values between environments, so a change is built once and promoted.
Integrations and custom interceptors	Every custom interceptor or external integration is code your team owns, and it must be retested whenever HAPI FHIR or Java changes.	Keep custom code small, document each interceptor's purpose and maintain a regression suite that runs against every upgrade candidate.
Compliance evidence requirements	Assessors expect logs, access records, change history and documented configuration. Producing and retaining this evidence is recurring work, and the assessment itself is performed by an independent auditor.	Agree the evidence list before build starts, and generate it from the deployment pipeline and audit logging rather than assembling it by hand.
Database choice	The default embedded H2 database is not a production choice. PostgreSQL or Microsoft SQL Server require provisioning, backup, patching and performance tuning. MySQL is not supported.	Choose PostgreSQL or Microsoft SQL Server based on the skills and managed services your organization already runs, and confirm supported versions with the project before committing.
Deployment target	Docker, Spring Boot, a WAR on Tomcat, Jetty or Wildfly, and Kubernetes with Helm each bring different patching, scaling and monitoring responsibilities.	Pick the target your platform team already operates. Illustrative example: a team that runs Kubernetes for other services can reuse its existing cluster tooling instead of adding a second application server to support.

How a HAPI FHIR cost model is built, step by step

The sequence turns a HAPI FHIR deployment, or a planned one, into a cost model that finance and engineering can review line by line. Each step produces a named artifact that feeds the next, so every assumption stays traceable to its source.

Inventory the deployment and features in use
Start with a written inventory of what runs or will run: the HAPI FHIR version, the starter or custom build, the FHIR versions in use (DSTU2, DSTU3, R4, R4B or R5), and the features enabled, such as terminology services, validation, MDM and partitioning. Add any custom interceptors and the number of environments. DeployOpen gathers this with your platform and application owners. The step closes when both sides sign off one inventory that every later step uses.
Map recurring work to roles
List each recurring operational task, including patching, upgrade testing, backup and restore checks, certificate renewal, monitoring, on-call response and access reviews. Assign each task to an internal role, an external provider or a retainer, and note its expected frequency. Mark which tasks are one-time and which recur. The output is a responsibility matrix showing who is paid for what, so the model counts labor your organization will fund and leaves out assumed headcount.
Set the infrastructure and database baseline
Record the hosting model (Docker, Kubernetes with the Helm chart, Spring Boot, or a WAR on Tomcat, Jetty or Wildfly), the compute and storage each environment needs, and the database. The starter defaults to an embedded H2 database, so production planning must name PostgreSQL or Microsoft SQL Server, since the starter does not support MySQL. Include the backup, replication and recovery objectives you must meet. The output is a baseline sheet listing each cost line, its owner, and the figure to be confirmed in your environment.
Estimate the security and compliance workload
Map the security work that HAPI FHIR leaves to the implementer. The project offers building blocks, including authentication interceptors, the AuthorizationInterceptor, consent and search narrowing interceptors, CORS support and BALP audit logging, but it does not provide a single security layer. Estimate the design, configuration, testing and ongoing review for each block, plus the evidence your compliance assessors will ask for. DeployOpen prepares systems and evidence for assessments, while independent auditors issue any report. The output is a security workload list with owners.
Build the Java runtime and upgrade calendar
Build a calendar of Java runtime requirements and HAPI FHIR releases you expect to adopt. Each release has its own JDK requirement: HAPI FHIR 8.2.0, for example, requires JDK 17. The newer v8.8.2 release, published on 25 September 2026, changes the baseline you must plan around, so confirm its JDK requirement in the release notes before scheduling work. Add database schema changes, JDK patching, regression tests for custom interceptors and partitions, and a rollback path. The output is a calendar showing the release and runtime each environment targets.
Compare support options side by side
Compare the ways to staff the platform after go-live. Options typically include an internal team that carries all upgrades and incidents, a DeployOpen retainer for ongoing support, upgrades and testing, and commercial support from Smile CDR, which the HAPI FHIR README points to. For each option, list what is covered, who responds, how issues escalate, and what is priced separately. Ask every provider for its response terms in writing. The output is a side-by-side table tied to the responsibility matrix from step two.
Assemble the model and confirm assumptions
Combine the baseline, security workload, upgrade calendar and support choice into one model. Separate one-time costs, such as implementation and migration, from recurring costs, such as hosting, database licensing where it applies, labor, testing and support. Show which inputs move the total most, so reviewers can see the cost drivers. Finish with a register of assumptions the client must confirm, each with an owner and a date to confirm by. The output is a model and assumptions register that feeds the written scope and quote.

Which parts of the running cost teams keep in-house and which they outsource

Teams usually keep the recurring work that depends on their own data and their own clinical or business rules. Day-to-day operations of a HAPI FHIR server, including watching the Java process, the database connection pool, backups, storage growth and search performance, needs people who can run Java and Spring applications in the team's own environment. Data stewardship stays in-house as well: someone has to decide which resources are authoritative, how identifiers are reconciled and who approves changes to stored data. Clinical or business rule ownership is the hardest part to outsource, because the team must decide which FHIR profiles apply, which terminology bindings are enforced and which validation failures block a write. Incident response also belongs with the team that carries the clinical or business accountability, with a named on-call rotation and an escalation path to the database administrators and identity team. The work that teams often buy is specialized and episodic. Initial database and TLS hardening is one example. The default embedded H2 database is not a production choice, and the move to PostgreSQL or Microsoft SQL Server, with correct credentials, encrypted connections and locked-down administrative endpoints, usually calls for PostgreSQL or SQL Server administration skill that a platform team may not hold day to day. Security control design is another. Ask your team who will design the rules in the AuthorizationInterceptor and who will configure BALP audit logging, and whether those people will still be available after go-live. HAPI FHIR does not ship a single security layer. It provides building blocks: authentication interceptors, the AuthorizationInterceptor, consent and search narrowing interceptors, CORS support and BALP audit logging. Each one must be wired to your identity provider, configured for your roles and tested against your data. That makes security labor a recurring line item rather than a one-time install. Every upgrade can change interceptor behavior, every new resource type or profile can open a new access path, and every audit finding can require a configuration change. Periodic upgrade and regression testing of custom interceptors is therefore a recurring cost that is often bought in bursts. Each HAPI FHIR release can bring Java requirements and database schema changes, and custom interceptors must be retested against them. Independent security testing is also commonly outsourced, because the team that built the controls is poorly placed to judge whether they hold. Before you decide, list each item, name the skill it needs (Java and Spring operations, PostgreSQL or SQL Server administration, FHIR profiling, identity integration, security testing or compliance evidence), and confirm who in your organization holds that skill today. When you request quotes, ask each provider to separate one-time build work from recurring operations, interceptor maintenance, upgrade testing and testing cycles. Ask who is accountable for compliance evidence, such as access review records and audit log retention, and which of those items the quote covers. Confirm these points with your own security, data and platform owners before you agree on a split.

Recurring costs after go-live and who pays for each

This table lists the recurring cost lines for running a HAPI FHIR server after go-live, who usually pays for each, and what to request in a quote. Use it to build a yearly cost model that separates your own staff time from vendor fees and infrastructure charges. Costs that recur are often larger than the initial build, so confirm each line with its owner before you compare options.

Cost line	One-time or recurring	Who pays and what to ask for
Hosting for application and database tiers	Recurring	Client team pays the cloud provider or data center operator. Ask for compute, storage, networking, backup storage and data transfer line items for each environment, including non-production.
Database licensing and operations	Recurring	PostgreSQL is open source, so the cost is hosting and operations. Microsoft SQL Server carries its own licensing terms, so confirm edition, core count and support terms with the vendor or reseller before choosing it.
Java runtime and container image maintenance	Recurring	Client team pays for staff time. HAPI FHIR 8.2.0 requires JDK 17, so confirm JDK version support and the rebuild cycle for the hapiproject/hapi image or your own WAR or container build.
Security patching and testing	Recurring	Client team pays for staff time and scanning tools. If a retainer is used, DeployOpen pays its own testers and the client pays the retainer fee. Ask what is covered per patch cycle and what triggers out-of-cycle work.
Upgrades across HAPI FHIR releases	Recurring, with spikes	Client team or a services partner pays. Ask for regression testing of custom interceptors, database schema migration steps and the expected effort per release, including what is excluded.
Monitoring, logging and backup	Recurring	Client team pays for monitoring tools, log storage and backup retention. Ask the vendor or partner for alert coverage, restore test frequency and the retention periods they will support.
Internal staff time	Recurring	Client team pays through salaries and on-call rotation. Estimate the share of FHIR platform engineers, database administrators and security staff that the server will consume, and record it as a line item.
Commercial support subscription through Smile CDR	Recurring	Client pays Smile CDR directly under a subscription. Ask for the support scope, response commitments, supported versions and whether the subscription covers custom code or only the base product.
Ongoing retainer for operations, testing or upgrades	Recurring, optional	Client pays DeployOpen under a written retainer if chosen. Ask for the covered services, the named responsibilities, how change requests are priced and how hours or deliverables are reported each period.

What usually inflates HAPI FHIR running costs after launch

Most HAPI FHIR cost overruns trace back to choices made during the first build, when the server seemed to work. The cards below cover the decisions that quietly add database, security, Java and operations effort once the server holds real clinical data and has real users.

Embedded H2 database left in production

The JPA server starter defaults to an embedded H2 database. Teams that keep it after go-live later pay for an unplanned migration to PostgreSQL or Microsoft SQL Server, including data movement, re-testing and downtime planning. Before launch, confirm which of the two supported production databases your organization runs and build the server against it from the first environment.

Security treated as a finished layer

HAPI FHIR provides building blocks such as authentication interceptors, the AuthorizationInterceptor, consent and search narrowing interceptors, CORS support and BALP audit logging. It does not provide a complete security layer. Teams that assume the product covers security underbudget identity integration, access rules, audit design and the testing that proves them. Scope these as separate work items with named owners during design.

Unplanned Java version changes

HAPI FHIR releases set their own JDK requirements. For example, HAPI FHIR 8.2.0 requires JDK 17. When the platform team standardizes on a different Java version, or a later release raises the minimum, the server, custom code and container images all need work at once. Record the required JDK for each candidate release in the design and agree who approves Java baseline changes.

Custom interceptors that break on upgrade

Custom interceptors, validators and operation providers written against HAPI FHIR internals often fail after a version change, and the failure may only appear in specific request paths. Each upgrade then costs investigation time that was never estimated. Keep custom code behind the public extension points, document each interceptor's purpose, and include them in a regression suite that runs before every upgrade.

Partitioning added late

HAPI FHIR JPA partitioning places each resource in a partition, which supports multitenancy, separation of data sources or grouping by region. Adding it after data exists means re-assigning resources, changing search behavior and retesting access rules across the whole dataset. Decide during design whether partitioning is needed, even if the first release uses a single partition.

Testing UI and operations exposed

A testing UI and administrative operations that remain reachable from the wider network create security findings, remediation work and extra review cycles that recur with each release. Restrict them to administrative networks or disable them in production, and confirm how your deployment template handles this setting. Treat the restriction as a configuration item tested in every environment.

How the running cost changes by starting point and environment

A new build on the JPA server starter keeps recurring work narrow because the server is packaged and deployed in a defined way. Most of the running cost sits in the platform itself: the database, the Java runtime and keeping pace with new releases. Your team owns configuration and the operational wiring, while the upstream project owns the server code.

Image ownership: Your team tracks the hapiproject/hapi image or the starter build and rebuilds when configuration or the base image changes.
Upgrade testing: Regression focuses on configuration, the database schema migration and your client traffic, since little custom code exists to re-test.
Database: The embedded H2 default is for evaluation. Production use means PostgreSQL or Microsoft SQL Server, and the hosting, licensing and backup of that database becomes a recurring line item.
Logs and backups: Logs flow to your platform's collector, but backups belong to the database team, so their schedule governs recovery.
Support model: Public community channels handle most questions. Commercial support through Smile CDR is a separate contract to price.

Confirm which database engine and Java runtime the target release requires, and ask the vendor which release lines remain in active support before you commit to a version.

What the client team needs to provide before a cost model can be built

A cost model for a self-hosted HAPI FHIR server is only as accurate as the inputs behind it. Before any partner or internal team can convert effort into dollars, the client team needs to supply a short set of facts about what the server must do, who will run it and what the organization will pay for labor and cloud capacity. Start with a current inventory of FHIR versions, resource types and features in use or planned. HAPI FHIR's JPA server covers DSTU2, DSTU3, R4, R4B and R5, along with terminology services, validation, MDM and partitioning. Each of these areas adds configuration, testing and maintenance, so a list that says only "FHIR R4" leaves out most of the work that drives cost. Ask which profiles, custom search parameters and operations are needed on day one and which are planned for later phases. Next, provide expected user counts, integration counts and data volume with a growth assumption. Count the systems that will read from or write to the server, the number of concurrent clients at peak and the number of resources expected in the first year and in year three. Growth assumptions determine database sizing, backup windows, storage costs and the point at which partitioning or a larger database tier becomes necessary. Also state the target hosting model and database choice. The JPA starter defaults to an embedded H2 database and supports PostgreSQL and Microsoft SQL Server for production, but MySQL is not supported. Your database standard, your cloud platform and whether you already run managed database services will all change the operating cost line. Confirm the number of environments as well, since development, test, staging and production each carry their own infrastructure and testing effort. The most important input is named ownership. Identify one accountable owner each for operations, security, identity and clinical or business rules. The security owner decides how authentication, the AuthorizationInterceptor rules, consent and search narrowing, and audit logging with BALP will be designed, because HAPI FHIR provides these as building blocks rather than a complete security layer. The clinical or business owner decides which rules the server must enforce. Missing owners are the most common reason a cost model is revised after go-live, because decisions that nobody was assigned to make stall, and the work they hold up then lands in production support. Finally, supply the rates needed to turn effort into cost: internal labor rates for Java engineers, platform operators, security staff and clinical informaticists, plus your cloud pricing or negotiated discounts. Also list any compliance frameworks the system must evidence, such as a framework your auditors already apply to clinical systems. DeployOpen prepares controls and evidence, but independent auditors issue any attestation, so the framework names matter for scoping. Ask your auditors and security team to confirm which frameworks apply before the model is built. Unclear data growth and unnamed owners together account for most post-launch revisions, so resolve those two items first.

Questions buyers ask about HAPI FHIR running costs

Does HAPI FHIR have a license fee?

No license fee applies to the open-source project itself, because HAPI FHIR is licensed under the Apache Software License 2.0. Your costs come from the work around the software: the infrastructure it runs on, the database behind it, the engineering time to deploy and customize it, and the security and operations work that a health data system requires. Those costs are what a cost model should itemize. Confirm with your legal team how the Apache 2.0 terms apply to any modifications or internal packaging you plan to make, since the license terms are the authority on that point.

Do we need commercial support for HAPI FHIR?

Commercial support is not required to run HAPI FHIR, but it changes who answers when something breaks. The project's README points to Smile CDR for commercial support, so that is one documented route to a vendor-backed contract. Without it, your team relies on its own engineers, the public project resources and any partner you engage for implementation or ongoing support. The decision depends on your uptime expectations, your in-house Java and FHIR depth, and how much incident response you need to own yourself. Ask any support provider to state in writing what is covered and how incidents are escalated.

Which database should we budget for, and why not H2?

Budget for PostgreSQL or Microsoft SQL Server, because the JPA server starter supports those two for production. The starter defaults to an embedded H2 database, which is convenient for evaluation but is not a production choice for clinical data. MySQL is not supported by the starter. The database drives cost through licensing (for SQL Server), hosting, backup and recovery design, storage growth, and the DBA time needed for tuning and patching. Your existing skills and standard database platform usually decide between the two supported options. Confirm the supported versions with the release you select.

Which Java version does the team need to plan for?

Plan for JDK 17 or later, because HAPI FHIR 8.2.0 requires JDK 17. Java version drives cost in two ways: your platform team must maintain a supported runtime in every environment, and each HAPI FHIR upgrade may raise the minimum JDK. Check the versions page for the release you intend to deploy before you size images, build pipelines and application server choices. Custom interceptors and build tooling also need to be compiled and tested against the same Java version, so the runtime decision affects engineering time as well as hosting.

How long does a HAPI FHIR cost model take to build?

The duration of a cost model follows the written scope, so it cannot be stated in advance without knowing what you want modeled. A model that covers a single environment with the default starter differs from one that includes multiple environments, custom interceptors, security integration and a support contract. Ask for the scope, deliverables and timeline in writing before work starts, and check that the timeline names each deliverable. DeployOpen agrees scope, deliverables and timelines in writing before work starts, and any duration in your quote should trace back to that agreed plan.

Can our team run HAPI FHIR without outside help?

Yes, many teams run it internally, provided they have the skills to cover the full lifecycle. The work includes Java application operations, PostgreSQL or SQL Server administration, TLS and identity configuration, audit logging, backup and restore testing, and upgrade regression testing. HAPI FHIR does not provide a single security layer, so authentication, authorization and consent controls must be designed and built by your team or a partner. Assess honestly whether you have FHIR knowledge, security engineering capacity and on-call coverage. Gaps in those areas are where internal programs usually need outside help.

What does the work require from our team?

Your team supplies access and decisions, and the engagement needs their time throughout. Expect to provide cloud or data center accounts, network and DNS approvals, identity provider details, a named business owner for FHIR profiles and data scope, and staff for review and testing. Security and compliance staff must approve the control design and evidence. Effort rises when requirements are unclear, approvals are slow or environments are not yet available. Ask any provider to list your responsibilities in the quote so you can staff them before the work begins.

How do upgrades change the running cost?

Upgrades recur, so they belong in the annual cost model rather than the launch budget. Each release can change the minimum Java version, the database schema, and the behavior of custom interceptors, which means regression testing and sometimes rework. The cost depends on how many customizations you run, how often you upgrade and how much test automation you already have. Latest release is v8.8.2, released 25 September 2026, per the project's GitHub releases page. Plan for upgrades on a cadence your team can sustain, and keep the upgrade path in mind when choosing a build approach.

What does a retainer cover compared with a one-off engagement?

A one-off engagement delivers a defined scope, such as a build, a migration or a hardening project, and ends at agreed deliverables. A retainer covers ongoing work over a period, such as support, upgrades and continuous testing, and its cost recurs. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope. Ask for a written list of what the retainer includes, how requests are prioritized, what response processes apply, and what is excluded, so you can compare it with the internal effort it replaces.

How DeployOpen scopes, delivers and hands over a HAPI FHIR cost model

DeployOpen approaches HAPI FHIR cost of ownership as a written, fixed-scope piece of work inside your own infrastructure. We map each cost component to a named owner, document the assumptions behind it, and hand over a model your team can maintain. Ongoing support is available as a retainer.

How we scope

Agree in writing which HAPI FHIR version, FHIR versions and deployment method the model covers.
Record the database choice, either PostgreSQL or Microsoft SQL Server, and the hosting environment behind the estimate.
Define which cost lines are in scope: infrastructure, database, Java engineering, security work and operations.

How we build

Build the cost model as a spreadsheet with separate one-time and recurring cost lines and stated assumptions.
Document the Java runtime and JDK requirement for the chosen release, and the effort to keep it current.
Test the assumptions against your environment, such as sizing, backup and security tasks, and note what changed.

How we hand over

Deliver the model with a written assumptions register that names each cost driver and its owner.
Walk your finance, platform and security leads through the cost lines and the questions to ask vendors.
Provide a comparison section covering self-hosting against commercial support, so your team can decide with the same inputs.

How we support

Update the model when your HAPI FHIR version, database or hosting changes, under the agreed scope.
Offer ongoing support and upgrade work as a retainer, priced from the written scope rather than a list price.
Confirm current release details and vendor support terms with the HAPI FHIR project and Smile CDR before you commit.

HAPI FHIR cost of ownership