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. Quels sont les deux formats disponibles pour transmettre les SDM recueillis dans les applications en mode connecté ?
  • Le format CDA r2 niveau3, format interopérable promu par l’ASIP santé et en cours de définition avec eux (date cible de publication pour concertation : 10/12). La philosophie de ce document (« Clinical Document Architecture » est d’être un compte rendu d’activité, donc envoyé au fil de l’eau. Il ne doit donc pas servir à faire de la reprise d’historique sur des dossiers éventuellement saisis en phase Intégration si la phase Transmission n’est pas encore déployée).
  • Le format Pivot qui est un format développé en interne par la BNDMR et permet de gérer deux cas non gérés par le CDA : l’envoi de dossier relatif à des fœtus en tant que patients, la reprise d’historique.
2. Quelles sont les fonctions spécifiques assurées par le format Pivot ?

Le format pivot a deux usages :

  • La reprise d’historique non permise par le CDA
  • La gestion des dossiers pour lesquels le patient est un fœtus, lorsque le DPI le permet.

Ce second besoin étant pérenne, le format Pivot est pérenne.

3. 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 : le cartouche d’anomalies cytogénétiques 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.

4. 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.
5. Une initialisation du DPI est elle prévue ?

« L’initialisation du DPI »  par les données présentes dans CEMARA et/ou BaMaRa semble couteuse et difficile à mettre en œuvre dans les délais impartis, de plus il y a une problématique importante d’identitovigilance.

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.

6. 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.
7. 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 http://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.

8. 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. Si ces deux numéros manquent il ne faut remplir que le code profession.

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é.

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

Point d’attention, l’annexe 8 du package initialement fourni, relative à la codification Orphanet, ne contenait que les codes maladies Orpha. La page Terminologies, jeux de valeurs, et annuaires est à présent complété par le fichier Groupe de maladie Orpha. Il est utilisé pour remplir le couple suivant :

9.2 Code diagnostic de la maladie rare
Libellé diagnostic de la maladie rare                Le référentiel Groupe de maladie Orphanet est utilisé pour remplir le couple suivant :
9.3 Code signes complémentaires associés à la MR
Libellé signes complémentaires associés à la MR
10. Un environnement Bac à sable sera t’il mis à disposition ?

Un délai de mise en œuvre important à prévoir, mais ce bac à sable est prévu.

A défaut, des vidéos sont disponibles sur le site de la BNDMR afin de visualiser la cinématique actuelle de BaMaRa web.

Aussi, nous prenons en compte la nécessité d’une infrastructure de qualification des échanges pour le mode connecté.

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

CIM10 : la nomenclature utilisée par les établissements peut être utilisée.

BaMaRa utilise une photo de la CIM10 de 2015 qui peut entrainer de légers déphasages.

12. 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.
  • Le format Pivot permet lui la transmission de tous les champs du SDM métier, en ce sens le format technique pivot est une déclinaison fonctionnelle du SDM métier complet.
13. Erratum sur les bornes d’âge

Dans le SDM MR CDA , le champ 8.5 devrait avoir les mêmes règles que 8.1.

14. 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.

15. 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).

16. Pourquoi les champs relatifs aux anomalies cytogénétiques (« 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.

17. 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).

18. Quels sont les champs spécifiques au mode autonome ?
Numéro de dossier du service*
Nom de naissance du père*
Précision « patient adressé par »*
résumé des anomalies chromosomiques*
Anomalie par chromosome*
Mode de transmission*
Commentaire*
Précision sur l’identité des PS réalisant l’activité*
Terme auquel la/les anomalie(s) a/ont été diagnostiquée(s)*
Proposition d’IMG*
échographie/échocardiographie*
Scanner/scanner 3D*
IRM/IRM cérébrale*
Biopsie du trophoblaste*
Amniocentèse*
19. 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).
20. Comment utiliser le référentiel HGNC ?

La nomenclature HGNC est utilisée pour les champs suivant du SDM :

confirmation du diagnostic
10.4 Code gènes [0..*] Gènes associés au diagnostic Code HGNC Annexe 9 – Terminologie HGNC code
Libellé gènes Gènes associés au diagnostic Code HGNC Annexe 9 – Terminologie HGNC Chaîne de caractères

 
La BNDMR souhaite récupérer à chaque fois les deux éléments du couple (code, libellé)  définissant le gène et correspondant aux colonnes (HGNC_code,term) de la nomenclature Annexe 9 – Terminologie HGNC.
 
L’essentiel est le code HGNC_code identifiant un gène unique dans la classification HGNC, le « term » étant un alias dudit gène (ce dernier est utile pour le médecin car c’est ce term qu’il connait).
 
Il peut donc y avoir plusieurs alias (term)  pour un même gène (HGNC_code), ici HGNC:10671 est connu sous plusieurs dénominations (terms) dont SDCCAG8, qui est accessoirement le label préférentiel (pref_label).
 

term HGNC_code is_pref_label pref_label gene_name
SDCCAG8 HGNC:10671 true SDCCAG8 serologically defined colon cancer antigen 8
NY-CO-8 HGNC:10671 false SDCCAG8 serologically defined colon cancer antigen 8
CCCAP HGNC:10671 false SDCCAG8 serologically defined colon cancer antigen 8
SLSN7 HGNC:10671 false SDCCAG8 serologically defined colon cancer antigen 8
NPHP10 HGNC:10671 false SDCCAG8 serologically defined colon cancer antigen 8
BBS16 HGNC:10671 false SDCCAG8 serologically defined colon cancer antigen 8

 

La donnée d’alias ‘term’ ne suffit cependant pas à identifier un gène, car dans certains cas un même alias pointe vers deux gènes comme par exemple 2F1, qui sert d’alias à deux gènes distincts sur deux chromosomes distincts : HGNC:6380 (connu sous le label préférentiel KLRG1)  et HGNC:10991 (connu sous le label préférentiel SLC25A5).

 

term HGNC_code is_pref_label pref_label gene_name
2F1 HGNC:6380 false KLRG1 killer cell lectin-like receptor subfamily G, member 1
2F1 HGNC:10991 false SLC25A5 solute carrier family 25 (mitochondrial carrier

 

term HGNC_code is_pref_label pref_label gene_name
2F1 HGNC:6380 false KLRG1 killer cell lectin-like receptor subfamily G, member 1
CLEC15A HGNC:6380 false KLRG1 killer cell lectin-like receptor subfamily G, member 1
KLRG1 HGNC:6380 true KLRG1 killer cell lectin-like receptor subfamily G, member 1
MAFA HGNC:6380 false KLRG1 killer cell lectin-like receptor subfamily G, member 1
MAFA-L HGNC:6380 false KLRG1 killer cell lectin-like receptor subfamily G, member 1

 

Ce ‘doublon’ du term étant utilisé internationalement (https://www.ncbi.nlm.nih.gov/gene/?term=2F1 reprend par exemple ce doublon), nous devons le conserver et utiliser le HGNC_Code (aka code HUGO) proprement dit pour identifier le gène.

 

Ce code HGNC n’étant pas nécessairement connu du métier, il faut afficher le term et le cas échéant un choix entre les deux pref_label (et/ou les deux HGNC Code).

Cela donne dans le cas standard :

  • Le médecin saisit le gène par son term ‘SLSN7’, le champs HGNC HGNC:10671 est automatiquement rempli dans l’IHM en complément du term SLSN7, le médecin n’a plus qu’à valider.

Et dans le cas de doublon d’alias :

  • Le médecin saisit le term ‘2F1’ , il peut être intéressant de lui afficher un choix entre le HGNC codes 6380 et 10991 afin de recueillir les informations essentielles au SDM, mais aussi d’afficher les pref_labels/noms principaux de ces deux gènes à savoir KLRG1 et SLC25A5 afin de l’aiguiller dans son choix.

Note sur les noms complets des gènes :

La base étant internationale de source anglophone, les libellés longs gene_name ne sont pas disponibles en Français.

Pour information ils ne semblent pas être utilisés par le métier qui lui préfèrent la version abrégée ‘term’.

Sauf erreur de notre part, un gène (ie. Un HGNC Code) unique possède un label long « gene name » unique.