Tópico 9.2 — Saúde digital global e internacional

Em uma frase: Os princípios deste livro viajam através das fronteiras, mas os sistemas, as leis e os contratos sociais em que aterrissam não; o seu trabalho é, portanto, aprender deliberadamente com outros sistemas de saúde, adotar os padrões globais compartilhados e adaptar todo o resto ao contexto, em vez de copiá-lo.

Por que isso importa na saúde e nos cuidados#

A saúde digital não é uma invenção britânica, e o Reino Unido não é o seu centro de gravidade. O trabalho mais difícil e mais instrutivo do campo está acontecendo na Estônia, na Índia, em Ruanda, no Brasil e no Quênia tanto quanto em Londres ou Leeds. Se vocês lideram a entrega digital no NHS, num Sistema de Cuidados Integrados ou num órgão independente e olham apenas para dentro, resolverão de novo problemas que outros resolveram há uma década e perderão os padrões, as ferramentas e as histórias de advertência que lhes teriam poupado anos.

Isso importa por razões que vão além da eficiência. A saúde é um bem comum global: patógenos, evidências, diretrizes clínicas e — cada vez mais — o software que roda os sistemas de cuidados atravessam todos as fronteiras. As mesmas preocupações de segurança clínica, equidade e confiança pública que definem como vocês trabalham em casa reaparecem, ampliadas, quando dados e tecnologia cruzam jurisdições. Uma ferramenta de monitoramento remoto que é segura numa cidade inglesa bem conectada pode ser insegura onde a conectividade falha; um modelo de consentimento lícito sob o regime de um país pode ser ilícito sob o de outro; um algoritmo treinado numa população pode prejudicar em silêncio outra.

Há também um dever de humildade. O Reino Unido tanto aprende com a saúde global quanto contribui para ela, e o fluxo corre nos dois sentidos. Os países de baixa e média renda (LMICs) foram pioneiros do cuidado móvel em primeiro lugar, de plataformas de agentes comunitários de saúde e de infraestrutura nacional de código aberto que sistemas mais ricos hoje estudam. Tratar a saúde digital internacional como caridade, ou como um cardápio de modelos a levantar e largar na Inglaterra, é a rota mais rápida para o fracasso. Tratá-la como uma disciplina de aprendizado cuidadoso e recíproco é como vocês tornam honesta, e não vazia, a alegação deste livro de "princípios internacionalmente transferíveis".

Conceitos centrais#

Saúde global e saúde digital. A saúde global é o estudo e a prática de melhorar a saúde e alcançar a equidade em saúde para todas as pessoas do mundo. A saúde digital é o uso de tecnologias de informação e comunicação — prontuários, aplicativos, dispositivos, análises e inteligência artificial — para prestar e melhorar o cuidado. A interseção é o tema deste tópico: como as ferramentas e os modos de trabalho digitais se movem, ou deixam de se mover, entre sistemas de saúde que diferem em riqueza, lei, infraestrutura e cultura.

A estratégia global da OMS e os bens públicos digitais. A Organização Mundial da Saúde (OMS) publicou uma Estratégia Global de Saúde Digital que enquadra a saúde digital como habilitadora da saúde universal — muitas vezes chamada de cobertura universal de saúde (UHC), a meta de que todos possam usar os serviços de que precisam sem dificuldade financeira. Uma ideia central é o bem público digital: software de código aberto, dados abertos, padrões abertos e conteúdo aberto — às vezes chamados de "bens globais" — que qualquer país pode adotar e adaptar em vez de comprar sistemas proprietários que não pode possuir nem custear. Ferramentas endossadas pela OMS, como o DHIS2 (uma plataforma de informação em saúde usada em mais de setenta países) e o OpenMRS (um prontuário de código aberto), são exemplos canônicos.

Padrões internacionais de interoperabilidade e de terminologia. As fronteiras são cruzadas não movendo sistemas inteiros, mas compartilhando uma língua comum. Três padrões fazem a maior parte do trabalho: o HL7 Fast Healthcare Interoperability Resources (FHIR) para trocar dados clínicos estruturados; o SNOMED CT, a terminologia clínica internacional governada pela SNOMED International; e a CID-11 (ICD-11) da OMS, a décima primeira revisão da Classificação Internacional de Doenças, usada em todo o mundo para a codificação de mortalidade, morbidade e reembolso. Esse é o vocabulário compartilhado que permite a um prontuário inglês, a um prontuário estoniano e a um relatório estatístico da OMS significarem a mesma coisa. (Ver Tópico 4.3 — Interoperabilidade e padrões de dados.)

mSaúde e salto de etapas (leapfrogging). A mSaúde (mHealth) — saúde móvel — é a prestação de serviços e informações de saúde por telefones celulares. Em muitos LMICs, o cuidado móvel em primeiro lugar não é um rebaixamento, mas o canal principal, e ilustra o salto de etapas: pular uma geração de infraestrutura (aqui, a conectividade fixa e a TI hospitalar pesada em papel) para ir direto a uma tecnologia mais nova. A lição para sistemas mais ricos não é que os celulares são baratos, mas que a restrição gera projetos — offline em primeiro lugar, baixa largura de banda, alternativa por SMS — mais resilientes do que muitas alternativas "avançadas".

Soberania de dados e fluxos transfronteiriços de dados. A soberania de dados é o princípio de que os dados são governados pelas leis da jurisdição em que são coletados ou armazenados. Os dados de saúde estão entre as categorias mais estritamente controladas, e os regimes jurídicos divergem bruscamente: o Regulamento Geral de Proteção de Dados (GDPR) do Reino Unido e da UE repousa em bases legais e direitos dos titulares de dados; o Health Insurance Portability and Accountability Act (HIPAA) dos EUA protege um conjunto mais estreito de "entidades cobertas"; o Artificial Intelligence Act da UE e o Regulamento de Dispositivos Médicos da UE (Regulamento (UE) 2017/745) impõem controles escalonados por risco ao software como dispositivo médico. Uma ferramenta em conformidade num regime pode ser ilícita em outro, e os fluxos transfronteiriços de dados exigem um mecanismo jurídico explícito de transferência, e não uma suposição.

Aprender entre sistemas de saúde. Os países conduzem experimentos naturais que vocês não podem conduzir em casa. A Estônia construiu uma camada governamental de troca de dados e prontuários quase universais; a Índia construiu um conjunto de componentes abertos de "pilha" digital para identidade, pagamentos e saúde sobre os quais atores privados e públicos constroem; Ruanda escalou o sangue entregue por drones e plataformas de agentes comunitários de saúde. Cada um é fonte de lições transferíveis e de especificidades intransferíveis — e distinguir umas das outras é a habilidade central que este tópico ensina.

Boas práticas#

1. Adotem os padrões globais antes de inventar os locais. Adotem por padrão o HL7 FHIR, o SNOMED CT e a CID-11 para troca, terminologia e classificação, porque são a língua compartilhada que torna possível qualquer futura comparação internacional, colaboração ou troca de fornecedor. Todo sistema de códigos local sob medida que vocês criam é um muro que mais tarde terão de demolir. Onde existir um perfil nacional — os perfis UK Core FHIR, por exemplo —, usem-no e contribuam de volta em vez de bifurcar em silêncio.

2. Prefiram bens públicos digitais e padrões abertos ao aprisionamento proprietário. Ao adquirir ou construir, deem grande peso às opções de código aberto, abertamente especificadas e governadas de forma independente, porque preservam a capacidade de possuir, auditar e sair. Os bens públicos digitais como o DHIS2 e o OpenMRS são comprovados em escala nacional e livres de renda de licença; mesmo onde vocês escolherem um produto comercial, insistam em padrões abertos e portabilidade de dados para jamais serem reféns. (Ver Tópico 9.0 — Colaboração com organizações parceiras sobre projetar contra o aprisionamento ao fornecedor.)

3. Aprendam com outros sistemas como disciplina, com donos nomeados e tradução honesta. Tratem a aprendizagem internacional como trabalho de verdade: designem alguém para estudar um sistema comparador, entender por que ele funciona lá — suas leis, seu financiamento, sua identidade digital e sua confiança social — e separar o princípio transferível da especificidade local. Uma visita de estudo que volta com "devemos copiar a Estônia" fracassou; uma que volta com "aqui está o problema de identidade e consentimento que a Estônia resolveu, e aqui está como nossas restrições diferem" teve sucesso.

4. Jamais levantem e larguem um modelo nacional. O sucesso da Estônia repousa numa população pequena, numa identidade digital nacional obrigatória e num pacto de alta confiança construído ao longo de duas décadas; a pilha de saúde da Índia repousa numa arquitetura público-privada particular e num sistema de identidade de um bilhão de pessoas. Extrair um componente e largá-lo na Inglaterra ignora o andaime que o torna seguro. Adotem o padrão e reconstruam a implementação para o seu contexto jurídico, demográfico e de confiança.

5. Mapeiem o regime jurídico antes de qualquer dado cruzar uma fronteira. Estabeleçam, por escrito, a base legal, o mecanismo de transferência e as relações de controlador antes que os dados de saúde saiam de uma jurisdição — não presumam que um fluxo lícito no Reino Unido é lícito adiante. Onde vocês operam entre o GDPR, o HIPAA, o AI Act da UE e o Regulamento de Dispositivos Médicos da UE, tratem o regime aplicável mais estrito como o piso e registrem como a soberania de dados é respeitada para toda população cujos dados vocês detêm.

6. Projetem para as condições realistas mais duras, e não para a demonstração. Tomem emprestada a disciplina dos LMICs de offline em primeiro lugar, baixa largura de banda e degradação elegante, porque ela produz serviços que sobrevivem à falha de conectividade, ao dispositivo antigo e ao ponto cego rural também em casa. Uma ferramenta que só funciona em fibra rápida numa clínica não é resiliente; a equidade e a segurança clínica melhoram quando se presume que a rede falhará.

7. Ancorem tudo na equidade e na cobertura universal e verifiquem quem é excluído. Perguntem, para cada implantação, se ela estreita ou amplia a distância — entre países e dentro da sua própria população —, porque um serviço digital que atende aos conectados e confiantes deixando outros para trás é um passo para longe da cobertura universal, e não rumo a ela. Meçam a adesão por grupo, e não apenas no agregado. (Isto se liga ao Tópico 1.9 — Inclusão digital e acessibilidade.)

8. Governem a IA e as tecnologias emergentes pela mais alta barra internacional aplicável. Os algoritmos treinados numa população podem prejudicar outra, e o terreno regulatório está mudando depressa sob o AI Act da UE e arcabouços comparáveis. Documentem a proveniência dos dados de treinamento, validem na sua própria população e alinhem a governança ao regime mais estrito que vocês tocam, e não ao mais permissivo. (Ver Tópico 8.4 — Governança de IA e de tecnologias emergentes.)

Perguntas para discutir com a sua equipe#

1. Quando admiramos o sistema de saúde digital de outro país, conseguimos articular exatamente quais partes são transferíveis ao nosso contexto e quais dependem de condições que não compartilhamos? Esta pergunta protege contra o erro mais comum e mais caro da aprendizagem internacional: confundir uma implementação específica com um princípio geral. A troca de dados quase sem atrito da Estônia depende de uma identidade digital nacional obrigatória e de um pacto social de alta confiança; a pilha de saúde da Índia depende de uma arquitetura público-privada particular e de um sistema de identidade em escala populacional; ambos levaram muitos anos e condições políticas específicas. A sua equipe deve ser capaz de nomear o problema subjacente que cada sistema resolveu — identidade segura, troca consentida de dados, alcance de populações remotas — e depois descrever com honestidade como o seu regime jurídico, o seu financiamento, a sua demografia e a sua confiança pública diferem. A discussão deve trazer à tona que andaime um modelo emprestado precisaria para ser seguro aqui e se esse andaime é realista. Uma resposta madura separa o padrão que vale adotar da implementação que não pode viajar e trata "devemos simplesmente copiá-los" como um sinal de alerta, e não como um plano. Faz também a pergunta recíproca: o que o nosso sistema faz que outros poderiam aprender, o que aguça a humildade que todo o exercício exige.

2. Antes de qualquer dado de saúde cruzar uma fronteira — inclusive para uma região de nuvem, um fornecedor ou um parceiro de pesquisa em outro país —, sabemos a base legal, o mecanismo de transferência e que regime o governa? Os fluxos transfronteiriços de dados são onde as boas intenções encontram a lei dura, e a falha costuma ser silenciosa: os dados passam por uma região de nuvem ou pela central de suporte estrangeira de um fornecedor sem que ninguém estabeleça um mecanismo jurídico de transferência. A sua equipe deve distinguir claramente entre o mundo do GDPR do Reino Unido e da UE, de bases legais e direitos dos titulares de dados, o modelo HIPAA dos EUA, que protege um conjunto mais estreito de entidades cobertas, e os controles emergentes do AI Act da UE e do Regulamento de Dispositivos Médicos para software clínico. A discussão deve cobrir concretamente a soberania de dados: para cada população cujos dados vocês detêm, a lei de que nação a governa e vocês a estão honrando? Deve também enfrentar as armadilhas práticas — um produto SaaS "global" com equipe de suporte em outro continente, um fornecedor de IA cujo modelo é retreinado com os seus dados, uma colaboração de pesquisa que pressupõe uma reciprocidade que a lei não concede. Uma resposta forte trata o regime aplicável mais estrito como o piso, registra por escrito o mecanismo de transferência antes que os dados se movam e consegue nomear quem responde quando um regulador pergunta.

3. Estamos projetando para a conectividade, os dispositivos e a alfabetização de todos que servimos, ou apenas para o usuário confiante e conectado da demonstração? Boa parte da tecnologia de saúde mais resiliente do mundo foi construída sob restrição — energia intermitente, baixa largura de banda, telefones básicos ou compartilhados, várias línguas — e essa disciplina produz serviços que também atendem aos excluídos dentro de um sistema rico. A sua equipe deve examinar se seus projetos pressupõem conectividade rápida, dispositivos modernos e alta alfabetização digital e o que acontece com um paciente quando essas suposições falham. O que está em jogo em termos de equidade é direto: um serviço que só funciona para os bem conectados amplia a distância que pretendia fechar, tanto entre países quanto dentro da sua própria população, afastando-se da cobertura universal em vez de rumar a ela. A conversa deve olhar o comportamento offline em primeiro lugar, a degradação elegante, a alternativa por SMS ou voz, a acessibilidade de língua e de nível de leitura e se a adesão é medida por grupo e não apenas no agregado. Deve também perguntar se vocês estão tomando emprestados padrões de projeto comprovados dos LMICs ou os ignorando por uma sensação de que "não são para nós". Uma boa resposta consegue apontar escolhas específicas de projeto que protegem o usuário mais difícil de alcançar e métricas que revelariam cedo a exclusão.

4. Quando construímos ou compramos, estamos escolhendo bens públicos digitais e padrões abertos que podemos possuir, auditar e deixar — ou aceitando em silêncio o aprisionamento proprietário porque é conveniente hoje? A escolha entre uma plataforma aberta e governada de forma independente e uma proprietária e polida é onde a soberania de longo prazo de um sistema é ganha ou perdida, e a pressão quase sempre corre rumo à opção fechada, porque ela faz melhor na demonstração e exige menos de vocês agora. A sua equipe deve ser capaz de dizer por que ponderou as opções de código aberto, abertamente especificadas e portáteis numa decisão recente específica — ou admitir honestamente que não o fez. Os bens públicos digitais como o DHIS2 e o OpenMRS são comprovados em escala nacional e livres de renda de licença, mas exigem capacidade interna e um compromisso de manutenção que um contrato comercial parece remover; essa concessão é real e deve ser debatida, e não descartada. A discussão deve cobrir também a saída concretamente: se este fornecedor dobrasse o preço ou deixasse o mercado em três anos, vocês conseguiriam mover os seus dados e o seu serviço, e testaram essa alegação em vez de confiar numa cláusula contratual? Uma resposta madura trata a portabilidade de dados e uma saída documentada como inegociáveis mesmo quando o produto escolhido é comercial e consegue nomear o que a organização teria de construir ou financiar para tornar viável a opção aberta.

5. Estamos tratando os parceiros de menor renda como fontes de projeto comprovado e colaboradores genuínos, ou como destinatários da nossa caridade — e conseguimos dizer com clareza o que contribuímos de volta? A saúde digital internacional carrega uma assimetria de poder persistente, e o enquadramento de caridade — em que um sistema rico "ajuda" um LMIC doando tecnologia — é ao mesmo tempo condescendente e uma rota segura para o fracasso, porque ignora que o cuidado móvel em primeiro lugar, as plataformas de agentes comunitários de saúde e a infraestrutura nacional aberta foram muitas vezes pioneiros precisamente nesses sistemas. A sua equipe deve examinar uma parceria real ou proposta e perguntar quem é dono do resultado, quem o mantém e se o fluxo de aprendizado genuinamente corre nos dois sentidos. As tensões são concretas: uma plataforma doada que se torna uma dependência sem financiamento, uma "colaboração" que extrai dados ou validação de uma população parceira sem benefício recíproco, uma visita de estudo que leva lições mas nada oferece em troca. Deve também enfrentar a humildade recíproca que o tópico exige — o que o seu próprio sistema faz que outros poderiam aprender e vocês o compartilham tão abertamente quanto esperam que eles compartilhem? Uma resposta honesta consegue apontar arranjos de copropriedade, contribuições de volta a núcleos abertos compartilhados e uma parceria que ainda faria sentido se a direção do financiamento fosse invertida.

6. Para qualquer algoritmo ou modelo de IA que implantamos, conseguimos mostrar que foi validado na população a que de fato servirá e governado pelo regime mais estrito que tocamos, e não pelo mais permissivo? Um modelo treinado e validado numa população pode prejudicar em silêncio outra, e a saúde digital internacional multiplica esse risco porque as ferramentas, os dados de treinamento e os fornecedores cruzam as fronteiras mais depressa do que a evidência de sua segurança. A sua equipe deve ser capaz de distinguir a proveniência de um modelo — de onde vieram seus dados de treinamento, contra qual população foi validado — da população que agora se pede que ele sirva e tratar qualquer lacuna como uma preocupação viva de segurança clínica, e não um detalhe de papelada. O terreno regulatório está mudando depressa e de forma desigual: o AI Act da UE impõe controles escalonados por risco ao software clínico de alto risco, o Regulamento de Dispositivos Médicos da UE trata muitos algoritmos como software como dispositivo médico e a lei do Reino Unido é mais leve em alguns pontos, o que cria a tentação de governar pelo regime mais permissivo que se consiga defender. A discussão deve trazer à tona quem é responsável pela revalidação, como as atualizações do modelo e o retreinamento pelo fornecedor são controlados e se a organização sequer documenta a proveniência dos dados de treinamento. Uma resposta forte revalida na população local antes da implantação, alinha a governança à mais alta barra internacional aplicável para manter opções abertas e consegue explicar essa escolha a um regulador sem constrangimento.

Na prática: um exemplo de saúde e cuidados#

Um órgão independente fictício inglês, o "National Remote Monitoring Service", é encarregado de adquirir uma plataforma para o monitoramento domiciliar de condições crônicas, com a opção de colaborar num núcleo de código aberto compartilhado com ministérios da saúde de dois países parceiros — um vizinho de alta renda da UE, outro um LMIC que escala agentes comunitários de saúde.

A tentação é comprar uma plataforma comercial polida e tratar o ângulo internacional como uma cortesia diplomática. A equipe resiste. Parte dos padrões: qualquer plataforma deve trocar dados em HL7 FHIR, codificar observações em SNOMED CT e classificar condições na CID-11, para que os dados signifiquem a mesma coisa nos três países e o serviço não fique preso a um fornecedor. Seleciona um núcleo de bem público digital (uma pilha derivada do OpenMRS) ao lado de duas opções comerciais, pontuando cada uma pela portabilidade de dados e pela saída tanto quanto pelas funcionalidades.

Quanto à lei, a equipe mapeia os regimes antes que um byte se mova. Os dados dos pacientes ingleses permanecem sob o UK GDPR numa região de nuvem do Reino Unido; a colaboração do parceiro da UE corre sob o GDPR da UE com um mecanismo de transferência documentado; nenhum dado pessoal flui de ou para o parceiro LMIC — apenas indicadores agregados desidentificados e o próprio código aberto, que é um bem público digital e não carrega risco de soberania. O algoritmo de monitoramento é tratado como software como dispositivo médico e validado separadamente na população inglesa, porque um modelo ajustado em outro lugar não pode ser presumido seguro aqui; sua governança é alinhada às expectativas de alto risco do AI Act da UE mesmo onde a lei do Reino Unido é mais leve, para manter opções abertas.

O projeto toma emprestado do parceiro LMIC em vez de lhe dar lições. A plataforma de agentes comunitários de saúde de lá é offline em primeiro lugar, com alternativa por SMS, e o serviço inglês adota o mesmo padrão — o que acaba importando para os pontos cegos rurais e os pacientes mais velhos em casa. Dezoito meses depois, o núcleo de código aberto compartilhado é mantido em conjunto, cada país opera a própria implantação lícita e nenhum parceiro copiou por atacado o modelo de outro. A equipe inglesa consegue mostrar a um regulador exatamente quais dados estão sob qual lei, e o ministério do LMIC tem uma plataforma copossuída, e não uma dependência doada.

Perspectivas setoriais#

Startup#

Uma startup de saúde digital frequentemente chega aos mercados internacionais antes de estar pronta para a complexidade jurídica que eles carregam. A vantagem é real — os padrões globais significam que um produto nativo em FHIR e codificado em SNOMED pode, em princípio, vender em qualquer lugar —, mas cada novo país traz um regime diferente (GDPR, HIPAA, o AI Act da UE, regras nacionais de dispositivos médicos) e uma expectativa diferente de soberania de dados. Construam para o regime mais estrito em que vocês plausivelmente pretendem entrar, mantenham os dados pessoais na região por projeto e tratem a compatibilidade com bens públicos digitais como uma vantagem de mercado e não como uma ameaça. Os fundadores que saltam etapas rumo a mercados de LMICs devem fazer parceria genuína e localizar com honestidade, porque uma ferramenta lançada de paraquedas sem propriedade local raramente sobrevive ao contato com a infraestrutura real.

Pequena empresa#

Um pequeno prestador estabelecido — um consultório de clínica geral, uma farmácia comunitária, uma casa de repouso, uma clínica de unidade única ou um pequeno fornecedor de tecnologia em saúde que já passou da fase de startup — carrega os mesmos deveres transfronteiriços e de padrões de um órgão nacional, mas com uma fração da capacidade para cumpri-los. Raramente tem equipe dedicada de TI ou de governança da informação, mas ainda pode usar um produto hospedado em nuvem cujos dados estão em outra jurisdição ou uma ferramenta de diagnóstico construída sobre um modelo validado em outro lugar. A proteção prática é apoiar-se nos padrões e na disciplina do regime mais estrito como piso em vez de tentar raciocinar cada caso do zero: peçam aos fornecedores que mostrem suporte a FHIR e SNOMED CT, residência de dados na região e uma base legal documentada antes de assinar e tratem a portabilidade de dados como questão de sobrevivência, porque vocês não podem se dar ao luxo de ficar presos a um fornecedor que falha. Tomar emprestados padrões comprovados de offline em primeiro lugar e baixa largura de banda é muitas vezes um encaixe melhor aqui do que perseguir o produto corporativo polido, porque a resiliência importa mais do que as funcionalidades quando não há ninguém a quem recorrer quando a rede cai. Onde já existir um perfil nacional ou um bem público digital, adotem-no em vez de encomendar algo sob medida que jamais conseguiriam manter.

Grande organização#

Um grande órgão do NHS, sistema de cuidados integrados ou fornecedor multinacional tem a escala para moldar os padrões e não apenas segui-los, e a obrigação de fazê-lo com responsabilidade. O risco da grande organização é uma aquisição global que centraliza em silêncio os dados entre jurisdições, criando problemas de soberania e aprisionamento que emergem anos depois na mesa de um regulador. Tornem obrigatórios os padrões abertos e a portabilidade de dados em todo contrato, insistam numa residência de dados clara na região e usem o peso de compra para fortalecer o ecossistema de bens públicos digitais em vez de matá-lo de fome. Quando aprendem com outros sistemas, dotem a aprendizagem de recursos adequadamente — visitas de estudo com donos nomeados e relatórios honestos — em vez de colecionar anedotas.

Governo#

Um órgão nacional ou supranacional define as regras dentro das quais todos os demais trabalham; suas escolhas sobre padrões, soberania e abertura ecoam, portanto, por uma década. Os governos devem tornar obrigatórios os padrões internacionais (FHIR, SNOMED CT, CID-11), investir em bens públicos digitais e contribuir para eles como questão de resiliência e de valor e legislar regimes claros e exequíveis para dados transfronteiriços e IA em vez de deixá-los a negociações caso a caso. Detêm também o papel diplomático: alinhar-se à Estratégia Global de Saúde Digital da OMS, apoiar os sistemas dos LMICs como parceiros e não como destinatários e fazer avançar a cobertura universal de saúde como meta compartilhada. A responsabilização é pública e internacional, de modo que as decisões devem ser transparentes e defensáveis, e não meramente convenientes. (Ver Tópico 9.1 — Trabalho com governos locais e nacionais.)

Modos de falha comuns#

• Levantar e largar. Copiar o modelo de outro país sem o andaime jurídico, de identidade e de confiança. Correção: adotem o padrão, reconstruam a implementação para o seu contexto.
• Inventar padrões locais. Construir sistemas de códigos sob medida em vez de usar FHIR, SNOMED CT e CID-11. Correção: adotem primeiro os padrões globais e usem perfis nacionais onde existirem.
• Vazamento silencioso de dados entre fronteiras. Dados circulando por regiões de nuvem ou centrais de suporte no exterior sem mecanismo de transferência. Correção: mapeiem o regime e registrem a base legal antes de qualquer dado se mover.
• Aprisionamento proprietário vestido de conveniência. Comprar uma plataforma fechada que vocês não podem possuir, auditar nem deixar. Correção: deem peso aos bens públicos digitais e tornem obrigatória a portabilidade de dados.
• Enquadramento de caridade do trabalho com LMICs. Tratar parceiros de menor renda como destinatários e não como fontes de projeto comprovado. Correção: façam parceria recíproca e adotem seus padrões resilientes de offline em primeiro lugar.
• Presumir que um algoritmo viaja. Implantar um modelo validado em outra população. Correção: revalidem na sua própria população e governem pelo regime aplicável mais estrito.
• Projetar só para a demonstração. Presumir conectividade rápida, dispositivos modernos e alta alfabetização. Correção: projetem offline em primeiro lugar, com degradação elegante, e meçam a adesão por grupo.

Modelo de maturidade#

Lista de verificação#

• A troca, a terminologia e a classificação usam HL7 FHIR, SNOMED CT e CID-11, com perfis nacionais onde existirem.
• As opções de bens públicos digitais e padrões abertos foram fortemente ponderadas nas decisões de construir ou comprar.
• Todo produto e contrato de fornecedor garante a portabilidade de dados e uma saída documentada.
• A base legal, a residência de dados e o mecanismo de transferência são registrados antes de qualquer dado de saúde cruzar uma fronteira.
• Os regimes aplicáveis (GDPR do Reino Unido/UE, HIPAA, AI Act da UE, Regulamento de Dispositivos Médicos da UE) são identificados, com o mais estrito tratado como piso.
• Qualquer modelo de IA é validado na sua própria população e governado pela mais alta barra internacional aplicável.
• A aprendizagem internacional tem um dono nomeado que separa princípios transferíveis de especificidades intransferíveis.
• Nenhum modelo nacional foi copiado por atacado sem reconstruir sua implementação para o contexto local.
• Os serviços degradam com elegância — offline em primeiro lugar, baixa largura de banda, canais alternativos — para as condições realistas mais duras.
• A adesão e os resultados são medidos por grupo para detectar a exclusão, a serviço da cobertura universal e da equidade.

Fontes-chave#

• Organização Mundial da Saúde — Global Strategy on Digital Health 2020–2025 (who.int).
• Organização Mundial da Saúde — Classification of digital health interventions e CID-11 (who.int).
• Digital Public Goods Alliance — DPG Standard e registro (digitalpublicgoods.net).
• HL7 International — especificação FHIR (hl7.org/fhir); SNOMED International — SNOMED CT (snomed.org).
• Estônia — e-Estonia e X-Road / Nordic Institute for Interoperability Solutions (e-estonia.com; niis.org).
• Ministry of Health & Family Welfare / National Health Authority (Índia) — Ayushman Bharat Digital Mission (abdm.gov.in).
• Comissão Europeia — Regulamento (UE) 2017/745 sobre dispositivos médicos; Regulamento (UE) 2024/1689 (Artificial Intelligence Act).
• Information Commissioner's Office — orientações sobre transferências internacionais sob o UK GDPR (ico.org.uk).
• The Lancet & Financial Times Commission — Governing health futures 2030 (thelancet.com).

Referências#

1. Global health — Wikipedia — https://en.wikipedia.org/wiki/Global_health
2. Digital health — Wikipedia — https://en.wikipedia.org/wiki/Digital_health
3. World Health Organization — Wikipedia — https://en.wikipedia.org/wiki/World_Health_Organization
4. Digital public goods — Wikipedia — https://en.wikipedia.org/wiki/Digital_public_goods
5. Universal health care — Wikipedia — https://en.wikipedia.org/wiki/Universal_health_care
6. Fast Healthcare Interoperability Resources (FHIR) — Wikipedia — https://en.wikipedia.org/wiki/Fast_Healthcare_Interoperability_Resources
7. SNOMED CT — Wikipedia — https://en.wikipedia.org/wiki/SNOMED_CT
8. ICD-11 — Wikipedia — https://en.wikipedia.org/wiki/ICD-11
9. mHealth — Wikipedia — https://en.wikipedia.org/wiki/MHealth
10. Leapfrogging — Wikipedia — https://en.wikipedia.org/wiki/Leapfrogging
11. Data sovereignty — Wikipedia — https://en.wikipedia.org/wiki/Data_sovereignty
12. Artificial Intelligence Act — Wikipedia — https://en.wikipedia.org/wiki/Artificial_Intelligence_Act
13. Regulation (EU) 2017/745 (EU Medical Device Regulation) — Wikipedia — https://en.wikipedia.org/wiki/Regulation_(EU)_2017/745
14. Health Insurance Portability and Accountability Act (HIPAA) — Wikipedia — https://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act
15. General Data Protection Regulation — Wikipedia — https://en.wikipedia.org/wiki/General_Data_Protection_Regulation
16. Global Strategy on Digital Health 2020–2025 — World Health Organization — https://www.who.int/publications/i/item/9789240020924
17. The DPG Standard — Digital Public Goods Alliance — https://www.digitalpublicgoods.net/standard
18. Ayushman Bharat Digital Mission — National Health Authority, Government of India — https://abdm.gov.in/