Loi défibrillateur cardiaque

C’est bien mon propos :wink:
Des coordonnées géographiques agrémentées d’autres données utiles.

@gendy54 le standard permet de plus facilement agréger les données.

C’est quasi indispensable (et même pas suffisant) quand on a un grand nombre d’acteurs qui peuvent être à l’origine de ces données.

L’expérience des infrastructures de recharges pour véhicules électriques (IRVE) ou des adresses montre qu’il est très compliqué d’utiliser des dizaines de jeux de données décrivant en principe le même type d’objet si ils sont tous organisés différemment. Je ne parle même pas du format, mais bien de ce qu’on trouve dans les fichiers.

Pour les IRVE, bien qu’il y ait un arrêté ministériel décrivant le format et des subventions à la clé, le standard n’est que partiellement respecté… c’est là où des outils en ligne de validation permettent de vérifier que le fichier produit est celui attendu et donc permet effectivement d’alimenter une base plus globale, car c’est elle qui sera vraiment utile, pas des centaines ou milliers de fichiers morcelés.

1 J'aime

Oui @cquest ca me semblait tellement évident d’imposer un standard que je me suis pris les pieds dans le tapis.
Dispo donc pour échanger sur le standard.

1 J'aime

http://agora.opendatafrance.net/topic/59a98104d1f0de63576f51c7

1 J'aime

C’est un bon début qui a le mérite de lancer la discussion. Il faudrait jeter un oeil aux autres comme celui d’Issy-les-Moulineaux : https://www.data.gouv.fr/fr/datasets/defibrillateurs/

Je vois pas mal de choses à améliorer sur le “modèle ODF”.

  • tout d’abord je ne vois pas l’intérêt de répéter les coordonnées géographiques : EQUIP_GEOLOCALISATION est redondant par rapport à EQUIP_LAT et EQUIP_LONG je ne garderais que ces deux derniers
  • à quoi sert l’identifiant unique (maintenance ?) ? est-il présent sur l’appareil ? sinon pourquoi ne pas reprendre ce dernier ? sinon comment est-il déterminé ? Lat-lon ne peuvent-ils suffirent pour garantir l’unicité ? l’ID OSM pourrait-il avoir du sens ?
  • COLL_NOM doit être spécifié correctement sans quoi on aura “Bégard”, “BEGARD” ou “BÉGARD”.
  • Pourquoi COLL_NOM ? Ne faudrait-il pas préférer systématiquement le nom de la commune (plus parlant) que celui de la collectivité ? On peut considérer qu’avoir la commune est une information redondante si on a les coordonnées géographiques. Mais dans certains cas d’usage je pense que ce n’est pas une mauvaise pratique. Cela permet à un humain d’identifier la commune sans passer par une cartographie ou un calcul. On parle ici de sauver des vies, ne mégotons pas…
  • COLL_SIRET : dans ton exemple Dominique, je pense que tu as indiqué le code INSEE et pas le SIRET ; soit dit en passant il y a un espace entre 22 et 004 alors que les codes INSEE n’en contiennent pas.
  • COLL_SIRET : je comprends que souvent (tout le temps ?) le DAE est rattaché à un local, un établissement, qui, dans la plupart des cas va posséder un code SIRET. Ce n’est pas idiot mais dans certains cas ce code pourrait changer régulièrement. À voir.
  • LIEU_TYPE : quel usage ? Je comprends que c’est une liste fermée ?
  • Pour l’adresse je pense qu’il faut faire appel à l’expertise de @cquest :wink: Trouver un truc simple mais le plus compatible possible avec la BAN.
  • ACCES_LIBRE : à quoi sert il ? J’imagine qu’en cas de problème cardiaque cette notion n’a plus vraiment court non ?
  • Horaires : ISO 8601 permet de spécifier des intervalles mais je ne sais s’il peut gérer des plages complexes. Je pense qu’il faut creuser un peu.
  • AUTRE_INFORMATIONS : pourquoi faire ?
  • EQUIP_ACCES_PARTICULIER : champ crucial mais plus ou moins bien utilisé dans l’exemple de Dominique ; je pense que ce dernier devrait systématiquement indiquer l’emplacement précis : “Bâtiment B-RdC face à l’ascenseur” est bien vu ; mais je ne vois pas l’intérêt de “Snack Bar”.
  • J’ajouterais bien des informations utiles au suivi du “parc” (utile à l’acteur public ou des assos ou des services de secours ou autres) :
    • la date de dernière observation où l’appareil était présent et paraissait fonctionnel
    • le contact du responsable de l’appareil

Si vous voulez je peux rédiger une spec un peu propre pour embrayer, sachant que ce ne sera qu’une base de travail.

Il faudrait faire rentrer d’autres acteurs dans la conversation. Lesquels ?
SDIS ? Médecins ? ARS ? Croix-Rouge ? Assos sur les risques cardio-vasculaires ? Un type acteur particulier se sent-il la responsabilité particulière de produire ces données ?

Certes on peut discuter longtemps sur le standard à mettre en place.
L’idée de lancer cette discussion est justement d’avoir les bons interlocuteurs.
En effet ODF et d’autres ont ou vont proposer des standard pour différents sujets.
Le HIc c’est que lorsque le gouvernement par décret propose un standard il devient forcément le référentiel à utiliser, d’où ma question sur les échanges avec le gouvernement, il ne sert à rien que l’on discute entre nous s’il n’est pas dans la boucle car au final c’est lui qui tranchera.
On l’a bien vu pour les marchés publics et les subventions!

1 J'aime

Sur la question de la maintenance des standards, je vous conseille de regarder la gouvernance de l’Open Contracting Data Standard : http://standard.open-contracting.org/latest/fr/support/governance/

bonjour,
je me permet d’intervenir sur la structure du fichier (qui est obligatoirement mauvaise puisque créée de manière empirique).

Mais je crois que mon manque de méthode peut aider a trouver une méthode plus efficace ;).
premièrement, histoire de ne pas réinventer la roue j’ai été voir ce qui existait sur https://www.data.gouv.fr/fr/ et je n’ai pas trouvé grand chose de satisfaisant, parfois on a une liste avec des adresses de rues (mais sans commune ni code INSEE) et à mon avis c’est important pour la réutilisation.

Ensuite, çà fait bientôt deux ans que Dominique on s’interroge sur la structure que pourrait avoir un fichier opendata sur le défibrillateur. au fil de sa réflexion @dom_datarmor a commencer à imaginer la structure qu’il a mis en lien

Dans la pratique elle me plait bien, il y a juste un truc que je ne vois pas bien aborder, ce sont les champs Horaire 1 Horaire 2 Horaire 3 en effet on peut avoir des horaires d’accès mais aussi des périodes d’ouverture d’un lieu sur l’année (c’est le cas d’Armoripark à Bégard, le parc est fermé d’octobre a avril et n’est ouvert que quelques jours ou plage horaires dans la semaine hors vacance d’été) bref je ne vois pas bien comment trouver une norme de marquage pour les dates (mais j’ai honte :wink: ).

Comme il nous semblait judicieux de faire un truc qui soit relativement réutilisable ou du moins qui puisse aider à la réflexion, avec la mairie de Bégard on c’est dit qu’on pouvait voir dans le socle commun si un jeu pouvait être un peu le modèle.
celui ci : https://drive.google.com/file/d/1McWh0BBFqiTFW3jlqrkuGYunptW7M9_4/view
nous semblait intéressant.
On a donc remixé les deux (mais c’est loin d’être au point)
Je reviens sur ACCES_LIBRE je pense que çà peut avoir du sens : un défibrillateur n’est pas toujours dans un lieu public (ou géré par un établissement public) , il peut être dans un lieu privé (un immeuble de bureaux, une usine) auquel cas il est bien de savoir qu’il existe, si on en a besoin quand on est à proximité du lieu pendant ses horaire d’ouverture, mais il est tout aussi bien de savoir qu’on n’y aura pas accès hors des horaires d’ouverture.
a la relecture du truc, il m’apparait aussi que la présence d’un champ nommé pour définir l’étage auquel est installé l’équipement pourrait être intéressant pour les immeubles.
Enfin, on c’est emmêlé les pinceaux entre l’INSEE et le Siret (les risque de l’expérimentation).
je note tout çà pour qu’on puisse améliorer le fichier.

Pour recentrer sur le débat de la loi “défibrillateur” effectivement elle va permettre d’avoir un standard (et c’est bien) par contre ce serait bien que çà ne se fasse pas hors sol et que les ébauches et travaux qui ont étés proposés jusqu’à présent en opendata puisse servir de base de réflexion.

En attendant merci a tous et a Dominique d’avoir lancé le débat, j’ai appris plein de choses et j’y vois un peu plus clair.

Nous sommes d’accord. J’ose espérer que c’est Étalab qui se chargera de la spec et qu’on pourra donc dialoguer. Ça ne nous empêche pas d’y réfléchir dès aujourd’hui, d’anticiper un peu les discussions et d’arriver, pourquoi pas, avec des propositions qui permettrons de gagner du temps.

Ça n’était pas si mauvais et ça a eu le mérite de lancer le sujet.

Votre méthode était aussi bien vue :

  • voir l’existant en terme de données afin de voir s’il y a des consensus/dissensus
  • voir l’existant en terme de standards proches afin de réutiliser des “motifs” (par exemple pour l’adresse ou autre)
  • publier ici même pour avoir des premiers retours

Jusqu’ici je trouve que c’est la bonne méthode. Il s’agit sans doute maintenant de mieux cerner les publics et ceux qui devraient pouvoir contribuer.

Oui, ce sujet est épineux mais je pense que certains ont déjà du bosser là-dessus. Je pense notamment @cquest créateur d’OpenEventDatabase.

Je ne comprends pas bien. S’il s’agit d’un établissement géré par un acteur public, prenons une mairie par exemple, on y aura pas plus accès qu’un lieu privé en dehors des horaires d’ouverture. J’aurais tendance à penser que le fait que le lieu soit un lieu public ou privé ne change rien : quand quelqu’un est mal, il est du devoir de chacun de l’assister lorsqu’on en a les moyens non ? (concept de non assistance à personne en danger). Je peux comprendre le distinguo accès permanent vs accès selon des horaires. Mais pas celui public/privé. (Mais je peux me tromper lourdement.)

Est-ce que ce n’est pas rôle de EQUIP_ACCES_PARTICULIER qui permet de préciser justement de préciser l’accès ?

Oui !

Oui merci à tous.

J’ai posé la question de la spécification sur le forum de data.gouv.fr.

effectivement, je reformule il peut arriver (c’est le cas dans ma cambrousse) qu’un défibrillateur public soit de plus accessible sur la voie publique. je reprends l’exemple de ma cambrousse, il y a un défibrillateur posé devant l’entrée du gymnase.

par contre ( mais toujours dans ma cambrousse) le supermarché du coin et une ou deux entreprises ont un défibrillateur, qui n’est pas accessible depuis la voie publique.

c’était là que je faisait la distinction

Je signale que le sujet a été évoqué lors du dernier groupe de travail Open Data de l’Afigéo.
Thomas Portier à l’origine du modèle minimal des Points d’Eau Incendie (PEI) voulait remettre le couvert avec cette thématique proche.
Je pense qu’on remettra ça à l’ordre du jour à la prochaine session.

Idéalement il faudrait que seuls les champs essentiels soient obligatoire.

2 J'aimes

L’Open Data Institute vient de sortir un guide pratique très complet sur les standards de données https://standards.theodi.org Il compile de nombreuses ressources pour comprendre comment créér, développer et favoriser l’adoption des standards …

3 J'aimes

Bonjour à tous,
Pour avoir eu à faire qques recherches récemment, il y a une opération de recensement organisée par L’association arlod. Elle propose un moteur de recherche qui ne permet que d’obtenir une réponse selon une localisation précise mais n’ouvre pas ses fichiers :
https://www.defib-arlod.fr/un-defibrillateur-pres-de-chez-vous

mais peut être faut il creuser…

1 J'aime

Merci pour vos cas “terrain” je comprends un peu mieux. Est-ce une question d’accès depuis la voie publique ou d’accès illimité : dans le cas de votre supermarché je comprends qu’il est parfois fermé (probablement la nuit et le dimanche) et que le défibrillateur n’est pas accessible en permanence ; dans le cas du gymnase je crois comprendre qu’on peut l’utiliser n’importe quand, c’est ça ? Dans le cas où l’accès est possible sans limite, est-ce que la solution n’est pas de préciser que l’accès est possible 24/24-7/7 ? C’est cette information qui compte non ? Du coup la notion ACCES_LIBRE n’aurait plus lieu d’être non ?

Il y a peut-être une bonne raison de garder ACCES_LIBRE mais je ne vois toujours pas pourquoi. Il permet de distinguer plus facilement, avec un peu de redondance, les défibrillateur accessibles 24/24-7/7 ?

Merci Laure nous cherchions des acteurs ayant réfléchi à la question, je pense que ARLoD l’a également déjà fait. On peut retrouver les infos demandés par ARLodD dans un formulaire de déclaration des défibrillateurs sur leur site http://arlod.e-monsite.com/medias/files/formulaire-declaration-dae-arlod-3.pdf
ACCESS_LIBRE c’est accessible 24/24-7/7=oui - heures ouvrables=non + horaire ouverture, tout cela pour moi est la m^me chose juste une histoire de sémantique. il faut simplement s’accorder sur les éléments de réponse dans le corps du tableau pour qu’il soit compréhensible et réutilisable

1 J'aime

J’ai regardé dans le détail. Il y a pas des bonnes choses mais dans l’ensemble et je trouve ça très (trop ?) généraliste.
Les choses intéressantes :

Ce qui est moins bien :

  • ils ont voulu embrasser trop large, du plus petit standard au standard international complet estampillé W3C : il aurait été plus utile je trouve de réduire le champ aux standards plus “simples”, plus “locaux” si je puis dire ; ou de faire des entrées “quick and (not so) dirty standards” ou “standards for dummies”
  • je pense que dans certains cas on peut prendre des raccourcis, des libertés sur la manière et les moyens
  • les grands principes ne sont pas lisibles immédiatement
  • le prisme anglo-saxon est gênant je trouve : pourquoi s’intéresser à d’autres langues et d’autres cultures ? Je note tout de même nos amis de Nord Ouvert : http://standards.theodi.org/community/who-can-i-work-with/opennorth/

Oui merci @LaureHuguenin. Et merci Dominique pour avoir trouvé le formulaire que je cherchais en vain… On voit qu’il n’est pas très différent de ce que l’on propose sauf qu’il ne contient pas de donnée pivot (code INSEE pour la ville). Comme leur base est privée il y a également toutes les données relatives au gestionnaire du défibrillateur, ce qui est intéressant pour des relances par exemple, mais qui pose le problème des données à caractère personnel. Sans doute serait-il utile de créer deux standards : un standard incluant les données “gestionnaire” et l’autre les excluant, les deux partageant le maximum de champs communs. Le premier pourrait ainsi être utilisé par les agents publiques (ou des acteurs privés) pour suivre des “parcs” de machines.

Oui d’accord. C’est le documentation qui doit permettre de comprendre et le nom des champs ne fait qu’aider si possible.

@dom_datarmor je te sens hyper-chaud, on pourrait ouvrir un pad et faire converger toutes nos discussions. En parallèle on peut aussi documenter la façon dont le fait pour pouvoir le refaire sur d’autres cas. Et ça nous permettrait d’avoir une documentation exemplaire sur ce jeu de données.

Je suis souvent partant de faire une première proposition construite pour la mettre en discussion. Mais le petit risque s’est aussi d’assécher la participation si on en fait trop : “c’est leur truc”.