Proposal talk:Healthcare 2.0

Word for particular areas is SPECIALTY not speciality

A minor, but probably more important than it should be, point is that the standard word in English for particular areas of medical practice is SPECIALTY not specialIty. See Specialty (medicine). Given the detailed nature of this proposal I think you would want to engage with medical practitioners, and, at least in the English speaking world, they seem to care about this distinction. I therefore suggest you change the tags to reflect this from speciality=* to specialty=* and in other places in the page where appropriate. SK53 22:49, 16 January 2011 (UTC)

Your contention is that the US word should replace the English. Speciality is the word used in English, Australian etc. The other spelling is a United States spelling. --Drlizau 22:11, 21 February 2011 (UTC)

Yes, this proposal is a try clean up and integrate the health care related tagging. Thank you for pointing out this spelling mistake. I fixed it now. I copied this mistake from the healthcare=* proposal and even missed to see the mistake on wikipedia. Kates auto completition and table markup copy-and-paste-editing then helped distributing it wider. :-( --Fabi2 00:05, 17 January 2011 (UTC)

I've been asked for a little more info on my assertion. Firstly, I spent several years consulting on information systems in the NHS (E&W, Scotland & Northern Ireland): I very rapidly learnt not to use 'speciality' as it more or less told people immediately that one lacked in-depth subject-area knowledge. Secondly, here is a link to the NHS Data Dictionary 'Main Specialty' which shows use of the term from the standard data model for UK healthcare. SK53 (talk) 12:50, 10 January 2016 (UTC)

RFC - To early

Hi Fabi2, thanks for your huge design work on this proposal. But please keep in mind, that we finished the last healthcare=* Proposal just a weeks ago. So currently we didn't finished the cleanup or adding this features to the major editors.

To me it doesn't make sense to reintroduce another scheme after such a short time, without taking the chance to fix the issues we had on healthcare=* after a bigger evolution period? --!i! 07:06, 25 January 2011 (UTC)

Which cleanup up of healthcare=* did you mean? It's problems are be published for at least six weeks now. Some of them can also be read on the discussion page. Why would you integrate a inextensible tagging scheme as healthcare=* into the editors, as it doesn't make the things any better. It should be replaced with something better as soon as possible.

How to tag a medical service (as defined as in this proposal), the offices and it's specialties in a health center or the specialties of some health persons which run a shared medical office with your scheme? It is at least much better then healthcare=*. If you see any real issues with Healthcare 2.0, then please report them. --Fabi2 15:51, 25 January 2011 (UTC)

Too much *:type and _type?

I think this all should be written without the "type" part: health_facility:type, health_service:type, health_person:type, health_amenity:type, counselling_type, room_type. It would be just as clear and you can still use subkeys if there is more information required, e.g.

room=waiting
room:waiting:capacity=35
room:waiting:music=partial
room:waiting:music:opening_hours=Mo-Fr 17:40-18:00
room:waiting:music:genre=classical

--Bk 12:44, 25 January 2011 (UTC)

The problem is, that it is hard to extract any data from keys with more the one subkey. So think of e.g. 1000 room types (e.g. room:waiting:capacity=*, room:sleeping:capacity=*, room:shared:capacity=*, room:class:capacity=*, ...) and then easily try to extract the room capacity of all these rooms e.g for room size map. Because this requires parsing the full key, you will not see more then one subkey in OSM in most cases. There is no clean and easy way to model any type of tree style information besides using a cascade of multiple relations. I think this is, why these subkeys are used by many people.

Now we want at least extensible subkeays as it does not help, if you see people using things like health_facility:clinic=yes on taginfo. The type subtag has been adopted from the Humanitarian OSM Data Model, which makes heavy use of *:type and _type, because of the reason above and to make the scheme extensible for other subkeys when needed. room_type has 242 uses on taginfo, where the more uniform room:type is not used yet. I used existing keys, if I can and thought, there are appropriate. counselling_type is used to reduce the subkey count of the key. The only execption from using type subkeys can be made for health_service:*=yes/no as this key, to be precise and useful, can be treatedas a kind of free text field, if you look at medical_service:*=yes/no on taginfo. I tried to make some abtract categories for health_service:type=* to maybe reduce the problem a little bit, but in most times more then one service is provided and then you will see things like health_service:condom_distribution=yes or health_service:pragnancy_testing=yes again, as they are now now used for medical_service:*=yes/no. I used a different key, because medical_service:*=yes/no is also used for specialties and so maybe are thought in a more general kind of use. --Fabi2 17:52, 25 January 2011 (UTC)

Some ideas

Just some ideas I had when reading the proposal, didn't want to start a new topic for each of them:

• How often will two medical systems be used in one space? Probably not often enough to justify the use of subkeys. Why not use medical_system=chinese and use the semicolon syntax as with other keys (e.g. medical_system=chinese;western). You have that with other proposed tags a lot more and use the key=value[;value] syntax here, like the health_person (of which you have lots in a hospital, don't you).

Tags like key=value1;value2, ... have to be fully parsed, maybe for every subkey, so in don't want to use them. Some universities in China e.g. have a combined hospitals for the western and chinese medical system. Maybe this affects also some other countries in some kind, as I found on the net, that e.g. ayurveeda is also official admitted in India. --Fabi2 02:34, 26 January 2011 (UTC)

In fact, I think parsing key=value[;value] isn't really more difficult. Ok, you can't see them in taginfo directly, but an application can simply do something like contains(valuelist, value) or contains(valuelist, ["start of string"|;]value["end of string"|;] to find out whether a specific value exists. Semicolonsyntax is allowed for every tag, so most applications have to be able to parse them anyway. Apart from the parsing there's no reason to split these tags that only allow yes or no as values. --Errt 15:35, 26 January 2011 (UTC)

With key=value1;value2;..., after the keys have been parsed and seperated by the apllication, the values have to searched many times for finding all the subvalues it includes, this means lots of non-matching character compare operations which can not fast aborted, because the subkey may be still contrained somewhere in the list. E.g. think about tagging a health_facility:type=support_group_home, which commonly contain about 30 support groups, with this scheme. There will be a long list of diseases, which have to be testeg against. --Fabi2 17:53, 27 January 2011 (UTC)

• Not quite sure on the health_person in general. Sure it's interesting to know whether a 'doctor' is a physician or a therapist, but do we really need hospitalss tagged with health_person=physician;therapist;nurse;paramedic;midwife? Probably the type of facility combined with the medical_system is enough to determine the type of health person working there.

The Kibera people use medical_stuff:<role>=<number> for the staff count in health_facilities, but the person role is mainly not thought to unspecific specify who works somewere, but to e.g tag multiple roles and the skill level of a health persons, which works e.g. in a shared office or maybe has a room for their own in a hospital department. --Fabi2 02:34, 26 January 2011 (UTC)

So this is mainly for single doctors or, using relations, for shared offices? --Errt 15:35, 26 January 2011 (UTC)

This is for both cases as needed. I thout also of the case that a physician's office should be tagged with the rooms it includes and the use of the rooms, so if has one or more examinations rooms as in a shred office, they can be tagged with the health_person:* tags, to describe which health person works in which room. --Fabi2 17:53, 27 January 2011 (UTC)

• I agree with Bk, the 'type' in most of the tags seems to be superflous. I understand you would like to have it similar to the Humanitarian Data Model, but apart from that I really can't see the reason for it.

I tried to explain above, that this is mainly for extensibility. Whene not type is used, an other subkey have to be used. Please tell if you have a better one. --Fabi2 02:34, 26 January 2011 (UTC)

Well, currently you have a structure like this: xy_type=a xy_w=b xy_z=c for your extensibility, but having it like this would work the same: xy=a xy:w=b xy:z=c Just look at the type-tag as the default value of xy. Another possibility is xy=a a:w=b a:z=c like many other tags (e.g. power=generator). --Errt 15:35, 26 January 2011 (UTC)

Yes, after I thought about it, it will be changed for extensibility and to unify the tags with the other ones. The problem with tagging like: key1=value1 value1=value2, is that there exist no real relationship or dependeny between value1 as value and value1 as key. This also pollutes useful namesspaces which could be uses for more general keys. See highway=service service=*, service=* have been better used for any provides services by objects. Some people still use this for services provided and so usage overlap an the tag use and meaning may become unclear. --Fabi2 17:53, 27 January 2011 (UTC)

• The proposal should probably deprecate tags like amenity=baby_hatch or medical=aed to avoid having more and more official tags describing exactly the same

a baby hatch is not a medical facility but a public service facility usually maintained by municipal authorities or volunteer organisations. Assigning it to the healthcare environment would be incorrect.Gilbert54 (talk) 20:42, 16 February 2013 (UTC)

People can use every key/tag they want, so you can not really disallow them to use any tags, besides placing a policeman beside every mapper. ;-) There should just be a better tagging scheme. If it convince many people and they use it, then tagwatch/taginfo will "deprecate" the old tags. --Fabi2 02:34, 26 January 2011 (UTC)

I don't say people should not be allowed to use whatever they want. I just think that, if possible, there should be one official, accepted way of tagging something and not five of them. Of course people may use medical=aed, but this would allow to have a bot changing over tags if reasonable. --Errt 15:35, 26 January 2011 (UTC)

• Perhaps merging the health_facilities and health_amenity would be possible. They don't differ that much.

A building or part of a builing has nothing to do with amenities, in this proposal meant in the sense as some kind of technical installation. --Fabi2 02:34, 26 January 2011 (UTC)

Well, at least both of them are places I go to in order to get something (in this case a health related service). We do have this with other tags, too: amenity=bank normally is a building, amenity=atm a technical installation. Ok, this causes some problems as these can often be combined, still I don't see the real difference. If you want to make clear something is a building or part of one, use building=yes on it. --Errt 15:35, 26 January 2011 (UTC)

But why we use any different keys? We could use amenity=* for everything. ;-) To describe the objects as good as possible, you first have to split them in an optimal count of groups. This is what I have done and why health_amenity exists. Now, you have in most cases two kind of objects in amenity=* buildings and some kind of technical installations. Maybe health_amenity:* should be renamed, but I had no idea how i could better name this. --Fabi2 17:53, 27 January 2011 (UTC)

• Excluding the health_specialty from this proposal could save have of the page and make it more clear. The proposal works without it and an additional proposal could introduce the specialties. Education as a value for specialties could be misleading. First thought that would mean that specialty is taught there. Perhaps 'educated', 'skilled' or 'trained' is better?

The use of the other objects just make sense, if they are finer described by the specialties. Good suggestion to look at, and maybe change, "education" to e.g. "trained". --Fabi2 02:34, 26 January 2011 (UTC)

"Education" has now be changed to "trained", which is more appropriate the "skilled", if now every health person which have be trained is really good in it's specialty. --Fabi2 23:22, 27 January 2011 (UTC)

• Same for the counselling. It's not directly related to the main purpose of the proposal and would make a great proposal itself. My first point applies on this, too: counselling=drugs;homeless would probably be ok, too, without making it more difficult than needed.

Couselling, if not preventive, can be considered a kind medical life enhancement therapy or "psychotherapy" such as self help.

I agree it is a part of health. What I mean is that counselling as it is proposed here, works without the rest of this proposal and the rest of the proposal works without this part. People might not want to use the scheme proposed here but still could need the counselling part, so I think it would be an idea to just make a seperate proposal out of it. --Errt 15:35, 26 January 2011 (UTC)

This is why I used counselling_type:* and not health_counselling_type:*, maybe someone whould do a proposal for general couselling and counselling_type:* can also be used there. But I want health care related counselling and not want first have to write a general counselling proposal, to just have tags for a few helth care related counselling facilities. --Fabi2 17:53, 27 January 2011 (UTC)

• You use councelling in the health_service but counselling for its type.

Thanks, this was a silly typo, if someone find an other one, feel free to correct them. --Fabi2 02:34, 26 January 2011 (UTC)

• Excluding the rooms would be a good idea, too. We currently have no accepted way of mapping building insides, so why bloat this proposal with something that general.

In this proposal I tried to make a complete scheme for the healthcare systems, such room types are included, but in most cases mapping will not be possible, so this can be maybe done in some later proposal. But on the other side room_type=* is already used on taginfo, so this extends only a key, which is already used.

room_type has now changed to room:tye for extensibility and to be uniform with the other tags. --Fabi2 23:22, 27 January 2011 (UTC)

• Provided_for could be changed to something like access which is quite similar and well known. Values should allow more than yes/no, at least something like 'partial'. Subkeys should include 'adult'.

The key access=women means the facility is only allowed to be used by women, where provided_for:women=yes, means, that the e.g. violence counselling is provided to women, but e.g. men can also enter the facility, but there is no counselling for them. So this is not like access=*.

There's some difference, that's true, but for the main purpose it is: Men don't get the service that is provided there, so there's hardly a reason to go there. But if you want to keep provided_for, that's ok, just add 'adult' and think about adding a 'partial' value. --Errt 15:35, 26 January 2011 (UTC)

"Adult" has been added. social_facility:* already defines nearly the same tag, and at least some people have voted for this, but these tag should be a provided_for:*=* which is clearly restricted to person groups and allows more as one value without using ";". It should also include no functional aspects as social_facility:for=drug_addivted which more described the facility itself it it is someone related to drug abuse, where it have been better social_facility:for=addicted social_facility=drug_abuse. --Fabi2 17:53, 27 January 2011 (UTC)

• What about replacing bed_capacity by capacity:beds (or capacity:bed) and add capacity for general capacity (though not quite sure how to define that, either by time (x persons/hour or so) or just for e.g. dentists that have like three rooms they can treat patients in (in this case it would be capacity=3)). capacity:waiting_room would be another possible addition.

I don't found this already existing tag, so it will be changed to capacity:bed=*, this is the overall count of beds in an health_faciliy. health_facility:patients_per_day=* is already used for the patient capacity on taginfo, but i did not define it, as it can be defined as subkey of health_facility:*=yes/no if needed.

• As I'd see 'damaged=yes' as completely damaged, I'd rather have the values for damaged 'yes/partial/no' or the like.

damaged=yes and damaged=partial is the same for me and has been taken from the HOT tagging scheme. Better is maybe to replace damaged=completely with ruins=yes, but the tag is described to be restricted to historic ruins only. --Fabi2 02:34, 26 January 2011 (UTC)

damaged=* now also removed to nor overload the proposal, HOT should fix this for their own. --Fabi2 23:22, 27 January 2011 (UTC)

• For diseases I'd prefer the semicolon syntax. You'll never specify all treated diseases if there a more than a handful and that should be ok with semicolons.

See above. --Fabi2 02:34, 26 January 2011 (UTC)

• Exclude spoken_language and propose it seperately. It's very general and could be used for everything, e.g. restaurants, too. Semicolon syntax might be an idea here, too.

Maybe I exclude spoken_language:*, as it also should be worked out a little bit more and is only a usefull add-on tag, which is not really needed for this proposal.

Yes, this should be worked out a little more in an other proposal. I got this attribute from one german physician search engine. --Fabi2 23:22, 27 January 2011 (UTC)

• In both relation examples, I think you could combine them into one object, as they don't overlap (there's no western tuina or so). Especially in the first example I think two relations is not a good idea as it's only one person. In general: Are health_persons always meant to be mapped with relations? Or should I tag them on the node or area of the facility if possible?

In general, the relation should only be used if needed. In the first example the area is tagged as office of an physician for psychiatry. But the person itself is also a trained psychotherapist. The first relation can be omittet, as the tags can be combined on the area. I should check the examples, as they have been used to create the tags in this proposal. And it was clear that i need a relation, but it's detailed use was one of the last things I defined. --Fabi2 02:34, 26 January 2011 (UTC)

• Explain the idea of the health relations more. I don't see how and especially why they should be used (ok, there's the two examples, but better description in the section on the relations would help).

This relation can be thought as a special site-realtion, which includes also person roles. If you have a hospital which has some departments with facilities in different suburbs, then it can be used to group the facilities together. site is to unspecific without definig somthing as site=bla, but there is nothing defined and is not intended as container e.g. for a person role itself.

• Do we really need medical_system=western on a standard baby hatch? Isn't that something quite general (if it even exists in other medical systems)

There are always dependencies to the cultural background, even if thre is not influence, I think it is better to alweays use this tag. --Fabi2 02:34, 26 January 2011 (UTC)

• Why keeping amenity=dentist but replacing amenity=doctors?

amenity=doctors should not be replaced, it was intended that is would also be used in addition, has now be more clearly stated. --Fabi2 02:34, 26 January 2011 (UTC)

--Errt 23:11, 25 January 2011 (UTC)

health_service:type=* is a bad idea

Now found a facility, which provides child care besides nursing, if it is needed. So it will be changed to health_service:*=yes/no and the few affected objects will be corrected by me. --Fabi2 04:48, 6 February 2011 (UTC)

I now fixed this and annother small restriction. These nursing sercives where a real suprise as i forgot, that they many of them are run by companies, which only does that and don't fall under health_servive:*, as i first thougth of this tags a an extention for assisted living e.g. social_facility=*. But now these should be tagged as health_facility:type=office, office=nurse and optional some nursing:*=yes/no tags for the kind of nursing, which I will have to create. The schmee works OK otherwise, at least as I tried it out until now. --Fabi2 22:27, 7 February 2011 (UTC)

No, now after I looking at all these nursing specialties, I think, this would really out of scope, so I leave this as possiblle extension of this proposal. If someone wants more then a "this is a nursing company"-tagging with health_facility:type=office and office=nurse, then the nursing specialty can also be put into health_specialty:*=yes/no. --Fabi2 21:49, 8 February 2011 (UTC)

Physician's Office

Here you are using a US type name, and it does not get used at all like that in the remainder of the English speaking world.

In most of the English speaking world, physician is a speciality, not the general name, which is still doctor. Even in the US, the word doctor is understood, and in other European languages a word which sounds like doctor is used.

Drop physician except for the speciality physician.

And the quantity of information?? I've worked within healthcare for more than 30 years and I don't have a use for all the information that you are proposing to collect within our work information system. It has no sign of being truly extensible as it is based on the concept of one healthcare provider in the same physical spot at all times. What about a room or space leased out on different days to different visitors? For example we rent out to audiologist, psychiatrist, dietitian, social worker, oro-facial surgeon, sleep medicine technician. --Drlizau 22:08, 21 February 2011 (UTC)

Have you noticed, that the proposal will also propose a relation of type=health? One of the reasons why it exists are just such complex cases as you have described.

You can also use a Chain of more the one type=health relations, as the OSM data model would not support building information trees in any other kind.

If you want, you can define your own health_person:type=doctor and add it to any health_facility:type=* you want. But I don't will propose "doctor" until now, as not every physician has become :an doctor/Ph.D. And when you see the tags it as equal, then also physician will do. --Fabi2 16:15, 19 April 2011 (BST)

landuse=healthcare

currently people use amenity=hospital on the building as also for the area on which the hospital is located (so it gets rendered nicely with a different color in mapnik), which leads to improper search results, since those two objects are always represented as dedicated hospitals in the result. i therefor think it might be a good idea to introduce a landuse=healthcare with this proposal as a solution to this problem. also a lot of times more than one hospital is located on the same (big) property, often sharing a recreation area like a park for example. this way, renderers still could draw the background differently, but search results would actually be correct, since only the actual facilities, tagged as hospitals, would be used. --Flaimo 13:25, 16 April 2011 (BST)

Yes, this is a good idea. This can also be done as separate proposal, as it already works with amenity=hospital and the other tags that we have until now. --Fabi2 16:29, 19 April 2011 (BST)

health_person:type may be unnecessary

At one point in the discussion above you list healthperson:type I think this is unnecessary. This is a map, not an all inclusive does everything scope. There needs to be some limit. Mapping the types of people is unnecessary when you are already defining what specialties are within a structure.

I also have a suggestion, for an active first aid station that is staffed, for instance an ambulance station the icon should be a green cross/crecent, with the hospital icon being a red cross/crecent. Rjhawkin 02:57, 31 July 2011 (BST)

This is a database about the reality. The reality is most times more complex then every model can express, so it is good to allow finer definitions in the model.

health_person:type=* is there, because the specialities and even the services a facility offer, in health care highly rely on the type and count of persons working there. There may be the case, that the facility is a shared office and the physician's have different working times. They may even have got additional training in specialities that they can not provide there, as e.g. more resources are required for it, such as additional staff and equipment (e.g. for surgeries). --Fabi2 00:09, 19 February 2012 (UTC)

health_person:type=* is needed, but there was bug at least in the example page, which leads to ambiguous data (but was a complex example which was nearly used by anyone and where it was, I will see if I can fix it). In a health facility there are working some health persons, which can be tagged with health_person:type=*, but then the shortcut version with office=*, which just says something like "e.g. most of the persons in this health facility are pycicians" must be omitted, as the detailed data which really works there will be expected to be tagged with health_person:type=* in relations on the object.

And if you ask, why health_person:type=* is not e.g. health_person:pyhsician=yes/no, as there are a few exeptions, such as with the pysician of psychiatry, which are most also trained in psychotherapy, then I annswer you: This is because some people already crying because of the complexity and because this, as far as I know, affect only a few cases, where the other role can be put in a child relation of the first person role. It is also easier for queries like "I want all health persons for ...". --Fabi2 21:57, 22 February 2012 (UTC)

Too complex perhaps

Why using all the subtags with yes/no?

Now I tagged a physiotherapist as: office=therapist health_specialty=physiotherapy name=*

It's simpler than health_specialty:physiotherapy=yes, for medical offices you could use office=therapist/doctor/[..] and health_specialty=dentist/generic/physiotherapy and so on --Sarchittuorg 11:18, 20 January 2012 (UTC)

Please read Talk:Proposed_features/Healthcare#To_complicated_and_static for the answer.

Yes, this may be complex, but I tried to make the tagging usable also for new mappers. The model used is relative simple:

In a given medical system there are a) a locality of a health facility, b) another kind of facility which provides some medical services or c) some non-living, most technical, installation, such as an aed. For a) such a health facility can contain another health facility, such as a hospital, which contains some departments. For a) and b) there must be some health persons working there, which provides the services, but they can also contain c) or may provide b) in addition. But in case of a health care related service, you may be more interesed in the kind of the, usually limited, service as in the kind of person. But there is of course a difference, if the service is provided by a paramedic, which is only trained for help in emergencies or a physician.

The (re)use of office=* is only there for mapper like you, as it saves you from using relations to specify the health persons and is most times good enough for a office, at least it is far more exact as amenity=doctors. --Fabi2 22:46, 22 February 2012 (UTC)

Hospital premises not for healthcare

I was tagging an hospital and I don't know how to tag premises that aren't used to provide care, but are necessary : laundries, staff room, technical service office... They are common to most of healthcare structures. We can think about tag it. Maybe with something like health_annex:*=yes/no. --PanierAvide 19:13, 24 June 2012 (BST)

My idea for room level indoor mapping, which is still experimental, as there is no common way to do it, was to use something like room:type=* e.g. with room=yes, but room=* e.g. room=shared may be better and easier. For an office I would use e.g. room=office and a health_person:type-relation on it for every person which work there. --Fabi2 16:57, 26 June 2012 (BST)

I was thinking at building level (in the hospital I surveyed, laundry and technical service are in separated building), so I didn't look at the room=* key. But it fits to the situation. Thanks :) --PanierAvide 17:52, 27 June 2012 (BST)

Sorry, that I don't understand, that you mean buildings. For general-use buildings I would use health_facility:type=department + name=* + other matching tags. At least in Germany it is common to have multiple stacked departments in each other. Many times they are in different buildings or even spread over the whole town/city (e.g. for Berlin Charite) so type=health-relations should be used, as it does not fit into a simple is-in schema any longer. --Fabi2 22:10, 27 June 2012 (BST)

Missing services: health facilities

Nothing in the proposal to take into account personal medical equipements and facilities.

E.g. auditive assistance (tagged as shop=electronics ???), prothesis, wheelchairs, and various equipments for disabled or ill persons... Also salers of medical oxygen, breath helpers, health monitoring (electronic or not, including insuline testers, not always sold in physician shops), medical kits, and resalers of personal assistive equipments for every day life (e.g. special beds, equipment for bathrooms or toilets, adapted phones, adaptation of vehicles in some garages, for driving without legs, or lifts and for bringing into a car or minibus with a wheelchair, or lifts at home for persons with reduced or difficult mobility...). — Verdy_p ^(talk) 06:21, 13 June 2013 (UTC)