fhir: map primitive elements

[hunterachieng]

Summary

Add ability to map primitive elements in fhir by focusing on elements starting with an _.
Regenerated fhir-eswatini with tests to check behavior

• Ensured we do not throw away primitive elements in generate-schema then mapped by checking if the parent has an extension.

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

Review Checklist

Before merging, the reviewer should check the following items:

• Does the PR do what it claims to do?
• If this is a new adaptor, added the adaptor on marketing website ?
• If this PR includes breaking changes, do we need to update any jobs in
  production? Is it safe to release?
• Are there any unit tests?
• Is there a changeset associated with this PR? Should there be? Note that
  dev only changes don't need a changeset.
• Have you ticked a box under AI Usage?

[josephjclark]

Maybe a bit of confusion over whether we're handling primitve types or primitive extensions? I'm expecting that primitive types work already, and we're just adding support for extensions here

[josephjclark]

Nervous about this diff! This looks unrelated to the work. And I think all the types here are actually broken?

[hunterachieng]

@josephjclark I used this command to regenerate the schema pnpm generate-fhir fhir-eswatini --respec could this be the cause of the changes? Because I got this error when testing and I had to export it from builders in fhir-4
TypeError: dt.ensureConceptText is not a function

[josephjclark]

Strange 🤔

When I rebuild from the root I also get strange type errors and wierd syntax. When I go into the adaptor folder and do pnpm build:src --respec, I get different output.

The two commands really should be aliases of each other. I fear some path has gotten misaligned and is doing wierd things.

if you go to main and run pnpm build:src --respec from inside the adaptor folder, what happens?

[hunterachieng]

@josephjclark It is only this that is updated "adaptorGeneratedDate": "2026-05-27T13:18:19.262Z",

[josephjclark]

That's what I get too.

So I think we have a bug when generating from the repo root. Or maybe it's a bug when generating inside the folder. Either way that needs investigating.

Maybe you can run pnpm build:src --respec on this branch and commit the changes - that should resolve some of the issues I see on this PR.

[josephjclark]

You mean the primitive extension no longer gets added? The test fails?

[hunterachieng]

It is not added, and the tests fail. I had to skip them

[josephjclark]

Don't skip them - if tests are failing its because something is broken. They should fail in CI until we fix the problem.

Something seems very messed up here. I'll try and take a look tomorrow but if I can't, it'll be Monday before I can investigate.

npm generate-fhir fhir-eswatini --respec and pnpm build:src --respec should be exactly the same command. I'm really nervous that we seem to be getting different behaviours. Can you try and investigate what might be different when running the commands?

There's no magic here, just code. All the answers are in this repo .

I suspect something is wrong on main, and we need to update fhir-eswatini on a branch off main first, and then rebase your work here onto that branch. That would help me understand what's wrong on main, and what you've added on this PR. That will make my review a lot easier.

[hunterachieng]

Sure. On it

[hunterachieng]

@josephjclark using npm generate-fhir fhir-eswatini --respec does not work. It flags that npm error Missing script: "generate-fhir"
When I try with pnpm when inside fhir-eswatini, I get these changes

[josephjclark]

Quite nervous about this cahnge too