Handle FHIR Objects with Typescript (and Javascript)

You’re using FHIR, you choose Typescript because you want to deal with fully-typed entities. So, take a look at @ahryman40k/ts-fhir-types !

Why use io-ts ?

Typescript can statistically analyze your code, by compiling it to JavaScript and throwing errors while doing it, if it sees something wrong with the way that the types are defined. However, being able to check types at runtime would be great and advantageous as well, since untyped data can come in from various different sources and cause unwanted effects on your code. The Typescript compiler cannot know what kind of data is coming from a REST API endpoint or a JSON file for example, it can only define the structures that are expected at compile-time. This is where Giulio Canti’s io-ts library comes in. You can see more here.

Thus, @ahryman40k/ts-fhir-types exposes: io-ts definitions, objects interface definition of all scalars and resources and enums defined in FHIR R4 specifications.

Example

let imagine you’ve got a JSON data from your GraphQL or REST API. In the following example an Account resource:

Unless you define your own type for that FHIR resource (and its sub-objects) you have to deal with an any type and it can be a pain ! But a R4.resources.Account type is here to help.

Yes we have a fully typed object !

Runtime Type Information (RTTI)

Don’t we speak about Runtime Type Checking earlier ? Yes we do ! That’s why you can also find RTTI objects.

If checkResult isRight, it means JSON is compliant with the definition of a FHIR R4 Account resource, otherwise it’s left and it means something is wrong in you’re JSON definition (and you have to deal with errors). It helps us a lot until now !

Next Steps

To conclude, we now have a fully typed library that support the full R4 specification. It’s a step and it could help you to have additional functionalities, please let me know that on my GitHub project.