Filter | XUND API Documentation

Filter object represents a filter that can be used to filter Medical Services.

Filter Flow

Filter Flow is required because supported and filterable properties differ by country.

The Filter Flow constists of three steps:

Requesting filters by country code or location from GET /v1/services/filters endpoint.
Building the user interface from the returned Filters object.
Sending the filter values to POST /v1/services/filters/apply endpoint and displaying the returned Service objects.

Filter Classes

FilterBase model is extended into different filter implementations. These classes are mapped by the FilterKey enum in the returned Filters object, where the following key → type combinations are found:

Filter key	Filter class	Filter purpose
`name`	NameFilter	Filter the name of the Medical Services
`genders`	GenderFilter	Filter the gender of the Medical Services
`specializations`	SpecializationFilter	Filter the specializations of the Medical Services
`openingHours`	OpeningHoursFilter	Filter the opening hours of the Medical Services
`insurers`	InsurerFilter	Filter the accepted insurers of the Medical Services
`location`	LocationFilter	Filter the location of the Medical Services

Each filter contains a property called type, which defines the way it behaves. Its value is of type FilterType, which is an enum that can hold the following values:

TEXT

Marks a text-based filter. For example: search for name

MULTISELECT

Marks a multiselect filter. Usage example: Select medical specializations

Marks a special type, a ‘list of filters’. Usage example: Select openimg hours

LOCATION

Marks a location filter. Usage example: Select location

The value of the filter type should be checked to decide how to render a filter.

Filter rendering notes

When rendering the filters returned by the server, the UI is not restricted in any way. The first two filter types are pretty straightforward:

TEXT type filter needs a text input for the display, and will be sent back to the server as a string under its FilterKey name.
MULTISELECT type filter needs checkboxes or other multiselect element for the display, and will be sent back to the server as an array of strings under its FilterKey name.

More special cases are the other two:

LOCATION has no own properties. The Location object is mandatory for filtering, but its values are probably coming from the user’s current position or a map element on the UI.

FILTER_LIST type is a type for a 'list of filters'. It contains other Filter objects under its filters property, which should be rendered according to their FilterType. Currently, only OpeningHoursFilter is using this type, and in that case it represents a two-dimensional array parameter. This filter will contain MULTISELECT filters for every day of the week. See example usage in its documentation.