Fhir 4 typescript

[josephjclark]

FHIR r4 adaptor with auto-generated typescript.

Replaces #909

This is a fully typescript implementation, so we get really good type definitions out of it, which gives us great code-assist support.

I am not using the npm fhir package for typings. It just doesn't work very well for us, and introduces a problem bundling for Monaco. Also it exposes _ variants of each property, for extensions. Which really pollutes the code assist.

Code assist is now provided in test files (which makes writing unit tests easier AND more lightning-like) as well as in Lightning. I've tested it locally, works great.

Major changes:

• Update jsdocs2md to support typescript docs. I think this was necessary but doesn't introduce any changes to existing adaptors
• This would be our first typescript-first adaptor. Cool.
• I have condensed the generated code to be more terse and permissive. Whatever the user passes in is spread into the result. So you can do whatever you like
• The builder signature now overloaded. You can do b.patient('Patient', { ...}) or b.patient({ ... }). Profile names aren't actually needed or useful here, but I want to keep API consistency with the IG adaptors. It works well.

Still do to before release:

• Add basic operations with fhir verbs - http, read, create, update, bundle
• I think I'll absorb the datatypes stuff into builders, so you can do b.concept, b.identifier.
• Properly extract meta and text properties from the generator, and let uses provide extension hooks for this in the mappings file DONE
• Manually write out a few tests for key types. This helps validates improvements
• Add a good docs overview and some examples to showcase best practice
• Fix docs for composite keys like deceased[x].
• Should we be a lot more restrictive in the builders we support? We include almost everything but maybe we should only include the medical stuff

Also note that this totally breaks the implementation guide generator. I'm tracking that in #955

Spin out issues to do later:

• Parse valuesets to allow auto-complete for basic types (like human name enums)
• Use valuesets to map simple string values to system/coded concepts
• Better support for extensions
• Allow job code to set mapping values. So that I can pass any arbitrary object to, eg, patient.identifier, and the mapping function will handle the mapping. Essentially we allow custom support for value mapping. This should make mapping to fhir MUCH easier

[josephjclark]

I'm a little bit disappointed by docs, but I think this is a problem for later.

Here's how generated docs look:

Issues:

• It's a really, really big page and quite slow to load
• There are no usage examples
• there's a LOT of repetition. Stuff like id, meta, text each written to each of the, uh, hundreds of generated types
• Types like HumanName aren't very useful. I should probably include those typedefs. Code assist should compensate but that doesn't help CLI users
• it's not at all clear when things can be arrays. Quite a lot of things can be, but we don't say so

Solutions?

• Put builders in a different page in the docs. Doesn't really help the size, but maybe stops the operations drowning
• Add some common typedefs and offload keys into them, so stuff like meta, id doesn't appear in every table
• Document allowed properties a lot more tersely. Probably doens't help.

[josephjclark]

Spun out a nice solution for docs in #987 . I don't think it's a big fix and I'll probably take a swing real soon.