Proposal:Practitioners
| Practitioners | |
|---|---|
| Proposal status: | Rejected (inactive) |
| Proposed by: | GA Kevin |
| Tagging: | practitioners=*, (practitioners:count=*) |
| Applies to: |    
|
| Definition: | A list of practitioners practicing in a given location. |
| Statistics: |
|
| Rendered as: | hidden |
| Draft started: | 2025-01-09 |
| RFC start: | 2025-01-09 |
| Vote start: | 2025-01-30 00:00:00 (UTC) |
| Vote end: | 2025-02-18 23:59:59 (UTC) |
Proposal
Add a key practitioners=* to list the practitioners in a given location.
Rationale
Many professional locations list publicly the practitioners=* that practice within a location. Most notably medical, legal, and accountant firms are sometimes referred to more by the practitioner located within a location than the formal name of the building or office itself. This information can be a valuable addition to the data within OSM by adding the ability to query and filter by practitioner name as well as the building or office name. Additionally, further use can be used by querying healthcare:speciality=* or craft=* to display a list of all practitioners in a given predefined area or operator. This tag is intended to be used to signify a list of one or more individuals, all of whom are operating in one location, all of whom are practicing the same specialty.
Special care should be taken when listing practitioners to only list those names which are publicly made available, such as those listed on a sign or advertisement. Please follow local law when adding practitioner names to the OSM database. Contributors should only tag practitioners that have made an effort to make their name public, such as with a sign or advertisement.
Potential issues
There exists several potential issues with a single practitioners=* tag.
- Length limit and readability, if many practitioners operate in the same location, the value of this tag can theoretically get very large. Talk page.
- Duplication if a practitioner has a "home office" but also "visiting offices" such as a doctor with a primary office, and is also a frequent practitioner at the local hospital. Only practitioners which have made an effort for their name to be public, such as with a sign or advertisement, should be listed regardless of location.
- Differing information within a location. Such as when a pair of lawyers share a office, staff, and other attributes, but each has their own email. Local customs, laws, and on-the-ground presentation should guide a contributor in this scenario.
Nevertheless, the practitioners=* tag's potential benefits far exceed the challenges of how to mitigate these potential issues and further refinement can be made throughout the proposal process.
Tagging
| Tag | Tagged On | Description | Example |
|---|---|---|---|
| practitioners=* |
|
A list of individuals and appropriate titles that practice at a given location. | practitioners=Jane Doe, MD; John Doe, MD |
| practitioners:count=* |
|
A count of individual practitioners at a given location. | practitioners:count=7 |
Changes based on community feedback
Originally, the 
practitioners:primary=* and practitioners:support=* were included to designate the primary and support practitioners at a given location. This served a dual purpose of listing senior members apart from non-senior members as well as double the Unicode character limit that can be used for such. After community input, these run a risk of personal non-public information inadvertently entering the database. While recognizing the character limit of the overall 
practitioners=* it was agreed to limit the scope to only the single and practitioners:count=*.
Further refinement has been made on 2025-01-29 to further clarify only publicly available name should be added and local law will supersede any tagging guidance listed in this proposal.
External discussions
Comments
Please comment on the discussion page.
Voting
Voting on this proposal has been closed.
The result is 47% support with 7 votes for, 8 votes against and 3 abstentions.
The proposal is rejected on first round of voting.
I approve this proposal. --Eatham (talk) 23:33, 1 February 2025 (UTC)- I approve this proposal. --Mueschel (talk) 09:55, 2 February 2025 (UTC)
I oppose this proposal. As discussed the storage of personal names in United Kingdom and European Union and other juridictions makes OSM a data controller with onerous conditions associated in managing and maintaining the practitioners data. The storage of practitioners is not necessary and requires maintenance beyond the capabilities of OSM. Passing the names of practitioners to OSM consumers makes them data controllers and places on them the burden of managing their instance of the OSM database. Generally the collection of personal data should be a big NO for OSM. --TonyS (talk) 13:58, 2 February 2025 (UTC)- I oppose this proposal. A strong NO. Collides with the General Data Protection Regulation (GDPR) inside EU. More generally, listing people by name is, in my opinion, totally outside OSM scope. --Reino Baptista (talk) 15:58, 2 February 2025 (UTC)
- I approve this proposal. Maintenance of practitioners is the same as maintenance of opening hours or plainly the name of a shop. I don't see how it's a larger problem. Those also don't fall under GDPR. We're not collecting private data here. This is data which can be read on signs or homepages and is therefore meant to be public --Fnordson (talk) 17:57, 2 February 2025 (UTC)
- I oppose this proposal. The word chosen as the key feels awkward and un-intuitive and having this tag documented will probably lead to overtagging of instances where this data isn't really publicised. --InsertUser (talk) 18:35, 2 February 2025 (UTC)
I have comments but abstain from voting on this proposal. Proposal content doesn't explain how the 255char length limit, except for the "benefit far exceeds the challenges of how to mitigate these potential issues and further refinement can be made throughout the proposal process." without an outcome. Not only the number, but the names and titles could be very long already. There's raw readability, and edit maintainability concern here as well. Personally I want to split by title, if this is to be added, and even first and last name. practitioners:count=* should be emphasized, but this is unclear as currently doctors and physician assistants or nurse practitioners may be mixed. The treatment of staff_count:*=* from Proposal:Healthcare_2.0 is unknown. practitioners:url=* is another easier and more widely acceptable solution that has become missing. —— Kovposch (talk) 09:49, 3 February 2025 (UTC)- I have comments but abstain from voting on this proposal. I do support the idea of the practitioners=* tag but I believe this proposal needs another round of refinements focused on A) clearly communicating the relationships between practitioners=*, operator=*, and owner=*; B) solving the character length limit; and C) clearly defining the valid structure of the values with respect to titles and practitioner type suffixes: practitioners=Dr. John Doe, MD vs practitioners=John Doe, MD vs practitioners=Dr. John Doe, M.D. etc. --Lumikeiju (talk) 21:30, 3 February 2025 (UTC)
- I oppose this proposal. I have no expertise in the legal side and therefore cannot comment on the storage of personal data. But I think this aspect should be taken very seriously and it should first be clarified legally what this means for OpenStreetMap before mapping and tagging takes place. --Chris2map (talk) 16:44, 4 February 2025 (UTC)
- I oppose this proposal. 1) We agreed on the number suffix scheme for long tags, but this has not been added to the proposal. 2) My concern about large numbers of practitioners has not been addressed. —M!dgard (talk) 21:38, 5 February 2025 (UTC)
- I approve this proposal. --Enno13 (talk) 14:34, 7 February 2025 (UTC)
- I oppose this proposal. Bedides the legal uncertainies, I vote against introducing more semicolon seperated lists. We have them on cuisine, healthcare:speciality, etc. but most tools still do not handle them as list (taginfo, osm.org) --Agent redd (talk) 09:47, 8 February 2025 (UTC)
- I oppose this proposal. This seems impractical. I also see no reason to store people's names on OSM. --501ghost (talk) 17:37, 8 February 2025 (UTC)
- I approve this proposal. --Watmildon This is collecting data that is already public. It has to be maintained the same as every other key. Consumers will have to deal with variation of input like every other key. There will be awkward cases where it goes beyond the char limit.. like every other key. I do not see any of those issues as specific to this proposal.
- I approve this proposal. --Adiatmad (talk) 03:51, 13 February 2025 (UTC)
- I approve this proposal. --GA Kevin (talk) 14:55, 13 February 2025 (UTC)
- I have comments but abstain from voting on this proposal. I support this idea in principle, but the proposal needs to communicate this idea more effectively to avoid misunderstanding. It's clear to me that this proposal pertains to the public names, prominently posted, of the principals of a professional practice (say that 20 times fast). But it is not clear to a lot of mappers, hence the misplaced concerns about GDPR. – Minh Nguyễn 💬 00:01, 15 February 2025 (UTC)
- You're right, it is not clear (at least to me). My problem is, how is a normal mapper like me supposed to know what is legally permissible and what is not? That is not something that can be clarified quickly, unless I hire a lawyer when I map. For example, is a name next to a doorbell button a sign of active effort to make data public? Are there any boundaries in type and form? Where do I, as a normal person, get the information I need for mapping? And I think it makes a difference whether it is a OSM tag in use or an approved OSM tagging. In the latter case, the approving institution should also provide relevant (legal) information. --Chris2map (talk) 09:53, 15 February 2025 (UTC)