fhir4: things I'm breaking

[josephjclark]

I am rebuilding the fhir adaptor generator to specialise in fhir4.

This is making me break regular fhir generation from an IG. For a couple of reasons:

• The base fhir spec has a different format to the IG. I don't really understand this - surely fhir is fhir? but the Ig and the base spec are packaged very differently
• A base fhir adaptor has a few different assumptions about where types come from

As a result, I'm introducing the following problems which will all need fixing before we can generate from an IG:

• signatures now support a simple format b.patient(props) which uses a default profile, but also you can specify a profile b.patient'inbound-patient', props).
• The typings I've done in these builders assume only a single profile. For multiple profile support, I need to do some fancier type stuff. Basically I need to union all the variants and also lookup the matching type from the string. I've done this in the IG already, I just need to rebuild that stuff into the generator
• more I'm sure??

Also, a quick reminder, we need to do further work once all this i done:

• When generating from an IG, we need a "base" adaptor (defaulting to r4). We should:
  • import data types from the base
  • In the builders, call the base resource buillder first, and then only apply diffs from the differential in the spec.

[josephjclark]

I need to spin out mappings and extensions to different issues.

It's taking a long time to get fhir working in typescript. I'm close now and want to get that released.

data values would be incredibly useful - for example, to provide completions on name usage or gender. All the data is available to do this.

Even more useful is shortcuts for complex values -I don't have a good example to hand but eg the simple string M can expand to { value: 'male', code: 'blahblah' }. Again, we have all the data fhir to do this.

Even better would be generic value mappers. So I could do something in job code to auto-map vales. Like we provide a function once to map incoming name objects to FHIR name objects. Now I can pass an upstream name object straight into the builder and let it automap. IG guides can't do this because they only provide one side of the mapping. But I'm sure we should be able to allow jobs to define mapping rules (or helper functions).

The other area is extensions, which need a bit more work. I would like builders to use a key like religion and use that to auto-map the incoming value into the correct extension structure. Job code then just has to provide the value (and maybe we can take advantage of value maps and custom mapping to allow this to be properly converted)

[josephjclark]

One thing that doesn't work so well is the typedproperties like deceased[x], which can expand to deceasedBoolean and deceasedDateTime. the builder works great, but docs don't really work