Qu’est-ce qu’un patient ?

Définition

Pour le commun des mortels, un patient « est » une personne. Depuis le tout début du XXIème siècle, pour la communauté des experts en informatique de santé, les deux notions de patient et de personne s’articulent de façon différente. Voici quelques explications.

« Patient » est le rôle qu’une personne joue dans le cadre de sa participation à un acte médical (une consultation par exemple). « Médecin » est un autre rôle que peut jouer une autre personne dans le cadre de sa participation au même acte. Il arrive au médecin (à la personne qui joue habituellement le rôle de médecin) d’être malade, et de jouer à son tour le rôle de patient.

Cette notion de rôle est omniprésente en informatique de santé. Un médicament n’est pas un produit pharmaceutique. « Médicament » est le rôle qu’un produit pharmaceutique joue dans le cadre d’un acte (une prescription par exemple). Il arrive au produit pharmaceutique de jouer un autre rôle dans le cadre d’un autre acte : « poison », « allergène », etc. Cela n’a rien de spécifique à l’informatique de santé : dans le monde de l’assurance, une même personne peut être tantôt dans le rôle de l’assuré dans le cadre d’un contrat, tantôt dans le rôle de conducteur dans le cadre d’un sinistre.

Comment sont identifiés les patients ?

Dans un hôpital, un patient est identifié par… un identifiant, qu’on appelle habituellement l’IPP, pour Identifiant Permanent du Patient. Tout va bien tant que :
• On n’a pas attribué au même patient un nouvel identifiant à l’occasion d’un nouveau séjour (cela arrive trop souvent pour les femmes mariées précédemment connues sous leur nom de jeune fille) – c’est le sempiternel problème des doublons.
• On ne cherche pas à partager des informations cliniques avec d’autres hôpitaux (où le patient n’est pas identifié de la même façon) – c’est le problème de plus en plus fréquemment rencontré de l’identification inter-établissements.

Pour gérer ces problèmes, il faut considérer que le rôle de patient est toujours joué par une personne, et rattacher à une même personne tous les identifiants de patient qui la concernent dans les différents établissements qui la connaissent.

Quand on cherche un dossier patient, c’est toujours via une requête simple, qui utilise l’IPP. Et si on n’a pas l’IPP ? – Alors ce qu’on cherche, ce n’est pas exactement un patient, c’est une personne. A l’intérieur d’un hôpital, cela revient pratiquement au même. Quand on a trouvé la personne on a trouvé son IPP et on accède à son dossier.

Dans un contexte multi-établissements, autrement dit du point de vue de l’avenir, quand on a trouvé la personne on a trouvé ses IPP dans chaque établissement, et de là on peut éventuellement accéder à ses données de santé qui sont réparties entre différents dossiers patient.

La classe Patient

Voici un extrait du RIM (Reference Information Model) :

La classe Patient

La classe Patient hérite de la classe abstraite Role.

Le rôle de patient est joué (played) par une entité qui est une personne, et « scopé » (scoped, supervisé) par une autre entité qui est une organisation (typiquement l’hôpital), au titre de sa participation à un acte (typiquement un séjour). On affecte l’IPP à l’attribut Patient.id.

On peut affecter à Patient.name le nom du patient tel qu’il est/était connu de cet hôpital à l’occasion de tel(s) ou tel(s) séjour(s). A ne pas confondre avec Person.name, qui a vocation à représenter le « vrai » nom de la personne, en principe strictement conforme à l’état civil.

Le sexe et la date de naissance doivent être portés par la classe Person, parce qu’en principe ils ne peuvent pas différer d’un hôpital à l’autre.

Voici un extrait du R-MIM (Refined Message Information Model) « Patient Activate/Revise », utilisé par IHE PIXv3 :

rmim-patient

Dans cette spécialisation du RIM, le patient n’a pas de nom, ce qui peut s’interpréter de deux façons complémentaires :
• En principe, et à sa connaissance, l’hôpital utilise le « vrai » nom de la personne, et tout écart avec l’état civil doit être considéré comme accidentel.
• La personne, telle qu’elle figure dans ce message émis par un hôpital précis à un moment précis, porte le nom tel qu’il était connu de cet hôpital à ce moment.

Il faut bien comprendre que ce modèle est un modèle de message, pas un modèle de système d’information. Le système qui reçoit un message doit tenir compte du fait que dans tout message certaines informations peuvent être plus ou moins cohérentes avec d’autres informations concernant la même personne physique, et trouvées dans d’autres message.

Dans un système qui implémente l’acteur IHE PIX Manager, si son modèle de données s’inspire du RIM, alors on doit affecter le nom qui figure dans le message (Person.name) à une instance de la classe Patient spécifique à cet hôpital (Patient.name). On doit aussi veiller à n’affecter à l’attribut « name » de l’instance unique de la classe Person, que des valeurs ayant fait l’objet d’un traitement spécifique en vue de se conformer, autant que faire se peut, à l’état civil.

L’hôpital pourrait être considéré comme implicitement identifié au travers de son serveur d’identité, dont l’OID (Object Identifier) est porté par Patient.id.root, mais ce modèle rend obligatoire le lien « providerOrganization » (qui renomme « scoper ») et une instance de la classe Organization.

La ressource Patient

La ressource Patient

On affecte l’IPP à Patient.identifier, le nom à Patient.name, le sexe à Patient.gender et la date de naissance à Patient.birthDate.

Il n’y a pas de lien apparent avec une personne, parce que c’est à la ressource Person de porter des liens vers des ressources Patient. Je trouve cette construction admirable, et je vais essayer d’expliquer pourquoi.

Il faut bien comprendre que la ressource Patient ne prétend aucunement représenter une personne physique, mais seulement un artefact informatique : la façon dont une personne est identifiée dans une organisation, ou plus précisément dans un système d’information. Dans le cas le plus simple d’une organisation unique avec un seul système d’information, on aura au moins une ressource patient par personne physique connue de l’établissement, et dans la pratique on en aura relativement souvent deux (voire trois ou plus), parce que rien ni personne n’a jamais pu empêcher la création de doublons. En un sens, les ressources Patient qui portent des « erreurs » (une confusion entre le nom de naissance et le nom marital, un prénom mal orthographié, etc.) ne sont pas « fausses » : elles reflètent fidèlement ce qu’on trouve dans le système d’information de l’établissement.

Pour « gérer les doublons » on pourra utilement utiliser la ressource Person qui rendra disponible par exemple l’information suivante : « le patient actuellement hospitalisé avec tels traits d’identification, nous avons réalisé qu’en fait c’est la même personne physique que tel patient hospitalisé précédemment avec des traits d’identification légèrement différents ». Cela peut suffire pour permettre aux applications de récupérer des informations cliniques essentielles (antécédents médicaux, allergies, etc.), sans passer par une opération complexe et relativement risquée de « fusion » des dossiers médicaux.

L’hôpital peut être considéré comme implicitement identifié via Patient.identifier.system, et si on a besoin de plus d’informations (comme le nom de l’hôpital), on affecte à Patient.managingOrganization une référence à une ressource Organization. Cette référence fonctionne pratiquement comme le lien « scoper » dans le RIM (« providerOrganization » dans le modèle d’IHE PIXv3).