Nein, das ist es nicht, es gibt diverse Probleme wie z.B. Gemeinschaftspraxen (mit mehreren Fachärzten und/oder unterschiedlichen Therapeuten), Praxen in Ärztehäusern (bei Unkenntnis der genauen Raumlagen), stadtweit verteilte Einrichtungen eines Krankenhauses, die sich mit dem Schema besser taggen lassen sollten als mit Healthcare.
Nach dem momentanen OSM-Objektmodell ist man nämlich auf Relationen angewiesen, um komplexere Sachverhalte darzustellen. Statt sich zu z.B. streiten ob z.B. medical=aed nicht emergency=aed sein
müßte, erstellt man einfach einen Node, der jeweils in einer Relation für die beiden Taggingvarianten Mitglied ist und hat das Problem gelöst. Das Beispiel ist jetzt absolut vereinfacht, aber zwigt das Problem auf, das man im Moment hat, wenn weitere Zusatztags hinzu kommen, dann weiß man irgendwann nicht mehr, welche der Zusatztags, sich auf welche Objekteigenschaften beziehen.
Die Alternative ist key:subkey:susubkey=value, usw., nur das kann man nicht vernünftig maschinell auswerten, wenn subtkey je nach Fall frei gewählt werden kann und man in der Anwendung aber susubkey auswerten möchte. Da macht gerade der Ersteller von “Access restrictions 1.5” eben diesen Fehler, der mir bei Healthcare 2.0 schon klar war. Eben aus dem Grunde gibt es ja auch keinen ensthaft im weiten Einsatz befindlichen Tag, mit mehr als einem subkey. Dafür hab ich teilweise bei den Healthcare 2.0 Beispielen, in Bezug auf die Beziehung der verschiedenen Fachrichtungen untereinander, das zuerst oben beschriebene Problem geglaubt lösen zu können, das geht aber nicht. Habe werde die Beispiele dann demnächst anpassen, wenn ich wieder Zeit habe.
Tags für die Krankheiten hat schon die Version 2.0 (disease:*=yes/no), weil wenn man z.B. einen SHG-Treffpunkt taggt, ist es ja schon ganz gut zu wissen, für welche Krankheiten es dort Gruppen gibt.