Proposal talk:Healthcare 1.1

Option A or B

Resolved: After Discussion here, on community.osm.org and mailing list -> Option B

I like option A. Compared to the current scheme of for example amenity=doctors, amenity=healthcare + healthcare=* might feel like double tagging. However I think facilities like a psychologist or a nursery home are also amenities, just like doctors etc. Then amenity=healthcare + healthcare=* makes sense a lot. --Cartographer10 (talk) 16:56, 2 October 2022 (UTC)

None of this makes any sense, option A would make all current healthcare tagging invalid, option B states what is already the current practice, with a small number of objects that have double tagging which, if it is actually a problem (which it isn't) should be addressed and not other non-problems. --SimonPoole (talk) 18:20, 2 October 2022 (UTC)

I like the proposal; with the restriction of closely coordinating this with data consumers (see comment by JeroenHoek below). I prefer Option B because I don't believe tagging an object only with amenity=healthcare would be any useful. Hence, this tag would be redundant and we can shortcut to using healthcare=* as primary tag. (but Option A wouldn't give me a big headache either). --Martianfreeloader (talk) 18:55, 2 October 2022 (UTC)

Same as Martianfreeloader Something B (talk) 21:39, 2 October 2022 (UTC)

one more time, healthcare is already in use as a primary tag, there are just some cases in which the tagging is customarily doubled up. SimonPoole (talk)

I have now decided that I would rather follow @Martianfreeloader:'s view. I therefore prefer option B.

And on the subject of @SimonPoole:: "healthcare is already in use as a primary tag," - apparently not everyone sees it that way (which is why Carto support was discontinued in 2019). I also see your assessment of "just some cases" as a standard case, since amenity=hospital,doctors, etc are always connected to healthcare=* only for rendering.

--SafetyIng (talk) 14:32, 3 October 2022 (UTC)

@SimonPoole: @Martianfreeloader:, The advantage of option A is that you get a very consistent tagging scheme. It is indeed a big change for which data users need to get the time to adjust. Data wise it is possible via a few mechanical edits to re-tag the current healthcare amenities. That the current system looks more like option B doesn't mean option A is not possible. It is a big change but sometimes a restructure of a tagging scheme is needed --Cartographer10 (talk) 17:36, 3 October 2022 (UTC)

I don't understand why either option would be more or less consistent than the other. Can you explain what you mean by that? Also, my argument was not that either option is currently in more widespread use. My point is that amenity=healthcare alone would almost always be useless without an additional healthcare=*. Hence, we can simply relinquish amenity=healthcare. --Martianfreeloader (talk) 18:59, 3 October 2022 (UTC)

What options are you talking about? --Push-f (talk) 19:23, 3 October 2022 (UTC)

In an earlier version of the proposal, it came in 2 flavours.

• Option A: amenity=healthcare (primary tag) + healthcare=* (secondary tag).
• Option B: Only healthcare=* (primary tag).

--Martianfreeloader (talk) 20:30, 3 October 2022 (UTC)

Thank you, @Martianfreeloader:, for documenting this again here. I should have done it here. --SafetyIng (talk) 12:45, 4 October 2022 (UTC)

Viability

While I am generally in agreement with this plan and of the opinion that rendering shouldn't stop good tagging, I do worry that deprecating something as important as amenity=hospital would need very broad support from the community and some amount of buy-in from the major renderers. If this proposal has the effect of seeing hospitals disappear from openstreetmap.org, than that would I fear be cause for concern for many mappers and make this proposal unviable even before voting opens.

So in order for this to succeed there would probably need to be a grace period after acceptance where rendering of either of the options should be sorted out. That might be tenable for the maintained well-willing projects (like OrganicMaps, OSMand, or OpenMapTiles), but would also harm lots of other projects and data consumers who never made the switch to healthcare=*. This, of course, also means Carto won't render anything for five years or so, and people will end up with quite unwanted regressions, like local media using openstreetmap.org screenshots which will then miss major hospitals… Not ideal, to say the least. Any ideas on how to avoid that?

But perhaps I'm mistaken and rendering is already well-supported. What is the current level of support for rendering of option B (i.e., healthcare=* without amenity=hospital)? --JeroenHoek (talk) 16:57, 2 October 2022 (UTC)

1 👍 for consulting with data consumers and giving them ample lead time ^{martianfreeloader 2022-10-02}

For me, the support of renderers cannot and must not be a basis for decision-making. Especially in view of the already wide distribution of the healthcare tag. Effectively, we are only talking about finally ending a process from 12 years ago. Also, voting for the proposal will not make all amenity=* disappear with a snap of the fingers. --SafetyIng (talk) 14:20, 3 October 2022 (UTC)

I agree. Yet, for something as important as healthcare, we should make sure data consumers have enough time to adapt to the decision we make. Sorry if that was not clear. --Martianfreeloader (talk) 19:01, 3 October 2022 (UTC)

The support by renderers (well, this is just about Carto really, other renderers are quick to adapt) is indeed not something that should stop progress, but it will influence mappers when voting for this proposal — people are likely to be reminded of highway=busway. Long term, there is nothing keeping mappers from just adding amenity=hospital back in for backwards compatibility leading to edit wars on the one hand and annoyed users who see openstreetmap.org lack any indication that a major hospital is, well, a hospital, on the other hand. I agree that this is ultimately an issue for the maintainers of openstreetmap.org to solve, but it will impact what you are proposing here. --JeroenHoek (talk) 17:06, 5 October 2022 (UTC)

Hey, @Martianfreeloader:, @JeroenHoek: I have added a section for this purpose. Do you think this is an appropriate tribute to the theme? --SafetyIng (talk) 11:02, 11 October 2022 (UTC)

I'd give a clear guideline. Something like: "This proposal will not take effect before 2023-07-01. This is to give data consumers enough time to adapt to the change. It is discouraged to remove existing amenity=healthcare before that date." --Martianfreeloader (talk) 13:40, 11 October 2022 (UTC)

For renderers specifically I would phrase it as a recommendation to render healthcare=* where appropriately in the absence of the legacy amenity=* tag (like hospital) as well before the cut-off date. --JeroenHoek (talk) 15:51, 11 October 2022 (UTC)

Left: rendering of amenity=hospital, right: rendering of healthcare=hospital without amenity=hospital.

I am very much in favour of change. Double labelling is never a good thing. healthcare=* key has been approved for many years. The amenity=* key is only used because it is the historical key for many objects, but it doesn't really make sense now that the project is developed. I am also in favour of allowing time for the map backgrounds to change. I recall that with Fanfouer and Overflorian, we had written a page to finely manage these changes which are sometimes necessary. Again, a very small part of the community is against it, because "the tag is too used to change so let's not change anything" and other silly reasons. When all that is needed is to define a timetable and a process. Nothing is impossible. If we can't change anything on OSM, the project is useless. Gendy54 (talk) 10:50, 16 October 2022 (UTC)

Link with landuse=healthcare

Currently, the tag landuse=healthcare is not used a lot. Services like hospitals and nursery homes do have a landuse and are healthcare. A properly documented tag like healthcare=* can be used as subtag to landuse=healthcare. For example, hospital grounds are currently tagged with amenity=hospital. Deprecating amenity=hospital can be replaced with landuse=healthcare + healthcare=hospital for the hospital grounds with e.g. the name and website --Cartographer10 (talk) 17:00, 2 October 2022 (UTC)

Why are nursery homes landuse=healthcare? amenity=social_facility in general doesn't fit. They are community facilities, and care doesn't mean "healthcare".
landuse=* is a different issue. healthcare=* is a functional unit that should not be an attribute to landuse=healthcare (landuse=industrial + industrial=* shows how bad that it is compared to man_made=works etc), although they can co-exist on the same area to represent the facility is occupying the entire land. It is only needed more when there is a mix of facilities sharing the same compound, similar to landuse=education. amenity=hospital again refers to the functional unit.
--- Kovposch (talk) 09:48, 3 October 2022 (UTC)

I agree with Kovposch insofar as I would not give a general recommendation/requirement to tag landuse=healthcare and healthcare=* on the same OSM object. Sometimes, this can be the right way, but often it isn't. Common examples where this wouldn't work: (1) A doctor's surgery in a residential building. (2) A landuse=healthcare area with multiple clinics on it. --Martianfreeloader (talk) 09:56, 3 October 2022 (UTC)

External discussion

Resolved

The external discussion that you've linked in the proposal is in German. As your proposal has global scope, I suggest to give a brief summary of the discussion in English to include those who don't read German. --Martianfreeloader (talk) 19:01, 2 October 2022 (UTC)

@Martianfreeloader: I don't see the need to write a summary for it so far. I think it is rather unusual and community.osm.org offers you the possibility of a translation function when you are logged in. With the help of this, people speaking other languages can also follow the conversation. --SafetyIng (talk) 20:59, 2 October 2022 (UTC)

@SafetyIng: Where do I activate that translation function? I Cannot see the option on community.osm.org. Thanks -- Privatemajory (talk) 04:58, 3 October 2022 (UTC)

Click the globe icon on a post in a foreign language. It's located in the group of icons on the bottom right of a post. --Tordanik 09:14, 3 October 2022 (UTC)

Method of transition

Resolved: healthcare:speciality=* is not touched in this proposal.

Simply replacing amenity=* with healthcare=* won't work. I suggest only requiring healthcare=* when healthcare:*=* is used. This limits the extent of works and users affected. Only those interested or needing details will be asked to add it.

healthcare:speciality=* in turns is in more need to be corrected by the proper word "specialty" as in health_specialty=* pointed out by Talk:Proposed_features/Healthcare_2.0#Word_for_particular_areas_is_SPECIALTY_not_speciality to not make us look silly. In fact, the opposition vote causing healthcare:speciality=* https://wiki.openstreetmap.org/w/index.php?oldid=589962 seemed to have a typo or misunderstanding in between. My spellchecker is already highlighting that the typo "speciality" should be replaced by "specialty" here. Kovposch (talk) 10:02, 3 October 2022 (UTC)

Speciality is correct in British English. Specialty is US English. We use British English for keys. --Nospam2005 (talk) 11:39, 3 October 2022 (UTC)

No, it is not the standard in medicine.
https://dictionary.cambridge.org/example/english/medical-specialty vs https://dictionary.cambridge.org/spellcheck/english/?q=medical+speciality
https://www.oxfordlearnersdictionaries.com/definition/english/specialty "usually" vs https://www.oxfordlearnersdictionaries.com/definition/english/speciality?q=speciality (no example sentence for medicine)
https://specialtytraining.hee.nhs.uk/
https://www.datadictionary.nhs.uk/classes/main_specialty.html?hl=specialty
https://bestpractice.bmj.com/specialties
https://www.bma.org.uk/advice-and-support/career-progression/training/specialty-explorer
https://www.medschools.ac.uk/studying-medicine/after-medical-school/specialties
https://www.gmc-uk.org/registration-and-licensing/join-the-register/registration-applications/specialist-application-guides/minimum-uk-training-time-for-each-specialty
https://roadtouk.com/training-in-uk/training-overview/specialty-or-gp-training-residency-in-the-uk/
--- Kovposch (talk) 14:22, 3 October 2022 (UTC)

Yes it is. If you look closely, you'll see that both Cambridge Dictionary and Oxford Dictionary recognize specialty as US spelling and speciality as UK spelling: https://dictionary.cambridge.org/dictionary/english/specialty (I got there by clicking on "Definition" of the Cambridge Dictionary page that you've cited) --Martianfreeloader (talk) 19:08, 3 October 2022 (UTC)

Words have different meanings and usage. Oxford describes this as being "usually", not always. This is the exception. Cambridge has "medical specialty" as "often used together".
And you can look beyond the dictionary to see most common usage and almost all professional usage have "specialty", not "speciality".
Encyclopedia: https://www.britannica.com/summary/medicine
News from last month:
"medical specialty" https://www.bbc.com/news/health-62569344
"specialty" https://inews.co.uk/opinion/luring-doctors-from-poorer-nations-is-uks-quiet-scandal-1846124
"medical specialty" https://www.thelancet.com/journals/landig/article/PIIS2589-7500(22)00175-3/fulltext
"GP specialty" https://www.gov.uk/government/publications/gp-and-dental-clinical-educator-pay-scales-2022-to-2023/gp-educator-pay-scale-2022-to-2023
"specialty" https://www.telegraph.co.uk/politics/2022/09/21/nhs-good-hands-no-nonsense-hands-on-therese-coffey
Compare:
https://www.thesouthernreporter.co.uk/health/former-bgh-doctor-launches-scathing-attack-on-nhs-borders-management-3811222 "specialty doctor" is the actual NHS title https://www.nwpgmd.nhs.uk/careers_advice/careers/specialty_doctor
https://www.gov.uk/government/organisations/uk-commission-on-covid-commemoration/about The official title is "acute specialty medicine" https://www.kch.nhs.uk/Doc/corp%20-%20695.1%20-%20register%20of%20interests%20(senior%20staff).pdf
https://www.express.co.uk/news/uk/1677627/energy-bills-price-rises-hospice-care Not sure about the quality of Daily Express, again the actual organization uses "specialty" https://darlingtonhospice.org.uk/referrals/
---/ Kovposch (talk) 08:05, 4 October 2022 (UTC)

Okay, @Kovposch: and @Martianfreeloader: I know specialty would be the correct translation. But I would like to keep it out of this proposal, because I don't want to touch this tag and it has already been used almost 100k times. --SafetyIng (talk) 12:52, 4 October 2022 (UTC)

This was touched upon on https://community.openstreetmap.org/t/rfc-healthcare-1-1/3455/6 so not entirely irrelevant. Mainly there seems to be a lack of strong reasons and attractiveness to motivate a move. Even on https://taginfo.openstreetmap.org/keys/healthcare:speciality#combinations 8.4% = 8k still lacks a healthcare=* for some reason. I guess you need a campaign to validate and add healthcare=* to amenity=*, more than a proposal to somehow change their status. --- Kovposch (talk) 05:44, 5 October 2022 (UTC)

Deprecate amenity=healthcare

Resolved: amenity=healthcare is included to deprecate

@SafetyIng: As you've opted for Option B, I think you should mention that this would deprecate amenity=healthcare if I'm not mistaken. --Martianfreeloader (talk) 20:33, 3 October 2022 (UTC)

Oh, amenity=healthcare is more widespread than I thought. Since it was not documented in the wiki before, I did not think too much about including it for deprecating. I have included it. --SafetyIng (talk) 12:57, 4 October 2022 (UTC)

Why this proposal is so much needed… ;-)

Resolved

Yes, we really should replace amenity=dentist with healthcare=dentist, as you will gain mutch from this replacement!

Yes, we need healthcare:speciality=* as it makes filtering out the interesting locations really easy, as healthcare:speciality=neurology;psychiatry is different from healthcare:speciality=psychiatry;neurology.

Yes, we require healthcare:speciality=dermatovenereology, as it was proposed and now emergency fixed, as many other things, by adding dermatology and venereology, as such tagging saves you mutch work! healthcare:speciality=neurologypsychiatry should also be added, such as healthcare:speciality=psychiatrypsychotherapy, to solve the problem above! healthcare:speciality=psychiatrypsychotherapy is common for psychiatrists in Europe now, are these healthcare=doctor or healthcare=psychotherapist?

Yes, we really require healthcare=* as especially has a good solution for facilities (What type of facility is it when healthcare=* is used for it?), which are larger therapy offices which are healthcare=physiotherapist and also healthcare=occupational_therapist, such as this one.

The provided services in health care, as also with lawyers, are close tied to the persons, who provide the services, as in medicine, it is such a difference if one physician has training in two specialties, or two physicians are trained in one specialty. A German explanation of this topic can be found here. For lawyers for example it is interesting, if many work on the same speciality or not. This blog post proposes to create generic person roles for such things, such as training or work experience. --Fabi2 (talk) 11:18, 7 October 2022 (UTC)

Snarky sarcasm isn't helpful here. It is a way to ridicule someone's ideas under the guise of 'humour' rather than actually engage with them. If you disagree with what is proposed here, why not lay out your arguments in a more polite, neutral tone of voice? --JeroenHoek (talk) 18:22, 7 October 2022 (UTC)

Back in 2010 I made the mistake and tried to improve the healthcare=*-proposal, but as the writers refused my improvements, I made Healthcare 2.0 as alternative. But instead of try to vote it through, I hoped that people would read and understand and maybe use it, as an effect of OSM swarm intelligence. But a few people understand its new concept of person-tagging using relations, which was only used with type=person-relations to specify the lifetime of dead persons until now. It wrote more examples, explained it in the German forum (later also sarcastic) and also wrote the blog post above to friendly explain the concepts of it. But health_person:type=* is still used outside of relations, if anyone used it. It also seems that many people have no problems with the still broken healthcare=*-proposal. I hope this helps you to understand that the time for friendly improvements is just over, and that making it the new default for health care helps even further. --Fabi2 (talk) 19:02, 7 October 2022 (UTC)

@Fabi2: Thank you very much for these lines. Unfortunately, I do not see any added value for this proposal. Here, only the classification for healthcare=* is decided.

Nevertheless, I would like to respond to a few of your comments: Just because you see the system as "inadequate" does not mean that others see it that way. For example, I see the Healthcare 2.0 proposal as too complex and loaded. But that doesn't mean that there isn't potential for development in healthcare=*.

Nor do I see that the order within healthcare:speciality=* should have an impact.

But thank you also for drawing my attention to health_facility and health_specialty, as well as the office=* tags, so that I can also include them in the proposal.

--SafetyIng (talk) 11:20, 11 October 2022 (UTC)

Reaction to oppose vote

I don't like to ruin the voting by putting comments in there. So I'm moving those comments here:

@Jeisenbe: As I already wrote on the mailing list: It is also not changed to a "new key". There is also nothing "new". Only the old Healthcare Proposal from 2010 (!) is finally enforced (so much for "without justification"). I think we should finally accept and enforce the solutions that have been agreed upon. Or deprecate the old consensus! But I have decided for the first. --SafetyIng (talk) 21:46, 5 November 2022 (UTC)

The proposal was 12 years ago, in that time the healthcare= tags have been adopted by some editor applications such as iD, yet the tags amenity=hospital, amenity=clinic, amenity=dentist, amenity=doctors etc remain more than twice as common as the healthcare= alternatives, and while there are many amenity= objects without healthcare= tags, there are very few healthcare= objects without an amenity tag. Mappers have clearly chosen to keep using the de facto tags, which are perfectly good.

In proposing a change now, it is necessary that the proposal author gives clear and convincing reasons that a long-existing standard should be altered, because it will require a great deal of extra work by mappers and application developers to change tags which are used ~1 million times. --Jeisenbe (talk) 22:12, 5 November 2022 (UTC)

What about dropping healthcare=* entirely, and moving all healthcare to amenity=*? -- Something B (talk) 13:02, 7 November 2022 (UTC)

@Eiskalt-glasklar: Where in the proposal is healthcare:speciality=* affected? Exactly nowhere. But if you want to optimise healthcare:speciality=* in the future, I would certainly support that. Otherwise, it is a tagging accepted as consensus since 2010. --SafetyIng (talk) 21:46, 5 November 2022 (UTC)

@Segubi: Wich issues do you see as unresolved? Why would "The overall quality of the data would decline"? In reality: The "amenity" keys have already been replaced by healthcare through the 2010 proposal. That is not even up for debate here. It is just that this step will finally be ended and the coexistence of two equal tagging schemes will be unified to the consensus of 2010. --SafetyIng (talk) 23:14, 5 November 2022 (UTC)

"The "amenity" keys have already been replaced by healthcare through the 2010 proposal" - no, they were proposed to be replaced. Actual replacement has not happened, even double tagging is not fully reached - even with iD heavily pushing it Mateusz Konieczny (talk) 23:49, 5 November 2022 (UTC)

NO. It was proposed AND ACCEPTED. There was a voting and it was successfull. Not iD have pushed it, iD accepted and implemented the decision. --SafetyIng (talk) 00:41, 6 November 2022 (UTC)

Proposal was voted and vote was won, but proposal was not accepted by general OSM community and significant opposition remains Mateusz Konieczny (talk) 00:54, 6 November 2022 (UTC)

So if you were to finally implement the proposal from 2010 via a mass edit to all amenity=XYZ, now add healthcare=* to it and then say: Editors, implement the proposal from earlier and adjust your presets. (period 2 months).

Then according to the data users are given time to switch. (e.g. one year, which is very realistic) - then it would be a sensible step and would have your support?

And I know that everything that runs under healthcare:* still has potential for development. But that's not what the proposal is about. Sorry, but you lose credibility if we don't implement our own community decisions. --SafetyIng (talk) 00:47, 6 November 2022 (UTC)

"Editors, implement the proposal from earlier and adjust your presets. (period 2 months)." - editor authors are free to ignore proposals, especially badly designed ones. People are free to vote against bad proposals. I would vote against any proposal making demands like this, partially because I want to preserve credibility of proposal process rather than burn it. And if we would be making such changes then make it where there would be some serious benefit like getting rid of confusing highway=unclassified Mateusz Konieczny (talk) 00:54, 6 November 2022 (UTC)

What does highway=unclassified still have to do with this?! It's about HEALTHCARE TAGGING. IF it's not important for you, then okay. Maybe it is for others. Who are you to say what is the biggest problem for others? I have an idea: If the definition of highway=unclassified bothers you - write a proposal. But that doesn't affect the topic here. For example, I have no problem with the current definition of highway=unclassified.

And on the subject of "editor authors are free to ignore proposals" - but they don't. In fact, they make it a priority. Proposals are not something that has no meaning. They are a big basis for decision-making by editors and data users. --SafetyIng (talk) 01:01, 6 November 2022 (UTC)

"If the definition of highway=unclassified bothers you" - I am bother by confusing tag name, though I do not expect proposal process to pass and even if passing it would be unlikely to be treated seriously Mateusz Konieczny (talk) 01:29, 6 November 2022 (UTC)

"Proposals are not something that has no meaning." - I am not claiming this. I am claiming that editors take them into account, often following them. But action taken can be also "lets ignore it altogether". For example this was done with 2010 healthcare=hospital tag by JOSM authors Mateusz Konieczny (talk) 01:27, 6 November 2022 (UTC)

Commentation/Discussion to

Strictly speaking, each of the tags that were proposed to be marked as obsolete in Proposed features/training, occur in the database in an amount of less than 500. -- Something B (talk) 22:52, 5 November 2022 (UTC)

amenity=language_school and amenity=driving_school were supposed to get competing approved tagging scheme which is a stealthy deprecation attempt. People were fooled by that before, nowadays this tactic is working less reliably. Mateusz Konieczny (talk) 23:30, 5 November 2022 (UTC)

These tags were not listed as deprecated in the "Features /Pages affected" section. They were only mentioned in the informative table. But that doesn't matter anymore because the reason the proposal was rejected is the amenity=training is too wide. -- Something B (talk) 12:08, 7 November 2022 (UTC)

Tactic "this is not deprecated, it is just approval of competing tagging scheme" with later "this old tagging scheme was replaced with a new approved one, so should be tired as deprecated" was done before. Mateusz Konieczny (talk) 13:46, 7 November 2022 (UTC)

Can you give an example please? Something B (talk) 13:56, 7 November 2022 (UTC)

"This proposal does not replace, deprecate or obsolete the already existing and well known tags." in PTv2 has not stopped some people from trying to treat highway=bus_stop as deprecated. Mateusz Konieczny (talk) 19:53, 7 November 2022 (UTC)

amenity=doctors listed twice in tags de be deprecated

amenity=doctors is listed twice in Proposed features/Healthcare 1.1#Proposal. Should one of them be amenity=doctor instead? --Das-g (talk) 12:39, 16 November 2022 (UTC)