FHIR Chat · HAPI FHIR 5.4.0 (Pangolin) Release · hapi

Stream: hapi

Topic: HAPI FHIR 5.4.0 (Pangolin) Release

view this post on Zulip James Agnew (May 19 2021 at 18:54):

Hi All,

Just a quick note that HAPI FHIR 5.4.0 (Pangolin) has been released to Maven Central and GitHub Releases.

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 May 20 2021. Details available here: https://www.smilecdr.com/quarterly-product-release-webinar-reminder

Security Changes

  • A resource exhaustion vulnerability in the HAPI FHIR JPA server was corrected. Learn more about CVE-2021-32053 here. Thanks to Zachary Minneker at Security Innovation for reporting!

General Client/Server/Parser Changes

  • HAPI FHIR now supports OpenAPI (aka Swagger). See here for an example.
  • Normalization and Standardization interceptors have been added. These can be used to normalize selected data fields according to configurable rules prior to storage.
  • Contained resources can now reference to containing resources, as allowed in the FHIR Specification. Previously this direction was blocked and contained resources with no incoming reference from the containing resource were automatically stripped, as this style was not permitted in early versions of the FHIR specification. In addition, contained resource order will now be preserved during parsing round-trips.
  • New interceptors have been added that can automatically map terminology in response resources using HAPI FHIR terminology services, returning configurable canonical terminology in the response payload.
  • Support for the FHIR Prefer: handling=lenient header has been added via an optional interceptor.
  • The automatic CapabiityStatement generation has been completely rewritten for R4+ servers. CapabilityStatements now include many new data elements, such as supported profiles, revincludes, resource level operations, and more.
  • Token Search Parameters in GraphQL expressions are now correctly parsed.

JDK Changes

  • HAPI FHIR now supports JDK 16, and this version is used to execute our CI test suite in order to ensure continued compliance. The minimum Java version required in order to use HAPI FHIR remains JDK 8. This may be updated to JDK 11 in an upcoming release, as many of the libraries we use are now either contemplating or have already completed an upgrade to JDK 11 as a minimum requirement.

JPA Server General Changes

  • Support for the _list search parameter has been added to the JPA server
  • Support for the :contained modifier has been added, allowing searches to select from data in contained resources found within the resource being searches. Note that this feature is disabled by default and must be enabled if needed.
  • The JPA server now supports persisting FHIR extensions in Resource.meta
  • Bulk Export now supports Patient- and Group- based exports
  • Auto-created reference target placeholder resources now include an extension and an identifier if one is known
  • A profiling effort led to improvements in performance when processing large FHIR Transaction bundles
  • Resources imported into a repository via NPM Packages will now attempt to preserve the resource ID defined in the source package.

JPA Server Performance Changes

  • Searches with only a single search parameter now generate a more streamlined SQL expression (one unnecessary JOIN was removed), improving performance.
  • A new header X-Upsert-Extistence-Check (note there is a typo in the name, this will be addressed in the next release of HAPI FHIR! Please be aware if you are planning on using this feature) can be added which avoids existence checks when using client assigned IDs to create new records. This can speed up performance.

JPA Server Partitioning Changes

  • Resource Reindexing is now supported on partitioned servers.
  • FHIR Bulk Export is now supported on partitioned servers (note that this operation is run at the system level and includes data from all partitions. Future enhancements may allow for more nuanced exports on partitioned servers.)

Terminology Server and Validation Changes

  • ValueSet expansion can now optionally return codes in the same hierarchy that they are defined in their source CodeSystem.
  • Validation can now be configured to return only a warning when a code is found from a CodeSystem that is unknown/unavailable to the validator.

JPA Server MDM Enhancements

  • A new search mdm-expansion syntax has been added to FHIR searches on MDM-enabled servers. For example Observation?patient:mdm=Patient/123 can be used to search for Observation resources belonging to Patient/123 but also to other MDM-linked patient records.
  • MDM matching rules can now use FHIRPath expressions as selection criteria.
  • A new syntax has been added to Group Bulk Export that allows MDM matching to be used to include matches in the group to export.
  • MDM matching rules can now match on extensions, checking the URL and Value for equality.
  • A new NUMERIC matcher has been added, allowing matching using numeric values.

Cheers,
James

view this post on Zulip Joe Atterberry (May 20 2021 at 01:04):

Hi. I've been using the hapi-fhir-jpaserver-starter. I'd been using 5.3.0 and wanted to play around with 5.4.0. I noticed that when I changed the parent version in the pom.xml from 5.3.0 to 5.4.0, the hapi-fhir-jpaserver-base disappeared from the maven dependency list. Did I miss something? Thanks.

view this post on Zulip James Agnew (May 20 2021 at 09:30):

Hmm, that's weird - no, nothing like that should happen. Might be worth comparing your project with the current git master to see if there are any obvious structural changes missing

view this post on Zulip Joe Atterberry (May 20 2021 at 13:53):

Thanks. It was an IDE issue. I upgraded to latest version and all is well.

view this post on Zulip Matthew Dickie (Oct 19 2021 at 09:44):

Hi @James Agnew

I'm working on Instant OpenHIE development and I've noticed a missing DockerHub tag release - v5.4.2

We were using Pangolin v5.4.2 as it was available as the latest DockerHub release but since the latest tag was updated a few weeks ago (to v5.5.1) we are now dependant on a non-existent tag.

Could we please get this tag released on DockerHub?

Thanks,
Matt

view this post on Zulip Jens Villadsen (Oct 19 2021 at 09:48):

@Matthew Dickie are you talking about the HAPI FHIR jpa starter Docker image?

view this post on Zulip Richard Stanley (Oct 19 2021 at 10:06):

Yes.

view this post on Zulip Jens Villadsen (Oct 19 2021 at 12:24):

@Richard Stanley / @Matthew Dickie Here's an advice: Don't EVER depend on latest on anything. I can make a tag on https://github.com/hapifhir/hapi-fhir-jpaserver-starter/commit/83908242a5ce69618a955d2f89e4534bc86aab73#diff-9c5fb3d1b7e3b0f54bc5c4182965c4fe1f9023d449017cece3005d3f90e8e4d8 which then should trigger a deploy to docker hub. Is there any specific reason why you cannot use the 5.5.1 ?

view this post on Zulip Richard Stanley (Oct 19 2021 at 12:32):

Thanks @Jens Villadsen. I don't know @Matthew Dickie 's specific use for that release. But, indeed, point taken :) and I think that's the goal here.

view this post on Zulip Jens Villadsen (Oct 19 2021 at 14:15):

@Richard Stanley whats the goal? Not to depend on latest or to depend on v5.4.2?

view this post on Zulip Matthew Dickie (Oct 19 2021 at 14:15):

Thanks @Jens Villadsen
This is the repo: https://hub.docker.com/r/hapiproject/hapi/tags
We did not depend on latest willingly, but we needed some features quickly as we were blocked and we hoped the version would be tagged before a new latest image was pushed.

All our testing has been done on version v5.4.2 as that's the tagged version on GitHub with the changes needed.
We haven't tested our system with v5.5.1 and there's a production in-country deployment happening in two weeks so jumping to that version could be risky for us.
Is this minor version well adopted?

view this post on Zulip Jens Villadsen (Oct 19 2021 at 14:18):

@Matthew Dickie - you're linking to the docker repo - and that is fed from the gtihub repo. I terms of tags you need to differentiate between the HAPI framework and the HAPI FHIR JPA Starter. The starter project does not have a 5.4.2 tag: See image

view this post on Zulip Jens Villadsen (Oct 19 2021 at 14:22):

I would recommend that you use v5.5.1

view this post on Zulip Jens Villadsen (Oct 19 2021 at 14:23):

... - and when you say production @Matthew Dickie ... - do you intend to go to production with the HAPI FHIR JPA Starter stock image?

view this post on Zulip Matthew Dickie (Oct 19 2021 at 14:42):

@Jens Villadsen
This is my local docker image version of latest (pulled from the Dockerhub repo above):
hapi-version.png

If possible, we'd like the HAPI FHIR server version 5.4.2 on a docker image again for the remainder of our QA process. If not, we'll make a plan to use v5.4.1 or v5.5.1.

Preferably, we'd like to go live with server version v5.4.2 as that's what we know, but we haven't agreed on how we are going to deploy yet though.
If you have any suggestions, they would be most welcome.
The environment is two large servers in-country with Linux virtual machines for every service.

view this post on Zulip Jens Villadsen (Oct 19 2021 at 14:52):

@Matthew Dickie I'm a bit puzzled here - the HAPI FHIR JPA starter server sort of an example of what you can do with the HAPI FHIR framework - as such it is not really intended for production, IMHO. For starters, there are no security restrictions on it and no compartmental limitations in regards to access to data. I myself use it as a highly effective mock in test setups where I have to interface other FHIR servers - but not production without any modifications. Surely, it delivers a lot of capabilities but I wouldn't use it for production without adding a authorization layer. Am I missing something here?

view this post on Zulip Patrick Werner (Oct 19 2021 at 14:56):

I think there are a lot of users using the JPA-Starter-Server in production. I do it myself.
We are facading the endpoint with an oidc filtering layer in apache.

view this post on Zulip Matthew Dickie (Oct 19 2021 at 15:01):

@Jens Villadsen The HAPI-FHIR server will not have any ports exposed publicly - the only way to access it would be through an OpenHIM channel which requires authorisation.

view this post on Zulip Jens Villadsen (Oct 19 2021 at 15:19):

@Matthew Dickie - ok, so more like a guarded datalake. That makes sense. I'd still recommend you to use the 5.5.1

view this post on Zulip Jens Villadsen (Oct 19 2021 at 15:24):

@Patrick Werner how is OICD sufficient? How do you control that the queries executed against the server does not include resources that you are not allowed to read/write? The JPA starter does not evaluate whether what you are reading are according to the claims. I can't see how the OICD flow is nearly sufficient, unless the case is like @Matthew Dickie 's. Eg. if a user does a read on eg. Observation, how do you determine that the user is related to that Observation, in hindsight? That is what the https://hapifhir.io/hapi-fhir/docs/security/authorization_interceptor.html and https://hapifhir.io/hapi-fhir/docs/security/search_narrowing_interceptor.html are there for.

view this post on Zulip Patrick Werner (Oct 19 2021 at 17:50):

@Jens Villadsen my answer was a little bit too short/abstract &we are not using SMART ON FHIR. We are just having some roles which have access to the whole repo, filtering for write read operations and specific operations. We are also do some filtering with an Authorization Interceptor

view this post on Zulip Jens Villadsen (Oct 19 2021 at 17:53):

well in that case you're not using the stock docker image if you've added a HAPI AuthorizationInterceptor

view this post on Zulip Jens Villadsen (Oct 19 2021 at 17:53):

and FYI @Patrick Werner - we (my colleagues and I) are working on adding SMART evaluation as an option to the example implementation

view this post on Zulip Patrick Werner (Oct 20 2021 at 08:00):

Jens Villadsen said:

well in that case you're not using the stock docker image if you've added a HAPI AuthorizationInterceptor

yes. But we war relying on the jpastarter project.

view this post on Zulip Patrick Werner (Oct 20 2021 at 08:00):

Jens Villadsen said:

and FYI Patrick Werner - we (my colleagues and I) are working on adding SMART evaluation as an option to the example implementation

:hearts:

view this post on Zulip Jens Villadsen (Oct 20 2021 at 08:23):

Patrick Werner said:

Jens Villadsen said:

well in that case you're not using the stock docker image if you've added a HAPI AuthorizationInterceptor

yes. But we war relying on the jpastarter project.

There's a huge difference between using the JPA starter project as a kickstarter for doing own development and using the docker image. @Matthew Dickie is using the docker image

view this post on Zulip Jens Villadsen (Oct 20 2021 at 08:23):

Patrick Werner said:

Jens Villadsen said:

and FYI Patrick Werner - we (my colleagues and I) are working on adding SMART evaluation as an option to the example implementation

:hearts:

I know :wink:

view this post on Zulip Jens Villadsen (Oct 20 2021 at 08:25):

The hope/intention is to enable more users to think about the security model, having a SMART setup ready at hand. - and yes, it will also involve an example Keycloak / IdP - so a total docker compose setup, ready to run

view this post on Zulip Patrick Werner (Oct 20 2021 at 09:06):

wow

view this post on Zulip Peter Imrie (Oct 20 2021 at 10:42):

Jens Villadsen said:

Patrick Werner said:

Jens Villadsen said:

well in that case you're not using the stock docker image if you've added a HAPI AuthorizationInterceptor

yes. But we war relying on the jpastarter project.

There's a huge difference between using the JPA starter project as a kickstarter for doing own development and using the docker image. Matthew Dickie is using the docker image

Hi @Jens Villadsen out of interest, other than the security ramifications of not having authentication and straight http access, what would the concerns be regarding using the jpastarter Docker image in a production environment?

view this post on Zulip Jens Villadsen (Oct 20 2021 at 10:48):

Well - nothing.

view this post on Zulip Jens Villadsen (Oct 20 2021 at 11:14):

@Peter Imrie I find security pretty central when dealing with other peoples data

view this post on Zulip Peter Imrie (Oct 20 2021 at 11:24):

Jens Villadsen said:

Peter Imrie I find security pretty central when dealing with other peoples data

@Jens Villadsen For sure, definitely a key consideration. Just wanting to check there wasn't something else like a hard limit on record numbers or something like that.

view this post on Zulip Jens Villadsen (Nov 05 2021 at 15:10):

@Patrick Werner -> https://github.com/hapifhir/hapi-fhir-jpaserver-starter/pull/287

view this post on Zulip Patrick Werner (Nov 11 2021 at 10:32):

just saw this, but the PR was closed?

view this post on Zulip Patrick Werner (Nov 11 2021 at 12:57):

@Jens Villadsen

view this post on Zulip Jens Villadsen (Nov 11 2021 at 19:06):

I'll let @James Agnew comment on that

view this post on Zulip Jens Villadsen (Nov 11 2021 at 19:07):

@Patrick Werner may I suggest you try out the features of the PR by building https://github.com/trifork/hapi-fhir-jpaserver-starter/tree/feature/smart-support

view this post on Zulip Patrick Werner (Nov 12 2021 at 09:42):

Will have a look at the weekend.

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -