FHIR

Recurso FHIR Condition explicado: estado clínico, estado de verificação, categorias e códigos, com um exemplo

Registe diagnósticos, problemas ou sintomas com o recurso Condition. Saiba o significado de clinicalStatus e verificationStatus, a diferença entre item da lista de problemas e diagnóstico, códigos SNOMED CT/ICD-10, início/remissão, exemplo R4 e o que não incluir.

por Publicado 7 min de leitura

Resposta curta: Condition é o recurso FHIR para um diagnóstico, um problema de saúde ou um sintoma que atingiu um nível de preocupação: este paciente tem diabetes tipo 2, ativa, confirmada, desde 2019. Os seus dois campos de estado são o que o tornam útil. clinicalStatus indica onde a condição se encontra no seu curso (ativa, recorrência, recaída, inativa, remissão, resolvida); verificationStatus indica o quão certo alguém está (não confirmada, provisória, diferencial, confirmada, refutada, inserida com erro). category separa itens da lista de problemas de longa duração de diagnósticos de encontro registados para uma consulta. O código é geralmente SNOMED CT, muitas vezes com um código ICD-10 ao lado para relatórios.

Um exemplo válido de FHIR R4

Um recurso Condition válido em FHIR R4 necessita de uma referência ao sujeito e, a menos que seja um erro de introdução, um clinicalStatus; na prática, também inclui verificationStatus, uma categoria (problem-list-item ou encounter-diagnosis), um diagnóstico codificado e um início (onset). O exemplo abaixo regista diabetes tipo 2 confirmada e ativa com um código SNOMED CT e um código ICD-10 lado a lado.

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

Os elementos que importam

Os elementos Condition que mais importam são clinicalStatus (onde a condição se encontra no seu curso), verificationStatus (quão certo é o diagnóstico), category (item da lista de problemas ou diagnóstico de encontro), code (geralmente SNOMED CT, muitas vezes com ICD-10 ao lado), onset e abatement, recordedDate, e recorder e asserter, que indicam quem introduziu a condição e quem a reivindica.

  • clinicalStatus é obrigatório sempre que a condição não é inserida com erro, e os seus valores seguem o curso de uma doença. resolved é para condições que terminaram (uma fratura que cicatrizou); remission para aquelas que podem retornar; inactive para um problema que já não está a ser gerido. Alterá-lo é como uma lista de problemas se mantém fiel sem apagar o histórico.
  • verificationStatus regista a certeza. provisional e differential são diagnósticos de trabalho durante uma investigação; confirmed uma vez estabelecido; refuted quando descartado, o que mantém o registo do que foi considerado. Uma entrada ao nível do sintoma é frequentemente unconfirmed.
  • category: problem-list-item para a lista permanente que um médico de família mantém; encounter-diagnosis para o que esta consulta foi. A mesma doença pode aparecer como ambas, ligada a diferentes encontros.
  • code é um CodeableConcept, pelo que pode conter um conceito SNOMED CT para significado clínico e um código ICD-10 para estatísticas lado a lado. Ver CodeableConcept e Coding e SNOMED CT vs ICD-10.
  • bodySite, severity e stage (com referências de avaliação) qualificam a condição; evidence aponta para as Observações ou relatórios que a suportam.
  • onset[x] e abatement[x] podem ser uma data-hora, uma idade, um período, um intervalo ou uma string ("infância"), porque os pacientes raramente sabem datas exatas. recordedDate é quando entrou no registo, o que pode ser anos mais tarde.
  • recorder inseriu-a; asserter é quem a reivindica, que pode ser o próprio paciente.

Condition vs Observation

Em FHIR, uma Observation é um único ponto de dados medido ou reportado, como uma leitura de pressão arterial ou uma dor de cabeça registada, enquanto uma Condition é a interpretação clínica persistente que é gerida ao longo do tempo, como hipertensão ou enxaqueca. As Observations fornecem evidências; uma Condition é uma afirmação sobre o paciente feita por um médico ou pelo paciente.

Uma leitura de pressão arterial é uma Observation. Hipertensão é uma Condition. Um sintoma que o paciente regista ("dor de cabeça, 6/10, desde terça-feira") é uma Observation; o julgamento de um médico de que as dores de cabeça são enxaqueca é uma Condition. Regra geral: as Observations são pontos de dados; as Conditions são a interpretação clínica que persiste e é gerida. A Anpheros regista sintomas como Observations e apenas cria uma Condition para um diagnóstico que um médico fez ou que a pessoa relatou ter-lhe sido dito; a aplicação nunca deriva uma Condition de sintomas. Ver Sintomas como Observações e Condições como registos.

Diagnósticos de encontro e a lista de problemas

Em FHIR, um diagnóstico de encontro (encounter diagnosis) é uma Condition ligada a partir de Encounter.diagnosis para uma visita, com um uso como diagnóstico de admissão ou alta e uma classificação (rank), enquanto a lista de problemas (problem list) é o conjunto permanente de Conditions com a categoria problem-list-item e um clinicalStatus ativo. A mesma doença pode aparecer em ambos os papéis, ligada a diferentes encontros.

Um Encounter aponta para os seus diagnósticos através de Encounter.diagnosis, cada um com um use (diagnóstico de admissão, diagnóstico de alta, queixa principal, comorbilidade, faturação) e um rank. A lista de problemas é o conjunto de Conditions com a categoria problem-list-item e um clinicalStatus de ativa ou similar. Conciliar os dois (o diagnóstico de alta tornou-se um novo problema?) é trabalho clínico que o FHIR regista mas não automatiza. Ver FHIR Encounter explicado.

O que não colocar numa Condition

Uma Condition em FHIR deve conter apenas um diagnóstico, problema ou sintoma que alguém afirma sobre o paciente. O historial familiar pertence a FamilyMemberHistory, alergias a AllergyIntolerance, riscos e pontuações a Observation ou RiskAssessment, e procedimentos concluídos a Procedure. Qualquer coisa inferida pelo software sem que um médico ou o paciente a afirme não pertence de todo a uma Condition.

  • Histórico familiar (isso pertence a FamilyMemberHistory).
  • Alergias (AllergyIntolerance tem o seu próprio modelo de criticidade e reação).
  • Riscos e pontuações (Observation ou RiskAssessment).
  • Procedimentos que foram realizados (Procedure).
  • Qualquer coisa que o software inferiu sem um médico ou o paciente a afirmar; uma Condition é uma afirmação sobre o paciente, e asserter diz de quem.

Na Anpheros

A Anpheros cria recursos Condition em FHIR na Plataforma Anpheros apenas a partir de uma clínica a escrever através da API, de um documento codificado com proveniência a apontar para ele, ou de um diagnóstico que a pessoa relata ter recebido. Cada Condition é apresentada com o seu estado e fonte, e a aplicação nunca diagnostica nem marca uma Condition como confirmada por si só.

Os médicos veem a mesma Condition com os seus códigos, o que torna o registo legível por qualquer sistema FHIR.

Páginas relacionadas

Fontes

Perguntas frequentes

Devo usar SNOMED CT ou ICD-10 em Condition.code?

Ambos, quando tiver ambos. SNOMED CT carrega o significado clínico para os cuidados; ICD-10 (ou a sua variante nacional) carrega a classificação para relatórios e faturação. Coloque cada um como um Coding no mesmo CodeableConcept; os perfis indicam qual é obrigatório.

Como registo que um diagnóstico estava errado?

Defina verificationStatus para refuted se a condição foi descartada após ter sido considerada, ou entered-in-error se foi registada por engano. Não elimine o recurso; o histórico faz parte do registo.

Onde vai um sintoma, Condition ou Observation?

Como Observation enquanto é um ponto de dados relatado (pontuação de dor, duração, gatilho). Como Condition apenas quando um médico ou o paciente o afirma como um problema a ser gerido, com o verificationStatus apropriado.

A Condition tem uma data em que foi diagnosticada?

onset[x] é quando a condição começou, o que pode ser aproximado; recordedDate é quando foi inserida. Não há uma data de diagnóstico separada; muitos guias usam recordedDate ou uma referência Encounter para isso.

Anpheros Platform

Experimente grátis no sandbox

Sua primeira chamada FHIR em 5 minutos. Uma API HL7 FHIR R4 com o consentimento do paciente integrado: experimente na sandbox e depois conecte a sua própria app ou sistema clínico.

Grátis · 30 pacientes sintéticos · sem cartão

Este guia é meramente informativo e não substitui aconselhamento médico. Para decisões sobre a sua saúde, fale com o seu médico. Em uma emergência, ligue para o número de emergência local (112 na Europa).
Escrito por
A equipa Anpheros

A Anpheros desenvolve um registo médico que o doente controla e pode partilhar com qualquer clínica, numa plataforma HL7 FHIR R4, sediada na UE. Estes guias ajudam-no a compreender e organizar a sua saúde; não substituem o seu médico.

Sobre a Anpheros →