Improve text-search without using extension of DocumentReference

[MiskoG]

Contexte

La recherche textuelle dans Cohort a été implémentée d'une façon particulière sur notre environnement démo, qui n'est pas reproductible dans un environnement réel à l'hôpital.

À Toulouse, le contenu texte des documents est stocké dans une ressource FHIR.
L'objectif de cette issue est d'adapter Cohort pour être capable de faire une recherche textuelle dans les documents, via ce champ FHIR.

À ma connaissance on trouve cette recherche à 2 endroits dans Cohort

(1) Dans le mode "création de cohorte" via le critère "documents cliniques"
(2) Dans la home via la barre de recherche (recherche sans création de cohorte)

PS : se pose aussi la question de l'aperçu des documents cliniques, peut-être à gérer dans un 2ème temps dans une autre issue.

[MiskoG]

@elsiehoffet-94 Tu peux nous préciser dans quelle ressource FHIR et quel attribut est stocké le texte des documents ?
Merci d'avance 🙂

[elsiehoffet-94]

Il y a deux manières de faire (on n'a pas encore convergé là dessus) :
@nriss pour l'extension de DocumentReference
@Peltier10 pour la ressource Composition

[MiskoG]

Top on attend vos précisions 👍 Idéalement je dirais que Cohort ne devrait lire cette info qu'à un seul endroit (qui sera précisé dans l'Implementation Guide de Cohort). What do you think ?

[elsiehoffet-94]

Je pense que ça dépend de comment on gère les documents dans les centres, qui peut varier, au moins au début :

• soit on reconstitue les CR en FHIR et on les stock dans la DB -> Composition
• soit on fait référence au texte qui est dans des documents auxquels on fait référence, et qui sont stockés/gérés par une autre instance -> DocumentReference

Mais la discussion est ouverte :)

[nriss]

Quand on regarde la doc fhir sur les documents, il est précisé que : Note that FHIR defines both this document format and a document reference resource. FHIR documents are for documents that are authored and assembled in FHIR, while the document reference resource is for general references to pre-existing documents.

Dans ma compréhension, la ressource Composition est un peu la nouvelle version du CDA : tu prends un bundle de ressources FHIR définies à l'avance, et tu génères à partir de celles ci une Composition (en gros, à partir d'éléments référencés dans ces ressources FHIR, un document textuel sera généré avec les résultats attendus).

A Composition is the basic structure from which FHIR Documents - immutable bundles with attested narrative - are built. A single logical composition may be associated with a series of derived documents, each of which is a frozen copy of the composition.

Dans le cas d'un document préexistant (qu'il s'agisse d'un pdf, d'un compte rendu orbis ou d'un fichier word...), la ressource adaptée selon moi est DocumentReference, qui permet de décrire un document généré ailleurs:

A reference to a document of any kind for any purpose. Provides metadata about the document so that the document can be discovered and managed. The scope of a document is any seralized object with a mime-type, so includes formal patient centric documents (CDA), cliical notes, scanned paper, and non-patient specific documents like policy text.

ou encore

FHIR defines both a document format and this document reference. FHIR documents are for documents that are authored and assembled in FHIR. This resource is mainly intended for general references to assembled documents.

Le pipe à faire selon moi est:

• Si on arrive à fetch le pdf grâce à nos services, on l'affiche dans cohort360.
• Si on y arrive pas ou si l'attribut reference n'est pas défini, on affiche le contenu textuel du document présent dans l'extension

[elsiehoffet-94]

Merci pour ces clarifications !
Désolée mais quelques choses me chiffonnent encore:

1. Pourquoi est-ce qu'on est obligés de stocker le texte du compte rendu dans une extension? Ca m'étonne vachement que ça soit pas anticipé dans le modèle FHIR. J'ai pas encore creusé Zulip sur ce sujet, ça pourrait être une bonne source de connaissance
2. En quoi les CR orbis qu'on reconstitue diffèrent d'un CDA ? Ils ont toute la métadonnée nécessaire il me semble.
3. L'utilisation d'un DocRef ici me perturbe parce qu'on ne fait référence à aucun document extérieur dans ces ressources créées

[nriss]

1. Je suis d'accord avec toi, c'est assez étonnant, il y a Attachment.data qui permet de stocker le document mais c'est du base64Binary et non un string comme on l'aurait souhaité
2. Je suis d'accord, et selon la doc fhir les CDA (hl7 v3) doivent se stocker dans des ressources DocumentReference:
   NOTE: While FHIR can be used to create documents using the Composition Resource, FHIR can also be used to exchange traditional CDA R2 documents making use of the DocumentReference resource, and handling the CDA document itself as a binary attachment (as XDS does). http://hl7.org/fhir/comparison-cda.html
3. Je vois ça comme une référence vers le document présent dans orbis pour ma part

[elsiehoffet-94]

Je suis d'accord avec toi, c'est assez étonnant, il y a Attachment.data qui permet de stocker le document mais c'est du base64Binary et non un string comme on l'aurait souhaité

En discutant avec @Jasopaum, base64Binary c'est l'encodage source à partir duquel on peut décoder en utf-8, ascii, et n'importe quel format de strings. Ca me semble donc pas incohérent de stocker des gros blocs de texte dans un autre format que des strings, je pense pas que ça devrait être un contre-argument. C'est ensuite aux réutilisateurs de données de la transformer dans le format voulu.

Je suis d'accord, et selon la doc fhir les CDA (hl7 v3) doivent se stocker dans des ressources DocumentReference: [...]
handling the CDA document itself as a binary attachment (as XDS does)

Merci pour cette précision! On peut mettre le contenu du CR dans DocumentReference.attachement.data alors (aussi de type base64Binary), t'en penses quoi?

[nriss]

On a totalement convergé 👌

[elsiehoffet-94]

Ok! @MiskoG on part sur un stockage du contenu des CRs dans DocumentReference.attachement.data alors. J'ai fait une issue sur river, on peut avancer sur cohort en parallèle :)

[MiskoG]

Ok top, merci pour le résumé et les précisions 🙂

But de cette issue

Adapter dans Cohort360 la recherche textuelle dans les documents.
Pour cela, il faudra désormais chercher dans la ressource FHIR DocumentReference, au niveau de attachement.data.
À voir si HAPI propose une recherche déjà native sur cet attribut ?

[MiskoG]

Feature côté River pour alimenter DocumentReference.attachment.data
arkhn/fhir-river#422

[nriss]

A priori, pas de SearchParam qui permet de chercher dans attachment.data en FHIR, il y a par contre le paramètre _content qui permet de chercher dans l'ensemble de la ressource

Ca serait intéressant d'investiguer les Operations et voir si on peut créer des opérations custom avec HAPI pour ce genre de cas d'usage avec un besoin de logique

[simonvadee]

Merci pour la description détaillée du problème, voici l'issue associée sur jpaltime: arkhn/jpaltime#20