FHIR Chat · Searching without prefixes · implementers

Stream: implementers

Topic: Searching without prefixes


view this post on Zulip Stephen MacVicar (Aug 09 2021 at 17:49):

Does the base FHIR specification require support for search without prefixes? This issue came up in the context of US Core and whether a server can require that prefixes be used for the date searches it contains (https://jira.hl7.org/browse/FHIR-33156).

The section on Prefixes (https://www.hl7.org/fhir/search.html#prefix) says:

For the ordered parameter types of number, date, and quantity, a prefix to the parameter value may be used to control the nature of the matching.

To me, "may be used" means that prefixes are optional for the above types.

The section on quantity searching (https://www.hl7.org/fhir/search.html#quantity) explicitly states, "The prefix is optional," but the descriptions for number and date searching do not. My assumption is that the fact that similar language is not present in the sections on number and date searching is not intended to suggest that the prefixes are not optional for these types.

If prefixes are optional, does that mean a server is required to support searching without a prefix?

view this post on Zulip Eric Haas (Aug 09 2021 at 18:14):

(deleted)

view this post on Zulip Eric Haas (Aug 09 2021 at 18:42):

In the past, we had a couple of trackers and discussions on how to define the modifiers in the base SearchParameter resource vs an IG. But looking back I think it is still unclear and we should say something more explicit like "these modifiers are all optional and you need to state which ones you support in a capability statement".

view this post on Zulip Eric Haas (Aug 09 2021 at 18:47):

FYI: here is the SP for date

{
  "resourceType": "SearchParameter",
  "id": "clinical-date",
  "extension": [
    {
      "url": "http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status",
      "valueCode": "trial-use"
    }
  ],
  "url": "http://hl7.org/fhir/SearchParameter/clinical-date",
  "version": "4.0.1",
  "name": "date",
  "status": "draft",
  "experimental": false,
  "date": "2019-11-01T09:29:23+11:00",
  "publisher": "Health Level Seven International (Patient Care)",
  "contact": [
    {
      "telecom": [
        {
          "system": "url",
          "value": "http://hl7.org/fhir"
        }
      ]
    },
    {
      "telecom": [
        {
          "system": "url",
          "value": "http://www.hl7.org/Special/committees/patientcare/index.cfm"
        }
      ]
    }
  ],
  "description": "Multiple Resources: \r\n\r\n* [AllergyIntolerance](allergyintolerance.html): Date first version of the resource instance was recorded\r\n* [CarePlan](careplan.html): Time period plan covers\r\n* [CareTeam](careteam.html): Time period team covers\r\n* [ClinicalImpression](clinicalimpression.html): When the assessment was documented\r\n* [Composition](composition.html): Composition editing time\r\n* [Consent](consent.html): When this Consent was created or indexed\r\n* [DiagnosticReport](diagnosticreport.html): The clinically relevant time of the report\r\n* [Encounter](encounter.html): A date within the period the Encounter lasted\r\n* [EpisodeOfCare](episodeofcare.html): The provided date search value falls within the episode of care's period\r\n* [FamilyMemberHistory](familymemberhistory.html): When history was recorded or last updated\r\n* [Flag](flag.html): Time period when flag is active\r\n* [Immunization](immunization.html): Vaccination  (non)-Administration Date\r\n* [List](list.html): When the list was prepared\r\n* [Observation](observation.html): Obtained date/time. If the obtained element is a period, a date that falls in the period\r\n* [Procedure](procedure.html): When the procedure was performed\r\n* [RiskAssessment](riskassessment.html): When was assessment made?\r\n* [SupplyRequest](supplyrequest.html): When the request was made\r\n",
  "code": "date",
  "base": [
    "AllergyIntolerance",
    "CarePlan",
    "CareTeam",
    "ClinicalImpression",
    "Composition",
    "Consent",
    "DiagnosticReport",
    "Encounter",
    "EpisodeOfCare",
    "FamilyMemberHistory",
    "Flag",
    "Immunization",
    "List",
    "Observation",
    "Procedure",
    "RiskAssessment",
    "SupplyRequest"
  ],
  "type": "date",
  "expression": "AllergyIntolerance.recordedDate | CarePlan.period | CareTeam.period | ClinicalImpression.date | Composition.date | Consent.dateTime | DiagnosticReport.effective | Encounter.period | EpisodeOfCare.period | FamilyMemberHistory.date | Flag.period | Immunization.occurrence | List.date | Observation.effective | Procedure.performed | (RiskAssessment.occurrence as dateTime) | SupplyRequest.authoredOn",
  "xpath": "f:AllergyIntolerance/f:recordedDate | f:CarePlan/f:period | f:CareTeam/f:period | f:ClinicalImpression/f:date | f:Composition/f:date | f:Consent/f:dateTime | f:DiagnosticReport/f:effectiveDateTime | f:DiagnosticReport/f:effectivePeriod | f:Encounter/f:period | f:EpisodeOfCare/f:period | f:FamilyMemberHistory/f:date | f:Flag/f:period | f:Immunization/f:occurrenceDateTime | f:Immunization/f:occurrenceString | f:List/f:date | f:Observation/f:effectiveDateTime | f:Observation/f:effectivePeriod | f:Observation/f:effectiveTiming | f:Observation/f:effectiveInstant | f:Procedure/f:performedDateTime | f:Procedure/f:performedPeriod | f:Procedure/f:performedString | f:Procedure/f:performedAge | f:Procedure/f:performedRange | f:RiskAssessment/f:occurrenceDateTime | f:SupplyRequest/f:authoredOn",
  "xpathUsage": "normal",
  "comparator": [
    "eq",
    "ne",
    "gt",
    "ge",
    "lt",
    "le",
    "sa",
    "eb",
    "ap"
  ]
}

view this post on Zulip Brian Beatty (Aug 09 2021 at 18:58):

from the section on Prefixes, it states: "If no prefix is present, the prefix eq is assumed. "

view this post on Zulip Stephen MacVicar (Aug 09 2021 at 19:02):

from the section on Prefixes, it states: "If no prefix is present, the prefix eq is assumed. "

Right, and that gets confusing when you have a search parameter which says that eq doesn't have to be supported, which is what led to this issue being raised in US Core.

Can a server require that a prefix be supplied with that parameter because it doesn't have to support eq? Or does it need to support the eq functionality when no prefix is supplied, even if it doesn't support you explicitly sending the eq prefix?


Last updated: Apr 12 2022 at 19:14 UTC