Fase 2

Fase 2: Piloto

1. Concepção

1.1. Resumo

O GT-Rarasnet, no primeiro ciclo de desenvolvimento, criou um protótipo funcional de aplicativo mobile para sistemas Android.  Esta iniciativa, em parceria e fomentada pela RNP e pela SGTES-MS, tem como meta principal o desenvolvimento e o estabelecimento de uma plataforma para integração e divulgação de informações sobre doenças raras cobertas pelo Sistema Único de Saúde. O aplicativo é uma solução completa que se conecta, via webservice, às bases de dados curadas pela equipe de pesquisa do Observatório: dados provenientes do DATASUS (SIM, SINASC, CNES), informações bibliográficas provenientes dos sistemas de indexação nacionais (BVS, Biblioteca de Teses e Dissertações da CAPES, SCIELO), informações sobre profissionais fornecidas por conselhos de classe, informações sobre locais de atendimento disponibilizadas por secretarias de saúde e sociedades científicas, informações internacionais sobre as doenças (Orphadata e OMIM), protocolos clínicos e diretrizes terapêuticas do MS, dados de medicamentos para doenças raras da RENAME, etc. O aplicativo foi concebido para rodar em smartphones com acesso a internet e, mediante cadastro básico, permite o acesso ao repositório. O funcionamento se dá numa estrutura cliente-servidor LAMP, mediada por webservice desenvolvido em PHP. Na segunda etapa de desenvolvimento pretende-se ampliar a funcionalidade do aplicativo, através da reestruturação do webservice e de revisão dos relacionamentos nas bases de dados. Serão realizados testes em cenário real, bem como em laboratório, a fim de identificar inconsistências. O estudo piloto envolverá profissionais de saúde e pesquisadores do campo das doenças raras, residente no Distrito Federal. Como resultado final, espera-se oferecer um serviço robusto, estruturado, fluido e intuitivo, permitindo uma visão panorâmica e ampla das informações nacionais e internacionais sobre doenças raras.

1.2.Abstract

The GT-RarasNet in the first cycle of development, created a working prototype of mobile application for Android systems. This initiative, in partnership and promoted by RNP and the SGTES-MS, has as main goal the development and establishment of a platform for integration and dissemination of information about rare diseases covered by the Brazilian National Health System. The application is a complete solution that connects, via webservice, databases maintained by Centre’s research team: data from DATASUS (SIM, SINASC, CNES), bibliographic information from the national indexing systems, professional information provided by professional associations, information service locations provided by health departments and scientific societies, international information on diseases (Orphadata and OMIM), clinical protocols and therapeutic guidelines, drug data for rare diseases (RENAME), etc. The application is designed to run on smartphones with Internet access and through basic registration allows access to the repository. The operation takes place in a client-server structure mediated by webservice in PHP. In the second stage of development is intended to expand the functionality of the application, through the restructuring of webservice and review of relationships in databases. A real scenario tests will be performed, as well as laboratory tests to identify inconsistencies. The pilot study will involve health professionals and researchers in the field of rare diseases, resident in the Federal District. The final result  expected is an offer of a robust service, structured, fluid and intuitive, allowing a panoramic and comprehensive view of national and international information on rare diseases.

1.3. Descrição do produto/serviço

A plataforma RarasNet foi idealizada como um sistema de acesso a informações nacional e internacional sobre doenças raras. Primariamente, trata-se de um aplicativo para sistemas Android se conecta a bases de dados estruturadas e/ou tratadas pela equipe do Observatório de Doenças Raras/UnB, a fim de apoiar ações de gestão, de cuidado ou de advocacy com oferta de evidências sistematizadas e de informações de regulação ou de legislação. As informações disponibilizadas no aplicativo encontram-se listadas no Quadro 1.

Quadro 1: Informações disponibilizadas no aplicativo RarasNet.

Informações oficiais do DATASUS (SIAB, SIM, SINAM, etc.)
Informações bibliográficas (BVS, Scielo, Biblioteca Virtual da CAPES, etc.)
Informações acerca de unidades de atendimento e centros de referência
Protocolos clínicos e diretrizes terapêuticas
Legislação vigente
Cadastro de especialistas
Cadastro de pacientes e geração de dados epidemiológicos (auto notificação)
Informações acerca das doenças raras (CID, taxonomia, genética, epidemiologia, clínica, etc.)
Modelo experimental de algoritmo de identificação de doenças raras por sinais e sintomas

 

O protótipo de aplicativo atende demanda da Portaria MS 199/2014, que apontou urgência na criação de mecanismos e ferramentas para educação e promoção em saúde, bem como de apoio aos serviços de saúde no campo das doenças raras. Outras lacunas se referem ao apoio matricial na referenciação dos pacientes e a geração de dados de ocorrência destas doenças (vigilâncias passiva e ativa). Este conjunto de informações visa apoiar as equipes de saúde na família e de serviços de urgência e emergência, bem como aos profissionais e gestores das redes de atenção em saúde. Neste sentido, uma ferramenta em e-health pode atender aos anseios da população brasileira de pessoas acometidas por doenças raras, de seus cuidadores e de profissionais de saúde da atenção básica.

1.4. Identificação do público alvo

O público-alvo para o aplicativo é constituído primariamente pelos profissionais da atenção básica e especializada a saúde. Mas em função das características do protótipo, o mesmo pode ser utilizado por estudantes da área de saúde, cuidadores, gestores de sistemas de saúde, conselheiros de saúde, pacientes e outros stakeholders.

2.    Definição do piloto

2.1.  A plataforma RarasNet

A plataforma RarasNet é uma solução híbrida com duas frentes de trabalho. A primeira, o aplicativo mobile, congrega elementos modulares nativos para Android, programados em Java. A segunda frente é voltada para permitir acesso, via desktop, de informações gerenciais do aplicativo, bem como permiti a visualização de dados e geração de relatórios; é desenhado em PHP/HTML5. O padrão de arquitetura de software adotado foi o MVC (Model-View-Controller), seguindo-se as boas práticas para desenvolvimento de aplicações: a flexibilidade para a adição contínua de novos módulos e funcionalidades; a adoção de interfaces gráficas intuitivas; e, a compatibilidade com a maioria dos dispositivos. Para o aplicativo mobile, há compatibilidade a partir da versão 3.0 (Honeycomb, API 11), que abrange a maioria dos smartphones em uso no Brasil. Para estruturação da camada do webservice RESTful (Representational State Transfer), a equipe decidiu migrar para o framework PHP Laravel. Para modelagem das bases de dados adotou-se o software MySQL Workbench.

2.2. Planejamento estratégico e arquitetura do Piloto

Dentro da lógica de planejamento estratégico, nesta etapa piloto será realizado o exame da viabilidade em transformar o protótipo e o sistema de informação em realidade, isto é, serão inventariadas as restrições de uso e as potencialidades do aplicativo para apoio a profissionais relacionados as equipes de atenção básica em saúde e as equipes gerenciais e sua incorporação no serviço. O processo de avaliação se dará com a participação de todos os stakeholders envolvidos. A equipe do GT-RarasNet coletará sistematicamente as informações para execução das correções e adequações (mudanças em layout, acréscimo de informações, mudanças em modelos dos bancos de dados, etc.). Como cenário primário, escolheu-se o Distrito Federal, não só pela conveniência geográfica, mas por envolver diversos níveis de interlocutores e potenciais usuários. O monitoramento e a avaliação serão executados mediante coleta de informações anônimas de uso, bem como pela resposta a questionários de avaliação em diferentes momentos.

2.3. Método de trabalho interno de equipe

A metodologia de trabalho interno adotada pela equipe para planejamento e implementação do piloto será a estratégia Scrum, que é um framework para desenvolver e manter produtos complexos[1]. Esta metodologia é ágil para gestão e planejamento de projetos de software. O piloto foi dividido em ciclos de atividades (Sprints), monitoradas em um backlog (plataforma Trello[2]). No início de cada ciclo de atividades será realizada uma reunião de planejamento (Sprint Planning Meeting), na qual as equipes responsáveis pelo desenvolvimento do aplicativo (time TI), da construção das bases de dados (time Saúde) e a coordenação do projeto definirão as tarefas do novo ciclo. O monitoramento/avaliação das atividades será realizado em scrums semanais, onde serão debatidos as metas alcançadas, as falhas e os próximos passos do trabalho semanal. Ao final do ciclo de produção, as equipes se reunirão para elaboração de relatório final e avaliação do piloto.

2.4.  Ações (Pré-testes e testes)

2.4.1. Testes de caixa branca (Pré-testes)

 

Tem sido adotado pela equipe um conjunto de testes, a fim de avaliar a estabilidade e utilidade do sistema. Por definição, os testes de caixa branca implicam em conhecimento da estrutura interna do sistema, isto significa que são necessários conhecimentos de programação, para se verificar-se o código interno do programa. Nestes casos de testes serão convidados stakeholders da rede de atenção em saúde do DF, do DATASUS e da RNP, além de pesquisadores da UnB. De modo geral, os testes de caixa branca envolvem três níveis de processo de teste de software: teste de unidade, testes de integração e testes do sistema. O perfil de teste escolhido foi o de Cobertura Lógica (Critérios Myers), que é constituído de critérios que, quando obedecidos, determinam os casos de teste a serem gerados. Os critérios se tornam progressivamente mais abrangentes e rigorosos, partindo-se da cobertura de comandos até atingir a cobertura de múltiplas condições.  A escolha do critério adequado será norteada pelos seguintes fatores: complexidade da aplicação web e da aplicação mobile; estrutura das aplicações; Criticidade; e, nível de confiança.

2.4.2. Testes de caixa preta

Nesta metodologia os casos de teste são gerados sem o conhecimento da estrutura interna do programa. Apenas o conhecimento das entradas e saídas possíveis para o programa é necessário. São também denominados testes funcionais. Dentre os vários métodos, técnicas ou estratégias de Teste de Caixa Preta existentes, o escolhido foi o Particiona mento de Equivalência, devido à redução de entradas possíveis por ele proporcionada. Como classes de entrada foram identificadas: Login; E-mail; Senha; CID ou Nome da Doença, Sinal, profissional ou Centro. Como classe de saída foram identificadas as mensagens geradas pelo aplicativo.

 

2.5. Refinamento do protótipo

Nesta etapa serão necessárias melhorias no que se refere a interoperabilidade, segurança de dados e modelagem das bases de dados. A aplicação web deverá ser totalmente remodelada a fim de oferecer uma interface intuitiva e capaz de gerar relatório funcionais para as equipes de gestão e profissionais de saúde. Será necessário reavaliar também o desenho dos perfis de usuários, para permitir sobreposições de papéis e adequação de acesso a informações específicas (medicamentos, condutas de urgência, etc.). Também será necessário estudar como implementar um sistema interno de mensageria, a fim de permitir eventos de teleconsultoria entre profissionais, uma vez que a área apresenta certa escassez de especialistas e superespecialização. Neste sentido, caberia uma maior aproximação com a RUTE e/ou com o UNASUS, a fim de incentivar a aproximação da temática por profissionais da atenção básica.

2.6. Principais componentes a serem desenvolvidos:

  • Criação de outros perfis de usuários: criação de perfis de usuário para gestores, cuidadores, pacientes e outros stakeholders.
  • Reestruturação da base de dados (verificação de inconsistências e de modelagem): trata-se de revisão de estrutura relacional da base de dados estruturada pelo Observatório
  • Aperfeiçoamento do sistema interno de mensageria, a fim de permitir eventos de teleconsultoria entre profissionais: trata-se de módulo de comunicação interna do aplicativo para permitir interação entre profissionais de saúde a fim de dirimir dúvidas e buscar apoio na referência/contra referência e na redução de itinerários dentro do SUS.
  • Criação de um Fórum na Web para os usuários da Rede Raras: trata-se da criação de um fórum para coleta de sugestões sobre o aplicativo (FAQ) e também para comunicação entre pacientes; o fórum poderá ser acessado pelo aplicativo. ·         Disponibilização de um Módulo de educação: fornecimento, via aplicativo, de acesso a um ambiente educacional (Moodle) mantidos pelo Observatório de Doenças Raras ou aos repositórios da UNASUS que tratem de temáticas correlatas, após pactuação com SGETS.
  • Alerta bibliográfico: módulo de atualização bibliográfica para as doenças raras, curado pela equipe do Observatório; serão fornecidas listas atualizadas de artigos, teses e outros documentos relevantes em formato *.html, *.xml, *.ris ou outro formato compatível com softwares gestores de referências.
  • Registro de pacientes: trata-se de registro de pessoas com doenças raras, mediante preenchimento de formulário padronizado.
  • Sistema de censo de pacientes: trata-se de geração de informação sobre localização e quantitativo de pessoas com doenças raras mediante preenchimento de registro; o relatório de informações será apresentado em planilhas ou em mapas·
  • Módulo de acompanhamento de saúde (piloto para hemofilia): trata-se inventário rápido de condições de saúde; a meta do Observatório é desenvolver esta estratégia para conhecer situação e necessidades de saúde das populações com doenças raras.

2.7. Ferramentas de suporte à operação (para propostas de serviço)

  • O equipamento mínimo para acessar a aplicação web/webservice/base de dados é um desktop PC com acesso a internet.
  • O equipamento mínimo para instalação e utilização do aplicativo mobile é um smartphone com sistema Android versão 3.x e que disponha de acesso à internet.
  • Os sistemas de cadastro e login funcionam diretamente nas aplicações, não sendo necessário acesso a qualquer sistema externo.
  • Caso seja necessário acesso em tempo real de bases de dados e código, a equipe do GT-RarasNet fornecerá login administrativo.
  • Caso a equipe gestora técnica necessite de uma instalação funcional em servidor que não seja aquele do projeto ou o servidor virtual cedido pela RNP, o equipamento mínimo é um servidor LAMP com as últimas versões de MySQL, PHP e Apache.

3.    Cronograma

Atividades e entregas do projeto:

  1. OE6: Apresentação Final do protótipo e pactuação das atividades (Kick-off 2016)
  2. RP5: Planejamento das atividades
  3. RT3: Relatório de mapeamento de componentes e licenças de software
  4. OE7: Site do GT atualizado
  5. RT4: Plano de testes do piloto
  6. RP6: Relatório de planejamento para inclusão no portfólio do MS
  7. RA5: Relatório de acompanhamento trimestral 1 (Abril-Junho)
  8. OE8: Entrega do código-fonte da versão implantada no piloto (códigos-fonte, executáveis, scripts, arquivos de configuração etc.)
  9. OE9: Demonstração em evento
  10. REV: Relatório de participação e demonstração em evento.
  11. RT5: Avaliação dos resultados do Piloto
  12. RA6: Relatório de acompanhamento trimestral 2 (Julho-Setembro)
  13. RP7: Relatório de planejamento do Workshop de transferência de conhecimento
  14. RT6: Recomendações para a implantação do serviço/produto
  15. OE10: Realização do Workshop de Disseminação de conhecimento (data a definir)
  16. Atualização do RT3: Relatório de mapeamento de componentes e licenças de software
  17. OE11: Entrega final do código-fonte e documentação
  18. OE10: Entrega de documentação atualizada (manuais de instalação e administração, manuais de usuário etc.)
  19. RF: Relatório final

[1] http://www.scrumguides.org

[2] https://trello.com/