kyriosdata / db Goto Github PK

View Code? Open in Web Editor NEW

8.0 8.0 3.0 8.61 MB

A health database management system

HTML 100.00%

db's People

Contributors

Stargazers

Watchers

Forkers

michaelsampietro igorqsilva gregggreggreg

db's Issues

Componentes

Geração de relatórios

Embora papel deva ser "evitado" e tenha sua necessidade reduzida de forma significativa, ainda será necessário em alguns casos excepcionais, por exemplo, quando houver indisponibilidade do sistema o que exige o emprego de formulários para preenchimento manual. Adicionalmente, versão impressa do conteúdo de um RES pode ser requisitado de forma explícita em papel (impresso). Esse componente tem como objetivo gerar uma versão em papel do conteúdo de dados baseados em arquétipos.

As ferramentas mais amplamente comentadas para esse cenário são:

JasperReports Studio (geração de templates) (http://community.jaspersoft.com/project/jaspersoft-studio)
JasperReports Library (geração de HTML, PDF, Excel, ...) (http://community.jaspersoft.com/project/jasperreports-library).

Componentes variados

Estratégia para persistência

Compressão

Conforme aqui o algoritmo LZFSE oferece resultados "impressionantes" em termos de compressão e, ao mesmo tempo, desempenho. Naturalmente, torna-se uma escolha a ser investigada para "empacotar" dados antes de serem transferidos. Estudo deve investigar implementações disponíveis e orientar processo de decisão com compromissos baseados no desempenho e taxa de compressão. Por exemplo, para a saúde a compressão deve prevalecer sobre o desempenho ou o inverso? Como decidir corretamente? Qual o algoritmo a ser utilizado? Consultar TurboBench (aqui). Qual a orientação que o estudo estabelece em termos do tamanho dos "pacotes" a serem transferidos? Há alguma sugestão para o desenvolvimento do healthdb? O SGBDs fazem nesse sentido? O que sistemas operacionais fazem? O que middlewares estão fazendo? Experimentar https://github.com/lzfse/lzfse ou outra implementação para "verificar" resultados.

Conversor XML documents (openEHR schemas) para healthcodec.

Converte documentos XML baseados nos schemas do openEHR para o healthcodec.

Adaptador healthcode para oferecer visão compatível com openEHR xml schemas

Oferece "visão" de acesso a um documento XML (baseado nos schemas do openehr) mas cujos dados estão empregando o healthcodec.

Conversor healthcodec para XML documents

Converte formato healthcodec para documentos XML em conformidade com os schemas do openEHR.

Componentes para acesso ao barramento do SUS

Acesso ao barramento do CNS (aqui)

Integração CADSUS PIX/PDQ (admite alteração e não apenas consulta)
Arquitetura: web service conecta-se com o serviço e oferece API específica para web (browser).
Visão: usuário humano interage com SPA por meio da qual ocorre acesso ao web service criado que, por sua vez, faz acesso ao CADSUS PIX/PDQ.

Acesso ao CNES (aqui)

Quais as funções que deve oferecer?
Como encapsular esse acesso em um componente de alto nível?

Acesso ao HORUS (aqui)

Quais as funções que deve oferecer?
Como encapsular esse acesso em um componente de alto nível?

Componente de acesso ao SIGTAP (aqui)

Quais as funções que deve oferecer?
Como encapsular esse acesso em um componente de alto nível?

Transferir Wiki para gitbook

Há mais de uma centena de wikis, o acesso é relativamente "complexo", o que desestimula a experimentação e inclusive dificulta a busca. Investigar a possibilidade de uso do Gitbook (http://www.gitbook.com).

Clientes (como facilitar a criação de SIS e administrativo)

API de acesso de SIS

No caso mais geral, um SIS faz uso de uma API, dentre as várias disponíveis, para acesso às funcionalidades do HD, conforme ilustrado abaixo. Consulte #1 para detalhes.

AR ou VR para navegar entre dados da saúde

Como fazer isso? Dados baseados no openEHR

Padrão tabular para respostas

Requisições retornam, em muitos casos, dados em forma de tabelas. Nesses casos, qual o modelo oferecido para o programador para acesso a tais dados? Uma variante de ResultSet restrita às operações de consulta? Simples vetor de objetos (JSON), JDBC-like resultset, outro? Qual o codec correspondente? Também contemplado em #1 .

Objetos de interação para arquétipos

Para auxiliar a elaboração de SIS, um conjunto de "views" predefinidas encontra-se disponível, em geral, há uma view (ou mais) para um arquétipo disponível no CKM. Trata-se de um conjunto de objetos de interação previamente estabelecidos para cada arquétipo. Esses objetos permitem a entrada e a consulta das informações referentes ao arquétipo. Nessa linha de trabalho, dado um conjunto de arquétipos, a GUI correspondente é gerada de forma automática e oferece ao usuário uma visualização "atrativa" para os profissionais de saúde. Objetos para uso em browser, iOs e Android e displays de baixo custo. Links relevantes: flexbox.

Ember (escolha para SPA framework)

Ember (http://emberjs.com/)
Ember-cli (https://ember-cli.com/)
Ambiente web para desenvolvimento (http://jsfiddle.net/ember/)
Ambiente web para desenvolvimento (http://emberjs.jsbin.com/)
Ambiente web para desenvolvimento (https://ember-twiddle.com/)
https://ghost.org/ (feito com Ember)
http://www.discourse.org/ (feito com Ember)

Projeto de interação para saúde

Cliente administrativo (acesso/configuração de serviços do healthdb)

Apenas um cliente administrativo é previamente fornecido com o HD. Por meio dele é possível emitir requisições AQL para dados criados com base em arquétipos. Embora toda a funcionalidade do HD possa ser explorada por meio desse cliente, trata-se de instrumento de desenvolvimento e de administração do HD. O que se pode fazer com o Cliente Administrativo (CA) é definido pelos serviços oferecidos pela HD API:

Executar sentenças AQL, executar sentenças em GraphQL (veja imagem abaixo)
Inserir dados com base em arquétipos
Cadastrar arquétipos
Consultar e alterar configuração do HD

Arquitetura

Disponível em http://www.snia.org/sites/default/files/Ali_Eghlima_Adding_Omics_Data_ABDS-2015.pdf

também inclui a lista abaixo. Como deixar os dados "independentes" de uma dessas ferramentas?

Governança

Sistema de Gestão de Continuidade de Negócios (SGCN)

SisVida é um Sistema Estadual de Informação em Saúde proposto para o estado de Goiás. Trata-se de um sistema crítico do qual os serviços de saúde recebem significativo impacto. Em decorrência, torna-se imprescindível a definição de um plano de continuidade de negócios (segundo [2]: "procedimentos documentados que orientam as organizações a responder, recuperar, retomar e restaurar, após interrupção, para um nível predefinido de operação"). De fato, o objetivo do projeto é "definir um Sistema de Gestão de Continuidade de Negócios (SGCN), que inclui o plano de continuidade de negócios". Conforme [1]: "a continuidade de negócios é a capacidade que uma organização tem de continuar a entrega de produtos ou serviços em níveis aceitáveis pré-definidos após um incidente de interrupção". O objetivo do plano é assegurar que um evento (um incidente) não impeça que a organização retome suas operações antes que surjam níveis de impacto inaceitáveis. Dito de outra forma, o entregável do presente projeto é uma proposta de SGCN para o SisVida. De fato, não é viável nem recomendado a definição do SisVida sem esse importante SGCN, que pode ser considerado parte do SisVida. A definição do SGCN para o SisVida deverá estar em conformidade, onde aplicável, às normas [1,2].

Referências:

ABNT NBR ISO 22313:2015 Segurança da sociedade -- Sistemas de gestão de continuidade de negócios -- Orientações [1]
ABNT NBR ISO 22301:2013 -- Segurança da sociedade -- Sistema de gestão de continuidade de negócios -- Requisitos [2]

Benchmark

Criação de benchmark para saúde bucal

Tem dependência do domínio #7. Requisitos e arquétipos.
Qual o volume de dados para saúde bucal no estado de goiás?
Criar base de dados para testes (funcionais e desempenho).
A implementação da base de dados para testes deve seguir formato que facilita o uso em cenários onde bancos de dados correspondentes serão gerados na forma de relações, JSON ou outro. Noutras palavras, a implementação deverá "facilitar" o uso independente da organização física dos dados.
Quais as consultas seriam relevantes?
Não são conhecidos benchmarks para SISs.

Hardware e System Software

Commodity hardware (definição aqui)

Só em Goiás existem milhares de unidades de atendimento ambulatorial. Naturalmente, qualquer investimento em TI para "informatizá-las" significa recursos financeiros significativos. Esse projeto deve investigar "hardware de baixo custo" e balancear com os recursos que oferece, definindo uma configuração de referência. Essa configuração será considerada para a definição de restrições para o software.

Qual o hardware de "baixo custo" e adequado para executar o healthdb, inclusive clientes? Deve ser claro que um computador "recente" é suficiente, contudo, uma plataforma de baixo custo baseada em Arduino, por exemplo, é viável?
Quais os hardwares que deveríamos ter como foco?
Qual a capacidade desse hardware? O que ele deve oferecer como mínimo?
Quais as restrições que impões sobre o software?
Quais os dispositivos de comunicação (hubs, roteadores,)? Qual a configuração deles?
Quais são os monitores, telas ou displays de baixo custo visando uma adoção de custo reduzido em grande escala (por exemplo, todo o estado)?
Quais são os critérios relevantes para escolha desse display? Resolução, cores, custo, e outros?

Sistema operacional personalizado para Hardware de baixo custo

Enquanto o projeto anterior faz análise de hardware disponível, o presente projeto visa "montar" o Sistema Operacional a ser empregado pelo hardware definido. O objetivo é "maximizar" a potencialidade do hardware, o que em geral significa eliminar componentes desnecessários.

Experimento usando ferramenta como UniK (https://github.com/emc-advanced-dev/unik). Realizar testes usando VirtualBox (dentre outros). A "prova de conceito" deve incluir uma aplicação qualquer que faz uso de todos os serviços esperados pelo HealthDB. Por exemplo, o HDB fará uso do sistema de arquivos, então é necessário que o aplicativo.

Funções (requisitos, restrições, ...)

openEHR implementação mínima

Um EHR mínimo baseado no openEHR. Inclui: repositório de arquétipos, serviço de terminologias, repositório de dados demográficos (empregado para oferecer as entidades para as quais os EHRs estão apontando).

Manual da SBIS para S-RES

T1: análise de requisitos do manual à luz de S-RES regional para saúde bucal. Contar com apoio da Juliana e da Renata. Resultado: monografia contendo análise dos requisitos "pertinentes" ao contexto do healthdb.

Portaria 2073 (aqui)

T2: Análise da Portaria 2073 do MS à luz de um sistema locoregional. O que é obrigatório? O que está claramente definido? O que ainda falta regulamentação? Qual o impacto em novos desenvolvidos que desejam estar aderentes à essa portaria?

Serviços do barramento do Datasus (aqui)

Quais são eles? Em que cenários devem ser utilizados? O trabalho deve oferecer uma visão de uso desses serviços.

Importância da informação em saúde

De fato, a informação em saúde é relevante? Quais são as evidências em uma clínica, em um hospital, na nossa cidade, no nosso estado, no país e no mundo?
Pode reduzir custos, de fato?
Pode salvar vidas, de fato?
Pode avançar o estado da arte da pesquisa em saúde, de fato?
O mundo seria "melhor" com informação em saúde dos cidadãos disponíveis?
Qual o interesse satisfeito para informação em saúde disponível? Esse interesse é legítimo?

Saúde (domínio)

Saúde bucal

Funcionalidades

Especificação de requisitos.
Projeto de interação
Protótipo do projeto de interação

Arquétipos (saúde bucal)

APIs e protocolo HD

Linguagem de desenvolvimento

Investigar a possibilidade de uso de Webassembly (http://webassembly.org/).

Modelo de API

table-driven like ResultSet. Implementação da interface resultset. Apenas consulta?
conversor HD para mr do openehr
implementação do mr ou reimplementacao o baseada no HD formato.
nova implementação do mr baseada no HD formato. Anteriores convertem esse é novo.
XPath
JSON cloud approach to search JSON data
healthcodec (https://github.com/kyriosdata/codec) é um formato compacto e admite operações eficientes em iOs, Android, Windows Phone, além de Linux, Windows e MacOs. Ou seja, é empregado para transferir informação em saúde baseada no openEHR, em vez de JSON ou XML, por exemplo.
drivers que convertem XML para codec e vice-versa. Em várias linguagens uma para cada um dos clientes. Veja #5.
Cliente faz uso de API implementada em js, Java, c, c#, Swift.
Verificar json (http://jsonassert.skyscreamer.org/)
REST (how)

Infraestrutura de desenvolvimento

Documentação do projeto

Ferramentas de desenvolvimento de referência

Análise de ferramentas "atuais" e "recomendadas" para as necessidades do HealthDB. Considerar a forma como ferramentas como hsqldb, H2, Derby, SQLite e Realm.

Todo o aparato technológico deverá ser documentado usando Technology Radar (aqui)
Análise das "ferramentas" mais indicadas para o desenvolvimento do HealthDB.
Radar (https://www.thoughtworks.com/radar)
JaxLondon (https://jaxlondon.com/jax-awards/)

Entrega Contínua para o projeto HealthDB

Definição do ambiente de entrega contínua, o que inclui as ferramentas, os recursos a serem empregados e a configuração inicial (prova de conceito).

https://devops.com/9-open-source-devops-tools-love/
Definição e implantação de "entrega contínua" para o projeto.
Inclui busca por ferramentas seguida da seleção, para os vários ambientes de desenvolvimento.
Como empacotar o resultado (db)? Packer (https://www.packer.io/)?
Entrega contínua para HealthDB.
Packer para auxiliar a entrega contínua.