Epic: Fhir Adaptor Generation

[josephjclark]

I may or may not break this down into smaller issues, but here's what needs to be done with the fhir adaptor auto-generation

• [ ] Port the existing fhir-ndr-et build tooling into a tools to create a generic fhir geneation service
• [ ] Re-generate fhr-ndr-et with the new tooling. There should be no diffs in src (there will be diffs to build (which goes) and package.json
• [ ] Use the new tools to generate a new fhir-4 adaptor (with hand written datatype builders and probably hand-written CRUD operations)
• [ ] Re-base the fhir-ndr-et adaptor on top of the new fhir-4 adaptor, so that imports datatype builders. This will result in many diffs and a minor version bump

At this point we have a generic fhir adaptor generation command which can work from any spec bundle (the thing linked from the jembi IG - I'm not sure yet precisely what this bundle is called).

Next steps then are all about improving this generation for better quality, more flexible adaptor generation, from more input sources

These steps I expect to spin out into separate issues:

• Generate adaptors from different inputs. We should be able to generate straight from a fhir github repo, and maybe from fhir-packages. Just give us a URL to any representation of your fhir implementation and we'll generate an adaptor
• Use differentials, rather than snapshots, to generate implementation adaptors. This means we import a generic Resource definition from fhir and build that, and then only generate code for the diffs (the extra constraints and extensions). This will result in significantly smaller adaptor source files
• When generating a base fhir adaptor (eg for r5), generate stub builder functions for the datatypes and operations. I think these will always have to be hand-written, but we should be able to programmatically template and scope exactly what needs to be manually implemented.
• Generate unit tests for an adaptor based on examples found in the spec (do we need AI for this?)
• Fix the docs. Our docs.openfn.org should describe every profile's object type in detail - because the reference and our API aren't actually 1:1, and the reference is quite hard to read and convert to our JSON input representation. We should just have flat docs for everything. I think it's hard to do this well under our current docsite, but first step is just to get the information up there

[josephjclark]

CC @aleksa-krolls - I've almost finished the first step