Next eswatini FHIR

[josephjclark]

Overview

This PR:

• Allows string values to map to Coding structure in FHIR - ie, PI can expand to { coding: [{ code: 'PI', system: '...' }] }
• Updates the coding datatype in fhir-4 to accept a single argument structure
• Allow simple constructors for resources with a single profile. So b.patient({}) works, you don't have to do b.patient('SzPatient', {})

Cool things we can do now

Patient.identifier.type

// vanilla
b.patient({
  identifier: [
    {
      use: 'usual',
      type: {
        coding: [
          {
            system:
              'https://hapifhir.eswatinihie.com/fhir/CodeSystem/SzPersonIdentificationsCS',
            code: 'MR',
            display: 'Medical Record Number',
          },
        ],
      },
      system: 'http://mfl.sys/m001',
      value: 'M002111111-11',
    },
})

// with adaptor
b.patient({
  identifier: [
    {
      use: 'usual',
      type: 'MR',
      system: 'http://mfl.sys/m001',
      value: 'M002111111-11',
    },
})

Encounter.class

(note that the IG maps to over 1000 values from base fhir-4, plus like 4 values from the Eswataini IG. I've only mapped the 4 value - I need to go back and support the 1k in fhir-4 but the scale is kinda hard)

// vanilla
b.encounter({
  class : {
    system : "http://172.209.216.154:3447/fhir/CodeSystem/SzEncounterClassificationCS",
    code : "OPD",
    display : "Out Patient Department"
  },
})


// with adaptor
b.encounter({
  class: 'OPD'
})

Details

This PR updates the eswatini and fhir-4 adaptors with the ability to map to values defined in valuesets via a shorthand syntax - so a simple string PI can expand to { coding: [{ code: 'PI', system: '...' }] }

What I particularly like is that the design of this means the mappings are soft-coded into the adaptor and can be updated by users. The generated adaptor will load a default set of value maps from the IG, but users can extend and map this from job code for big productivity wins.

What I've done:

• Parsed the IG to extract values from valueSets and save them to a schema file
• Updated the fhir-4 base datatypes to use mappings when available
• Update the code generator to a) use datatype builders more and b) pass in mappings to the correct value sets in the right place

What I still need to do:

• Apply this mapping logic to all datatypes, not just identifiers
• Load the mapping values into the adaptor (I've hard coded the map for a test, but the information is available to laod properly)
• Test more cases against the IG
• Generate typings to support mapped codes
• Generate docs to list mapped codes (don't generate docs - just link to the values)

Future Work

• For some mappings, like the Inkundla codes, the display value is actually easier to use than the coding (which is just a number). So we should either allow inversed mappings on some values (driven by mappings.js), or maybe we have a generic rule which says "the code or display will be used as the mapping key - we'll try both)

AI Usage

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

• I have used Claude Code
• I have used another model
• I have not used AI

You can read more details in our
Responsible AI Policy