Topics discussed:

• The date-time problem, stated cleanly: FHIR hands you a date, a dateTime, an instant or a Period, at whatever precision the source felt like, and a database wants one typed column. The proposal moved away from tagging columns with hints and towards adding floorInstant and ceilingInstant as FHIRPath functions — the reasoning being that once you've accepted getId you have already crossed the line into extending FHIRPath, so extend it honestly. It also removes the need for a type hint: an instant is fully specified, timezone and all, so it maps onto a database type without further help.
• Josh pushed for the functions to work on the polymorphic element directly — ask for the floor of Observation.effective rather than branching over dateTime and Period and unioning the results back together. That's a want for FHIRPath generally, not just for analytics, which is itself the argument for pushing it upstream rather than keeping it local; it had already been raised in the FHIRPath channel to see who else cares. This also clarified something the group had half-assumed: FHIR itself adds functions to FHIRPath, so doing the same for the analytics context is a well-trodden path rather than a transgression.
• Evan raised the sharpest objection: flooring is data erasure. In quality measurement, if a birth date is only 2023 you are not permitted to decide it is January 1st — and if one platform floors and another doesn't, plans start passing or failing measures according to their database vendor rather than their care. So the spec has to be explicit about whether this is a must or a should, and a view an engine can't honour should be an error, not a quiet approximation. The same principle bites on timezones: you cannot invent one for a bare year, so either preserve the source's timezone, take an optional parameter defaulting to UTC, or configure it on the runner — and a Period's start and end can each be partial, so you floor the start and ceiling the end.
• A union keyword was agreed in principle — it turned up as useful for date-times and again for unit conversions, which was taken as enough evidence it earns its complexity — with the semantics left to a written proposal. The open question is whether it needs an or-null variant like forEach does; nobody had yet hit a case needing a fallback, so the ask was for a use case to come with the proposal. A related ergonomic worry: if where becomes a keyword in the JSON, there are then two places to write the same filter, and having two ways to write every expression cuts against the whole point of the exercise.
• A proposal from outside the view layer: bulk export only defines NDJSON, and Parquet would serve analytics far better — but Parquet needs a schema, and a schema is precisely what the level-zero storage layer is. The suggestion was to recommend one based on SQL on FHIR v1, with open source tooling to convert NDJSON into it, rather than mandating an opinionated flat view. The counter-consideration: a recommendation plus good tooling can become the de facto standard on merit, and a standard imposed up front on something this opinionated probably won't.