A JavaScript decimal limit the group decided not to work around, and why sorting a ViewDefinition makes no sense — May 17, 2024

The boundary functions ran into JavaScript itself

Numbers are 64-bit doubles, so you get about 16 significant digits, while FHIR decimals need more. Rather than build a separate fixed-point decimal, the group decided to treat it as a known issue in the JavaScript FHIRPath engine and fix it upstream.

The reference implementation is allowed to fail that test — better than every other implementation inheriting the bug.

The rule that flows from it

The tests assert what the FHIRPath specification says, not what the JavaScript engine does. The reason field already in the test framework covers the rest — you record why a test is skipped instead of inventing an excluded status — and the implementation dashboard should surface that reason rather than showing a bare fail.

Sorting inside a ViewDefinition — left out

A proposal to add sorting, carried over from data requirements, which have sort and limit.

The objection: a ViewDefinition sees one resource at a time, so sorting inside one resource is easy but useless, and sorting the output table is out of scope — that is what SQL is for.

If sort and limit belong anywhere it is on a future operation that materialises a view, since they flex at runtime while a ViewDefinition should be static.

The gap in the narrative

People arrive assuming a ViewDefinition is SQL in FHIR language — an easy mistake to make, and partly the spec's fault for talking in end-to-end use cases.

The scope is one resource at a time, no joins, no cross-resource anything. It is a building block you then build your SQL on. An issue was logged to state the non-goals explicitly.

Parquet — concrete next step

Rather than abstract: pick one resource — Patient, or US Core Patient so extensions are in play — have everyone who has done this share their actual Parquet schema before the meeting, and expect maybe 80% to agree, so the discussion can go straight at the 20% that does not.

The original SQL projection document is the common ancestor of the existing implementations, so it serves as the shared baseline.