FHIR Search Parameters
Search parameters are defined in two different places
- in the specification itself, with a name, a type and a short description of the what the parameter searches for.
- in a conformance profile, where systems declare the actual parameters they support
- are systems obligated to support all of the parameters defined in the spec? some of them?
- do systems just add their own? is there any prefixing to make that safe?
- Grahame's test implementation preforms transitive searches, where if a resource has a parameter x : Resource(Y), then you can either search x=id, or x.z = value, where z is a search parameter of y. this is useful but can be... challenging.. for performance (I don't know if it will scale yet). Is this standard? expected? required?
- what is the significance of type? What is the expectations around searching for coded values?
- it supposed to be the same parameters for search and updates?
Working though the conformance document, I propose a couple of changes to the rest.resource.search.param and rest.resource.updates.param
I propose that the param elements each have 3 sub elements:
name title (a short title to display against the input element) documentation (a longer 'help' type message)
param.name : name param.title : Patient Name param.documentation : Will return any patient with the search string in any part of their name
This would allow for auto-generated screens that have a compact layout, but built in support.
(Also, for consistency, 'updates' should be the singluar - update)
- how far do you go? Grouping elements? screen layout hints?
- system assisted keyboard look up for possible values?
- this is a little world to itself..... seems like too much?
DH: Always a tricky one. However, we should be consistent with whatever it decided eg: the <param> child of <updates> should have the same children as <search><param>:
<updates> <param> <name></name> <documentation></documentation> </param> </updates>