Questions fréquentes

Oui, la gestion de l'historisation des versions de documents est bien obligatoire. Lorsqu'un document a fait l'objet d'une ou plusieurs mises à jour, il doit être possible d'accéder aux versions antérieures de ce document et de les visualiser. L'enjeu est médico-légal : les professionnels de santé ont exprimé le besoin de pouvoir consulter l'historique des versions d'un document (par exemple, un compte-rendu modifié).
En revanche, l'ergonomie et le mode d'implémentation de cette historisation ne sont pas spécifiés. Les éditeurs sont libres de choisir : affichage direct des versions antérieures, accès via un menu contextuel ou un clic sur le document, indication discrète qu'il existe des versions antérieures, etc. 
pour en savoir plus

La météo de service publiée par l'ANS (https://status.esante.gouv.fr/) ne couvre, à ce jour, que les services de l'ANS elle-même et ne remonte pas l'état de disponibilité des services de l'Assurance Maladie (dont le DMP fait partie). Des travaux sont en cours pour intégrer le statut du DMP dans cette météo. 
En pratique, les éditeurs disposent de deux moyens pour détecter une indisponibilité du DMP : les alertes envoyées par le GIE Sesam-Vitale en cas d'indisponibilité, et les erreurs retournées lors des transactions (qui peuvent indiquer que le DMP est fermé, indisponible, ou que le patient n'a pas de DMP). L'objectif pour les logiciels est d'afficher un message d'alerte clair au professionnel de santé lorsque l'une de ces situations est détectée.
Par ailleurs, l'absence d'API publique pour interroger la météo de service a été signalée comme une limite, et l'ANS en a pris note. 

Oui, cette implémentation est conforme à l'esprit de l'exigence DMP.UX.10. L'objectif fondamental est d'éviter que le logiciel soit entièrement bloqué pendant une transaction DMP, ce qui obligerait le médecin à attendre sans pouvoir continuer à travailler. 
Deux approches sont acceptables : l'implémentation en mode multithread (la transaction se déroule en arrière-plan pendant que l'utilisateur continue à utiliser le logiciel), ou, si cela est complexe à réaliser, la possibilité d'interrompre volontairement la transaction via un bouton ou une croix de fermeture et de passer à autre chose. Dans les deux cas, l'exigence est satisfaite. 

Les feuilles de style tendent à être abandonnées pour des raisons de sécurité (risques d'injection, cross site scripting, déni de service). L'exigence SC.CDA.VISU.01 prévoit que le système peut utiliser sa propre feuille de style par défaut. Cependant, elle précise également que lorsque la feuille de style par défaut n'est pas celle du producteur, le système doit permettre d'afficher le document avec la feuille de style du producteur si l'utilisateur le demande.
En pratique : si votre propre feuille de style permet d'afficher correctement l'ensemble des contenus, y compris les parties narratives (CDA niveau 1 et 2), vous êtes conformes. Il n'est pas obligatoire d'appliquer la feuille de style du producteur par défaut, mais il faut être capable de la proposer en option. L'exigence dans le scénario est de pouvoir afficher la partie narrative en appliquant soit la feuille de style du producteur, soit celle du consommateur.
Si la feuille de style reçue présente un risque de sécurité, il est tout à fait justifié de ne pas l'appliquer et d'utiliser uniquement la vôtre. 

L'exigence SC.INS.14 n'a pas spécifié le type de recherche (préfixe ou infixe). Les éditeurs sont donc libres de choisir leur implémentation. D'un point de vue métier, la recherche depuis le début de la chaîne (recherche préfixe) paraît la plus logique et la plus conforme aux usages. Le référentiel impose en revanche des champs séparés pour le nom de naissance et le prénom, mais ne contraint pas la logique de correspondance de la chaîne de recherche.

Sur Gazelle, il existe un outil appelé « Test Contenu CDA » qui permet de valider la qualité des fichiers CDA produits ou reçus, en s'appuyant sur des schématrons et des feuilles de style. Cet outil a notamment été utilisé pour les comptes rendus de biologie.
Concernant la mise à jour des outils par rapport aux évolutions des spécifications : les équipes en charge des outils d'interopérabilité actualisent les jeux de tests au fur et à mesure des nouvelles versions publiées. 
Annexe – testContenuCDA | Agence du Numérique en Santé 

Le DMP prévoit plusieurs niveaux de gestion de la visibilité des documents, qui doivent être bien distingués :
1. Masquage aux représentants légaux : c'est le cas visé dans la question (enfants à l'ASE, adolescents dont on souhaite protéger la confidentialité vis-à-vis des parents pour des soins en santé sexuelle, en addictologie ou en santé mentale). Ce type de masquage n'est pas concerné par le mécanisme de remise en visibilité automatique. Les médecins peuvent rassurer leurs patients : le masquage aux représentants légaux reste permanent sauf action volontaire du professionnel.
2. Invisibilité au patient lui-même : c'est dans ce cas uniquement que le mécanisme de remise en visibilité automatique (la « voiture balai ») s'applique. Il concerne typiquement les situations d'annonce de maladies graves (cancer, maladie neurologique grave, etc.), où le professionnel envoie le document en mode invisible au patient pour permettre une annonce médicalement accompagnée. Dans ce cas : une notification est envoyée au patient à 1 mois pour l'informer de l'existence d'un document invisible dans son dossier ; à 3 mois, si aucun professionnel n'a remis le document en visibilité, une remise en visibilité automatique intervient.
3. Masquage aux professionnels de santé : cette fonctionnalité, à l'initiative du patient lui-même, n'a pas vocation à être fortement mise en avant dans les logiciels métiers.
Pour les situations ASE, le mécanisme automatique à 3 mois ne s'applique donc pas. 

Le prescripteur peut conditionner la délivrance de certains médicaments à la réalisation et au résultat de tests à caractère médical, notamment d'examens biologiques ou d'orientation diagnostique, au moyen d'une ordonnance dite de dispensation conditionnelle (cf. [RG_EP107], cas particulier de la prescription avec dispensation conditionnelle).
Concrètement, le prescripteur doit pouvoir :
- sélectionner la dispensation conditionnelle (angine ou cystite),
- saisir une ligne produit de santé/DM en texte libre pour le TROD ou le test urinaire à réaliser par le pharmacien,
- saisir une ligne produit de santé/Médicament pour l’antibiotique,
- indiquer dans le champ « posologie » de niveau ligne en première position la condition de dispensation :
Pour l’angine : « si TROD angine positif, sous 7 jours calendaires à compter de ce jour »
Pour la cystite : « si BU positive ».
Le libellé de la condition de dispensation doit être standardisé et le poste doit le générer automatiquement pour faciliter la saisie par le prescripteur.
La posologie usuelle doit être saisie à la suite, et séparée de la condition de dispensation par un retour chariot (matérialisé par « \r »).

Non. Ces exigences sont bien distinctes de la base de données médicamenteuses et de la partie LAP. Elles portent sur les référentiels sémantiques pour la codification des pathologies et des actes, c'est-à-dire les jeux de valeurs mis à disposition sur le Serveur Multi-Terminologie (SMT) de l'ANS. Il s'agit notamment des nomenclatures CIM-10, CISP-2 et Dictionnaire des Résultats de Consultation, ainsi que des jeux de valeurs pour la biologie.
Ces référentiels doivent être intégrés directement dans le logiciel de gestion de cabinet (LGC), avec différentes modalités d'implémentation possibles : certains éditeurs les intègrent individuellement, jeux de valeurs par jeux de valeurs, d'autres proposent une recherche transversale sur les codes pathologiques (notamment pour CIM-10/CISP-2/DRC, qui peuvent faire l'objet d'une interrogation croisée). L'interrogation via le SMT de l'ANS est également possible.
Les trois exigences ERG.VA1.01, ERG.VA1.02 et ERG.VA1.03 vont ensemble et couvrent ces trois référentiels de pathologies. La biologie dispose quant à elle d'exigences dédiées et distinctes.

Le cas typique est celui où la carte CPS se trouve chez la secrétaire. Le médecin envoie un document depuis son poste, mais l'envoi ne part pas faute de carte CPS. Le document est alors mis en liste d'attente et c'est depuis le poste de la secrétaire, lorsque celle-ci est connectée avec une carte permettant l'envoi au DMP, que le document est effectivement transmis.
La production du document et sa validation restent de la responsabilité du prescripteur.
Sur la question de l'auteur du document dans les métadonnées : même si le document part via une carte CPE anonyme, le champ « auteur » doit rester renseigné avec l'identité du médecin qui a validé le document dans le logiciel. Les spécifications techniques de la transaction (TD 2.2 du GI DMP 2.10) précisent les attributs associés à l'auteur et au porteur de la carte ; certains de ces attributs peuvent être absents lorsque la carte utilisée est anonyme, mais l'auteur fonctionnel du document doit toujours être tracé.