La ressource FHIR Condition expliquée : statut clinique, statut de vérification, catégories et codes, avec un exemple

Réponse courte : La ressource Condition est utilisée pour un diagnostic, un problème de santé ou un symptôme qui atteint un niveau de préoccupation : ce patient a un diabète de type 2, actif, confirmé, depuis 2019. Ses deux champs de statut la rendent utile. clinicalStatus indique où en est la condition dans son évolution (actif, récidive, rechute, inactif, rémission, résolu) ; verificationStatus indique le degré de certitude (non confirmé, provisoire, différentiel, confirmé, réfuté, erreur de saisie). category distingue les éléments de la liste de problèmes de longue durée des diagnostics de rencontre enregistrés pour une visite. Le code est généralement SNOMED CT, souvent accompagné d'un code ICD-10 pour le reporting.

Un exemple valide de FHIR R4

Une ressource Condition FHIR R4 valide nécessite une référence au sujet et, sauf si elle est marquée comme erronée, un statut clinique ; en pratique, elle inclut également un statut de vérification, une catégorie (élément de liste de problèmes ou diagnostic de rencontre), un diagnostic codé et une date d'apparition. L'exemple ci-dessous enregistre un diabète de type 2 confirmé et actif avec un code SNOMED CT et un code ICD-10 côte à côte.

{
  "resourceType": "Condition",
  "id": "t2dm",
  "clinicalStatus": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/condition-clinical", "code": "active"}]},
  "verificationStatus": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/condition-ver-status", "code": "confirmed"}]},
  "category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/condition-category", "code": "problem-list-item"}]}],
  "severity": {"coding": [{"system": "http://snomed.info/sct", "code": "6736007", "display": "Moderate"}]},
  "code": {
    "coding": [
      {"system": "http://snomed.info/sct", "code": "44054006", "display": "Type 2 diabetes mellitus"},
      {"system": "http://hl7.org/fhir/sid/icd-10", "code": "E11", "display": "Type 2 diabetes mellitus"}
    ],
    "text": "Type 2 diabetes"
  },
  "subject": {"reference": "Patient/example"},
  "onsetDateTime": "2019-03",
  "recordedDate": "2019-03-18",
  "recorder": {"reference": "Practitioner/gp-42"},
  "asserter": {"reference": "Practitioner/gp-42"},
  "note": [{"text": "Diet-controlled at diagnosis; metformin started 2021."}]
}

Les éléments importants

Les éléments de la Condition qui importent le plus sont le statut clinique (où en est la condition dans son évolution), le statut de vérification (à quel point le diagnostic est certain), la catégorie (élément de liste de problèmes ou diagnostic de rencontre), le code (généralement SNOMED CT, souvent avec ICD-10 à côté), l'apparition et la disparition, la date d'enregistrement, ainsi que l'enregistreur et le déclarant, qui indiquent qui a saisi la condition et qui la revendique.

• clinicalStatus est requis chaque fois que la condition n'est pas une erreur de saisie, et ses valeurs suivent l'évolution d'une maladie. resolved est pour les conditions qui se sont terminées (une fracture qui a guéri) ; remission pour celles qui peuvent revenir ; inactive pour un problème qui n'est plus géré. Le modifier permet de maintenir une liste de problèmes fidèle sans supprimer l'historique.
• verificationStatus enregistre la certitude. provisional et differential sont des diagnostics de travail pendant une investigation ; confirmed une fois établi ; refuted lorsqu'il est écarté, ce qui conserve l'enregistrement de ce qui a été envisagé. Une entrée au niveau du symptôme est souvent unconfirmed.
• category : problem-list-item pour la liste permanente qu'un médecin généraliste maintient ; encounter-diagnosis pour ce qui a motivé la visite. La même maladie peut apparaître sous les deux formes, liée à différentes rencontres.
• code est un CodeableConcept, il peut donc porter un concept SNOMED CT pour la signification clinique et un code ICD-10 pour les statistiques côte à côte. Voir CodeableConcept et Coding et SNOMED CT vs ICD-10.
• bodySite, severity et stage (avec des références d'évaluation) qualifient la condition ; evidence pointe vers les Observations ou les rapports qui la soutiennent.
• onset[x] et abatement[x] peuvent être une date-heure, un âge, une période, une plage ou une chaîne de caractères ("enfance"), car les patients connaissent rarement les dates exactes. recordedDate est la date d'entrée dans le dossier, qui peut être des années plus tard.
• recorder l'a saisi ; asserter est celui qui l'affirme, ce qui peut être le patient lui-même.

Condition vs Observation

Dans FHIR, une Observation est un point de donnée unique mesuré ou rapporté, comme une mesure de tension artérielle ou un mal de tête enregistré, tandis qu'une Condition est l'interprétation clinique persistante qui est gérée dans le temps, comme l'hypertension ou la migraine. Les Observations fournissent des preuves ; une Condition est une affirmation concernant le patient, faite par un clinicien ou le patient.

Une mesure de tension artérielle est une Observation. L'hypertension est une Condition. Un symptôme que le patient enregistre ("mal de tête, 6/10, depuis mardi") est une Observation ; le jugement d'un clinicien selon lequel les maux de tête sont une migraine est une Condition. Règle générale : les Observations sont des points de données ; les Conditions sont l'interprétation clinique qui persiste et est gérée. Anpheros enregistre les symptômes comme des Observations et ne crée une Condition que pour un diagnostic posé par un clinicien ou rapporté par la personne telle qu'on lui a dit ; l'application ne dérive jamais une Condition à partir de symptômes. Voir Symptômes en tant qu'Observations et Conditions en tant qu'enregistrements.

Diagnostics de rencontre et la liste de problèmes

Dans FHIR, un diagnostic de rencontre est une Condition liée depuis Encounter.diagnosis pour une visite, avec un usage tel que diagnostic d'admission ou de sortie et un rang, tandis que la liste de problèmes est l'ensemble permanent des Conditions avec la catégorie problem-list-item et un statut clinique actif. La même maladie peut apparaître dans les deux rôles, liée à différentes rencontres.

Une Encounter pointe vers ses diagnostics via Encounter.diagnosis, chacun avec un use (diagnostic d'admission, diagnostic de sortie, motif de consultation, comorbidité, facturation) et un rank. La liste de problèmes est l'ensemble des Conditions avec la catégorie problem-list-item et un clinicalStatus actif ou similaire. La réconciliation des deux (le diagnostic de sortie est-il devenu un nouveau problème ?) est un travail clinique que FHIR enregistre mais n'automatise pas. Voir FHIR Encounter expliqué.

Ce qu'il ne faut pas mettre dans une Condition

Une Condition FHIR ne devrait contenir qu'un diagnostic, un problème ou un symptôme que quelqu'un affirme concernant le patient. Les antécédents familiaux appartiennent à FamilyMemberHistory, les allergies à AllergyIntolerance, les risques et scores à Observation ou RiskAssessment, et les procédures terminées à Procedure. Tout ce qui est inféré par le logiciel sans qu'un clinicien ou le patient ne l'affirme n'appartient pas du tout à une Condition.

• Antécédents familiaux (cela appartient à FamilyMemberHistory).
• Allergies (AllergyIntolerance a son propre modèle de criticité et de réaction).
• Risques et scores (Observation ou RiskAssessment).
• Procédures qui ont été effectuées (Procedure).
• Tout ce que le logiciel a déduit sans qu'un clinicien ou le patient ne l'affirme ; une Condition est une affirmation concernant le patient, et asserter indique de qui il s'agit.

Dans Anpheros

Anpheros crée des ressources Condition FHIR sur la plateforme Anpheros uniquement à partir d'une écriture de clinique via l'API, d'un document codé dont la provenance remonte à celui-ci, ou d'un diagnostic que la personne rapporte avoir reçu. Chaque Condition est affichée avec son statut et sa source, et l'application ne pose jamais de diagnostic ni ne marque une Condition comme confirmée par elle-même.

Les cliniciens voient la même Condition avec ses codes, ce qui rend le dossier lisible par tout système FHIR.

Pages connexes

• FHIR Encounter expliqué
• CodeableConcept et Coding dans FHIR
• SNOMED CT vs ICD-10
• FHIR Observation expliqué
• FHIR AllergyIntolerance expliqué
• Exemple de Condition sur le site développeur

Sources

• HL7 FHIR R4 : Condition
• HL7 Terminology : condition-clinical code system
• HL7 Terminology : condition-ver-status code system
• HL7 US Core : Profils de Condition
• HL7 IPS : Profil de Condition

Questions fréquentes

Dois-je utiliser SNOMED CT ou ICD-10 dans Condition.code ?

Les deux, lorsque vous les avez tous les deux. SNOMED CT porte la signification clinique pour les soins ; ICD-10 (ou sa variante nationale) porte la classification pour le reporting et la facturation. Mettez chacun comme un Coding dans le même CodeableConcept ; les profils indiquent lequel est requis.

Comment enregistrer qu'un diagnostic était erroné ?

Définissez verificationStatus à refuted si la condition a été écartée après avoir été envisagée, ou entered-in-error si elle a été enregistrée par erreur. Ne supprimez pas la ressource ; l'historique fait partie de l'enregistrement.

Où va un symptôme, Condition ou Observation ?

En tant qu'Observation tant qu'il s'agit d'un point de données rapporté (score de douleur, durée, déclencheur). En tant que Condition uniquement lorsqu'un clinicien ou le patient l'affirme comme un problème à gérer, avec le verificationStatus approprié.

La Condition a-t-elle une date de diagnostic ?

onset[x] est la date à laquelle la condition a commencé, ce qui peut être approximatif ; recordedDate est la date à laquelle elle a été saisie. Il n'y a pas de date de diagnostic distincte ; de nombreux guides utilisent recordedDate ou une référence Encounter pour cela.

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 →