Vous devez indiquer avec quel profil vous êtes référencé. En revanche, dans les scénarios d’installation intégrés dans le bon de commande, vous n’êtes pas obligé d’indiquer quel sera l’opérateur MSSanté qui fera l’objet de l’installation. Mais, au moment de la demande de solde, pour la MOM ou la VA, vous devrez indiquer l’adresse MSSanté effective utilisés par le client. Les contrôles a posteriori s’appuieront sur cette adresse.
Dans le fichier PS_LibreAcces_Personne_activite, une ligne correspond à une activité d'un professionnel. Ainsi, si un professionnel de santé possède plusieurs activités, celui-ci aura plusieurs lignes dans le fichier. Par exemple, pour un médecin ayant une activité de libéral dans son cabinet, et une activité de salarié dans un établissement de santé, il apparaîtra deux fois dans le fichier, avec une ligne par activité. Les adresses renseignées correspondent aux adresses des activités.
Dans le fichier Extraction_Correspondance_MSSante, une ligne correspond à une boîte aux lettres MSSanté d'un professionnel. Un professionnel avec plusieurs boîtes aux lettres MSSanté aura donc plusieurs lignes dans ce fichier. Par ailleurs, une BAL MSSanté nominative est obligatoirement reliée à un PS (donc à son numéro RPPS ou ADELI), mais n'est pas forcément reliée à une structure. C'est pourquoi l'adresse postale n'est pas toujours renseignée dans ce fichier de correspondance MSSanté, et qu'il y a donc des différences d'adresse entre les deux fichiers.
Pour plus d’information concernant ces fichiers, vous pouvez consulter le Dossier de Spécifications Fonctionnelles et Techniques (DSFT) de l’Annuaire Santé.
Effectivement, il y a une anomalie sur le validateur du metadata lorsque l'on passe une liste de prénoms.
Nous allons procéder à la mise en place de corrections.
En attendant les corrections, il ne faut pas tenir compte de cette erreur.
Nous nous excusons pour la gêne occasionnée.
Non.
On se fie au nombre de BAL déclaré. Une date sera fixée dans le nouveau contrat opérateurs. Toute nouvelle boite ouverte ne nécessite pas un effort de déploiement massif. Cet effort a déjà été réalisé pendant l’ouverture des anciennes boites
Dans la preuve ANN 4.1.1, dans le cas où le système met à jour les données de façon synchrone, la démonstration du paramétrage de la fréquence d’intégration de l’Annuaire de santé n’est pas requise dans la mesure où il est montré que le système opère de façon synchrone. Plus spécifiquement, dans le cas où le système utilise l’API FHIR, la mention de la méthode utilisée (full, delta, unitaire) est attendu également.
Dans le cas d’intégration asynchrone de l’Annuaire de santé, il est attendu de montrer l’existence et la possibilité de paramétrage de la fréquence d’intégration. L’Annuaire subissant un grand nombre de modifications chaque jour, il est fortement recommandé de tendre vers une fréquence d’intégration quotidienne afin de garantir la qualité des données.
Si le Système utilise les fichiers d’extraction disponible sur le site https://annuaire.sante.fr, il est attendu de montrer que le service appelle les services de publication du répertoire sectoriel de référence des personnes physiques (Annuaire Santé) et l'intègre, fournir les logs du chargement du fichier.
Si le Système utilise l’API FHIR, il est attendu de montrer que le service appelle l'API FHIR du répertoire sectoriel de référence des personnes physiques, fournir un exemple de requête et le retour de l'appel des ressources FHIR de l’environnement bac à sable.
Dans le cas de l’API FHIR :
- Il est possible de récupérer un jeton d’authentification vie l’API Manager Gravitee via le lien suivant : https://portal.api.esante.gouv.fr/
- Il est possible de se connecter à l’API FHIR Annuaire de Santé en libre accès via le lien suivant : https://gateway.api.esante.gouv.fr/fhir/
- Vous trouverez le guide de démarrage de l’API via le lien suivant : https://ansforge.github.io/annuaire-sante-fhir-documentation/pages/quick-start/readme
Oui, ces exigences sont obligatoires mais elles peuvent être optionnelles pour les cas suivants :
- MSS 9 : Cette exigence porte sur la réponse à un courriel MSS. Certaines solutions ne peuvent pas recevoir de courriel MSS et passe par une boite applicative, elle ne font qu'émettre des messages. Cette exigence n'impose pas à une solution de savoir répondre à un message. Ainsi, lors du dépôt de la preuve l’éditeur doit préciser que "sa solution émet des messages uniquement à partir de boîtes applicatives. Cette preuve n’est pas applicable à la solution candidate au référencement."
- MSS 14 : Cette exigence porte sur la gestion des accusés de réception à un courriel MSS reçu. Certaines solutions ne peuvent pas recevoir de courriel MSS et passe par une boite applicative, elle ne font qu'émettre des messages. Elles sont donc dans l'incapacité de fournir une preuve sur la gestion des accusés de réception. Ainsi, lors du dépôt de la preuve l’éditeur doit préciser que "sa solution émet des messages uniquement à partir de boîtes applicatives. Cette preuve n’est pas applicable à la solution candidate au référencement."
Deux possibilités existent :
- La réception d’un message MS Santé si vous avez intégré une solution de messagerie pour la consultation des messages.
- L’utilisation d’un document papier avec datamatrix INS
- Un exemple peut être la réception d’un document de santé papier apporté par le patient sur lequel on scanne le datamatrix INS.
- Pour simuler cela on peut par exemple :
- Générer un CR d’entretien ou BPM comme demandé par l’exigence DOC 3.
- Imprimer ce document.
- Utiliser ce document et son datamatrix comme flux entrant dans une autre instance logicielle (domaine d’identification différent).
- Et ainsi tester la fonction d’intégration d’un INS provenant d’un autre domaine d’identification.
Il s'agit de permettre aux médecins d'extraire les données et/ou les tableaux de bord générés par le logiciel. Ceci peut-être particulièrement utile si le médecin change de logiciel et veut conserver ces éléments de preuves pour le financement à l'usage (cf forfait structure).