That wiki does say that it “is used to map the office of a clinical psychologist, including psychotherapists”. So while definitely not the same, they seem to be mapped with that same tag. As you note, healthcare:specialty provides possibilities to provide more options/details if wanted.
Well, one can always try to explain in description=* the details if it’s more complicated so it can’t be explained with healthcare:specialty multivalues.
I haven’t looked into our tagging too deeply as I say this, but I can imagine broad sub-categories / “buckets” being used. A value like mental_health could include all that is said here (and more). A value like dental_health could include dentists, orthodontists, certain kinds of oral surgeons… (and more). A value like radiological_health could include radiologists with a medical degree, x-ray technicians, oncology treatment centers, et cetera.
That way, if I know it’s a healthcare:specialty office, and I know it’s a blood work laboratory, I could tag with value blood_work_lab (I’m making all these up) without knowing if it is phlebotomist, technicians or whatever. If a wiki does (or starts to) better say what values might represent / be in which buckets, we get closer to allowing people to “be vague” while tagging, as we also build what’s needed to make the data better refined if better refinements to the data are actually known.
Again, this is pure “spitball” (an idea launched upon the wall to see if it sticks), but this sort of thing has worked before.
Firstly (and minorly), there are problematic overlaps (e.g. for dental x-ray would it be dental_health or radiological_health?)
But more importantly, people will usually seek specific medical services as they require.
Being routed to psychologist while you need to renew drug prescription to treat mental state would not be really helping. Nor would be being routed to dental x-ray if you’ve broken your femur be helpful either, etc.
I agree wholly, but such “errors” in parsing OSM’s data would come from “assuming too much” from limited data. That’s the thing about finding a “bucket” that’s entered: it might be the doctor you are looking for, it might not. It almost certainly means that if you DO know specifically what sort of doctors / services are there, you would benefit the rest of the map and downstream / consuming community of our data by “refining the data here,” as it is most certainly welcome with “bucket” (vague) tagging.
This “captures vague” but “only vague.” Is this better than zero? Yes. By very much? Well, maybe (if you got lucky and seemed to match) or no (if you didn’t). Sometimes “hitting the dartboard” is a good result, even if you didn’t strike the bullseye.
Perhaps, I myself see mostly “no” category, but I might be missing imagination.
If such idea was found useful however, rather then going the key+subkey way (which would need complete redesign and remapping of current tags!) I’d rather suggest adding wording like “undefined” or “unspecified” in those vague healthcare:specialty values, e.g.
healthcare:specialty=undefined_cardio (if it is unknown whether it is healthcare:speciality=cardiology or healthcare:speciality=cardiothoracic_surgery)
But, as I said, I’m not convinced that such vague specification makes sense for healthcare category (while it may make more sense for, say, cuisine=*).
To be clear yet again, we are simply rough-sketching ideas here. Hand-waving; spit-balling.
Usually, I’d say that when “no specific data are known,” a tag should be left empty, that is, not entered for that datum, no tag of that key. But sometimes, if “something vague” (like “doctors” or “medical facility”) is known, it can be helpful to add a thoughtful key as “intermediate, not-very-specific data.” This is a poor search-value if you are looking for a specific kind of doctor or medical facility, but it can “hit the dartboard” (though not the bullseye) to provide a renderer, for example, that a “hospital cross” or “caduceus symbol” (wrapped snake to represent doctors) should be rendered here.
What it can do (best?) is to prompt a contributor who does know the specifics of what is here to enter those. And that can be a worthy “bridge strategy” to enter “partially known data” (which OSM does a fair bit of) so that they can be further refined into “rather precise data.”
Yes, some redesign (and fairly extensive wiki-documentation of how this should all be sub-categorized, likely with a very lively updating regimen among healthcare categorizers around the world) would be necessary. Maybe some find this potential strategy worth doing, maybe not. It does seem worth discussing, but if it is found to be much too problematic (which I can certainly see as possible or even likely), then this all simply becomes good discussion which we decide is not worthy of pursuing.