Calculateur d'immunité vaccinale

L'outil gratuit du navigateur et l'API partagent la même bibliothèque JavaScript pure, de sorte que les contrôles interactifs et les tâches automatisées s'accordent toujours.

Comment la protection vaccinale restante est estimée

Un schéma incomplet est mis à l'échelle linéairement vers ce pic avec un facteur saturant à deux doses : zéro dose n'apporte rien, une dose atteint la moitié de l'efficacité publiée, deux doses ou plus atteignent l'efficacité publiée complète, et les doses ultérieures n'élèvent pas le pic au-dessus de ce chiffre car, dans ce modèle, elles ne font que réinitialiser l'horloge que l'appelant fournit déjà comme mois depuis la dernière dose. Algébriquement, remaining_percent vaut efficacy multiplié par le minimum de un et de doses sur deux, multiplié par le facteur exponentiel d'affaiblissement.

Contrat d'entrée, sorties et comportement d'erreur

Une validation en échec n'est pas facturée. Il n'y a ni table de pathogènes, ni ajustement selon l'âge, ni indicateur d'immunodépression, ni date de calendrier dans cette capacité : ce sont des intentions de produit distinctes. Envoyez un objet JSON avec trois nombres finis obligatoires : efficacy, l'efficacité vaccinale publiée en pourcentage sur l'intervalle fermé de zéro à cent ; doses, un entier non négatif de doses reçues, au plus vingt ; et months, le temps non négatif écoulé en mois depuis la dernière dose, au plus six cents, les mois fractionnaires étant autorisés. Des alias tels que vaccine_efficacy, ve, efficacy_pct, n_doses, doses_received, dose_count, shots, months_since_last_dose, months_since, elapsed_months et time_months sont acceptés afin que formulaires et scripts n'aient pas besoin d'un seul nom de champ. Champs obligatoires manquants, chaînes vides, valeurs non finies, doses non entières, doses ou mois négatifs, plus de vingt doses, plus de six cents mois et une efficacité hors de zéro à cent échouent avec invalid_input et un message qui nomme le problème. En cas de succès, la réponse renvoie remaining_percent comme estimation principale, répète efficacy, doses et months, et inclut peak_percent, dose_factor, waning_factor, half_life_months égal à douze, waning_rate_per_month égal au logarithme naturel de deux divisé par douze, primary_series_doses égal à deux, et une chaîne de formule qui reformule remaining_percent = efficacy × min(1, doses/2) × exp(−ln(2)×months/12). Associez remaining_percent à votre propre calendrier si vous devez comparer l'estimation éducative à une politique de rappel que vous avez choisie vous-même. Les appels API réussis coûtent le $0.002 publié par élément ; les échecs de validation ne consomment jamais le solde prépayé.

Où les équipes l'utilisent et comment le tarif fonctionne

Les chaînes de traitement de recherche qui enregistrent des comptes de doses autodéclarés et l'âge de la dernière dose peuvent poster de nombreuses tâches indépendantes — une par personne et par intervalle — et stocker remaining_percent à côté de la session pour une analyse ultérieure. Les modules d'épidémiologie en classe peuvent fixer efficacy et doses et balayer months pour illustrer une demi-vie de douze mois sans une cellule de tableur qui a dérivé lorsqu'on a modifié le taux. Comme l'implémentation est un parse de niveau A pur, chaque appel réussi coûte le tarif de base publié $0.002, sans jetons de modèle et sans réseau sortant. Présentez toujours remaining_percent comme une estimation éducative selon la définition d'affaiblissement fixe ; les décisions cliniques exigent des professionnels qualifiés, des calendriers locaux et un contexte d'éligibilité que cet outil ne recueille pas.