Para que a troca de informação seja transparente tanto por aplicações locais num ambiente hospitalar como para fora dele se faz necessária interoperabilidade. Não importa a plataforma, nem a linguagem usada para desenvolver S-RES, a troca de mensagens ocorrerá devido ao padrão adotado.
Esses padrões possuem uma nomenclatura própria para área da saúde, identificando individualmente desde o paciente até eventos como: atendimento ambulatorial, procedimentos cirúrgicos, doenças, diagnósticos, etc. Hoje existe uma variedade de padrões, porém procurou-se discriminar neste trabalho os mais solidificados que ofereçam melhor estrutura. Dentre estes se destacam Continuity Care of Record (CCR), criado pela empresa ASTM
International e HL7 - CDA (Health Level Seven – Clinical Document Architecture) de
2.11.1 HL7
Health Level Seven (HL7) é uma organização voluntária sem fins lucrativos, que foi
fundada em 1987 com o objetivo de produzir protocolos e transações de seguradoras. O HL7 é específico para dados clínicos e administrativos (HL7, 2007). Conceituada como uma das Organizações Desenvolvedoras de Standarts (Padrões) que operando na área da saúde possui “um framework abrangente e normas relacionadas com o intercâmbio, integração, compartilhamento e recuperação de informações de saúde eletrônica que suporta prática clínica e gestão, execução e avaliação dos serviços da saúde” (GONÇALVES, 2010, p.16).
Uma mensagem no padrão HL7 versão 2.4 é caracterizada por eventos, por exemplo, na admissão de pacientes, automaticamente um evento é disparado para todas as aplicações que estejam interessadas na informação (PETRY; LOPES, 2005). Como demonstra o Quadro 2, um exemplo de mensagem ADT^A01 enviada na admissão de paciente.
Quadro 2: Exemplo mensagem HL7.
Fonte: http://www.hosinc.com/products/interfaces/interface_documentation.htm#A01
Observando o Quadro 2, as mensagem são compostas por segmentos que são separados pelo caractere pipe. Cada pipe é um campo que contém uma informação. Os dados nos campos não são obrigatórios, pois o HL7 não verifica se o campo está vazio ou não. As mensagens são enviadas para toda aplicação que possua o recurso de receber as mensagens e interpretá-las. A Figura 12 mostra o funcionamento do envio das mensagens HL7.
Figura 12: Funcionamento do HL7. Fonte:https://dspace.isep.ipp.pt/jspui/bitstream/123456789/74/1/Tese.pdf MSH|^~\&|AccMgr|1|||20050110045504||ADT^A01|599102|P|2.3||| EVN|A01|20050110045502||||| PID|1||10006579^^^1^MRN^1||DUCK^DONALD^D||19241010|M||1|111 DUCK ST^^FOWL^CA^999990000^^M|1|8885551212|8885551212|1|2||40007716^^^AccMgr^VN^1|123121 234|||||||||||NO
NK1|1|DUCK^HUEY|SO|3583 DUCK RD^^FOWL^CA^999990000|8885552222||Y||||||||||||||
PV1|1|I|PREOP^101^1^1^^^S|3|||37^DISNEY^WALT^^^^^^AccMgr^^^^CI|||01||||1|||37^DISNEY ^WALT^^^^^^AccMgr^^^^CI|
A versão mais atual do HL7, a versão 3, foi desenvolvida com uma abordagem direcionada para orientação a objeto, usando princípios de Unified Modeling Language (UML) e a estrutura é criada com XML. Abaixo o histórico das versões (ABRAHÃO, 2005, p.9):
1987. Versão 1.0: Definido o âmbito e o formato de mensagens; 1988. Versão 2.0: Realizada uma série de atualizações;
1990. Versão 2.1: Primeira publicação do Padrão HL7. Efetivamente adotado (Estados Unidos);
1993. Primeira Afiliação Internacional (Alemanha, Holanda); 1994. Versão 2.2: Primeiro reconhecimento pela ANSI;
1997. Versão 2.3: Aprovada pela ANSI. Ampla implementação internacional; 1999. Versão 2.3.1: Aprovada pela ANSI. Realizadas atualizações;
2000. Versão 2.4: Aprovada pela ANSI. Adição de novos eventos, segmentos e mensagens;
2003. Versão 2.5: Aprovada pela ANSI. Adição de novos eventos, segmentos e mensagens;
2005. Versão 3.0 Normative Edition: Parcialmente aprovada pela ANSI.
Reestruturação baseada em modelo orientado a objetos Reference Information Model
(RIM);
2006. Versão 3.0 Normative Edition May 2006: Parcialmente aprovada pela ANSI.
2.11.2 CCR
No ano de 2003 um grupo de médicos, enfermeiros e tecnólogos com o apoio da ASTM International, mais antiga das organizações de padrões de desenvolvimento, criaram um padrão para troca de informações da saúde de pessoas. Conforme a ASTM, o objetivo do
Continuity of Care Record é usar a tecnologia da informação para trocar informações
relevantes sobre a saúde dos pacientes (ASTM, 2007).
O resumo das informações mais relevantes é feito pelo médico no fim da consulta. Este documento em CCR pode ser disponibilizado em papel ou eletronicamente em XML, conforme a Figura 13. A concepção é transportar as informações mais relevantes sobre a condição de saúde do paciente.
São dados como alergias, medicações, diagnósticos, procedimentos recentes, tratamentos recentes, recomendações para cuidados futuros, motivo de encaminhamento e transferência. É criado apenas um documento contendo todas as informações e após é disponibilizada para toda a rede.
Figura 13: Criação de XML e documento pelo CCR. Fonte: http://www.nchica.org/Past/06/presentations/Kibbe.pdf 2.11.3 Diferenças entre CCR e HL7
Tanto CCR como HL7 são usados para transporte de dados clínicos. Na versão mais nova, o padrão HL7 é definido em formato XML, bem como o CCR. No entanto, versões mais antigas do HL7 são descritos em Encoding Rules Seven (ER7). A diferença mais específica entre as tecnologias é que o CCR envia às aplicações e usuários o resumo do atendimento, contendo todas as informações que o médico relatou serem relevantes, ou seja, existe apenas um envio de informação. Enquanto o HL7 envia partes de um atendimento. Por exemplo, é realizado um exame no paciente, uma mensagem é enviada para todas as aplicações que o enfermo recebeu tal procedimento.
Com todas as mensagens HL7 enviadas de um paciente pode-se criar um resumo do atendimento. O que ocorre é que com HL7 o hospital sabe a informação em tempo real. CCR informa para aplicações o que ocorreu até o momento com o paciente e HL7 descreve o que está ocorrendo num determinado instante.
3 TRABALHOS RELACIONADOS
No levantamento de trabalhos relacionados buscou-se a informações relacionadas à computação ubíqua móvel na medicina, fazendo uma breve descrição de suas principais características.
A primeira aplicação relacionada foi desenvolvida sob o padrão de arquitetura de
software, REST (Representational State Transfer). Este sistema móvel tem como objetivo
principal a busca por resultados laboratoriais por nome de paciente. Trata-se de um sistema em que profissionais clínicos acessam as informações de pacientes que estão sendo atendidos. Selecionando o paciente desejado, abrirá uma lista com resultado de laboratório disponível para este paciente. Selecionando o resultado, aparecerão os detalhes do exame. Além disso, há a opção de fazer buscas por nome do paciente e por resultados de laboratório (ANDRY et al, 2011). O sistema utiliza padrão de comunicação HL7.
Adiante foi relacionado um aplicativo móvel que se conecta as funcionalidades de um PEP através de web services. A meta dele é prestar ao médico acesso ao prontuário eletrônico do paciente em qualquer lugar, a qualquer momento. Em suma, o usuário pode inserir dados de seus pacientes e pesquisar, por exemplo, as medicações dos enfermos (MACHADO et al, 2010). O sistema trabalha com padrão de mensagem CCR.
O próximo software relacionado é um aplicativo para Iphone e Ipad, cujo acesso aos dados é feito em um registro eletrônico de pacientes. De forma geral, o objetivo da aplicação é permitir ao usuário acessar informações referentes ao paciente dentro de uma base de dados e verificar, editar e excluir compromissos da agenda. O trabalho foi realizado no âmbito do projeto ClinicSpace. Para projetar os procedimentos do software foram abordadas algumas atividades essenciais dos médicos, obtidas através de pesquisa. Alguns elementos importantes podem ser destacados como o uso de serviços do Google Calendar e Health. O sistema usa também CCR para troca de informações médicas (GUERRA, 2010).
Em seguida foi relacionado o software móvel Primary Health Care System (PHCS) . O usuário alvo é o agente de saúde, que desenvolve atividades no modelo assistencial Atenção Primária a Saúde (APS). O objetivo do sistema móvel é auxiliar na realização de ações preventivas nos pacientes, como automatizar formulários de cadastro e acompanhar os sinais vitais através de sensores. Todos os dados inseridos e sinais captados pelos sensores são enviados para uma base de dados. Quaisquer profissionais terão acesso a essas informações podendo fazer diagnósticos e prevenções (BARROS et al, 2011). O aplicativo foi desenvolvido sob a infraestrutura do projeto Cognitividade com Sensibilidade a Conexão
como Suporte a Otimização de Recursos em Malha Heterogênea (COMAH) (GERCOM UFPA, 2011).
Por fim, o último trabalho relacionado foi o Sistema de Assistência a Urgência Médica (SAUM). Ele consiste em módulo desktop e embarcado num palmtop. O objetivo da aplicação é transferir informações em que ocorra caso de atendimento pelo Sistema de Atendimento Móvel de Urgência (SAMU). Através desse sistema é possível transmitir imagens, mensagens escritas ou sonoras entre a equipe do SAMU, médicos, e prontos- socorros. Dessa forma, poderia se ter um atendimento à distância de médico e saber com antecedência se há leitos vagos para o enfermo no hospital (JUNIOR, 2008).
4 FERRAMENTAS E METODOLOGIA DE DESENVOLVIMENTO
Neste capítulo é mostrada toda implementação do projeto que foi feita na ferramenta IDE Eclipse Indigo 3.7.2. As outras tecnologias utilizadas como HAPI, Android, SDK
Android, QRCode, Barcode Scanner, SQLite serão descritas a seguir. O desenvolvimento, os
diagramas entidade-relacionamento e de sequência bem como outros aspectos seguem a mesma seção.