La risorsa FHIR Condition spiegata: stato clinico, stato di verifica, categorie e codici, con un esempio

Risposta breve: Condition è la risorsa FHIR per una diagnosi, un problema di salute o un sintomo che ha raggiunto un livello di preoccupazione: questo paziente ha il diabete di tipo 2, attivo, confermato, dal 2019. I suoi due campi di stato sono ciò che lo rendono utile. clinicalStatus indica a che punto è la condizione nel suo decorso (attivo, recidiva, ricaduta, inattivo, remissione, risolto); verificationStatus indica quanto si è sicuri (non confermato, provvisorio, differenziale, confermato, confutato, inserito per errore). category separa gli elementi della lista dei problemi a lungo termine dalle diagnosi di incontro registrate per una visita. Il codice è solitamente SNOMED CT, spesso con un codice ICD-10 accanto per la rendicontazione.

Un esempio valido di FHIR R4

Una risorsa FHIR R4 Condition valida richiede un riferimento al soggetto e, a meno che non sia inserita per errore, uno stato clinico; in pratica, include anche lo stato di verifica, una categoria (elemento della lista dei problemi o diagnosi di incontro), una diagnosi codificata e un'insorgenza. L'esempio seguente registra il diabete di tipo 2 confermato e attivo con un codice SNOMED CT e un codice ICD-10 affiancati.

{
  "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."}]
}

Gli elementi che contano

Gli elementi Condition che contano di più sono clinicalStatus (dove si trova la condizione nel suo decorso), verificationStatus (quanto è certa la diagnosi), category (elemento della lista dei problemi o diagnosi di incontro), code (solitamente SNOMED CT, spesso con ICD-10 accanto), onset e abatement, recordedDate, e recorder e asserter, che indicano chi ha inserito la condizione e chi la rivendica.

• clinicalStatus è richiesto ogni volta che la condizione non è inserita per errore, e i suoi valori seguono il decorso di una malattia. resolved è per le condizioni che sono terminate (una frattura che è guarita); remission per quelle che potrebbero ripresentarsi; inactive per un problema non più gestito. Modificarlo è il modo in cui una lista di problemi rimane veritiera senza cancellare la cronologia.
• verificationStatus registra la certezza. provisional e differential sono diagnosi di lavoro durante un'indagine; confirmed una volta stabilite; refuted quando escluse, il che mantiene il registro di ciò che è stato considerato. Una voce a livello di sintomo è spesso unconfirmed.
• category: problem-list-item per la lista permanente che un medico di base mantiene; encounter-diagnosis per ciò di cui trattava questa visita. La stessa malattia può apparire come entrambe, collegata a diversi incontri.
• code è un CodeableConcept, quindi può contenere un concetto SNOMED CT per il significato clinico e un codice ICD-10 per le statistiche fianco a fianco. Vedere CodeableConcept e Coding e SNOMED CT vs ICD-10.
• bodySite, severity e stage (con riferimenti alla valutazione) qualificano la condizione; evidence punta alle Osservazioni o ai referti che la supportano.
• onset[x] e abatement[x] possono essere una data-ora, un'età, un periodo, un intervallo o una stringa ("infanzia"), poiché i pazienti raramente conoscono date esatte. recordedDate è quando è entrata nel registro, il che può essere anni dopo.
• recorder l'ha inserita; asserter è chi la rivendica, che può essere il paziente stesso.

Condition vs Observation

In FHIR, un'Observation è un singolo dato misurato o segnalato, come una lettura della pressione sanguigna o un mal di testa registrato, mentre una Condition è l'interpretazione clinica persistente che viene gestita nel tempo, come l'ipertensione o l'emicrania. Le Observations forniscono prove; una Condition è un'affermazione sul paziente fatta da un medico o dal paziente.

Una lettura della pressione sanguigna è un'Osservazione. L'ipertensione è una Condizione. Un sintomo che il paziente registra ("mal di testa, 6/10, da martedì") è un'Osservazione; il giudizio di un medico che i mal di testa sono emicrania è una Condizione. Regola generale: le Osservazioni sono punti dati; le Condizioni sono l'interpretazione clinica che persiste ed è gestita. Anpheros registra i sintomi come Osservazioni e crea una Condizione solo per una diagnosi fatta da un medico o riportata dalla persona come le è stato detto; l'app non deriva una Condizione dai sintomi. Vedere Sintomi come Osservazioni e Condizioni come registrazioni.

Diagnosi di incontro e lista dei problemi

In FHIR, una diagnosi di incontro è una Condition collegata da Encounter.diagnosis per una visita, con un uso come diagnosi di ammissione o dimissione e un rango, mentre la lista dei problemi è l'insieme permanente di Conditions con categoria problem-list-item e uno stato clinico attivo. La stessa malattia può comparire in entrambi i ruoli, collegata a incontri diversi.

Un Encounter punta alle sue diagnosi tramite Encounter.diagnosis, ognuna con un use (diagnosi di ammissione, diagnosi di dimissione, motivo principale, comorbilità, fatturazione) e un rank. La lista dei problemi è l'insieme delle Condizioni con categoria problem-list-item e uno clinicalStatus attivo o simile. La riconciliazione dei due (la diagnosi di dimissione è diventata un nuovo problema?) è un lavoro clinico che FHIR registra ma non automatizza. Vedere FHIR Encounter spiegato.

Cosa non inserire in una Condition

Una Condition FHIR dovrebbe contenere solo una diagnosi, un problema o un sintomo che qualcuno afferma riguardo al paziente. La storia familiare appartiene a FamilyMemberHistory, le allergie ad AllergyIntolerance, i rischi e i punteggi in Observation o RiskAssessment, e le procedure completate in Procedure. Tutto ciò che il software ha dedotto senza che un medico o il paziente lo abbia affermato non appartiene affatto a una Condition.

• Anamnesi familiare (appartiene a FamilyMemberHistory).
• Allergie (AllergyIntolerance ha il suo modello di criticità e reazione).
• Rischi e punteggi (Observation o RiskAssessment).
• Procedure eseguite (Procedure).
• Qualsiasi cosa che il software ha dedotto senza che un medico o il paziente l'abbiano affermato; una Condizione è una dichiarazione sul paziente, e asserter dice di chi.

In Anpheros

Anpheros crea risorse FHIR Condition sulla Piattaforma Anpheros solo da una clinica che scrive tramite API, da un documento codificato con provenienza che vi rimanda, o da una diagnosi che la persona riferisce di aver ricevuto. Ogni Condition viene mostrata con il suo stato e la sua fonte, e l'app non diagnostica o contrassegna mai una Condition come confermata da sola.

I medici vedono la stessa Condition con i suoi codici, il che rende il record leggibile da qualsiasi sistema FHIR.

Pagine correlate

• FHIR Encounter spiegato
• CodeableConcept e Coding in FHIR
• SNOMED CT vs ICD-10
• FHIR Observation spiegato
• FHIR AllergyIntolerance spiegato
• Esempio di Condition sul sito per sviluppatori

Fonti

• HL7 FHIR R4: Condition
• HL7 Terminology: condition-clinical code system
• HL7 Terminology: condition-ver-status code system
• HL7 US Core: Condition profiles
• HL7 IPS: Condition profile

Domande frequenti

Devo usare SNOMED CT o ICD-10 in Condition.code?

Entrambi, quando li avete entrambi. SNOMED CT porta il significato clinico per la cura; ICD-10 (o la sua variante nazionale) porta la classificazione per la rendicontazione e la fatturazione. Inseriteli entrambi come Coding nello stesso CodeableConcept; i profili indicano quale è richiesto.

Come registro che una diagnosi era sbagliata?

Impostare verificationStatus su refuted se la condizione è stata esclusa dopo essere stata considerata, o entered-in-error se è stata registrata per errore. Non cancellare la risorsa; la cronologia fa parte del registro.

Dove va un sintomo, Condition o Observation?

Come Osservazione finché è un punto dati riportato (punteggio del dolore, durata, fattore scatenante). Come Condizione solo quando un medico o il paziente la afferma come problema da gestire, con il relativo verificationStatus.

La Condition ha una data di diagnosi?

onset[x] è quando la condizione è iniziata, che può essere approssimativa; recordedDate è quando è stata inserita. Non esiste una data di diagnosi separata; molte guide usano recordedDate o un riferimento Encounter per questo.

Anpheros Platform

Provalo gratis nella sandbox

La tua prima chiamata FHIR in 5 minuti. Un'API HL7 FHIR R4 con il consenso del paziente integrato: provala nella sandbox, poi collega la tua app o il sistema della tua clinica.

Crea una sandbox gratuitaLeggi le guide per sviluppatori →

Gratis · 30 pazienti sintetici · senza carta

Scritto da

Il team Anpheros

Anpheros sviluppa una cartella clinica che il paziente controlla e può condividere con qualsiasi studio medico, su una piattaforma HL7 FHIR R4, con sede in UE. Queste guide ti aiutano a comprendere e organizzare la tua salute; non sostituiscono il tuo medico.

Chi siamo →