Change to "Retrieve a patients appointments" search parameters and error handling

[james-answer]

There is a change to the search parameters for the "Retrieve a patients appointments" request. We need to update the demonstrator with the new requirements and remove the no longer supported version of the search prefixes, adding error handling. This should be changed for both the 1.0.0 and 1.1.0 versions of the demonstrator.

The changes in the spec are described below and there is a Netlify link to a draft of the changed spec:

https://gpconnect-retrieve-app-change.netlify.com/appointments_use_case_retrieve_a_patients_appointments.html

The original requirements were that providers:

• SHALL support the search prefixes eq, gt, lt, ge and le
• SHALL consider no search prefix to be the same as including the eq search prefix
• SHALL support the following combinations of start date search parameters
  • No search parameter
  • One search parameter with either the “eq” or “” search prefix
  • One search parameter with either the “gt” or “ge” search prefix
  • One search parameter with either the “lt” or “le” search prefix
  • Two search parameters, one “gt” or “ge” prefixed parameter and one “lt” or “le” prefixed parameter
• SHALL only return appointments in the future so possibly return an empty bundle if the consumer requested appointments in the past.

There was no guidance for a consumer or any specific guidance for a provider relating to what should be considered an error.

---

The new requirements would be:

The consumer

• SHALL always send two start search parameters. One will be prefixed with the search prefix le demoting the upper boundary, the other will be prefixed with ge denoting the lower boundary for the search date range.
• The Date parameters SHALL only contain the date element and SHALL NOT contain a time element. For example, "start=ge2018-03-05" is correct but "start=ge2018-03-05T12:34" is not valid
• Enhanced guidance that consumer should indicate to the user that they are not able to see appointments in the past.

The provider:

• SHALL return an error if any of the requested date range is in the past, the error SHALL contain a clear message telling the consumer the issue is that they requested a date range in the past.
• As the resolution of the request parameter is the date and not the time the validation should only be on the date, so if the request includes today’s date it should include the appointments for today, pending agreement from IG.

[lucywilcock]

This has been completed and merged with the 1.0.0 and 1.1.0 release branches and tags as well as with develop.