FHIR Chat · Normalization of search-parameters.json · implementers

Stream: implementers

Topic: Normalization of search-parameters.json

Jaime Olivares (Aug 17 2018 at 20:55):

We are using search-parameters.json as a base for generating search filter pages in the UI. So far so good with one exception. I will use the following case, trimmed for the sake of simplicity:

      "resource" : {
          "resourceType" : "SearchParameter",
          "id" : "medications-code",
          "url" : "http://hl7.org/fhir/SearchParameter/medications-code",
          "name" : "code",
          "date" : "2018-07-05T19:08:58+00:00",
          "description" : "Multiple Resources: \r\n\r\n* [Medication](medication.html): Codes that identify this medication\r\n* [MedicationRequest](medicationrequest.html): Return prescriptions of this medication code\r\n* [MedicationAdministration](medicationadministration.html): Return administrations of this medication code\r\n* [MedicationStatement](medicationstatement.html): Return statements of this medication code\r\n* [MedicationDispense](medicationdispense.html): Returns dispenses of this medicine code\r\n",
          "code" : "code",
          "base" : ["Medication",
              "MedicationRequest",
              "MedicationAdministration",
              "MedicationStatement",
              "MedicationDispense"],
          "type" : "token",
          "expression" : "Medication.code | MedicationRequest.medication.as(CodeableConcept) | MedicationAdministration.medication.as(CodeableConcept) | MedicationStatement.medication.as(CodeableConcept) | MedicationDispense.medication.as(CodeableConcept)",
          "xpath" : "f:Medication/f:code | f:MedicationRequest/f:medicationCodeableConcept | f:MedicationAdministration/f:medicationCodeableConcept | f:MedicationStatement/f:medicationCodeableConcept | f:MedicationDispense/f:medicationCodeableConcept | f:MedicationStatement/f:medicationCodeableConcept | f:MedicationRequest/f:medicationCodeableConcept | f:MedicationDispense/f:medicationCodeableConcept | f:MedicationAdministration/f:medicationCodeableConcept",
          "xpathUsage" : "normal"
      }

Here the parameter medications-code can be applied to several resource types, as detailed in the .base array. Now the way as .description, .expressionand .xpathare formatted is inconsistent and not machine-friendly. I would easier and safer to process if they are arrays rather than using \n and pipe separators.

Grahame Grieve (Aug 17 2018 at 20:57):

.expression and .xpath are both valid expressions that don't need any more processing than running in either and xpath or a fhirpath engine

Jaime Olivares (Aug 17 2018 at 21:02):

I am focusing on the way they are formatted (with pipe) rather than a more json-ish way (array or even object), which is easier to consume. Now, regarding your comment that "don't need any more processing than for xpath or fhirpath", that's excluding implementers looking for mining that information in new ways, and not only for the use-cases you have already considered.

Lloyd McKenzie (Aug 17 2018 at 21:04):

XPath and FHIRPath are languages. The FHIR spec doesn't control how they look. There's nothing "JSON" about them. XPath doesn't even run on JSON instances...

Grahame Grieve (Aug 17 2018 at 21:04):

ok what kind of uses do you have in mind?

Jaime Olivares (Aug 17 2018 at 21:06):

@Grahame Grieve We already do it: We use this file as an input for a form generator 'Filter Form' based on the resource type. It works pretty well.

Grahame Grieve (Aug 17 2018 at 21:07):

well, I do that too; that's an expected use. so I see the issue with description, which I don't mine into the form. but not the xpath or expression

Jaime Olivares (Aug 17 2018 at 21:07):

@Lloyd McKenzie the json file can contain the information in any format. it can be x-path or fhirpath or something more agnostic. The array would be more agnostic.
Regarding the description, I guest that verbose format does'n t correspond to any 'language'.

Jaime Olivares (Aug 17 2018 at 21:10):

@Grahame Grieve OK, let's start with description, I don't think it is defendable. Where would you show such a big text? It can be split into individual descriptions for each resource type.

Grahame Grieve (Aug 17 2018 at 21:11):

well, for form use, no, it's not suitable. It's documentation of the search parameter as a whole. I'm just looking at search parameter thinking about this

Grahame Grieve (Aug 17 2018 at 21:13):

The markdown in these cases is highly controlled (all generated) so you can parse it. but that's pretty yuck. I could generate it differently to make it easier to parse but then it doesn't present nicely, and it's still yuck.

Grahame Grieve (Aug 17 2018 at 21:13):

it's too late to add something to search parameter itself, but I could generate an extension for this

Jaime Olivares (Aug 17 2018 at 21:14):

It can be an array of markdowns. Everybody happy.

Grahame Grieve (Aug 17 2018 at 21:15):

you'd still have to parse each to figure out which one you wanted.

Jaime Olivares (Aug 17 2018 at 21:16):

I see two alternatives: An array with the size and order of the .base array, or an object with key=resourcetype, value=description_markdown

Brian Postlethwaite (Aug 17 2018 at 22:13):

An additional extension for "Label" would be useful for that to explicitly indicate that its a user interface label for the field.

Brian Postlethwaite (Aug 17 2018 at 22:15):

I don't expect you'd need anything else?
(some of the servers generically implement their search systems based on the existing data - with the exception of the geo location stuff)
Apart from choosing a specific UI label for the field(s) the only part not present is the layout/ordering, and don't know that is something that the server is responsible for. But could just assume that its the order on the capability statement.

Grahame Grieve (Aug 17 2018 at 22:19):

that's how I render them

Jaime Olivares (Aug 20 2018 at 04:09):

Please let me know if I can help on this.

Last updated: Apr 12 2022 at 19:14 UTC