openehr Ricardo Correia

Transcrição

1 openehr Ricardo Correia

2 Apresentação Ciência Computadores (Fac. Ciências UP) Curso de Empreendedorismo (EGP) Doutoramento pela Fac. Medicina da UP ImplementaBon, monitoring and ublizabon of an integrated Hospital InformaBon System CerBficado pela Mirth CorporaBon (Mirth/HL7) Co- fundador de 3 spin- off da universidade do Porto na área da informábca em saúde VirtualCare, HealthySystems, IS4Health

3 Ötzi Tattoos! BC!!! Ötzi had several carbon tattoos including groups of short, parallel, vertical lines to both sides of the lumbar spine, a cruciform mark behind the right knee, and various marks around both ankles. Radiological examination of his bones showed "age-conditioned or straininduced degeneration" in these areas, including osteochondrosis and slight spondylosis in the lumbar spine and wear-and-tear degeneration in the knee and especially the ankle joints. It has been speculated that these tattoos may have been related to pain relief treatments similar to acupressure or acupuncture. If so, this is at least 2000 years before their previously known earliest use in China (c BC).!!! Wikipedia, 19 Oct 2012!

4 Ricardo Correia UPorto SISTEMAS DE INFORMAÇÃO EM OPENEHR

5 Problemas actuais - O SW e BD têm que estar constantemente a ser adaptadas - Dificuldade em manter compa;bilidade com dados anteriores - É dificil documentar as alterações - Os sistemas de apoio à decisão ficam demasiado ligados ao SW

6 Penso logo registo A estrutura dos dados (e a qualidade) depende do objectivo na sua recolha Prestação de cuidados Investigação clínica Gestão / Financeira Ensino Legal

7 Qualidade de dados Heterogeniedade na forma de introdução de dados Dúvidas na interpretação na leitura Conceitos que evoluem Falta de avaliação na qualidade dos dados

8 Compreensão e análise estaasbca Existem exemplos de grandes diferenças de protocolo que impossibilitam uma análise correcta dos dados Proporção de internamentos com um diagnós;co de gripe (2001 a 2007)

9 Compreensão e análise estaasbca Alterações ao longo do tempo As alterações de protocolo podem não ser conhecidas de todos os que analisam os dados Uso de ICD- 9- CM para codificar enfarte isquémico

10 Codificação do sexo de uma pessoa M - Male F Female T Transgender U Undifferenciated? - Unknown HIS dos EUA F Female M Male O Other DICOM F Female M Male O Other U Unknown A Ambiguous N Not applicable HL7 1 Homem 2 Mulher 3 Hibrido SONHO

11 [ ] Alergia à Penicilina Valores omissos

12 Valores omissos [ ] Alergia à Penicilina Alergia à Penicilina: ( )Sim (x)não ( )Sim ( )Não (x)desconhecido ( )Sim ( )Não (x)desconhecido ( )N/A - Não aplicável ( )Sim ( )Não ( )Desconhecido ( )N/A (x)não introduzido

13 Valores omissos [ ] Alergia à Penicilina Alergia à Penicilina: ( )Sim (x)não ( )Sim ( )Não (x)desconhecido ( )Sim ( )Não (x)desconhecido ( )N/A - Não aplicável ( )Sim ( )Não ( )Desconhecido ( )N/A (x)não introduzido Alergia à Penicilina: ( )Médico sabe que sim ( )Médico sabe que não ( )Doente diz que sim ( )Doente diz que não ( )Desconhecido (x)não introduzido ( )N/A

14 Dificuldades da modelação em saúde Bases de dados para prontuários têm que: Ler e gravar rápido os dados de 1 doente Adaptar- se à alteração das necessidades de informação de uma insbtuição Novas ublizações Novas consultas Recolha de novos elementos A capacidade de se adaptar é fundamental porque a conhecimento estruturado em saúde está sempre incompleto e em evolução Como resultado, os sonwares sofrem de melhoramentos frequentes, e novos módulos/ sistemas estão constantemente a ser integrados

15 Necessidade de um novo paradigma Mito: um sistema que resolve todos os problemas Não é o soxware que representa e compõe o registro de saúde, são os dados Importância de dados estruturados de maneira mundialmente comum e reconhecida (podem ser ublizados para qualquer finalidade) Necessidade de um modelo clínico comum e coerente para permibr: Par;lha de registos Agregação de dados ABvidades baseadas em conhecimento - sistemas de apoio à decisão Apoiar a análise comparabva de dados de saúde Quanto maior o nível (local, regional, nacional, internacional) de aceitação de modelos comuns maior o potencial de interoperabilidade semânbca

16 Ver demo Demo

17 O que é openehr Em termos técnicos - pretende criar especificações (normas) e sonware que permita a representação de conceitos clínicos complexos Em termos clínicos - pretende criar modelos de qualidade reusáveis descrevendo conceitos clínicos (arquébpos)

18 Desenvolvimento tradicional de SW Requisitos Alterações constantes nas necessidades dos ublizadores IdenBficação de omissões Desenvolvimento Ambiguidades nas descrições são detectadas nos testes ou ublização UBlização Instalação e Teste

19 Nova forma de desenvolver com openehr Requisitos Desenvolvimento Instalação e Teste UBlização Modificar arquébpos e templates IdenBficação de omissões Os ublizadores podem alterar os arquébpos e templates sem alterar o sonware

20 Os actores envolvidos Source:

21 Os actores envolvidos Source:

22 Uma primeira abordagem ArquéBpo peça de LEGO Template uma forma úbl composta por várias peças de LEGO CKM uma caixa de peças de LEGO (arquébpos) e de formas úteis (templates) Aplicação openehr ambiente onde posso colocar as várias formas, tendo estas formas a possibilidade de comunicar entre si

23 ArquéBpos e templates Templates ArquéBpos Modelo de Referência EHR Folders Artefact generator Composi;ons Sec;ons Entries Clusters Elements Data values UI Form The electronic health record for one person High- level organisa;on of the EHR e.g. per episode, per clinical speciality API Set of entries commi[ed at one date/;me e.g. progress note, report, le[er, test result Clinical headings reflec;ng the workflow and consulta;on/reasoning process XSD Clinical statements about Observa;ons, Evalua;ons, and Instruc;ons Compound entries e.g. blood pressure, full blood count Element entries e.g. reason for encounter, body weight e.g. Coded terms from term sets, measurements with units

24 ArquéBpos e templates UI Form Artefact generator API Templates ArquéBpos XSD Exemplos Altura Peso Sumário Gravidez Ecocardiograma Apgar Modelo de Referência

25 ArquéBpos e templates Templates ArquéBpos Modelo de Referência Artefact generator Exemplos Nota UI Form de alta do Hospital de Leiria API Nota de Admissão da ARS Centro XSD Receita de medicamentos do Ministério de Saúde Registo de alergias e RAMs

26 ArquéBpos e templates Formulário Artefact generator API Templates XSD Archetypes Ref. Model Model World Read World

27 Separação clara de responsabilidades Profissionais de saúde Definem modelos que descrevem conceitos consensuais Definem modelos de templates (eg. formulários) a ublizar por insbtuições de saúde InformáBcos Criam software que lê estes modelos e se ajusta às definições Garantem o controlo de versões da informação e a capacidade de gestão dos dados

28 Principais Mensagens A ublização de openehr não é fácil, pois obriga a que: os profissionais de saúde assumam novas responsabilidades nomeadamente a desenhar arquébpos e templates os programadores façam sonware mais genérico e robusto

29 Principais Mensagens A ublização de openehr é importante porque: garante que os dados sejam compreensíveis no futuro facilita a ublização de bases de dados comuns a vários sonwares permite a cooperação entre países e organizações

30 PROJETOS ATUAIS EM OPENEHR

31 Projetos atuais em openehr OpenObsCare Capacitar uma solução comercial (registo clínico obstétrico) com tecnologia openehr Nota alta obstétrica Brasil Definição da nota de alta em openehr 3 milhões de partos por ano Está em aprovação para ser norma nacional

32 Criem uma vez Usem muitas