Antes de comprar um componente é preciso saber onde ele vive, quem responde por ele e o que atravessa cada fronteira. Definimos arquiteturas de saúde digital que podem ser operadas, auditadas e conectadas a uma rede nacional sem serem refeitas.
Quase nenhuma instituição começa do zero. Tem um prontuário, um laboratório, um PACS, um portal e uma fila de projetos pendentes. O problema aparece quando é preciso incorporar peças novas —um índice mestre de pacientes, um catálogo de produtos, a validação de profissionais e estabelecimentos— e ninguém consegue dizer com precisão onde elas devem viver, quem as mantém, o que expõem para fora nem como se conectam à plataforma nacional de intercâmbio. Nosso trabalho é fechar essas decisões e deixá-las escritas, com detalhe suficiente para contratar, construir e auditar.
Quatro planos, e nenhum deles se resolve no seguinte. Quando uma organização pula direto para o plano tecnológico, termina com componentes corretos que ninguém sabe operar e pelos quais ninguém responde.
Quem decide, quem aprova e como se muda o que foi decidido?
O que se decide aquiO que significa cada dado e qual é a sua fonte de verdade?
O que se decide aquiQuais componentes existem e que contrato cada um cumpre?
O que se decide aquiOnde roda, como é protegido e como se sustenta?
O que se decide aquiNão é uma lista de compras. Cada componente resolve um problema concreto e arrasta uma decisão que costuma ficar sem dono até que algum projeto a feche por conta própria.
Resolve se dois registros de dois sistemas diferentes são a mesma pessoa, e mantém o vínculo entre seus identificadores.
Se a correspondência é determinística sobre o identificador nacional, probabilística, ou ambas com uma fila de revisão humana; e qual sistema fica como dono do identificador mestre.
Dá um identificador estável a cada medicamento, insumo ou dispositivo, para que a prescrição, a dispensação e o estoque falem do mesmo produto.
Se adota o catálogo nacional, um internacional ou o próprio, e como mapear o que já está carregado nos sistemas sem perder o histórico.
Confirma que quem assina um ato clínico está habilitado a fazê-lo, no momento em que o faz.
Se a validação é consultada em linha na fonte autoritativa —o conselho profissional ou o registro nacional— ou replicada localmente, e o que acontece quando essa fonte não responde.
Identifica de forma única cada unidade, serviço e sede, que é o que permite rotear, reportar e auditar por local.
Qual codificação se usa —o cadastro sanitário nacional ou outro— e quem atualiza o registro quando uma unidade abre, muda de serviço ou fecha.
Publica e valida os CodeSystem, ValueSet e ConceptMap que os sistemas usam, em vez de deixar cada tabela de códigos embutida em cada aplicação.
Se opera um servidor terminológico próprio ou consome o nacional, e como versionar um ValueSet sem invalidar os dados já capturados.
Guarda o que precisa ser guardado —recursos FHIR, documentos, imagens— com uma política de retenção e um modo testado de recuperá-lo. É a fonte de verdade e, por isso, nunca é exposto diretamente.
Qual conteúdo é fonte de verdade aqui e qual é cópia de outro sistema, porque disso depende quem pode escrever nele e o que se perde se ele cair.
Registra quem acessou o quê, quando e com que justificativa. O ponto de exposição emite o evento, mas o registro é guardado aqui e em modo somente-anexar: quem chegar à fronteira não deve conseguir reescrever a evidência do próprio acesso.
Se a auditoria vive em cada sistema ou é centralizada, e por quanto tempo se conserva um registro que pode vir a ser prova.
Determina quem pede, em nome de quem pede e a que tem direito de acessar — tanto para pessoas quanto para sistemas.
O que se resolve com identidade de sistema e o que exige identidade da pessoa usuária, e onde fica registrado o consentimento quando o dado sai da instituição.
A cópia conforme ao perfil que responde às consultas externas: apenas o que já foi publicado, materializado a partir da fonte de verdade e reconstruível a qualquer momento.
O que se materializa, com que frescor, e como se reconstrói a partir da fonte quando o perfil muda. Se essa cópia virar a única, deixou de ser uma cópia.
É a única porta pela qual a instituição publica e consome informação para fora: gateway de API, camada FHIR, nó da rede nacional.
O que se expõe, sob qual perfil e para quem; e se essa porta armazena dados ou apenas os deixa passar.
A pergunta mais adiada é onde vive cada componente. E não é uma pergunta de infraestrutura: define o que pode ser exposto, o que precisa ser replicado e quais controles são obrigatórios em cada ponto.
O espaço onde a sua instituição é mais um membro entre outros: prestadores, registros do Estado e a plataforma nacional de intercâmbio. Você não a administra, mas decide como se apresenta a ela.
Nada se publica aqui sem um contrato explícito: perfil, terminologia, identidade do solicitante e registro da transação.
A única zona alcançável de fora. Aqui vivem os componentes que falam com o exterior, e apenas esses. Tudo o que passa por aqui é autenticado, autorizado e registrado.
Nada do que vive aqui é fonte de verdade. A DMZ traduz, roteia e publica cópias reconstruíveis do que já foi autorizado, sem acesso direto às bases internas.
O prontuário, os repositórios, o índice mestre, a terminologia e a auditoria. Nada disso é exposto diretamente; só se alcança através da DMZ.
Nenhum sistema externo chega até aqui, e nenhum componente interno sai para a internet por conta própria.
Uma fronteira não se define por onde está o firewall, mas pelo que se permite atravessá-la e sob qual prova.
Consultas e respostas dos componentes internos que atendem uma solicitação externa, já reduzidas ao que essa solicitação precisa.
Conexões iniciadas de dentro, contas de serviço com privilégio mínimo, credenciais distintas por ambiente e resultado registrado.
Recursos que cumprem um perfil publicado, com sua terminologia vinculada, e apenas para solicitantes identificados e autorizados.
Autenticação mútua entre sistemas, autorização por caso de uso e não por sistema inteiro, assinatura e carimbo quando o dado tem valor probatório, e registro de cada mensagem.
Na Costa Rica, a plataforma nacional de intercâmbio é o X-Road. Encaixá-lo na arquitetura muda menos do que se teme e mais do que se planeja.
A instituição instala seu próprio security server. É o único componente que fala com a rede nacional; nenhum dos seus outros sistemas o faz diretamente.
Cada organização e cada subsistema se registra e recebe certificados. A rede sabe quem pergunta antes de a pergunta chegar até você.
A plataforma assina e carimba o que a atravessa. Isso resolve o não repúdio, mas também obriga a decidir o que se envia: o que atravessa fica registrado.
Não há uma base nacional que guarde tudo. Cada instituição continua dona da sua informação e responde consultas pontuais.
A Meddyg realiza provas de conceito junto à Agência Nacional de Governo Digital para validar transações de recursos FHIR sobre o X-Road, dentro da demonstração funcional de interoperabilidade da Costa Rica. Em outros países muda o nome da plataforma; as decisões de arquitetura que é preciso fechar —onde fica o nó, o que se expõe, quem autoriza e o que se registra— são as mesmas.
Trabalhamos sobre modelos já comprovados em outros países e ecossistemas. Para a sua instituição isso são três coisas concretas: menos meses discutindo o que já está resolvido, uma arquitetura que o resto do ecossistema reconhece, e requisitos que você pode colocar em um edital e exigir.
Construir por dentro o que o país já vai oferecer, e acabar pagando duas vezes.
Dizemos o que convém reutilizar e o que construir, e deixamos escritos os requisitos de padrões abertos e portabilidade a exigir em cada contratação. É o que evita descobrir três anos depois que você não consegue trocar de fornecedor.
Meio ano discutindo como se chama cada componente e quem responde por ele.
Sua arquitetura fica nomeada com o mesmo vocabulário que os demais atores do ecossistema usam. Quando for hora de integrar, a conversa começa no ponto certo e não no glossário.
Descobrir durante a implementação que o componente já comprado não consegue cumprir o perfil nacional.
Transformamos o perfil que o guia nacional exige em um requisito de arquitetura verificável, antes da compra. Se um produto não cumpre, você fica sabendo enquanto ainda pode trocar de produto.
Cada equipe interpretar a norma clínica à sua maneira e você terminar com cinco versões do mesmo processo.
Descemos a norma até o sistema por uma rota já comprovada: do documento aos processos e aos dados, daí ao perfil FHIR, e daí a algo testável antes da produção. Se o seu domínio já tem um DAK publicado, você economiza a etapa mais lenta do projeto.
O risco não aparece quando se adotam padrões; aparece quando se expõe um sistema que foi projetado para viver dentro de uma rede fechada. Estas são as barreiras que definimos junto com a arquitetura, não depois.
Publica-se uma API sobre o prontuário inteiro porque era mais rápido do que definir o intercâmbio.
Expõe-se um caso de uso por vez, com seu perfil e seu alcance. O que não está em um contrato publicado não pode ser pedido.
Qualquer sistema que já está dentro pode consultar qualquer coisa, porque a rede é considerada segura.
Autenticação de sistema e de pessoa usuária em cada chamada, permissões por caso de uso e credenciais distintas por ambiente.
Quando é preciso responder quem acessou um prontuário, a informação está espalhada em registros que já rotacionaram.
O registro de acesso é projetado como componente, com retenção definida e consulta própria, desde o primeiro intercâmbio.
Devolve-se o recurso inteiro porque o consumidor «filtra depois», e essa cópia fica fora de controle.
Minimização desde o desenho: cada intercâmbio define seu conjunto mínimo e a resposta é recortada no ponto de exposição.
Um documento clínico intercambiado não consegue provar quem o emitiu nem que não foi alterado.
Assinatura e carimbo nos intercâmbios que exigem. A Meddyg prestou assistência técnica ao Banco Central da Costa Rica para habilitar a assinatura JAdES de recursos FHIR.
Testa-se contra produção porque o ambiente de testes não tem dados parecidos com os reais.
Ambientes separados com dados sintéticos ou anonimizados, promoção controlada e segredos distintos em cada um.
Cada fase fecha uma pergunta e deixa um artefato. Uma arquitetura sem artefatos não pode ser contratada, construída nem auditada.
O que existe hoje, quem opera e o que realmente se intercambia?
Inventariamos sistemas, integrações vivas, fluxos clínicos e contratos vigentes. Não o que o diagrama diz: o que está rodando.
O que a organização precisa conseguir fazer e hoje não consegue?
Priorizamos os intercâmbios por valor clínico e viabilidade, e os escrevemos como requisitos funcionais e não funcionais. Quando existe um DAK da OMS para o domínio, tomamos como ponto de partida.
Quais componentes existem no estado desejado e que contrato cada um cumpre?
Definimos o catálogo de componentes, suas responsabilidades e seus limites, com os perfis e terminologias que cada um deve cumprir.
Onde vive cada componente e o que atravessa cada fronteira?
Posicionamos cada componente na sua zona, definimos os controles de cada fronteira e o ponto único de exposição para a rede nacional.
Quem responde por cada componente e como se muda o que foi decidido?
Atribuímos donos, definimos o registro de decisões de arquitetura e o caminho para aprovar uma exceção sem que a exceção vire a norma.
Em que ordem se constrói e o que pode entrar em produção primeiro?
Ordenamos o trabalho em incrementos que podem ser liberados e medidos, começando pelo que resolve um intercâmbio real e não pelo que é maior.
Está sendo construído o que foi definido?
Revisamos as entregas do fornecedor contra os contratos definidos e ajustamos a arquitetura quando a realidade obriga, com a decisão registrada.
Documentos que servem para contratar, construir e auditar — não para apresentar uma vez e arquivar.
O estado atual, a arquitetura alvo, os componentes e seus contratos, no nível de detalhe que um edital exige.
O que vive em cada zona, o que atravessa cada fronteira e sob qual controle, e como a organização se conecta à plataforma nacional.
Cada componente com sua responsabilidade, seu dono, seu contrato e a decisão de comprar, construir ou reutilizar.
Cada decisão com seu contexto, as alternativas avaliadas e a consequência assumida. É o que evita rediscutir o mesmo todo ano.
Controles por fronteira, matriz de acesso, requisitos de auditoria e de assinatura, redigidos para poderem ser exigidos contratualmente.
Incrementos liberáveis, dependências, riscos e a ordem em que convém construir para que algo entre em produção logo.
Arquitetura não é o diagrama que se entrega: é o que continua funcionando três anos depois. Estes são projetos em que a Meddyg definiu ou construiu a arquitetura que ficou em operação.
Provas de conceito junto à Agência Nacional de Governo Digital para validar transações de recursos FHIR sobre a plataforma nacional, dentro da demonstração funcional de interoperabilidade da Costa Rica: intercâmbio seguro entre sistemas diferentes, sem centralizar os dados.
Desenho, implantação em produção e operação do primeiro servidor FHIR que recebe as notificações de doenças de notificação compulsória, vacinas e resultados de laboratório do EDUS/CCSS, e posteriormente de outros estabelecimentos de saúde.
Assistência técnica ao Banco Central da Costa Rica para integrar o formato JAdES dentro do GAUDI, sua plataforma de assinatura digital e carimbo, habilitando a assinatura de recursos FHIR.
Implementação de arquiteturas de PACS e estações de trabalho de diagnóstico para o intercâmbio de imagens médicas sob o padrão DICOM, em hospitais públicos do Serviço Nacional de Saúde da República Dominicana.
Os modelos que citamos nesta página são o método com que trabalhamos, não clientes. Quando um caso corresponde a um cliente, dizemos o nome — como os quatro acima.
O serviço atende tanto quem precisa definir a arquitetura pela primeira vez quanto quem já a tem escrita e precisa conectá-la ao ecossistema.
Institutos, ministérios e hospitais que devem incorporar componentes nacionais e conectar-se à plataforma de intercâmbio do país.
Hospitais, clínicas e laboratórios que precisam participar do ecossistema sem refazer seus sistemas nem abrir sua rede.
Equipes que já têm o mandato de definir a arquitetura e precisam fechar decisões e deixá-las defensáveis.
Responsáveis que devem habilitar o intercâmbio sem ampliar a superfície de exposição da instituição.
Fabricantes que devem cumprir um perfil nacional e demonstrar como seu produto se encaixa na arquitetura do cliente.
Iniciativas que precisam de uma arquitetura de referência comum para que cada instituição não resolva à sua maneira.
Se você reconhece três ou mais, o problema não é tecnológico: são decisões em aberto que cada projeto está fechando por conta própria, de forma diferente.
Definimos a arquitetura de que a sua organização precisa para operar hoje e conectar-se amanhã, com as decisões escritas, os componentes posicionados e as barreiras de segurança colocadas desde o desenho.