Another quarter gone by, another HAPI-FHIR release.
HAPI FHIR 5.5.0 (Codename: Pangolin) brings a whole bunch of great new features, bugfixes, and more.
Highlights of this release are shown below. See the Changelog for a complete list. There will be a live Webinar (recording available on-demand afterward) on August 18 2021. Details available here: https://www.smilecdr.com/quarterly-product-release-webinar-reminder
- Resolved multiple vulnerabilities by updating dependencies.
General Client/Server/Parser Changes
- Added configuration to enable/disable various scheduled tasks.
- Support for qualified * for _include and _revinclude has been added, e.g.
- Flyway migration used to enforce order by default. This has been changed so now the default behaviour is out of order migrations are permitted. Strict order can be enforced via the new strict-order flag if required.
CLI Tool changes:
- Support for multiple header-passthrough option using -hp or --header-passthroughparameter has been added to hapi-fhir-cli commands: example-data-uploader, export-conceptmap-to-csv, import-csv-to-conceptmap and upload-terminology
JPA Server General Changes
- DELETE _expunge=true has been converted to a Spring Batch job.
- Added a new setting to JpaStorageSettings called
Tag Versioning Mode, which determines how tags are maintained.
- A new tag storage mode called Inline Tag Mode tas been added. In this mode, all tags are stored directly in the serialized resource body in the database, instead of using dedicated tables. This has significant performance advantages when storing resources with many distinct tags (i.e. many tags that are unique to each resource, as opposed to being reused across multiple resources).
- A new interceptor has been addeed to the JPA server called
ForceOffsetSearchModeInterceptor. This interceptor forces all searches to be offset searches, instead of relying on the query cache.
- Added a new
$reindex operation which creates a Spring Batch job to reindex selected resources.
JPA Server Performance Changes
- A new setting has been added to the JpaStorageSettings that allows the maximum number of
_revinclude resources to be added to a single search page result. In addition, the include/revinclue processor have been redesigned to avoid accidentally overloading the server if an include/revinclude would return unexpected massive amounts of data.
- When performing non-query cache JPA searches (i.e. searches with
Cache-Control: no-store) the loading of
_revinclude will now factor the maximum include count."
- Subscriptions will no longer be triggered on unversioned changes.
- A new JpaStorageSettings setting called Mass Ingestion Mode has been added. This mode enables rapid data ingestion by skipping a number of unnecessary checks during backloading.
- FHIR Transactions with writes in them will now aggressively pre-fetch as many entities as possible at the start of processing. This reduces the number of database roundtrips.
- A new interceptor has been added for JPA servers that uses semaphores to avoid multiple concurrent FHIR transactions from trying to create/update the same resource at the same time. This can improve overall performance when writing many concurrent transactions since it avoids the need for retries.
JPA Server Partitioning Changes
- PatientIdPartitionInterceptor now supports conditional creates of resources where the resource is in the patient compartment but the conditional URL does not contain a patietn reference.
- The $evaluate-measure now works on a partitioned server.
Terminology Server and Validation Changes
- Added support for ICD-10-CM.
- A new interceptor ValidationMessageSuppressingInterceptor has been added. This interceptor can be used to selectively suppress specific vaLidation messages.
- Support for LOINC 2.70 has been added.
- Fixed a bug where ValueSet expansion did not correctly preserve order if multiple codes were included in a single inclusion block.
- A new Validation Support Module has been added that can use NPM Packages to supply validation conformance artifacts programatically to the validator."
JPA Server MDM Enhancements
- Too many MDM candidates matching could result in an OutOfMemoryError. Candidate matching is now limited to the value of IMdmSettings.getCandidateSearchLimit(), default 10000.
- Searches for mdm-expanded references such as Observation?subject:mdm=123 were getting denied by access rules that did not recognize the :mdm suffix. This has been corrected.
- $mdm-submit operation was only submitting 100 resources and then stopping. It now correctly submits all