Welcome to a new major release of HAPI FHIR! Since there are many breaking changes, we are making this a major release.
- Support for Java 8 has been dropped. A minimum of Java 11 is now required for HAPI FHIR. Java 17 is also supported.
- Database indexes have been completely reworked for Search Index tables. This should result in significantly faster searches in most use cases.
- A new batch operation framework for executing long running background jobs has been created. This new framework is called 'Batch2', and will eventually replace Spring Batch. This framework is intended to be much more resilient to failures as well as much more paralellized than Spring Batch job.
- Previously, it was possible to update a resource with wrong
tenantID. This issue has been fixed.
- User was permitted to bulk export all groups/patients when they were unauthorized. This issue has been fixed.
- The Spring Framework library was upgraded to version 5.3.18 in order to avoid depending on a version known to be vulnerable to CVE-2022-22965, known as Spring4Shell. HAPI FHIR is not believed to be vulnerable to this issue, but the library has been bumped as a precaution.
General Client/Server/Parser Changes
- Added search parameter modifier :nickname that can be used with 'name' or 'given' search parameters.
- Added a new pointcut:
STORAGE_PRESTORAGE_CLIENT_ASSIGNED_ID which is invoked when a user attempts to create a resource with a client-assigned ID.
- The XML and JSON Parsers are now encoding narratives of contained resources. Narratives were skipped before for contained resources.
- Include property regex operation was not working when expanding ValueSet. This is now fixed
- When performing a search with a
_revinclude. the results sometimes incorrectly included resources that were reverse included by other search parameters with the same name. Thanks to GitHub user @vivektk84 for reporting and to Jean-Francois Briere for proposing a fix.
- The HAPI FHIR server GraphQL endpoints now support GraphQL introspection, making them much easier to use with GraphQL-capable IDEs.
- Support has been added to the JPA server for token
- SearchNarrowingInterceptor can now be used to automatically narrow searches to include a
code:not-in expression, for mandating that results must be in a specified list of codes.
- Support has now (finally!) been added for the FHIR Bulk Import ($import) operation.
- A consent service implementation that enforces search narrowing rules specified by the SearchNarrowingInterceptor has been added.
GET resource with
_summary=count if consent service enabled should throw an InvalidRequestException. This issue has been fixed.
- Reindexing jobs were not respecting the passed in date range in SearchParams. We now take date these date ranges into account when running re-indexing jobs.
- The server now supports date searches with the NOT_EQUALS (
- Previously the Fhir parser would only set the resource type on the resource ID for resources which implemented
IDomainResource. This caused a few resource types to be missed. This has been corrected, and resource type is now set on the id element for all
IBaseResource instances instead.
CLI Tool changes:
- Previously there was no way to recreate freetext indexes for terminology entities. A new CLI operation, reindex-terminology now exists for this purpose.
JPA Server General Changes
- _include now supports canonicals as well as standard references.
- The resource JSON can now be stored and retrieved in the Lucene/Elasticsearch index. This enables some queries to provide results without using the database. This is enabled via
- An occasional concurrency failure in AuthorizationInterceptor has been resolved. Thanks to Martin Visser for reporting and providing a reproducible test case!
- When cross-partition reference Mode is used, the rest-hook subscriptions on a partition enabled server would cause a NPE. This has been resolved.
- Group Bulk Export (e.g. Group/123/$export) now additionally supports Organization and Practitioner as valid _type parameters. This works internally by querying using a
JPA Server Performance Changes
- When deleting a large ValueSet operation was timing out. This issue has been fixed.
- Performance for JPA Server ValueSet expansion has been significantly optimized in order to minimize database lookups, especially with large expansions.
- When using JPA persistence with Hibernate Search (Lucene or Elasticsearch), simple FHIR queries that can be satisfied completely by Hibernate Search no longer query the database.
- Added a new setting to BinaryStorageInterceptor which allows you to disable binary de-externalization during resource reads.
- When searching for date search parameters on Postgres, ordinals could sometimes be represented as strings, causing a search failure. This has been corrected.
- A regression in HAPI FHIR 5.5.0 meant that very large transactions where the bundle contained over 1000 distinct client-assigned resource IDs could fail on MSSQL and Oracle due to SQL parameter count limitations.
Terminology Server and Validation Changes
- ValueSet pre-expansion was failing when number of concepts was larger than configured BooleanQuery.maxClauseCount value (default is 1024). This is now fixed.
- A regression in HAPI FHIR 5.7.0 meant that when UnknownCodeSystemWarningValidationSupport was configured for WARNING behaviour, validating a field with an implicit code system could incorrectly result in an error.
- We now Provide a Remote Terminology Service implementation for the $translate operation.
- The JPA server terminology service can now process IS-A filters in ValueSet expansion on servers with Hibernate Search disabled.
- HAPI-FHIR no longer performs Repository Validation on resources that are implicitly created, e.g. placeholder resources.