IPF 3.5 Migration Guide
IPF 3.5 comes with some changes that must be considered when upgrading from IPF 3.4.
ATNA Audit changes
ATNA auditing was reimplemented, which makes the need of the OpenHealthTools libraries obsolete.
For migration, replace your legacy ATNA configuration. For details on how to configure ATNA auditing now, please check here.
If you only require one
AuditContext for all transactions, you can keep the legacy
parameter in your endpoint URIs. It is recommended, however, to switch to the new
ref is the ID of a
The parameters for executing RFC 5425-compliant auditing over TLS are now exclusively derived from the standard JSSE parameters.
If you derived your own ATNA auditing from the OpenHealthTools libraries, you might want to migrate to the new API
in order to avoid redundant configuration. Please check here for details on
the new API and configuration.
If you choose to migrate your own ATNA auditing at a later point in time, you can continue to use the legacy
library by explicitly depending on
In order to avoid split packages (violating the module concept as of Java 9), a couple of package names were changed to avoid that different IPF modules expose classes under the same package. Most likely, the following changes will affect library users:
ipf-commons-springmodule: classes were moved from
ipf-commons-ihe-fhir-dstu2-coremodule: classes were moved from
ipf-commons-ihe-fhir-stu3-coremodule: classes were moved from
Removal of deprecated functionality in IPF 3.5
The following deprecated classes have been removed in IPF 3.5
- all deprecated classes in
ipf-modules-hl7, particularly the old validation rule builders