Service d'Accès aux Soins
0.1.0 - ci-build France flag

Publication Build: This will be filled in by the publication tooling

FAQ

Cette section regroupe les réponses aux questions les plus fréquemment posées au cours des travaux de développements menés par les éditeurs, et les tests d’intégration.

Agrégateur

Quel est le format à utiliser afin de transmettre un OID dans un élément System ?

L'OID doit être précédé du préfixe `urn:oid:`, comme dans l'exemple suivant : "system": "urn:oid:1.2.250.1.71.4.2.2".

urn:oid:1.2.250.1.71.4.2.1 = IDNPS
urn:oid:1.2.250.1.71.4.2.2 = IDNST

Quels codes sont attendus afin de décrire le type d’identifiant de professionnel (élément identifier.type.coding.code des ressources Practitioner), ou de structure (élément organization.identifier.type.coding.code des ressources Location), transmis ?

Les valeurs IDNPS (ID National de PS) et IDNST (ID National de STructure), présentes dans la nomenclature http://interopsante.org/fhir/CodeSystem/fr-v2-0203 sont attendues.

Quels champs de l’élément identifier des ressources FrLocation et FrPractitioner sont obligatoires ?

Les éléments identifier.system, identifier.type et identifier.value sont obligatoires.

Quelle URL doit être transmise dans l’élément comment ?

Il est attendu l’URL de redirection vers l’agenda du PS concerné et non l’URL du créneau.

A quel niveau la ressource FrLocation doit-elle être transmise ?

Les ressources locations doivent être contenues contained dans la ressource PractitionerRole associée. Par ailleurs, au niveau de la ressource PractitionerRole, la référence vers la ressource Location doit être indiquée.

Quelle est la ressource discriminante au niveau de la structure du fichier de réponse JSON ?

Il est attendu dans le fichier de réponse JSON d’avoir 1 ressource Schedule pour 1 ressource PractitionerRole. Cela se traduit par le fait d’avoir 1 agenda pour 1 lieu de consultation. Dans la structure du fichier de réponse, un PS aura ainsi autant d’agendas que de lieux de consultation.

Comment intégrer les ID nationaux de structure (FINESS, SIRET, RPPS rang) ?

Description

Comportement attendu

Gestion des préfixes
des ID nationaux
de PS et de Structure

Quel que soit le format de l'ID national renseigné au niveau de la solution logicielle éditeur (préfixé ou pas) :

  • Les créneaux associés aux PS doivent remonter
  • Les ID renseignés dans la réponse sont bien préfixés
Rappel concernant les préfixes attendus :

- Pour les ID nationaux des PS :
  • Préfixe "0" pour ADELI
  • Préfixe "8" pour RPPS
- Pour les ID nationaux de structure :
  • Préfixe "0" pour les identifiants de cabinet ADELI (ADELI rang)
  • Préfixe "1" pour les FINESS
  • Préfixe "3" pour les SIRET
  • Préfixe "4" pour les identifiants de cabinet RPPS (RPPS rang)
- Pour l'identifiant de structure, respecter cet ordre :
  • Le FINESS (les établissements sanitaires, sociaux et médico-sociaux ont un FINESS)
  • Si pas de FINESS le SIRET
  • Si ni FINESS ni SIRET alors le RPPS rang/ADELI rang (c'est le cas des cabinets libéraux)

Les éditeurs ont la possibilité de récupérer les référentiels nationaux des professionnels de santé et de leurs structures associées via l’annuaire santé de l’ANS qui propose deux modalités d’accès :

Canal

Processus

Extractions à plat

Par le téléchargement des fichiers plats : Extractions en libre accès - L'Annuaire Santé

  • Intitulé du dossier à télécharger : ps_libreacces
  • Intitulé du fichier cible : PS_LibreAcces_Personne_activite
Les données sont ensuite récupérables :
  • colonne "Numéro FINESS site" pour FINESS (sans préfixe)
  • colonne "Numéro SIRET site" pour SIRET (sans préfixe)
  • colonne "Ancien identifiant de la structure" pour RPPS rang ou Adeli rang (avec préfixe)
La donnée "ancien identifiant de la structure" prend la valeur FINESS ou SIRET (avec préfixe) s'ils sont connus, sinon le champ sera complété avec la donnée RPPS_rang ou Adeli_Rang (avec préfixe).
Documentation de référence : Annuaire_sante_fr_DSFT_Extractions_donnees_libre_acces_V2.3.1

Interfaces FHIR

Par la récupération via une API mise à disposition par l'ANS
De nouvelles interfaces sont en cours de co-construction avec les éditeurs.
Ces nouveaux services permettront d'exposer les données des référentiels Personnes physiques/Personnes morales au format JSON, structurés selon la norme d'interopérabilité FHIR. Une première version sera mise à disposition à l'été 2022.
Les StructureDefinition ont été publiées et sont accessibles sur : https://simplifier.net/Modelisationdesstructuresetdesprofessionnels

Quelles sont les principales erreurs rencontrées au cours des tests ?

ID

Description

Comportement attendu

1

Gestion des préfixes des ID
de PS et de Structure

Quel que soit le format de l'ID renseigné au niveau de la solution logicielle (préfixé ou pas) :

  • Les créneaux associés aux PS doivent remonter
  • Les ID renseignés dans la réponse sont bien préfixés.
Rappel concernant les préfixes attendus :

- Pour les ID nationaux des PS :
  • Préfixe "0" pour ADELI
  • Préfixe "8" pour RPPS
- Pour les ID nationaux de structure :
  • Préfixe "0" pour les identifiants de cabinet ADELI
  • Préfixe "1" pour les FINESS
  • Préfixe "3" pour les SIRET
  • Préfixe "4" pour les identifiants de cabinet RPPS

2

Format du numéro de téléphone

Une logique corrigeant le format du numéro de téléphone renseigné dans la solution logicielle doit être mise en oeuvre.
Rappel du format attendu : +33XXXXXXXXX 

      "telecom": [
        {
          "system": "phone",
          "value": "+33XXXXXXXXX"
        }
      ]

3

Spécialité et compétences

L'ensemble des spécialités ou compétences associées aux créneaux, ou au PS, doivent être transmises. Si l'information est codifiée au niveau de l'application, il doit être transmis au sein d'un élément structuré coding. Sinon, le libellé doit être transmis sous forme de texte au niveau de l'élément text.
Exemple : 

    "specialty": [
      {
        "coding": [
          {
            "code": "SM54",
            "system": "https://mos.esante.gouv.fr/NOS/TRE_R38-SpecialiteOrdinale/FHIR/TRE-R38-SpecialiteOrdinale"
          }
        ]
      },
      {
        "text": "ORL"
      },

4

Type de créneau

L'ensemble des types associés aux créneaux doivent être transmis, sous forme codifiée, au niveau de l'élément meta.security.
Exemple : 

    "resourceType": "Slot",
    "id": "1636036800",
    "meta": {
      "profile": [
        "http://sas.fr/fhir/StructureDefinition/FrSlotAgregateur"
      ],
      "security": [
        {
          "system": "https://mos.esante.gouv.fr/NOS/TRE_R314-TypeCreneau/FHIR/TRE-R314-TypeCreneau",
          "code": "PUBLIC"
        },
        {
          "system": "https://mos.esante.gouv.fr/NOS/TRE_R314-TypeCreneau/FHIR/TRE-R314-TypeCreneau",
          "code": "PRO"
        },
        {
          "system": "https://mos.esante.gouv.fr/NOS/TRE_R314-TypeCreneau/FHIR/TRE-R314-TypeCreneau",
          "code": "SNP"
        }
      ]
    },

5

Type et motif de consultation

Au niveau de l'élément serviceType :

  • L'ensemble des types de consultation associés aux créneaux doivent être transmis, sous forme codifiée
  • L'ensemble des motifs de consultation associés aux créneaux doivent être transmis, sous forme de texte libre
Exemple : 
        "serviceType": [
          {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
                "code": "VR"
              }
            ]
          },
          {
            "coding": [
              {
                "system": "http://terminology.hl7.org/CodeSystem/v3-ActCode",
                "code": "AMB"
              }
            ]
          },
          {
            "text": "Suivi médical"
          },
          {
            "text": "Pédiatrie"
          }
        ],

6

Gestion des multiples lieux
de consultation

Lorsqu'un PS dispose de créneaux associés à différents lieux de consultation, il est attendu que l'ensemble des créneaux soient remontés, et soient associés au bon lieu de consultation.

7

Gestion des multiples PS

Lorsqu'une recherche est faite sur plusieurs PS ayant des créneaux disponibles dans la solution logicielle, il est attendu que l'ensemble des créneaux soient remontés, et soient associés au bon PS.

8

Gestion de l'absence de créneaux
et agenda PS

Lorsqu'aucun créneau n'est disponible ou qu'aucun des PS de la recherche n'est présent dans la solution logicielle, un bundle de réponse vide est attendu.
Exemple : 

    "resourceType": "Bundle",
    "id": "8cbb33dc-779e-45e9-a5f6-ea66101288c5",
    "meta": {
      "profile": [
        "http://sas.fr/fhir/StructureDefinition/BundleAgregateur"
      ]
    },
    "type": "searchset",
    "total": 4,
    "link": [
      {
        "relation": "self",
        "url": "https://exemple.com/ans-sas/Slot/?_include=Slot:schedule&_include:iterate=Schedule:actor&status=free&start=ge2021-11-04T14:19:35.760+00:00&start=le2021-11-06T23:59:59.999+00:00&schedule.actor:Practitioner.identifier=urn:oid:1.2.250.1.71.4.2.1%7C810002673899,urn:oid:1.2.250.1.71.4.2.1%7C810100050075&_count=1000"
      }
    ],

9

Eléments vide

Lorsqu'une information optionnelle n'est pas renseignée dans la solution logicielle, l'élément correspondant ne doit pas être transmis au niveau de la réponse. Il ne faut pas transmettre un élément vide.

Rendez-vous

Comment faire la distinction entre un ID national et un ID technique ?

Un ID national possède une structure bien définie dont les spécificités sont explicitées ici. Un identifiant technique SAS prendra la forme d’un UUID (ex. b6e39355-8a61-4556-b340-36f7b95fec6a) où une REGEX peut-être implémentée côté éditeur. Dans les spécifications SAS_SPEC INT_R02_Gestion des comptes régulateurs, au sein de la requête, les champs identifier.system (autorité d’affectation) et identifier.type (type d’identifiant) permettent d’indiquer s’il s’agit d’un identifiant technique SAS ou d’un identifiant national.