RES: [sbis_l] Google diz ser impossivel cumprir determinacao do stj para abrir dados do gmail

Olá Dra. Jussara e outros membros da SBIS, Boa Noite.

Dra. Jussara, você sabe o quanto admiro o seu trabalho ao longo desses anos que nos conhecemos e que meu nível de conhecimento da arquitetura OpenEHR é pouco se comparado com o seu e de outras membros da SBIS, mas já li um pouquinho sobre ele e isso me permite o atrevimento em te responder a seguir.

O uso OpenEHR tenta resolver questões como uniformizar e disponibilizar os conceitos do negócio saúde de forma aberta (não vou discutir aqui a questão do pagamento dos royalties, pois, não é o tema do debate), criando objetos e classes de negócios (aliás, Modelo Orientado a Objetos é um conceito antigo na Ciência da Computação) sobre os conceitos envolvidos na prática de saúde que podem ser reutilizados em vários sistemas, mas a arquitetura OpenEHR não resolve um problema real, que todos os desenvolvedores de Sistemas de Informação em Saúde têm, que é a modelagem Conceitual, Lógica e Física do Dados e do banco de Dados e que na prática nos obriga a ter o modelo de dados real e não um metadados, que possa gerenciar, como já falei no e-mail anterior, conceitualmente, logicamente e fisicamente esses dados, não só com segurança, mais também com transações persistentes, controle de concorrência, serialização, bloqueios, compactação, controle de integridade, desempenho, entre outros itens importantes e fundamentais que garantam o controle total dos dados por quem é responsável legal, técnico e administrativo por eles.

Em que pese a belíssima apresentação do Dr. Vince Kutais, falta a ela, se me permite ser ousado mais uma vez, uma visão realista de Gerencia de Dados e Banco de Dados e de desenvolvimento de sistemas corporativos em larga escala e distribuídos, sistemas esses onde estão verdadeiramente os dados de saúde das pessoas.

O problema central da Computação nas Nuvens não está em compartilhar Objetos e Classes (arquétipos), não está apresentar a identificação dos pacientes ou unificar e reutilizar os conceitos médicos, mas sim em não definir uma infra-estrutura de Gerencia de Dados e Banco de Dados viável (porque no fundo esses dados são concretos e reais), em ter uma infra-estrutura legal definidas nos países e no mundo (porque responsabilidade cível é dura, é cultural, reflete a realidade de um povo e é um caso quase impossível ser mundial) e finalmente, Sistemas Distruídos são caros, complexos e necessitam de muito cientista e analista de computação trabalhando neles.

Infelizmente ou felizmente, dependendo do ponto de vista, não é possível desenvolver sistemas de informação em saúde corporativos, onde todos os processos, tais como inserção, atualização, exclusão e consulta aos dados sejam implantados sem a definição de Modelos de Engenharia de Software e Modelos de Dados e Bancos de Dados planejados, desenvolvidos, testados, colocados em produção e mantidos com segurança e técnicas de SGBDs e Processos.

Luciano Lima.


De: sbis_l@googlegroups.com [mailto:sbis_l@googlegroups.com] Em nome de Jussara macedo
Enviada em: segunda-feira, 10 de junho de 2013 14:06
Para: sbis_l@googlegroups.com
Assunto: Re: [sbis_l] Google diz ser impossivel cumprir determinacao do stj para abrir dados do gmail

Luciano, a arquitetura do RES openEHR já foi desenvolvida levando em consideração uma distribuição dos dados, pois foi baseada na norma ISO/IEC 10746, mas conhecida como RM -ODP (http://en.wikipedia.org/wiki/RM-ODP)<http://en.wikipedia.org/wiki/RM-ODP0>, que também é base de uma série de normas ISO, inclusive a de arquitetura de RES, que é uma das bases do manual SBIS/CFM e cuja revisão de 2011 já se encontra publicada em português. Outra norma é ISO/CEN 13.606 que é de comunicação de dados entre RES usando o modelo de arquétipos, que tem cinco partes, uma delas a 4 trata justamente de segurança.

A persistência dos dados clínicos, no modelo openEHR, encontra-se separada dos dados demográficos, que identificam os pacientes, por questões de segurança entre outras, o que significa que você pode até ver os dados, mas não sabe de quem são. Esse é apenas um dos motivos desse modelo de arquitetura ver sendo cada vez mais sendo a arquitetura projetos de esaúde no mundo, justamente por ter se preocupado com os dados num sistema distribuído.
Future of proof EHRs, é a preocupação dos membros da fundação openEHR. Vale a pena quem ainda não conhece e está interessado em plataformas abertas de serviços de RES distribuidos na nuvem (PaaS), dar uma estudada no modelo (http://www.openehr.org/wiki/display/spec/openEHR+Service+Model)

Anexo uma apresentação do Dr Vince Kuraitis sobre o assunto.
Abs a todos
jussara


Jussara Rötzsch
Md, MSc
Director, OpenEHR Foundation
Owner, Giant Global Graph ehealth Solutions


2013/6/10 Abel Magalhaes <magalhaes.abel@gmail.com<mailto:magalhaes.abel@gmail.com>>
Prezado colega "computonauta" Luciano

Muito obrigado pelos esclarecimentos/lembretes do seu email, em particular o 4o parágrafo que trata de alguns princípios básicos.

São justamente estes que têm sido um entrave, na minha prática diária de consultor, para uma mais ampla implantação de sistemas cloud.

Um abraço

Abel

Dr Abel Magalhães | magalhaes.abel@gmail.com<mailto:magalhaes.abel@gmail.com>
Cardiologia e Clínica Médica | CRM 52.58558-8
http://www.abelmagalhaes.com.br

2013/6/10 Luciano Romero Soares de Lima <lucianorsl@sarah.br<mailto:lucianorsl@sarah.br>>
Caro Dr. Sabbatini e demais colegas da SBIS,

Em primeiro lugar, o termo "Computação nas Nuvens" é um termo novo, criado pelos bons marqueteiros de TI, para se tratar um conceito antigo da Ciência da Computação, chamado "Sistemas e Bancos de Dados Distribuídos", em muitos casos sem uma preocupação mais rigorosa que esse conceito complexo exige. Para quem quiser conhecer um pouco da complexidade do tema, recomendo um livro antigo de dois grandes pesquisadores brasileiros da área, professores Marco Antônio Casanova e Arnaldo Vieira Moura, professores da PUC-Rio, intitulado "Princípios de Sistemas de Gerência de Bancos de Dados Distribuídos".

Prof. Sabbatini, além das questões que você levantou no seu e-mail resposta, há outras de caráter técnico bastante difícil de serem respondidas e em muito mais complexas.

Por exemplo, é impossível ter qualquer sistema coorporativo, seja ele de que área for, se ele não estiver baseado, administrado e gerenciado por Sistemas de Gerenciamento de Banco de Dados referenciados e confiáveis, e isso é tão delicado, que até hoje, a maioria esmagadora das corporações utilizam os SGBDs baseados num conceito da computação chamado "Modelo Relacional" do Codd, construído nos anos 70 (há 40 anos).

Há princípios básicos dos sistemas de banco de dados, para não entrarmos no mérito geral dos Sistemas Distribuídos, que precisam ser observados e garantidos, como os conceitos de transações, controle de concorrência, serialização, bloqueios, compactação, controle de integridade, desempenho, entre outros itens importantes e fundamentais, que a chamada "Computação nas Nuvens" não tem a menor preocupação, pelo menos nos textos que eu li até o momento. Não vejo iniciativas de pesos pesados da área de Banco de Dados, como a Oracle, por exemplo, apresentando uma futura versão do seu SGBD para bases de dados nas "nuvens".

Acho que a menor das preocupações é visualização de dados de pacientes em aparelhos móveis, hoje isso é possível, seguindo inclusive a questão da assinatura digital, desde que tenha pleno controle onde os dados estão.

Para finalizar, capilaridade das informações se consegue com os sistemas atuais, sem problema nenhum, o que não é possível, e isso minha experiência tem me ensinado (pode até ser de maneira errada), que não se gerencia dados sensíveis, sem ter o controle total dos sistemas e das bases de dados.

Todos os sítios famosos (Google, Facebook, LinkedIn, etc.) que apregoam o uso da chamada "Computação nas Nuvens", guardam dados, em geral, pessoais, incluindo dados multimídias, e duvido que se preocupem com as questões conceituais que levantei acima, porque elas custam muito caro e é mais barato, quando um problema acontecer, pagar as custas judiciais de um processo.

Por essas razões, na conjuntura atual, nem a versão 10 do manual SBIS/CFM, na minha opinião, terá condições de resolver esse tema, porque, pelo menos no estágio atual e na perspectiva que já vivi dos sistemas computacionais distribuídos, a "Computação nas Nuvens", em que pese os avanços tecnológicos da TIC que o mundo obteve, tem muito feijão para comer.

Insisto, para finalizar, que duvido que alguém técnico de TIC consiga convencer um Diretor Clínico, um Diretor de Tecnologia em Saúde ou um Diretor-Presidente de uma Instituição de Saúde, e dizer para ele, Senhor, vamos colocar seus dados nas nuvens, mesmo que dentro do país, mas não temos como garantir o controle total sobre eles.

Desculpe-me o tamanho do texto, mas o tema transcende a informática em saúde e só será resolvido pela Ciência da Computação, tanto teórica, como experimentalmente, bem como na prática.

Luciano Lima.

-----Mensagem original-----
De: sbis_l@googlegroups.com<mailto:sbis_l@googlegroups.com> [mailto:sbis_l@googlegroups.com<mailto:sbis_l@googlegroups.com>] Em nome de Renato M.E. Sabbatini, PhD
Enviada em: domingo, 9 de junho de 2013 17:15
Para: sbis_l@googlegroups.com<mailto:sbis_l@googlegroups.com>
Assunto: Re: [sbis_l] Google diz ser impossivel cumprir determinacao do stj para abrir dados do gmail
Em 7/6/2013 14:37, Luciano Romero Soares de Lima escreveu:
> Para finalizar, com o Manual de Certificação do CFM atual e nas suas perspectivas de novas versões, seria necessário se riscar vários parágrafos desse manual.
> Luciano Lima.
O atual manual de certificação foi elaborado praticamente em 2008, cinco anos atrás, uma eternidade no diz respeito à evolução da tecnologia.
Smartphones e tablets estavam começando, nuvem era uma coisa no céu, e tantas outras evoluções perturbadoras do cenário. Luciano, realmente existem muitos requisitos na versão 3.3 que não se aplicam a cenários atuais, portanto sistemas modernos não conseguem ser certificados pela SBIS. Alguns pontos:

1. Como se faz a sincronização segura de datas/tempo com a nuvem?
2. Como se implementa comunicação segura entre componentes fisicamente separados dos servidores em nuvem?
3. Como se protege um backup do sistema, se ele é feito no datacenter, automaticamente, sem controle do sistema aplicativo? Onde reside(m) o(s)
backup(s) do sistema?
4. Como se faz a autenticação e assinatura usando um smartcard como o CRM Digital em dispositivos móveis?
5. Como tratar a questão de data/hora em telemedicina?

A versão 4, se não me engano, continua a não tratar essas questões.
Portanto, teremos que esperar a versão 5, quando então teremos outras novidades tecnológicas (como o Google Glass), que provocarão novos questionamentos em relação a certificação.

> COncordo acho que um posicionamento SBIS - CFM seria um grande avanço
> para fomentar a melhoria da estrutura das ofertas de nuvem no pais,
> além de dar um "norte" para as empresas que querem montar e oferecer
> este tipo de servico no BRasil.... Gottberg
Com a palavra a gerência de certificação da SBIS.... Corremos o perigo de estarmos sempre obsoletos (aliás, todo mundo está sempre obsoleto, devido à grande velocidade da evolução tecnológica).
>
> Atão em outro país é bastante complicada a responsabilização legal. Seria muito bom promover essa discussao na câmara técnica do CFM e na SBIS resultando em um posicionamento.
> Kiatake
>
>
Concordo, Kia!
A guarta virtual é a mesma coisa que guarda física? Ter o controle sobre os bancos de dados, não interessa onde estiverem, equivale à uma guarda real? São questões que precisamos discutir, e também obter posicionamentos do CFM e outros conselhos da área de saúde.

Abraços
Sabbatini


--
--
----------------------------------------------------------
Seja associado da SBIS!
Visite o site www.sbis.org.br<http://www.sbis.org.br>

---
Você está recebendo esta mensagem porque se inscreveu no grupo "Sociedade Brasileira de Informática em Saúde - Lista de Discussão" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para sbis_l+unsubscribe@googlegroups.com<mailto:sbis_l%2Bunsubscribe@googlegroups.com>.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.

--
--
----------------------------------------------------------
Seja associado da SBIS!
Visite o site www.sbis.org.br<http://www.sbis.org.br>

---
Você está recebendo esta mensagem porque se inscreveu no grupo "Sociedade Brasileira de Informática em Saúde - Lista de Discussão" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para sbis_l+unsubscribe@googlegroups.com<mailto:sbis_l%2Bunsubscribe@googlegroups.com>.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.


--
--
----------------------------------------------------------
Seja associado da SBIS!
Visite o site www.sbis.org.br<http://www.sbis.org.br>

---
Você está recebendo esta mensagem porque se inscreveu no grupo "Sociedade Brasileira de Informática em Saúde - Lista de Discussão" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para sbis_l+unsubscribe@googlegroups.com<mailto:sbis_l%2Bunsubscribe@googlegroups.com>.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.



--
--
----------------------------------------------------------
Seja associado da SBIS!
Visite o site www.sbis.org.br<http://www.sbis.org.br>

---
Você está recebendo esta mensagem porque se inscreveu no grupo "Sociedade Brasileira de Informática em Saúde - Lista de Discussão" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para sbis_l+unsubscribe@googlegroups.com<mailto:sbis_l+unsubscribe@googlegroups.com>.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.


--
--
----------------------------------------------------------
Seja associado da SBIS!
Visite o site www.sbis.org.br

---
Você está recebendo esta mensagem porque se inscreveu no grupo "Sociedade Brasileira de Informática em Saúde - Lista de Discussão" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para sbis_l+unsubscribe@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.