-
Notifications
You must be signed in to change notification settings - Fork 8
Evaluation of Hapi as a FHIR Server
This is a quick evaluation of using the Hapi FHIR server as the base server for Intervention Engine. While Intervention Engine tries to use "plain" FHIR, or FHIR without any profiles.
Hapi is a Java-based implementation of FHIR. The project generates its representation of FHIR using a tool called Tinder. Tinder is a plugin for the Maven build system that appears to be independent of the HL7 FHIR tool chain. Tinder has a copy of the FHIR spreadsheets in its repo that it uses.
Hapi stores FHIR objects in a relational database. The database is comprised of two main tables. One table is used to represent resources in blob format. The other is used for search facets, where individual pieces of data from the resources are pulled out so that they can be used for search.
Hapi interacts with the relational database using JPA. For the search facet table, it may result in multiple tables in the database depending on the type of the data being faceted. I just couldn't tell by the JPA annotations.
Hapi has very good support for the FHIR specification. Per the Crucible tests, it is one of the best servers as defined by compliance to the FHIR specification. It has support for chained queries, which can be useful when trying to do complex queries with plain FHIR.
While the FHIR search capabilities of FHIR are present, they appear to have some issues that would impede use in Intervention Engine.
The first issue has to do with performance. Based on my reading of the Hapi source code, it appears that when searching, each criteria for a search is executed somewhat independently. The initial search criteria is applied to the search facet table. This returns a list of candidate resource ids. The next search criteria is then applied with an IN query scoping down the list of potential resources. This repeats until the search criteria have all been accounted for. This slows queries where there are multiple criteria. It may also be unworkable in a large database, where thousands or millions of resource IDs may be returned.
Supporting the population queries that Intervention Engine currently uses will be very difficult with Hapi. Resources cannot be queried directly since they are stored as blobs. Using the search facets tables will require multiple self-joins that will be cumbersome, if even possible, when using JPA. Even if we were to hand code SQL (and risk divergence with the Java code), it will likely be very difficult to replicate the current population filtering features.
Hapi is not a good fit for Intervention Engine. It will be too costly, if even possible, to replicate the population filter features.
Hapi may be a good pure FHIR server. Anyone considering using Hapi as a base server for their application should do a more thorough investigation into the performance characteristics of the search implementation.