Welcome to HAPI FHIR
- Table of Contents 1.0
- Changelog: 2023 1.1
- Changelog: 2022 1.2
- Changelog: 2021 1.3
- Changelog: 2020 1.4
- Changelog: 2019 1.5
- Changelog: 2018 1.6
- Changelog: 2017 1.7
- Changelog: 2016 1.8
- Changelog: 2015 1.9
- Changelog: 2014 1.10
Getting Started
- Introduction 2.0
- FHIR and HAPI FHIR Versions 2.1
- HAPI FHIR Modules 2.2
- Downloading and Importing 2.3
- FHIR R4B Support 2.4
Working With The FHIR Model
- Working With Resources 3.0
- Parsing and Serializing 3.1
- Resource References 3.2
- Profiles and Extensions 3.3
- Version Converters 3.4
- Custom Structures 3.5
- Narrative Generation 3.6
- Bundle Builder 3.7
Client
- Introduction 4.0
- Get Started ⚡ 4.1
- Generic (Fluent) Client 4.2
- Annotation Client 4.3
- Client Configuration 4.4
- Client Examples 4.5
Plain Server
- REST Server Types 5.0
- Plain Server Introduction 5.1
- Get Started ⚡ 5.2
- Resource Providers and Plain Providers 5.3
- REST Operations: Overview 5.4
- REST Operations: Search 5.5
- REST Operations: Extended Operations 5.6
- Paging Search Results 5.7
- Web Testpage Overlay 5.8
- Multitenancy 5.9
- JAX-RS Support 5.10
- Customizing the CapabilityStatement 5.11
- OpenAPI / Swagger 5.12
JPA Server
- Introduction 6.0
- Get Started ⚡ 6.1
- Architecture 6.2
- Database Support 6.3
- Database Schema 6.4
- Configuration 6.5
- Search 6.6
- Performance 6.7
- Upgrade Guide 6.8
- Diff Operation 6.9
- LastN Operation 6.10
- Lucene/Elasticsearch Indexing 6.11
- Terminology 6.12
- International Patient Summary (IPS) 6.13
JPA Server: MDM
- MDM Getting Started 7.0
- MDM Rules 7.1
- MDM Enterprise Identifiers 7.2
- MDM Operations 7.3
- MDM Technical Details 7.4
- MDM Search Expansion 7.5
- MDM Customizations 7.6
JPA Server: Partitioning and Multitenancy
- Partitioning and Multitenancy 8.0
- Partition Interceptor Examples 8.1
- Partitioning Management Operations 8.2
- Enabling Partitioning in HAPI FHIR 8.3
JPA Server: Batch Processing
JPA Server: HFQL (SQL) Driver
Clinical Reasoning
- Clinical Reasoning Overview 11.0
- CQL 11.1
- Care Gaps 11.2
- Measures 11.3
- ActivityDefinitions 11.4
- PlanDefinitions 11.5
- Questionnaires 11.6
Interceptors
- Interceptors Overview 12.0
- Client Interceptors 12.1
- Client Pointcuts 12.2
- Built-In Client Interceptors 12.3
- Server Interceptors 12.4
- Server Pointcuts 12.5
- Built-In Server Interceptors 12.6
- 7.0.0 Migration Guide 12.7
Security
- Introduction 13.0
- Authorization Interceptor 13.1
- Consent Interceptor 13.2
- Search Narrowing Interceptor 13.3
- CORS 13.4
- Basic Audit Log Pattern (BALP) 13.5
- Binary Resource Security Interceptor 13.6
Validation
- Introduction 14.0
- Parser Error Handler 14.1
- Instance Validator 14.2
- Validation Support Modules 14.3
- Schema/Schematron Validator 14.4
- Repository Validating Interceptor 14.5
- Validation Examples 14.6
Android
Tools
Contributing to HAPI FHIR
Appendix
Architecture
6.2.1HAPI FHIR JPA Architecture
The HAPI JPA Server has the following components:
-
Resource Providers: A RESTful server Resource Provider is provided for each resource type in a given release of FHIR. Each resource provider implements a @Search method implementing the complete set of search parameters defined in the FHIR specification for the given resource type.
The resource providers also extend a superclass which implements all of the other FHIR methods, such as Read, Create, Delete, etc.
Note that these resource providers are generated as a part of the HAPI build process, so they are not checked into Git. The resource providers do not actually implement any of the logic in searching, updating, etc. They simply receive the incoming HTTP calls (via the RestfulServer) and pass along the incoming requests to the DAOs.
-
HAPI DAOs: The DAOs actually implement all of the database business logic relating to the storage, indexing, and retrieval of FHIR resources, using the underlying JPA API.
-
Hibernate: The HAPI JPA Server uses the JPA library, implemented by Hibernate. No Hibernate specific features are used, so the library should also work with other providers (e.g. Eclipselink) but it is not tested regularly with them.
-
Database: The RESTful server uses an embedded Derby database, but can be configured to talk to any database supported by Hibernate.
6.2.2Schema
This implementation uses a fairly simple table design, with a single table being used to hold resource bodies (which are stored as CLOBs, optionally GZipped to save space) and a set of tables to hold search indexes, tags, history details, etc. This design has proven to be very scalable and flexible, and has been successfully used in large scale production architectures. That said, this design is still only one of many possible ways of designing a FHIR server so it is worth considering whether it is appropriate for the problem you are trying to solve.