This wiki has undergone a migration to Confluence found Here

Difference between revisions of "FHIR Search Parameters"

From HL7Wiki
Jump to navigation Jump to search
Line 47: Line 47:
     <param>  <!-- 1..* search params supported -->
     <param>  <!-- 1..* search params supported -->
     <name><!-- 1..1 string name of search parameter --></name>
     <name><!-- 1..1 string name of search parameter --></name>

Revision as of 23:35, 19 June 2012


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


Working though the conformance document, I propose a couple of changes to the and rest.resource.updates.param

I propose that the param elements each have 3 sub elements:

 title (a short title to display against the input element)
 documentation (a longer 'help' type message)

eg             : 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?

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>: