usability issues with "address" as a search parameter for patient

XMLWordPrintableJSON

    • Type: Change Request
    • Resolution: Persuasive with Modification
    • Priority: Medium
    • FHIR Core (FHIR)
    • DSTU1 [deprecated]
    • Patient Administration
    • STU
    • Patient
    • 5.1.6
    • Hide

      Include these new additional search parameters (in addition to the existing parameter):

      addressCity, addressState, addressPostcode, addressCountry, addressUse

      on the Patient, Person, Practitioner, Location, Organization and RelatedPerson

      Show
      Include these new additional search parameters (in addition to the existing parameter): addressCity, addressState, addressPostcode, addressCountry, addressUse on the Patient, Person, Practitioner, Location, Organization and RelatedPerson
    • Grahame Grieve/Peter Bernhardt: 13-0-0
    • Correction
    • Compatible, substantive
    • DSTU1 [deprecated]

      Currently, "address" is listed as a search parameter. I believe that there isn't sufficient information given for implementers regarding how to make this work well for patient queries.

      A client application is rarely going to have a single field for user input for "address" rather, the client application may have a field for street address, postal code, city, etc.

      From a server standpoint, a system is likely to have more than just one address. Also, attempting a match/filter a set of patient records based on street address lines is something that is unlikely to be supported. Lastly, when used in a search, address information is typically always referring to a patient's usual residence so it would be helpful if the specification made this clear in some way.

      Suggestion: break out any address related search parameters to be more specific. etc. Include 1 or 2 of the most common items that might be included in a patient search and then allow individual implementations to add in any additional search parameters. e.g. instead of "address" have e.g. homeCity, homePostalCode.

            Assignee:
            Unassigned
            Reporter:
            dloewenstein
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: