Padr�es de interoperabilidade para os Sistemas de Informa��es

Document Sample
Padr�es de interoperabilidade para os Sistemas de Informa��es Powered By Docstoc
					PADRÕES DE
INTEROPERABILIDADE
PARA OS SISTEMAS DE
INFORMAÇÕES EM SAÚDE


 Ramon Alfredo Moreno
 ramon.moreno@incor.usp.br
RESUMO
   PARTE 1                     PARTE 2
     Sistemas de                   CID-10
      Informação no Brasil          LOINC
     Interoperabilidade            SNOMED CT
         O que                     TISS
         Porquê
                                    HL7
         Como
                                    DICOM
       Padrões
           Terminologias           IHE
     Ontologias                    openEHR
     Arquétipos                PARTE 3
                                    Exercícios
PARTE 1
SISTEMAS   DE INFORMAÇÃO NO      BRASIL
 A informatização de Hospitais públicos
  começou entre 1970 e 1980 a partir do
  Decreto-Lei no. 200 de Fev. 1967 (Castello);
 Reforma gerencial / administrativa
  valorizando uso do computador e
  descentralizando a gerência do país;
 Em 1974 é criada a Empresa de Tecnologia e
  Informações da Previdência Social
  (Dataprev);
 Em 1974 é criada a Companhia de
  Processamento de Dados do Estado de São
  Paulo (PRODESP);
SISTEMAS   DE INFORMAÇÃO NO    BRASIL
 Na década de 80 hospitais públicos
  desenvolvem sistemas próprios para atender
  necessidades locais, não fornecidas pelo
  Estado;
 Desenvolvimento de Sistemas de Informação
  Hospitalar (SIH), inicialmente voltados ao
  gerenciamento de contas;
 Constituição de 1988 define a saúde como
  "direito de todos e dever do Estado“;
SISTEMAS   DE INFORMAÇÃO NO    BRASIL
 Em 1988 é criado o Sistema Único de Saúde
  (SUS) substituindo o Instituto Nacional de
  Assistência Médica da Previdência Social
  (INAMPS) – universalização do tratamento
  médico as pessoas no Brasil;
 Funcionamento do SUS em três esferas:
  nacional, estadual e municipal;
 Em 1991 é criado o DATASUS – departamento
  de informática do SUS. Responsável pela
  coleta, processamento e divulgação de
  informações sobre saúde (antes DATAPREV);
SISTEMAS   DE INFORMAÇÃO NO    BRASIL
Bases de dados gerenciadas pelo DATASUS:
 CNES (Cadastro Nacional de
  Estabelecimentos de Saúde) – 2003. Área
  Física, Recursos Humanos, Equipamentos e
  Serviços Ambulatoriais e Hospitalares
  (TODOS);
 Sistema de Informação sobre Mortalidade
  (SIM) – 1975. Declaração de óbito;
 Sistema de Informações sobre Nascidos
  Vivos (SINASC) – 1990. Declaração de
  Nascido Vivo (DNV);
SISTEMAS   DE INFORMAÇÃO NO      BRASIL
 Sistema de Informação de Agravos de
  Notificação (SINAN) – 1993. Doenças de
  notificação compulsória (ex.: tuberculose,
  hanseníase, dengue, AIDS);
 Sistema de Informações Hospitalares do
  Sistema Único de Saúde (SIH/SUS) – 1983.
  Autorização de Internação Hospitalar (AIH);
 Sistema de Informações Ambulatoriais do
  Sistema Único de Saúde (SIA/SUS) – 1993.
  Tabela de Procedimentos Ambulatoriais /
  Autorização de Procedimentos Ambulatoriais
  de Alta Complexidade (APAC);
SISTEMAS     DE INFORMAÇÃO NO     BRASIL
   Sistema de Informação da Saúde Básica
    (SIAB) – 1998. Cadastramento familiar,
    condições de moradia, saneamento, situação
    de saúde. Fichas A, B, C e D;

 Final de 1990 início 2000, hospitais começam
  a adotar sistemas PACS (Picture Archiving
  and Communication Service).
  Discussão/implementação do Prontuário
  Eletrônico do Paciente (PEP);
 Em 1996 é criado o Cartão Nacional de
  Saúde (CNS). Identificação única de cada
  pessoa no país. Cadastro território nacional;
SISTEMAS   DE INFORMAÇÃO NO     BRASIL
 Em 2002, o Conselho Federal de Medicina
  (CFM) recomenda as normas da SBIS para
  certificação dos Sistemas de Registro
  Eletrônico de Saúde (S-RES);
 Em 2005 é criado o TISS (Troca de
  Informação de Saúde Suplementar).
  Padronização da troca de informações entre
  as operadoras de planos e seguros-saúde e
  prestadores de serviço;
 Na mesma resolução é criado o COPISS
  (Comitê de Padronização das Informações
  em Saúde Suplementar);
SISTEMAS   DE INFORMAÇÃO NO      BRASIL
 Em 2007 resolução da ANS (Agência
  Nacional de Saúde) torna obrigatório os
  requisitos de segurança nível 1 (NGS-1) da
  SBIS/CFM;
 Em 2009 a ANS torna obrigatório o uso do
  TUSS (Terminologia Unificada em Saúde
  Suplementar) na comunicação entre
  operadoras e provedoras;
 Em Agosto 2011, Portaria No.2.073 define
  adoção de padrões de interoperabilidade pelo
  SUS: Web Services, openEHR, SNOMED CT
  (clínico), LOINC (laboratorial), HL7-CDA.
NO   MUNDO

 1983 – ACR/NEMA 300;
 1985 – ACR/NEMA (“DICOM 1.0”);

 1986 - Unified Medical Language System
  (UMLS);
 1987 – Fundação do HL7 (Health Level 7);

 1988 – ACR/NEMA (“DICOM 2.0”);

 1989 – HL7 versão 2;

 1992 – ICD-10 (International Classification
  of Diseases);
NO   MUNDO

 1993 – DICOM 3.0;
 1994 – LOINC (Logical Observation
  Identifiers Names and Codes);
 1996 – Assinatura do HIPAA (Health
  Insurance Portability and Accountability Act);
 1997 – Integrating the Healthcare Enterprise
  (IHE)
 2002 – SNOMED CT;

 2006 – HL7 versão 3 / openEHR.
INTEROPERABILIDADE – O                                          QUE


   O que é interoperabilidade?

   Segundo a IEEE* é “a habilidade de dois ou
    mais sistemas trocarem informações e serem
    capazes de utilizar a informação trocada” **

   Basicamente: “falar e ser entendido”
    (computacionalmente)



* IEEE: Institute of Electrical and Electronics Engineers
** IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, New York, NY (1990).
INTEROPERABILIDADE – O          QUE

Tipos de interoperabilidade:

   Interoperabilidade
    funcional (ou sintática):
    mesmo meio de
    comunicação (ex: som,
    sílabas, sujeito, verbo,
    objeto);

   Interoperabilidade
    semântica: significado
    compreensível (mesmos
    conceitos)
INTEROPERABILIDADE – O        QUE

Padrões abertos x interoperabilidade:

   Interoperabilidade não precisa
    necessariamente ser realizada sobre padrões
    abertos. Simplesmente indica que há
    compreensão entre as mensagens trocadas;

   Padrões abertos contam com a participação
    de vários grupos na sua elaboração e o
    documento final forma um padrão comum,
    consensual, e, portanto, interoperável.
INTEROPERABILIDADE - PORQUÊ
Porque interoperar?
 Necessário integrar sistemas internos e
  externos das Instituições:
     Em geral, o sistema de um único vendedor não
      atende todas as necessidades (+q 1 vendedor);
     Reutilizar informações entre sistemas;
     Sistemas integrados permitem visão geral dos
      processos pelos Gestores (consolidar dados);
     Automatização de processos.

   Em nível governamental: epidemiologia,
    estatísticas nacionais, gerenciamento de
    recursos, transparência, política de saúde
INTEROPERABILIDADE - PORQUÊ
Exemplos na saúde:
 Em 1980 somente os fabricantes conseguiam
  abrir as imagens de aparelhos de RM e CT.
  Necessidade de determinar a dose de
  radiação aplicada em radioterapia (câncer).
  Criado o padrão DICOM (ACR e NEMA);
 Maio de 2012: Sistemas de Holter são
  diferentes para cada fabricante. A entrada de
  dados é manual (Cardios, GE, Philips), com
  informações diferentes em cada aparelho.
  Produzidos 1000 exames /mês – 20 fls
  impressas cada exame.
INTEROPERABILIDADE - COMO
   A interoperabilidade pode ser obtida com a
    adoção de um ou mais PADRÕES (abertos ou
    não);

   Para atingir a interoperabilidade é necessário
    compreensão funcional e semântica;

   Alguns exemplos de padrões são:
     Web Services;
     TCP/IP;
     XML;
     HL7.
PADRÕES - DEFINIÇÃO
   Segundo o Houaiss: “base de comparação,
    algo que o consenso geral ou um
    determinado órgão oficial consagrou como
    um modelo aprovado”;

   Segundo a ISO, “É um documento
    estabelecido por consenso e aprovado por
    um grupo reconhecido, que define para uso
    geral e repetido um conjunto de regras,
    protocolos ou características de processos
    com o objetivo de ordenar e organizar
    atividades em contextos específicos para o
    benefício de todos” *
*ISO apud http://www.hl7brasil.org.br/arquivos/tutorial7_hl7_padroes.pdf
PADRÕES - CRIAÇÃO
Padrões podem ser estabelecidos de diversas
  formas *:
   De facto: estabelecido na prática pelas
    condições do mercado. Ex.: Windows, UNIX;
   Ad hoc: obtido para a solução específica para
    um determinado problema por um grupo de
    interessados. Ex: DICOM;
   Governo: determinado por lei. Ex.: FDA,
    ANVISA;
   Consenso formal: estabelecido por um grupo
    de participantes. Ex.: HL7, openEHR
* Adaptado de http://www.hl7brasil.org.br/arquivos/tutorial7_hl7_padroes.pdf
PADRÕES - CRIAÇÃO
Para o estabelecimento de padrões FORMAIS em
  saúde existem várias organizações:
 ABNT –Associação Brasileira de Normas Técnicas

 ANSI - American National Standards Institute
       HL7, ACR/NEMA DICOM, ASC X12, ASTM,
        IEEE/MEDIX, NCPDP
   CEN - European Committee for Standardization
       CEN/TC 251 -Health Informatics
   ISO -International Standards Organization
       ISO/TC 215 -Health Information and
        Communications Technology
PADRÕES - CRIAÇÃO
   Exemplo de processo formal de adoção de padrão (ISO):
0) Investigação – verifica necessidade de criar um novo
    padrão
1) Proposta – submetida uma proposta ao Joint Technical
  Committee 1 (JTC 1). JTC 1 aceita ou não;
2) Preparatório – Subcomitê cria um grupo de trabalho
  para o tema – acerta detalhes técnicos. Pode levar até 3
  anos;
3) Comitê – registro da proposta como “draft” – recebe
  votação deve justificar cada comentário negativo
  recebido;
4) Aprovação – Vira “final draft” submetido a votação –
  pode voltar estagio anterior;
5) Publicação – Aprovado para publicação
PADRÕES - TIPOS
Os padrões em saúde podem ser estabelecidos
 para diferentes áreas*:
   Aquisição de dados: sinais, imagens, áudio
    (Ex.: DICOM);
   Comunicação: troca de mensagens entre
    sistemas e interfaces de comunicação (Ex.:
    HL7);
   Representação: terminologias, conhecimento
    e modelos conceituais (Ex.: SNOMED);
   Outros: segurança, serviços, middleware.

* Adaptado de http://www.hl7brasil.org.br/arquivos/tutorial7_hl7_padroes.pdf
PADRÕES - VOCABULÁRIOS MÉDICOS
   Grupo de termos padronizado com significado
    claramente estabelecido.

Exemplos:
   CID-10. Ex.: A95.1 (Febre amarela urbana)
   SNOMED CT. Ex.: 74166005 (Urban yellow fever
    (disorder));
   UMLS. Ex.: CUI C0043398 (URBAN YELLOW
    FEVER);
   LOINC. Ex.: 8310-5 (BODY
    TEMPERATURE:TEMP:8H^MAX:XXX:QN -
    componente:propriedade:intervalo:forma
    amostragem:escala)
PADRÕES – CONTEÚDO     E ESTRUTURA

 Determinam a estrutura da informação e
  quais dados são trocados;
 Podem ser complexos. Auxiliam na formação
  do Registro Eletrônico de Saúde (RES);

Exemplos:

 DICOM;
 HL7 v3;

 openEHR.
ONTOLOGIAS
 Descrição  estruturada do
  conhecimento;
 Especificação formal explícita dos
  termos pertencentes a um domínio e
  as relações entre eles:
     Definição de entidades;
     Propriedades de cada entidade;
     Relacionamento entre as entidades
      representadas.
 Base   de conhecimento (instâncias).
                                       (Adaptrado de Noy)
                    Ontologias - ASB                    27
ONTOLOGIAS - UTILIZAÇÃO
Em medicina:
 Existem na forma de:
     Vocabulários padronizados;
     Sistema de terminologias.
 Uso:
     Indexação de artigos;
     Alimentação de sistemas como o PEP, por
      exemplo;
     Padronização de vocabulário em laudos;
     Etc...
 Exemplos:
     UMLS, SNOMED-CT, RadLex, CID10, Mesh,
      ...
                     Ontologias - ASB           28
ONTOLOGIAS - CRIAÇÃO
 Desenvolvidas       por especialistas em
  cada área;
 Definição de termos e relacionamentos
  Domínio pré-determinado (Ex.:
   Laboratório);
  Estrutura hierárquica
      Classes e subclasses;
      Slots (atributos);

      Restrições.


 Base   de conhecimento
    Classes instanciadas com slots preenchidos.
                       Ontologias - ASB       29
ONTOLOGIAS - EXEMPLOS
   Pizzas – um tipo de
    comida, com diversos
    sub-tipos (veg.,
    queijo, etc..)
ONTOLOGIAS - EXEMPLOS
   SNOMED-CT pode ser
    visto como uma
    Ontologia (programa
    Minnow), assim como
    UMLS e CID-10.
ARQUÉTIPOS      E   TEMPLATES
   Utilizados pelo OpenEHR e CEN TC/251 e
    compatível com HL7/CDA;

   Arquétipo: modelo de um conceito bem
    definido. Ex: pressão sanguínea, peso,
    altura, etc.

   Template: define como arquétipos podem ser
    reunidos para representar uma informação;

   Possível aplicar restrições sobre os dados,
    como em Ontologias.
ARQUÉTIPOS          E   TEMPLATES *

Verificação de diabetes                                 Visita pré-natal
                                Arquétipos
Pés formigando e                                        Dor nas costas
                                 Freq. Card.
Sensação de cansaço
                                                        66 Kg
                                    Peso
76 Kg
                                  Pressão               102/64 mmHg
124/92 mmHg
                                   HbA1c                142/ min
7%                               Problema
                                                        Nenhum problema
Controle muito bom               Avaliação              encontrado.
Da diabete


 *Adaptado de http://hl7.org.uk/repository/uploads/508/1/070223_CDA_BEALE.pdf
PARTE 2
PARTE 2 - RESUMO
Padrões de interoperabilidade em Saúde
 CID-10;

 LOINC;

 SNOMED CT;

 TISS;

 HL7;

 DICOM;

 IHE;

 openEHR.
CODIFICAÇÃO INTERNACIONAL                       DE   DOENÇAS
 Criado em 1992;
 Classifica uma grande variedade de doenças;

 Presente nas AIHs (Autorização de Internação
  Hospitalar) e APACs (Autorização de
  Procedimentos Ambulatoriais de Alta
  Complexidade), portanto, utilizado em todos os
  hospitais que atendem o SUS;
 Organizada por grupos. Ex.:
       A00-B99 Algumas doenças infecciosas e parasitárias
           A90-A99 Febres por arbovírus e febres hemorrágicas virais
              A95 – Febre Amarela

                  A95.1 Febre amarela urbana
CODIFICAÇÃO INTERNACIONAL   DE   DOENÇAS
   Capítulos do CID-10
LOINC - LOGICAL OBSERVATION
IDENTIFIERS NAMES AND CODES
 Criado em 1994;
 Padrão para identificação de observações
  laboratoriais;
 Posteriormente, evoluiu para incluir
  diagnósticos de enfermagem, intervenções
 Uso público (grátis);

 Contem mais de 58.000 entradas no banco,
  cada uma com um identificador único;
 Permite a integração dos resultados de
  laboratório com o prontuário do paciente
  (RES);
LOINC - LOGICAL OBSERVATION
IDENTIFIERS NAMES AND CODES
   Formato é baseado em um nome único dividido em 6
    campos:
    1.   Componente (o que é medido)
    2.   Propriedade medida (SCnc=Concentração Substância)
    3.   Tempo (Pt=medida pontual)
    4.   Sistema (Aonde a medida foi realizada)
    5.   Escala (Qn=quantidade)
    6.   Método (procedimento p/ a medida - opcional)
   Exemplos:
     Sodium:SCnc:Pt:Urine:Qn
     Sodium:SRat:24H:Urine:Qn
     Creatinine renal clearance:VRat:24H:Ur+Ser/Plas:Qn
     Glucose^2H post 100 g glucose PO:MCnc:Pt:Ser/Plas:Qn
LOINC - LOGICAL OBSERVATION
IDENTIFIERS NAMES AND CODES
   Ferramenta RELMA disponível site LOINC (270 MB)
SYSTEMATIZED NOMENCLATURE OF MEDICINE -
CLINICAL TERMS (SNOMED-CT®)
 Criado em 2002 a partir da união do
  SNOMED RT (Reference Terminology) e o
  Clinical Terms do Serviço de Saúde Britânico;
 O sistema de nomenclaturas mais completo
  para termos clínicos;
 Necessária uma licença para a utilização em
  produção;
 Para pesquisa científica, demonstração,
  avaliação, uso por países sub-desenvolvidos
  a licença é gratuita;
 Existem vários browsers para visualizar o
  SNOMED CT. Ex.: Minnow
EXEMPLO: MINNOW
SYSTEMATIZED NOMENCLATURE OF MEDICINE -
CLINICAL TERMS (SNOMED-CT)
 O SNOMED CT fornece uma forma
  padronizada de representação de condições
  médicas e sintomas, eliminando a confusão
  que poderia surgir com o
  uso de termos coloquiais;
 É uma Ontologia
  descrevendo condições
  médicas e sintomas;
 Descreve relações entre
  termos;
 Mais de 360.000 conceitos

 Mais de 1.400.000 relac.
SYSTEMATIZED NOMENCLATURE OF MEDICINE -
CLINICAL TERMS (SNOMED-CT)
Estrutura baseada em :
 Conceitos (90539001);

 Descrições (Aneurisma
  ventricular);
 Hierarquias (seguinte);

 Relacionamentos (IS-A
  Aneurisma do coração, IS-
  A desordem do ventrículo
  cardíaco, morfologia
  associada: Aneurisma,
  Localização: estrutura
  ventricular cardíaca).
SYSTEMATIZED NOMENCLATURE OF MEDICINE -
CLINICAL TERMS (SNOMED-CT)
 Hierarquias: relação do tipo
  “IS-A”;
 Relação pai/filho;

 Herda as mesmas
  características do pai;




   Mostrar programa
TISS - TROCA DE INFORMAÇÃO EM SAÚDE
SUPLEMENTAR
 Criado em 2005;
 Padrão definido pela ANS (Agencia Nacional
  de Saúde);
 Padroniza a troca de informações entre
  operadoras privadas (Sul América, Bradesco
  Saúde, Unimed, etc.) e prestadores
  (hospitais, laboratórios, etc.);
 Pagamento de serviços das prestadoras;

 Objetivo de atingir interoperabilidade
  funcional e semântica;
 Antes uma guia diferente para cada
  operadora;
TISS - TROCA DE INFORMAÇÃO EM SAÚDE
SUPLEMENTAR
Padrões adotados pelo TISS:
 Comunicação: Web Service (opcional);

 Codificação: XML + XML Schema;

 Vocabulário: TUSS (Terminologia Unificada
  em Saúde Suplementar) - procedimentos
  médicos;
 Privacidade: normas do CFM / SBIS
  (Sociedade Brasileira de Informática em
  Saúde)
TISS - TROCA DE INFORMAÇÃO EM SAÚDE
SUPLEMENTAR
Mensagens padronizadas do TISS:
 Solicita Elegibilidade;
 Solicita Autorização;
 Envio de Lotes de Guias;
 Envio de Lote de Guias de revisão de glosa;
 Solicitação de Demonstrativo de Pagamento;
 Solicitação do Status do Protocolo;
 Cancela Guia;
 Confirmação de Elegibilidade;
 Protocolo de Recebimento;
 Autorização de Procedimentos;
 Status do Protocolo.
TISS - TROCA DE INFORMAÇÃO EM SAÚDE
SUPLEMENTAR
Exemplos do TUSS:
 20101210 - Acompanhamento clínico
  ambulatorial pós-transplante de córnea;
 20102020 - Holter de 24 horas - 3 canais –
  digital;
 20103166 - Confecção de prótese imediata;
 30101042 - Alopecia parcial - rotação múltipla
  de retalhos;
 30101247 - Curetagem e eletrocoagulação de
  CA de pele (por lesão);
 30720079 - Encurtamento segmentar dos ossos
  do antebraço com osteossíntese - tratamento
  cirúrgico
PADRÃO HL7
HEALTH LEVEL 7 - HL7
 Instituição fundada em 1987;
 Acreditado pelo ANSI (American National
  Standards Institute);
 Desenvolve padrões internacionais para
  interoperabilidade em saúde;
 Desenvolve:
     Padrões conceituais (HL7 RIM);
     De documentos (HL7 CDA);
     Serviços (CCOW);
     Mensagens (HL7 v2.X e v3.0).

   Para poder utilizar o padrão (produção) é
    necessário filiação ao HL7 (e.g.: HL7 Brasil);
HEALTH LEVEL 7 - HL7
   Termo HL7 se refere normalmente ao padrão
    de mensagens:
     V2.x – original;
     V3.0 – conceitos atuais.



   A versão 2 foi criada em 1988;

   A versão 3 começou em 1995 e foi publicada
    em 2005;
HEALTH LEVEL 7 - HL7 V2.X
 v2.0 – 1988;
 2.1, 2.2, 2.3, 2.3.1, 2.4, respectivamente,
  em 90, 94, 97, 99, 00;

Exemplos de mensagens trocadas (admin):
 Admissão do paciente;

 Resultado de exame de laboratório;

 Faturamento da conta do paciente.



   Formato ASCII com separador “|” (pipe) –
    simples.
HEALTH LEVEL 7 - HL7 V2.X
Admissão do paciente (versão 2.3)*:




Mensagem de laboratório (versão 2.4)**:




* http://projetos.inf.ufsc.br/arquivos_projetos/projeto_377/TCCparte1.doc
** http://www.ringholm.de/docs/04300_en.htm
 HEALTH LEVEL 7 - HL7 V2.X
 Limitações (*):
  Sem modelo explícito de dados e, portanto,
   contem referências ambíguas entre
   segmentos (conceitos mal-definidos);
  Não determina uso de termos codificados
   como valores;
  É um formato de troca de dados, não de
   interoperabilidade;
  Cada vendedor implementa sua
   “interpretação” do modelo. Na prática,
   configuração par-a-par.

* http://ncicb.nci.nih.gov/content/ncicblfs/caAdapter/caAdapter_4_0/NIHSeminar_Charlie%20Mead.ppt
HEALTH LEVEL 7 - HL7 V3.0
 Desenvolvido para resolver os problemas da
  versão anterior;
 Feito para interoperabilidade;

 Modelo explícito de dados (Reference
  Information Model - RIM);
 Vocabulário claramente determinado;

 Baseado em XML;

 Complexo;

 Levou 10 anos para ser elaborado.
HEALTH LEVEL 7 - HL7 V3.0 (RIM)
HEALTH LEVEL 7 - HL7 V3.0 (EXEMPLO**)
HEALTH LEVEL 7 - HL7 V3.0 (EXEMPLO**)
HEALTH LEVEL 7 - HL7 V3.0 (EXEMPLO**)
HEALTH LEVEL 7 - HL7 V3.0 (EXEMPLO**)




    ** http://www.ringholm.de/docs/04300_en.htm
HL7 CDA - DOCUMENTOS
   HL7 CDA - Clinical Document Architecture

   CDA define uma arquitetura para criação de
    XMLs estruturados para a troca (exchange)
    de documentos clínicos (RES);

   O CDA se baseia no HL7 Reference
    Information Model (RIM) e tipos de dados
    pré-definidos (Data Types);
CLINICAL DOCUMENT ARCHITECTURE - CDA
   Palavra-chave para CDA é “Documento”;

   Uma instância do CDA não pretende conter
    toda informação de um prontuário do
    paciente;

   O CDA pode incluir:
       Referências (link);
       Texto;
       Imagens;
       Sons;
       Outros elementos multimídia.
CLINICAL DOCUMENT ARCHITECTURE - CDA
 CDA é composto de:
a) Parte textual (para interpretação humana);

b) Parte estruturada (para processamento pelo
    computador).
 A parte estruturada se baseia em codificação
  padronizada, como o SNOMED (Systematized
  Nomenclature of Medicine) e o LOINC
  (Logical Observation Identifiers Names and
  Codes).
 O CDA não define como os documentos são
  transmitidos. Assim, podem-se utilizar HL7
  v2, HL7 v3, e-mail, ftp e até mesmo DICOM.
CDA - NÍVEIS
 Os documentos CDA podem ser criados com um
  dos três níveis crescentes de complexidade:
Nível 1: Cabeçalho codificado. Corpo do documento é
estrutural (ex.: parágrafo), embora códigos possam
ser inseridos;

Nível 2: Nível anterior + uso de Templates (modelos)
para definir o corpo do documento (tags);

Nível 3: Nível anterior + uso de codificação até o
nível definido no RIM (Reference Information Model).
Objetiva interoperabilidade computacional.
CDA – NÍVEIS                    DE     COMPLEXIDADE
   Nível 1: ‘Human readable’ – interoperabilidade
    em nível de interpretação humana (estrutural)




Fonte: http://www.srdc.metu.edu.tr/webpage/seminars/Healthcare/Clinical%20Document%20Architecture.ppt
CDA – NÍVEIS                    DE     COMPLEXIDADE
   Nível 2: Permite a criação de agrupamentos
    (sections) mais específicos, com uso de Templates.




Fonte: http://www.srdc.metu.edu.tr/webpage/seminars/Healthcare/Clinical%20Document%20Architecture.ppt
CDA – NÍVEIS                    DE     COMPLEXIDADE
   Nível 3: ‘Machine readable’ – interoperabilidade
    em nível de interpretação computacional (valores
    codificados)




Fonte: http://www.srdc.metu.edu.tr/webpage/seminars/Healthcare/Clinical%20Document%20Architecture.ppt
CDA - ESTRUTURA
Um documento CDA é composto de duas
partes:



   Cabeçalho – dados estruturado;

   Corpo – estrutura varia de acordo com o
    Nível de complexidade.
CDA – ESTRUTURA
   Diagrama lógico da estrutura do CDA
CDA - CABEÇALHO
 Constante em todos os documentos.
  Independe do Nível;
 É estruturado;

 Tem informações de emissor e receptor da
  informação;
 Tem detalhes do paciente (nome, id, etc.);



   É elaborado com propósito de permitir o
    intercâmbio de documentos entre
    Instituições.
CDA - CABEÇALHO
Composto de 4 partes
lógicas:
 Informação sobre o
  documento;
 Dados da admissão
  (encounter);
 Service actors (ex.:
  provedores);
 Service targets (ex:
  pacientes)
EXEMPLO CABEÇALHO
   Exemplo de informações do cabeçalho
CDA – DEFINIÇÃO   DO CABEÇALHO
CDA - CORPO

   Depende do nível de complexidade e da
    padronização definida.




   Exemplos a seguir.
EXEMPLO        CORPO DE         CDA – NÍVEL 1
<!-- CDA Document Header -->
...
<!-- CDA Document Body -->
<component>
<structuredBody>
<component>
   <section>
   <title>History of Present Illness</title>
   <text>
   <content styleCode="Bold">Henry Levin, the 7<sup>th</sup> </content>
         is a 67 year old male referred for further asthma management.
         Onset of asthma in his <content revised="delete">twenties</content>
         <content revised="insert">teens</content>.
         He was hospitalized twice last year, and already twice this year.
         He has not been able to be weaned off steroids for the past several
         He was hospitalized twice last year, and already twice this year.
   </text>
   </section>
</component>
</structuredBody>
</component>
EXEMPLO    CORPO DE     CDA – NÍVEL 2
Especificação:




+ Implementação:
<!-- CDA Document Body -->
<component>
 <structuredBody>
 <component>
  <section>
   <code code='10157-6' codeSystem='2.16.840.1.113883.6.1'/>
   ...
 </component>
 <component>
   <section>
   <code code='26436-6' codeSystem='2.16.840.1.113883.6.1'/>
   ...
  </component>
</structuredBody>
</component>
EXEMPLO       CORPO DE       CDA – NÍVEL 3
Especificação + Implementação + Codificação

<section>
  <code code="10153-2" codeSystem="2.16.840.1.113883.6.1"
codeSystemName="LOINC"/>
  <title>Past Medical History</title>
  <text> There is a history of <content ID="a1">Asthma
</content></text>
  <entry>
    <Observation>
      <code code="84100007" codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT" displayName="history taking (procedure)"/>
      <value xsi:type="CD" code="195967001"
codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"
displayName="Asthma">
          <originalText>
            <reference value="#a1"/>
          </originalText>
      </value>
   </Observation>
  </entry>
</section>
EXEMPLO CDA      COMPLETO




   A seguir exemplo de documento CDA
Paciente
CDA – TEMPLATES
   Templates limitam conteúdo do corpo do CDA;
   São definidos por “domain experts”;
   Podem ser definidos regionalmente;
   O HL7 espera que, futuramente, possam-se
    estabelecer padrões internacionais para troca de
    documentos;
   Atualmente estão sendo definidos padrões para o
    CDA nos EUA (CCD – Continuity of Care
    Document - ANSI). Outros países estudando;
   Os templates são definidos através de um
    “implementation guide”, descrito pelos
    interessados em trocar documentos.
CDA – TEMPLATES
   Validação com regras (e.g. schematron) permite
    estabelecer restrições mais complexas
<pattern name='required-sections' see='&baseURI;#Body'>
  <rule id='top-level' context='cda:structuredBody'>
    <assert diagnostics='CNF-5' test='cda:component/cda:section[cda:code/@code="X-
COND"]'>
A main section must be present with a code value of <emph>X-COND</emph>.
    </assert>
    <assert diagnostics='CNF-8'
test='cda:component/cda:section[cda:code/@code="10155-0"]'>
A main section must be present with a code value of <emph>10155-0</emph>.
    </assert>
    <assert diagnostics='CNF-9' test='cda:component/cda:section[cda:code/@code="X-
MEDS"]'>
A main <emph>section</emph> must be present whose <emph>code</emph>
is <emph>X-MEDS</emph>.
    </assert>
  </rule>
</pattern>
CDA – ENCAPSULAMENTO
 O documento CDA pode ser encapsulado
  como pacotes MIME dentro de mensagens
  HL7;
 Pode ser usado qualquer evento/mensagem
  que suporte troca de documentos.




Fonte: http://www.srdc.metu.edu.tr/webpage/seminars/Healthcare/Clinical%20Document%20Architecture.ppt
USOS DO CDA

No Brasil: SIGA (Sistema Integrado de Gestão
de Atendimento) – SADT (Cidade de São Paulo):
 Utiliza um CDA modificado;

 Realiza integração de UBS (Unidade Básica de
  Saúde) com sistemas de laboratório;
 Arquitetura:


                 Envelope SOAP


          CDA Body + Tags traduzidas
          + Ajustes para resultados de
              laboratório no Brasil
CDA
 CDA é complexo;
 Para adoção é necessário “experts” que
  conheçam o trabalho desenvolvido no HL7
  (RIM, DIM, MIM, processos internos, etc.);
 Preciso “lucro” para justificar investimento +
  tempo para que sejam desenvolvidos
  templates específicos para Instituições;
 Adoção do HL7 v3 e CDA tem sido bastante
  lenta, mas gradualmente crescente no
  mundo;
 SIGA relata que complexidade do HL7
  dificultou elaboração de sistema real (ref!).
PADRÃO DICOM
 1. Agenda                               6. Visualização




                   Exemplo fluxo
                    de imagens                         C-FIND
2. Registro/Admissão                                   C-MOVE



                                   5. Armazenamento (PACS)




  3. Setor Exames (espera)
                             4. Realização Exame
                       WORKLIST                    C-STORE
PADRÃO DICOM
 Padrão desenvolvido por um comitê conjunto
  entre ACR (the American College of Radiology) e
  NEMA (the National Electrical Manufacturers
  Association);
 Objetivo: Transmissão e armazenamento de
  imagens médicas de maneira padronizada;
 Versão 1 (1985): ACR-NEMA 1.0;

 Versão 2 (1988): ACR-NEMA 2.0;

 Versão 3 (1993): DICOM 3.0;

 O padrão é estruturado como um documento de
  várias partes (atualmente 20) e suplementos:
PADRÃO DICOM
 PS 3.1: Introduction and Overview;
 PS 3.2: Conformance;
 PS 3.3: Information Object Definitions (núcleo
  do DICOM);
 PS 3.4: Service Class Specifications;
 PS 3.5: Data Structure and Encoding;
 PS 3.6: Data Dictionary;
 PS 3.7: Message Exchange;
 PS 3.8: Network Communication Support for
  Message Exchange;
PADRÃO DICOM
 PS 3.9: Point-to-Point Communication
  Support for Message Exchange;
 PS 3.10: Media Storage and File Format for
  Data Interchange;
 PS 3.11: Media Storage Application Profiles;
 PS 3.12: Storage Functions and Media
  Formats for Data Interchange;
 PS 3.13: Print Management Point-to-Point
  Communication Support;
 PS 3.14: Grayscale Standard Display
  Function;
PADRÃO DICOM
 PS 3.15: Security and System Management
  Profiles
 PS 3.16: Content Mapping Resource

 PS 3.17: Explanatory Information;

 PS 3.18: Web Access to DICOM Persistent
  Objects (WADO)
 PS 3.19: Application Hosting;

 PS 3.20: Transformation of DICOM to and
  from HL7 Standards
DICOM
Partes mais importantes para entendimento
  inicial são:

   PS 3.3: O “Modelo” do DICOM;

   PS 3.5: Como se codifica o DICOM;

   PS 3.7: Como se transmite o DICOM;

   PS 3.10: Como se armazenam os arquivos
    DICOM.
PADRÃO DICOM
    Modelo de imagens médicas:
ARQUIVOS DICOM

   O arquivo DICOM é organizado em um header
    (cabeçalho) seguido de uma ou mais imagens




     HEADER       IMG 1     IMG 2   ...    IMG N




                    IMAGEM DICOM
ARQUIVOS DICOM
   O header é composto de diversas tags
    (marcadores) que contem informações sobre
    o paciente e sobre a imagem adquirida.




    ASSINATURA   TAG 1    TAG 2   ...    TAG N




                         HEADER
PADRÃO DICOM
     Atributos e tags:
ARQUITETURA
 Arquitetura Cliente-Servidor:
  Cliente (Service Class User - SCU)

  Servidor (Service Class Provider - SCP)



                 Protocolo DICOM
                  de comunicação




       SCU                          SCP
COMUNICAÇÃO DICOM

   Comunicação é feita Ponto a Ponto;

   Cada entidade assume papel de cliente ou
    servidor;

   Cada entidade envolvida na comunicação é
    identificada pela tripla:
     AE Title: Nome da entidade. Ex.: “ANGIO1”
     Host: IP ou nome de rede. Ex.: “192.168.0.1”
     Port: Porta para comunicação: Ex.: “104”
COMUNICAÇÃO DICOM

Serviços para imagens:
 C-ECHO: Equivalente ao “ping”;

 C-FIND: Pesquisa por imagens;

 C-STORE: Armazenamento de imagem;

 C-GET: Recuperação de imagem;

 C-MOVE: Transferência de imagens entre duas
  entidades.
COMUNICAÇÃO DICOM

Outros serviços:
 N-GET: recupera alguma informação;

 N-SET: modifica uma informação;

 N-ACTION: Solicita realização de uma ação;

 N-CREATE: cria uma instância de uma SOP
  Class;
 N-DELETE: apaga uma instância de uma SOP
  Class.
COMUNICAÇÃO    GENÉRICA

   SCU                          SCP
            ASSOCIATE-RQ               Negocia quais
                                        operações
                                        podem ser
            ASSOCIATE-RSP
                                        realizadas

              OPERACAO 1

         SUB-OPERACOES (opcional)     Realiza uma
                                      ou mais das

                 ...                   operações
                                      negociadas
              RESPOSTA 1
                  ...
              OPERACAO N
                  ...
C-ECHO

   SCU                   SCP
         ASSOCIATE-RQ
                               Mais simples das
         ASSOCIATE-RSP          comunicações
                                 DICOM. Não
           C-ECHO              realiza nenhuma
                                     ação.
         C-ECHO RSP
C-FIND

   SCU                         SCP
         ASSOCIATE-RQ

         ASSOCIATE-RSP                Ex.: Data do
                                       Estudo >
                                      12/12/2007
         C-FIND (Parâmetros)

                                     SELECT ou similar
            Resposta 1

               ...
            Resposta N

           C-FIND RSP
C-STORE

   SCU                       SCP
          ASSOCIATE-RQ

          ASSOCIATE-RSP

          C-STORE (IMAGEM)


                                   INSERT ou similar


                                   Salva imagem
          C-STORE RSP
 C-GET

          SCU                            SCP
                                                 Note que para
                ASSOCIATE-RQ                      realizar o C-
                                                 STORE, o SCP
                                               precisa dos dados
                ASSOCIATE-RSP                   corretos do SCU
 Neste                                          (AETitle, host e
caso, o                                               port)
                 C-GET (identificador)
  SCU
passa a
 atuar                                         Busca imagens
 como           C-STORE (IMAGEM 1)
  SCP
                C-STORE (IMAGEM N)

                   C-GET RSP
C-MOVE                                  Notar que o
                                        SCP precisa
                                        conhecer as
SCU                           SCP       outras duas   SCP (2)
                                         entidades
        ASSOCIATE-RQ                      DICOM!
        ASSOCIATE-RSP
  C-MOVE (Destino, Identificador)

                                      Busca imagens

                                     ASSOCIATE-RQ
                                     ASSOCIATE-RSP

      Sucesso / Falha (1/N)         C-STORE (IMAGEM 1)

      Sucesso / Falha (N/N)         C-STORE (IMAGEM N)
         C-MOVE RSP
CONFIGURAÇÃO   NO   CLIENTE (DICOM EYE)
CONFIGURAÇÃO   NO   CLIENTE (DICOM EYE)




                             C-STORE


                              C-FIND
CONFIGURAÇÃO   NO   SERVIDOR
WORKLIST




   Serviço do DICOM utilizado para exibir, em
    um equipamento de aquisição, informações
    sobre procedimentos de imagem agendados.
WORKLIST                                             Modality
                                          Basic     Performed
                                       Management   Procedure
SCU                              SCP     Worklist      Step
         ASSOCIATE-RQ
         ASSOCIATE-RSP
        C-FIND (parâmetros)
                                       Busca Agendados
           C-FIND RSP                  STATUS=‘SCHEDULED’
      N-CREATE (Identificador)
                                       Muda Agendado ID=id
         N-CREATE RSP                  STATUS=‘IN PROGRESS’

      N-SET (Identificador, Status)
                                       Muda Agendado ID=id
                                       STATUS=‘COMPLETED’
           N-SET RSP
                                       ou ‘DISCONTINUED’
INTEGRATING THE HEALTHCARE
ENTERPRISE (IHE)
INTEGRATING THE HEALTHCARE
ENTERPRISE (IHE)
 Não é um padrão nem autoridade de
  certificação;
 É um modelo de alto nível para orientar na
  utilização dos padrões de saúde (HL7 e
  DICOM);
 Define “Perfis de Integração” nos quais são
  definidos diferentes casos de uso para
  integração de sistemas no hospital.
INTEGRATING THE HEALTHCARE
ENTERPRISE (IHE)
Atualmente tem 12 perfis de integração:
 Fluxo de agendamento;
 Reconciliação das informações do paciente;
 Apresentação consistente das imagens;
 Apresentações agrupadas de procedimentos;
 Acesso a informações de radiologia;
 Imagem-chave;
 Imagem simples e relatório numérico;
 Segurança básica;
 Custo de postagem;
 Fluxo de pós-processamento;
 Fluxo de relatório;
 Evidencias de documentos.
Extraído de http://www.imib.med.tu-dresden.de/imib/apis/tagu2002/IHE.pdf
Extraído de http://www.imib.med.tu-dresden.de/imib/apis/tagu2002/IHE.pdf
Extraído de http://www.imib.med.tu-dresden.de/imib/apis/tagu2002/IHE.pdf
OPENEHR
OPENEHR
   Se propõe a permitir que a Tecnologia da
    Informação seja utilizada para auxiliar no
    atendimento ao paciente, na pesquisa
    médica e em áreas relacionadas (*);

   Principal contribuição: criação de modelos de
    dados clínicos reutilizáveis independentes de
    tecnologia – os chamados arquétipos;

   Oferece também ferramentas para o
    desenvolvimento de arquétipos (ADL, editor
    de arquétipos).
              * http://www.openehr.org/home.html
ARQUÉTIPOS       E   TEMPLATES
   Propõe o conceito de modelagem em duas
    camadas (two-level modeling). Separa o
    desenvolvimento do EHR em dois níveis:
     Nível “tecnológico”: determina um modelo de
      dados fixo (referência) que independe do modelo
      conceitual;
     Nível conceitual: específico para o “expert” de
      cada área médica, que não precisa entender o
      nível tecnológico. Modela conceitos clínicos.
   Similar a Ontologia (conceitual) combinada
    com um meio de comunicação (tecnológico).
   ARQUÉTIPOS             E   TEMPLATES *
      Utilização dos arquétipos (B-RES)




*Extraído de http://sres.saude.mg.gov.br/upload/manual/DocumentodeInteroperabilidade.pdf
ARQUÉTIPOS
   Modelo genérico do EHR (tecnológico)
ARQUÉTIPOS
   Modelo dos arquétipos (tecnológico)
ARQUÉTIPOS
 Extract: conjunto de Compositions que vão
  ser trocadas com outro sistema;
 Composition: representa um documento do
  EHR (Ex.: Resumo de Alta);
 Sections: define um conjunto lógico de
  informações (por exemplo, um cabeçalho ou
  uma seção do documento);
 Entries: representam os “dados”, a
  informação clínica propriamente dita (Ex.:
  peso). Pode ser classificada em três tipos:
  “Observation”, “Evaluation” e “Instruction”;
ARQUÉTIPOS - ENTRIES
   Observation
     Os dados coletados ao longo de um período de tempo
      (em uma composição);
     Associado ao conceito de intervalo de medida (máximo e
      mínimo).
   Evaluation
     Dado obtido através de uma observação / medida direta;
     Baseado em uma extrapolação clínica ou avaliação.

   Instruction
     Dados sobre o tempo q um evento ocorreu;
     Dados de workflow (inicio, completado, cancelado);
     Condições necessárias para um evento ocorrer;
     Instruções sobre um procedimento requerido.
ARQUÉTIPOS - ENTRIES
 Entries podem conter dados dos seguintes
  tipos:
 Simples: um par nome-valor;

 Lista: uma lista ordenada de pares nome-
  valor;
 Árvore: um conjunto hierárquico de nós,
  sendo que as folhas são pares nome-valor
  enquanto que os nós são chamados
  “clusters”;
 Tabela: colunas com tipos de dados e linhas
  contendo valores.
ARQUÉTIPOS - EXEMPLO
ARQUÉTIPOS - EXEMPLO
   Série de medidas do número de batimentos
    cardíacos.
ARQUÉTIPOS
   Ferramenta criação arquétipos
ARQUÉTIPOS
   Ferramenta criação arquétipos
ARQUÉTIPOS
   Ferramenta criação arquétipos
ARQUÉTIPOS
   Ferramenta criação arquétipos
ARQUÉTIPOS
   Ferramenta criação arquétipos
ARQUÉTIPOS
   Ferramenta criação arquétipos
CONCLUSÕES
   Cenário complexo: vários padrões, alguns
    indeterminados, outros obrigatórios;

   Outros padrões, não citados aqui (MESH,
    UMLS, DECS, DICOM SR, etc, etc,...);

   Importante saber que existem.
FIM   (da PARTE 2)

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:129
posted:7/6/2012
language:Portuguese
pages:137