Migration API

Migrer vers la nouvelle api

Cet article traite de la migration de l’ancienne api vers la nouvelle. Tout d’abord, nous vous recommandons de lire la description de la nouvelle api. Nous allons énumérer ici les différences les plus importantes entre l’ancienne et la nouvelle api.

Par exemple, pour obtenir un dossier de santé :

Vous pouvez trouver la documentation complète à…

Migrer depuis le sadv

Questionnaire

Avant

Historiquement afin d’obtenir un questionnaire de personnalisation de la recommandation vaccinale il fallait appeler le Endpoint suivant: POST /decision_support/health_profile_form.json

Avec comme données:

{
  "birth_date": "2000-01-01",
  "gender": "female",
  "condition_ids": [52, 145, 146],
  "user_type": "patient"
}

Maintenant

Il faut désormais appeler le Endpoint suivant: POST /questionnaire Le format du payload a évolué comme suit.

{
  "patient": {
    "birthdate": "2000-01-01",
    "gender": "f",
    "conditions": [
      {
        "id": "2934c287-e36b-4adf-a5f6-e2f30dc8ed4a",
        "value": true
      },
      {
        "id": "f235d2d9-3855-44c3-9d3e-25591d7918fb",
        "value": "2022-10-10"
      }
    ],
    "area_of_residency": {
      "zipcode": "33000"
    }
  },
  "requested_by_professional": true
}

Conditions

Désormais les conditions qui étaient identifiées par des ID sont remplacées par des UUID. De plus les conditions ont désormais un type, il existe 4 types de conditions:

Booléenne (comme les conditions historique)
Date (Exemple: Date de la dernière infection à la Covid 19)
Entier (Exemple: Poids du patient)
Flottant (Exemple: Dosage des anticorps antitétaniques en UI/L)

Historiquement les conditions étaient envoyées en tant que Booléen uniquement, il n’y avait donc pas de valeurs à spécifier. Désormais il faut spécifier la valeur.

L’envoi des conditions permet d’ajuster le questionnaire en fonction des réponses précédentes.

Genre

Les valeurs du champ gender changent:

female devient f
male devient m

Type d’utilisateur

Afin d’obtenir un label de condition adapté à l’utilisateur, on utilisait le champ user_type. Il est désormais remplacé par une valeur booléenne avec le champ requested_by_professional. Si on demande le formulaire en tant que professionnel de santé on doit mettre ce champ à true.

Autres changements

Si le code postal de résidence du patient est connu, il convient de l’envoyer dans le champs area_of_residencyceci afin d’obtenir des recommandations en lien avec sa zone de résidence.

retourne les données du questionnaire de personnalisation de la recommandation vaccinale Le questionnaire de personnalisation se présente sous la forme d’un arbre de conditions représentées par des cases à cocher.

Service de recommandation vaccinale grand public

Avant

Historiquement afin d’obtenir des recommandations vaccinales il fallait appeler les Endpoint suivant:

POST /decision_support/recommendations.json

Avec comme données:

{
  "birth_date": "2000-01-01",
  "gender": "female",
  "condition_ids": [52, 145, 146],
  "user_type": "patient"
}

POST /decision_support/immunisation_assessment.json

Avec comme données:

{
  "birth_date": "2000-01-01",
  "gender": "female",
  "condition_ids": [52, 145, 146],
  "vaccinations": [
    {
      "date": "2015-04-04T16:04:20+02:00",
      "vaccine_id": 549,
      "booster": false
    }
  ],
  "user_type": "patient"
}

Maintenant

Désormais, les 2 services sont regroupés en un, il faut appeler le Endpoint suivant: POST /diagnostic_for_patient

Le format du payload a évolué comme suit.

{
  "patient": {
    "birthdate": "2000-01-01",
    "gender": "f",
    "conditions": [
      {
        "id": "2934c287-e36b-4adf-a5f6-e2f30dc8ed4a",
        "value": true
      },
      {
        "id": "f235d2d9-3855-44c3-9d3e-25591d7918fb",
        "value": "2022-10-10"
      }
    ],
    "prevention_acts": [
      {
        "date": "2010-01-01",
        "prevention_method_id": "a7131590-0b14-43f5-8c4d-b87cd55b99af",
        "booster": "false"
      }
    ],
    "area_of_residency": {
      "zipcode": "33000"
    }
  },
  "requested_by_professional": true
}

L’essentiel des paramètres du profil santé sont détaillés dans la partie Questionaire. Le payload contient cependant une donnée de plus: l’historique vaccinal.

Vaccinations

L’historique vaccinal doit être envoyé comme suit:

"prevention_acts": [
  {
    "date": "2010-01-01",
    "prevention_method_id": "a7131590-0b14-43f5-8c4d-b87cd55b99af",
    "booster": "false"
  },
  {
    "date": "2015-01-01",
    "prevention_method_id": "a7131590-0b14-43f5-8c4d-b87cd55b99af",
    "booster": "true"
  }
]

Désormais les vaccinations sont renommées prevention_acts et utilise les identifiants vaccins provenant de la NUVA sous la clé prevention_method_id.