FHIR R4 · FHIR R5 · Technical Expertise
FHIR at Production Scale.
Peerbits designs, builds, validates, and operates FHIR R4/R5 servers, resource APIs, Bulk Data pipelines, and Implementation Guide-compliant systems — across every major EHR, payer gateway, and clinical data exchange in the US market.
50M+
FHIR API calls / month
157+
Resource types supported
12+
IGs implemented
Compliance & Standards
RESOURCE COVERAGE
157 FHIR Resource Types. Every Category. Every Operation.
FHIR R4 defines 157 resource types across six categories. Peerbits has implemented, tested, and deployed all clinically significant resources — validated against US Core profiles, Da Vinci Implementation Guides, and CMS interoperability rule requirements.
Clinical & Medications
- Patient
- Encounter
- Condition
- Observation
- Procedure
- DiagnosticReport
- AllergyIntolerance
- CarePlan
- CareTeam
- Goal
- Immunization
- FamilyMemberHistory
- Medication
- MedicationRequest
- MedicationAdministration
- MedicationStatement
- MedicationKnowledge
- Substance
- NutritionOrder
- ImmunizationRecommendation
Financial
- Coverage
- Claim
- ClaimResponse
- ExplanationOfBenefit
- CoverageEligibilityRequest
- CoverageEligibilityResponse
- PaymentNotice
- PaymentReconciliation
- InsurancePlan
Workflow
- Appointment
- AppointmentResponse
- ServiceRequest
- Task
- Communication
- CommunicationRequest
- DeviceRequest
- Subscription
- Schedule / Slot
Infrastructure
- CapabilityStatement
- StructureDefinition
- ValueSet
- CodeSystem
- ConceptMap
- OperationDefinition
- Bundle
- OperationOutcome
- MessageHeader
- Schedule
- AuditEvent
Implementation Guide Expertise.From US Core to Da Vinci.
FHIR Implementation Guides define how the base standard must be configured for specific use cases — and conformance to the right IGs is now mandatory for CMS program participation, ONC certification, and payer API compliance. Peerbits has production experience with every major IG deployed in the US market.
US Core Implementation Guide
The foundational IG for all ONC-certified FHIR servers — defining must-support elements, mandatory profiles, and search parameter requirements for Patient, Encounter, Condition, Observation, DiagnosticReport, MedicationRequest, and 20+ additional resources.
Da Vinci Payer Data Exchange
CMS-mandated payer-to-payer and provider access API IG — enabling health plan members to access their complete clinical and claims history via FHIR. Required under CMS 9115-F. Peerbits has deployed compliant PDex servers for Medicare Advantage and commercial health plans.
Prior Authorization Support IG
FHIR-native prior authorization request and response framework — enabling real-time PA submission directly from EHR order workflows via CDS Hooks + FHIR, replacing fax-based and portal-based PA processes with structured, automated determinations.
CARIN Blue Button for BCBS
Consumer-directed payer claims access API — enabling members to retrieve their complete claims history (ExplanationOfBenefit, Coverage, Patient) via SMART on FHIR-authenticated API calls. Required for CMS interoperability compliance across commercial payers.
SMART Application Launch Framework
The authorization framework for launching FHIR-connected applications within or outside EHR contexts — OAuth 2.0 scopes, launch parameters, standalone and EHR launch flows, and PKCE support. See our dedicated SMART on FHIR page for full service detail.
minimal Common Oncology Data Elements
Standardized FHIR profiles for oncology data — cancer diagnosis, staging, genomics, treatment, and outcomes — enabling interoperability between oncology EHRs, cancer registries, clinical trial systems, and real-world evidence platforms. Deployed for life sciences and NCI-designated cancer centers.
Documentation Templates & Rules
Automated clinical documentation retrieval for payer coverage requirements — FHIR Questionnaire-driven workflows that pre-populate PA documentation from EHR data, reducing manual data entry by clinical staff and accelerating authorization turnaround.
FHIR Bulk Data Access IG
Asynchronous export of large FHIR datasets for population health analytics, payer reporting, and clinical research — Group-level and Patient-level exports in NDJSON format via the $export operation. Peerbits has processed bulk data exports exceeding 10M patient records per run.
US Core Data for Interoperability
ONC-defined minimum data elements required for all certified health IT — expanded through USCDI versions to include social determinants of health, health insurance information, preferred language, sexual orientation and gender identity, and disability status.
FHIR Server Architecture —How Peerbits Builds for Production.
A production FHIR server is not just a REST API wrapper over a database. It requires a conformance-validated resource store, a terminology service, an authorization server, a search engine tuned for FHIR query patterns, and a Bulk Data export pipeline — all operating within a HIPAA-compliant, audit-logged infrastructure.
CLIENTS
API Gateway / Rate Limiter
HTTPS · TLS 1.3 · Request validation · CORS
Auth Server (SMART / OAuth 2.0)
PKCE · Scopes · JWT · Token introspection
FHIR R4/R5 Server Core
Terminology Service
LOINC · SNOMED · RxNorm
Validation Engine
Profile · IG · ValueSet checks
Audit & Provenance
AuditEvent · Provenance · ATNA
IG Conformance Layer
US Core · Da Vinci · CARIN · mCODE
FHIR Resource Store
PostgreSQL · HAPI FHIR · Custom RDBMS
Search Index
Elasticsearch · FHIR search params
Bulk Export Store + Audit Logs
S3-compatible · NDJSON · HIPAA-encrypted
All layers: HIPAA · SOC 2 Type II · AES-256 at rest · TLS 1.3 in transit · AWS/Azure BAA
// Figure 1 — Peerbits FHIR R4/R5 Production Server Architecture. Multi-Layer design: API Gateway + Auth + FHIR Core (CRUD, Search, Operations, Subscriptions, Bulk) + Service Layer (Terminology, Validation, Audit, IG Conformance) + Storage. Full HIPAA/SOC 2 compliance at every layer.
Real-World Challenges
What Makes HL7 Integration Hard — and How We Solve It
HL7 v2.x has been deployed across 35+ years and thousands of healthcare organizations — each with their own implementation quirks, custom Z-segments, and non-standard field usage. Real HL7 integration expertise is earned in production environments, not built from reading the spec.
R4 → R5 Migration Without Breaking Production
FHIR R5 introduces breaking changes across 25+ resources — renaming elements, changing cardinalities, restructuring MedicationRequest, splitting Observation into specialized profiles, and replacing Questionnaire workflow patterns. Organizations running FHIR R4 in production face a migration that requires careful API versioning, parallel server operation, and client application updates — all without service disruption to clinical or payer-facing systems.
US Core Must-Support Gaps That Fail ONC Certification
US Core profiles define must-support elements that a server must be capable of populating — and ONC certification testing using Inferno specifically validates these requirements. Most EHR-sourced FHIR data fails US Core conformance in 3–7 profile areas on first test: missing race/ethnicity extensions, incomplete Patient identifiers, Observation lacking component arrays for blood pressure, and DiagnosticReport without presentedForm for document types.
FHIR Search Queries That Time Out Under Clinical Load
FHIR's search framework is powerful — chained searches, _include, _revinclude, composite parameters, and $everything operations — but naively implemented against a relational database, even simple queries like Patient/$everything for a patient with 10 years of records can return 5,000+ resources and time out under concurrent clinical load. Production FHIR search requires purpose-built indexing, result pagination strategies, and resource count limits that the spec leaves to implementers.
$export Operations That Hang on Large Populations
FHIR Bulk Data $export is designed for asynchronous operation — a client requests the export, polls a status URL, and downloads NDJSON files when ready. But implementations that run $export as a synchronous database query on millions of patients create queue saturation, memory exhaustion, and hours-long export jobs that block production API capacity. Payer population health and ACO reporting workflows require Bulk Data exports that complete in minutes, not hours.
Full Service Catalogue
FHIR Engineering Services. From Specification to Production.
Nine specialized FHIR engineering services — from server build and IG conformance to Bulk Data pipelines, terminology services, and FHIR-native application development. SMART on FHIR development is covered on our dedicated service page.
FHIR R4/R5 Server Development
End-to-end FHIR server build — CapabilityStatement design, resource store implementation, search parameter indexing, $operations, Subscription topics, Bulk Data $export, and conformance validation. HAPI FHIR, custom FHIR server, or hybrid architecture based on your throughput and hosting requirements.
US Core Profile Implementation
Full US Core 6.1.0 profile implementation across all 23 mandatory profiles — with automated Inferno test suite validation, ONC §170.315 certification preparation, must-support element gap analysis, and USCDI v3/v4 data mapping for all required clinical data classes.
FHIR Bulk Data ($export) Engineering
Production-grade Group-level and Patient-level Bulk Data $export — asynchronous job management, parallel NDJSON serialization to object storage, status polling API, file manifest generation, and client download SDKs. Optimized for population health, payer reporting, and clinical research export volumes.
Da Vinci IG Implementations
Full Da Vinci suite implementation — PDex (Payer Data Exchange), PAS (Prior Authorization Support Templates), HREX (Health Record Exchange), and PDex Plan Net (provider directory) — for CMS-9115-F compliance and value-based care workflow automation.
FHIR Terminology Service
Hosted FHIR Terminology Service — Scalable $validate, $lookup, $expand, and $translate operations for LOINC, SNOMED CT, RxNorm, ICD-10-CM/PCS, CPT, and custom ValueSets. Updated quarterly with official HL7/NLM terminology releases. Used by clinical decision support, coding automation, and IG conformance validation pipelines.
FHIR Validation & Conformance Testing
Automated FHIR resource validation against base R4/R5 schemas, US Core profiles, and client-specified Implementation Guide StructureDefinitions — integrated into CI/CD pipelines for teams doing frequent FHIR server updates. Inferno test suite execution, HL7 FHIR Validator, and custom conformance profile testing.
HL7 v2.x → FHIR R4 Migration
Bidirectional transformation between HL7 v2.x messages and FHIR R4/R5 resources — with full terminology mapping, Z-segment handling, and US Core profile conformance. Enables legacy systems to participate in FHIR ecosystems without source system replacement. See our HL7 page for full v2.x expertise.
FHIR Subscription (R4B / R5)
Real-time event-driven notifications via FHIR Subscription — Subscription topic definition, filter criteria, channel configuration (REST-hook, WebSocket, messaging), and payload shaping. Enables clinical alerting, care gap triggers, and payer event feeds without polling. R4B backport and R5 native both supported.
SMART on FHIR App Development
EHR-embedded clinical application development using the SMART App Launch 2.0 framework — OAuth 2.0 scoped authorization, EHR and standalone launch flows, and native launch context within Epic, Cerner, and Athenahealth. This service has a dedicated page with full technical detail and client case studies.
ENGAGEMENT MODEL
From CapabilityStatement to Production in 8 Weeks.
A FHIR implementation project begins with deciding exactly which resources, profiles, search parameters, and operations you need to support — and which IGs govern your use case. We design that scope precisely before writing a single line of server code.

STEP 1
Use Case & IG Scoping
Two-week discovery — identifying your target use case (payer API, provider interoperability, analytics, patient access), the IGs that govern it (US Core, Da Vinci, CARIN), the resource types required, and the search parameter set your clients will actually use. We write your CapabilityStatement before we build anything.
STEP 2
Server Architecture & Data Mapping
FHIR server architecture design — storage model, search index strategy, Bulk Data export design, Subscription channel configuration, and source data mapping from your EHR, claims, or lab data into the FHIR resource model with US Core must-support element coverage.
STEP 3
Build, Validate & Certify
Server implementation with automated Inferno conformance testing at every sprint milestone. Load testing at 2x peak expected throughput. US Core profile validation testing all 23 mandatory profiles. ONC certification preparation with pre-submission Inferno test run and gap remediation before submission.
STEP 4
Production & Continuous Compliance
Production deployment with FHIR API monitoring dashboard, SLA uptime reporting, quarterly IG update assessment as US Core and Da Vinci IGs release new versions, and conformance revalidation whenever your source data model or IG requirements change.
COMPETITIVE DIFFERENTIATION
Peerbits vs. the Alternatives
Compared to generic API consultancies, HAPI FHIR self-implementation, Azure/AWS managed FHIR services, and FHIR-only platform vendors — Peerbits delivers full-spectrum FHIR expertise from IG conformance to Bulk Data scale, with embedded HL7 v2.x migration capability no pure-FHIR vendor offers.
| Capability | Peerbits | DIY HAPI FHIR | Azure Health Data | Google FHIR | Generic Consultancy |
|---|---|---|---|---|---|
| FHIR R4 + R5 parallel support | ✓ Both | R4 default | R4 primary | R4 primary | Varies |
| US Core 6.1.0 / Inferno Certification | ✓ All 23 profiles | Manual | Partial | Partial | Varies |
| Da Vinci PDex / PAS / DTR IGs | ✓ Full Suite | - | - | - | Some |
| Bulk Data at 1M+ patient scale | ✓ <45 min | Manual tuning | ✓ | ✓ | Unlimited |
| FHIR Subscription (R4B / R5) | ✓ Full | R4B only | Limited | Limited | Varies |
| HL7 v2.x → FHIR migration capability | ✓ Full | - | - | - | Partial |
| Managed terminology service (LOINC/SNOMED) | ✓ Hosted | - | Add-on | Add-on | - |
| Average production go-live (full FHIR server) | 8 Weeks | 6–12 Months | 3–5 Months | 3–5 Months | 4–8 Months |
MEASURED OUTCOMES
Numbers from Production FHIR Implementations.
Across 60+ production FHIR server deployments — from single-hospital FHIR APIs to multi-payer population health pipelines — these are the performance, compliance, and delivery metrics Peerbits delivers.
50M+
FHIR API Calls / Month
Across all active FHIR R4 servers — Patient reads, Observation writes, search queries, $operations, and Subscription notifications.
157
Resource Types Supported
All clinically significant FHIR R4 resource types implemented, tested, and validated against US Core profiles and all major Implementation Guide profiles.
<100ms
Search Response (p95)
FHIR search including chained parameters, _include, and _revinclude — measured at p95 under concurrent clinical load on Elasticsearch-backed indexes.
100%
Inferno Test Pass Rate
Zero ONC Inferno test failures across all US Core FHIR server certifications — all 23 mandatory profiles passing certification submission.
12+
Implementation Guides
Production implementations of US Core, Da Vinci (PDex/PAS/DTR), CARIN Blue Button, mCODE, Bulk Data, SMART App Launch, USCDI v3/v4, and others.
45min
Bulk Data Export (1M patients)
Population-level $export to NDJSON on isolated read-replica — isolated from production API traffic, enabling payer reporting and population health without latency impact.
8wks
Avg. Production Go-Live
From CapabilityStatement scoping to production FHIR server live — including US Core profile implementation, Inferno validation, and load testing.
60+
FHIR Deployments
Across hospitals, health systems, payers, digital health startups, and life sciences organizations — spanning every major FHIR use case category.
What CIOs & FHIR Architects Say
From ONC certification projects and CMS interoperability compliance to payer population analytics and clinical trial data platforms — Peerbits' FHIR work in production speaks for itself.
#clientspeak
Learn more about our processes from our clients
After a rigorous selection process, choosing Peerbits as our technology partner was the right choice. Peerbits is an innovative company with a team of talented, committed, and smart individuals. Thank you for helping us deliver world-class healthcare solutions.
Dan
Health Vector
READY TO START?
Get Your Free FHIR Architecture Assessment
In a 45-minute technical session, our FHIR engineering team will assess your current FHIR maturity, identify your US Core and IG conformance gaps, review your Bulk Data and search performance, and give you a concrete implementation roadmap.
Book Your Free Assessment —Case studies: Real provider outcomes
See how we've helped hospitals, clinics, and health systems solve real operational challenges with custom software.
Frequently asked questions
FHIR R4 is the current production standard required by ONC and CMS mandates — all certified EHRs must expose FHIR R4 APIs. FHIR R5 introduces breaking changes across 25+ resources including MedicationRequest, SubscriptionTopic, and EvidenceReport. Peerbits builds on R4 with parallel R5 support and a phased migration path — keeping R4 clients operational while R5 is built alongside.
Inferno is the ONC-designated test suite for US Core FHIR conformance — validating all 23 mandatory US Core profiles including must-support elements, race/ethnicity extensions, composite search parameters, and presentedForm requirements for DiagnosticReport. Peerbits runs automated Inferno validation against every FHIR server before ONC submission, achieving a 100% first-submission pass rate across all client certifications.
We have production implementations of US Core 6.1.0, Da Vinci PDex, PAS, DTR, and HREX, CARIN Blue Button, mCODE, SMART App Launch v2.0, FHIR Bulk Data v2.0, and USCDI v3/v4 — covering payer data exchange, prior authorization, oncology, population health, and ONC certification use cases.
FHIR Bulk Data $export is an asynchronous operation — a client requests the export, polls a status URL, and downloads NDJSON files when ready. Peerbits runs $export on a dedicated read-replica cluster with parallel resource serialization to S3-compatible object storage — exporting 1M patient populations in under 45 minutes, isolated from production API traffic.
Yes. We provide bidirectional transformation between HL7 v2.x messages and FHIR R4/R5 resources — with full terminology mapping (LOINC, SNOMED, RxNorm), Z-segment handling, and US Core profile conformance. This enables legacy systems to participate in FHIR ecosystems without source system replacement.
Most organizations go live in 8 weeks — from CapabilityStatement scoping through production deployment. This includes use case and IG scoping, server architecture design, data mapping, build, automated Inferno validation, load testing at 2x peak throughput, and ONC certification preparation.
The cost depends on the number of IGs required, resource types supported, Bulk Data scale, search performance requirements, and ONC certification scope. Unlike managed FHIR cloud services with per-API-call pricing that compounds with patient volume, Peerbits delivers a fully owned implementation — no ongoing per-request licensing costs.
Have more questions?
Ask our expertsKnowledge hub
Stay ahead with expert insights on healthcare technology, compliance, and digital transformation.











