Lit: Yet another FHIR library
By Hugh Simpson, Felix Chapman, Greg McKay & Alexander Morley
Lit is a new FHIR® library. Specifically it is an implementation of the domain model of FHIR as opposed to implementing either the client or server specifications. That means it is a library for manipulating FHIR objects, not serving them or sending/fetching them from a server. It also has an implementation of the FHIRPath standard.
What is FHIR?
The HL7® FHIR® standard, typically referred to as just “FHIR” is, in the words of the HL7 body that created and maintains the spec: a “standard [which] defines how healthcare information can be exchanged between different computer systems regardless of how it is stored in those systems”.
What do you need FHIR for?
Babylon as a healthcare provider needs to store a variety of information about everything from consultation times to lab results to medical history — and we need that information to be readable in a consistent format both by an array of internal services, and by other healthcare providers with which we partner. The FHIR domain model is battle-tested for the vagaries of clinical data modelling, and we felt we would be fools not to take advantage of the lessons learned by others. On the other hand we don’t, for internally-facing systems, use the server or client APIs that the spec defines; nor do we directly interop with models prior to R4. Whilst it’s laudable that this aspect was considered in the specification, it doesn’t fit a lot of our use-cases — for example, we make heavy usage of streaming — so we wanted to take the advantage of the model, without the additional bloat and restrictions implied by the aspects we’re not leveraging.
Is this the first implementation of its kind?
No, otherwise “Yet another FHIR library” would have been a strange title. They are many existing FHIR libraries that all have their own strengths and weaknesses. And supported languages. And runtimes. And assumptions about data format. (And licensing too!)
So what did you want to do differently?
I’m so glad you asked. Here are the design goals of Lit:
- Simple
- Well typed
- Immutable
- Generated and extensible
- Metamodel
- Transformation and extraction
- Performance
- Multi-language support
I want to know more!
Great. Check out the repo. There’s a deep-dive article there too, including some comparisons with aforementioned existing implementations.
