Colocamos uma camada FHIR na frente dos sistemas que já operam — prontuário, laboratório, imagens, sistemas legados sem API — para que falem o padrão sem serem substituídos, com a conformidade verificada e a operação intacta.
Os sistemas que sustentam a operação clínica raramente podem ser desligados: têm anos de dados, processos amarrados, contratos vigentes e usuários que dependem de que funcionem amanhã às sete. Mas cada vez mais lhes é pedido participar de um intercâmbio para o qual nunca foram desenhados: expor um resultado, notificar uma autoridade, alimentar uma visão consolidada, conectar-se a uma rede. Uma camada FHIR resolve essa tensão traduzindo entre o que o sistema guarda e o que o ecossistema exige, sem tocar no seu banco de dados nem na sua operação. Bem desenhada, compra anos de margem. Mal desenhada, vira o próximo sistema legado: mais uma caixa que ninguém se atreve a abrir.
«Sistemas legados» não diz nada. O que define o trabalho é a forma real da origem e o que se encontra ao abri-la.
Acesso direto ao esquema relacional do sistema clínico, quase sempre somente leitura e contra uma réplica, para não competir com a operação.
Tabelas sem documentação, campos reaproveitados para duas coisas distintas, flags de status que só quem as escreveu entende e regras de negócio que vivem na aplicação, não no modelo.
Mensageria de admissão, pedidos e resultados que já circula entre sistemas e pode ser aproveitada como fonte em vez de construir uma nova extração.
Segmentos Z próprios de cada instalação, campos opcionais usados de forma criativa e o fato de que uma mensagem descreve um evento, não o estado atual do paciente.
CSV, posicionais ou XML que o sistema já gera para relatórios ou para outros consumidores, processados em lote.
Janelas de geração fixas, entregas parciais ou repetidas, codificações de caracteres herdadas e nenhum mecanismo para saber o que mudou desde o arquivo anterior.
Interfaces que o fornecedor já expõe, pensadas para um consumidor específico e com um modelo de dados próprio.
Granularidade que não coincide com a do recurso FHIR, limites de paginação e concorrência não documentados e mudanças de contrato que chegam sem aviso.
Estudos e laudos de imagem, em que o metadado vive no equipamento e no PACS antes de chegar ao registro clínico.
Identificadores de paciente diferentes dos do prontuário, laudos em texto livre dentro do estudo e volumes que tornam inviável materializar sem um critério claro.
Os catálogos que sustentam processos reais mesmo sem viver em nenhum sistema: serviços, profissionais, equivalências de códigos.
Sem controle de versão, sem dono formal e com a verdade repartida entre várias cópias que não coincidem entre si.
É a primeira decisão de arquitetura e a que determina o custo, a latência e a quem dói uma indisponibilidade. Quase nunca é uma escolha pura.
A camada traduz cada consulta contra o sistema de origem, no momento.
Os dados são transformados e carregados em um repositório FHIR que atende às consultas.
Os extremos puros são pouco frequentes. A maioria das camadas que operam bem são combinações deliberadas das duas.
Seis etapas. A primeira decide o que se pode extrair da origem sem arriscar a operação clínica.
Antes de mapear qualquer coisa, entendemos o que o sistema realmente guarda e o que pode ser extraído sem colocar em risco o que já funciona.
Decide-se qual recurso representa cada dado, qual perfil se aplica e de onde vem cada elemento — inclusive aquele que a origem não tem.
Modo de entrega, alcance por domínio, segurança e contrato com os consumidores. Aqui se fixa o que depois é caro mudar.
Implementam-se as transformações, a exposição e o tratamento de erros, com os casos limite tratados como parte do escopo e não como surpresas.
A camada é testada contra os perfis que precisa cumprir, com exemplos válidos e com exemplos que devem ser rejeitados.
Uma camada sem monitoramento falha em silêncio e é descoberta quando alguém reclama de um dado que nunca chegou.
A diferença entre uma camada que passa numa demonstração e uma que sustenta um ecossistema está em detalhes que só aparecem quando um terceiro tenta consumi-la.
Monta-se o JSON à mão até que «pareça certo» e testa-se apenas contra o cliente próprio.
Cada recurso é validado contra o perfil do guia aplicável, em integração contínua, com exemplos que devem passar e exemplos que devem falhar.
Publica-se um CapabilityStatement copiado que declara operações e buscas que ninguém implementou.
Declara-se exatamente o que a camada suporta. Um consumidor precisa conseguir planejar a integração lendo-o, sem descobrir na marra o que funciona.
Implementam-se dois ou três parâmetros e o resto é ignorado em silêncio, devolvendo tudo como se o filtro não existisse.
Os parâmetros declarados são implementados, ou não são declarados. E a paginação é testada com os volumes reais da origem, não com dados de teste.
Usam-se chaves internas como se fossem ids FHIR, referenciam-se recursos que a camada nunca expõe e enviam-se códigos locais sem dizer de onde vêm.
Toda referência resolve ou é declarada lógica, os identificadores de negócio viajam em identifier com o seu system, e todo código leva o seu declarado.
Diante de um problema devolve-se um 500 genérico ou, pior, um 200 com o recurso incompleto.
Os erros são devolvidos como OperationOutcome, com severidade, código e uma localização que diga ao consumidor o que corrigir.
Preenche-se com um valor padrão, uma data inventada ou um código genérico para que o recurso valide.
O ausente é representado como ausente. Quando o guia exige o elemento, usam-se os mecanismos previstos para dados desconhecidos e documenta-se a lacuna, em vez de fabricar o dado.
A camada em operação e tudo o que é preciso para consumi-la, auditá-la e fazê-la evoluir sem nós.
O serviço implantado, com os seus endpoints, a sua segurança e a sua configuração documentada.
Correspondência elemento a elemento entre a origem e os recursos, com as decisões registradas.
Equivalências declaradas entre os códigos locais e as terminologias padrão.
O que a camada realmente suporta: recursos, operações e parâmetros de busca.
Exemplos válidos, exemplos que devem falhar e os testes que rodam a cada mudança.
Métricas de latência, erro e frescor, com alertas sobre o que não pôde ser transformado.
Como autenticar, o que buscar, o que esperar e quais limites a camada tem.
O que se materializa depois, quais domínios seguem e quando convém revisar o modo de entrega.
Infraestrutura FHIR construída sobre sistemas e plataformas que já existiam e continuaram funcionando.
A Meddyg implementou e colocou em produção o primeiro servidor FHIR que receberia 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.
Parte da equipe da Meddyg participou como consultora no desenho e na implementação da infraestrutura que receberia as notificações regionais de ESAVI, junto com o guia que define o seu formato.
Provas de conceito com a Agência Nacional de Governo Digital para validar transações de recursos FHIR sobre a plataforma nacional X-Road, dentro da demonstração funcional de interoperabilidade da Costa Rica.
Assistência técnica para que as equipes do Banco Central da Costa Rica habilitassem a assinatura de recursos FHIR com o formato JAdES dentro do GAUDI, a sua plataforma de assinatura digital e selagem.
Os casos acima são infraestrutura FHIR construída sobre sistemas e plataformas que já operavam. O mesmo método — análise da origem, mapeamento, escolha do modo de entrega e validação de conformidade — é o que aplicamos a uma fachada sobre um prontuário ou um sistema departamental legado.
Todos compartilham a mesma restrição: o sistema de origem não pode ser parado nem substituído no prazo em que é preciso interoperar.
Um sistema clínico que não será substituído e ao qual agora se pede expor dados, notificar ou conectar-se a uma rede.
Produtos que precisam demonstrar capacidade FHIR a clientes e licitações sem refazer o seu banco de dados.
Resultados e laudos que precisam chegar a múltiplos receptores externos com a mesma estrutura e os mesmos códigos.
Sistemas de missão crítica que precisam participar de um ecossistema nacional sem abrir o seu banco nem parar a operação.
Ecossistemas que incorporam participantes cujos sistemas não falam o padrão e precisam de um padrão de conexão repetível.
Intercâmbio com prestadores cujos sistemas expõem formatos próprios e evoluem no seu próprio ritmo.
Se alguma destas situações descreve a sua organização, uma camada FHIR pode resolver o intercâmbio sem colocar em risco o que já funciona.
Uma camada bem desenhada deixa os sistemas atuais participando do ecossistema, sem tocar na sua operação nem hipotecar a rota de modernização.