Jorge José Pereira Oliveira; Marcos Jardel Henriques

DOI: 10.22167/2675-6528-202600975

Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

Resumo

A crescente demanda por sistemas de saúde digitais impulsionou a necessidade de soluções robustas e escaláveis para o registro clínico, enfrentando desafios de desempenho, escalabilidade e conformidade com a Lei Geral de Proteção de Dados (LGPD). Com o objetivo de desenvolver um protótipo de prontuário eletrônico, fundamentado em Arquitetura Limpa de microsserviços, conteinerização com Docker e orquestração com Kubernetes, buscou-se evidenciar avanços em agilidade, escalabilidade, segurança e governança de dados clínicos sensíveis, com integração nativa de Inteligência Artificial. A metodologia adotou uma arquitetura cloud-native, decompondo o sistema em microsserviços independentes (Auth, Patient, EMR, Scheduling, Audit, Professional e AI), comunicados via APIs RESTful. A infraestrutura foi conteinerizada com Docker e orquestrada por Kubernetes, garantindo padronização e resiliência. Implementou-se o Registro Clínico Orientado por Problemas (RCOP) e o protocolo SOAP para estruturação de dados, além de um pipeline de CI/CD e práticas de MLOps para o ciclo de vida dos modelos de IA. Os resultados demonstraram a padronização de ambientes, escalabilidade automática dos serviços, observabilidade avançada e conformidade com a LGPD. A arquitetura proposta mostrou-se eficaz para aplicações críticas em saúde, garantindo a qualidade do dado clínico por validações ativas e codificação terminológica. Concluiu-se que a orquestração de microsserviços conteinerizados estabeleceu uma base tecnológica viável e auditável, capaz de gerenciar grandes volumes de dados sensíveis, sustentar operações críticas com alta disponibilidade, interoperabilidade e segurança, consolidando uma solução flexível e alinhada às demandas contemporâneas do setor de saúde.

Palavras-chave: Cloud-native; LGPD; MLOps; Observabilidade; Saúde digital.

1. Introdução

A transformação digital tem remodelado profundamente diversos setores, e a saúde emerge como um dos campos mais impactados, impulsionando a demanda por sistemas digitais que transcendem o simples armazenamento de informações administrativas. A necessidade premente é por soluções tecnológicas que assegurem a qualidade, a segurança e a disponibilidade dos dados, pilares essenciais para aprimorar a tomada de decisões clínicas, gerar indicadores robustos sobre a saúde populacional e otimizar a gestão sanitária (Haddad e Lima, 2024; Pinto et al., 2022). Nesse cenário, a qualificação dos registros clínicos, particularmente na Atenção Primária à Saúde (APS), assume um papel central. A estruturação meticulosa dos dados, conforme preconizado por metodologias como o Registro Clínico Orientado a Problemas (RCOP) e o protocolo Subjetivo, Objetivo, Avaliação e Plano (SOAP), é crucial para aprimorar a qualidade do registro, preservar a memória assistencial e garantir a continuidade do cuidado longitudinal (Celuppi et al., 2024). A fragmentação dos dados clínicos pode levar a erros e ineficiência operacional, impactando a segurança do paciente.

Contudo, a concretização dessas diretrizes enfrenta obstáculos consideráveis. Além das barreiras culturais e do letramento digital, há desafios técnicos substanciais relacionados à infraestrutura, à interoperabilidade e à segurança em ambientes de sistemas distribuídos (Genezini, 2022; Gudelli, 2023). Arquiteturas de software monolíticas, comuns em sistemas legados, frequentemente resultam em ineficiências no uso de recursos e dificuldades na manutenção da consistência entre ambientes (Cherukuri, 2024), levando a falhas e atrasos. Para mitigar tais problemas, a engenharia de software contemporânea oferece soluções robustas como a conteinerização e a orquestração. O Docker permite encapsular aplicações e suas dependências em unidades leves e portáteis, garantindo que o software opere de maneira consistente em qualquer infraestrutura subjacente (Cherukuri, 2024; Gudelli, 2023). Em escala, o gerenciamento desses contêineres é otimizado pelo Kubernetes, que atua como orquestrador, automatizando a implantação, o balanceamento de carga, a escalabilidade horizontal e a auto-recuperação, conferindo aos sistemas maior resiliência e disponibilidade (Cherukuri, 2024).

Paralelamente a essas inovações infraestruturais, o avanço da saúde digital aponta para a integração cada vez mais profunda da Inteligência Artificial (IA) no suporte à decisão clínica, prometendo otimizar diagnósticos e personalizar tratamentos (Maia, 2024; Pinto et al., 2022). No entanto, essa integração exige uma arquitetura de sistema robusta, capaz de processar volumes massivos de dados em tempo real, e um gerenciamento sofisticado do ciclo de vida dos modelos de IA, conhecido como Machine Learning Operations (MLOps). A complexidade reside em garantir que a automatização e o uso de algoritmos observem rigorosamente princípios éticos e legais, especialmente no que tange à privacidade e proteção de dados sensíveis dos pacientes (Haddad e Lima, 2024). A governança de dados em saúde, portanto, torna-se um imperativo técnico e legal, exigindo soluções que protejam a privacidade dos indivíduos e garantam a integridade, a auditabilidade e a rastreabilidade de cada interação com os dados clínicos (Pinto et al., 2022). A Lei Geral de Proteção de Dados (LGPD) impõe requisitos estritos para o tratamento de informações pessoais de saúde, demandando mecanismos de controle de acesso, consentimento e auditoria intrínsecos ao design do sistema.

Neste cenário, a problemática central reside na complexidade de orquestrar microsserviços clínicos que exijam alto desempenho, escalabilidade e estrita conformidade com a Lei Geral de Proteção de Dados (LGPD). A justificativa para este estudo baseia-se na necessidade de validar uma arquitetura que una as melhores práticas de registros clínicos, como o modelo e-SUS APS, com a eficiência operacional de ambientes cloud-native (Cherukuri, 2024; Celuppi et al., 2024). Diante disso, o objetivo geral é desenvolver e analisar um protótipo de prontuário eletrônico, fundamentado em Arquitetura Limpa de microsserviços, conteinerização com Docker e orquestração com Kubernetes, com integração nativa de Inteligência Artificial, visando evidenciar avanços em agilidade, escalabilidade, segurança e governança de dados clínicos sensíveis.

2. Material e Métodos

A presente pesquisa caracterizou-se como um estudo de natureza aplicada e de desenvolvimento tecnológico, cujo objetivo principal consistiu na criação e validação de um protótipo de prontuário eletrônico. Este protótipo foi concebido para atender às demandas de atividades médico-hospitalares, integrando práticas clínicas consolidadas, como o Registro Clínico Orientado por Problemas (RCOP), com tecnologias avançadas de engenharia de software. O desenvolvimento da solução fundamentou-se em uma arquitetura de microsserviços e contêineres, alinhada aos princípios de Arquitetura Limpa e cloud-native. A unidade de análise primária foi o próprio sistema de prontuário eletrônico, com seus componentes e interações, sem envolver população ou amostra de usuários finais, focando na validação da arquitetura em ambiente controlado de desenvolvimento.

Para garantir escalabilidade, modularidade e baixo acoplamento, adotou-se uma arquitetura baseada em microsserviços, conforme as orientações de Newman (2022) sobre aplicações distribuídas. O sistema foi decomposto em sete serviços independentes, cada um responsável por um domínio de negócio específico. Estes incluíram o Auth Service para autenticação, Patient Service para dados demográficos, EMR Service para registros clínicos RCOP/SOAP, AI Service para funcionalidades inteligentes, Audit Service para eventos críticos, Scheduling Service para agendamento e Professional Service para gestão de usuários profissionais.

A comunicação entre esses microsserviços foi estabelecida por meio de APIs RESTful, permitindo o desacoplamento entre o frontend e o backend da aplicação (Newman, 2022). O frontend serviu como interface principal para os profissionais de saúde, oferecendo telas para o preenchimento do método SOAP, visualização de histórico e interação com serviços de apoio. Para a persistência dos dados, empregou-se uma abordagem híbrida, utilizando bancos de dados relacionais para informações estruturadas e bancos NoSQL para textos livres e logs de auditoria, assegurando integridade e performance (Marmentini e Kuszera, 2025).

O empacotamento da aplicação foi realizado utilizando a tecnologia Docker. Para cada microsserviço, foram criados arquivos de configuração (Dockerfiles) que definiram as dependências e o ambiente de execução. Essa abordagem resultou na geração de imagens leves, reprodutíveis e portáveis (Newman, 2022), o que permitiu a padronização dos ambientes de desenvolvimento, teste e produção. Tal padronização mitigou inconsistências de configuração, um problema comum em implantações tradicionais (Matthias e Kane, 2015).

Para o gerenciamento e a orquestração dos contêineres, utilizou-se o Kubernetes. A infraestrutura foi organizada em clusters, onde recursos como Deployments e Services foram configurados para garantir o balanceamento de carga e a alta disponibilidade da aplicação (Gudelli, 2023). A implementação do Kubernetes permitiu a automação da escalabilidade horizontal (autoscaling), baseada na demanda por recursos computacionais. Isso assegurou a resiliência do sistema frente a variações de tráfego e possibilitou atualizações contínuas sem interrupção (Cherukuri, 2024).

A camada clínica da aplicação foi estruturada seguindo o método do Registro Clínico Orientado por Problemas (RCOP), operacionalizando o formato Subjetivo, Objetivo, Avaliação e Plano (SOAP) para a organização e registro das notas de evolução. Essa metodologia foi implementada para qualificar a coleta de dados e favorecer o contexto longitudinal do cuidado (Celuppi et al., 2024). O EMR Service, núcleo do sistema, foi o microsserviço responsável por gerenciar esses registros clínicos, garantindo validações de qualidade e integração com o serviço de Inteligência Artificial.

Na interface desenvolvida, o método SOAP foi operacionalizado com campos de texto para o registro Subjetivo, abrangendo a queixa principal e a história clínica do paciente. O Objetivo referiu-se a campos estruturados para inserção de sinais vitais e dados de exames físicos. A Avaliação permitiu ao profissional registrar suas impressões e integrar com bases de dados diagnósticos como CID, CIAP e SIGTAP. O Plano foi o módulo para prescrição de condutas, solicitações de exames e orientações ao paciente, consolidando o plano de cuidados.

Para automatizar o ciclo de vida do desenvolvimento, estabeleceu-se um pipeline de Integração Contínua e Entrega Contínua (CI/CD), garantindo estrita correspondência entre o que foi testado e o que seria implantado (Cherukuri, 2024; Matthias e Kane, 2015). O fluxo automatizado incluiu etapas de compilação do código, execução de testes unitários e de integração, análise estática de segurança e construção das imagens Docker. Essas imagens foram posteriormente enviadas a um registro de contêineres para distribuição segura (Gudelli, 2023).

Adicionalmente, implementou-se um serviço de Inteligência Artificial (AI Service) integrado à arquitetura via práticas de Machine Learning Operations (MLOps). Este módulo foi configurado para processar os dados inseridos nos campos do SOAP e fornecer sugestões de diagnóstico e alertas de risco clínico em tempo real. O AI Service operou como um microsserviço independente para facilitar o versionamento e a atualização dos modelos preditivos, garantindo que eles se mantivessem operando em escala no ambiente de produção sem interromper o funcionamento do prontuário eletrônico (Kumara et al., 2025).

Para conformidade com a Lei Geral de Proteção de Dados (LGPD) e outros dispositivos legais, implementou-se um fluxo mínimo no microsserviço Patient Service. Este fluxo permitiu criar, revogar, auditar e listar consentimentos, com suporte a filtro de status na API. O dispositivo de Consentimento e Base Legal foi estruturado para consolidar a base técnica, focando nas evoluções de privacidade do projeto (Pinto et al., 2022). A entidade Consent encapsulou os campos para o registro formal do consentimento do titular de dados, com base legal declarada.

Três casos de uso foram implementados para gerenciar o fluxo de consentimento: CreateConsentUseCase, RevokeConsentUseCase e ListPatientConsentsUseCase. Cada um possuía responsabilidade única e validações alinhadas às exigências legais. A persistência foi implementada pela classe ConsentModel via SQLAlchemy, mapeada na tabela patient_consents para eficiência nas consultas. Uma trilha de auditoria de operações de consentimento foi implementada pela função _emit_consent_audit_event, que invocou o AuditServiceClient com um payload estruturado, registrando eventos críticos após cada operação bem-sucedida.

A rastreabilidade técnica foi sustentada por versionamento no GitHub e por documentação em múltiplos artefatos. A implementação em nível de requisição foi realizada por meio de um middleware de correlação em todos os microsserviços do protótipo, que lia o cabeçalho HTTP X-Request-Id. Na ausência do valor, um UUID v4 era gerado e acrescentado ao cabeçalho de resposta, sendo incorporado a todos os eventos de log emitidos pelo serviço, que adotavam formato JSON estruturado com campos padronizados para método, caminho, código de status, duração e identificador de correlação.

A observabilidade da aplicação foi configurada com instrumentação de métricas Prometheus e tracing distribuído. Quatro métricas foram definidas e registradas na camada de infraestrutura de todos os serviços, incluindo contadores de requisições totais e em progresso, histogramas de latência e contadores de spans de trace. O endpoint /metrics foi exposto em todos os serviços e declarado como alvo de scrape. O contexto de observabilidade, incluindo Prometheus, Alertmanager e Grafana, foi provisionado, com dashboards e regras de alerta operacionais definidos (Beyer et al., 2016).

A abordagem metodológica permitiu a condução de experimentos controlados para coletar métricas de desempenho, disponibilidade e segurança, e analisar os resultados em ambiente cloud-native. Contudo, o protótipo ainda carece de refinamento com um volume maior de dados reais para validação em cenários de produção em larga escala. A extrapolação para esses ambientes depende de campanhas contínuas de carga e operação prolongada, embora a base obtida já caracterize um nível robusto de maturidade para o escopo do protótipo, conforme as limitações identificadas no estudo.

3. Resultados e Discussão

A implementação do protótipo de prontuário eletrônico demonstrou um avanço significativo na engenharia de software para sistemas de saúde, caracterizando-se por uma abordagem modular que prioriza a separação de responsabilidades, a testabilidade e a evolução incremental de funcionalidades clínicas e de inteligência artificial. A análise dos artefatos desenvolvidos revelou uma aderência prática às diretrizes de arquitetura moderna para sistemas distribuídos, um aspecto crucial para a robustez e adaptabilidade exigidas no setor de saúde. No entanto, a maturidade heterogênea entre os componentes, com maior solidez no serviço de IA e na validação por testes, e menor comprovação na orquestração e governança de *board* via evidência automatizada, sugere áreas para aprimoramento contínuo. Este achado é consistente com a complexidade inerente ao desenvolvimento de sistemas distribuídos, onde a uniformidade na maturidade de todos os módulos é um desafio comum, conforme discutido por Newman (2022). A capacidade de evoluir incrementalmente é particularmente valiosa em um domínio como a saúde, onde as necessidades e tecnologias estão em constante mudança, permitindo que o sistema se adapte sem interrupções significativas.

A organização da solução em serviços independentes, com uma estrutura interna em camadas (domínio, aplicação e infraestrutura), demonstrou aderência à Arquitetura Limpa e aos princípios de microsserviços. O *AI Service*, por exemplo, encapsulou explicitamente seus casos de uso – inferência, registro/promoção de modelo e monitoramento de *drift* – mantendo os detalhes externos, como API HTTP e *model registry*, na camada de infraestrutura. Essa separação de preocupações é fundamental para reduzir o acoplamento e favorecer a evolução isolada dos componentes, um princípio central da Arquitetura Limpa (Newman, 2022). A decomposição por domínio e os contratos explícitos de integração entre os microsserviços, estabelecidos via APIs RESTful, confirmam a eficácia dessa abordagem. Este modelo contrasta com as arquiteturas monolíticas, que, embora mais simples de implantar inicialmente, frequentemente se tornam gargalos para a escalabilidade e a manutenção à medida que crescem (Matthias e Kane, 2015). A vantagem do protótipo em termos de escalabilidade organizacional e evolução por serviço é notável, permitindo que equipes distintas trabalhem em paralelo em diferentes domínios, acelerando o ciclo de desenvolvimento e implantação.

Contudo, a adoção de microsserviços não está isenta de desafios. O protótipo, ao herdar custos típicos de sistemas distribuídos, como a necessidade de coordenação entre serviços, a complexidade da observabilidade transversal e uma maior superfície operacional, reflete as considerações levantadas por Newman (2022). A coordenação entre os sete serviços independentes (Auth, Patient, EMR, AI, Audit, Scheduling e Professional) exige mecanismos robustos de comunicação e governança para evitar inconsistências e garantir a integridade dos dados. A observabilidade transversal, que abrange o monitoramento de múltiplos serviços interconectados, é mais complexa do que em um monólito, demandando ferramentas e estratégias específicas para rastrear requisições e identificar gargalos. A maior superfície operacional, resultante da distribuição da lógica de negócio em múltiplos componentes, pode aumentar a complexidade de gerenciamento e a exposição a potenciais vulnerabilidades. A implicação prática é que, embora a arquitetura de microsserviços ofereça flexibilidade e escalabilidade, ela exige um investimento contínuo em ferramentas de automação, monitoramento e segurança para mitigar seus desafios inerentes, garantindo que os benefícios superem os custos operacionais.

A conteinerização da aplicação com Docker demonstrou a capacidade de empacotamento reprodutível e o preparo para execução padronizada. A criação de *Dockerfiles* para cada microsserviço assegurou que as dependências e o ambiente de execução fossem definidos de forma consistente, gerando imagens leves, reprodutíveis e portáveis. Essa abordagem permitiu a padronização dos ambientes de desenvolvimento, teste e produção, mitigando inconsistências de configuração que são problemas comuns em implantações tradicionais (Matthias e Kane, 2015). A execução padronizada com usuário não privilegiado e a verificação ativa de saúde em tempo de execução são práticas essenciais para a segurança e a resiliência do sistema. Este resultado alinha-se ao consenso técnico de *cloud-native* sobre portabilidade e consistência de ambiente (Cherukuri, 2024), confirmando que o Docker é uma ferramenta eficaz para garantir que o software funcione de forma idêntica em diferentes infraestruturas. A implicação prática é a redução drástica do tempo e esforço necessários para configurar ambientes de desenvolvimento e implantação, permitindo que as equipes se concentrem mais na inovação e menos na resolução de problemas de ambiente.

A orquestração por arquivo único viabilizou a inicialização integrada da malha de serviços, com dependências explícitas por condição de saúde e persistência de dados para componentes que utilizam armazenamento local. A execução ponta a ponta tornou-se mais estável e menos suscetível a falhas de configuração manual, mesmo após ajustes de permissão para escrita em banco local sob execução *non-root*. Essa evidência reforça a mitigação de inconsistências entre desenvolvimento e validação experimental, um objetivo metodológico predominante (Matthias e Kane, 2015). A incorporação de varreduras de vulnerabilidades em imagens e a geração de *Software Bill of Materials* (SBOM) por serviço elevaram a maturidade do processo de empacotamento, transformando-o em um componente ativo de governança técnica do ciclo de entrega. A presença de um *gate* automatizado para vulnerabilidades críticas corrigíveis indica que a conteinerização não é apenas um mecanismo de empacotamento, mas uma parte integrante da estratégia de segurança e conformidade, conforme recomendado por Gudelli (2023) e Matthias e Kane (2015). Isso garante que apenas artefatos seguros e auditáveis avancem para as etapas de implantação, protegendo o prontuário eletrônico contra ameaças cibernéticas e garantindo a integridade dos dados sensíveis dos pacientes.

A orquestração em Kubernetes demonstrou a transição de uma execução local integrada para um fluxo de implantação em homologação, com arquivos de configuração renderizados a partir de identificadores imutáveis de imagem, preservando a rastreabilidade entre *build* e execução. A implantação, que incluiu *Deployments*, *Services* e *Ingress*, com verificações automáticas de prontidão e funcionamento contínuo, sustentou o *rollout* validado dos serviços no *cluster*. A configuração de *autoscaling* horizontal para serviços críticos, associada a *PodDisruptionBudget* e testes automatizados de auto recuperação por falha induzida, demonstrou resiliência operacional compatível com o objetivo de continuidade de serviço. Isso é crucial para sistemas de saúde, onde a alta disponibilidade e a resiliência são imperativas (Cherukuri, 2024). Os mecanismos de *hardening* no *cluster*, com configuração por *ConfigMap/Secret*, políticas de rede de menor privilégio de saída e *guardrails* de recursos (*LimitRange/ResourceQuota*), indicam um avanço da orquestração para além da mera publicação de *workloads*. Esses resultados confirmam que os objetivos metodológicos de padronização, disponibilidade, escalabilidade e capacidade do Kubernetes de gerenciar cargas de trabalho distribuídas foram atingidos no ambiente de homologação, corroborando os achados de Gudelli (2023) sobre a robustez operacional de arquiteturas baseadas em microsserviços conteinerizados. No entanto, a extrapolação para cenários de produção em larga escala ainda depende de campanhas contínuas de carga e operação prolongada, o que representa uma limitação do estudo e uma área para futuras investigações.

A estruturação dos dados clínicos, baseada no método Subjetivo, Objetivo, Avaliação e Plano (SOAP) do Registro Clínico Orientado por Problemas (RCOP), mostrou-se eficaz na padronização da entrada de dados e na consolidação da camada clínica. O protótipo disponibilizou operações clínicas completas para criação e consulta de problemas e evoluções SOAP, com integração na borda via *gateway* e controle de acesso por perfil profissional. Este desenho resultou em uma base de registro orientada por problema, capaz de associar cada evolução SOAP ao respectivo problema clínico, preservando o vínculo semântico entre o evento assistencial e o contexto longitudinal do cuidado. A importância do RCOP e do SOAP na qualificação dos registros e na preservação da memória dos atendimentos é amplamente reconhecida na literatura (Celuppi et al., 2024), e a implementação no protótipo valida a aplicabilidade prática desses conceitos em um ambiente digital. A capacidade de vincular eventos assistenciais a problemas específicos do paciente melhora a continuidade do cuidado e facilita a compreensão da trajetória terapêutica ao longo do tempo.

No que tange à qualidade do dado clínico, a introdução de regras explícitas de completude e coerência do SOAP foi um avanço relevante. O protótipo passou a bloquear a persistência de registros com conteúdo mínimo insuficiente, uso de *placeholders* e combinações textuais incoerentes entre seções clínicas. Esse comportamento reduz o ruído documental, melhora a consistência da narrativa clínica e aumenta a confiabilidade do prontuário para uso assistencial e analítico. Do ponto de vista da discussão, trata-se de um avanço importante na qualidade estrutural do dado, pois desloca o sistema de um modelo permissivo para um modelo com validação clínica ativa em tempo de registro. A literatura tem enfatizado a necessidade de dados clínicos de alta qualidade para apoiar a tomada de decisões e a gestão sanitária (Haddad e Lima, 2024), e a abordagem do protótipo contribui diretamente para esse objetivo. A validação ativa em tempo real impede a entrada de informações inconsistentes ou incompletas, o que é fundamental para a segurança do paciente e para a precisão das análises clínicas e epidemiológicas.

Outro resultado central foi o fortalecimento da qualidade semântica do eixo RCOP por meio da integração de terminologias clínicas no ciclo de criação de problemas. Ao implementar suporte para validação de códigos em sistemas como CID, CIAP e SIGTAP, com rejeição prévia de entradas inválidas e trilha de auditoria para eventos de sucesso e falha, estabeleceu-se um mecanismo de padronização terminológica que reduz a ambiguidade diagnóstica e favorece a comparabilidade entre registros. A codificação validada amplia a utilidade do dado clínico para a continuidade do cuidado, vigilância e futuras camadas de inteligência clínica, ao mesmo tempo em que reforça a rastreabilidade operacional. O formulário estruturado guiou o registro clínico, assegurando que campos críticos não fossem omitidos, o que é um desafio comum em sistemas de prontuário eletrônico (Celuppi et al., 2024). A capacidade de integrar bases de dados diagnósticas e de procedimentos em tempo real não só melhora a precisão do registro, mas também oferece um suporte valioso para a decisão clínica, permitindo que os profissionais de saúde consultem informações padronizadas e atualizadas. A rastreabilidade operacional, por sua vez, garante que todas as ações e modificações nos registros sejam documentadas, o que é essencial para auditorias e para a conformidade regulatória.

No componente longitudinal, a implementação da *timeline* clínica por paciente e por problema consolidou o valor prático do RCOP no protótipo. Problemas e evoluções SOAP passaram a ser apresentados como eventos cronológicos em um mesmo fluxo de consulta. Esse resultado qualifica a leitura evolutiva do caso, melhora a compreensão da trajetória terapêutica e cria uma base objetiva para acompanhamento contínuo. Em ambiente de integração, a manutenção dessa capacidade também no *gateway* confirma a consistência de comportamento entre o serviço clínico e a camada de exposição, um aspecto relevante para uso real em cenários multiusuário e para a replicabilidade dos experimentos. A usabilidade, evidenciada pela separação clara entre a narrativa do paciente (Subjetivo) e os dados medidos (Objetivo), favorece a organização da informação, fundamental para concretizar o contexto longitudinal do cuidado. A robustez de desenvolvimento foi sustentada por evidências sucessivas de validação automatizada no repositório e no *pipeline* GitHub Actions, com incremento de cobertura ao longo das entregas. A progressão dos testes aprovados em serviço clínico e integração de *gateway*, associada à preservação de compatibilidade de API, indica maturidade incremental do módulo RCOP/SOAP sem regressão estrutural relevante. Em síntese, a estruturação dos dados clínicos no protótipo foi traduzida em comportamento sistêmico verificável, com ganhos concretos de consistência, estrutura semântica adequada e capacidade longitudinal do prontuário, superando as limitações de sistemas que não conseguem manter a integridade e a coerência dos dados ao longo do tempo.

A implementação do *pipeline* de Integração Contínua e Entrega Contínua (CI/CD) consolidou-se no arquivo ‘*python-ci.yml*’, composto por quatorze *jobs* paralelos organizados em camadas de qualidade progressiva. A primeira camada abrangeu a verificação de compatibilidade de contrato de API, comparando os esquemas OpenAPI atuais com a linha de base registrada, impedindo qualquer regressão silenciosa de interface entre os microsserviços. A segunda camada executou análise estática de segurança via Bandit, construiu imagens Docker e as submeteu ao Trivy, bloqueando a promoção do artefato em caso de CVE crítico com correção disponível, além de gerar a *Bill of Materials* (SBOM) em formato CycloneDX. Com todos os *gates* satisfeitos, a *suite* de testes por serviço e os testes de integração do *gateway* foram executados, garantindo que somente código aprovado em qualidade e segurança avance para as etapas de publicação e *deploy*. Este fluxo automatizado é fundamental para a agilidade e a segurança no desenvolvimento de software, como enfatizado por Cherukuri (2024) e Matthias e Kane (2015), pois garante que as entregas sejam consistentes e livres de vulnerabilidades conhecidas. A geração de SBOM, em particular, oferece uma transparência sem precedentes sobre os componentes de software utilizados, o que é vital para a gestão de riscos e a conformidade regulatória em sistemas de saúde.

A publicação de imagens foi realizada pelo *job* ‘*cicd-publish-images*’, condicionado ao êxito de todos os *jobs* antecedentes, operando em matriz paralela sobre os oito microsserviços e autenticando no GitHub Container Registry (GHCR) via GITHUB_TOKEN, publicando cada imagem com duas *tags*: a de rastreabilidade imutável por *commit SHA* e a *tag* operacional *main*. Para cada serviço, o *job* emitiu um artefato de rastreabilidade em JSON contendo nome do serviço, repositório da imagem no GHCR, as duas *tags* publicadas, o *digest* criptográfico da imagem, a referência ao arquivo SBOM correspondente e a URL do *workflow run*. Esses metadados de rastreabilidade são consumidos pelo *job* ‘*cicd-progressive-cd*’, que executa o *script* ‘*progressive_cd_with_rollback.sh*’ para promover as imagens em quatro estágios de liberação (*dev*, *homolog*, *prod-canary* e *prod*), preservando o estado anterior em *prod-rollback* e acionando o *rollback* automático por violação de SLO. Este mecanismo, exercitável por meio do parâmetro ‘*simulate_slo_breach*’ do disparo manual (*workflow_dispatch*), demonstra uma governança robusta sobre o ciclo de vida do software, garantindo que as atualizações sejam controladas e que o sistema possa se recuperar automaticamente de falhas, um requisito crítico para aplicações de saúde.

O *AI Service* foi concebido como um microsserviço independente para isolar o ciclo de vida dos modelos preditivos do restante do prontuário, implementado em Arquitetura Limpa com camadas *domain*, *application* e *infra*, expondo um *endpoint* com contrato versionado e protegido por RBAC via *tokens* JWT. O caso de uso ‘*RunInferenceUseCase*’ executa a inferência em *thread* isolada com *timeout* configurável de 800 ms. Em caso de *timeout* ou falha do *runtime*, um mecanismo de *fallback* determinístico retorna uma resposta degradada, preservando a disponibilidade do prontuário sem propagar erros de latência do modelo para o fluxo clínico. O *provider* de *runtime* configurável, com modos *stub* para testes e *http* para validação ponta a ponta, e a integração da rota de borda ao *gateway-service* com propagação de cabeçalhos de correlação, garantem a rastreabilidade distribuída do contexto clínico. Este design reflete as melhores práticas de MLOps (Kumara et al., 2025), permitindo que os modelos de IA sejam desenvolvidos, testados e implantados de forma independente, sem comprometer a estabilidade do sistema principal. A capacidade de *fallback* é particularmente importante em um contexto clínico, onde a interrupção do serviço pode ter consequências graves.

O *pipeline* MLOps foi construído de forma incremental, com o caso de uso ‘*TrainAndRegisterModelUseCase*’ implementando o ciclo completo de treino, avaliação e promoção governada. O modelo linear é treinado sobre amostras de entrada, avaliado por acurácia nas amostras de validação e promovido apenas se o ‘*quality_score*’ atingir o limiar mínimo configurado (padrão 0,75). Modelos abaixo do critério são bloqueados com resposta HTTP 400 e mensagem explícita de rejeição. O ‘*FileModelRegistry*’ persistiu cada versão promovida em diretório versionado, mantendo o arquivo ‘*active_model.json*’ sempre apontado para a versão ativa. O ‘*FileExperimentTracker*’ registra toda tentativa de treino, aprovada ou rejeitada, com identificador único, decisão de promoção e URI de rastreabilidade, provendo auditabilidade completa do histórico experimental. O *registry* suporta um *provider* externo via HTTP, configurável sem alteração de contrato de API. A *suite* acumulou 27 testes aprovados, confirmados na *run* 23213046569. Este rigoroso processo de governança de modelos é essencial para garantir a confiabilidade e a segurança das sugestões de diagnóstico e alertas de risco clínico fornecidos pelo *AI Service*, especialmente em um ambiente de saúde onde a precisão é crítica.

O ciclo MLOps foi completado com o monitoramento objetivo de *drift* e *rollback* automático. O caso de uso ‘*MonitorDriftAndRollbackUseCase*’, acessível via ‘POST /api/v1/ai/monitoring/drift/check’, calcula o *drift_score* como a distância relativa normalizada entre as médias por *feature* de amostras *baseline* e amostras recentes. Quando o escore supera o limiar configurável (padrão 0,20) e o parâmetro *auto_rollback* está habilitado, o caso de uso invoca ‘*FileModelRegistry.rollback_to_previous*’ substitui o modelo ativo pela versão imediatamente anterior disponível no índice histórico e retorna o campo ‘*rollback_target_version*’ na resposta, fornecendo rastreabilidade explícita da decisão de *rollback*. A ausência de versão anterior resulta em erro funcional com mensagem de diagnóstico, evitando estados inconsistentes no *registry*. A *suite* do *ai-service* atingiu 32 casos de teste aprovados na *run* 23239434931, abrangendo os cenários de *drift* abaixo e acima do limiar, *rollback* executado com verificação de troca de versão ativa e ausência de versão anterior. Em conjunto, as entregas da trilha AI/MLOps estabeleceram uma base técnica que desacopla o ciclo de vida dos modelos preditivos do prontuário eletrônico, permitindo que atualizações, reavaliações de qualidade e respostas a degradações de modelo ocorram de forma independente e auditável. Embora ainda careça de refinamento com um volume maior de dados reais, a arquitetura provou ser capaz de suportar o ciclo de vida do modelo de IA sem interromper os serviços clínicos, atendendo à necessidade de inovação constante apontada por Pinto et al. (2022) para a transformação digital na saúde.

A implantação de conformidade legal do protótipo com a Lei Geral de Proteção de Dados (LGPD) introduziu um domínio de consentimento no microsserviço *patient-service* sob estrita observância da Arquitetura Limpa. A entidade *Consent* encapsula campos para o registro formal do consentimento do titular de dados, com base legal explicitamente declarada a cada operação. A separação entre camadas foi mantida com a definição da interface ‘*ConsentRepositoryInterface*’ no domínio, de modo que a camada de aplicação permaneça independente do mecanismo de persistência. Três casos de uso foram implementados para compor o fluxo completo: ‘*CreateConsentUseCase*’, ‘*RevokeConsentUseCase*’ e ‘*ListPatientConsentsUseCase*’, cada um com responsabilidade única e validações próprias alinhadas às exigências da legislação em vigor. O ‘*CreateConsentUseCase*’ implementou regras de criação defensiva do consentimento, exigindo que ‘*patient_id*’ e ‘*legal_basis*’ sejam não nulos, que ‘*purpose*’ possua ao menos três caracteres descritivos, verificando a existência do paciente no repositório e bloqueando a duplicidade de consentimento ativo para uma mesma finalidade, retornando erro semântico sem necessitar de acesso à camada de infraestrutura. Este rigor no tratamento do consentimento é fundamental para a proteção de dados sensíveis em saúde, conforme preconizado por Pinto et al. (2022).

O ‘*RevokeConsentUseCase*’, por sua vez, valida a pertinência do consentimento ao paciente informado e impede a revogação de registros já revogados; quando autorizada, a operação registra o campo ‘*revoked_at*’ em ISO 8601 com fuso UTC e faz a transição do campo ‘*status*’ de ‘*active*’ para ‘*revoked*’. O ‘*ListPatientConsentsUseCase*’ retorna o histórico completo de consentimentos do paciente ordenado de forma decrescente por ‘*granted_at*’, permitindo ao sistema exibir tanto os consentimentos ativos quanto os revogados, o que viabiliza o exercício do direito de acesso previsto na LGPD. A persistência foi implementada pela classe ‘*ConsentModel*’ via SQLAlchemy, mapeada na tabela ‘*patient_consents*’ com colunas indexadas para ‘*patient_id*’, ‘*status*’ e ‘*granted_at*’, garantindo eficiência nas consultas mais frequentes, com listagem por paciente e filtragem por status. Três *endpoints* foram publicados no *patient-service* e propagados ao *gateway-service* sem alteração de contrato. A verificação de contrato OpenAPI foi incluída no *test suite* do *patient-service*, assegurando que os caminhos de consentimento estejam presentes no esquema publicado e que o *endpoint* de criação exija autenticação via ‘*BearerAuth*’. Os testes de integração do *gateway-service* validaram o fluxo ponta a ponta (criação, consulta e revogação) pela camada de borda, com a *run* 22958751261 confirmando 15 testes aprovados no *patient-service* e 9 no *gateway-service*, todos com status *completed successfully*. A trilha de auditoria de operações de consentimento foi implementada pela função ‘*_emit_consent_audit_event*’, que invoca o ‘*AuditServiceClient*’ com um *payload* estruturado, registrando eventos críticos após cada operação bem-sucedida. A estratégia de *fail-open* foi deliberadamente adotada, garantindo que falhas de comunicação com o microsserviço *audit-service* não bloqueiem o exercício do direito de consentimento pelo titular, preservando a disponibilidade do fluxo clínico.

A conformidade técnica do projeto foi formalmente consolidada por meio de um processo reproduzível de *checklist* de controles. O catálogo declarativo em ‘*experiments/res03/inputs/control_catalog.json*’ define cinco controles distribuídos em dois domínios (‘*lgpd*’ e ‘*security*’), e o *script* ‘*run_res03_compliance.py*’ produz o relatório de cobertura ponderada, resultando em 90,00% de cobertura (4 controles ‘*compliant*’, 1 ‘*partial*’, 0 ‘*non_compliant*’). Os controles ‘LGPD-C01’ (ciclo de vida de consentimento e base legal), ‘SEC-C01’ (*hardening* de segredos), ‘SEC-C02’ (segurança de contêineres e SBOM) e ‘SEC-C03’ (endurecimento de políticas Kubernetes) foram classificados como ‘*compliant*’. O controle ‘SEC-C04’ (arquivamento contínuo de evidências) foi classificado como ‘*partial*’, com o *gap* explícito de definição de cadência periódica de exportação de pacotes de conformidade. A *run* 23249509299 confirmou a execução bem-sucedida de todos os *jobs* do *pipeline*, ratificando o estado de conformidade mínima viável que o protótipo estabelece como base técnica para evoluções futuras de privacidade. Este nível de conformidade é um diferencial importante para sistemas de prontuário eletrônico, que lidam com dados altamente sensíveis e estão sujeitos a rigorosas regulamentações.

A rastreabilidade técnica foi sustentada por versionamento no GitHub e por documentação em múltiplos artefatos. A implementação em nível de requisição foi realizada por meio de um *middleware* de correlação em todos os microsserviços do protótipo, que lê o cabeçalho HTTP X-Request-Id e, na ausência do valor, gera automaticamente um UUID v4. O identificador é então acrescentado ao cabeçalho de resposta e incorporado a todos os eventos de *log* emitidos pelo serviço, que adotam formato JSON estruturado. O serviço de *gateway* foi estendido para propagar o mesmo X-Request-Id a todas as chamadas HTTP realizadas em direção aos serviços, garantindo rastreamento de ponta a ponta ao longo de cadeias de chamadas internas. A conformidade com esse contrato foi verificada pelos testes ‘*test_gateway_echoes_request_id_on_response*’ e ‘*test_http_proxy_forwards_request_id_to_downstream*’, aprovados no *job* de IC ‘*obs-01-correlation-tests*’. Essa capacidade de rastreamento é vital para depuração, auditoria e compreensão do fluxo de dados em um sistema distribuído complexo, como o prontuário eletrônico.

A instrumentação de métricas Prometheus e *tracing* distribuído foi introduzida, com quatro métricas definidas e registradas na camada *infra* de todos os serviços: (1) o contador ‘*http_requests_total*’, rotulado por *service*, *method*, *path* e *status_code*; (2) o histograma ‘*http_request_duration_seconds*’, que permite cálculo de percentis de latência; (3) o *gauge* ‘*http_requests_in_progress*’, que reflete requisições simultâneas em andamento; e (4) o contador ‘*trace_spans_total*’, rotulado por ‘*service*’ e ‘*span_name*’. O *endpoint* ‘*/metrics*’ foi exposto em todos os serviços e declarado como alvo de *scrape*. Para *tracing* distribuído, o *gateway* passou a propagar o cabeçalho *traceparent* (W3C Trace Context) a cada chamada a serviços internos. Os campos ‘*trace_id*’ e ‘*span_id*’ correspondentes foram adicionados a todos os eventos de *log* JSON, permitindo correlação entre *logs* e *spans* sem dependência de coletor externo de *traces*. O contexto de observabilidade (Prometheus, Alertmanager e Grafana) foi provisionado, com *dashboard* e três regras de alerta operacionais definidas: *ServiceDown*, *GatewayHighErrorRate* e *GatewayHighLatencyP95*. O *job* de IC ‘*obs-02-observability-tests*’ validou a consistência da configuração. Essa arquitetura de observabilidade é crucial para a operação de sistemas críticos de saúde, permitindo a detecção proativa de falhas e a garantia da segurança operacional, alinhando-se aos princípios de Engenharia de Confiabilidade de Sites (SRE) (Beyer et al., 2016).

A camada de observabilidade foi completada com a publicação de Indicadores de Nível de Serviço (SLIs) e Objetivos de Nível de Serviço (SLOs) individuais por microsserviço. Três regras de gravação Prometheus foram definidas, calculadas em janela de cinco minutos: (1) ‘*sli:availability:ratio_5m*’, derivada da proporção de requisições com código de status não pertencente à família 5xx; (2) ‘*sli:latency_p95_seconds:5m*’, obtida por ‘*histogram_quantile*’ (0.95, …) sobre o histograma de duração; e (3) ‘*sli:error_rate:ratio_5m*’, complemento aritmético da disponibilidade. Os SLOs operacionais estabelecidos foram: disponibilidade ≥ 99,00%, latência p95 ≤ 0,8s e consumo de orçamento de erro ≤ 1%. Três alertas monitoram o cumprimento desses alvos, disparando após dez minutos de violação contínua. Um *dashboard* Grafana foi provisionado para acompanhamento visual dos SLIs em relação aos SLOs. Os aspectos de correção das configurações Prometheus foram verificados automaticamente. A rastreabilidade experimental foi formalmente endereçada, com um módulo que implementou o cômputo determinístico de cinco métricas de confiabilidade a partir de um cenário declarativo versionado e uma base de incidentes de exemplo. Toda a instrumentação de observabilidade foi configurada na camada *infra* de cada microsserviço, sem acoplamento a entidades de domínio, casos de uso ou portas de domínio, preservando integralmente a Arquitetura Limpa. A cadeia de *gates* de IC garante que nenhuma imagem Docker seja publicada ou promovida sem que a totalidade dos contratos de rastreabilidade, métricas, *tracing* e SLI/SLO tenha sido verificada automaticamente. O conjunto resultante configura uma solução de observabilidade de baixo acoplamento, auditável por *pipeline* de integração contínua e operacionalizável diretamente no ambiente Docker Compose, fundamental para a manutenção de um prontuário eletrônico confiável e seguro.

4. Conclusão

Conclui-se que o objetivo foi atingido, pois o protótipo de prontuário eletrônico, fundamentado em Arquitetura Limpa de microsserviços, conteinerização com Docker e orquestração com Kubernetes, com integração nativa de Inteligência Artificial, evidenciou avanços significativos. A solução demonstrou agilidade, escalabilidade, segurança e governança de dados clínicos sensíveis, conforme proposto. A estruturação dos dados clínicos via RCOP e SOAP garantiu consistência e qualidade semântica, enquanto a arquitetura de microsserviços e o pipeline CI/CD/MLOps asseguraram modularidade, automação de testes e entregas contínuas e auditáveis. A conformidade com a LGPD foi estabelecida, e a observabilidade da aplicação, com métricas e rastreamento distribuído, provou ser robusta para operações críticas.

Contudo, o estudo apresenta limitações importantes. A maturidade heterogênea entre os componentes, especialmente na orquestração e governança via evidência automatizada, sugere áreas de aprimoramento. A extrapolação para cenários de produção em larga escala requer campanhas contínuas de carga e operação prolongada, e os modelos de IA ainda carecem de refinamento com maior volume de dados reais. Futuros estudos devem focar na otimização da governança de microsserviços, na validação em ambientes de produção sob estresse e no aprofundamento da segurança em runtime. Além disso, a definição de cadência periódica para exportação de pacotes de conformidade é uma área promissora para garantir a rastreabilidade contínua e a conformidade legal.

Referências Bibliográficas

Beyer, B.; Jones, C.; Petoff, J.; Murphy, N. R. 2016. Engenharia de Confiabilidade do Google: Como o Google Administra Seus Sistemas de Produção. 1. Novatec, São Paulo, SP, Brasil. Disponível em: <https://books.google.fr/books/about/Engenharia_de_Confiabilidade_do_Google.html?hl=pt-BR&id=dGrgDAAAQBAJ&redir_esc=y>. Acesso em: 04 abr. 2026.

Celuppi, I.C.; Mohr, E.T.B.; Felisberto, M.; Rodrigues, T.S.; Hammes, J.F.; Cunha, C.L.; Wazlawick, R.S.; Dalmarco, E.M. 2024. Dez Anos do Prontuário Eletrônico do Cidadão e-SUS APS: Em busca de um Sistema Único de Saúde eletrônico. Rev Saude Publica 58: 23.

Cherukuri, B.R. 2024. Containerization in cloud computing: comparing Docker and Kubernetes for scalable web applications. International Journal of Science and Research Archive 13(01): 3302-3315.

Genezini, B.S. 2022. Tecnologias, desafios e barreiras para a transformação digital na saúde: uma revisão de literatura. Revista Valore 7(edição especial): 23-38.

Gudelli, V.R. 2023. Containerization Technologies: ECR and Docker for Microservices Architecture. Independent Researcher.

Haddad, A.E.; Lima, N.T. 2024. Saúde Digital no Sistema Único de Saúde (SUS). Interface (Botucatu) 28: e230597.

Kumara, I.; Arts, R.; Nucci, D. D.; Kazman, R.; Heuvel, W. J. V. D.; Tamburri, D. A. 2025. Requirements and Reference Architecture for MLOps: Insights from Industry. TechRxiv. Disponível em: <https://www.techrxiv.org/doi/full/10.36227/techrxiv.21397413.v2>. Acesso em: 08 abr. 2026.

Maia, A.A.C. 2024. Transformação Digital no Serviço de Saúde: Perspetiva do utente. Dissertação de Mestrado em Gestão. Universidade Católica Portuguesa, Porto, Portugal.

Marmentini, L.F.; Kuszera, E.M. 2025. Abordagem de migração de bases relacionais para bases orientadas a documentos apoiada por LLM. In: Proceedings of the 40th Brazilian Symposium on Data Bases, 2025, Fortaleza, CE, Brazil, p. 441-454.

Matthias, K.; Kane, S.P. 2015. Docker: Up and running. O’Reilly Media, Printed, United States of America.

Newman, S. 2022. Criando Microsserviços: Planejando sistemas com componentes menores e mais especializados. 2ed. Novatec Editora, São Paulo, SP, Brasil.

Pinto, H.A.; Santana, J.S.S.; Chioro, A. 2022. Por uma transformação digital que assegure o direito à saúde e à proteção de dados pessoais. Revista Saúde em Redes 8(2): 361-371.

Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy