Da Descoberta à Produção:
Plataforma de Monitorização de Dispositivos Médicos

O que a plataforma faz

Dispositivos médicos conectados — pacemakers, garrafas de oxigénio e outros equipamentos críticos — enviam leituras contínuas de pacientes no terreno. A plataforma ingere essa telemetria em tempo real, valida-a e processa-a contra regras clínicas.

Quando uma leitura é anómala — um ritmo de pacemaker fora dos parâmetros esperados, um nível de oxigénio a descer abaixo do limiar — o sistema gera um alerta. Os médicos analisam esses alertas num dashboard, examinam os dados do paciente e decidem se devem escalar.

Cada passo nesta cadeia tem de ser auditável, encriptado e disponível 24 horas por dia. Um alerta perdido, uma leitura corrompida ou uma falha no trilho de auditoria pode afectar directamente o cuidado ao paciente. É esse o peso do que esta plataforma carrega.

O desafio

O cliente estava a construir um novo dispositivo médico conectado e precisava de uma plataforma cloud-native de raiz para o suportar. Milhares de dispositivos transmitiriam telemetria continuamente. A plataforma tinha de ingerir, processar e armazenar esses dados com total conformidade PHI (Protected Health Information) e disponibilidade 24/7.

Isto não eram dados de inventário ou analytics. Eram leituras de pacemakers e níveis de oxigénio. Um alerta atrasado ou uma falha no trilho de auditoria podia afectar directamente a segurança do paciente. Cada decisão arquitectural tinha de ter isso em conta.

Precisavam de uma equipa que pudesse ser dona de toda a entrega — arquitectura, engenharia backend, infraestrutura, DevOps e conformidade — tudo sob o mesmo tecto. Uma unidade autónoma capaz de avançar rápido sem depender de equipas externas ou handoffs.

As restrições eram apertadas. Nove meses da primeira linha de código até produção. Uma equipa distribuída por vários fusos horários. E requisitos regulatórios que não deixavam margem para atalhos: cada dado de paciente tinha de ser encriptado, auditável e com controlo de acesso desde o primeiro dia.

Descoberta

Começámos com uma fase de descoberta focada antes de escrever qualquer código de produção. O objectivo era compreender o domínio clínico com profundidade suficiente para tomar decisões arquitecturais que resistissem ao escrutínio regulatório.

Mapeámos o modelo de domínio completo para telemetria de dispositivos: que dados cada tipo de dispositivo emitiria, com que frequência e em que formato. Um pacemaker envia leituras diferentes de uma garrafa de oxigénio, a intervalos diferentes, com limiares de alerta diferentes. Definimos os limites de classificação PHI — quais elementos de dados contavam como Protected Health Information e quais não — porque esta distinção determina a encriptação, controlo de acesso e requisitos de auditoria em todo o sistema.

Trabalhámos directamente com a equipa regulatória do cliente para validar o modelo de conformidade. O resultado foi uma especificação partilhada que cada decisão arquitectural subsequente iria referenciar.

Porque é que cada dado tem de ser contabilizado

Quando um pacemaker envia uma leitura, essa leitura tem de ser armazenada de forma imutável. É preciso saber exactamente o que foi recebido, quando chegou e quem acedeu depois. A conformidade na área da saúde exige um trilho de auditoria definitivo e à prova de adulteração — não apenas o estado actual de um registo de paciente, mas o histórico completo de cada alteração.

Resolvemos isto com Event Sourcing. Cada mudança de estado é armazenada como um evento imutável. Nada é sobrescrito. Nada é apagado. O histórico completo está sempre disponível para auditoria, e o sistema pode reconstruir o estado de qualquer registo em qualquer momento no tempo.

A plataforma também precisava de lidar com duas cargas de trabalho muito diferentes em simultâneo: escritas pesadas e contínuas de milhares de dispositivos a transmitir telemetria, e leituras rápidas dos dashboards de médicos que precisam de ver dados de pacientes e alertas em tempo real. Usámos CQRS (Command Query Responsibility Segregation) para separar estes caminhos — escritas append-only de alto throughput de um lado, projecções de leitura pré-computadas optimizadas para o dashboard do outro.

O controlo de acesso era igualmente crítico. Num ambiente PHI, o acesso de cada utilizador deve ser granular e auditável — um enfermeiro vê dados diferentes de um cardiologista, e cada acesso é registado. Usámos Keycloak para gestão de identidade, dando-nos controlo de acesso baseado em papéis e single sign-on integrado com a infraestrutura de autenticação existente do cliente.

Construir para a fiabilidade

A plataforma funciona 24/7 porque os médicos dependem dela. Se o sistema falha, os alertas não são gerados. Se os alertas não são gerados, um médico pode não ver uma leitura anómala de um pacemaker. Cada decisão de infraestrutura foi tomada com isso em mente.

Construímos a plataforma como microserviços containerizados em Kubernetes (AKS), para que cada serviço pudesse escalar de forma independente. Quando a carga de dispositivos aumentava — milhares de dispositivos a transmitir dados em simultâneo, actualizações de firmware a disparar uploads em lote — os serviços de ingestão escalavam sem afectar as camadas de alertas ou dashboard.

Toda a comunicação entre serviços era encriptada por defeito usando mutual TLS. Implementámos um service mesh (Istio) que também nos deu circuit breakers para isolar falhas antes de se propagarem, e canary deployments para lançar alterações numa fracção do tráfego antes de comprometer.

Tratámos a infraestrutura como código. Toda a configuração de deployment vivia no Git e era automaticamente reconciliada usando GitOps (FluxCD). Cada ambiente — dev, staging, produção — era reprodutível a partir de um único commit. Os recursos cloud eram provisionados com Terraform, o empacotamento da aplicação com Helm. Sem passos manuais. Sem drift entre ambientes. As alterações de infraestrutura passavam pelo mesmo processo de pull request e revisão que o código aplicacional.

Do dispositivo ao dashboard

Uma leitura de pacemaker chega à plataforma. Precisa de ser armazenada, processada contra regras clínicas e — se anómala — apresentada como alerta no dashboard de um médico em segundos. A jornada dos dados cruza várias camadas de armazenamento, cada uma escolhida por uma razão específica.

A telemetria dos dispositivos é diversa — um pacemaker envia dados diferentes de uma garrafa de oxigénio, e o formato pode mudar entre versões de firmware. Armazenámos a telemetria bruta numa base de dados documental flexível (CosmosDB) que podia ingerir payloads variados sem migrações de schema rígidas. Os dados estruturados — registos de pacientes, registos de dispositivos, configurações de alertas — viviam numa base de dados relacional (SQL Server). Os dados frequentemente acedidos eram colocados em cache (Hazelcast) para que os dashboards dos médicos carregassem rapidamente mesmo sob tráfego pesado de leitura.

Instrumentámos toda a jornada dos dados com monitorização e tracing. Se uma leitura demorava demasiado a processar, se um alerta falhava a ser gerado, ou se uma consulta ao dashboard abrandava, a equipa de operações via imediatamente. O Prometheus recolheu métricas em tempo real de cada serviço. O Jaeger rastreou cada pedido desde o momento em que os dados do dispositivo chegaram, passando pela ingestão, processamento, geração de alertas e armazenamento — essencial para perceber onde vivia a latência num sistema com dezenas de serviços.

Coordenação da equipa distribuída

A equipa estava distribuída por vários fusos horários, o que adicionou um desafio de coordenação à complexidade técnica. Resolvemos isto através do modelo de equipa autónoma: arquitectura, engenharia backend, infraestrutura, DevOps e conformidade estavam todos dentro da mesma unidade. Sem dependências externas. Sem filas de handoff. Quando uma decisão precisava de ser tomada, as pessoas que a podiam tomar já estavam na sala.

Estabelecemos padrões claros de comunicação assíncrona e horas de trabalho sobrepostas para colaboração cross-timezone. As decisões arquitecturais ficaram documentadas em registos de decisão. As cerimónias de sprint eram conscientes dos fusos horários. O workflow GitOps significava que alterações de infraestrutura eram visíveis e revistas por qualquer membro da equipa independentemente da localização — o histórico Git era a fonte única de verdade.

Entrega iterativa através de MVPs

Entregámos a plataforma através de uma série de MVPs progressivos em vez de um único lançamento big-bang. Cada MVP visou um risco clínico e técnico específico antes de avançarmos para a fase seguinte.

O primeiro MVP respondeu à pergunta mais fundamental: conseguimos ingerir leituras de pacemakers a escala e armazená-las com a encriptação PHI e controlos de acesso necessários? O segundo validou se os médicos conseguiam consultar dados de pacientes rápido o suficiente para agir sobre alertas — testando as projecções de leitura CQRS sob carga realista. MVPs posteriores adicionaram camadas de detecção de anomalias e geração de alertas, testes de resiliência sob cenários de falha, e a integração de gestão de identidade que controlava quem podia ver que dados de pacientes.

Quando chegámos a produção, cada caminho crítico — da ingestão do dispositivo ao alerta do médico — tinha sido testado e refinado ao longo de múltiplas iterações. Cada MVP construiu confiança com as equipas regulatórias e de produto do cliente. Quando entrámos em produção, não houve surpresas.

Stack tecnológico