Stream: implementers
Topic: Machine-readable definition of token search parameters
Paul Church (Aug 20 2019 at 16:32):
While working on the search parameters that use ContactPoint, it occurred to me that the table in the token search definition defining the URI/Code fields for various data types would be nice to have as a machine-readable definition.
It's not obvious from the structure definitions or search parameters that sometimes the code field is called "code" or "value", and back in DSTU2/STU3 the URI field might be "system" or "use" (really glad to see ContactPoint.use as a token system removed in R4). It also makes it difficult to create a framework for users to define custom token search parameters as they can't express how the token should work.
Perhaps the SearchParameter for a token could contain one expression/xpath for the URI and one for the code? If the URI expression is not present then it's an exact match on the code with no pipe character allowed in the query. This is a bit cumbersome because tokens are on data types that are used in many places, but I don't see a convenient way to annotate the data type itself.
Lloyd McKenzie (Aug 20 2019 at 17:19):
@Grahame Grieve @Ewout Kramer @Brian Postlethwaite
Grahame Grieve (Aug 20 2019 at 21:37):
I do not understand this; the name of the element on which the search parameter is based is explicit in the expression
Paul Church (Aug 20 2019 at 21:45):
The explicit element is an instance of a data type - the opaque part is inside the data type. I know telecom is a token search on "Patient.telecom" from the expression.
The knowledge that it is a token search with a URI of telecom.use (in STU3) and a code of telecom.value and a doesn't have .text or .display value - that information is only in the search spec.
Grahame Grieve (Aug 21 2019 at 19:33):
that's true. I guess I hardcoded that since there's also modifiers and qualifiers and stuff to prepare for. We can't fill out all the implications of that in a table
Last updated: Apr 12 2022 at 19:14 UTC
