Stream: hapi
Topic: NPM Support in HAPI FHIR
James Agnew (Jun 01 2020 at 16:04):
Hi All- I'm working now on beefing up package support to HAPI FHIR. (A bunch of the initial legwork was done by @Martin Zacho Grønhøj . Big shoutout for the fine work!)
I'd like to validate the approach we're taking to make sure this will be useful to people who are working with NPM packages. Essentially we're thinking the following:
- A new "package installation spec" will be present in the JPA server. It is defined by configuration, and is read only on server startup.
- In this spec you can define IG packages by any of the following:
- ID/version (meaning it will be fetched automatically from the FHIR package server at packages.fhir.org)
- URL to direct download
- Local file path
- The system will import the IG and optionally any dependency IGs. Importing happens into a set of dedicated database tables in order to provide permanent storage. The actual IG binary is stored in a Binary resource, and the individual conformance resources within it also get extracted into Binary resources (in order to allow people who are using externalized binary storage to take advantage).
- Once an IG is imported, it becomes available to the validator via a newly IValidationSupport module. We don't load the whole IG into memory in order to save space, but the usual caching tier in front of the validation support module will cache these resources too and performance seems pretty good in my tests so far.
- Optionally, the conformance resources can also be loaded into the repository as resources (i.e. if the IG contained a StructureDefinition, that SD will actually be saved in the repo as a SD so it can be found using searches/reads/etc.). This step is optional since the validator can get at these resources without them being saved as resources in the DB.
- This same mechanism will also be usable for people who need to "pre seed" resources of other types into their repository. E.g. if you need a set of patients and observations automatically imported into every environment you build or something like that.
Would like to hear feedback from anyone who is developing against IG packages right now- would this meet your needs? Do you have other needs?
I'm hoping this will be merged in the next few days, would really love some early testing so we can get this feature right by the time august rolls around..
Grahame Grieve (Jun 01 2020 at 20:59):
there's some test data available via packages - fhir.test.data.r[v]. There's also an additional package that contains a bunch of terminology resources that we can't put in the base FHIR spec: fhir.tx.support
Grahame Grieve (Jun 01 2020 at 21:00):
@James Agnew note that it would be good to define a way to get the latest published version of a package without nominating a specific version. It might also be good to allow current as a version as well
Jens Villadsen (Jun 01 2020 at 21:08):
yep - support for WIP packages is highly needed
Jens Villadsen (Jun 01 2020 at 21:10):
What about the example resources that are part of IG? Where are they placed? Are they what you call "pre seed" @James Agnew ?
Oliver Egger (Jun 02 2020 at 08:39):
@James Agnew the npm support sounds awesome! we are using npm packages for StructureMap/StructureDefinition/ValueSet for the $transform operation where we don't need JPA at all but would be happy to migrate to the setup you describe. As far as I can see your description fits our needs.
Jens Villadsen (Jun 02 2020 at 08:42):
Would "pre seed" be anything that isn't Conformance/Terminology resources, with the subscription resource being an exception to that?
Last updated: Apr 12 2022 at 19:14 UTC
