Service d'Accès aux Soins
1.0.0 - trial-use France flag

This page is part of the Service d'Accès aux Soins (v1.0.0: trial-use) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version in its permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions

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.

Quelles sont les ressources à transmettre lorsqu’un créneau de disponibilité transmis est mis en visibilité d’une ou plusieurs CPTS ?

Il est attendu dans le fichier de réponse JSON d’avoir la relation : 1 ressource HealthcareService pour 1 ressource Organization (modélisant la structure CPTS).
Dans la structure du fichier de réponse, si un créneau est associé à plusieurs CPTS, alors il y aura autant de références à de ressources HealthcareService qu’il y a de CPTS.

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
Une API en libre accès, permettant 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 est mise à disposition avec la documentation associée ci-dessous :
<https://ansforge.github.io/annuaire-sante-fhir-documentation/>

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"
        },
        {
          "system": "https://mos.esante.gouv.fr/NOS/TRE_R314-TypeCreneau/FHIR/TRE-R314-TypeCreneau",
          "code": "CPTS"
        }
      ]
    },

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"
          }
        ],

 

Créneau de type CPTS

Dans le cas d'un créneau mis en visibilité d'une (ou plusieurs) CPTS, des données supplémentaires sont à renseigner au sein de la ressource Slot, au niveau du serviceType.
- Le type de soins correspondant aux structures de CPTS
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"
          },
          {
            "coding": [
              {
                "system": "https://mos.esante.gouv.fr/NOS/TRE_R66-CategorieEtablissement",
                "code": "604"
              }
            ],
            "extension": [
              {
                "url": "http://hl7.org/fhir/5.0/StructureDefinition/extension-Slot.serviceType",
                "valueReference": {
                  "reference": "HealthcareService/e9e31708-9550-4197-8c32-ae541b6a5cbd"
                }
              }
            ]
          },
        ],
- Il sera également attendu de transmettre les ressources HealthcareService et Organization correspondantes (cf. tableau de valeur et nomenclature 2.3.1 et 2.3.2)

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.

10

Créneau mis en visibilité de 2 CPTS

à venir

11

Créneau non rattaché à une CPTS

Si pour une ressource Slot, le type de créneau ne contient pas la valorisation `CPTS` (ID 14) mais uniquement PUBLIC, PRO et/ou SNP, alors aucune donnée supplémentaire n’est attendue.
On est dans la configuration du flux d'agrégation de disponibilités INT_R01 (PS à titre individuel) qui a déjà été implémenté par l'éditeur.

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.