fhir v4

[josephjclark]

WIP PR for fhir 4 adaptor support

• Download the fhir 4 spec and generate a basic adaptor
• Implement a full suite of datatype builders, with tests
• Add tests for each datatype and tune the APIs
• Generate tests with examples?
• Generate fhir verbs API? read search etc?
• Implement full and proper extension support? Can I even do this with the base?

AI Usage

Please disclose how you've used AI in this work (it's cool, we just want to know!):

• Code generation (copilot but not intellisense)
• Learning or fact checking
• Strategy / design
• Optimisation / refactoring
• Translation / spellchecking / doc gen
• Other
• I have not used AI

You can read more details in our Responsible AI Policy

[josephjclark]

Bit of a false start this afternoon as it turns out that the core fhir definitions seem to use a different structure to the definitions downloaded from IG guides. But I figured that out and I've now managed to download the fhir 4 spec and generate a basic adaptor for it. I'll tune that up an get the basics submitted, then start working on improvements.

[josephjclark]

A good dev day today with improvements, plus some good news and mixed.

In brief I have:

• Restructured the output so that each profile has its own file. It's now possible to read the code, hurrah!
• Simplified (and complicated) builder signatures so that the profile is optional. You can now do b.patient({ id: 'joe' }) rather than b.patient('patient', { id: 'joe' }) . This needs some work to be properly compatible with IG guides with multiple profiles (we should default to the base profile)
• Added jsdoc annotations for each profile, so the builders are documented. Yay! This won't work on IGs with multiple profiles.
• Got code assist working in VSC on unit tests. This has been a bit of pain and does require testing against the built code.

There does seem to be an issue where once we've built to dist, the code assist in the test file breaks down. I need to investigate.

I seriously flirted with adopting a typescript-first implementation today. There are many benefits to this. The biggest reason NOT to is that I have to re-write most of the code generator to use the TypeScript AST (which has a horrible interface)

Also worth noting is one failing test which requires investigation.

Next steps, I think, are:

• Generate unit test stubs from examples (this is important to allow me to exercise the API)
• Build a set of operations for fhir compliance
• Work out what to do about extensions

I also think the basic datatype builders probably need work (and definitely testing).