Stream: committers
Topic: search parameters
Eric Haas (Jan 12 2017 at 15:51):
We have all these onesy twosy gforges to add search params here and there. Why not just automatically generate a search parameter for every element? I know we have a qa criteria and there are some twists to this but it seems a bit uneven right now with search parameters.
Lloyd McKenzie (Jan 12 2017 at 16:03):
I'd much rather see thought go into search parameter definition - and I think the 80% rule is important there. It's important for implementers to have a sense of what they can expect "most systems" to support (and what most systems will expect them to support too)
Brian Postlethwaite (Jan 23 2017 at 00:25):
The generator code that produces the "combined" logic search parameter expressions I believe is wrong.
PractitionerRole.telecom.where(system='phone') | RelatedPerson.telecom.where(system='phone') | Practitioner.telecom.where(system='phone') or Practitioner.role.telecom.where(system='phone') | Person.telecom.where(system='phone') | Patient.telecom.where(system='phone')
Is what is created for the Patient emailserch parameter.
(I don't like the merged expression, but I can get over that)
The or that is in between each of the expressions is wrong, that produces a boolean, it should be a | which performs the union.
Brian Postlethwaite (Jan 23 2017 at 00:29):
Interestingly this only occurs for email and phone search parameters (which are all PA resources)
Brian Postlethwaite (Jan 23 2017 at 00:42):
Correction, issue was mine in the Practitioner spreadsheet.
Grahame Grieve (Feb 06 2017 at 02:31):
so I will conclude that there's nothing for me to do here
Last updated: Apr 12 2022 at 19:14 UTC
