Analisamos, revisamos e redesenhamos o modelo de dados da sua organização para que a informação clínica preserve o seu significado ao passar de um sistema para outro — com uma estratégia de terminologias, um modelo-alvo e um plano de migração que não interrompe a operação.
Quando dois sistemas não conseguem se entender, quase nunca é porque a mensagem não chegou. É porque cada um guarda o mesmo fato clínico de forma diferente: um campo de texto livre onde o outro tem um código, uma tabela própria de diagnósticos, uma data que às vezes é a da coleta e às vezes a do laudo, um identificador que se repete entre estabelecimentos. Padronizar o intercâmbio sem organizar o modelo apenas transfere o problema para a camada seguinte. Este serviço atua onde o problema nasce: analisamos o modelo atual, revisamos o seu desenho, acordamos até onde vai o alcance e propomos um modelo-alvo com as terminologias, as regras de normalização e o plano de migração necessários para chegar até ele.
As cinco existem mesmo que ninguém as tenha decidido. Quando uma é pulada, a decisão é tomada assim mesmo — por quem está desenvolvendo, no momento de desenvolver, e sem deixar registro.
Quem é dono de cada dado, quem aprova uma mudança de modelo, com que cadência se versiona e como uma decisão é documentada para continuar compreensível daqui a três anos.
Cada projeto cria a sua própria variante do mesmo conceito, ninguém consegue reverter uma mudança e entender o modelo vira trabalho de arqueologia.
O que exatamente cada dado significa: a qual terminologia se vincula, com que força de binding, em quais unidades se expressa e o que se faz com os valores que não têm código.
Os sistemas compartilham estruturas idênticas e dados incomparáveis. A análise agrega coisas distintas sob o mesmo nome e ninguém percebe.
Como a informação é estruturada: o que é recurso e o que é atributo, como as observações se aninham, quais cardinalidades se aplicam e o que exatamente significa um valor ausente.
Cada integração precisa do seu próprio tradutor, nenhum mapeamento é reaproveitável e o custo de conectar cresce a cada novo sistema.
Como se persiste e se consulta: esquema físico, índices, versionamento de registros, historização e o desempenho tanto da consulta clínica quanto da analítica.
O modelo está correto no papel e a consulta de que o clínico precisa leva minutos, então alguém cria uma tabela paralela e o modelo único deixa de ser único.
Quais regras transformam o dado real — o que já está carregado, com duplicidades, abreviações e texto livre — em dado conforme ao modelo, e o que se faz com aquilo que não encaixa.
O modelo novo convive com anos de dados que não o cumprem, e a migração se revela inviável quando uma data já foi prometida.
Cinco etapas. A primeira olha os dados reais, não apenas o diagrama.
Levantamos o que existe: esquemas, dicionários, tabelas de códigos próprias, formulários e as estruturas que cada sistema de fato usa. E perfilamos os dados já carregados — distribuições, nulos, texto livre, duplicidades — porque o modelo documentado e o modelo em produção raramente coincidem.
SaídasAvaliamos o modelo contra critérios explícitos em vez de opiniões: expressividade clínica, rastreabilidade de quem registrou o quê e quando, extensibilidade diante de um domínio novo, consultabilidade para a clínica e para a análise, e capacidade de sustentar o intercâmbio de que a organização precisa.
SaídasAcordamos até onde ele vai: quais domínios clínicos entram agora, com que granularidade, o que é representado de forma estruturada e o que é aceito como texto por enquanto. Quando o domínio já tem um DAK das SMART Guidelines da OMS, seus elementos de dados essenciais são o ponto de partida do escopo, em vez de uma lista construída do zero. Um alcance honesto é o que torna todo o resto executável.
SaídasDesenhamos o modelo de destino e o expressamos nos artefatos da abordagem escolhida: arquétipos e templates, perfis e extensões, ou um modelo canônico interno. Com identificadores, terminologias e regras de conformidade decididos, não pendentes.
SaídasUm modelo sem processo de mudança volta a divergir no primeiro projeto urgente. Definimos quem aprova uma alteração, como se versiona, como se comunica e qual compatibilidade se garante entre versões.
SaídasopenEHR e FHIR às vezes são apresentados como alternativas excludentes. Não são: resolvem problemas diferentes e, em mais de um ecossistema, vale usar os dois.
Modela e persiste a informação clínica com o modelo separado do software: os arquétipos definem o conjunto máximo de dados de um conceito clínico, os templates o restringem para um uso concreto e as consultas são escritas contra o modelo, não contra um esquema físico. O conteúdo é governado pelos clínicos, não pela equipe de desenvolvimento.
ArtefatosModela como a informação sai de um sistema e entra em outro: recursos com granularidade pensada para o transporte, perfis que os restringem a um caso de uso concreto e APIs com buscas e operações definidas. É o contrato com o mundo externo.
ArtefatosO modelo comum que a organização usa entre os seus próprios sistemas, a sua análise e os seus processos. Nem sempre precisa ser um padrão externo, mas precisa ser um só: é o ponto em que as diferenças entre fontes são resolvidas antes de expor qualquer coisa para fora.
ArtefatosEscolher um não exclui os outros. O caminho habitual vai do modelo clínico ao contrato de intercâmbio, e o modelo canônico é o que evita que cada ponta acabe falando uma língua própria.
Baixar o SNOMED CT não é adotá-lo. Cada terminologia obriga a decisões sobre alcance, manutenção, licenciamento e versionamento que, se não forem tomadas no início, acabam sendo tomadas sozinhas e mal.
Vocabulário clínico de referência para diagnósticos, procedimentos, achados e contexto clínico.
Decisões que obriga a tomarIdentificação de observações, exames de laboratório, painéis e variáveis clínicas.
Decisões que obriga a tomarClassificação para reporte estatístico, morbidade, mortalidade e obrigações regulatórias.
Decisões que obriga a tomarOs catálogos próprios do país — estabelecimentos, serviços, profissionais — e os ValueSets que as guias nacionais impõem.
Decisões que obriga a tomarOs catálogos que a organização já tem e que não vão desaparecer de um dia para o outro.
Decisões que obriga a tomarTrabalhamos com essas terminologias como marco técnico de referência. O licenciamento e a afiliação, quando aplicáveis, cabem à organização ou ao país que as adota.
Um modelo novo não serve de nada se os dados que já existem não chegarem até ele. A migração é desenhada como um projeto próprio, com fases, critérios de aceite e uma saída de emergência.
Mede-se o que existe de fato: volumes, qualidade, texto livre, duplicidades, valores fora de faixa e dados que nunca cumpriram a regra que diziam cumprir.
Definem-se as transformações e os critérios de qualidade: o que se limpa, o que se deduplica, o que se enriquece com terminologia e o que se marca como não conforme.
Mapeia-se campo a campo e código a código, declarando o tipo de equivalência de cada mapeamento. O que não mapeia é documentado como exceção; não é descartado em silêncio.
O modelo antigo e o novo operam ao mesmo tempo por um período acordado, com escrita dupla ou visões de compatibilidade, para que nenhum sistema dependa de uma única data de corte.
O histórico é migrado em lotes e validado por equivalência: reconciliação de volumes, comparação de agregados e revisão clínica por amostragem. A validação é o que autoriza o corte.
Corta-se o fluxo para o modelo antigo e ele é desativado quando se demonstra que ninguém mais o lê, preservando a rastreabilidade de cada transformação para explicar depois a origem de um dado.
Documentos usados durante o redesenho e depois dele — não um relatório que é arquivado.
Inventário de fontes, dicionário consolidado e perfilamento dos dados reais.
Achados por camada, riscos, dívida de modelo e as decisões ainda pendentes.
Domínios, granularidade e o que fica explicitamente fora desta iteração.
O modelo lógico e os artefatos da abordagem escolhida: arquétipos e templates, perfis ou modelo canônico.
Bindings por elemento e equivalências declaradas com os códigos locais.
Transformações, critérios de qualidade e tratamento explícito das exceções.
Sequência, critérios de aceite, convivência e condições para autorizar o corte.
Versionamento, processo de mudança e responsáveis por domínio.
O trabalho de modelagem e terminologia por trás de guias de implementação que hoje estão publicados e em uso.
Perfis e ValueSets das terminologias clínicas compartilhadas pelo ecossistema de saúde do país: decidir qual vocabulário se aplica a cada elemento, com que força de binding e quem mantém o catálogo.
Estrutura e regras de conformidade para notificar resultados: o que se representa como observação, como os exames são codificados e como unidades, valores de referência e interpretação viajam junto.
Perfis para o intercâmbio de relatórios de estudos de imagem: a tradução entre o que o equipamento produz e o que o registro clínico precisa.
Notificação de doenças de notificação compulsória, vacinas e resultados de laboratório: alinhar o que o sistema de origem registra com o que o guia nacional exige receber, e recebê-lo no primeiro servidor FHIR nacional.
Estes casos correspondem ao trabalho de modelagem e terminologia dentro de guias de implementação nacionais. A abordagem openEHR faz parte do serviço e é avaliada caso a caso; não aparece aqui porque não fez parte destes projetos.
O que muda de uma organização para outra não é o método, e sim quanto custa continuar sem um modelo acordado.
Vários sistemas clínicos que registram o mesmo fato de formas distintas. O modelo comum é o que permite uma visão única do paciente.
Ecossistemas que precisam acordar o modelo antes de exigir conformidade, para que o guia nacional se apoie em uma decisão e não em uma suposição.
Catálogos próprios que precisam ser mapeados para LOINC ou para códigos nacionais sem perder o detalhe de que o laboratório precisa para operar.
Produtos cujo esquema cresceu por acúmulo e que agora precisam expor dados conformes sem refazer a base do zero.
Equipes que dependem de o dado significar o mesmo em todas as fontes para que um indicador seja comparável entre estabelecimentos.
Intercâmbio com múltiplos prestadores em que cada um codifica à sua maneira e a equivalência precisa ser declarada, não suposta.
Se você reconhece várias destas situações, o problema não está nas interfaces: está no modelo que existe por baixo delas.
Antes de expor APIs ou se comprometer com um guia nacional, vale saber o que o modelo realmente representa e o que falta para chegar aonde se precisa.