Bashir Sadjad

Update: what I meant by FHIRPath constraints was, for example, like this: ``` qr.select(         {             "id": qr.id,             "answer1_0": qr.item.where(qr.item.linkId=='1.0').answer.first().value.ofType('coding').code,         }     ) ``` This works and the advantage is that it...

Update: The mentioned bug with `qr.item.item` was fixed by [this commit](https://github.com/google/fhir-py/commit/1cf87972f889be66e55365c19b832018b30e4c79) (thanks to @rbrush) but then the current Spark runner implementation failed at generating proper SQL for constraints on `qr.item.item`....

Just to clarify re performance: A major concern is the `GROUP BY` part which is not really required to achieve what we are doing here; i.e., all `answer` elements should...

Besides the solution offered above, now with the [ViewDefinition support](https://github.com/google/fhir-data-pipes/issues/821) we can create flat-views directly from the original `QuestionnaireResponse` resources (with FHIRPaths to extract `item` and `answer` at arbitrary levels)....

Thanks @jjtswan for filing this. Re. the first goal, what does FHIR-views have to do with performance targets? Also another goal could be that we add some sort of simple...

We will do this after Beta launch.

Marking this as P3 until we make a decision on whether we want to continue maintaining `activePeriod` as a feature. If we do, there are also other improvements we need...

Prior performance evaluation work is available [here](https://docs.google.com/document/d/11S7FwhxwuooSfJZl-_MEghF5b1Ki7gu0a6wqvAk5d1U/edit?resourcekey=0-uBtQjehEcw-3_9w8Xpa6mw); this exercise should cover cases not well-covered in the old one.

Actually the guard that I mentioned in the above description is fine (not a "hack"). This way we keep `ProfileProvider` interface simpler and leave it to the implementations to decide...

/gcbrun