Build a FHIR Server Tailored to Your Workflow
Design a high-performance FHIR server that aligns perfectly with your clinical, operational, or regulatory needs—no compromise required.
01
Define Your Data Model
Choose Your Standards - Select FHIR version (R5, R4, STU3, etc.) and resources to support (e.g., Observation, Patient, custom resources).
Extend or Restrict
Define custom extensions or restrictions on base FHIR resources using StructureDefinitions.
Reuse profiles from global FHIR profile registries or adapt templates from our reference projects.
Govern Terminology - Define value sets (ValueSet) and code systems (CodeSystem) to enforce standardized terminology.
02
Configure FHIR API Behavior
Shape your server's capabilities declaratively using native FHIR artifacts:
CapabilityStatement
Enable/disable FHIR interactions (delete, patch, etc.) for a resource type.
Enable/disable versioning support for a resource type.
Set reference policies (logical vs. literal) for a resource type.
Configure conditional interactions (conditional create, updates, etc.) for a resource type.
SearchParameter - Add custom search parameters (e.g., risk-score for Observations) or limit existing ones for security/performance/compliance.
CompartmentDefinition - Restrict access by clinical context (e.g., compartmentalize data by patient, practitioner or care team). Define new compartments if required.
03
Optimize Search
Configure onFHIR.io to meet exact performance targets (SLAs, hardware limits, data volumes) while ensuring ultra-fast queries at any scale.
Horizontal Scalability
Shard by Clinical Context: Route related data (e.g., all resources for a Patient) to the same MongoDB shard using related search parameters (e.g. patient) or compartments for related resource types minimizing cross-shard queries for time-sensitive workflows.
Adapt to Workloads: Optimize sharding keys (patient, practitioner, organization) to align with access patterns (e.g., regional deployments, specialty-specific clusters).
Lightning-Fast Queries
Index Strategically: Define single or composite indexes directly from FHIR SearchParameter definitions (e.g., indexing Observation on paths for “code” and “date” search parameters in addition to patient based sharding on “patient”).
Tune for Priorities: Balance read/write performance by indexing high-volume search parameters (e.g., diagnosis-code) while leaving rarely used parameters unindexed.
Why It Matters?
In Türkiye's HYP platform, patient-based sharding and priority indexing enable 14K+ queries/second on 38 billion+ resources, with a few millisecond response times for critical screenings.
04
Zero-Trust Security & Compliance
Design granular access policies and audit trails that align with healthcare regulations (HIPAA, GDPR, etc.) or organizational mandates.
SMART on FHIR Authorization
OAuth 2.0 & HEART WG Scopes: Enforce least-privilege access using standardized scopes (e.g., patient/Observation.rs for read-only access to blood pressure readings).
Dynamic Access Control with RBAC/ABAC Policies: Define rules using FHIR Path and FHIR search statements to restrict access based on:
User Attributes: Role (e.g., "nurse"), organization, or license status.
Resource Content: Mask HIV test results unless the user has sensitive-data:read scope.
Context: Time of day, geolocation, or IP range (e.g., block external access to psychiatric records).
e.g., ABAC Rule: "Practitioners can only access Patient resources if the managing organization of patient is same with user's organization"
Observation?subject:Patient.organization=Organization/$claims.organization
Compliance-Ready Auditing
FHIR AuditEvent Generation: Automatically log all REST API interactions (reads, writes, searches) with:
Full Context: User identity, IP, timestamp, accessed resource ID, and query parameters, etc.
Flexible Export: Persist logs internally as resources; stream to external systems via FHIR API or message queues; and write to filesystem for ELK Stack ingestion.
Extend Without Overhead - Replace or augment default security modules via the SDK:
Custom Auth Providers: Integrate legacy IAM systems (e.g., Active Directory, Keycloak).
Policy Engines: Embed proprietary rule engines or policy enforcement points.
Why It Works?
In Türkiye's HYP platform, ABAC policies ensure 35K+ practitioners only access data for their assigned patients and store/update data for assigned encounters, while audit logs meet national data sovereignty laws.
05
Deployment
Package Your Configurations - Bundle all configurations StructureDefinitions, CapabilityStatement, and SearchParameters, etc., access control policies, indexing configurations and general configurations into a package.
Deploy - Deploy and run onFhir.io with your configuration package —no code changes required.