Stream: implementers
Topic: Use of HealthcareService.specialty
Tim Berezny (Sep 28 2020 at 20:54):
Is the intended use of HealthcareService.specialty rigidly tied to the idea of clinical specialties of practitioners?
We have a desire to add a concept of "specialties" to a service that may be something different, and i'm trying to figure out if we should use the specialty field (which has a preferred value set), or take another approach:
- For long term care: Reunification bed, smoking bed, etc...
- For orthopaedic specialists: hand, foot, shoulder, etc...
- For physiotherapist: motor vehicle accidents, sports injury, acupuncture, etc...
- For meals on wheels: Hot meals, cold meals, etc...
I think of these as more detailed information that is a bit more precise than what a "Service listings" in a directory might be. Kind of like searching for a hair-dresser, but only some will do a perm.
I'm currently considering the following alternatives:
- Create a "Service options" extension
- Use "HealthcareService.Characteristics"
- Use Healthcareservice.type (which is already being used for the main taxonomy classification like "orthopaedic specialist", "physiotherapist", "meals on wheels".
- Use Healthcareservice.specialty, (throwing the preferred valueset out the window.)
Thoughts?
Lloyd McKenzie (Sep 28 2020 at 21:06):
@Brian Postlethwaite
Brian Postlethwaite (Sep 28 2020 at 23:21):
I'd have suggested Characteristics to cover those types of things.
Robert McClure (Oct 07 2020 at 18:10):
@Robert Dieterle and @Saul Kravitz I think we also thought characteristics was the thing to use? I understand this is not covered by PlanNet but...
Saul Kravitz (Oct 07 2020 at 20:08):
@Gail Kocher
Saul Kravitz (Oct 07 2020 at 20:17):
specialty has a strong (required) binding, so that would mitigate against using it.
type has a weaker (extensible) binding, so that might help.
characteristic is wide open, but not MS.
Last updated: Apr 12 2022 at 19:14 UTC
