Este documento discute a modelagem multinível de sistemas de informação em saúde usando as especificações openEHR/MLHIM. Ele explica que a informação em saúde é complexa devido à dinâmica e interdependência do sistema de saúde, e que a modelagem tradicional de um único nível não é eficiente. A abordagem openEHR/MLHIM separa o modelo de referência implementado em software da modelagem do conhecimento usando arquétipos, permitindo que especialistas de saúde modelem seu domínio de conhecimento

1. Modelagem do Conhecimento em Arquétipos /
CCDs para Sistemas de Informação em Saúde
Laboratório Associado INCT-MACC
“Multilevel Healthcare Information Modeling
UFF/UERJ

2. Modelagem multinível de sistemas de
informação em saúde
Laboratório Associado INCT-MACC
“Multilevel Healthcare Information Modeling
UFF/UERJ

3. Sumário
• Informação em Saúde: Conceitos Gerais
• Fundamentos da Modelagem Multinível de SI
• As especificações openEHR/MLHIM: Visão Geral
• O Modelo de Referência openEHR/MLHIM
• O Modelo de Informação openEHR/MLHIM:
Arquétipos/CCDs
• Hands-On

4. A Informação em Saúde é Complexa...
...porque o sistema de saúde é um sistema complexo e
dinâmico:
• Complexidade: o sistema gera um grande número de
variáveis que apresentam complexas interdependências,
sendo a principal a...
...dependência espaço-temporal: a informação a ser
armazenada varia no tempo e no espaço
• Dinâmica:
▫ A associação entre as variáveis é “variável”
▫ A variação temporal é rápida e a variação espacial é próxima

5. As Políticas de Saúde também são Complexas
• O estabelecimento de consensos em relação a um
determinado conceito em saúde é difícil:
▫ Competição entre “escolas médicas”
▫ Multiprofissionalismo e não transdisciplinaridade
• As redes de atenção são hierárquicas, com múltiplas
portas de entrada e sem um mecanismo funcional de
referência e contra-referência

6. Desafios do Sistema x Promessas da Informatização
•  % de eventos adversos advindos de erros terapêuticos
(interações, duplicações, indicações erradas)
•  Tempo de busca por informações críticas
•  % de pacientes “perdendo tempo” no sistema em função da falta
de referência e contra-referência
•  Duplicação de investigações, testes e procedimentos
•  Capacidade de prevenção e detecção precoce
•  Capacidade de tomada de decisões não-pontuais
•  Adesão a protocolos terapêuticos
•  Efetividade dos programas orientados a uma doença específica
•  Taxa de hospitalização e de reinternações evitáveis

7. Outras Questões Importantes
• Coerência semântica: manutenção do significado
(contexto) da informação registrada dentro da base de
dados
• Interoperabilidade: capacidade de enviar a informação de
um lugar (sistema) para outro, mantendo a informação
inteligível em ambos os lugares (sistemas)
• Persistência: a informação deve ser armazenada de forma
perpétua no sistema do modo que foi registrada
originalmente

8. Onde Está o Contexto?

9. Aqui Está o Contexto!

10. Interoperabilidade

11. Interoperabilidade!

12. Interoperabilidade?

13. Modelagem Tradicional

14. Problemas do Modelo de Um Nível
 A informação é modelada de uma forma que “serve” às necessidades
atuais do sistema de saúde
 A adição de novos conceitos implica em refazer o sistema todo
(remodelagem, reimplementação, reteste, redistribuição)
 Alto custo, lentidão na integração dos novos conhecimentos aos SIS etc.

15. Modelagem Multinível

16. Por que Adotar Padrões para os SIS?
• Condição essencial para a efetiva implementação de um
sistema de saúde único e universal, como o SUS
• Uniformização de “regras, protocolos, processos” e
“atividades”, “para o benefício de todos” (ISO)
• Democratização dos processos de gestão do sistema
• Aprimoramento dos processos de controle e avaliação

17. Padrões e Especificações para os SIS
Nome O que é Implementado Aberto
ISO/CEN Padrão Sim Não
HL7 Especificação e Sim Não
“Padrão”
openEHR Especificação e Sim “Sim”
“Padrão”
MLHIM Especificação e Sim Sim
“Padrão”

18. x T
ICD es E DC
p OM
WHO a
ty SN
Dat IHTSDO
ISO PMAC
EN13606-
EN1
ASTM CCR Documents
Content models
Security
Terminology
EN
3606
Services
1
E
36
C
N1
A
0
36
-3
4
RB
6-2
Q 06
PD -1
s
ge
IHE PIX s
CEN
sa
RID age
v2
ss
es
m e
m
v3
XD
HL7
S
HI
HSSP
SA
W
CCO CD
A
s
te
pla
m
Te
Fonte: Thomas Beale, EFMI

19. As Especificações openEHR/MLHIM
• Modelo multinível (ou dual): desenvolvimento do software e
modelagem do conhecimento são separados
• O modelo de referência é implementado em software
• O conhecimento é modelado em “arquétipos” (openEHR),
ou “Definições de Restrições para os Conceitos” (Concept
Constraint Definitions – CCD) (MLHIM)

20. Modelo dual openEHR/MLHIM

21. Modelo de Referência openEHR/MLHIM
• Definição das classes entendidas como “blocos genéricos”
de construção de um SIS:
▫ Representação das características genéricas dos
componentes necessários em um SIS, e de como eles se
agregam
• Separa o conteúdo clínico do demográfico
• Especifica os elementos necessários a serem seguidos na
implementação em função dos princípios éticos e legais
próprios da área da saúde

22. Modelo de Referência Clínico

23. Estrutura de alto nível do MR
Composition

24. Estrutura de uma Composição

25. Pacote text
A classe CODE_PHRASE permite a codificação de informações
utilizando uma dada terminologia
A classe TERM_MAPPING permite o mapeamento entre
terminologias

26. Pacote quantity
Ordered DATA_VALUE INTERVAL<T>
(rm.support.assumed) (rm.data_types.basic) (rm.support.assumed)

27. Pacote Entry

28. Pacote Item Structure

29. Cluster e Element
Observe que um cluster pode ser composto de elementos e outros clusters. Isto fornece
a flexibilidade para se estruturar as informações do modo mais desejável.
Todo valor de um dado será armazenado no atributo “value” da classe “ELEMENT”, que
pode ser qualquer um dos tipos permitidos de “DATA_VALUE” do Modelo de Referência.

30. Exemplo de uma estrutura tabular

31. Exemplo de uma estrutura com um
único elemento

32. Exemplo de uma estrutura em forma de
lista de elementos

33. Exemplo de uma estrutura em forma
de árvore

34. Arquétipo openEHR
• É a arquitetura adotada nas especificações para a
modelagem do conhecimento
• É a definição das “combinações de” + “restrições a”
classes existentes do MR que são necessárias para
expressar um conceito específico em saúde
• Contém todo o contexto semântico do conceito que modela
• Para garantir interoperabilidade, os arquétipos devem ser:
▫ Elaborados por uma comunidade aberta
▫ Mantidos em um repositório público que permita reutilização

35. Arquétipos

36. Propósito dos arquétipos
▫ Permitir que especialistas tomem para si a
responsabilidade de modelar o conhecimento
que dominam para os SIS
▫ Permitir interoperabilidade no segundo nível do
sistema (o do conhecimento), desde que os
sistemas sejam baseados no mesmo modelo
de referência e usem os mesmos arquétipos
para um determinado conceito clínico

37. Arquétipos e Templates
Diabetic checkup Archetypes Antenatal visit
Tingling feet FH Back pain
Feeling tired
Weight 66 kg
76 kg
BP 102/64 mmHg
124/92
142/min
HbA1c
7.5%
NAD, see 4/52
Issues
Excellent control
Assess
Template Template

38. FORMS

39. Clinical Knowledgment Management (CKM)
www.openehr.org/knowledge

40. Um exemplo simples:
Fonte: Qamar e Rector, 2007
Um arquétipo desenvolvido em uma comunidade aberta, e colocado num repositório de
acesso livre para validação pela comunidade teria muito menor probabilidade de ter um
erro de ortografia como esse

41. Síntese:
• A modelagem tradicional de sistemas de informação, na
qual o conhecimento do domínio é implementado em
software, é ineficiente para realidades complexas e
dinâmicas como a do sistema de saúde
• Os problemas advindos do uso desta modelagem nos SIS
mundiais tem estimulado iniciativas de padronização
• A adoção de terminologias é um elemento importante, mas
não resolve os problemas da área se os sistemas
continuarem sendo implementados em um só nível

42. Síntese:
• Na modelagem multinível, cada especialista é responsável
pela sua “especialidade”:
▫ O cientista da computação implementa o modelo de referência
▫ O profissional de saúde modela o conhecimento
• A camada de software + DB é separada da camada de
conhecimento
• Não confundir com “three tier”, que tradicionalmente mantém
a camada de conhecimento implementada em software e
somente separa BI e GUI

43. Perguntas?
http://www.mlhim.org
lutricav@vm.uff.br