Recurso FHIR Encounter explicado, com um exemplo

Resposta curta: um Encounter é uma interação entre um paciente e o sistema de saúde: uma consulta externa, uma estadia hospitalar, um atendimento de urgência, uma consulta por vídeo, uma visita domiciliária. Registra quando (period), em que contexto (class: ambulatório, internamento, urgência, cuidados domiciliários, virtual), o seu estado (planeado → em curso → concluído), quem participou, porquê (reasonCode) e o que foi diagnosticado (diagnosis, ligando a Conditions). Observações, procedimentos, prescrições de medicação e documentos apontam para o Encounter a que pertencem, sendo assim possível ler o registo visita a visita.

Um exemplo válido de FHIR R4

Um recurso FHIR R4 Encounter válido requer apenas o estado e a classe, mas um recurso útil também inclui o sujeito, o período, o tipo, os participantes, um motivo e os diagnósticos que estabeleceu. O exemplo abaixo é uma consulta ambulatorial concluída para diabetes tipo 2, com um profissional principal, um diagnóstico de queixa principal classificado em primeiro lugar, um local e a organização responsável.

{
  "resourceType": "Encounter",
  "id": "visit-2026-03-14",
  "status": "finished",
  "class": {"system": "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code": "AMB", "display": "ambulatory"},
  "type": [{"coding": [{"system": "http://snomed.info/sct", "code": "11429006", "display": "Consultation"}]}],
  "serviceType": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/service-type", "code": "165", "display": "Diabetes Education"}]},
  "subject": {"reference": "Patient/example"},
  "participant": [{
    "type": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType", "code": "PPRF", "display": "primary performer"}]}],
    "individual": {"reference": "Practitioner/gp-42"}
  }],
  "period": {"start": "2026-03-14T09:00:00+01:00", "end": "2026-03-14T09:25:00+01:00"},
  "reasonCode": [{"coding": [{"system": "http://snomed.info/sct", "code": "44054006", "display": "Type 2 diabetes mellitus"}]}],
  "diagnosis": [{
    "condition": {"reference": "Condition/t2dm"},
    "use": {"coding": [{"system": "http://terminology.hl7.org/CodeSystem/diagnosis-role", "code": "CC", "display": "Chief complaint"}]},
    "rank": 1
  }],
  "location": [{"location": {"reference": "Location/clinic-3"}, "status": "completed"}],
  "serviceProvider": {"reference": "Organization/hospital"}
}

Estado: o ciclo de vida

O estado de um Encounter FHIR transita por planeado, chegado, triado, em curso, em licença e concluído, com cancelado, inserido com erro e desconhecido como as outras saídas. O elemento statusHistory mantém cada estado anterior com o seu período, pelo que uma hospitalização mostra quando o paciente chegou, foi admitido e saiu. Um Encounter é a interação em si, não a Consulta que a agendou.

planned (marcado, ainda não iniciado) → arrived → triaged (serviços de urgência) → in-progress → onleave (paciente internado em licença temporária) → finished. cancelled e entered-in-error terminam-no de outra forma; unknown existe para importações. statusHistory guarda os estados anteriores com os seus períodos, pelo que uma estadia hospitalar mostra quando o paciente chegou, quando foi admitido e quando saiu. Note que um Encounter não é um Appointment: o Appointment é a marcação; quando o paciente chega, é criado um Encounter que o referencia através de appointment.

Classe: o contexto

A class do Encounter provém do sistema HL7 v3 ActCode: AMB ambulatório (externo), IMP internado, EMER emergência, HH saúde ao domicílio, VR virtual (telemedicina), ACUTE e NONAC para subtipos de internamento, OBSENC observação, PRENC pré-admissão, SS curta duração. classHistory regista transferências, por exemplo, um atendimento de emergência que se tornou uma admissão.

Os outros elementos

Para além do estado e da classe, um Encounter FHIR inclui o tipo e o serviceType (que tipo de visita e qual a linha de serviço), o participante (clínicos com os seus papéis e períodos), o reasonCode ou reasonReference, o diagnóstico (Condições ligadas com uso e classificação), a hospitalização (detalhes de admissão e alta), entradas de localização ao longo do tempo, duração, o serviceProvider e partOf para sub-encounters.

type e serviceType indicam o tipo de encontro e a linha de serviço (cardiologia, educação para a diabetes), com códigos que variam por país.
participant lista clínicos e outros com um tipo de participação (admitente, atendente, executor principal, consultor, referenciador) e o período em que cada um esteve envolvido.
reasonCode / reasonReference fornecem o motivo da visita; diagnosis liga as Conditions estabelecidas ou abordadas, com um use (diagnóstico de admissão AD, diagnóstico de alta DD, queixa principal CC, comorbilidade CM, faturação) e uma rank. Ver FHIR Condition explicado.
hospitalization contém detalhes da admissão: admitSource (referenciação médica de família, urgência, transferência), dischargeDisposition (casa, outro hospital, falecido), preAdmissionIdentifier, dieta e arranjos especiais.
location lista os locais com o seu estado ao longo do tempo (planeado, ativo, reservado, concluído); uma transferência de enfermaria adiciona uma nova entrada.
length é a duração; serviceProvider a organização responsável; partOf liga um sub-encontro (uma estadia em enfermaria) à admissão a que pertence.

O que mudou no R5

O FHIR R5 renomeou Encounter.hospitalization para admission, fundiu reasonCode e reasonReference em reason, tornou class uma lista de CodeableConcept (um encounter pode ter várias classificações), moveu participant.individual para actor, e introduziu EncounterHistory como um recurso separado para o histórico de estado e classe. O R4 continua a ser a versão no US Core e na maioria dos guias nacionais; veja FHIR R4 vs R5.

Mapeamento do HL7 v2

As mensagens HL7 v2 ADT mapeiam para FHIR Encounter por tipo de evento: A01 admitir cria um Encounter internado em curso, A03 dar alta conclui-o com period.end e discharge disposition, A02 transferir adiciona uma entrada de localização, A04 regista um Encounter ambulatório e A08 atualiza-o. A maior parte dos dados provém do segmento PV1, cujo número de visita se torna Encounter.identifier.

Um ADT^A01 (admissão) cria um Encounter com classe IMP e estado in-progress; A03 (alta) define o estado finished e preenche period.end e dischargeDisposition; A02 (transferência) adiciona uma entrada location; A04 (registo de consulta externa) cria um Encounter AMB; A08 atualiza-o. PV1 contém a maioria dos dados (classe do paciente em PV1-2, localização em PV1-3, atendente em PV1-7, número da visita em PV1-19, que se torna Encounter.identifier). Ver Mensagens HL7 v2 explicadas.

Na Anpheros

A Plataforma Anpheros cria recursos FHIR Encounter de duas formas: as clínicas escrevem-nos através da API, e a visita registada de uma pessoa torna-se um Encounter concluído assim que a consulta tiver ocorrido. Os resultados, documentos e notas dessa visita referenciam o Encounter, pelo que o registo pode ser lido visita a visita pela pessoa e por qualquer clínica com quem partilhe.

As consultas agendadas na aplicação são recursos de Consulta até que aconteçam.

Páginas relacionadas

Fontes

Perguntas frequentes

Qual é a diferença entre Encounter e Appointment?

Um Appointment é a marcação de um horário futuro; um Encounter é a interação que realmente aconteceu (ou está a acontecer). Quando o paciente chega, o Encounter é criado e referencia o Appointment.

Uma estadia hospitalar é um Encounter ou vários?

Normalmente um Encounter para a admissão, com entradas de localização para cada enfermaria e classHistory para mudanças de contexto. Alguns sistemas criam sub-encontros por estadia em enfermaria ligados através de partOf; os guias nacionais indicam qual.

Onde vai o resumo de alta?

Como um DocumentReference ou um documento FHIR cuja Composition referencia o Encounter. O próprio Encounter contém a disposição de alta e as datas, não a narrativa.

Cada Observation precisa de um Encounter?

Não. Observações que o paciente regista em casa, ou que chegam de um dispositivo vestível, não têm Encounter. As que são feitas durante uma visita devem referenciá-lo para que o registo possa ser lido por visita.

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.

Criar um sandbox grátis Ler os guias para programadores →

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 →