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

• [x] Port the existing fhir-ndr-et build tooling into a tools to create a generic fhir geneation service
• [x] 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. Without using AI, we should be able to:
  • Generate a test suite for each resource type
  • Create a very basic test like const result = builders.patient('patient', {}); expect(result).to.be.truthy
  • For each example we find for that resource, generate a SKIPPED test that creates the resource and asserts the value.
  • The tests are skipped because they'll fail without human intervention
  • This gives us a pretty cool stub test suite, which passes, but invites the user to come in and fill in the blanks and exercise the API
• 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

[josephjclark]

One annoying thing here is that the order of generated code is changing as a result of these changes. Simply because we iterate through the generated spec in a slightly different way.

I think I'll raise small PR against main which sorts keys in fhir-jembi-et but otherwise makes no changes, and release a patch. This shouldn't affect anything in our proof of concept (worth testing!), but will allow me to make a better diff against the generated source.

EDIT: This is done in #802