Le but de cette page est de regrouper les questions fréquemment posées par les établissements et éditeurs dans le cadre de la mise en place de BaMaRa connecté afin de mutualiser les connaissances.

1. Quel est le format disponible pour transmettre les SDM recueillis dans les applications en mode connecté ?
  • Le format CDA r2 niveau3, format interopérable promu par l’ANS (https://esante.gouv.fr/volet-sdm-mr-set-de-donnees-minimum-maladies-rares)
2. Quel besoin pour le mode autonome lorsque le mode connecté est déployé ?

Les modes autonomes et connecté vont coexister, BaMaRa web complète la saisie via le mode connecté pour les cas suivants :

  • Au sein d’un même CHU, tous les établissements n’ont pas nécessairement le DPI.
  • Certains champs spécifiques sont absents du SDM, donc des dossiers connectés, mais peuvent être remplis sur l’application web (ex : les informations génétiques complémentaires SDM-G demandé par les équipes de génétique).
  • Saisie des dossier MR des fœtus.
  • Avis sur dossier pour des patients externes à l’hôpital donc absents du DPI.

Il permet de plus un accès aux données cumulées de CEMARA, BaMaRa autonome, et BaMaRa connecté ainsi que d’extraire des listes de patients et de générer les données pour compléter les rapports annuels PIRAMIG.

3. Questions sur le modèle de données
  • Traitement et Recherche sont bien reliés directement au patient et non pas au diagnostic, pour des raisons historiques (cela veut en effet dire que si un patient prend 2 traitements maladie rares pour deux diagnostic, on ne sait pas lequel va avec lequel.). Ces champs sont peu utilisés et servent principalement au suivi des médicaments ATU. Effectivement, dans les perspectives d’amélioration un historique des traitements et/ou un lien avec un diagnostic peuvent être des pistes (le SDM v1.11 est cependant fixé pour septembre 2019 afin de permettre aux éditeurs de travailler).
  • La notion de propositus est a prendre dans un sens large. Effectivement une définition stricte imposerait d’indiquer qu’il s’agit du premier patient d’une famille vu pour un diagnostic donné, or il est relié uniquement au patient dans notre cas. Dans notre cas le bloc propositus sert à indiquer les différents membres d’une même famille.Dans les grandes lignes il s’agit du « Premier patient d’une famille donnée vu dans le cadre des maladies rares (pour une instance de BaMaRa donnée, c’est-à-dire en simplifiant pour un hôpital donné) »
4. Une initialisation du DPI est elle prévue ?

« L’initialisation du DPI »  par les données présentes dans CEMARA et/ou BaMaRa aurait été coûteuse et difficile à mettre en œuvre dans les délais impartis, en plus de la problématique importante d’identitovigilance. Il a été décidé de ne pas en faire.

Cela implique que si un patient possède des informations dans BaMaRa et/ou CEMARA lors de l’ouverture du recueil dans le DPI, ces informations seront à ressaisir dans le dossier MR du DPI.

5. Quelle confidentialité/visibilité des data dans BaMaRa autonome ?

Un intervenant peut voir :

  • Toutes les données du dossier des patients auquel il a accès (diagnostic, activités etc. même sur d’autres centres).
  • A accès uniquement aux patients de son (ses) centre(s), et ne peut modifier que les informations liées à des prises en charge dans ses centres.
  • Un mode dit « brise-glace » permet au médecin de voir les patients hors de son centre dans un même hôpital, mais avec un message d’information et un engagement à ce que cette consultation soit légitime.
6. Comment utiliser les codes hôpital ?

Afin d’identifier un hôpital au sens du PNMR une, une liste de codes a été établie et publiée page https://www.bndmr.fr/un-cadre-dinteroperabilite-pour-les-maladies-rares/ .

Cette liste a été établie à partir des établissements définis dans le processus de labellisation.

Les codes ‘hôpital’ permettent d’identifier l’émetteur du dossier Maladie Rares dans le cadre du mode connecté.

Ils formalisent aussi le périmètre « hôpital », au sein duquel un médecin peut voir les patients des différents centres dudit hôpital (cf. question visibilité des données).

Par exemple l’ensemble des établissements du CHU de Rennes forment un même hôpital au sens du PNMR, un patient vu dans plusieurs de ces établissements partagera un même dossier, et pourra être vu par les médecins des différents établissements composant le CHU.

7. Comment peuvent être identifiés les intervenants ?

Les intervenants doivent être identifiés dans deux cas

  • Le médecin de référence est un médecin, il doit être identifié par son RPPS.

6.3         Nom du médecin de référence
6.4         Prénom du médecin de référence
6.5         Identifiant RPPS du médecin de référence

  • Pour les intervenants participant aux activités, on parle alors des champs suivant du SDM MR CDA :

7.5          Nom du PS réalisant l’activité
7.6          Prénom du PS réalisant l’activité
7.7          Identifiant national du PS réalisant l’activité
7.8          Profession du PS réalisation l’activité

PS est à prendre au sens large de personnel soignant.

Le champ 7.7 doit être rempli par le numéro au RPPS si disponible, à défaut le numéro Adeli ou le n° d’identifiant interne de la personne dans le DPI. 

Techniquement le champ 7.8 est toujours obligatoire, et le triplet (7.5, 7.6, 7.7) ne peut être remplit que si les trois champs sont renseignés.

Exception importante : pour la profession MED (médecin) seul le code RPPS est accepté.

8. Comment utiliser les référentiels Orphanet de niveau Maladie et Catégorie de maladie ?

La procédure est décrit dans la page décrivant le cadre d’interopérabilité : https://www.bndmr.fr/boite-a-outils/kit-editeurs/un-cadre-dinteroperabilite-pour-les-maladies-rares/

box type= »tick »]9. Un environnement Bac à sable sera t’il mis à disposition ?[/box]

L’environnement est disponible à l’adresse : https://demo.bamara.bndmr.fr/login

10. Quelle version de la CIM10 peut être utilisée ?

Les référentiels et leurs versions à utiliser sont à retrouver sur la page : https://www.bndmr.fr/boite-a-outils/kit-editeurs/un-cadre-dinteroperabilite-pour-les-maladies-rares

11. Pourquoi les foetus sont ils absent du SDM MR CDA ?
  • Le SDM présent dans la section publications est à destination du grand public et reprend le besoin métier.
  • La section SDM MR CDA est la déclinaison fonctionnelle de ce SDM, tel qu’il doit être implémenté dans les applications. Il est adapté au format d’échange CDA, et ne contient donc pas les informations fœtus qui existent dans SDM besoin métier car le CDA ne permet pas l’échange de dossier foetus à proprement parler.
12. Le champ ‘traitement spécifique’ est il obligatoire ? Question plus générale des champs obligatoires au sein d’un bloc facultatif.

Dans le SDM MR CDA le champ ‘traitement spécifique’ (11.1) est noté avec une cardinalité 1…1. Il n’est cependant obligatoire que si le bloc traitement (11) est rempli, ce dernier étant facultatif.

De la même manière le chapitre 6 (qui conserve pour l’instant son nom historique de ‘parcours de soin’), et correspond au bloc 6 Prise en charge du SDM MR CDA, le bloc entier est facultatif.

Si ce bloc facultatif est présent, alors les attributs [1…1] et [1…n] qui le composent sont obligatoires.

13. Quel mode de saisie est prioritaire lorsque les recueils DPI et Autonome sont utilisés pour un même patient ?

Pour un patient pris en charge en génétique et suivi via le mode autonome BaMaRa, on verrait deux cas :

Cas 1 – Le même patient est vu pour un autre site de l’hôpital pour lequel il est suivi via le DPI (BaMaRa connecté), ceci en plus du site de génétique pour lequel il est déjà enregistré dans BaMaRa autonome.

o    le ‘tronc commun’ regroupe les champs suivants du SDM MR :

Ce sont des données au niveau patient, elles seront écrasées lors d’une mise à jour DPI.

Cette mise à jour intervenant lorsqu’un acte est réalisé, cela veut dire que les informations du DPI sont ultérieures à la saisie en autonome.

Elles sont donc censées être plus à jour.

Il est de plus important par exemple qu’une mise à jour du statut vital dans le DPI soit reportée en autonome, même si cette màj est le fait d’un autre site que celui de génétique.

o   Les blocs ‘hors tronc commun’ qui ne seront pas mis à jour par cet autre site sont les suivants :

Pour ces derniers il n’y a pas de risque d’écrasement par les données BaMaRa connecté car les blocs vont s’ajouter (gestion cumulative => pas d’écrasement).

Cas 2 – Le même patient est saisi pour le même centre génétique en connecté, en plus du mode autonome.

o   Sur les champs tronc commun définis ci-dessus, le DPI prend la main.

o   Hors tronc commun, le bloc suivant est prioritaire dans le DPI :

o  Les blocs suivants s’additionneront :

Cela veut dire que les activités et diagnostics créés en Autonome et en Connecté seront tous conservés (y compris si la même activité est saisie en autonome et en connecté, le doublon sera conservé).

PS1 : exception à cette addition : si l’ensemble des attributs sont identiques alors la nouvelle activité/diagnostic ne sera pas ajoutée

PS2 : la gestion du cas ‘diagnostic’ est toujours en cours de définition (risque de doublons).

In fine, les cas d’écrasement problématiques semblent peu nombreux dans la mesure où le codage au sein d’un même centre est uniforme (i.e. tout le personnel du site génétique code en autonome). En effet, les mises à jours écrasant les données et provenant d’autres sites ne concernent pas les données propres au suivi par le site de génétique (prise en charge, activité, diagnostic) mais concernent à l’inverse les données communes à tous les sites (traitement MR, etc.) pour lesquelles une mise à jour semble légitime.

Pour rappel, un écrasement se produira lorsqu’une modification sera saisie dans le DPI, ce qui déclenchera l’envoi du dossier par format d’échange (CDA ou Pivot) et mise à jour de la base de données BaMaRa. Cela veut dire que qu’un dossier mettant à jour la base sera forcément ‘le plus récent’.

Effectivement, au-delà de la problématique d’identitovigilance le développement d’un flux BaMaRa -> DPI n’est pas aujourd’hui prévu et soulèverait d’autres problématiques.

C’est un sujet en effet complexe, si un flou persiste n’hésitez pas à me le remonter.

PS3 : pour les cas d’écrasement, ils n’arrivent que si la donnée du DPI est renseignée.

Ex : si le bloc anténatal est renseigné en autonome mais que les champs sont tous laissés à vide dans le DPI, une mise à jour du tronc commun par le mode connecté n’écrasera pas les données déjà présentes dans le bloc anténatal (cela est vrai champ par champ).

14. Pourquoi les champs relatifs aux informations génomiques (« Cartouche Chromosomique ») sont absents des formats d’échange CDA/Pivot ?

Pour information les formats d’échange Pivot et DPI sont conçus pour véhiculer le SDM, soit le set de data minimum commun à toutes les pathologies. Les informations supplémentaires propres à la génétique ne faisant pas partie de ce SDM transverse elles ne sont pas transmissibles en Connecté à ce jour.

15. Comment gérer le booléen étendu lorsqu’il est facultatif ?

Ce dernier peut prendre fonctionnellement les valeurs Y/N/inconnu

Inconnu est différent de non rempli (car optionnel) : cela veut dire que l’information a été demandée au patient, et que sa réponse est ‘ne sait pas’ (booléen non renseigné aurait indiqué que la question n’a pas du tout été posée au patient).

16. Différence entre « 3.1 Patient atteint de Maladie Rare » et « 10.6 Sujet apparemment sain »
  • « 3.1 Patient atteint de maladie rare » est vrai lorsqu’il y a suspicion de Maladie Rare pour ce patient, cela peut être :
    • Un patient présentant des symptômes évoquant une maladie rare (avec ou sans diagnostic).
    • Un porteur sain, pour lequel il est établi qu’il possède une mutation génétique pouvant entrainer une maladie rare mais sans symptômes à ce jour (ce qui renvoie alors à l’item 10.6 ci-dessous).

La fonction de ce champ est de permettre la saisie de prises en charge Maladie Rare uniquement pour les patients maladie rares.

  • « 10.6 Sujet apparemment sain » permet d’indiquer que le patient est sain mais porteur de la mutation pouvant entrainer une maladie rare (par exemple une mutation est repérée par examen génétique mais le patient ne présente pas de symptômes à ce jour).
17. Comment utiliser le référentiel HGNC ?

La nomenclature HGNC est décrite dans la page dédiée aux référentiels : https://www.bndmr.fr/boite-a-outils/kit-editeurs/un-cadre-dinteroperabilite-pour-les-maladies-rares/

18. Le sexe ‘Inconnu’ peut il être renseigné pour un patient non-foetus ?
  • Oui, pour les patients de moins de deux ans. (évolution attendue en 2024)
19. Le sexe attendu est il le sexe administratif ou le sexe biologique ?
  • Le sexe administratif. Bien que le sexe biologique ait son importance dans le cadre médical des maladies rares, la donnée recueillie ici l’est à des fins administratives.
    En conséquence, le sexe doit être mis à jour après un changement de sexe officiel.
20. Comment gérer les différents types d’INS ?
  • Si dans le SDM seul le numéro d’INS est nécessaire, il sera en plus nécessaire de qualifier le type d’INS dans le cadre du mode connecté. En effet, le CDA décrit dans le CI-SIS indique que pour pouvoir saisir un INS, il faut préciser le type de celui-ci (INS ou INS-C, via l’OID).
  • Pour rappel, historiquement le NIR ne pouvait pas être utilisé comme INS, un INS calculé a alors été proposé. Des changements légaux ont rendu obligatoire l’usage de l’INS-NIR.
  • Afin de pouvoir réconcilier les fiches patient, il est nécessaire de connaitre le type d’INS utilisé afin de réconcilier les INS-NIR entre eux, et les INS-C entre eux (les détails de la réconciliation des fiches patients restent disponible dans notre Spécification Réconciliation des dossiers entre BaMaRa autonome et connecté )
21. L’item 7.10 Lieu de consultation est facultatif, mais il est indiqué dans le guide de codage que ce champ doit être rempli si la consultation n’est pas réalisée sur site. Comment sera traité ce champ lorsqu’il n’est pas renseigné ?

Si l’activité a lieu à l’hôpital, il ne faut pas renseigner cette élément.