5 Aprendizados de uma Integração de EHR Transfronteiriça
Passei meses conectando registros de pacientes entre dois países diferentes. Trabalhei com uma Analista de Negócios Líder com dez anos de experiência clínica. A abordagem dela mudou minha visão sobre software de saúde.
Aqui estão cinco lições desse projeto.
- O mapeamento de terminologia é mais difícil do que o mapeamento de dados
Engenheiros frequentemente tratam a integração como um problema de esquema. Você mapeia o campo A para o campo B e termina. Na saúde, isso falha.
Um sistema usava CID-10 e o outro usava CID-11. Eles não se mapeiam de forma limpa. Um sistema usava LOINC para exames laboratoriais, enquanto o outro usava códigos internos antigos.
Nossa BA construiu um mapeamento de conceitos (crosswalk) antes de escrevermos o código. Ela mapeou códigos locais para um conjunto padrão como o SNOMED CT. Sem isso, teríamos corrompido o significado clínico.
O mapeamento de campos incorreto cria valores errados. O mapeamento de terminologia incorreto cria valores plausíveis, mas clinicamente errados. O segundo é muito mais perigoso.
- Leis de dados moldam a arquitetura precocemente
Eu pensei que projetaríamos o modelo de dados primeiro e lidaríamos com a conformidade depois. Eu estava errado.
Dados de pacientes cruzando fronteiras esbarram em múltiplas leis, como HIPAA ou GDPR. Alguns países proíbem que dados de saúde saiam de seus territórios.
Nossa BA trabalhou com as equipes jurídicas logo no início. Ela decidiu quais campos poderiam ser replicados e quais precisavam de desidentificação.
Isso mudou nossa arquitetura. Construímos uma camada de consulta federada em vez de um único banco de dados replicado. Adicionamos tags de classificação de dados diretamente ao nosso esquema.
Traga especialistas em conformidade e uma BA para a reunião antes de projetar seu modelo de dados.
- Padrões não são suficientes
Ambos os sistemas suportavam HL7. No entanto, um usava HL7 v2 e o outro usava FHIR R4. Eles não conseguiam se comunicar sem uma camada de tradução.
Mesmo dentro do FHIR, encontramos incompatibilidades de perfis. Ambos os sistemas alegavam conformidade, mas usavam guias de implementação diferentes.
Não assuma que a integração é fácil só porque um sistema suporta um padrão. Sempre pergunte sobre a versão e o perfil específicos. Reserve tempo para uma camada de adaptador.
- Diagramas de fluxo de trabalho capturam casos de borda ocultos
Eu costumava ver diagramas de fluxo de trabalho como documentação extra. Eu estava errado.
Nossa BA mapeou as transferências de pacientes em detalhes. Ela analisou o que acontece quando um paciente se muda no meio do tratamento ou quando um resultado de laboratório chega após a alta.
Estes não são casos de borda em um hospital. Eles acontecem todos os dias.
Esses diagramas mudaram nosso modelo de dados. Adicionamos um conceito de episódio de cuidado para rastrear o atendimento contínuo em ambos os sistemas.
- Construa um glossário compartilhado precocemente
Palavras como "atendimento" (encounter) ou "alta" (discharge) significam coisas diferentes em sistemas diferentes. Perdemos tempo porque as equipes interpretavam os termos de forma distinta.
Nossa BA construiu um glossário compartilhado. Cada stakeholder revisou e concordou com essas definições. Referenciamos este documento em cada requisito.
Assuma que todo termo de domínio é ambíguo. Defina-o em um documento assinado por ambas as partes.
Resumo
Uma BA forte faz mais do que escrever tickets. Eles atuam como arquitetos para restrições regulatórias e significado clínico. Se você constrói software complexo, não veja esse papel como um custo adicional. Ele evita que o sucesso técnico se torne um fracasso clínico.
Comunidade de aprendizado opcional: https://t.me/GyaanSetuAi