Getting a FHIR implementation live in 90 days sounds like a stretch — and for many teams it is. But it’s also realistic when you focus on a tight scope, the right stack, and clear measures of success. This article is for product leads, engineers, clinical informaticists, and operations owners who need a practical, no-fluff playbook: how to stand up useful FHIR functionality quickly, prove measurable ROI, and avoid the usual “pilot forever” trap.
Over the next sections you’ll find a pragmatic breakdown of what a minimum viable FHIR rollout looks like (what to include and what to leave out), the must‑have features that stop projects from stalling, four high‑impact use cases that unlock value fast, and a day‑by‑day 90‑day plan you can adapt to your context. We’ll also show the simple metrics that prove ROI — not vanity numbers, but things leaders actually care about: clinician time saved, reductions in no‑shows and readmissions, and data pipeline cost per gigabyte.
This isn’t a vendor pitch or a long list of every FHIR capability. Think of it as a surgical guide: pick a small set of resources (Encounter, Observation, DocumentReference, Patient), wire up SMART on FHIR for authentication, map your core data, route subscriptions or bulk export to analytics, and measure impact. When done right, that sequence gets you from sandbox to production workflows without months of rework.
Why 90 days? Because momentum matters. Long projects lose sponsorship, data drifts, and user expectations change. A clear 30/60/90 plan creates quick wins (pilot users and measurable results), while leaving room to expand into full interoperability, terminology management, and scale. Later sections explain exactly what to do in each window — plus the operational and security checks you cannot skip.
Whether you’re building or buying, this guide will help you choose the right tradeoffs: which open‑source and managed components to lean on, when to tolerate technical debt for speed, and when to harden for long‑term reliability. Most importantly, you’ll get concrete success metrics and a short checklist to prove to stakeholders that the project delivered business value.
Ready to see the 90‑day plan and the practical checklist that makes it happen? Keep reading — the next section shows the exact features to include (and the ones to defer) so you can go live quickly and start measuring ROI from week one.
What FHIR software includes (and what it doesn’t)
“FHIR software” is a broad term: at minimum it exposes the HL7 FHIR REST API and persisting FHIR resources, but a production-ready FHIR stack usually bundles several supporting pieces (auth, terminology, validation, bulk export, eventing) — and often omits other parts of the care stack (front‑end UIs, analytics warehouses, device drivers) that you will need to provide or integrate. Below is a practical breakdown of what to expect from a FHIR server or platform, and where you’ll need complementary systems or engineering.
FHIR server vs FHIR facade (when each fits)
FHIR server: the canonical choice when you need a persistent, auditable store of FHIR resources and full read/write semantics. A true FHIR server implements the RESTful endpoints, search parameters, versioning, transactions and resource history defined by the FHIR spec and is appropriate when you control the data lifecycle, require ACID or consistent storage, or must support bulk export and provenance.
FHIR facade (or “on‑the‑fly” adapter): a façade translates an existing system’s data into FHIR at runtime without moving everything into a new store. Facades are fast to deploy for read scenarios, minimize data duplication, and reduce migration risk — but they struggle with writebacks, complex transactions, search scale, and long‑running analytics because underlying systems govern persistence and consistency.
Choose a server where you need durability, compliance, controlled updates, or heavy downstream analytics. Choose a facade for quick interoperability layers, prototypes, or when legal/operational limits prevent moving data.
SMART on FHIR: OAuth2/OIDC and app launch
Modern FHIR platforms support SMART on FHIR as the standard way to authorize apps and exchange launch context. SMART builds on OAuth2 / OpenID Connect for delegated access, defines scopes (patient/*.read, user/*.write, offline_access, etc.), and specifies the app launch sequence so apps receive the patient or encounter context from an EHR.
If you plan to run third‑party apps or mobile clients, ensure the platform provides a SMART-compatible authorization server (supporting OAuth2 token endpoints, refresh tokens, appropriate scopes, and launch context) and clear app registration flows. SMART docs and app launch details are at the SMART project site and HL7 resources: https://smarthealthit.org/ and https://www.hl7.org/fhir/smart-app-launch/.
Terminology: codes, value sets, SNOMED/LOINC, $validate-code
FHIR resources reference clinical code systems but usually don’t host a complete terminology ecosystem by default. A production platform commonly includes or integrates with a terminology service for:
Popular authoritative systems you’ll integrate are SNOMED CT and LOINC. Production deployments either embed a terminology server (e.g., a CTS2/Terminology service) or connect to managed terminology services. For reference: SNOMED International (https://www.snomed.org/), LOINC (https://loinc.org/), and the FHIR $validate-code operation documentation (https://www.hl7.org/fhir/operation-validate-code.html).
Profiles and validation: US Core, IPS, EU/UK Core
Out of the box, FHIR resources are flexible; implementation guides (IGs) and profiles are how vendors and regulators constrain that flexibility for interoperability. Profiles specify required elements, cardinality, permitted codings, and example bindings. Common IGs you’ll encounter include US Core (for US clinical interoperability), the International Patient Summary (IPS), and regional variants (EU/UK cores).
Key implications: your FHIR platform should include a validation engine that can load and apply IGs (and their value set bindings) during import, API requests, or CI/CD tests. That prevents downstream mapping drift and is essential if you need certification or to pass conformance testing.
See the US Core IG for an example of how profiles shape interoperability: https://www.hl7.org/fhir/us/core/.
Bulk Data ($export/$import) and analytics pipelines
For analytics and population‑scale use cases, look for Bulk Data support. The Bulk Data Access (NDJSON) pattern lets you export large sets of resources efficiently (federated exports, asynchronous jobs, paging) so downstream analytics or data warehouses can ingest normalized FHIR payloads. Some platforms also offer bulk import or tools to stage large volumes into the FHIR store.
Note: a FHIR server’s bulk export alone doesn’t make an analytics solution. You’ll still need ETL/ELT pipelines, a data lake or warehouse, transformation jobs (flattening FHIR to analytics tables), and cost management for export egress and storage. The HL7 Bulk Data IG is a canonical reference: https://hl7.org/fhir/uv/bulkdata/.
Subscriptions and eventing for real-time workflows
Subscriptions let systems react to changes in resources (create/update/delete) by pushing notifications (webhook, websocket, queue) or by integrating with message buses. A platform that supports Subscriptions enables real‑time workflows such as alerts, device streaming, or triggering AI transcription when a new encounter documentation appears.
Implementations vary: some servers push direct webhooks, others publish to Kafka/SQS or provide integration adapters. Designing delivery guarantees, retry policies, and filtering (so you don’t overwhelm subscribers) is as important as supporting the Subscription contract itself. See the FHIR Subscriptions spec for details: https://www.hl7.org/fhir/subscription.html.
What a FHIR platform typically does not include (so plan to add or integrate): user‑facing EHR UIs, full analytics and BI layers, clinical decision engine rule repositories, device drivers for proprietary medical hardware, and often sophisticated consent/workflow engines — these live in adjacent systems or require bespoke engineering. With the server, auth, terminology, profile validation, bulk access and subscriptions in place, you have the core to build high‑value integrations; the next step is turning those platform capabilities into a non‑negotiable feature checklist you can use to select or harden a production deployment.
The non‑negotiable feature checklist
Interoperability and conformance: CapabilityStatement, search, transactions, versioning (R4/R4B now, R5‑ready)
Require a platform that publishes a machine‑readable CapabilityStatement and adheres to FHIR search and HTTP semantics (including transactions and versioning). CapabilityStatement is the canonical way to advertise supported resources, interactions and profiles; search and transaction behavior determine whether integrations will work predictably across systems. Verify the server’s supported FHIR release (R4 / R4B today and R5 compatibility plans) and that it can surface conformance tests for your chosen implementation guides.
References: HL7 CapabilityStatement and search/transaction docs — https://www.hl7.org/fhir/capabilitystatement.html, https://www.hl7.org/fhir/search.html, https://www.hl7.org/fhir/http.html; FHIR release pages — https://www.hl7.org/fhir/r4b/ and https://build.fhir.org/.
Performance and scale: search latency, $export throughput, partitioning/tenancy
Define measurable SLAs: search response times for typical queries, throughput for bulk export ($export) jobs, and concurrency for transaction workloads. Confirm the platform supports horizontal scale, data partitioning (per‑tenant or per‑customer), and resource quotas so high‑volume patients or tenants don’t degrade performance for others. Also validate large‑file handling, asynchronous job APIs, and rate limiting behavior under peak loads.
Reference for bulk export patterns and async jobs: HL7 Bulk Data — https://hl7.org/fhir/uv/bulkdata/.
Security and privacy: consent, audit, encryption, breach response
Security is non‑optional. At minimum the platform must:
References: FHIR AuditEvent and Consent resources — https://www.hl7.org/fhir/auditevent.html, https://www.hl7.org/fhir/consent.html; HIPAA breach rules — https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html.
Data quality and mapping: ETL to FHIR, terminology binding, round‑tripping
Validate the platform’s support for robust data onboarding and ongoing quality controls:
References: FHIR ValueSet/CodeSystem and validate‑code operation — https://www.hl7.org/fhir/valueset.html, https://www.hl7.org/fhir/codesystem.html, https://www.hl7.org/fhir/operation-validate-code.html.
Operations and cost: SLAs, monitoring, backups, upgrades, TCO
Operational maturity decides whether a 90‑day rollout can be sustained. Require:
Ask vendors for concrete runbooks, example dashboards, RTO/RPO targets, and historical uptime reports before committing.
Together, these items form a short checklist you can use to evaluate platforms and vendors: conformance articulation (CapabilityStatement + IG support), measured performance and partitioning, strict security and consent enforcement, proven data mapping and terminology flows, and operational guarantees tied to cost transparency. With those boxes ticked you can safely move from platform selection into building the first high‑impact integrations and pilots that prove ROI — the next section walks through the use cases that unlock that value.
4 high‑ROI use cases FHIR software unlocks
Ambient clinical documentation: cut EHR time ~20% using Encounter, Composition, DocumentReference
Ambient scribing and AI‑assisted note generation are a natural fit for FHIR: record encounters as Encounter, store structured and narrative notes as Composition, and surface attachments or transcribed artifacts via DocumentReference. Integrations that write back concise, coded summaries into the EHR (or into a parallel FHIR store) reduce duplicate charting and make notes queryable for downstream analytics and CDS.
“20% decrease in clinician time spend on EHR (News Medical Life Sciences).” Healthcare Industry Challenges & AI-Powered Solutions — D-LAB research
“30% decrease in after-hours working time (News Medical Life Sciences).” Healthcare Industry Challenges & AI-Powered Solutions — D-LAB research
Practical implementation notes: capture encounter context via SMART launch, persist draft Compositions, and emit AuditEvent/Provenance so downstream reviewers and auditors can trace AI contributions. Start with a narrow pilot (primary care or a single specialty) to validate templates and terminology bindings before broad roll‑out.
Telehealth and RPM: stream Device/Observation with Subscriptions
Remote monitoring and telehealth scale when device readings (Device, Observation) are streamed into care workflows and analytics. Use FHIR Subscriptions to notify care teams or trigger automation when thresholds are crossed; leverage Device resources to capture device metadata and provenance for regulatory traceability.
“78% reduction in hospital admissions when COVID patients used Remote Patient Monitoring devices (Joshua C. Pritchett).” Healthcare Industry Disruptive Innovations — D-LAB research
Design considerations: apply filtering in Subscription criteria to avoid alert fatigue, normalize device telemetry to LOINC codes where possible, and route high‑priority events into secure messaging/clinical tasking systems. Start by streaming a single vital sign (e.g., SpO2) and instrumenting the alert-to-action loop to measure impact.
Scheduling and revenue protection: Appointment/Slot + messaging to reduce no‑shows
Appointment and Slot resources give you a canonical schedule model to couple with patient contact channels. When a Slot changes or an Appointment is created, a Subscription can trigger automated reminders, two‑way confirmations, or waitlist offers that reduce no‑shows and free up capacity.
Implementation tips: integrate messaging providers at the Subscription or middleware layer, instrument confirmation rates and abandoned bookings, and ensure consent/preferences are respected at the ContactPoint level. A phased approach—pilot reminders for a single clinic and measure confirmed vs. no‑show rates—lets you quantify revenue protection before scaling.
Value‑based care analytics: Measure/MeasureReport + Bulk Data for outcomes and quality
FHIR Measure and MeasureReport provide native structures to represent quality measures and captured performance; Bulk Data ($export) lets you move population‑scale, normalized resources into analytics pipelines for cohorting, risk adjustment, and outcomes tracking. Combining MeasureReports with periodic bulk exports yields repeatable, auditable indicators for value‑based contracting.
Operational advice: schedule regular $export jobs for the relevant resource types, maintain deterministic mapping from source systems to the FHIR schema so measure calculations are stable, and track versioned Measure definitions to ensure historical comparability. Start by implementing a small set of high‑value measures to validate the end‑to‑end pipeline from ingestion to payer/reporting dashboards.
These four use cases are pragmatic, fast to pilot, and tightly aligned to measurable ROI — once you’ve proven value in each, you’ll be ready to decide whether to build or buy the remaining pieces of your FHIR stack and standardize on an architecture that sustains growth and compliance.
Thank you for reading Diligize’s blog!
Are you looking for strategic advise?
Subscribe to our newsletter!
Build vs buy: a reference FHIR stack that works
Open‑source core: HAPI FHIR server, Firely SDK, fhir‑py client
Open‑source components give maximum control and lower license costs, but require engineering investment to operate and secure. Use a proven FHIR server as the persistence layer, SDKs for server or client development, and language‑native clients for integrations and ETL jobs. Plan for supportability (patching, upgrades), testing harnesses, and internal runbooks if you choose this route.
Managed cloud options: Azure Health Data Services, Google Cloud Healthcare API, AWS HealthLake
Managed FHIR services remove much of the operational burden: they handle scaling, platform security, and platform updates while exposing FHIR APIs. The tradeoffs are reduced implementation control, potential vendor lock‑in, and cloud cost models (storage, egress, compute). Evaluate managed offerings against your data residency, compliance, and integration needs before committing.
Reference architecture: ingestion/mapping, terminology, auth, server, events, warehouse/lakehouse
A reliable, repeatable reference architecture separates responsibilities into clear layers:
Design interfaces between layers as small, testable contracts and automate deployment and schema validation to reduce drift.
Decision rules: data residency, scale, team skills, time‑to‑value
Use simple decision criteria to choose build vs buy:
Score each option against these rules (compliance, cost, risk, speed) and pick the one that maximizes near‑term wins while keeping strategic options open.
Testing and certification: profiles, $validate, Inferno/Touchstone
Make testing part of the delivery pipeline. Validate resources against the implementation guides and value set bindings you require, automate $validate or equivalent checks during ingest, and use conformance testing tools to exercise expected interactions. Maintain a certification checklist that includes profile conformance, security scans, performance benchmarks, and interoperability tests with important partners.
Choosing build vs buy is less about technology and more about tradeoffs: control vs speed, cost predictability vs flexibility, and internal capabilities vs vendor SLAs. With a reference architecture and a short decision rubric in hand you can lock the right stack for a 90‑day go‑live and move quickly to the pilot use cases and metrics that prove ROI.
Your 90‑day rollout plan and success metrics
Days 0–30: stand up sandbox, pick implementation guides, wire SMART, import synthetic data
Goals: get a repeatable, isolated environment where teams can iterate without touching production and validate end‑to‑end flows.
Days 31–60: map 3–5 resources, pilot AI scribe, set Subscriptions
Goals: prove integration patterns for the highest‑impact resources and validate the closed loop from capture to action.
Days 61–90: add RPM feed, enable bulk export to analytics, harden security
Goals: extend to a second use case that demonstrates downstream value (analytics or remote monitoring) and lift security to production standards.
Metrics to track
Define baseline and target for each metric, measure continuously, and report weekly during the rollout.
Risk checks and mitigation
Address technical, privacy and vendor risks early and document mitigations.
Run this plan with tight governance: short daily standups during sprints, weekly executive checkpoints, and a clear acceptance criteria list for each milestone. If the three 30‑day blocks complete with measurable improvements on the KPIs above, you’ll have both an operational FHIR platform and the quantitative evidence needed to scale and prove ROI.