Grahame Grieve
I'm just working on my presentation for the SQL on FHIR webinar, and I've found an aspect of my implementation that could be improved if there's a new feature in ViewDefinition. At present, the ViewDefinition nominates the resource type on which it's based. And my expression checker checks the expressions against the base resource definition.
That check includes a particular check that's quite useful: checking whether the expression for a column value can return more one value, and comparing that to the definition of the column
But that check would be more useful if the checker was informed by a profile on the resource. E.g. the base resource says that the base category element can repeat, but a profile says that it can only be 0..1 not 0..*.
The author knows that the profile applies, and the warning is not correct. But the machinery could get this right if as well as the resource type, the view definition could also nominate a profile for the resources it applies to.
I don't propose that the applicable profile acts as a filter like in a .where clause - that's computationally difficult, even if an implementer can link in validation like that. Just that the profile acts as a context for semantic checking of the definition, based on the assumption that the implementation will ensure that the profile is met somehow
NR: Good idea. I think we discussed that author can attach a list of profiles to view definition to communicate intention. But didn't agree on extra semantic of it like filtering or hints context for fhirpath.
I imagine that IG authors can compliment profiles with flat views and eventually "queries" and publish as part of IG ;)
https://chat.fhir.org/#narrow/channel/179219-analytics-on-FHIR/topic/Future.20Feature
Grahame Grieve I'm just working on my presentation for the SQL on FHIR webinar, and I've found an aspect of my implementation that could be improved if there's a new feature in ViewDefinition. At present, the ViewDefinition nominates the resource type on which it's based. And my expression checker checks the expressions against the base resource definition.
That check includes a particular check that's quite useful: checking whether the expression for a column value can return more one value, and comparing that to the definition of the column
But that check would be more useful if the checker was informed by a profile on the resource. E.g. the base resource says that the base category element can repeat, but a profile says that it can only be 0..1 not 0..*.
The author knows that the profile applies, and the warning is not correct. But the machinery could get this right if as well as the resource type, the view definition could also nominate a profile for the resources it applies to.
I don't propose that the applicable profile acts as a filter like in a .where clause - that's computationally difficult, even if an implementer can link in validation like that. Just that the profile acts as a context for semantic checking of the definition, based on the assumption that the implementation will ensure that the profile is met somehow
NR: Good idea. I think we discussed that author can attach a list of profiles to view definition to communicate intention. But didn't agree on extra semantic of it like filtering or hints context for fhirpath.
I imagine that IG authors can compliment profiles with flat views and eventually "queries" and publish as part of IG ;)