Quatre profils existent : 

• Responsable de structure, 
• Porteur d’offre, 
• Responsable de la disponibilité en lits/places 
• Référent de la saisie de la disponibilité en lits/places.

Les comptes utilisateurs sont à la main de votre GRADeS. En ce sens et en cas d'absence de compte, nous vous invitons à contacter.

Les comptes utilisateurs sont créés via un premier import de fichier CSV transmis par chaque région à l’équipe programme ROR. En ce sens et en cas d'absence de compte, nous vous invitons à contacter votre GRADeS qui pourra créer directement les utilisateurs dans le ROR National

Oui. Un même compte utilisateur peut se voir attribuer plusieurs profils sur des périmètres différents via les habilitations. 

La page de détail d'un compte (disponible depuis l'onglet Administration) affiche d'ailleurs un tableau listant tous ses profils et périmètres avec la région ayant donner ces droits.

Les profils sont : Responsable structure, Porteur d’offre, Responsable de disponibilité en lits/places, Référent de la saisie de disponibilité en lits/places.

Les exigences MS.AHI/SISIAO.09 et MS.AHI/SISIAO.12 précisent les règles de gestion et d’échange des données d’identité entre le SI SIAO et le DUI.

Les principales évolutions concernent :

• la récupération des données d’une PERSONNE via le flux GET PERSONNE et leur restitution dans le DUI ;
• les correspondances de champs lors de la première intégration ;
• les règles applicables lors de la mise à jour d’une PERSONNE déjà connue ;
• l’attribution automatique de l’attribut « identité douteuse » ;
• les correspondances lors de la transmission des données du DUI vers le SI SIAO via PUT PERSONNE ;
• le versionnement des objets.

Quelles correspondances appliquer lors de la première intégration ?

Lorsqu’une PERSONNE est intégrée pour la première fois depuis le SI SIAO :

• Nom SI SIAO → Nom de naissance DUI
• Nom d’usage SI SIAO → Nom utilisé DUI
• Prénom SI SIAO → Prénom utilisé DUI
• Premier prénom de naissance DUI → « INCONNU »

Quelles règles appliquer lors d’une mise à jour ?

Pour une PERSONNE déjà connue du DUI, lors d’une mise à jour reçue du SI SIAO :

• Prénom SI SIAO → Prénom utilisé DUI uniquement

L’attribut « identité douteuse » doit-il être appliqué ?

Oui. Toute identité créée à la suite d’un transfert de données d’identité depuis le SI SIAO doit se voir attribuer automatiquement, par défaut, l’attribut « identité douteuse ».

Quelles données transmettre du DUI vers le SI SIAO ?
Lorsqu’un utilisateur modifie et valide les informations d’une PERSONNE, le DUI doit transmettre automatiquement les données via le flux PUT PERSONNE :

• Nom de naissance DUI → Nom SI SIAO
• Nom utilisé DUI → Nom d’usage SI SIAO
• Prénom utilisé DUI → Prénom d’usage SI SIAO

Non. Le certificat de conformité HDS de l’hébergeur constitue un élément de preuve recevable pour les populations relevant du périmètre de l’hébergement (par exemple : exploitation, administration ou maintenance de l’infrastructure lorsqu’elles sont couvertes par le périmètre certifié).

Toutefois, ce certificat ne permet pas à lui seul de démontrer que les autres populations intervenant sur le système d’information de l’éditeur (par exemple : conception, développement, intégration, support fonctionnel, etc.) bénéficient également des actions de sensibilisation exigées.

L’éditeur doit obligatoirement compléter cette preuve par une documentation décrivant son dispositif de sensibilisation (PSSI ou autre document équivalent) pour les populations non couvertes par le certificat HDS.

Il doit donc fournir également une PSSI pour une partie du périmètre ce qui justifie de compléter le template correspondant pour y pointer les éléments attendus.
 

L’identification du patient doit comporter l’ensemble des éléments constitutifs de l’identité INS, à savoir :

• le nom de naissance ;
• les prénoms de naissance ;
• la date de naissance ;
• le sexe ;
• le lieu de naissance – code INSEE ;
• le matricule INS, complété par son OID.

Cet attendu est explicitement précisé par l’exigence DB.SO.105, qui mentionne l’utilisation des informations contenues dans l’entête du Compte-Rendu pour l’identification du patient, à savoir « INS accompagné de ses traits stricts ».

Dans le cadre de la trace d’audit définie par DB.SO.43, ces informations doivent être véhiculées au niveau du « ParticipantObjectID » du bloc « C.Patient AuditMessage/ParticipantObjectIdentification ».

Aucun format de représentation particulier n’est imposé par la spécification. L’utilisation d’un format tel que HL7 CX est possible mais non obligatoire ; une représentation libre est acceptable dès lors que l’ensemble des éléments constitutifs de l’identité INS est effectivement véhiculé et exploitable.

La formulation actuelle de DB.SO.43, qui mentionne uniquement « Identifiant INS du patient », peut prêter à confusion. Cet attendu doit être compris en cohérence avec DB.SO.105 et avec la définition des traits stricts composant l’INS.

Le fichier des structures éligibles a été établi à partir de la situation à fin 2023. Il recense les structures à jour de leur accord conventionnel interprofessionnel (pour les MSP) ou de leur accord national (pour les CDS), et ayant effectué leur déclaration d'effectifs auprès de l'Assurance maladie. Ce fichier ne devrait pas être réactualisé. Les structures créées après fin 2023 ne sont donc pas éligibles au dispositif. Les causes possibles d'absence de ces structures dans le fichier de référence peuvent être : une déclaration d'effectifs non réalisée, un accord conventionnel non signé, ou encore une erreur dans la collecte des données.  Pour les structures créées après fin 2023 et non éligibles dans le cadre du dispositif collectif (MSP/CDS), des bons de commande individuels au niveau du médecin peuvent être envisagés. Cette option ne s'applique cependant pas aux centres de santé.

Oui, l'ensemble des types de documents listés dans le profil « Structure d'exercice coordonné » est requis, car ce profil a été défini de façon standardisée pour couvrir l'ensemble des structures d'exercice coordonné. Il s'agit d'exigences de niveau CDA R1 (format minimal), ce qui signifie qu'aucune spécification particulière n'est imposée sur le contenu du document : un document avec un titre suffit. Ainsi, même si une carte d'implant ou un bilan bucco-dentaire n'est pas une production habituelle de la structure concernée, il doit être techniquement possible de produire un tel document depuis le logiciel, même avec un contenu minimal.

Sur le premier point : les statistiques sont demandées à deux niveaux distincts – à l'échelle du professionnel de santé (identifié par son numéro RPPS) et à l'échelle de la structure (identifiée par son numéro FINESS). Pour les cabinets de groupe avec plusieurs RPPS, il n'est pas spécifiquement demandé d'agréger les données, mais cette fonctionnalité est bienvenue si elle est implémentée.  
Sur le second point : aucune spécification n'a été posée sur ce point. Par logique fonctionnelle, chaque praticien devrait visualiser ses propres statistiques. L'accès aux statistiques d'un autre praticien du cabinet est laissé à l'appréciation de l'éditeur.  Il est également précisé que des taux supérieurs à 100 % sont possibles et acceptables : par exemple, si un médecin envoie plusieurs documents au DMP pour une même consultation (plusieurs ordonnances, etc.), le taux de documents transmis par consultation peut dépasser 100 %. Ce cas ne constitue pas une anomalie.

Oui, ce scénario est tout à fait acceptable. L'exigence ne mentionne pas spécifiquement une secrétaire : elle porte sur le cas où la CPS est insérée dans un poste différent de celui sur lequel le professionnel travaille. Un médecin connecté sur deux postes distincts (l'un sans CPS, l'autre avec sa CPS) correspond parfaitement à ce scénario et constitue une preuve valide.

Un professionnel peut bénéficier d’un financement « Vague 1 + Vague 2 » dès lors :

• qu’il n’a pas déjà bénéficié du financement de la mise à jour Vague 1, quel que soit l’éditeur ;
• qu’il atteste ne pas avoir payé lui-même la mise à jour vague 1.

Un bon de commande Vague 1+vague 2 signé par un professionnel ne répondant aux conditions précisées ci-dessus sera refusé par l’ASP, un nouveau bon de commande uniquement  vague 2 sera à faire signé.

Oui, il faut en faire la demande via la messagerie Convergence
Un éditeur n’est pas tenu de maintenir un profil pour lequel il ne souhaite finalement pas être référencé.
Cette décision peut être prise jusqu’au référencement final.
Rappel de l’AF :

• Si le Client est une Structure d’exercice coordonné, alors la Solution logicielle doit disposer du Profil « Structures d’exercice coordonné » et du Profil « Médecin traitant et Suivi de l’enfant ».
• Si le Client est un médecin ayant une activité de médecin traitant déclarée (adultes et/ou enfants), d’au moins 10 patients auprès de l’Assurance Maladie, alors la Solution logicielle doit disposer du Profil « Médecin traitant et Suivi de l’enfant ».

Cette distinction n’est plus présente dans l’exigence MDV-07 de la vague 2.
Deux tableaux de bord distincts existent désormais :

• MDV-07 : indicateurs relatifs aux envois vers le DMP et MSSanté ;
• INS-02 : indicateurs relatifs aux statuts de qualification des INS de la patientèle.

La confusion provient probablement d’exigences historiques de la vague 1 qui autorisaient encore certains usages avec des INS récupérées ou non qualifiées.