Date début manquante

[iherveOCSIN]

• Pour le Fucidin :
o Je n’ai pas de date de début, mais c’est une donnée obligatoire dans Swiss-Meds. Est-ce qu’il y a une interprétation à faire lorsqu’aucune limite de durée n’est indiquée ? Faut-il prendre la dateAsserted comme début peut-être ?
L’agrégateur fait la considération suivante :

Mais ça fait référence aux entrées originales envoyées par les systèmes. On ne peut pas utiliser le dateAsserted des entrées du PMLC car dans ce cas là c’est la date de la décision de la dernière modification (p.ex. d’un PADV CHANGE) (voir http://build.fhir.org/ig/hl7ch/ch-emed/authorship.html). Pour l’instant on ne peut pax extraire la date de début d’un medication statement du PMLC si elle n’est pas spécifiée dans les entrées originales. On peut discuter si on veut que l’agrégateur ajoute toujours la date consolidée de début du traitement aux entrées du PMLC.
o Il y a une instruction à prendre sur 7 jours, mais je suppose que l’app n’est pas censée extraire cette info d’un texte libre pour calculer une date de fin.
 S’il n’y a pas de date de fin renseigné, Swiss-Meds considère que le traitement est à prendre sur une durée indéterminée et continuera de l’afficher tant que le traitement est présent et actif.
La date de fin peut et devrait être ajouté de manière structurée. Aucune extraction d’information du texte livre est attendue. L’agrégateur va aussi considérer le traitement comme actif. En plus, si le traitement ne fût pas considéré comme actif, il ne serait pas ajouté au PMLC par défaut.

[iherveOCSIN]

[iherveOCSIN]

hello @laberg j'ai retenu ce bug suite aux derniers tests. D'après un échange que j'ai eu avec Daniel, c'est une correction à faire côté Swiss-Meds, est-ce que tu confirmes ?

[iherveOCSIN]

@laberg n'hésite pas à reformuler le titre et la description

[laberg]

Hello @iherveOCSIN oui c'est juste, merci pour la création du ticket.
Il faut qu'on définisse comment gérer ce bug de notre côté. Peut-être faudra-il toujours aller chercher l'entrée originale pour récupérer la date de début "initiale" du traitement.

[laberg]

Hello @dvribeira
Après discussion en interne, on a convenu que c'est la date de planning initiale qu'on aimerait récupérer comme date de début de traitement, même après récupération d'updates du traitement.
Si j'avais bien compris, la planning date (dateAsserted) est toujours présente oui ? Est-ce donc envisageable d'avoir la valeur initiale même sur les màj suivantes ? Ou bien faudra-t-il récupérer avec une transaction l'entrée initiale du traitement ?
Redis-moi si c'est pas clair ;)

[dvribeira]

@laberg dateAsserted n'est pas la date de début du traitement, mais la date de la décision médicale. La date de début du traitement est fournie avec le dosage base dans le champ boundsPeriod. Un médecin (ou quelqu'un d'autre) peut décider de créer un traitement le 30.06.2024 (dateAsserted), être enregistré dans le système par l'assistant(e) le 01.07.2024 (Bundle.timestamp | Composition.date), et avec une posologie à prendre entre le 15.07.2024 et le 15.08.2024 (boundsPeriod).

Le PMLC ne retourne (forcement) les données d'un MTP, car ne il retourne pas les traitements actifs (c'est un abus de langage quand on dit ça du PMLC) mais les lignes de traitement actives. Normalement, un traitement n'a qu'une ligne de traitement active, mais ça peut arriver qu'il y en a plusieurs pour les traitements avec plus d'une prescription (ordonnance). Avec cette idée clarifiée, c'est plus évident que le PMLC ne retourne (forcement) la période de traitement des traitements, mais des lignes de traitement actives (détail important pour les traitements prescrits).

Pour récupérer le boundsPeriod du MTP original il faut récupérer le document original et pas les données agrégées comme fournies par le PMLC.

Pourquoi est-ce que vous trouvez plus utile de récupérer la période de traitement envoyée avec le MTP original et pas la période de traitement à jour?

[laberg]

@dvribeira merci pour ces précisions. Je comprends mieux la distinction entre dateAsserted et le boundsPeriod. Mais du coup le boundsPeriod est toujours fourni dans le MTP original ?

Quand tu parles de lignes, ça peut être, par exemple, un changement de dosage qui créerait une nouvelle ligne ?

Le PML retourne l'ensemble des lignes pour chaque traitement c'est juste ? Du coup c'est peut-être plutôt ce document qu'il nous faudrait pour récupérer les boundsPeriod originaux. Dans Swiss-Meds, nous considérons que le traitement continue, même si la posologie change, on parle toujours du même médicament. Ce n'est pas un choix ferme de mémoire, mais actuellement, on ne donne pas à l'utilisateur beaucoup d'informations sur l'historique des changements de son traitement, si ce n'est pour ses prises, du coup on préfère que la date initiale de début soit toujours visible.

Après, quand on aura implémenté la navigation dans l'historique des changements, on aura de toutes façons accès à toutes les lignes et on pourra afficher l'information comme on le souhaite dans Swiss-Meds.

[dvribeira]

@laberg Je vais séparer un peu les différentes questions entremêlées:

• Lignes de traitements: les lignes de traitement sont créées:

  • Implicitement par le MTP: la publication du MTP original crée la ligne de traitement base.
  • Avec chaque nouvelle medication request (ordonnance) dans un PRE. La première ordonnance d'un traitement crée une ligne de traitement qui remplace la ligne base du MTP. Chaque ordonnance en plus ajoute une nouvelle ligne de traitement.
    Un PADV ne crée pas de nouvelles lignes de traitement -> un changement de posologie publié par voie d'un PADV CHANGE ne crée pas une nouvelle ligne de traitement, mais modifie une (si le cible est une ordonnance) ou toutes les lignes de traitement (si le cible est un traitement/MTP).

• Qu'est-ce que le PMLC retourne?

  • Le PMLC retourne les lignes de traitement actives (sauf si le flag pour retourner aussi les non-actives est fournie avec la requête) pour les dates spécifiées comme paramètres (si fournies, voire Other aggregator changes: dans la service guide) de manière agrégée:
    • Le PMLC contient que des entrées de type medication statement, une entrée par ligne de traitement, avec les données agrégées (avec tous les changements appliqués).

• Qu'est-ce que le PML retourne?

  • Le PML retourne toutes les entrées comme fournies dans les documents envoyées au PMP: les données ne sont pas agrégées.
  • Ça veut dire que si pour un traitement le PMP a reçu un MTP, un PADV CHANGE et un PRE ciblant le traitement, le PML retournera le medication statement original du MTP, l'observation du PADV, le medication statement (changed) du PADV et le medication request du PRE. En revanche, un PMLC aurait retourné qu'un medication statement.

• Est-ce que boundsPeriod est toujours présent dans le medication statement d'un MTP?

  • Pour l'instant, ce champ et ses sou-champs sont optionnels dans CH EMED EPR. Si le champ ou un de ses sou-champs n'est pas présent, l'agrégateur fait les assomptions suivantes:
    • Si boundsPeriod.start n'est pas fourni, l'agrégateur juge la date de publication du document comme date initiale du traitement.
    • Si boundsPeriod.end n'est pas fourni, l'agrégateur juge que le traitement est pérenne.

• Est-ce que boundsPeriod est toujours présent dans les medication statement du PML?

  • Les entrées du PML sont retournées comme fournies avec le document original, si le boundsPeriod ou le champ boundsPeriod.start n'étaient fournies avec l'entrée originale, il ne seront présents non plus dans le PML.

• Est-ce que le boundsPeriod est toujours présent dans les medication statement du PMLC?

  • Les entrées du PMLC contiennent des données agrégées, ça veut dire que le medication statement contenu dans le PMLC contient les mises à jour de la ligne de traitement. En effet, si la dernière posologie fournie dans la chaîne de la ligne de traitement ne contenait pas boundsPeriod (même chose pour un sous-champ), le PMLC ne le contiendra non plus.

• Est-ce qu'on peut extraire la date initiale du traitement dans le PMLC de manière fiable:

  • Non, on ne peut pas. Le PMLC ne garantie, pour l'instant, l'inclusion du boundsPeriod.start.
  • Alors, qu'est-ce qu'on peut faire?
    1. La première option, toujours possible, est que le système client récupère le MTP original pour chaque ligne de traitement qui ne contient pas de boundsPeriod.start et utilise la date de publication fournie par le document MTP. Cette option est déjà possible et n'exige pas d'effort du côté de l'agrégateur ni des autres systèmes.
    2. Exiger l'ajout du boundsPeriod.start pour toutes les posologies base:
       • On aurait toujours le boundsPeriod.start dans les résultats du PMLC et du PML.
       • Pas d'effort côté agrégateur.
       • Les systèmes devront changer leurs implémentations pour toujours ajouter le boundsPeriod.start avec les publications.
       • Ajouter des contraintes au format constitue un obstacle à l'interopérabilité. On devrait les éviter si possible.
    3. Exiger que l'agrégateur complète le champ boundsPeriod.start dans les entrées du PMLC (données agrégées).
       • On aurait toujours le 'boundsPeroid.start` dans les résultats du PMLC (mais pas du PML).
       • Pas d'effort côté systèmes client.
       • Une contrainte n'est pas ajouté aux entrées originaux mais elle est implicite si les systèmes l'exigent des entrées du PMLC. Ça sera un problème pour l'interopérabilité avec des autres systèmes basés CH EMED.

Si vous voulez explorer les solutions b ou c, on devra le discuter ensemble avec tous les systèmes car ça affecte tout le monde.