Opinionated library for easily constructuring FHIR resources in Scala and Java.

Supports generating Scala and Java from FHIR v4.0.1 structureDefinition and valueSet jsons, with extremely naïve support for transforming from the model at Google's open-sourced FHIR stuff. (this support basically just goes via json and is nice if you have compatability concerns or a need for protobuf, but otherwise is best avoided)

About Lit

Examples

We're published on maven central. There are various libs availaible, and what you want or need will depend on your use case. Generally, you'll want the 'basics', which is available as

"com.babylonhealth.lit" %% "hl7" % "0.14.6"

"com.babylonhealth.lit:hl7_2.13:0.14.6"

Should be convertable if you know your dependency manager.

• core: The minimal subset, if you want to use the spec's extension modelling. Most users should use hl7.
• hl7: the expected dependency
• usbase: Mostly extensions. Support for this appears nice, but has some performance implications. You may want it if you're dealing with 'meta' fhir
• uscore: Adds some useful stuff to the base for FHIR. You may very well want this dependency. Consider using hl7 alone first -- check your business requirements.
• ukcore: Includes models from the NHS's FHIR UK Core API Standards.
• *_java: Like their scala counterparts, but with some builder methods to make handling construction less painful, and some enum aliases to make construction of them have fewer $ signs. There are some additional serde utils available in LitUtils
• fhirpath: A reasonably complete FHIR path interpreter
• protoshim: In case you want to convert between domain models and proto. Fairly experimental
• macros/common: It's extremely unlikely you'll want either of these in isolation. The macros module enables the the with${FOO}/update${FOO}/with${FOO}IfExists syntax for scala 2 dependencies (and transitively Java, which for the time being depenends on this because the functionality isn't AFAIK replicable in scala 3). The common module is a very small number of utility functions shared between the generator and the generated code, and arguably shoudldn't exist.
• generator: For when you have json representing your own profile definitions, and want to generate a class model along the same lines as the pre-rolled modules here. Currently requires that you also specify an explicit dependency on the 'common' module because of some shenanigans around published versions.

Please make a new issue!

First you may want to generate the classes:

make build-all-class-models

Then you can run the tests:

make test

• We release via github actions, and all releases should be basically traceable. The first couple of versions are a bit wonky because we were figuring out the release process, but everything public was ultimately released via github actions.

• Better support for protobuf models (current approach just round-trips through json, which is slow)
• Support future versions of FHIR spec (In progress)
• Better support for slices
• Support for typescript and python (Rust now more interesting)

Hugh Simpson ([email protected])

Felix Chapman ([email protected])

Greg McKay ([email protected])