openEHR: Archetypes, Templates e Modelagem Dual na Prática

# openEHR: Archetypes, Templates e Modelagem Dual na Prática

Enquanto FHIR domina a conversação sobre interoperabilidade em saúde no Brasil e no mundo, o openEHR oferece uma abordagem fundamentalmente diferente para modelagem de dados clínicos. Entender as duas filosofias — e quando cada uma se aplica — é essencial para quem trabalha com informática em saúde.

O que é openEHR

openEHR é uma especificação aberta para sistemas de informação em saúde, mantida pela openEHR Foundation. Sua premissa central é a separação completa entre informação e conhecimento — o que se chama de "modelagem dual" (two-level modelling).

Na prática: O padrão FHIR democratiza a interoperabilidade em saúde com APIs modernas e acessíveis — mas implementar bem exige mapeamento semântico cuidadoso e validação de conformidade.

Diferente de um banco de dados tradicional onde o schema é fixo, no openEHR o "schema clínico" é definido por profissionais de saúde (através de archetypes) e pode evoluir sem alterar o software.

Modelagem dual: o conceito central

Nível 1: Modelo de Referência (Reference Model)

O modelo de referência define estruturas genéricas de informação:

• Composition (documento clínico)
• Section (seção dentro de documento)
• Entry (registro clínico — Observation, Evaluation, Instruction, Action)
• Cluster (agrupamento de dados)
• Element (dado individual)
• Data types (quantidade, texto, data, ordinal, etc.)

Esse modelo é estável e raramente muda. O software é construído sobre ele.

Nível 2: Archetypes (Arquétipos)

Archetypes definem o significado clínico das estruturas. São modelos formais de conceitos clínicos, criados por profissionais de saúde e validados por comunidade.

Exemplos:

• Archetype de pressão arterial: define que contém sistólica, diastólica, posição do paciente, tamanho do manguito
• Archetype de diagnóstico: define que contém nome da condição, data de início, severidade, certeza
• Archetype de prescrição de medicamento: define dose, via, frequência, duração

Cada archetype é:

• Identificado por um código único (ex: openEHR-EHR-OBSERVATION.blood_pressure.v2)
• Definido em ADL (Archetype Definition Language)
• Versionado e governado publicamente
• Reutilizável em qualquer sistema openEHR

A separação na prática

Um desenvolvedor pode construir um sistema de prontuário completo sem conhecer detalhes clínicos. O modelo de referência fornece as estruturas. Quando clínicos definem novos archetypes (ex: uma nova escala de avaliação), o sistema os incorpora sem mudança de código — apenas configuração.

Templates: composição de archetypes

Um template combina múltiplos archetypes para formar um formulário clínico completo:

• Template de "Avaliação de enfermagem na admissão" combina archetypes de:
• Sinais vitais (pressão arterial + frequência cardíaca + temperatura + SpO2)
• Avaliação de dor
• Risco de queda
• Avaliação de pele (Braden)
• Alergias

Templates podem restringir archetypes:

• Tornar campos opcionais em obrigatórios
• Limitar opções de listas (de todas as posições possíveis, aceitar apenas "sentado" e "deitado")
• Ocultar campos não relevantes para aquele contexto

Archetypes na prática: Clinical Knowledge Manager (CKM)

A comunidade openEHR mantém o CKM (Clinical Knowledge Manager), um repositório público de archetypes revisados por pares. O processo de governança inclui:

1. Proposta de novo archetype por qualquer membro da comunidade
2. Revisão por especialistas clínicos e de informática
3. Ciclos de comentários e refinamento
4. Publicação com status (draft, team review, published)
5. Versionamento quando alterado

Archetypes publicados no CKM são multilíngues — o mesmo conceito clínico com terminologia em inglês, português, espanhol, alemão e outros idiomas.

Comparação com FHIR

Filosofia

Quando usar openEHR

• Sistemas de prontuário eletrônico que precisam de flexibilidade clínica sem desenvolvimento
• Repositórios de dados clínicos de longo prazo (décadas)
• Ambientes onde clínicos precisam definir novos formulários sem equipe de TI
• Instituições com múltiplas especialidades e formulários complexos

Quando usar FHIR

• Integração entre sistemas heterogêneos
• APIs públicas para acesso a dados
• Comunicação com sistemas externos (laboratórios, operadoras, governo)
• Aplicativos de terceiros que precisam consumir dados

Complementaridade

openEHR e FHIR não são mutuamente excludentes. Uma arquitetura comum é:

• openEHR como repositório de dados clínicos (EHR)
• FHIR como camada de API para troca de informações

O sistema armazena internamente em formato openEHR e expõe dados via FHIR API para consumidores externos.

Implementação técnica

Ferramentas

Editores de archetypes:

• Archetype Designer (web-based, openEHR Foundation)
• LinkEHR (editor e plataforma de integração)

Servidores openEHR:

• EHRbase (open source, Java)
• Better Platform (comercial)
• Marand/Think!EHR (comercial)
• Nedap/openEHR platform

Query language:

• AQL (Archetype Query Language) — linguagem SQL-like para consultar dados modelados com archetypes

Exemplo de AQL

`

SELECT

o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value as systolic,

o/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value as diastolic

FROM EHR e

CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.blood_pressure.v2]

WHERE o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude > 140

`

Adoção no Brasil

O openEHR tem presença crescente no Brasil, particularmente em:

• Instituições acadêmicas com projetos de pesquisa em informática em saúde
• Hospitais universitários que buscam flexibilidade na modelagem
• Empresas de PEP que adotaram a arquitetura para diferenciação

A RNDS (Rede Nacional de Dados em Saúde) é baseada em FHIR, o que torna o FHIR obrigatório para comunicação com o governo. Mas internamente, instituições podem usar openEHR.

Desafios da adoção

Curva de aprendizado

openEHR exige compreensão profunda de seus conceitos. A modelagem dual, embora poderosa, é contraintuitiva para desenvolvedores acostumados com bancos relacionais tradicionais.

Ecossistema menor

Comparado a FHIR, o ecossistema openEHR tem menos bibliotecas, menos exemplos de implementação e menos desenvolvedores familiarizados.

Governança de archetypes local

Embora o CKM internacional seja maduro, cada instituição precisa governar seus templates locais. Sem processo definido, a flexibilidade vira caos.

Performance

Queries AQL em grandes volumes de dados podem ser desafiadoras. A estrutura hierárquica dos dados openEHR exige estratégias de indexação específicas.

Perguntas Frequentes

O que é FHIR e por que é importante para prontuários eletrônicos?

FHIR (Fast Healthcare Interoperability Resources) é um padrão internacional para troca de dados clínicos via APIs modernas (RESTful). Permite que sistemas de diferentes fornecedores troquem informações de saúde de forma padronizada. É a base da Rede Nacional de Dados em Saúde (RNDS) no Brasil.

Qual a diferença entre FHIR e HL7 v2?

HL7 v2 usa mensageria baseada em texto (pipes and hats) e é amplamente adotado em sistemas legados. FHIR usa APIs RESTful com recursos em JSON/XML, é mais moderno e fácil de implementar para desenvolvedores atuais. Ambos coexistem: FHIR para novas integrações, HL7 v2 mantido onde já funciona.

Meu sistema precisa implementar FHIR?

Se o sistema troca dados com a RNDS (Rede Nacional de Dados em Saúde), a conformidade com FHIR é obrigatória para determinados eventos (vacinação, resultados de exames). Para novas integrações entre sistemas, FHIR é altamente recomendado como padrão de futuro. Para sistemas isolados, a necessidade é menor, mas a preparação é prudente.

Conclusão

openEHR não é melhor ou pior que FHIR — resolve problemas diferentes. Onde FHIR brilha na interoperabilidade entre sistemas, openEHR brilha na modelagem flexível de dados clínicos dentro de um sistema. Instituições maduras em informática em saúde tendem a usar ambos: openEHR para estruturar e armazenar, FHIR para comunicar e integrar. A escolha depende do problema a resolver, dos recursos disponíveis e da maturidade da equipe técnica.