Usando DB2 pureXML para implementar uma solução de dados no setor de saúde

Uma solução Query Existing Data (QED)

Hoje, interoperabilidade e padrões são os dois últimos jargões do setor de saúde. O uso de padrões é essencial para fornecer a hospitais e médicos a capacidade de interoperar, visando compartilhar melhor os relatórios. O IBM Research vem investigando a evolução dos padrões do setor de saúde, incluindo os padrões IHE e HL7. Este artigo fornece uma breve introdução a estes padrões e protocolos, e oferece um cenário para uma solução IBM DB2® pureXML®, que segue o protocolo IHE QED.

Amnon Shabo, Research Relationship Manager, IBM

Photo of Amnon ShaboAmnon Shabo (Shvo), PhD, trabalha no IBM Research Lab, em Haifa, como membro da equipe de pesquisa especializado em informática da saúde. Amnon lidera o Programa Healthcare and Life Sciences Standards na IBM. Ele detém posição de liderança em HL7 (Health Level 7 - uma importante organização de desenvolvimento de padrões para informações de saúde). Amnon lidera a contribuição do grupo Haifa Healthcare and Life Sciences para o projeto Hypergenes (http://www.hypergenes.eu/), fundado pela União Europeia para explorar a base genética da hipertensão essencial: um estudo conduzido por uma associação de cerca de vinte parceiros europeus. Amnon é especializado em Electronic Health Records (EHR) longitudinais e multi-institucionais. Pioneiro da visão dos Independent Health Record Banks (IHRBs), Amnon promoveu esta ideia ao longo da última década em vários encontros, incluindo no Congresso Norte-Americano, onde ele forneceu instruções especiais ao Congressional Policy Staff (2007) sobre as novas legislações introduzidas no IHRB.



Mary Desisto, Technical Alliance Manager, IBM

Mary Desisto photoMary Desisto é uma Arquiteta de Soluções do grupo IM Technologies. DB2 pureXML é o seu foco principal desde 2007. Antes disso, ela foi especialista técnica no grupo ECM.



Anna Burla, Software Developer, IBM

Photo of Anna BurlaAnna Burla está trabalhando na equipe Healthcare and Life Sciences no IBM Haifa Research Lab. Atualmente, ela está trabalhando em um projeto europeu chamado HyperGenes (http://www.hypergenes.eu/), o qual desenvolve tratamentos personalizados para a doença de hipertensão essencial. Anna cursa Bacharelado em Ciências de Engenharia de Computação no Technion (Instituto Tecnológico de Israel). Ela tem experiência em projeto e implementação de sistemas em larga escala para a indústria militar.



Yonatan Maman, Research Relationship Manager, IBM

Photo of Yonatan MamanYonatan Maman é membro da equipe de pesquisa nos IBM Research Labs em Haifa. Ele recebeu seu Bacharel em Ciências de Engenharia de Software do Technion (Instituto Tecnológico de Israel). Ele está envolvido, sobretudo, em vários projetos do IBM Healthcare and Life Sciences, com foco em interoperabilidade e padrões de base de repositórios clínicos e genômicos. Atualmente, ele trabalha em um projeto que capacita pacientes e médicos fornecendo-lhes meios de monitorar as condições dos pacientes, explorar o conhecimento médico existente de várias fontes e aproveitar as técnicas de análise de ponta, visando aumentar a segurança dos pacientes com foco em ADE (adverse drug events - reações adversas a medicamentos). Yonatan tem experiência em projeto e implementação de sistemas baseados nas tecnologias OpenSource e IBM.



22/Mar/2010

Introdução

Este artigo:

  • Introduz a arquitetura da implementação QED
  • Descreve os componentes da solução QED
  • Introduz as consultas que o perfil QED requer
  • Ilustra as consultas usando a linguagem XQuery a partir do w3c

Entendendo os termos

Sobre o IHE

O Integrating the Healthcare Enterprise (IHE) é uma iniciativa de profissionais e do setor de saúde para melhorar o modo como os sistemas de computador no setor de saúde compartilham as informações. Sistemas que suportam perfis de integração IHE funcionam melhor em conjunto, são mais fáceis de implementar e ajudam provedores de cuidados a usar a informação de modo mais eficiente.

O objetivo da iniciativa IHE é a distribuição eficiente dos melhores cuidados aos pacientes. Centenas de produtos suportam um ou mais perfis IHE. Um típico perfil IHE usa padrões existentes, como o HL7, para os dados clínicos e administrativos. Também usa o padrão DICOM para as informações de imagens médicas. O perfil restringe cada uma das mensagens selecionadas para atender aos casos de uso de negócios requisitados.

Sobre o QED

O Query Existing Data (QED) é um dos perfis de integração com suporte a consultas dinâmicas de dados clínicos. O QED define um caso de uso no qual um sistema do consumidor clínico consulta informações clínicas em um sistema de fonte clínica. O QED define diferentes tipos de consultas, todas centradas no paciente. Um sistema clínico do consumidor pode solicitar vários tipos de dados clínicos de um paciente específico, incluindo sinais vitais, alergias, medicamentos, imunizações, resultados dos diagnósticos, procedimento e histórico de visitas. Um perfil QED usa os padrões de domínio HL7 para o modelo de conteúdo e os formatos comuns de mensagem HL7 para a transferência de consultas e resultados. A resposta é composta por declarações clínicas, como fragmentos de CDA, que descrevem dados clínicos de acordo com os parâmetros da consulta. O HL7 desenvolveu o XML Schema Generator para permitir a representação do padrão via XML.

Sobre o RIM

O Reference Information Model (RIM) é uma parte essencial da metodologia de desenvolvimento HL7 V3. O RIM expressa os conteúdos de dados necessários em contextos administrativos ou clínicos específicos. O RIM fornece uma representação explícita das conexões semânticas e léxicas que existem entre as informações carregadas nos campos de mensagens HL7. O RIM é um padrão aprovado pelos padrões ANSI e ISO. Aplicativos e repositórios baseados em RIM foram desenvolvidos com base em esquemas de relações.

Connectathons

O IHE North American Connectathon é um evento de testes com duração de uma semana, planejado por organizações patrocinadoras, pela Health Information Management Systems Society (HIMSS) e pela Radiological Society of North America (RSNA). O objetivo do IHE Connectathons em todo o mundo é promover as soluções de interoperabilidade IHE baseadas em padrões para sistemas de TI para o setor de saúde disponíveis comercialmente. O IHE Connectathons serve como um evento de testes que abrange todo o setor, onde os participantes podem testar suas implementações com as de outros vendedores.

Sobre o RIMon

Em fevereiro de 2009, uma equipe da IBM Haifa Research apresentou uma solução IHE QED para a consulta aos dados clínicos de pacientes à North American 2009 Connectathon. A equipe demonstrou com sucesso que as consultas QED emitidas por sistemas de outros vendedores (como General Electric, Corp.) podem ser executados contra a fonte de dados QED usando um armazém de dados que integra dados clínicos em vários formatos em uma estrutura padronizada. Este artigo descreve a solução QED chamada RIMon e seus benefícios para o setor de saúde quando dados clínicos dispersos são consultados.

O RIMon, o armazém HL7 baseado em RIM, introduz o uso de XML na camada de persistência, como exibido na Figura 1. O RIMon suporta a interoperabilidade semântica, pois o XML é a tecnologia de implementação favorita das especificações HL7.

Figura 1. Diagrama de classe UML do Modelo de Informação de Referência
Diagrama de classe UML do Modelo de Informação de Referência

(Veja a imagem maior.)

Sobre o DB2 pureXML

O DB2 pureXML é um veículo ideal para implementar um sistema de fonte de dados clínicos QED, pois a necessidade do formato de retorno das consultas QED (ou seja, declarações clínicas representadas em XML) já está disponível no RIMon. O armazém de dados do RIMon permite a integração de dados de várias fontes e em vários formatos em uma estrutura padronizada, que é mais bem preservada através do uso de representações HL7 XML.


Entendendo a arquitetura QED

A solução da IBM Haifa Research Team é exibida na Figura 2.

Figura 2. Arquitetura de solução do perfil IBM QED
Arquitetura de solução do perfil IBM QED

Os principais componentes

Os principais componentes da solução IBM Research são a fonte de dados clínicos, a interface da fonte de dados clínicos e um consumidor de dados clínicos. A fonte de dados clínicos consiste de um repositório RIMon. O repositório RIMon contém um banco de dados DB2, no qual os documentos CDA são inseridos como XML usando o recurso pureXML do DB2 V9. Todos os resultados requeridos pelas consultas padrão QED estão dentro dos documentos CDA. XQueries estáticas escritas com relação aos documentos CDA inseridos podem extrair os dados necessários para responder às consultas padrão QED. Estas consultas podem ser realizadas em lotes para criar tabelas contendo:

  • Os dados necessários para responder à consulta QED
  • Dados adicionais de atributos
  • O XPath referenciado a partir do qual os dados originaram-se

É possível que alguém usando a solução IBM Research escolha extrair dados selecionados dos documentos XML por várias razões. Um usuário pode ter vários esquemas diferentes em uma coluna XML, ou, no caso dos documentos XML serem muito grandes e complexos, extrair uma porção dos dados requeridos para um aplicativo em particular pode ajudar a estrutura de dados em um aplicativo ou caso de uso específico. É necessário manter intacto todo o documento XML para construir os resultados da consulta QED.

Tornando a complexidade utilizável

O mapeamento de atributos, a adição do XPath dos dados e os dados adicionais adicionados em um arquivo de configuração são necessários, pois a estrutura CDA é muito complexa. A estrutura CDA é deliberadamente vaga, pois seu esquema é um padrão projetado para praticamente qualquer tipo de observação ou ação médica. Uma pessoa lendo diretamente um CDA, ou tentando consultar diretamente um documento CDA (sem um entendimento preliminar dos variados modelos no armazém), teria dificuldades em entender todos os códigos médicos embutidos, que representam a tarefa ou o procedimento médico que ocorreu no consultório médico. Por exemplo, o código para o batimento cardíaco é 8867-4, e o ID do modelo para uma alergia é 1.3.6.1.4.1.19376.1.5.3.1.4.5.3. Os códigos em CDA derivam de terminologias médicas padrões, incluindo SNOMED e LOINC, porém, usuários que não são médicos normalmente não têm familiaridade com os códigos. O mapeamento permite que uma pessoa que não seja médica consulte o batimento cardíaco, como definido pelas especificações QED, sem requerer o código nas terminologias globais padrão. O batimento cardíaco está mapeado internamente com o código 8867-4 e os dados de observação corretos são devolvidos.

Estes dados extraídos são a fonte de dados clínicos. O consumidor de dados clínicos pode emitir uma requisição solicitando o batimento cardíaco, a altura ou alergias, como exibido na Figura 3.

Figura 3. Fonte de dados clínicos
Fonte de dados clínicos

A interface gráfica do usuário (GUI) permite que um usuário emita uma requisição de todas as consultas padrão QED com base nas especificações QED (veja Recursos). O consumidor da fonte de dados clínicos empacota os resultados em uma resposta PCC-1 QED, de acordo com os requerimentos QED no formato XML. A seguir, o consumidor da fonte de dados clínicos envia a resposta para a interface da fonte de dados clínicos, como exibido na Listagem 1.

Listagem 1. Resposta PCC-1 QED
<?xml version="1.0" encoding="UTF-8"?>
 <soapenv:Envelope xmlns:q0="urn:hl7-org:v3" 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
     <soapenv:Body>  
         <QUPC_IN043100UV01 ITSVersion="XML_1.0" xmlns="urn:hl7-
org:v3"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">  
             <!-- A unique identifier for this transmission (mandatory). -->  
             <id extension="123" root="2.16.840.1.113883.19.4"/>  
             <!-- The time that the transmission was created. -->  
             <creationTime value="20100222185444"/>  
             <interactionId extension="QUQI_IN000003UV01" root="2.16.840.1.113883.5"/>
              <!-- debugging, production or training -->  
              <processingCode code="T"/>  
              <!-- 
          Archive, Current Processing, Initial Load or Restore from Archive 
      -->  
              <processingModeCode code="T"/>  
                
              <acceptAckCode code="AL"/>  
              <receiver typeCode="RCV">  
                  <device classCode="DEV" determinerCode="INSTANCE">  
                      <id root="2.16.840.1.113883.3.18.12.7.30.20"/>  
                  </device>  
              </receiver>  
              <sender typeCode="SND">  
                  <device classCode="DEV" determinerCode="INSTANCE">  
                      <id root="2.16.840.1.113883.3.18.12.7.30.20.77"/>  
                      <name>IBM QED clinical Consumer testing utility</name>  
                      <telecom value="http://ibm2:8080/qedConsumer/QedConsumer.html"/>
                      <manufacturerModelName>QED clinical consumer 
                       module</manufacturerModelName> 
                      <softwareName>QED clinical consumer device 
                       softwareName</softwareName>  
                  </device>  
              </sender>  
              <controlActProcess classCode="CACT" moodCode="RQO">  
                  <id extension="111" root="2.16.840.1.113883.19.4"/>  
                  <!-- the identifier of the query -->  
                  <code code="QUPC_TE043100UV"/>  
                  <!-- The trigger event code -->  
                  <effectiveTime value="20100222185444"/>

Usando uma API, a interface da fonte de dados clínicos QED cria uma única instrução SQL a partir da requisição XML para ser executada com relação à fonte de dados clínicos, como um banco de dados relacional criado a partir das XQueries estáticas. A interface da fonte de dados clínicos empacota os resultados combinando de volta os CDAs desta consulta na resposta PCC-1 QED, e o consumidor dos dados clínicos os exibe para o usuário final, como exibido na Figura 4.

Figura 4. Resultado PCC-1 QED
Resultado PCC-1 QED

A solução do exemplo organiza os códigos de prestação de cuidados em mensagens QED para atributos dentro da fonte de dados clínicos. O XPATH de onde os dados foram extraídos na fonte de dados clínicos também foi definido.


Lidando com as consultas

Consultas estáticas são executadas com relação aos documentos CDA para extrair os dados das consultas padrão QED. Além do resultado da consulta ser adicionado ao banco de dados da fonte de dados clínicos, campos adicionais são adicionados e mapeados, de modo que as consultas possam localizar os dados requeridos para atender as especificações QED. O XPath para os dados também foi incluído em uma coluna. O comitê Connectathon ditou as consultas que a demo da equipe IBM Research teve que seguir. A consulta que extraiu a observação do batimento cardíaco é exibida na Listagem 2.

Listagem 2. Observação do batimento cardíaco
xquery 
  declare default element namespace "urn:hl7-org:v3"; 
  for $obs in db2-fn:xmlcolumn('RIM.INSTANCE')
  //section[@classCode='DOCSECT'] 
  [code/@code='8716-3']/entry/observation[@classCode='OBS']
  [code/@code='8867-4']
    let $y := fn:root($obs)
      let $entity_ext:=$y/*/id/@extension 
      let $entity_root:=$y/*/id/@root 
      let $effectiveTime:=$obs/effectiveTime[1] 
      let $statusCode:=$obs/statusCode 
      return <ibm:res xmlns:ibm="http://www.ibm.com/hrl" xmlns:v3="urn:hl7-org:v3"
          entity_ext="{string($entity_ext)}" entity_root="{string($entity_root)}" 
          attr="HEART_BEAT" value="{string($obs/value/@value)}" 
          nullFlavor="{string($obs/value/@value/../@nullFlavor)}" 
          bakRef_root="{string($obs/id/@root)}" bakRef_ext="{string($obs/id/@extension)}">
          <ibm:props>{$effectiveTime}{$statusCode}</ibm:props></ibm:res>

A consulta ao batimento cardíaco usa a linguagem w3c XQuery, que é o padrão para as consultas de dados em XML. O espaço de nomes é declarado, pois todos os CDAs contêm este espaço de nomes. A função db2-fn:xmlcolumn é uma função específica de DB2 para consultar colunas XML. A listagem 2 consulta a coluna INSTANCE na tabela RIM. A linha //section[@classCode='DOCSECT'] é o XPath para navegar à observação apropriada, que contém o batimento cardíaco. Os códigos 8716-3 e 8867-4 indicam que este é o segmento de observação correto para o batimento cardíaco.

Um documento CDA pode ter muitos segmentos de observação. Os outros elementos na listagem 2, tais como o tempo efetivo, código de status e assim por diante, são outros elementos do documento CDA necessários na resposta QED. Estes elementos são extraídos e devolvidos para a fonte de dados clínicos.

Um atributo adicional chamado Heart_Beat é copiado e mapeado com o código para o batimento cardíaco - 8867-4. Além disso, o XPath do documento original é mantido para localizar estes valores.

Usando o repositório pureXML diretamente

A interface da fonte de dados clínicos também pode acessar diretamente o repositório DB2 pureXML. O repositório pureXML se tornaria, então, a fonte de dados clínicos. A API que atualmente gera uma única instrução SQL pode ser alterada para gerar uma consulta XML/SQL ou uma XQuery, que pode acessar diretamente o documento CDA. A execução de tarefas em lote para extrair os dados em um banco de dados relacional não seria mais necessária. A consulta pode retornar os mesmos dados exigidos para a resposta QED, os quais a interface pode usar para preencher o consumidor de dados clínicos. A listagem 3 mostra um exemplo de uma consulta XML/SQL para obter o sinal vital do batimento cardíaco.

Consulta XML/SQL para obter o batimento cardíaco diretamente
SELECT XMLQUERY ('$d//*:section/*:entry/*:observation[@classCode="OBS"
 and *:code/@code="8867-4"]' passing DOCUMENT as "d") 
FROM CDA WHERE ID=?

O valor do ID vem do ID do paciente que consta na GUI. O código code/@code="8867-4"] vem da seleção de batimento cardíaco. Nesta consulta, o *: representa um curinga para o espaço de nomes, o qual pode ser substituído com o espaço de nomes real. A consulta é escrita com relação a uma tabela de banco de dados (CDA), na qual o ID do paciente foi extraído do CDA em uma coluna relacional. A coluna DOCUMENT indica onde o CDA baseado em XML foi inserido.


Usando a demo você mesmo

Você pode experimentar com a QED Consumer Web interface (veja Recursos) enviando solicitações QED para o RIMon QED Data Source. Esta interface da Web pode lhe ajudar a construir requisições QED, renderizar respostas QED e exibir quais informações são transferidas. Os IDs válidos para os pacientes são 120 e 130. Deixe o ID padrão do paciente como root.


Conclusão

A demonstração da equipe IBM Research provou que a implementação de um sistema de fonte de dados clínicos QED pode ser feita em uma DB2 pureXML com sucesso e de forma conveniente. Muitos fatores influenciam se os dados são extraídos em um banco de dados relacional. Porém, um dos benefícios de usar pureXML é que o documento XML de origem permanece intacto. Ter está fonte armazenada permite que você use este repositório para muitas aplicações diferentes, que podem necessitar de dados, incluindo CDAs, CCDs, EMRs e outros documentos de saúde baseado em XML.

Recursos

Aprender

Obter produtos e tecnologias

  • Experimente a interface da Web do consumidor QED enviando requisições QED para o RIMon QED Data Source. Os IDs válidos para os pacientes são 120 e 130. Deixe o ID padrão do paciente como root.
  • Elabore seu próximo projeto de desenvolvimento com o software de teste IBM, disponível para download diretamente no developerWorks.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Information Management, Segmentos de mercado
ArticleID=483922
ArticleTitle=Usando DB2 pureXML para implementar uma solução de dados no setor de saúde
publish-date=03222010