Desenhamos, perfilamos, publicamos e mantemos guias de implementação FHIR — do alcance institucional de uma organização a especificações nacionais e regionais — em R4 e R5, com regras de conformidade que os implementadores podem validar por conta própria.
O FHIR define recursos deliberadamente flexíveis para servir a qualquer país e a qualquer domínio clínico. Essa mesma flexibilidade explica por que dois sistemas «compatíveis com FHIR» podem ser incapazes de se entender. Um guia de implementação fecha essa distância: fixa quais recursos são usados, quais elementos são obrigatórios, quais terminologias se aplicam, quais identificadores são reconhecidos, como a informação é buscada e o que um sistema precisa cumprir para ser considerado conforme. Na Meddyg construímos esses guias como especificações executáveis — perfis, ValueSets, exemplos, regras e testes publicados como pacote instalável — e não como documentos que cada implementador interpreta à sua maneira.
O método é o mesmo. O que muda é quem governa a especificação, quantos implementadores dependem dela e quanto custa errar.
Uma organização e os sistemas que operam sob sua autoridade.
Uma jurisdição inteira, ou vários países que precisam reportar sob um mesmo formato.
Os dois alcances compartilham o mesmo pipeline técnico e os mesmos artefatos de conformidade. A diferença está na governança, na política de versões e no custo de uma mudança incompatível.
Sete etapas. Cada uma produz artefatos que são validados e publicados — não entregáveis intermediários que ficam dentro de um documento.
Um guia de implementação não nasce de um documento em branco. A OMS define uma escada de cinco níveis para descer de uma norma clínica narrativa até um software que a executa e pode ser testado, e um guia FHIR é exatamente o nível L3. Quando o domínio já tem um DAK publicado —o nível L2—, suas personas, processos, elementos de dados, indicadores e requisitos são o insumo de que parte o perfilamento, em vez de serem reconstruídos do zero em cada país.
Usamos as SMART Guidelines como modelo de referência e método de trabalho. Não é um projeto entregue à OMS: é o modelo com que organizamos o trabalho quando existe uma norma clínica por trás do guia.
Definimos quais intercâmbios o guia cobre e quais ficam explicitamente de fora. Atores, cenários, gatilhos e o percurso completo de cada transação, de ponta a ponta.
Os casos nascem de dores concretas: um resultado que não chega, um atendimento duplicado, um relatório que alguém monta à mão todo mês.
Os casos nascem de um mandato: uma norma de notificação compulsória, um programa de saúde pública ou um compromisso regional de reporte.
Antes de perfilar, acordamos o que cada dado significa. Modelamos a informação clínica do domínio e decidimos qual recurso FHIR a representa — e quando a resposta certa é uma extensão em vez de forçar um recurso.
O mapeamento é feito contra os modelos que já existem nos sistemas da organização, incluindo suas particularidades históricas.
O mapeamento é feito contra a norma e contra o core nacional, para que o novo guia dependa dele em vez de redefini-lo por conta própria.
Restringimos os recursos ao que o caso de uso exige: cardinalidades, must-support, slicing, tipos permitidos e invariantes expressas em FHIRPath. As extensões são definidas somente quando o dado não cabe no recurso base.
Perfilamento apertado: dá para restringir com firmeza porque o universo de sistemas é conhecido e delimitado.
Perfilamento prudente: cada obrigatoriedade deixa algum implementador de fora, então o que se exige hoje fica separado do que se anuncia para o próximo release.
Compartilhar estruturas não é compartilhar significado. Definimos os vocabulários de cada elemento, a força do binding e as equivalências com os códigos locais já em uso.
Resolvem-se as tabelas de códigos próprias de cada sistema e sua equivalência com o vocabulário padrão, sem obrigar a substituí-las de imediato.
Define-se quem publica e mantém os ValueSets nacionais e sob quais condições se distribuem vocabulários licenciados, como o SNOMED CT®.
O guia declara o que um sistema conforme precisa ser capaz de fazer: quais operações expõe, quais buscas suporta, quais perfis aceita e o que deve rejeitar. Sem isso, «conforme» não é verificável por ninguém.
A conformidade vira cláusula contratual e critério de aceite para receber uma entrega de um fornecedor.
A conformidade vira requisito de habilitação: sem ela, um sistema não se conecta ao ecossistema.
Escrevemos o guia em FSH e o compilamos com SUSHI e o IG Publisher, dentro de um pipeline de integração contínua que executa o relatório de QA a cada mudança. A saída é um site navegável e um pacote instalável.
É publicado em um domínio da organização e entregue aos fornecedores como parte da documentação de integração.
É publicado com jurisdição declarada, histórico de versões e presença em registros públicos, com a URL canônica como identidade permanente de cada artefato.
Um guia que ninguém consegue implementar não serve. Validamos os exemplos com o validador oficial, preparamos material e testes para os implementadores, acompanhamos as primeiras integrações e deixamos o ciclo de mudanças aberto.
Acompanhamos a primeira integração real até que ela valide de ponta a ponta em produção, e não apenas no ambiente de testes.
Organizam-se testes de conectividade e connectathons, e o suporte aos implementadores é sustentado durante todo o período de adoção.
A pergunta certa não é qual versão é melhor, e sim com quem o seu sistema precisa conversar e por quanto tempo. Trabalhamos nas duas e, quando o ecossistema exige, sustentamos ambas ao mesmo tempo.
A versão com a maior base instalada.
Recursos mais maduros para domínios em que o R4 ficava curto.
Quase nenhum ecossistema troca de versão de um dia para o outro. O normal é que R4 e R5 convivam por anos, e essa convivência se projeta em vez de improvisar.
Tudo o que um implementador precisa para construir, validar e demonstrar conformidade sem depender de uma reunião conosco.
O guia compilado e versionado, instalável com as ferramentas padrão do ecossistema.
StructureDefinitions com cardinalidades, must-support, slicing e invariantes documentadas.
Terminologias, força de binding e equivalências entre os códigos locais e os padrões.
Instâncias que passam no validador, incluindo casos limite e exemplos que devem falhar.
O que um sistema conforme expõe: operações, parâmetros de busca e perfis aceitos.
Repositório com FSH, configuração e integração contínua, para que o guia siga vivo sem nós.
Regras de compatibilidade, numeração e transição entre releases do guia.
Documentação inicial, plano de testes e acompanhamento das primeiras integrações.
Especificações publicadas e em uso, não exercícios de laboratório. Cada uma define o contrato de conformidade de um intercâmbio que acontece hoje.
Os recursos FHIR base e seus perfis fundamentais para o intercâmbio clínico nacional: o guia do qual todos os outros dependem.
Papel da MeddygColaboração no desenho, perfilamento e publicação.
Perfis e ValueSets das terminologias clínicas compartilhadas pelo ecossistema de saúde do país.
Papel da MeddygColaboração no desenho, perfilamento e publicação.
Estrutura e regras de conformidade para notificar resultados de laboratório por meio de FHIR.
Papel da MeddygColaboração no desenho, perfilamento e publicação.
Perfis para o intercâmbio de relatórios de estudos de imagens médicas.
Papel da MeddygColaboração no desenho, perfilamento e publicação.
Guia para a notificação de doenças de notificação compulsória, vacinas e resultados de laboratório. A Meddyg implementou e colocou em produção o primeiro servidor FHIR que receberia essas notificações do EDUS/CCSS e, posteriormente, de outros estabelecimentos de saúde.
Papel da MeddygParticipação no desenho, perfilamento e publicação do guia, e implementação da infraestrutura receptora.
Primeiro guia de implementação HL7® FHIR® para a notificação regional de ESAVI (Eventos Supostamente Atribuíveis à Vacinação e Imunização), junto com o desenho da infraestrutura que receberia essas notificações.
Papel da MeddygParte da equipe da Meddyg participou como consultora no desenho do guia e no desenho e implementação da infraestrutura receptora.
Integração do formato JAdES dentro do GAUDI, a plataforma de assinatura digital e selagem do BCCR. Não é um guia em si: é exatamente o tipo de regra de conformidade — como se assina e como se verifica um recurso — que um guia precisa declarar para que o não repúdio seja exigível.
Papel da MeddygAssistência técnica para que as equipes do BCCR habilitassem a assinatura de recursos FHIR.
Os guias acima são de alcance nacional e regional. O mesmo método — modelo de informação, perfis, terminologia, conformidade e publicação — é o que aplicamos em guias institucionais, com ciclos mais curtos e governança interna.
O método é o mesmo; o que muda é o que está em jogo quando a especificação fica ambígua.
Ministérios e órgãos reguladores que precisam normatizar como o país reporta e troca informação. O guia transforma a norma escrita em algo verificável.
Sistemas de cobertura nacional com muitos estabelecimentos e fornecedores. O guia define o que se exige de cada um, sem negociar caso a caso.
Iniciativas em que vários países precisam reportar sob um mesmo formato sem abrir mão das particularidades de cada um.
Ecossistemas que incorporam novos participantes e precisam de um contrato técnico repetível, em vez de um acordo diferente por conexão.
Organizações com vários sistemas clínicos que querem parar de negociar o formato a cada nova integração.
Resultados e laudos que precisam chegar a múltiplos receptores externos com a mesma estrutura e os mesmos códigos.
Produtos que precisam demonstrar conformidade com um guia nacional, ou construir o seu para ordenar a integração com os clientes.
Se alguma destas situações descreve a sua organização, um guia de implementação é a forma de transformar o acordo em uma regra que se pode validar.
Um guia de implementação transforma normas e acordos em regras que um sistema pode validar antes de entrar em produção.