HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. We are an open community developing software licensed under the business-friendly Apache Software License 2.0. HAPI FHIR is a product of Smile Digital Health.
The HAPI FHIR Global Atlas is inspired by our friends at the OpenMRS project. We would love to add your project, company, or organization to the map. Learn more about how you can add yourself (or update/remove an existing entry).
This is the homepage for the HAPI-FHIR library. We are developing an open-source
implementation of the FHIR specification in Java. FHIR (Fast Healthcare Interoperability Resources) is a
specification for exchanging healthcare data in a modern and developer friendly way. Note that this is the
home for the FHIR version of HAPI. For HL7 v2 support, see
hapi-hl7v2.
Welcome to the winter release of HAPI FHIR! Support has been added for FHIR R4B (4.3.0). See the R4B Documentation for more information on what this means. Now onto the rest!
ActionRequestDetails
class has been dropped (it has been deprecated
since HAPI FHIR 4.0.0). This class was used as a parameter to the
SERVER_INCOMING_REQUEST_PRE_HANDLED
interceptor pointcut, but can be
replaced in any existing client code with RequestDetails
. This change
also removes an undocumented behaviour where the JPA server internally
invoked the SERVER_INCOMING_REQUEST_PRE_HANDLED
a second time from
within various processing methods. This behaviour caused performance
problems for some interceptors (e.g. SearchNarrowingInterceptor
) and
no longer offers any benefit so it is being removed.reindex-terminology
command.":nickname
qualifier only worked with the predefined name
and given
SearchParameters.
This has been fixed and now the :nickname
qualifier can be used with any string SearchParameters.Accept
header that matched the contentType
of the stored resource, the server would return an XML representation of the Binary resource. This has been fixed, and a request with a matching Accept
header will receive
the stored binary data directly as the requested content type.STORAGE_TRANSACTION_PROCESSING
has been added. Hooks for this
pointcut can examine and modify FHIR transaction bundles being processed by the JPA server before
processing starts.$meta
operation
against the deleted resource, and will remain if the resource is brought back in a subsequent update.Accept
header._outputFormat
parameter was omitted. This behaviour has been fixed, and if omitted, will now default to the only legal value application/fhir+ndjson
.[fhir base]/Patient/[id]/$export
, which will export only the records for one patient.
Additionally, added support for the patient
parameter in Patient Bulk Export, which is another way to get the records of only one patient.$poll-export-status
endpoint so that when a job is complete, this endpoint now correctly includes the request
and requiresAccessToken
attributes.$export
operation receives a request that is identical to one that has been recently
processed, it will attempt to reuse the batch job from the former request. A new configuration parameter has been$mdm-submit
can now be run as a batch job, which will return a job ID, and can be polled for status. This can be accomplished by sending a Prefer: respond-async
header with the request.$reindex
operation failed with a ResourceVersionConflictException
the relatedResourceVersionConflictException
during the $reindex
operation. In addition, the ResourceIdListStep
was submitting one more resource than expected (i.e. 1001 records processed during a $reindex
operation if only 1000
Resources
were in the database). This has been corrected.upload-terminology
operation of the HAPI-FHIR command-line tool. You can pass the -s
or --size
parameter to specify
the maximum size that will be transmitted to the server, before a local file reference is used. This parameter can be filled in using human-readable format, for example:
upload-terminology -s \"1GB\"
will permit zip files up to 1 gigabyte, and anything larger than that would default to using a local file reference.import-csv-to-conceptmap
command in the command-line tool successfully created ConceptMap resources
without a ConceptMap.status
element, which is against the FHIR specification. This has been fixed by adding a required
option for status for the command.reindex-terminology
command.DocumentReference
with an Attachment
containing a URL over 254 characters
an error was thrown. This has been corrected and now an Attachment
URL can be up to 500 characters._include
and _revinclude
parameters in the JPA server has been streamlined, which should
improve performance on systems where includes are heavily used.reindex-terminology
command.":text
qualifier was not performing advanced search. This has been corrected.MAP_TO
properties defined in MapTo.csv input file to TermConcept(s).$mdm-submit
can now be run as a batch job, which will return a job ID, and can be polled for status. This can be accomplished by sending a Prefer: respond-async
header with the request.reloadExisting
attribute in PackageInstallationSpec. It defaults to true
, which is the existing behaviour. Thanks to Craig McClendon (@XcrigX) for the contribution!A public test server can be found at http://hapi.fhir.org. This server is built entirely using components of HAPI-FHIR and demonstrates all of its capabilities. This server is also entirely open source. You can host your own copy by following instructions on our JPA Server documentation.
Commercial support for HAPI FHIR is available through Smile CDR.
HAPI is designed with one main intent: providing a flexible way of adding FHIR capability to applications. This project was originally developed at University Health Network to allow UHN to build up a system of unified FHIR services to expose data backed by a number of systems and repositories. It is designed to be flexible and composable above all else.
Use the HAPI FHIR parser and encoder to convert between FHIR and your application's data model.
Use the HAPI FHIR client in an application to fetch from or store resources to an external server.
Use the HAPI FHIR server in an application to allow external applications to access or modify your application's data.
Use the HAPI JPA/Database Server to deploy a fully functional FHIR server you can develop applications against.
We are on a mission to improve global healthcare. We know that we can't do it alone though! HAPI FHIR thanks all of these amazing organizations who have sponsored HAPI FHIR development, helped out with infrastructure, or otherwise helped us keep the lights on.