O documento discute a complexidade do sistema de saúde e os desafios da informatização no setor. A saúde é mais complexa do que outros setores devido a três dimensões: espaço, tempo e ontologia. Isso torna difícil a interoperabilidade semântica entre sistemas. Padrões como HL7 e normas da ISO tentam resolver esses problemas, mas a alta dinâmica do conhecimento médico dificulta a padronização.

1. PADRÕES E
ESPECIFICAÇÕES PARA A
ÁREA DE INFORMÁTICA EM
SAÚDE
Profa. Luciana Tricai Cavalini
Departamento de Tecnologias de Informação em Saúde
Faculdade de Ciências Médicas
Universidade do Estado do Rio de Janeiro (UERJ)

2. Dinâmica e
Complexidade
do Sistema de
Saúde
POR QUE TUDO ESTÁ
INFORMATIZADO, MENOS A
SAÚDE?

3.  Sistemas de saúde efetivos respondem rápido às mudanças
do perfil demográfico e epidemiológico da população
 Estas mudanças costumam ser inesperadas. Exemplos:
 Zoom out: quando há uma epidemia (ou um tsunami)
 Zoom in: a qualquer hora da emergência de um grande hospital
 Em sistemas de saúde baseados em papel, nós demoramos
semanas para conseguir identificar uma epidemia (zoom out)
ou um surto de bactéria assassina em um hospital (zoom in)
 Promete-se há décadas que esses problemas desaparecerão
com a informatização dos serviços de saúde
 O fato é que essas promessas ainda não foram cumpridas.
INFORMATIZAÇÃO DA SAÚDE:
PANACEIA OU PLACEBO?
Por quê?
Por que é tão fácil informatizar tudo (bancos, imposto de renda,
DETRAN, compras na Internet) e é tão difícil na saúde?
(Shaw et al, 2002)

5.  Inundar o sistema de saúde de hardware (e o correspondente
software embarcado) tem um efeito pífio sobre a melhora das
condições de saúde individuais e coletivas
 Sem ilusões: NADA vai JAMAIS superar o efeito da melhoria na
renda, no saneamento básico e na cobertura de vacinação
 Entretanto, gastam-se milhões ou até bilhões para
informatizar, sem planejamento, os sistemas de saúde
 Não há muita massa crítica nas áreas técnicas de governo (ou
dos hospitais privados) sobre qualidade de software em saúde
 Software médico é comprado ou desenvolvido com a mesma
arquitetura de software adotada para videolocadoras, postos
de gasolina ou caixas de banco
INFORMATIZAR POR INFORMATIZAR?
Creia-me: não vai funcionar.
Mas por quê?

6.  Apenas para não dar a impressão de que o problema da
informática médica é meramente a qualidade de software:
 Imaginemos o software médico com a melhor qualidade
possível, baseado em modelagem tradicional, instalado na
Clínica C.
 O paciente vai à Clínica C fazer um cateterismo pré-
operatório, mas a cirurgia de marcapasso será feita no
Hospital H, que também tem um software similar.
 Por melhor que sejam estes dois softwares, o contexto da
informação coletada na Clínica C fica “aprisionado” no
modelo de dados definido no código do Software C, e idem
para o Software H
UM PARÊNTESIS
Voltemos à pergunta:
Por que a modelagem de software que se usa em todos os outros
setores da economia não é efetivo para a saúde?

7.  A saúde é o único setor da economia humana que lida com os
processos de produção biológicos (criados pela natureza)
 Todos os outros setores da economia lidam com processos de
produção industriais (criados pelo homem)
 Os processos de produção criados pelo homem são mais
simples que os biológicos, porque:
POR QUE É DIFERENTE NA SAÚDE?
Tive essas ideias lendo: Dawkins R. O maior espetáculo da Terra, pp. 204-5 (e Marx, lógico).
A evolução teve milhões de anos para
chegar a essa complexidade
A civilização começa há apenas
dezenas de milhares de anos atrás
Os sistemas industriais são tão
simples quanto possível para
maximizar lucro
Os sistemas biológicos são tão
complexos quanto necessário para
garantirem a sobrevivência da
espécie

8. Sistemas de saúde são muito mais complexos
do que qualquer outra coisa no mundo, em
relação a 3 dimensões:
Espaço
Tempo
Ontologia
DINÂMICA E COMPLEXIDADE EM SAÚDE

9. Duas cidades podem ser vizinhas e
terem necessidades de saúde
completamente diferentes
Ou melhor, dois bairros podem ser
vizinhos e precisarem de atendimentos
de saúde diferentes!
Ou melhor, dois prédios na mesma rua
podem ser vizinhos e precisarem de
cuidados de saúde diferentes!
Ou melhor, duas pessoas
morando juntas podem ter
necessidades de saúde
diferentes!
Ou melhor, seu pé e seu
coração TÊM
necessidades de cuidados
diferentes!
Ou melhor, dois
alelos que
determinam
doenças
diferentes em
você vão precisar
de terapias
gênicas
diferentes no
futuro!
A COMPLEXIDADE ESPACIAL (1)

10. Dando um Zoom Out...

11. A COMPLEXIDADE ESPACIAL (2)

12. A COMPLEXIDADE TEMPORAL

13. A COMPLEXIDADE TEMPORAL

14. A COMPLEXIDADE TEMPORAL

15. A COMPLEXIDADE TEMPORAL

16. A COMPLEXIDADE TEMPORAL

17. A COMPLEXIDADE TEMPORAL

18. A COMPLEXIDADE TEMPORAL

19. A COMPLEXIDADE TEMPORAL

20. Dando um Zoom In...

21. A COMPLEXIDADE TEMPORAL

22. Infelizmente, acabou a parte com fotos fofas.

23.  A maior terminologia de medicina (SNOMED-CT) tem mais de
310.000 termos conectados por mais de 1.000.000 de links
 Isto significa que, em medicina, existem aproximadamente
310.000 conceitos, conectados entre si de milhões de formas
diferentes
 Em termos práticos, isso significa que montar um “sistemão
megalítico” que todos os serviços poderiam utilizar
significaria montar uma quantidade enorme de tabelas com
310.000 campos e milhões de relacionamentos entre si
A COMPLEXIDADE ONTOLÓGICA
Conjectura de Cavalini-Cook: A probabilidade de consenso entre 2
ou mais especialistas de uma mesma área em relação ao que seria
o “modelo de dados máximo” para qualquer conceito em saúde
tende a zero

24.  Esta complexidade faz com que um problema de ciência da
computação que não existe (ou não é crítico) em qualquer
outro setor da sociedade humana seja muito grave em saúde.
 Este problema é:
O QUE ESTA COMPLEXIDADE CAUSA?

25.  De forma inteligível:
 Interoperabilidade semântica é a capacidade de enviar um
extrato de informação de um sistema A para o sistema B, e
destes para o sistema C, e vice-versa, etc, sendo que todos
estes extratos de informação são semanticamente válidos em
todos os sistemas
INTEROPERABILIDADE SEMÂNTICA
Todos os sistemas leem e entendem
todos os extratos de informação dos
outros sistemas

26. - Tosse
- Por 3 meses
- Febrícula
RX de tórax:
- Nódulo em
ápice D
LBA:
- TB
RX de tórax:
- Nódulo em
ápice D
LBA:
- TB
- Tosse
- Por 3 meses
- Febrícula
- Tosse
- Por 3 meses
- Febrícula
RX de tórax:
- Nódulo em
ápice D

27.  Uma pessoa pode ter cadastro em várias videolocadoras. O seu
histórico de locação na videolocadora A não afeta em nada a
qualidade do atendimento que vai receber na videolocadora B
 Em saúde, tudo é interligado!
 O que aconteceu com o paciente quando foi atendido no posto
de saúde é CRÍTICO para definir o seu atendimento na hora em
que ele vai para o hospital
 “Ah, mas o paciente pode contar”.
 Mas muitos pacientes estão desacordados ou sob efeito de
medicamentos psicotrópicos nas horas mais críticas das suas
vidas, e as famílias em volta estão chorando e não informam
bem tampouco
 “Ah, mas pode imprimir o atendimento do posto e redigitar no
sistema do hospital”
 Ah, mas pode fazer um sistemão que funcione nos dois lugares”
POR QUE A SAÚDE PRECISA DE
INTEROPERABILIDADE SEMÂNTICA?
Isso (e coisas similares que funcionam em outras indústrias) vem sendo tentado
deste 1961, com gastos de bilhões de dólares e euros, e não tem funcionado

28.  Interoperabilidade semântica é crítica, mas a complexidade
temporal traz um problema incontornável mesmo para
sistemas autocontidos
 Em saúde, você define o seu modelo de dados hoje e ele não
dura 6 meses, porque os conceitos evoluem rápido e novos
conceitos aparecem todo dia
 A média de tempo para que um software médico seja
abandonado é de 2 anos e a taxa de abandono é de 70%
(fonte: CHAOS Report)
UM OUTRO PROBLEMA: MANUTENÇÃO

29.  Muitas coisas (muito caras!) foram e ainda têm sido
propostas para resolver o problema da interoperabilidade
semântica e para reduzir os custos de manutenção dos
aplicativos da área biomédica, sem nenhum resultado
evidente
 Juntando a isto o fato de que a saúde é o setor mais
conservador da sociedade, o resultado é que a saúde é o
único sistema que ainda depende inteiramente de papel
 Lobistas batem à porta dos governos o tempo todo, alegando
terem em mãos a solução para os problemas de
informatização da saúde, e os governos, aflitos com a pressão
política e as queixas sobre a qualidade do sistema de saúde,
entram nessa e desperdiçam centenas de milhões de [moeda]
 As empresas de software não querem desenvolver produtos
para a saúde porque é complicado e os clientes nunca ficam
satisfeitos
CONSEQUÊNCIA

30. Até o momento, a padronização parece ser a
solução para os problemas técnicos da área
de informática em saúde
As duas principais instituições
desenvolvedoras de padrões para a área de
informática em saúde são:
Health Level 7 (HL7)
International Standards Organization (ISO)
SOLUÇÃO: PADRONIZAR (?)

31. Health Level 7 Inc. é a empresa que
desenvolve o padrão HL7 desde 1987
HL7 é um padrão para troca de informações
em saúde credenciado pelo American National
Standards Institute (ANSI)
Há duas versões do padrão HL7:
HL7v2
HL7v3
HL7

32. HL7v2 define uma série de mensagens que
podem ser trocadas entre sistemas
distribuídos
Sempre existe uma certa necessidade de
mapeamento entre mensagens que vêm de
outros sistemas, mesmo que seja dentro da
mesma sub-versão
As mensagens HL7v2 são codificadas em
ASCII (não são XML)
HL7V2 (1)

33. Cada linha de uma mensagem HL7v2 é um
segmento
Os segmentos são compostos por campos
Os campos são delimitados por um caractere
simples
Cada campo pode apresentar compomentes e
subcomponentes
Cada subcomponente tem seu próprio
delimitador único
HL7V2 (2)

34. Os delimitadores são:
Barra vertical (“|”) para os campos
Acento circunflexo (“^”) para os componentes
“E” comercial (“&”) para os subcomponentes
Til (“~”) como o separador de repetições
padrão
HL7V2 (3)

35. O primeiro campo de um segmento contém o
nome do segmento composto por 3 caracteres
Cada segmento da mensagem contém uma
categoria específica de informação
O primeiro segmento é sempre identificado
por “MSH” e contém o tipo de mensagem
O tipo da mensagem define os segmentos que
a compõem
Os nomes dos segmentos são definidos na
documentação do padrão
HL7V2 (4)

36. EXEMPLO DE MENSAGEM HL7V2
MSH|^~&|MegaReg|XYZHospC|SuperOE|XYZImgCtr|20060529090131-
0500||ADT^A01^ADT_A01|01052901|P|2.5
EVN||200605290901||||200605290900
PID|||56782445^^^UAReg^PI||KLEINSAMPLE^BARRY^Q^JR||19620910|M||
2028-9^^HL70005^RA99113^^XYZ|260 GOODWIN CREST
DRIVE^^BIRMINGHAM^AL^35 209^^M~NICKELL’S PICKLES^10000 W 100TH
AVE^BIRMINGHAM^AL^35200^^O |||||||0105I30001^^^99DEF^AN
PV1||I|W^389^1^UABH^^^^3||||12345^MORGAN^REX^J^^^MD^0010^UAMC^
L||678
90^GRAINGER^LUCY^X^^^MD^0010^UAMC^L|MED|||||A0||13579^POTTER^S
HER
MAN^T^^^MD^0010^UAMC^L|||||||||||||||||||||||||||200605290900
OBX|1|NM|^Body Height||1.80|m^Meter^ISO+|||||F
OBX|2|NM|^Body Weight||79|kg^Kilogram^ISO+|||||F
AL1|1||^ASPIRIN
DG1|1||786.50^CHEST PAIN, UNSPECIFIED^I9|||A

37. A versão 3 do padrão HL7 foi desenvolvida
para permitir a modelagem de aplicativos
semanticamente interoperáveis
HL7v3 é baseado em um Reference
Information Model (RIM) que foi convertido na
Norma ISO 21731
Algumas (tentativas de) Implementações:
CDA/CCD/CCR
FHIR
HL7V3 (1)

38. Clinical Document Architecture
Especificação de mensagens de acordo com
HL7v3
Documentos padronizados (XML ou não):
Sumário de Alta, Laudo de Exames, Admissão
e Exame Físico, etc
Convertido na Norma ISO 27932
Base para a implementação do CCR na
especificação CCD
HL7V3 (2) CDA

39. Continuity of Care Record
Padrão para um registro sumário (“salva-vidas”)
dos dados do paciente:
Dados demográficos
Informações sobre o plano de saúde
Lista de problemas
Medicamentos e alergias
Plano terapêutico
Criado por um grupo de empresas de software
médico nos EUA
Gera mensagens padronizadas no formato XML
HL7V3 (3): CCR

40. Continuity of Care Document
Subconjunto do HL7v3 RIM que implementa
os documentos CCR em XML
Hoje em dia, CCR e CCD são padrões rivais no
programa americano de informática médica
denominado Meaningful Use
HL7V3 (4): CCD

41. Fast Healthcare Interoperability Resources
Iniciativa “open source” dentro da HL7 Inc.
Documentos XML abertos para troca de
mensagens entre sistemas
Motivou a iniciativa A New Day Has Dawned,
que abriu o acesso às especificações HL7 até
um certo ponto desde 01/04/2013
HL7V3 (5): FHIR

42. Apesar da iniciativa New Day..., que apresenta
diversas indefinições relativas a questões de
propriedade intelectual, a rigor HL7 ainda é um
padrão comercial
A padronização das mensagens restringe a
modelagem dos conceitos clínicos – a maioria
das mensagens são voltadas para a parte
administrativa dos sistemas
Criou-se uma babel de iniciativas em torno de
Hl7 indo em direções diferentes – a solução
tornou-se parte do problema
Não há registro comprovado de uma única
implementação de prontuários eletrônicos
baseados em HL7v3 RIM
HL7V3 (6): DESAFIOS

43. Definidos na Norma ISO 21090
Especificação de todos os tipos de dados que
podem ser necessários para o registro de
qualquer informação em saúde
Padronização de dados faltantes (missing):
valores excepcionais
A Norma ISO 21090 é o ponto mais forte do
padrão HL7, pois define a granularidade
correta do “ponto de partida” para qualquer
iniciativa bem sucedida de padrão de
interoperabilidade semântica
TIPO DE DADOS HL7V3

44. International Standards Organization – Technical
Committe 215
Comitê Técnico da ISO para a definição de
normas para a área de informática em saúde
6 Grupos de Trabalho:
WG1: Arquitetura
WG2: Interoperabilidade de sistemas e dispositivos
WG3: Conteúdo semântico
WG4: Segurança e Privacidade
WG6: Indústria farmacêutica
WG7: Gerenciamento de risco em redes que
incorporam dispositivos médicos
ISO TC 215

45. A lentidão do processo faz com que iniciativas
mais adequadas à dinâmica tecnológica atual
sejam adotados como padrões de facto antes
de se tornarem Normas ISO (se é que se
tornam)
A representatividade é baseada na capacidade
de participação nas reuniões, não nas
necessidades reais do mercado (produtores ou
consumidores)
Consequência: baixo nível de implementação das
Normas
ISO TC 215: DESAFIOS

46. O PROBLEMA DE FUNDO É...

47. O PROBLEMA DE FUNDO É...

48. O PROBLEMA DE FUNDO É...

49. UMA VIRADA HELIOCÊNTRICA

50. Padrão
heliocêntrico
para a
informática
médica
MODELAGEM
MULTINÍVEL

51. PRINCÍPIOS DE MODELAGEM MULTINÍVEL
Especialista
do domínio
Biblioteca
de conceitos
Vocabulário
do domínio
define
usando
Cientista da
computação
Modelo de
informação
Schema
define
expresso como
A
P
L
I
C
A
T
I
V
O
Persistência
dos dados
instâncias

52. DE UM JEITO MAIS SIMPLES...
Modelo de Referência
Modelagem do Conhecimento
Seu aplicativo (GUI, DSS, BI etc)

53. Em modelagem multinível, o contexto da informação não fica “encarcerado” no
software, porque o Modelo de Referência é composto por classes genéricas
com o “mínimo” de contexto possível
O contexto da informação fica contido, de uma forma intercambiável entre
sistemas, nos Modelos de Domínio
A informação coletada em tempo real durante a consulta terá seu contexto
persistido para sempre: as modificações futuras no software - mantido o
Modelo de Referência estável - nunca mais afetarão seu conteúdo
Estes extratos de informação, contendo o contexto original, corretamente
referenciados no espaço e no tempo, podem ser compartilhados por qualquer
aplicativo baseado no mesmo Modelo de Referência
TRAZENDO O CONTEXTO DE VOLTA

54. MODELAGEM DO DOMÍNIO
Arquétipos (openEHR ou ISO 13606)
CCD (MLHIM)
Concept
Constraint
Definition

55. 2013:
Convergência espontânea entre openEHR e
MLHIM
ISO 13606 está sob revisão
2009:
MLHIM é lançado
Virada do século 21:
Cook abandona o TORCH e se torna
voluntário no ARB da Fundação openEHR
openEHR vai para a ISO e negocia a família
de Normas 13606
Últimos anos do século XX:
Europa: o projeto GEHR se torna openEHR EUA: Cook desenvolve o TORCH
HISTÓRIA

56. O PROBLEMA KEPLERIANO DA
MODELAGEM MULTINÍVEL

57. MODELO HELIOCÊNTRICO PARA UM
MUNDO REAL

58. MODELAGEM MULTINÍVEL: ENFOQUES
openEHR MLHIM 13606Modelos
(Quase)
Maximalista
Minimalista ReducionistaEnfoque
(Quase) Máximo
Qualquer
tamanho (Sob revisão)
Modelo de
Dados
Exceto móvel que
receba dados
Qualquer
aplicativo
Somente troca de
mensagens
Implementação
possível
Muito Mínimo Intermediário
Resíduo de
contexto no
MR

59. MODELAGEM MULTINÍVEL DO
CONHECIMENTO
openEHR MLHIM 13606Modelos
Arquétipo CCD ArquétipoEstrutura
(Mais que) uma n (Sob revisão)
# de
estruturas /
conceito
Parcialmente
centralizado
De baixo para
cima
(Sob revisão)
Modelo de
governança
ADL XML Schema 1.1 ADLLinguagem

60. OBRIGADA!
lutricav@lampada.uerj.br
Agradecimentos especiais:
Tim Cook
CE-CAS