medplum / medplum / 23155714523

92%

main: 92%

push

github

Scheduling: Remove "Generic" (aka "Wildcard") availability (#8672)

Using the absence of a "service-type" parameter to imply a catch-all
availability classification has some challenges;

- it adds complexity to an already rich problem domain
- it can cause surprising scheduling behavior when a request falls back
  to this "generic" availability

When a user is setting up scheduling, if they want a "default" service
type, they should define and instantiate a CodeableConcept to represent
that, and explicitly use that service-type in their $find request
parameters.

This has some nice bonus effects:
- The provider example app no longer has to distinguish between `null`
  (meaning "no selection has been made") and `undefined` (meaning "the
  wildcard availability has been selected").
- Some type annotations get a bit tidier
- Some failure modes become more explicit (such as a typo in a
  service-type parameter will not be masked by the presence of "generic"
  availability)

There are some tradeoffs:
- Extra configuration can be required: the "serviceType" subextension is
  now required when setting up scheduling on Schedule resources.
- Clients who want a "default" or "catch-all" service type will have to
  explicitly define one and include it in all requests.
- This is a breaking change, but as scheduling is still in "alpha" we
  consider this acceptable.

Signed-off-by: Noah Silas <noah@medplum.com>

17850 of 20253 branches covered (88.14%)

Branch coverage included in aggregate %.

12 of 12 new or added lines in 2 files covered. (100.0%)

32431 of 34235 relevant lines covered (94.73%)

15105.04 hits per line