OpenEHR

A interoperabilidade dos dados clínicos continua a ser um dos principais desafios enfrentados por instituições, profissionais e governos no que diz respeito transformação digital em saúde. Os sistemas de Registo de Saúde Eletrónico (RSE) tradicionais, para além de frequentemente marcados por falta de interoperabilidade, também apresentam interfaces desatualizadas, altos custos de manutenção e estruturas rígidas que dificultam a sua adaptação a novos requisitos clínicos. Além disso, muitos sistemas de informação apresentação fragmentação de dados, dependência tecnológica de fornecedores específicos e com pouca capacidade de integração com novos dispositivos, plataformas cloud, aplicações móveis ou fluxos clínicos complexos. Neste cenário, surge o openEHR como uma resposta arquitetónica e semântica a estas falhas, propondo uma abordagem centrada na flexibilidade estrutural, na participação ativa dos profissionais de saúde e na longevidade dos dados clínicos.

O que é o openEHR?

openEHR

Designação	openEHR Foundation
Data de Fundação	2003
Entidade Gestora	openEHR Community Interest Company
Tipo de Entidade	Organização sem fins lucrativos
Área de Atuação	Registos de Saúde Electrónicos, Interoperabilidade semântica, Modelação clínica
Missão	Desenvolver especificações abertas e sustentáveis para sistemas de informação clínica interoperáveis
Sistemas e Ferramentas Associadas	CKM, AQL, Archetype Designer, EHRbase, openEHR Specs
Arquitetura	Modelo em dois níveis (Reference Model + Archetypes/Templates)
Utilizadores	Hospitais, ministérios, fornecedores de software, investigadores
Função Principal	Estruturação, armazenamento e reutilização semântica de dados clínicos

O openEHR é um conjunto de especificações abertas, baseada em normas internacionais, desenvolvida para auxiliar a criação e manutenção de RSE. Define um conjunto de modelos, linguagens e regras para o armazenamento, gestão, recuperação e troca de dados de saúde, com enfoque na semântica, na modularidade e na longevidade da informação clínica. É um padrão computacional que separa a lógica da informação técnica do conhecimento clínico, permitindo que a evolução científica e prática não obrigue a alterar a infraestrutura tecnológica.

O seu propósito fundamental é definir os componentes de uma plataforma computacional de saúde que responda a desafios centrais da área, nomeadamente:

• Complexidade da informação clínica e dos fluxos de trabalho;
• Constante mudança dos requisitos clínicos;
• Necessidade de um registo centrado no utente;
• Integração entre diferentes fornecedores de software e componentes.

A sua proposta não visa apenas a interoperabilidade técnica, mas também a interoperabilidade semântica e computacional, sustentando aplicações como sistemas de apoio à decisão, integração com dispositivos móveis, medicina personalizada e inteligência artificial.

Desenvolvida por uma fundação sem fins lucrativos e sustentada em colaboração internacional, o openEHR caracteriza-se por promover uma arquitetura de dois níveis (Dual model), que separa o modelo técnico dos dados da representação do conhecimento clínico. Esta separação confere ao sistema flexibilidade e capacidade de adaptação, permitindo que os dados se mantenham válidos mesmo quando as práticas clínicas ou os sistemas tecnológicos evoluem.

Arquitetura openEHR- Estrutura e funcionamento

A arquitetura do openEHR resulta de um processo de desenvolvimento conceptual sustentado na tentativa de resolver um dos problemas mais complexos na área dos sistemas de informação em saúde: como representar, armazenar e partilhar dados clínicos de forma duradoura, segura e semanticamente consistente, num contexto em que o conhecimento clínico está em constante evolução. Ao contrário de muitas soluções tradicionais, o openEHR não propõe apenas um modelo de dados, mas uma arquitetura completa de informação clínica, desenhada para assegurar a interoperabilidade e a sustentabilidade dos registos eletrónicos de saúde ao longo do tempo.

A principal inovação metodológica introduzida por este standard assenta no conceito de modelação em dois níveis (Dual model), o que estabelece uma separação clara entre as estruturas técnicas dos sistemas e o conhecimento clínico. Este modelo surgiu como resposta à constatação de que os sistemas tradicionais tendem a introduzir o conhecimento clínico diretamente nas bases de dados e aplicações, dificultando a sua atualização e adaptação à evolução das práticas clínicas.

A estrutura deste modelo de dois níveis é constituído pelo Modelo de Referência e pelos Modelos de conteúdo clínico (Arquétipos e Templates).

Modelo de referência (Reference Model-RM)

Constitui o núcleo estrutural da arquitetura openEHR. Define os tipos de dados, as hierarquias, as estruturas temporais e a lógica de composição de registos clínicos. Em termos práticos, estabelece como os diferentes elementos de informação se inter-relacionam e são organizados, garantindo a coerência estrutural e o correto armazenamento da informação clínica .

Componentes fundamentais incluem entidades como Composition, Section, Entry (Care_entry como Observation, Evaluation, Instruction e Action; Admin_entry), entre outros, que permitem estruturar qualquer episódio clínico em unidades de informação logicamente organizadas.

Esta estrutura flexível permite descrever não só eventos clínicos episódicos, mas também dados longitudinais e complexos percursos assistenciais, assegurando a sua interpretação inequívoca ao longo do tempo.

Modelos de conteúdo clínico (Arquétipos e Templates)

• Arquétipos (Archetypes): São o principal mecanismo de representação do conhecimento clínico no openEHR. Cada archetype descreve com precisão a estrutura e o conteúdo de um conceito clínico, incluindo as variáveis, unidades de medida, restrições de valor e ligações semânticas com terminologias normalizadas (por exemplo, um modelo de “pressão arterial” especifica todos os elementos, unidades, codificações e restrições semânticas que definem esse conceito). Estes são construídos e validados por especialistas da área, permitindo uma representação consensual e partilhada de conceitos;
• Templates: Combinam e adaptam múltiplos arquétipos a contextos de casos de uso específicos, como uma nota de alta hospitalar ou um formulário de rastreio oncológico. Este modelo assegura que o significado clínico dos dados é compreendido não apenas pelo software que os gere, mas também por sistemas terceiros, profissionais de saúde e até algoritmos de inteligência artificial.

A utilização combinada de archetypes e templates proporciona uma enorme flexibilidade na construção de aplicações clínicas, mantendo simultaneamente a complexidade semântica necessária para garantir a interoperabilidade.

Contudo, a sua especificação não se limita à modelação da informação, tendo também em consideração o versionamento, em que cada alteração ao conteúdo clínico ou à estrutura dos modelos é registada de forma imutável e auditável e, uma linguagem própria de consulta – a AQL (Archetype Query Language) –, tudo com o objetivo de tornar os RSE mais reutilizáveis, compreensíveis e, permitir a rastreabilidade clínica, jurídica e científica dos registos.

História e evolução

Linha temporal da origem e evolução do openEHR

Início dos anos 90 – O Dr. Alain Maskens (oncologista belga) e o Dr. Sam Heard (clínico geral australiano e professor no St. Bartholomew’s, em Londres) lideram um consórcio para desenvolver um modelo genérico de registo eletrónico de saúde.

1991 – Criação do consórcio GEHR (Good European Health Record), coordenado pela Faculdade de Medicina do St. Bartholomew’s Hospital, com o Professor David Ingram como Diretor do Projeto e apoio de Lesley Southgate.

1992 – Início oficial do projeto GEHR, com sete parceiros industriais, académicos e profissionais. Desenvolvimento de uma arquitetura pioneira baseada em modelação orientada a objetos, que influenciaria a norma CEN ENV 12265 e os primeiros esforços de padronização de registos clínicos na Europa.

1993 – O consultor Tom Beale junta-se ao projeto, criando o primeiro modelo de objetos GEHR.

1994 – Encerramento formal do projeto GEHR.

1995 – David Ingram torna-se Professor de Informática em Saúde na University College London (UCL), onde funda o CHIME – Centre for Health Informatics and Multiprofessional Education.

1995–1997 – Lançamento do projeto europeu Synapses, liderado por Ingram, com a participação da Siemens e outros parceiros. Introduz-se o conceito de modelo duplo, com separação entre estrutura e conteúdo clínico, permitindo a implementação de servidores clínicos piloto em diversos países europeus.

1996 – Na Austrália, Sam Heard e Tom Beale retomam os princípios do GEHR, desenvolvendo o modelo de objetos GEHR Australia. Este modelo aprofunda a abordagem arquetípica e a modelação de dois níveis, com contribuições de Peter Schloeffel e parcerias com o DSTC (Distributed Systems Technology Centre).

Transição para o openEHR

1998 – Surge a ideia da criação da openEHR Foundation, com o intuito de unir os esforços da UCL e da Austrália numa iniciativa de código aberto, com rigor clínico e base técnica sólida.

Fundação e consolidação

2001 – Realiza-se uma reunião internacional em Londres, juntando Heard, Beale, Schloeffel e Kalra, que alinham metodologias e confirmam a compatibilidade entre as abordagens desenvolvidas nos diferentes continentes.

2003 – Constituição oficial da openEHR Foundation como entidade sem fins lucrativos com sede na UCL, com ativos bloqueados. A sua missão é levar a interoperabilidade semântica dos registos clínicos a uma escala global.

2003–2014 – Período de consolidação técnica, desenvolvimento das estruturas de governação e colaboração com organizações internacionais.

Nova estrutura organizacional

2014 – Início de uma nova fase com a criação de uma estrutura formal de membros e a eleição de um conselho de administração representativo da comunidade global.

2018 – A Fundação transforma-se numa Community Interest Company (CIC) sediada em Londres, garantindo a continuidade dos princípios de abertura, independência e envolvimento comunitário.

Parcerias e reconhecimento internacional

2021 – Estabelecimento de uma parceria estratégica com o HL7, promovendo a interoperabilidade entre o openEHR e o standard internacional FHIR.

2024 – Grandes empresas tecnológicas, como a Microsoft, passam a integrar o ecossistema openEHR como parceiros estratégicos, reforçando a maturidade e a relevância internacional da iniciativa.

Governação e comunidade

A governação do openEHR é assegurada por uma estrutura clara e transparente, organizada em programas e liderada por uma direcção eleita. A entidade legal da iniciativa é a openEHR Community Interest Company, uma organização sem fins lucrativos e com activos bloqueados, registada no Reino Unido. O seu funcionamento é sustentado por uma comunidade internacional de membros subscritores, tanto individuais como institucionais, que elegem a direção e participam ativamente nos processos de decisão.

A estrutura organizativa do openEHR inclui quatro programas principais:

• Specification Program – Responsável pelo desenvolvimento técnico das especificações openEHR;
• Clinical Modelling Program – Supervisiona a criação e revisão dos modelos clínicos (archetypes e templates);
• Software Program – Promove o desenvolvimento de software de referência e ferramentas open-source;
• Community Program – Apoia a participação da comunidade e iniciativas educativas e de adoção global.

Cada programa tem líderes nomeados e opera com equipas abertas, sendo as decisões tomadas com base em princípios de abertura, colaboração e revisão por pares. A openEHR mantém ainda diversos comités e grupos de trabalho, incluindo o Management Board, que supervisiona a estratégia e o funcionamento geral da organização, e o International Board, que garante a representação global da comunidade. A governação é documentada publicamente e todas as decisões e contribuições são registadas em canais acessíveis, reforçando a transparência e a legitimidade técnica e comunitária do openEHR.

Um dos pilares da governação openEHR é o Clinical Knowledge Manager (CKM), um repositório público onde se criam, traduzem, discutem e publicam archetypes clínicos. O CKM é multilingue, colaborativo e auditável, envolvendo profissionais de saúde e especialistas em informática clínica de dezenas de países. Funciona assim, como “biblioteca oficial”, que disponibiliza códigos de publicação em vários formatos (ADL 1.4/2, OPT, JSON, XML).

Vantagens e contributo

O modelo openEHR apresenta-se como uma solução sólida e amplamente fundamentada para responder aos desafios da informação clínica estruturada e interoperável. Desta forma, este standard apresenta diversas vantagens e pontos fortes, entre os quais:

• Adoção da arquitetura de dois níveis, que separa o modelo de informação (Reference Model) do conhecimento clínico (Archetypes e Templates). Esta abordagem garante uma elevada flexibilidade e capacidade de adaptação às constantes evoluções da prática clínica, sem comprometer a estabilidade da infraestrutura técnica;
• Mecanismo de versionamento, auditoria e rastreabilidade dos dados clínicos, aspetos fundamentais para garantir a confiança e segurança na utilização dos sistemas de informação em saúde. Os dados clínicos, ao serem representados por archetypes e templates validados por comunidades clínicas internacionais, favorecem a normalização semântica e promovem o consenso clínico, reforçando a interoperabilidade entre sistemas;
• Filosofia aberta e independente de fornecedores, que permite a livre implementação e reutilização de modelos clínicos, potenciando a sustentabilidade e reduzindo o risco de vendor lock-in;
• Capacidade para suportar análises longitudinais, decisões clínicas baseadas em dados e integração com terminologias como SNOMED CT e LOINC como vantagens estratégicas;
• Independência de fornecedor, com suporte a múltiplos formatos e tecnologias (PostgreSQL, JSON-B, NoSQL);
• Facilidade de adaptação a projetos de saúde digital, inteligência artificial e análise de dados clínicos, graças à granularidade e estruturação dos dados.

Estas características fazem do openEHR uma infraestrutura semântica de referência, especialmente indicada para projetos nacionais, redes de saúde, hospitais universitários e sistemas de saúde orientados à medicina personalizada e preventiva.

Desafios e limitações

Apesar benefícios, a implementação do openEHR implica um conjunto de obstáculos significativos, nos quais se destacam:

• Complexidade técnica da sua arquitetura, sobretudo ao nível da criação e gestão de archetypes e templates, exige competências especializadas tanto em engenharia de software como em conhecimento clínico. Esta exigência dificulta a adoção do modelo por parte de instituições com menos recursos técnicos ou capacidade organizativa para constituir equipas multidisciplinares;
• Integração do openEHR em ecossistemas onde coexistem outros standards, como o HL7 FHIR ou o ISO 13606. Apesar da existência de mapeamentos e iniciativas de interoperabilidade entre estes, persistem dificuldades práticas na conversão de modelos, nomeadamente pela diferença de granularidade e expressividade entre os mesmos;
• Necessidade de alterações profundas nos processos de documentação clínica e governação da informação. A gestão colaborativa de modelos clínicos, embora benéfica, pode gerar resistências institucionais e requer políticas claras de validação e atualização contínua;
• A utilização de ADL (Archetype Definition Language), AQL e ferramentas como o Archetype Designer requer investimento formativo;
• A governação de modelos clínicos demora tempo e exige consenso entre múltiplos peritos e revisores;
• A riqueza semântica dos archetypes, embora essencial para garantir a interoperabilidade, pode originar modelos excessivamente extensos, difíceis de interpretar ou implementar sem ferramentas de apoio adequadas. Esta complexidade afeta também o desempenho dos sistemas baseados em openEHR, que podem apresentar latências superiores às soluções com modelos de dados mais simplificados, especialmente em ambientes hospitalares com grande volume de transações.

Ferramentas, projetos e comunidades

O openEHR conta com várias ferramentas, projetos e comunidades:

• CKM (Clinical Knowledge Manager) - https://ckm.openehr.org
• Especificações técnicas – https://specifications.openehr.org
• Servidores open-source – EHRbase, EtherCIS, EHRServer.
• Bibliotecas – Archie (Java), pyEHR (Python), openEHR SDK.
• Ferramentas de modelação – Archetype Designer, Template Designer.
• Interfaces REST e integração com FHIR – através de APIs e mapeamentos bidireccionais.
• Repositórios de código – GitHub openEHR, GitLab EHRbase.
• Comunidade internacional – Fóruns, grupos regionais, publicações e projetos académicos.

Referências bibliográficas

• Beale, T., & Heard, S. (2007). openEHR Architecture Overview. The openEHR Foundation.
• Garde, S., Knaup, P., Hovenga, E. J., & Heard, S. (2007). Towards Semantic Interoperability for Electronic Health Records. Methods of Information in Medicine.
• Portal de Livros UFG. (2021). Informática em Saúde: modelos de informação clínica. Universidade Federal de Goiás.
• openEHR Foundation. (2024). Origins and History. Disponível em: https://openehr.org/
• Chen, R., et al. (2022). Archetype-based EHR systems: A review and future directions. International Journal of Medical Informatics. https://doi.org/10.1016/j.ijmedinf.2022.104860
• openEHR Foundation. Origins. Disponível em: https://openehr.org/origins
• openEHR Foundation. History. Disponível em: https://openehr.org/history
• openEHR Foundation. Home, Mission, Governance, Clinical Modelling. Disponível em: https://openehr.org/
• Beale, T., & Heard, S. (2007). openEHR Architecture Overview. The openEHR Foundation.
• Zhang, Y., Chen, R., Deng, K., Wang, X., & Li, L. (2018). Archetype-based electronic health record systems: a literature review and future directions. BMC Medical Informatics and Decision Making, 18(1), 1-10.
• Garde, S., Buck, J., Chen, R., Leslie, H., & Heard, S. (2015). Towards semantic interoperability for electronic health records: domain knowledge governance for openEHR archetypes. Journal of Biomedical Informatics, 56, 229-239.
• Chen, R., Klein, G., Sundvall, E., Karlsson, D., & Ahlfeldt, H. (2018). openEHR-based electronic health record system architecture. BMC Medical Informatics and Decision Making, 18(59), 1-10.
• Kalra, D., Beale, T., Heard, S., & Lloyd, D. (2018). The openEHR Foundation: Building a Platform for EHR Interoperability. Procedia Computer Science, 138, 68-75.
• openEHR Foundation. (2024). Documentation, Origins, Architecture. Disponível em: https://openehr.org/
• Żuk, P., Dąbrowski, M., Rukat, A., Zieliński, K., & Borycki, E. (2023). Comparison of openEHR and HL7 FHIR approaches in the context of interoperability of electronic health records. Polish Academy of Sciences. Disponível em: https://journals.pan.pl/dlibra/publication/144330/edition/126538/content
• Chen, R., Klein, G., & Sundvall, E. (2022). Archetype-based electronic health record systems: A review and future directions. International Journal of Medical Informatics, 165, 104860. https://doi.org/10.1016/j.ijmedinf.2022.104860
• Jiang, Y., Zhang, X., Zhang, Y., Liu, L., & Li, L. (2022). openEHR archetypes and templates: A systematic review and analysis of their application in clinical practice. Studies in Health Technology and Informatics, 294, 235–239. https://pubmed.ncbi.nlm.nih.gov/35395475/
• Kryszyn, J., Smolik, W., Wanta, D., Midura, M., & Wróblewski, P. (2023). Comparison of openEHR and HL7 FHIR Standards. International Journal of Electronics and Telecommunications, 69(1), 47–52. https://repo.pw.edu.pl/info/article/WUTabc672c937c544328ebfb67a38bfc07f/
• openEHR & HL7 Joint Announcement (2021). Joint statement on collaboration between openEHR and HL7. Disponível em: https://discourse.openehr.org/t/openehr-and-hl7-joint-announcement/5243
• Martínez-Costa, C., Menárguez-Tortosa, M., & Fernández-Breis, J. T. (2010). An approach for the semantic interoperability of ISO EN 13606 and OpenEHR archetypes. Journal of Biomedical Informatics, 43(5), 736–746. https://doi.org/10.1016/j.jbi.2010.05.013
• Kalra, D., Beale, T., Heard, S., & Lloyd, D. (2018). The openEHR Foundation: Building a Platform for EHR Interoperability. Procedia Computer Science, 138, 68–75. https://doi.org/10.1016/j.procs.2018.10.010