medplum / medplum / 24863414073

92%

main: 92%

push

github

Use explicit HealthcareService references in Scheduling (#8927)

* Remove extraneous SchedulePage->FindPane tests

These are a remnant of an earlier implementation when these were more
tightly coupled.

In #8857 SchedulePage started delegating more of the rendering concerns
down to FindPane, so we don't need to test it in this file as richly.

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

* Use MockClient.searchResources in FindPane tests

Mea culpa: I asked Claude to write the first iteration of these tests,
and I glossed over this detail when reviewing. It claimed that the
MemoryRepository didn't have this search parameter indexed, but I think
that this was a bit of a hallucination as it was trying to explain why
the tests were not working.

Let's clean it up: we amend our `medplum.get` mock to only intercept
`$find` requests (which the MemoryRepository truly doesn't support), and
let other requests such as a FHIR search go through normally. Then we
create the HealthcareService resources normally and our tests are more
consistent.

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

* $find requires Schedule list available service types

This was listed in the documentation in some places, but not
consistently represented.

This allows use cases where practitioners should only be scheduled for
certain service types.

The Provider UI now only offers menu options from HealthcareServices
matching an entry in the `serviceType` attribute of the viewed schedule.

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

* ProviderUI: Focus on HealthcareService as Scheduling primitive

Based on the original API spec, I had been treating a "CodeableConcept"
as the fundamental unit for scheduling when originally implementing
this, which led to some slightly gnarly outcomes:

- Lots of comparisons of Codings / Codes

- Needed to assign stable keys to the concepts

- Confusing behavior when a code is on multiple schedulable items

We're adjusting to move towards using a Healthc... (continued)

18419 of 20982 branches covered (87.78%)

Branch coverage included in aggregate %.

70 of 76 new or added lines in 4 files covered. (92.11%)

33326 of 35364 relevant lines covered (94.24%)

13506.39 hits per line