Integração & APIs — HL7® FHIR + MQTT/REST
Atualizado em jan/2026 · Voltar ao Hub
Por que FHIR + MQTT no Edge
FHIR é o padrão API‑first (REST/JSON/XML) para interoperabilidade em saúde e tem priorização em planos federais/guia de adoção. MQTT é um protocolo leve (pub/sub) com baixa latência, ideal para eventos e telemetria em redes instáveis. Trabalhos recentes mostram um stack aberto com ESP32 + MQTT + FHIR Observations operando em tempo real sem middleware proprietário. [1][2]
Modelo de dados (FHIR)
Observation: vitais e indicadores (e.g.,hr,spo2,arrhythmia_event_probability).Device,DeviceMetric: identificação e métricas do sensor/gateway.Patient,Encounter: contexto clínico quando aplicável.
Arquitetura
- Gateway (Edge): coleta BLE/USB, processa, gera Observations e alerts.
- Broker MQTT local: tópicos como
healthtrack/site/<deviceId>/alerts(QoS1/2). - Servidor FHIR local ou bridge:
POST /Observationassinado/TLS para EHR/Analytics. [1]
// Exemplo: payload MQTT (JSON) mínimo, sem PHI
{
"deviceId": "gw-ecg-001",
"ts": "2026-01-23T03:21:00Z",
"type": "arrhythmia_alert",
"p": 0.86,
"hr": 104
}Segurança e conformidade
- TLS/mTLS, rotação de credenciais, RBAC no broker e no servidor FHIR.
- Logs e métricas sem PHI; auditoria e alarmes de integração.
- Terminologias (LOINC/SNOMED) quando aplicável; perfis FHIR versionados. [3]
Testes de contrato
Crie contract tests para endpoints FHIR (schemata JSON), tópicos MQTT (estrutura, QoS) e paths de erro. Simule latência/perdas e confirme o comportamento store‑and‑forward do gateway.
Quando a integração vira “dispositivo”
Se outputs afetarem decisão clínica, documente ciclo de vida de software (IEC 62304) e, para AI/ML com atualização, considere um PCCP (plano de mudanças pré‑determinadas) junto à FDA quando aplicável. [4][5]