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);remissionpara aquelas que podem retornar;inactivepara 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.
provisionaledifferentialsão diagnósticos de trabalho durante uma investigação;confirmeduma vez estabelecido;refutedquando descartado, o que mantém o registo do que foi considerado. Uma entrada ao nível do sintoma é frequentementeunconfirmed. - category:
problem-list-itempara a lista permanente que um médico de família mantém;encounter-diagnosispara 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
asserterdiz 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
- FHIR Encounter explicado
- CodeableConcept e Coding em FHIR
- SNOMED CT vs ICD-10
- FHIR Observation explicado
- FHIR AllergyIntolerance explicado
- Exemplo de Condition no site do programador
Fontes
- 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
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.
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

