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:
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.
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:
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)
Acesso ao CNES (aqui)
Acesso ao HORUS (aqui)
Componente de acesso ao SIGTAP (aqui)