La ressource Patient FHIR expliquée : identifiants, noms, données démographiques et liens, avec un exemple valide

Réponse courte : Patient est la ressource FHIR qui décrit une personne recevant des soins : qui elle est administrativement, pas ce qui ne va pas chez elle. Elle contient des identifiants (numéros de dossier médical, identifiants nationaux), des noms, des contacts télécom, le genre administratif, la date de naissance, l'adresse, le statut marital, la communication (langues), un praticien généraliste, une organisation gestionnaire et des liens vers d'autres enregistrements Patient pour la même personne. Chaque Observation, Condition, Encounter ou MedicationStatement y fait référence via subject ou patient. Les faits cliniques ne résident jamais dans Patient ; ils résident dans les ressources qui y pointent.

Un exemple FHIR R4 valide

Une ressource Patient FHIR R4 valide ne nécessite que resourceType, mais en pratique, elle contient au moins un identifiant avec un système et une valeur, un nom avec les parties nom de famille et prénom, un genre administratif et une date de naissance. L'exemple ci-dessous revendique également le profil Patient IPS dans meta.profile et ajoute les coordonnées, l'adresse, la langue préférée, le médecin traitant et l'organisation gestionnaire.

{
  "resourceType": "Patient",
  "id": "example",
  "meta": {"profile": ["http://hl7.org/fhir/uv/ips/StructureDefinition/Patient-uv-ips"]},
  "identifier": [{
    "use": "usual",
    "type": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v2-0203", "code": "MR"}]},
    "system": "https://hospital.example.org/mrn",
    "value": "MRN-00012345"
  }],
  "active": true,
  "name": [{"use": "official", "family": "Doe", "given": ["Jane", "Marie"], "prefix": ["Ms"]}],
  "telecom": [{"system": "email", "value": "[email protected]", "use": "home"}],
  "gender": "female",
  "birthDate": "1980-05-23",
  "address": [{"use": "home", "line": ["12 High Street"], "city": "Leeds", "postalCode": "LS1 4AB", "country": "GB"}],
  "communication": [{"language": {"coding": [{"system": "urn:ietf:bcp:47", "code": "en-GB"}]}, "preferred": true}],
  "generalPractitioner": [{"reference": "Practitioner/gp-42"}],
  "managingOrganization": {"reference": "Organization/hospital"}
}

Les éléments importants

Les éléments Patient les plus importants pour l'interopérabilité sont l'identifiant (identifier avec système, valeur et type), le nom (name avec usage, nom de famille et prénom), le genre administratif (administrativeGender), la date de naissance (birthDate), le statut de décès (deceased), le statut actif (active), les contacts (contact) et le lien (link). Les identifiants et les noms permettent la correspondance entre les systèmes, le genre et la date de naissance sont des faits administratifs, et le lien (link) enregistre comment un index maître des patients a connecté des enregistrements dupliqués d'une personne.

• identifier est une liste, chacune avec un system (qui l'a émis) et une value. Le type indique de quoi il s'agit : MR numéro de dossier médical, NI identifiant national, PPN passeport, SS numéro de sécurité sociale, issu de la table HL7 0203. Un patient en a généralement plusieurs ; le numéro de dossier d'un hôpital et un identifiant national sont tous deux valides, et les systèmes les font correspondre.
• name est également une liste avec un use : official, usual, nickname, maiden, old. family est une chaîne de caractères ; given est une liste. Les scripts, translittérations et l'ordre des noms sont laissés à l'implémentation du guide du pays.
• gender est le genre administratif avec quatre valeurs : male, female, other, unknown. C'est ce que dit le dossier, utilisé pour la correspondance et les formulaires. Le sexe clinique, l'identité de genre et les pronoms vont dans des extensions ou des Observations, que FHIR R5 et le projet Gender Harmony ont formalisés.
• birthDate est une date, éventuellement seulement l'année ou l'année et le mois lorsque la date exacte est inconnue. Une extension patient-birthTime ajoute l'heure pour les nouveau-nés.
• deceased[x] est un booléen ou une date-heure. active false marque un enregistrement qui ne doit plus être utilisé (doublon, déplacé), sans le supprimer.
• contact liste les personnes à contacter (proche, tuteur), avec un code de relation ; ce ne sont pas des ressources Patient elles-mêmes. Un parent qui est aussi un patient est un RelatedPerson pointant vers les deux.
• link connecte les enregistrements Patient qui sont la même personne : replaced-by et replaces après une fusion, refer vers l'enregistrement faisant autorité, seealso pour un enregistrement dans un autre système. C'est ainsi qu'un index maître de patients exprime ses décisions en FHIR ; voir Correspondance des patients.

Ce que les profils nationaux ajoutent

Les profils FHIR nationaux et internationaux transforment la ressource Patient de base, peu définie, en quelque chose d'utilisable en rendant certains éléments obligatoires et en ajoutant des extensions spécifiques au pays. US Core exige l'identifiant, le nom et le genre et ajoute des extensions pour la race, l'ethnicité et le sexe à la naissance ; le profil Patient IPS exige le nom, le genre et la date de naissance ; les profils nationaux définissent les systèmes d'identifiants et les formats d'adresse.

La ressource de base rend presque tout facultatif. Les profils le rendent utilisable :

Un enregistrement qui doit traverser une frontière doit satisfaire le profil de chaque côté, ce qui en pratique signifie porter à la fois l'identifiant national et un MRN, un nom officiel complet et une date de naissance complète. Voir Guides d'implémentation FHIR.

Opérations que vous utiliserez

Les opérations FHIR les plus utilisées avec Patient sont la recherche par identifiant ou par données démographiques (GET /Patient avec les paramètres identifier, family ou birthdate), l'opération $everything qui renvoie le patient et toutes les ressources qui le référencent, et $match qui interroge l'algorithme de correspondance du serveur pour les doublons probables. Une opération $merge est en cours de standardisation dans FHIR R5.

• GET /Patient?identifier=https://hospital.example.org/mrn|MRN-00012345 trouve un patient par identifiant ; ?family=doe&birthdate=1980-05-23 par données démographiques.
• GET /Patient/{id}/$everything renvoie le patient et toutes les ressources qui y font référence, paginées, c'est ainsi qu'un dossier complet est exporté.
• $match (là où il est pris en charge) demande à l'algorithme de correspondance du serveur les doublons probables ; $merge est en cours de standardisation en R5.

Erreurs qui cassent les dossiers patients

Les erreurs qui corrompent le plus souvent les dossiers Patient FHIR sont le stockage d'un identifiant national dans l'ID de la ressource au lieu de l'élément identifier, l'omission du identifier.system qui entraîne des collisions de valeurs provenant de différents hôpitaux, l'inscription du nom entier dans text sans les parties nom de famille et prénom, l'utilisation du genre administratif pour le sexe clinique, et la modification d'un enregistrement fusionné sur place au lieu de le lier et de le désactiver.

• Mettre l'identifiant national dans id. L'id de la ressource appartient au serveur et peut changer lors de l'importation ; les identifiants appartiennent à identifier.
• Un seul name avec tout dans text et sans family/given, donc les recherches par nom de famille échouent.
• gender utilisé pour le sexe clinique, ou défini sur unknown parce que le formulaire n'avait pas de champ.
• identifier.system manquant, de sorte que les valeurs MRN-1 de deux hôpitaux entrent en collision.
• Modifier un Patient sur place lorsqu'une fusion a eu lieu, au lieu de le lier et de le désactiver.

Dans Anpheros

Anpheros représente chaque personne, le titulaire du compte et chaque profil familial, comme une ressource Patient FHIR sur la plateforme Anpheros, et chaque enregistrement qu'une clinique ajoute via l'API référence ce Patient. Les identifiants de clinique sont conservés comme identifiants supplémentaires avec le propre système de la clinique, et les données démographiques qu'une personne saisit restent des données administratives à partir desquelles rien de clinique n'est déduit.

Lorsqu'une clinique envoie son propre identifiant, il est stocké comme un identifier supplémentaire avec le système de la clinique, de sorte que la même personne puisse être retrouvée de part et d'autre. Les données démographiques que la personne a saisies dans l'application constituent le nom usual et des données administratives ; le dossier n'en déduit jamais rien de clinique.

Pages connexes

• Correspondance des patients et l'index maître des patients
• Guides d'implémentation FHIR
• FHIR Encounter expliqué
• FHIR Condition expliqué
• Recherche FHIR expliquée
• Exemple de Patient sur le site développeur

Sources

• HL7 FHIR R4 : Patient
• HL7 FHIR R4 : Patient $everything
• Terminologie HL7 : codes de type d'identifiant (v2-0203)
• HL7 US Core : Profil Patient
• HL7 IPS : Profil Patient

Questions fréquentes

Est-ce que Patient est la même chose que Person dans FHIR ?

Non. Person est une ressource administrative qui relie le même humain à travers différents rôles (un Patient ici, un Praticien là, un RelatedPerson ailleurs). Les ressources cliniques font référence à Patient, jamais à Person.

Où vont les allergies et les conditions ?

Dans les ressources AllergyIntolerance et Condition qui font référence au Patient. Patient lui-même ne contient que des données administratives.

Comment enregistrer un nouveau-né sans nom ?

Avec un nom dont l'usage est temporary ou vide, une birthDate avec l'extension patient-birthTime, et un link vers le dossier de la mère via RelatedPerson ou l'extension patient-mothersMaidenName, comme spécifié par les profils nationaux.

Une seule ressource Patient peut-elle être partagée par deux hôpitaux ?

Chaque système conserve sa propre ressource Patient avec son propre id ; ils partagent des identifiants (un identifiant national) et peuvent lier les enregistrements. La correspondance entre les systèmes est le travail d'un index maître de patients, pas de la ressource.

Anpheros Platform

Essayez gratuitement dans le sandbox

Votre premier appel FHIR en 5 minutes. Une API HL7 FHIR R4 avec le consentement du patient intégré : essayez-la dans le bac à sable, puis connectez votre propre application ou système de clinique.

Créer un sandbox gratuitLire les guides développeurs →

Gratuit · 30 patients synthétiques · sans carte

Rédigé par

L'équipe Anpheros

Anpheros développe un dossier médical que le patient contrôle et peut partager avec n'importe quelle clinique, sur une plateforme HL7 FHIR R4, basée en UE. Ces guides vous aident à comprendre et organiser votre santé ; ils ne remplacent pas votre médecin.

À propos d'Anpheros →