Jeu de données : Données hospitalières relatives à l'épidémie de COVID-19
Titre : Les données hospitalières dans le dashboard gouvernement.fr (https://www.gouvernement.fr/info-coronavirus/carte-et-donnees)
Date : 2020-05-07 12:27

Je viens de remarquer de la cohérence dans l'incohérence des totaux qui sont affichés à gauche de la carte du gouvernement !

Il y a cependant quelques gros écarts pour des jours dont les totaux ne correspondent pas du tout avec le jeu des données hospitalières ("départements, sexe"). Pourtant, pour ces journées comme pour les autres, les sous-totaux de chaque région et département correspond exactement aux data du fichier hospitalier.
- certains totaux France sont complètement faux mais uniquement pour six journées : 18, 19, 21, 22, 25 mars et 28 avril.
- il y a aussi une erreur de 40 dans le total "France" des retours à domicile pour la journée le 15 avril ; la valeur saisie est de 30995 au lieu de 30955 dans le fichier si on additionne tous les départements (sexe 0) - le dashboard du point épidémique quotidien pour ce jour est juste lui aussi : 30955 le 15/04).

Il y a ensuite un écart entre les totaux du fichier et du tableau pour chaque jour à partir du 23 mars (sauf le 24 où les sommes sont identiques) mais cela me semble cohérent : le 24 mars, les totaux sont identiques car c'est le jour où il y a cette ligne dans le fichier sans numéro de département. Il semble que cette série commence le 23 mars avec 2 hospitalisés et 2 réanimations puis, les 13 hosp, 13 rea, du 24 mars et ça continue de croître tous les jours avant de redescendre :





Ce sont les différences entre les totaux journaliers du fichier et ceux du tableau ; j'ai ajouté une colonne cumulant le nombre d'hospitalisés, de radiés et de décédes (nombre de personnes au total) ; puis un champs pour noter les valeurs erronnées :

"date";"hosp";"rea";"rad";"dc";"hosp+rad+dc";"err"
2020-03-18;654;160;184;46;884;err
2020-03-19;388;120;120;45;553;err
2020-03-20;0;0;0;0;0
2020-03-21;272;72;0;37;309;err
2020-03-22;286;72;83;42;411;err
2020-03-23;2;2;0;0;2
2020-03-24;0;0;0;0;0
2020-03-25;-533;-108;-185;-57;-775;err
2020-03-26;25;24;1;0;26
2020-03-27;31;29;0;0;31
2020-03-28;40;37;0;0;40
2020-03-29;43;40;0;0;43
2020-03-30;62;51;1;0;63
2020-03-31;85;69;1;0;86
2020-04-01;96;77;1;0;97
2020-04-02;115;94;1;0;116
2020-04-03;130;106;1;0;131
2020-04-04;140;115;1;0;141
2020-04-05;144;119;1;0;145
2020-04-06;153;124;1;0;154
2020-04-07;156;127;1;0;157
2020-04-08;158;129;1;0;159
2020-04-09;159;129;1;0;160
2020-04-10;159;129;1;0;160
2020-04-11;161;131;1;0;162
2020-04-12;161;131;1;0;162
2020-04-13;161;131;1;0;162
2020-04-14;161;131;1;0;162
2020-04-15;156;126;43;0;199
2020-04-16;133;109;6;7;146
2020-04-17;129;105;6;8;143
2020-04-18;124;100;6;8;138
2020-04-19;124;100;6;8;138
2020-04-20;122;99;6;8;136
2020-04-21;122;99;6;8;136
2020-04-22;114;91;6;11;131
2020-04-23;106;86;6;11;123
2020-04-24;104;85;7;11;122
2020-04-25;103;84;7;11;121
2020-04-26;103;84;7;11;121
2020-04-27;101;82;7;11;119
2020-04-28;-123;-5;564;134;575;err
2020-04-29;98;79;7;12;117
2020-04-30;91;72;7;13;111
2020-05-01;78;59;8;19;105
2020-05-02;76;57;8;19;103
2020-05-03;76;57;8;19;103
2020-05-04;76;57;8;19;103
2020-05-05;74;55;8;19;101
2020-05-06;71;52;9;19;99
En fait, il semblerait qu'il s'agisse des transferts à l'étranger qui sont simplement ajoutés manuellement aux totaux du fichier hospitalier. En effet, il n'est pas possible de les classer hors département - d'où cette ligne orpheline du 24 mars avec 13, 13. Il Les totaux du tableau sont entrés manuellement puisqu'ils ne sont pas calculés à partir des champs détaillés. De ce fait, il y a aussi des erreurs pour certains jours.

Selon moi, le 6 mai, il y avait 71 hospitalisés dont 52 en réanimation, 9 retours à domicile et 19 décès à l'étranger. La valeur du nombre de personnes à l'étranger diminue (même en comptant les décès) car il doit y avoir conjointement des rapatriations vers des hôpitaux en France mais sans qu'il soit possible de les voir apparaître dans le détail.
Autant poster le tableau complet:
Lignes :
- FR1 : totaux journaliers, sexe "0" : donnees-hospitalieres-covid19-2020-05-06-19h00.csv"
- FR2 : totaux journaliers de la table "France" du dashboard gouvernement.fr
- FR3 = FR2 - FR1 (valeur nulle attendue)

Champs :
- "tot_pers" = hospitalisés + décédés + radiés => nombre total de personnes hospitalisées
- "tot_dash" = nombre total de personnes hospitalisées (chiffres clés du point journalier à partir du 4 avril)
- "écart" : différence entre "tot_pers" et "tot_dash"

"type";"jour";"hosp";"rea";"rad";"dc";"tot_pers";"tot_dash";"écart";"erreur"
FR1;2020-03-18;2972;771;816;218;4006;;;
FR2;2020-03-18;3626;931;1000;264;4890;;;x
FR3;2020-03-18;654;160;184;46;884;;;
FR1;2020-03-19;4073;1002;1180;327;5580;;;
FR2;2020-03-19;4461;1122;1300;372;6133;;;x
FR3;2020-03-19;388;120;120;45;553;;;
FR1;2020-03-20;5226;1297;1587;450;7263;;;
FR2;2020-03-20;5226;1297;1587;450;7263;;;
FR3;2020-03-20;0;0;0;0;0;;;
FR1;2020-03-21;5900;1453;1811;525;8236;;;
FR2;2020-03-21;6172;1525;1811;562;8545;;;x
FR3;2020-03-21;272;72;0;37;309;;;
FR1;2020-03-22;6954;1674;2117;632;9703;;;
FR2;2020-03-22;7240;1746;2200;674;10114;;;x
FR3;2020-03-22;286;72;83;42;411;;;
FR1;2020-03-23;8673;2080;2567;860;12100;;;
FR2;2020-03-23;8675;2082;2567;860;12102;;;
FR3;2020-03-23;2;2;0;0;2;;;
FR1;2020-03-24;10176;2516;3281;1100;14557;;;
FR2;2020-03-24;10176;2516;3281;1100;14557;;;
FR3;2020-03-24;0;0;0;0;0;;;
FR1;2020-03-25;12072;2935;4085;1388;17545;;;
FR2;2020-03-25;11539;2827;3900;1331;16770;;;x
FR3;2020-03-25;-533;-108;-185;-57;-775;;;
FR1;2020-03-26;13879;3351;4947;1696;20522;;;
FR2;2020-03-26;13904;3375;4948;1696;20548;;;
FR3;2020-03-26;25;24;1;0;26;;;
FR1;2020-03-27;15701;3758;5698;1995;23394;;;
FR2;2020-03-27;15732;3787;5698;1995;23425;;;
FR3;2020-03-27;31;29;0;0;31;;;
FR1;2020-03-28;17580;4236;6624;2314;26518;;;
FR2;2020-03-28;17620;4273;6624;2314;26558;;;
FR3;2020-03-28;40;37;0;0;40;;;
FR1;2020-03-29;19311;4592;7131;2606;29048;;;
FR2;2020-03-29;19354;4632;7131;2606;29091;;;
FR3;2020-03-29;43;40;0;0;43;;;
FR1;2020-03-30;20946;5056;7923;3024;31893;;;
FR2;2020-03-30;21008;5107;7924;3024;31956;;;
FR3;2020-03-30;62;51;1;0;63;;;
FR1;2020-03-31;22672;5496;9443;3523;35638;;;
FR2;2020-03-31;22757;5565;9444;3523;35724;;;
FR3;2020-03-31;85;69;1;0;86;;;
FR1;2020-04-01;24543;5940;10934;4032;39509;;;
FR2;2020-04-01;24639;6017;10935;4032;39606;;;
FR3;2020-04-01;96;77;1;0;97;;;
FR1;2020-04-02;26131;6305;12427;4503;43061;;;
FR2;2020-04-02;26246;6399;12428;4503;43177;;;
FR3;2020-04-02;115;94;1;0;116;;;
FR1;2020-04-03;27302;6556;14007;5091;46400;;;
FR2;2020-04-03;27432;6662;14008;5091;46531;47055;524;
FR3;2020-04-03;130;106;1;0;131;;;
FR1;2020-04-04;28003;6723;15437;5532;48972;;;
FR2;2020-04-04;28143;6838;15438;5532;49113;49684;571;
FR3;2020-04-04;140;115;1;0;141;;;
FR1;2020-04-05;28747;6859;16182;5889;50818;;;
FR2;2020-04-05;28891;6978;16183;5889;50963;51557;594;
FR3;2020-04-05;144;119;1;0;145;;;
FR1;2020-04-06;29569;6948;17249;6494;53312;;;
FR2;2020-04-06;29722;7072;17250;6494;53466;54036;570;
FR3;2020-04-06;153;124;1;0;154;;;
FR1;2020-04-07;29871;7004;19336;7091;56298;;;
FR2;2020-04-07;30027;7131;19337;7091;56455;57021;566;
FR3;2020-04-07;156;127;1;0;157;;;
FR1;2020-04-08;30217;7019;21253;7632;59102;;;
FR2;2020-04-08;30375;7148;21254;7632;59261;59849;588;
FR3;2020-04-08;158;129;1;0;159;;;
FR1;2020-04-09;30608;6937;23205;8044;61857;;;
FR2;2020-04-09;30767;7066;23206;8044;62017;62641;624;
FR3;2020-04-09;159;129;1;0;160;;;
FR1;2020-04-10;31108;6875;24931;8598;64637;;;
FR2;2020-04-10;31267;7004;24932;8598;64797;65420;623;
FR3;2020-04-10;159;129;1;0;160;;;
FR1;2020-04-11;31159;6752;26390;8943;66492;;;
FR2;2020-04-11;31320;6883;26391;8943;66654;67312;658;
FR3;2020-04-11;161;131;1;0;162;;;
FR1;2020-04-12;31665;6714;27185;9253;68103;;;
FR2;2020-04-12;31826;6845;27186;9253;68265;68925;660;
FR3;2020-04-12;161;131;1;0;162;;;
FR1;2020-04-13;31952;6690;27717;9588;69257;;;
FR2;2020-04-13;32113;6821;27718;9588;69419;70097;678;
FR3;2020-04-13;161;131;1;0;162;;;
FR1;2020-04-14;32131;6599;28804;10129;71064;;;
FR2;2020-04-14;32292;6730;28805;10129;71226;71903;677;
FR3;2020-04-14;161;131;1;0;162;;;
FR1;2020-04-15;31623;6331;30952;10643;73218;;;
FR2;2020-04-15;31779;6457;30995;10643;73417;74030;613;30955
FR3;2020-04-15;156;126;43;0;199;;;
FR1;2020-04-16;31172;6139;32806;11053;75031;;;
FR2;2020-04-16;31305;6248;32812;11060;75177;75853;676;
FR3;2020-04-16;133;109;6;7;146;;;
FR1;2020-04-17;31061;5922;34414;11470;76945;;;
FR2;2020-04-17;31190;6027;34420;11478;77088;77825;737;
FR3;2020-04-17;129;105;6;8;143;;;
FR1;2020-04-18;30515;5733;35977;11834;78326;;;
FR2;2020-04-18;30639;5833;35983;11842;78464;79203;739;
FR3;2020-04-18;124;100;6;8;138;;;
FR1;2020-04-19;30486;5644;36572;12061;79119;;;
FR2;2020-04-19;30610;5744;36578;12069;79257;79988;731;
FR3;2020-04-19;124;100;6;8;138;;;
FR1;2020-04-20;30462;5584;37403;12505;80370;;;
FR2;2020-04-20;30584;5683;37409;12513;80506;81251;745;
FR3;2020-04-20;122;99;6;8;136;;;
FR1;2020-04-21;29984;5334;39175;12892;82051;;;
FR2;2020-04-21;30106;5433;39181;12900;82187;82916;729;
FR3;2020-04-21;122;99;6;8;136;;;
FR1;2020-04-22;29627;5127;40651;13225;83503;;;
FR2;2020-04-22;29741;5218;40657;13236;83634;84342;708;
FR3;2020-04-22;114;91;6;11;131;;;
FR1;2020-04-23;29113;4967;42082;13536;84731;;;
FR2;2020-04-23;29219;5053;42088;13547;84854;85512;658;
FR3;2020-04-23;106;86;6;11;123;;;
FR1;2020-04-24;28554;4785;43486;13841;85881;;;
FR2;2020-04-24;28658;4870;43493;13852;86003;86657;654;
FR3;2020-04-24;104;85;7;11;122;;;
FR1;2020-04-25;28119;4641;44587;14039;86745;;;
FR2;2020-04-25;28222;4725;44594;14050;86866;87524;658;
FR3;2020-04-25;103;84;7;11;121;;;
FR1;2020-04-26;28114;4598;44896;14191;87201;;;
FR2;2020-04-26;28217;4682;44903;14202;87322;87985;663;
FR3;2020-04-26;103;84;7;11;121;;;
FR1;2020-04-27;27954;4526;45506;14486;87946;;;
FR2;2020-04-27;28055;4608;45513;14497;88065;88712;647;x
FR3;2020-04-27;101;82;7;11;119;;;
FR1;2020-04-28;27607;4392;46322;14676;88605;;;
FR2;2020-04-28;27484;4387;46886;14810;89180;89818;638;
FR3;2020-04-28;-123;-5;564;134;575;;;
FR1;2020-04-29;26736;4128;48221;15041;89998;;;
FR2;2020-04-29;26834;4207;48228;15053;90115;90753;638;
FR3;2020-04-29;98;79;7;12;117;;;
FR1;2020-04-30;26192;3947;49469;15231;90892;;;
FR2;2020-04-30;26283;4019;49476;15244;91003;91615;612;
FR3;2020-04-30;91;72;7;13;111;;;
FR1;2020-05-01;25809;3819;50204;15350;91363;;;
FR2;2020-05-01;25887;3878;50212;15369;91468;92087;619;
FR3;2020-05-01;78;59;8;19;105;;;
FR1;2020-05-02;25751;3770;50554;15468;91773;;;
FR2;2020-05-02;25827;3827;50562;15487;91876;92491;615;
FR3;2020-05-02;76;57;8;19;103;;;
FR1;2020-05-03;25739;3762;50776;15564;92079;;;
FR2;2020-05-03;25815;3819;50784;15583;92182;92799;617;
FR3;2020-05-03;76;57;8;19;103;;;
FR1;2020-05-04;25472;3639;51363;15807;92642;;;
FR2;2020-05-04;25548;3696;51371;15826;92745;93372;627;
FR3;2020-05-04;76;57;8;19;103;;;
FR1;2020-05-05;24701;3375;52728;16041;93470;;;
FR2;2020-05-05;24775;3430;52736;16060;93571;94191;620;
FR3;2020-05-05;74;55;8;19;101;;;
FR1;2020-05-06;23912;3095;53963;16218;94093;;;
FR2;2020-05-06;23983;3147;53972;16237;94192;94798;606;
FR3;2020-05-06;71;52;9;19;99;;;
oui cela a deja fait l'objet de plusieurs remarques , vous pourriez aussi vous "amuser" à regarder les ecarts du dashboard de SPF entre 2 jours 
Aucune réponse n'a été apportée à ces anomalies à ma connaissance et d'ailleurs on peut dire qu'en regle generale , il n'y a pas de réponse officielle sur ce forum qui est en autogestion 
J'ai compris assez vite les écarts du SPF du fait que les deltas proviennent du fichier incid.

En fait, je trouve que les données du tableau gouvernement.fr sont plus cohérentes qu'elles n'en avaient l'air à première vue. Il semblerait que cette plateforme dispose d'un jeu de données supplémentaires pour les patients traités à l'étranger qui n'a toujours pas été publié jusqu'ici.

Ce qui me manque maintenant, ce sont ces retours de l'étranger. Parmi les 183 patients qui ont été envoyés en Allemagne, Autriche, Suisse ou Luxembourg, visiblement, il y en a 19 qui sont décédés, 71 qui sont toujours en cours de soins mais 93 qui sont déjà rentrés ; il y aurait deux possibilités pour le retour :
- soit par une décharge de l'hôpital où ils étaient traités ; a priori, c'est le cas seulement de 9 patients
- soit par un reprise en charge hospitalière en France ; a priori, pour les 84 patients restants.

Cela explique aussi la différence entre GEODES et cette plateforme car GEODES précise bien qu'ils ne comptabilisent pas du tout dans leurs stats les patients pris en charge à l'étranger.
Vous pouvez aller lire ce qu'on a dit sur cet autre lien data.gouv 
https://www.data.gouv.fr/fr/datasets/donnees-relatives-aux-transferts-de-patients-atteints-de-covid-19/

mais les données n'ont pas bougé depuis la première mise à disposition 

Le tableau que vous citez est alimenté par un github , je pense que vous le savez, pour lequel tous les jours il y a 2 lignes au niveau France :

date,granularite,maille_code,maille_nom,cas_confirmes,cas_ehpad,cas_confirmes_ehpad,cas_possibles_ehpad,deces,deces_ehpad,reanimation,hospitalises,gueris,depistes,source_nom,source_url,source_archive,source_type
2020-05-05,pays,FRA,France,132967,71692,34108,,16060,9471,3430,24775,52736,,Ministère des Solidarités et de la Santé,,,ministere-sante
2020-05-05,pays,FRA,France,,,,,16041,,3375,24701,52728,,OpenCOVID19-fr,,,opencovid19-fr


Désolé pour la mise en forme , mais sur ce site les valeurs non renseignees entre 2 virgules n'apparaissent pas et meme les virgules disparaissent ...
Le dataset des transferts ne couvre que les départs, ce qui permet quand même de savoir qu'il y a eu 183 transferts vers les autres pays européens dont les dates correspondent aux écarts avec le fichier hospitalier et GEODES ; c'est de là dont j'ai tiré ce chiffre pour les départs.
Quant aux retours, et le devenir de ces patients, j'ai simplement trouvé nada via Santé Publique, les ARS, etc. Donc je ne crois pas qu'il s'agisse de données compilées mais bien d'une autre source. J'ai aussi la totalité du fichier opencovid19 et je n'ai rien vu au niveau du sort des transférés. Or, la série que révèle le différentiel avec le dataset hospitalier est bien trop cohérente pour que ce soit juste un hasard.
Dans la discussion correspondante , j 'ai posé explicitement la question : 
Faut il comprendre que l’écart des hospitalisés donnés par le fichier des données hospitalières et les chiffres qu’on retrouve sur le portail SPF correspondent aux transferts à l’étranger , cela avait semblé correspondre en tous cas à un certain moment
Si on regarde l’ écart en nombre d’hospitalisés le jour dit depuis une semaine il est passé de 122 à 104 , et comme dans votre fichier il y a eu 183 transferts étrangers , cela voudrait dire qu’il ne reste plus que 104 personnes à l’étranger.
De la meme facon depuis quelques jours il y a un écart constant de 11 deces entre les données hospitalières et le chiffre du portail SPF , peut on interpreter cet écart comme les décès de personnes à l’étranger ?

La réponse du propriétaire du site : Etalab a été : 
Les transferts participent aux écarts mais il est peu probable que ce soit les seuls facteurs.
Nous n’avons malheureusement pas plus d’informations à ce jour.
 je vois maintenant dans la discussion que vous avez soulevé cette question et X a répondu que les données de l'étranger étaient réintégrées dans les chiffres communiqués par Santé Publique. Or, on a d'une part la série hospitalière sans ces chiffres et cette autre série où ils sont réintégrés ; comme le différentiel semble coller avec cette hypothèse, je suis assez positif qu'il ne peut s'agir que des transferts.
Après correction de la série, on reste en dessous d'un total théorique de 183 avec un max de 162 patients transférés au 14 avril.

Date;hosp_eur;rea;rad;dc;total_eur;corrections
2020-03-23;2;2;0;0;2;
2020-03-24;11;11;0;0;11;* (+11 hos +11 rea)
2020-03-25;11;11;0;0;11;* (ligne à 0)
2020-03-26;25;24;0;0;25;* (rad. -1)
2020-03-27;31;29;0;0;31;
2020-03-28;40;37;0;0;40;
2020-03-29;43;40;0;0;43;
2020-03-30;62;51;1;0;63;
2020-03-31;85;69;1;0;86;
2020-04-01;96;77;1;0;97;
2020-04-02;115;94;1;0;116;
2020-04-03;130;106;1;0;131;
2020-04-04;140;115;1;0;141;
2020-04-05;144;119;1;0;145;
2020-04-06;153;124;1;0;154;
2020-04-07;156;127;1;0;157;
2020-04-08;158;129;1;0;159;
2020-04-09;159;129;1;0;160;
2020-04-10;159;129;1;0;160;
2020-04-11;161;131;1;0;162;
2020-04-12;161;131;1;0;162;
2020-04-13;161;131;1;0;162;
2020-04-14;161;131;1;0;162;
2020-04-15;156;126;3;0;159;* (rad. -40)
2020-04-16;133;109;6;7;146;
2020-04-17;129;105;6;8;143;
2020-04-18;124;100;6;8;138;
2020-04-19;124;100;6;8;138;
2020-04-20;122;99;6;8;136;
2020-04-21;122;99;6;8;136;
2020-04-22;114;91;6;11;131;
2020-04-23;106;86;6;11;123;
2020-04-24;104;85;7;11;122;
2020-04-25;103;84;7;11;121;
2020-04-26;103;84;7;11;121;
2020-04-27;101;82;7;11;119;
2020-04-28;101;82;7;11;119;* (ligne à 0)
2020-04-29;98;79;7;12;117;
2020-04-30;91;72;7;13;111;
2020-05-01;78;59;8;19;105;
2020-05-02;76;57;8;19;103;
2020-05-03;76;57;8;19;103;
2020-05-04;76;57;8;19;103;
2020-05-05;74;55;8;19;101;
2020-05-06;71;52;9;19;99;


je viens de voir votre discussion : l'écart au niveau des décès, par exemple, était de 0 (donc identique) jusqu'au 15 avril.
Le 15 Avril c'est le jour où M. X a fait la discussion 'on y est presque' ou quelque chose du genre. Suivi le lendemain par 'on y était presque'
Donc quand on est bon dans le zig, on ne l'est pas dans le zag mais quand on est bon dans le zag, on ne l'est plus dans le zig
J'ai posé la question pour le 28 avril avec une discussion spécifique mais aucun retour ... enfin si : le lendemain j'ai dit que c'était revenu à des écarts ... 'normaux'?
on n'a jamais eu non plus de retour sur les 3 lignes sans département ... et tout un tas d'autres.
par contre nos remarques sont dans les fichiers d'incohérences
en ce qui me concerne je ne m'occupe plus de ces écarts, quand il reste dans la normalité.

Les data du 23 sans numéro de département ne sont pas une erreur. C'est en fait cohérent (une ligne est la somme des deux autres) : il n'y a pas de numéro de département pour ces données car ce champs n'était pas renseigné dans la base ; de la même manière, ils ont ajouté des champs "nuls" pour sexe ou âge lorsque cette information était manquante mais qui n'appraissent que dans les totaux : la valeur du champs "0" pour sexe est toujours supérieure ou égale à la somme de "1" et "2" ; la valeur de la classe d'âge "0" est toujours supérieure ou égale à la somme des autres classes puisqu'elle tient compte des cas où cette valeur n'est pas connue ; si ce n'était pas le cas, on pourrait douter de la cohérence du dataset - en fait, nous avons là un simple export d'une requête sur la base de données et on peut vérifier que c'est cohérent en croisant les deux datasets hospitaliers issus de cette même base (par sexe et par âge, département ou région).

Par la même méthode, on peut croiser les datasets issus des fichiers hospitaliers avec les datasets publiés sur le site du gouvernement et GEODES. On trouve que les seules incohérences, vis à vis du dataset hospitalier, se situent au niveau des totaux nationaux dans l'outils du gouvernement : ces totaux ne correspondent pas aux totaux des data sous-jacentes dans le même outils : ils ont été modifiés et non pas calculés.

Pour retrouver la cohérence, il faut ajouter une autre série de données qui apparaît en faisant le différentiel ; il faut aussi faire abstraction des jours (6) où ces totaux n'ont pas de sens (hormis qu'ils correspondent aux chiffres annoncés lors des briefings).
Cette série de données correspond à mon sens aux transferts à l'étranger qui ne sont pas repris par GEODES et ces trois lignes du 24 en font partie. Passé ce jour, il n'y a plus de ligne sans numéro de département ; elles ont été supprimées du dataset mais réintégrées uniquement dans les totaux du gouvernement.

D'ailleurs, vous me faites remarquer qu'il y a une erreur pour le 24 et le 25 mars, qui devraient être, après suppression des lignes sans département :
2020-03-23;2;2;0;0;2;
2020-03-24;13;13;0;0;13;* (+13 hos +13 rea - total lignes sans département du dataset)
2020-03-25;13;13;0;0;13;
2020-03-26;25;24;0;0;25;

Selon nos informations, les transferts à l'étranger on commencé le 21 mars mais à partir du 14 avril, au plus tard, des retours en France ont été effectués. En plaçant ces lignes dans un graphe, on voit bien que l'évolution de ces courbes sont cohérentes entre elles et qu'elles suivent cette chronologie.

L'écart des décès entre les annonces et la base hospitalière (uniquement pour la France, excepté le 24 mars) vient du fait qu'à compter du 16 mars, ils ont commencé à ajouter les décès à l'étranger au nombre de 7 ce même jour. Les décès ont ensuite grimpé jusqu'à atteindre 19, soit l'écart actuel entre la base et les annonces.

Bonjour,

Merci pour toutes ces explications. J'avais déjà fait ces hypothèses dans des discussions précédentes mais sans confirmation. Le fait qu'une autre personne pense la même chose est rassurant. Pour autant je ne le prends pas pour "argent comptant".
Le souci c'est qu'avant on pouvait se contenter de travailler au niveau national. Aujourd'hui cela n'est plus possible : il faut travailler au niveau départemental pour établir la stratégie de sortie du confinement.
Et si je ne prends pas ces explications pour "argent comptant", bien qu'elle me plaisent, c'est qu'autant je comprends que sur un dossier d'admission on 'oublie' de renseigner le sexe ou la classe d'age, autant ne pas connaitre le département me parait incroyable. L'hôpital envoie ces/ses données électroniquement. C'est donc référencé dans la base. Si non, il faut revoir le modèle de données. C'est le B.A BA. Le département est donc connu. Le département envoie à l'ARS (si ce n'est fait automatiquement, je ne connais pas les détails) qui sait quand même d'où viennent les données.
De plus quand on lit au dessus les 'explications' de comment lire et comprendre les données, on parle bien d'un problème potentiel au niveau du sexe, au niveau de la classe d'age mais pas au niveau du département.
J'allais faire la remarque que si c'est lignes n'étaient pas des erreurs elles n'avaient donc pas à être dans les fichiers des incidents mais je constate qu'elles ont disparu. Fin mars elles y étaient. Ou alors je ne les ai pas trouvées : il y a tellement de lignes et d'onglets dans les fichiers erreurs maintenant ...
Lorsque des champs ne sont pas renseignés dans une base, ce n'est pas forcément une question de négligence car il se peut qu'un formulaire n'ait pas prévu la possibilité d'une valeur... comme par exemple, le cas d'un transfert de patient à l'étranger.
Je ne connais pas la structure de cette base mais c'est tout à fait le genre de problème qu'on doit rencontrer actuellement avec des procédures de soins et de reporting qu'on doit improviser, faute d'avoir pu prévoir ce qui se passe. À la base, SI-VIC est un outils qui était destiné à autre chose (le suivi des victimes du terrorisme) mais qu'on a reconfiguré pour la gestion de cette pandémie.
Avec les données d'hier, on voit que la décrue régulièrement sur la semaine avec 2 patients sortis de réanimation à l'étranger et probablement repris en charge par un hôpital en France :

2020-05-01 ; 78 ; 59 ; 8 ; 19 ; 105
2020-05-02 ; 76 ; 57 ; 8 ; 19 ; 103
2020-05-03 ; 76 ; 57 ; 8 ; 19 ; 103
2020-05-04 ; 76 ; 57 ; 8 ; 19 ; 103
2020-05-05 ; 74 ; 55 ; 8 ; 19 ; 101
2020-05-06 ; 71 ; 52 ; 9 ; 19 ; 99
2020-05-07 ; 69 ; 50 ; 9 ; 19 ; 97
La décrue continue... mais ce qui me paraît remarquable, c'est que ces quatre valeurs pour hospitalisés, réanimation, radiation et décès sont liées. Lorsque l'une d'elle change, elles évoluent de concert ; ce n'est donc pas dû au hasard.

Information ARS BFC du 22/4  

Sur un total de 56 patients admis en réanimation transférés hors région (hôpitaux de Suisse,
Auvergne-Rhône-Alpes, PACA), 22 ont été rapatriés.
Onze personnes ont pu regagner leur domicile, 11 sont encore hospitalisées (dont 2 en
réanimation).
Vingt-neuf personnes restent hospitalisées à l’extérieur de la Bourgogne-Franche-Comté.
Cinq personnes concernées par les transferts sont malheureusement décédées.

Pas d'autre info depuis , par contre comme j'ai trouvé une autre info le 1/5 ,sur les suspicions COVID , juste pour montrer que les chiffres sont interprétables dans tous les sens , puisque parfois on ne considere pas les patients au meme niveau : 
Précision concernant la Nièvre
La Nièvre apparaît en rouge sur la première carte représentant le niveau de circulation du virus,
alors même que la dynamique épidémique y est plus faible que dans le reste de la région.
L’indicateur national a été construit sur la base du pourcentage de passages aux urgences lié à
des suspicions de COVID. Or, ce nombre a intégré dans la Nièvre un grand nombre de dépistages
de personnels soignants réalisés ces derniers jours. Ce biais d’analyse a été signalé à l’échelle
nationale par l’ARS et les équipes de Santé publique France en région, afin de permettre une
correction de la cartographie.
Ce n'est pas interprétable dans tous les sens : ce jeu de données est décrit sur GEODES comme ne tenant pas compte des patients transférés à l'étranger et ce sont les données brutes "hospitalières" ; donc je ne parle pas ici des transferts entre région mais spécifiquement à l'étranger. Vous avez d'autre part eu confirmation qu'ils sont bien réintégrés sur l'appli Etalab et, par la même occasion, dans le dashboard quotidien. D'où cette différence qui est interprétable lorsque les données officielles sont cohérentes d'un jour sur l'autre, ce qui n'a pas toujours été le cas :)
L'interprétation logique est qu'à ce jour, sur 183 transferts, 69 sont toujours hospitalisés à l'étranger dont 50 en réanimation ou soins intensifs ; 9 ont été déchargés directement de l'étranger ; 19 sont décédés à l'étranger ; 65 ont été repris en charge en France depuis le 14 avril (162 - 97), et 21 autres l'auraient été avant cette date (puisque le total des patients culmine à 162 le 14 avril). 
je viens de retourner sur GEODES et je ne vois toujours pas d'information sur les transferts.
Pourriez-vous indiquer où vous les voyez svp?
Je ne vois pas de quelle confirmation de prise en compte dans le dashboard quotidien vous parlez , puisque le fichier a été mis à disposition vers le 24/4 et plus mis à jour depuis , et les questions sur les retours n'ont pas non plus évolué 

puisque à mes questions sur les transferts retour , il m'avait été répondu : Nous avons publié ces données sous la forme qui nous a été communiqué. Nous avons déjà remonté cette demande.
Pour les transferts dans l’autre sens, je ne crois pas que ce soit prévu à ce stade.


Comme c'est Etalab qui gere tous ces depots de données , on peut supposer que s'ils avaient eu des informations ils nous en aurait fait part 
Et si Etalab ne répond pas à toutes vos hypothèses , ni aux notres en leur temps , c'est qu'il n'y a peut etre pas de réponse carrée ,  car si Etalab n'arrive pas à avoir des infos du Ministère de la Santé , qui le peut . 

Mais libre à vous de continuer à les poser , à force d'insister à plusieurs , cela finira peut etre par marcher . 

On a eu les nouveaux réa ce qui était important pour comprendre l'évolution , on n'aura pas les suites de rea car c'est trop sensible. 
Il faut se faire une raison , attendons les resultats des travaux de chercheurs dans quelques temps.

On  comprendra peut etre un jour aussi la logique des couleurs :  j'ai compris que 2 oranges valent 1 rouge  (Hauts de France) mais que quand un rouge est dans le Sud , on peut negocier.
J'ai l'impression qu'on tourne en rond et que ce n'est toujours pas clair pour vous :)

Pour la dernière fois, je vais récapituler :
- le jeu de données hospitalières (ancien) qui est mis à notre disposition est celui utlisé dans l'outil GEODES de Santé Publique et celui d'ETALAB (gouvernement.fr). Les données de ce fichier sont totalement identiques dans les trois cas.
- il y a pourtant une exception pour ETALAB que vous avez aussi remarquée : le total pour la France de tous les champs du fichier (hosp, rea, rad, dc) est différent pour chaque jour (ou presque) des sommes journalières de ces même champs ; d'autre part, ce sont aussi ces totaux différents qui est utilisé dans le dashboard quotidien de Santé Publique.

maintenant, en tenant compte de ces informations :
- a) GEODES commente notre jeu de données hospitalières de la manière suivante : « Précisions : ... Seules les personnes hospitalisées ou décédées en France sont représentées dans Géodes. Les personnes hospitalisées à l’étranger ne sont pas représentées. »
- b) vous avez déjà posé des questions sur le delta entre les sommes du fichier et ceux d'ETALAB ainsi que sur la méthodologie liée aux transferts. ETALAB vous a répondu sur ces deux points : 
Jérôme Desboeufs (25 avril 2020) : « (...) si un patient quitte le pays il disparait des décomptes départementaux, mais est réintégré dans les cumuls nationaux communiqués par la direction générale de la santé. »
 (25 avril 2020) : « (...) Les transferts participent aux écarts mais il est peu probable que ce soit les seuls facteurs. Nous n’avons malheureusement pas plus d’informations à ce jour.. »

En fait, il a répondu du mieux qu'il pouvait aux questions que je me posais moi aussi et j'en déduis que :

1. le Dashboard quotidien de SPF est utilisé par ETALAB pour renseigner les totaux France : les sommes sont identiques aux communiqués car elles ne sont donc pas calculées à partir des données hospitalières qui peuplent pourtant la base ;
2. lorsque le communiqué de SPF est cohérent (tous les jours sauf les 18, 19, 21, 22, 25 mars et 28 avril) le calcul du delta entre les totaux du dashboard SPF et les sommes des quatres champs du fichier hospitalier correspond bien à la situation, en solde cumulé, des patients transférés à l'étranger.

Voilà, ça me semble tout à fait correspondre car je ne vois pas bien quel autre décompte SPF pourrait réintégrer dans son dashboard quotidien pour que les totaux changent de manière aussi cohérente.
Si ETALAB , qui , je vous apprends rien , est en plein dans la gestion de la crise,  avait de nouvelles infos à mettre à notre disposition, j'ose penser qu'ils nous en auraient fait part, plutot que de nous laisser perdre  notre temps en conjectures et que s'ils avaient des infos sur les transferts retour ou sur la fameuse anomalie du 24/3 avec le departement fantome , ils en auraient fait beneficier tout le monde dans leur github, leur dashbord ou les data.gouv qu'ils animent  
(tous sites que je suis depuis le debut, pour info leur github reprenait à la main au debut tous les compte rendus ARS car il n'y avait pas de données data. gouv ; j'ai gardé le mail de debut mars que SPF m'avait envoyé pour me dire que leurs personnels étaient trop occupés pour mettre à disposition les données dans des fichiers suite à une question que je leur avais posée après avoir vu en particulier ce que faisaient les italiens, donc le github a suppléé au debut à ce manque)

Je ne cherche donc plus à expliquer ces chiffres, puisqu'eux memes, ETALAB, ne nous les expliquent pas.

Mais par contre je continue à etre étonné par la non coherence des chiffres du dashboard SPF entre 2 jours successifs , c'est ce que j'ai essayé de vous expliquer plus haut :

SPF annoncait le 7/5 que 95210 personnes avaient été hospitalisées, et que cela faisait 728 personnes hospitalisées en plus en 24h  alors que la veille il annoncait 94798 personnes ayant été hospitalisées depuis le début.
La difference entre ces 2 chiffres est de 412, ce qui ne correspond ni au 728 annoncés dans le tableau du 7/5 , ni au 431 qu'on peut calculer soit meme à partir des données hospitalières. Disons que l'écart entre 412 et 431 reste de l'ordre de l'anecdotique .
Le 728 vient du fichier incid nouveaux hospitalisés dont personne n'a encore expliqué la cohérence par rapport au chiffre calculé des nouveaux hospitalisés à partir des données hospitalières donc le 431.
De la meme facon il y a toujours eu un ecart dans la comptabilité des décés (hier un ecart de 10 entre incid et données hospitalières et pourtant on travaille sur le meme périmetre de departements) 

Ce fichier incid ne me sert à moi comme à d'autres qu'a enregistrer la valeur des nouveaux rea au niveau departemental , comme ce chiffre consolidé des nouveaux rea est cohérent des annonces officielles de SPF je m'en contente et pourtant il sert à SPF pour annoncer les nouveaux hospitalisés et les nouveaux décès et les nouveaux rad. 

Donc je remonte ces incoherences , mais j'ai renoncé à les expliquer 


J'ai une idée pourquoi le fichier incid et le fichier hospitalier ne peuvent pas se recouper mais ce n'est pas mon souci principal à l'heure actuelle : je cherche simplement à comprendre la cohérence derrière les chiffres du dashboard quotidien communiqué par SPF (ou la DGS).

1. La source des données principales du jour (les fameux "cumuls nationaux" pour les malades hospitalisés, malades en réanimation ou soins intensifs, retours à domicile et les décès) est bien celle du fichier hospitalier (ancien) qui correspond aux valeurs cumulées + les infos cumulées pour les patients à l'étranger (c'est mon hypothèse et je pense vraiment qu'elle est juste).
2. la source des deltas journaliers "24H" est issue du fichier hospitalier_nouveaux (incid) et ne correspond donc pas aux. écarts journaliers entre les "cumuls nationaux" de l'autre fichier hospitalier : ces deux fichiers ne se recoupent pas.
3. je n'ai aucune explication concernant les cumuls communiqués les 18, 19, 21, 22, 25 mars et 28 avril, pour l'instant, car je n'ai pas encore cherché à quoi ils peuvent bien correspondre.
4. je soupçonne que le cumul national du nombre de patients hospitalisés qui est augmenté, par rapport à mon calcul, d'un montant quotidien qui varie dans l'intervalle 500-700, est affecté par les transferts sur le territoire national (double compte ?)
5. je soupçonne que le fichier "incid" est exporté par date d'évènement (chiffres de la vieille de 0h à 24h) alors que le fichier hospitalier est exporté quotidiennement par date de rapport et chaque jour à 14h (puisqu'il s'agit de cumuls). Il y a d'ailleurs un décalage d'un jour entre les deux.
5. (ou inversement) : dans les deux cas, c'est dur de trouver une correspondance sans le détail ligne par ligne
5 . je ne vois pas le jour de decalage que vous annoncez entre ces 2 fichiers , le seul fichier que je connaisse qui soit decalé est le fichier Sursaud 

Pour les ecarts entre les fichiers qui ont deja fait l'objet d'au moins une discussion suivie , j'avais essayé de graphiquer les écarts et de repérer les departements les plus en écarts ,  mais je continue à suivre les écarts entre les fichiers depuis le debut  : ecart sur les hosp de 180 par jour, de 10 sur les deces et de 70 sur les gueris 
Et puis le fichier des données hospitalières n'est pas à l'abri d'anomalies lui meme , voir le gros ecart sur les rad du 68 d'hier , ce qui ne simplifie pas l'analyse.

5. Il y a un fichier qui démarre le 18 mars et l'autre (incid) le 19 mars.

- Le Delta du Dashboard SPF vs fichier hospitalier continue de décroître de manière cohérente ( -2 réa ; -2 hospitalisés).
2020-05-01 ; 78 ; 59 ; 8 ; 19 ; 105
2020-05-02 ; 76 ; 57 ; 8 ; 19 ; 103
2020-05-03 ; 76 ; 57 ; 8 ; 19 ; 103
2020-05-04 ; 76 ; 57 ; 8 ; 19 ; 103
2020-05-05 ; 74 ; 55 ; 8 ; 19 ; 101
2020-05-06 ; 71 ; 52 ; 9 ; 19 ; 99
2020-05-07 ; 69 ; 50 ; 9 ; 19 ; 97
2020-05-08 ; 67 ; 48 ; 19 ; 9 ; 95

- Le fichier hospitalier donne, le 8 mai, un total calculé de 94 908 hospitalisés covid-19 ;
- le même calcul sur les valeurs du Dashboard SPF donne 95 003, soit un écart de 95 (après réintégration des patients à l'étranger selon mon hypothèse).
- le cumul national du Dashboard indique 95 601, soit un écart de 598 avec le calcul précédent ou de 693 avec le fichier hospitalier.
- 
2020-05-01 ; 78 ; 59 ; 8 ; 19 ; 105
2020-05-02 ; 76 ; 57 ; 8 ; 19 ; 103
2020-05-03 ; 76 ; 57 ; 8 ; 19 ; 103
2020-05-04 ; 76 ; 57 ; 8 ; 19 ; 103
2020-05-05 ; 74 ; 55 ; 8 ; 19 ; 101
2020-05-06 ; 71 ; 52 ; 9 ; 19 ; 99
2020-05-07 ; 69 ; 50 ; 9 ; 19 ; 97
2020-05-08 ; 67 ; 48 ; 9 ; 19 ; 95 (correction de l'inversion au dessus)
selon le fichier hospitalier nouveaux (incid), le total des hospitalisés atteint le 8 mai la somme de 100 561 patients
soit un écart de :
- 5 653 patients avec le fichier hospitalier par sexe ou par âge ;
- 5 558 patients avec le total calculé sur les cumuls du dashboard ;
- 4 960 patients avec le cumul publié dans le dashboard.

Donc, c'est une bonne chose d'être transparent et de vouloir publier des chiffres mais il faudrait soit apprendre à compter ou bien nous expliquer la méthodologie derrière toutes ces données :)


Vous voyez bien que vous aussi vous commencez à douter de la cohérence  des chiffres !
C'est sans doute du en partie à l'absence d'outils de mise en évidence des anomalies 
Mais vous savez aussi qu'on nous dit qu'il peut y avoir des anomalies involontaires dans les chiffres : des gens sont soupconnés covid avant test puis le test est négatif 

Ce qu'on peut surtout reprocher aux datasets c'est que les erreurs manifestes d'un jour sur l'autre ( record de -123 sur les rad et -24 sur les dc  dans un departement d'un jour sur l'autre )  ne soient pas toutes  reprises dans le dataset a posteriori pour que les données soient cohérentes . A un moment on a bien repris les anomalies de declarations  des EPHAD sur les cas de covid qui avaient ete comptées en double)
Il y a donc des anomalies entre les fichiers mais le fichier hospitalier n'est pas a priori plus fiable que l'autre, donc n'est pas une reference selon moi.

Sinon pour le fichier incid , je peux aussi emettre l'hypothese que le decalage à l'origine etait volontaire puisqu'on parlait des nouveaux cas , il n'y a pas d'elements connus montrant  qu'il couvre une période differente dans la journée  (jusqu'à preuve du contraire )
sentinelle n'a été activé que le 17 mars (pour le covid)
1e fichier données hosp le 18 (avec les données du 17 14h au 18 14h)
pour faire le fichier incid (maintenant appelé nouveaux) il faut J et J-1
Le 18 il n'y avait pas de J-1 puisque c'était le 1e fichier
Il a donc fallu attendre le 19 pour avoir incid/nouveaux
précision : on serait tout à fait capable de sortir un incid/nouveau à J avec les dossiers patients, ce n'est pas une question technique mais plutôt politique et de priorités puisque incid n'est pas (données hosp à J) - (données hosp à J-1)
@Denis
euh... non. Pas besoin de J-1 pour enregistrer le nombre d'admissions à l'hôpital le jour J dans le fichier incid. Il ne s'agit pas d'un delta.
Je crois plutôt que le décallage vient du fait que ce sont les admissions du jour (donc datées de la veille le 18 de 0h à 24h) publiées le lendemain dans le fichier incid.
si un fichier va de 14h J-1 à 14h et l'autre de 0h à 23h59 alors ça (peut) expliquer les décalages entre les fichiers données hosp et incid/nouveaux
Sur SPF il n'y a pas de distinction entre données hosp et incid/nouveaux : c'est tout dans 'arrêtées à 14h'

J'ai toujours douté de la cohérence des chiffres publiés depuis que j'ai ouvert les fichiers lorsqu'ils ont été publiés. Maintenant, j'ai aussi cherché à comprendre le process en commençant par essayer de comprendre d'où étaient tirés les indicateurs journaliers publiés dans le dashboard.

La DGS (ou SPF) consolide ce tableau de bord avec les données hospitalières dont nous disposons plus des data qu'ils ne ce sont pas donné la peine de publier (patients à l'étranger - transferts, etc.).

Non plus :)
Le fichier hospitalier est juste une photographie d'une situation (occupation des lits, radiés, décédés) à un instant T. Il n'y a pas non plus besoin de J-1. Cette situation correspond à la date du jour de publication à 14h ; le premier a été publié le 18 mars, situation à 14h.

Le fichier nouveau (incid) est un cumul journalier ; pour faire ce genre de situation à partir d'une base de données hospitalière, il me semble évident qu'ils se basent sur la date d'entrée, de sortie, de décès... et non pas une date plus une heure (14h) car ils auraient plein de cas où l'heure exacte ne serait pas renseignée.
tout est expliqué sur le jeu de données 'indicateurs'
ensuite, les écarts entre les deux proviennent sans aucun doute des retards dans la saisie des données - du fait que les rectifications ne concernent que le dernier jour pour le fichier hospitalier cumulé... en plus de la période pour chaque requête qui ne correspond pas exactement entre les deux fichiers.
rad = 'retours à domicile' et pas radiés
vous m'avez compris.
Je ne vois pas de jeu de données "indicateurs".
il est ici https://www.data.gouv.fr/fr/datasets/indicateurs-dactivite-epidemique-covid-19-par-departement/
qu'appelez-vous le fichier hospitalier cumulé? données hospitalières?
pourquoi dites-vous que les rectifications ne concernent que le dernier jour?
la cohérence hosp -2 % rea -2 n'est valide qu'à condition que décès fasse -2 aussi
si les 2 personnes en réa étaient retournées en hosp, on aurait eu -2 en réa et 0 en hosp
on pourrait aussi dire que c'est lié à rad au lieu de décès mais on imagine mal quelqu'un sortir de réa pour rentrer à la maison directement
après pour le 24 mars : pourquoi avoir mis ces 3 lignes pour 13 personnes et pas les 185?
pourquoi avoir mis +13 au lieu de -13?
si on compte +19 pour les décès survenus à l'étranger, il faut compter les personnes qui sortent pour être envoyées à l'étranger. Donc -13
Sauf si elles ont déjà été retirées une à une au cours des publications précédentes et qu'on souhaite les réintégrer au système
et enfin pour le département 'manquant' : c'est à ça que sert le code 99
c'est pour toutes ces raisons (et c'est non exhaustif) que j'ai arrêté de me poser des questions sur ces 'incohérences'
là j'ai cru après 1 mois et demi que quelqu'un avait trouvé les info sûres mais ce n'est donc toujours pas le cas

Je ne vois aucune explication en rapport avec la manière dont les fichiers hospitaliers sont constitués en suivant le lien que vous m'avez indiqué. Je précise que je ne m'intéresse pas à la carte du déconfinement, aux couleurs des départements, etc., seulement aux données hospitalières sur lesquelles sont construites les dashboards journaliers (DGS / SPF) en particulier les "cumuls nationaux".

Ensuite, deuxième question, il y a deux séries de data différentes publiées sous la rubrique : "Données hospitalières relatives à l'épidémie de COVID-19".
- un premier lot, dit "données hospitalières", en deux fichiers par sexe et par âge, par département et région ;
- un deuxième lot, dit "données hospitalières nouveaux ou "incid" ;
 
Les données du premier lot se recoupent totalement ; ce fichier est une extraction à un instant T du nombre de patients hospitalisés, en réanimation ou soins intensifs (compris dans le premier champs) et du cumul pour les décès et des retours à domicile depuis le 1er mars par catégorie d'âge, sexe.

Dans ce fichier, qui sert de base aux "indicateurs nationaux", il y a visiblement des corrections qui sont effectuées, mais uniquement sur la dernière édition du jour (sans jamais reprendre l'historique qui est aggrégé et reste identique pour tous les jours précédents). Ceci explique parfois de gros écarts de valeur sur les cumuls "rad" ou "dc" d'une journée sur l'autre. On perd la cohérence dès que ces corrections ne sont pas appliquées rétroactivement jusqu'aux dates où elles se sont produites.

Pourquoi je dis ça ? parce qu'un cumul ne peut qu'augmenter ou rester inchangé. Si le delta devient négatif d'une journée à l'autre, ce qui se vérifie, c'est qu'il a été corrigé entre deux éditions ; ça pourrait aussi être le cas des autres champs "hosp" et "rea" mais on n'a pas le moyen de le vérifier de par la nature même des données qui représentent des soldes d'occupation des lits à cet instant T (le jour de publication à 14h, nous dit-on).
vous avez dit 'indicateurs' et j'ai compris 'indicateurs d'activité épidémiques' qui sont les indicateurs à suivre aujourd'hui. C'est pour ça que je vous ai renvoyé là-bas. Vous vouliez parler des dashboards (SPF) et tableau de bord 'vue d'ensemble' (il a changé de nom il y a peu) du site du gouvernement
pour les corrections : j'ai démontré il y a 3 jours que les corrections pouvaient être faites plusieurs jours à compter de la dernière version mise à dispo : le fichier du 5 mai avait des données en date du 30 avril remises à jour. Sur le site 'indicateurs' justement.

Vous dites :
"la cohérence hosp -2 % rea -2 n’est valide qu’à condition que décès fasse -2 aussi
si les 2 personnes en réa étaient retournées en hosp, on aurait eu -2 en réa et 0 en hosp"
Non, pas vraiment :
La baisse de 2 en réanimation et 2 en hospitalisation veut dire que deux personnes sont sorties de reanimation et deux sont reprises en charge par un hôpital français, sans retour au domicile direct (la valeur "rad" aurait augmenté) ou décès (la valeur "dc" aurait augmenté). 

J'ai déjà expliqué plus bas qu'il y avait aussi bien des cas de retour à domicile directs de l'étranger et des cas de reprise en charge par les hôpitaux en France de patients qui étaient à l'étranger ; dans tous les cas, les indicateurs "rad" et "dc" ne concernent que les retours à domicile de l'étranger et les décès à l'étranger, sans présumer du sort de ceux qui sont repris en charge en hôpital sur le territoire. 
Vous pouvez vous aussi vérifier avec ce document :
https://www.fehap.fr/upload/docs/application/pdf/2020-04/covid-19_fiche_retour_post_transfert_international_v08042020_finalise_.._.pdf


ce qu'on observe dans la continuité, c'est que lorsque les patients sortent de réanimation à l'étranger, ils sont souvent rapatriés dans un hôpital français (ces données sont remises à jour en même temps).
"après pour le 24 mars : pourquoi avoir mis ces 3 lignes pour 13 personnes et pas les 185?
pourquoi avoir mis +13 au lieu de -13?
si on compte +19 pour les décès survenus à l’étranger, il faut compter les personnes qui sortent pour être envoyées à l’étranger. Donc -13"

C'est comme si vous ajoutiez au fichier un département "990" et lui affectiez la somme des lignes sans département, puis toutes les valeurs du delta entre les sommes journalières et le dashboard journalier (ma liste). Il nous est dit que ce département 990 des "Français à l'étranger" commence à recevoir des patients hospitalisés (en réanimation) à partir du 21 mars ; à ce moment le compte est à zéro et la valeur peut grimper jusqu'à 183.
 
Avant le 23 rien n'est pas vérifiable à cause des incohérences des totaux du Dashboard les deux jours précédents. Maintenant, selon mon hypothèse, il en a reçu 2 avant le 23 mars, puis 13 le 24 mars, etc.
Lorsque le nombre du "total patients" (hosp + rad + dc) commence à baisser, c'est que le solde commence à diminuer en raison des reprises en charge des patients sortis de réanimation.
les valeurs "hosp" et "rea" représentent des nombre de lits occupés ; 13 le 24 mars ne veut pas dire 13 nouveaux tranferts mais 13 patients transférés jusqu'à ce jour, dont 13 en réanimation, ce qui est cohérent avec ce qu'on sait de l'état des patients envoyés à l'étranger.
Ok, je comprends votre problème sur les signes maintenant.
Vous semblez oublier que les champs "hosp" et "rea" sont différents des champs "rad" et "dc" dans les données hospitalières. Les deux premiers sont des soldes (mouvements positifs et négatifs) alors que les deux autres sont des cumuls (mouvements positifs ou nuls uniquement).

Par conséquent, "hosp" et "rea" ne contiennent que le solde des patients en France et c'est pour ça que les données hospitalières communiquées dans le dashboard sont toujours supérieures (selon le delta que j'ai calculé) au total du jour pour ces valeurs dans le fichier hospitalier ; ce qui est cohérent s'il s'agit bien de l'ajout des patients à l'étranger qui est ensuite réintégré dans le total du dashboard par SPF.
je ne vois pas comment j'aurai pu 'reconstruire' les cartes de France à l'identique de ce que présente les autorités sanitaires si c'était le cas
ce que j'ai mal compris plutôt je pense c'est la relation de cohérence que vous faisiez entre -2 hosp et -2 réa
#############
Le Delta du Dashboard SPF vs fichier hospitalier continue de décroître de manière cohérente ( -2 réa ; -2 hospitalisés).
#############
Alors expliquez-moi pourquoi vous me proposez, alors que nous avons un surplus dans les dashboards, de soustraire ce delta au lieu de l'ajouter ?

Si le fichier dont nous disposons ne contient que des personnes hospitalisées en France, alors il me semble tout à fait raisonnable de penser que les personnes qui sont transférées à l'étranger sont un surplus ?

Mais s'il s'agit uniquement des patients concernés par les lignes du 24 mars sans département, ce que j'ai expliqué étant une erreur due aux transferts, j'ai déjà précisé que je ne les avais pas conservées dans mon décompte (donc elles sont bien entendu soustraites de mon total du fichier avant d'être ajoutées à ma liste des cas à l'étranger) vu que, ce jour-là, il n'y a justement pas d'écart entre le fichier hospitalier et les sommes du dashboard. Delta = 0.

Ce Delta du 8, comme les autres, est tout à fait cohérent : deux patients sortis de réa ; deux retours à l'hôpital en France. Qu'est-ce qui vous gêne ?

Selon mon hypothèse, lorsqu'il n'y aura plus aucun patient hospitalisé à l'étranger, il n'y aura plus aucun delta entre "hosp" et "rea" du fichier et du dashboard mais il restera un écart pour "rad" et "dc", respectivement de 9 et 19 à la date d'aujourd'hui mais qui peuvent toujours augmenter d'ici là.
La personne qui a été transférée d'un hôpital français vers un hôpital étranger, à un moment donné elle a bien été intégrée dans les 'nouveaux' arrivants de l'hôpital français non?
Elle a bien occupé un lit d'hôpital
Quand elle a été déplacée de France à 'hors de France' elle n'occupait plus ce lit.
Il faut donc faire -1 et pas +1
Donc -13 et pas plus 13
il existe bien une valeur incohérente dans le delta le 26 mars : il s'agit d'un écart de 1 sur retour à domicile (ligne corrigée à -1 rad). Soit il y a une erreur ce jour-là, soit il y en a une les trois jours suivants où la nombre de 1 retour à domicile n'est pas confirmé. Il reste ensuite à zéro et ne reprend la valeur de 1 qu'au 30 mars.
Oui Denis, elle va bien occuper un lit de plus "hosp" lorsqu'elle rentre en France. Par conséquent, une fois qu'elle a été rapatriée, ce lit est déjà compté dans les admissions (en théorie) puisqu'il s'agit bien d'un point de situation d'occupation des lits... en France. Idem dans l'autre sens.

Mais il n'y a pas moyen de le vérifier puisqu'on n'a que le solde et que l'autre fichier ne permet pas de recoupements. Comment pourrions nous même distinguer une reprise en charge suite à un transfert d'une nouvelle admission ? Pour les sorties ("rad" et "dc") on voit les compteurs augmenter mais, pour les entrées, il n'y en a pas qu'on puisse vérifier.


Annotation : Erreur dans les données fournies  (Fiabilité )