FHIR Search Parameters

Context

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

Open Questions:

• 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 value 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?

Conformance Profiles

(DavidHay)

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)

eg

 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)

Grahame's responses:

• 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?