Missing boundary functions in JS FHIRPath, and what sibling selects actually cross-join — Apr 17, 2024
Boundary functions the JS engine simply doesn't have
lowBoundary and highBoundary turned out not to exist in the JavaScript FHIRPath engine at all — no branch, no pull request, not even a GitHub issue discussing them. So the group decided to write them itself rather than wait.
The person who has started already hit the awkward part: telling a date from a dateTime, because the two look the same in the data and type inference reports both as string.
Sibling selects — cross-joined per resource, not across them
"Sibling selects are effectively cross joined" reads as though you run each select across all resources and then cross join the lot. In fact the cross join happens per resource.
— an implementer writing his own runner
The reply: this is exactly why the processing model page exists — it describes the algorithm rather than trying to say it in prose. But that page may not be prominent enough, and the main section probably needs the words too.
Nikolai's functional model — take it out of Zulip, put it in the spec
Writing the algorithm down in English is the hard part. The group has been discussing this for a year, so the current wording looks clear to us and may be clear to nobody else.
Explaining it to a designer with a technical background took days, and the four-functions version was what finally landed.
Getting to milestone one — a checkbox instead of the full HL7 machinery
Rather than run the full HL7 machinery — the IG publisher's qa.html checks, a ballot, formally resolving every comment raised — the group leaned to something lighter: a sheet where each member ticks off that they have actually read the spec and the tests and left comments.
The reason for the checkbox was admitted openly: everyone is busy with other things, and a name against a box is what makes people sit down and read. The pull of the HL7 route is that it reaches a broader set of people than this call does.
A C++ FHIR deserialiser at half a gigabyte per second
A C++ FHIR deserialiser built on simdjson reports around half a gigabyte per second, roughly six times faster than marshalling into Firely's object model. The suggested next step was to drop the structs entirely: simdjson only records where everything is, so FHIRPath could query that position table directly and never build an object.
The bigger prize is upstream — a million patients is a terabyte of JSON, while the slice a large measure actually reads is somewhere between 150 MB and a couple of gigabytes, which is what Parquet and predicate pushdown are for.