| (4 revisões intermediárias por 3 usuários não estão sendo mostradas) | |||
| Linha 114: | Linha 114: | ||
= Casos de Uso = | = Casos de Uso = | ||
[[Arquivo: | [[Arquivo:Diagrama Caso de uso.jpg]] | ||
== Detalhamento == | == Detalhamento == | ||
| Linha 589: | Linha 589: | ||
::O sistema respeitará todo o sigilo médico-paciente; | ::O sistema respeitará todo o sigilo médico-paciente; | ||
= | = Código = | ||
<br> | <br> | ||
=>Link no MEGA: https://mega.co.nz/#!sIJ0gLhZ!6Ou16ZZo7TxZ9Se3WmswW6xe3jUeBMmpJFjtgt2JUoI | |||
Edição atual tal como às 00h05min de 27 de agosto de 2014
5W2H
- Nome do Projeto: iHealth
What
1. Qual o objetivo deste projeto?
- O projeto prevê a construção de um sistema de controle de Prontuários Eletrônicos, incorporando atendimentos em estabelecimentos de saúde público e privados, que poderão ser disponibilizados para médicos, laboratórios e pacientes em geral. Estes prontuários controlarão os exames clínicos básicos tendo flexibilidade para incorporar novas demandas para laboratórios que possuírem exames específicos.
- O sistema tornará possível a transmissão de imagens médicas via rede e a visualização em computadores remotos e dispositivos móveis, a qualquer hora, de qualquer lugar, por pacientes, médicos ou quem mais o paciente autorize o acesso a suas informações.
2. Quais os maiores desafios, na sua opinião, para se realizar este trabalho?
- Desenvolvimento de um cadastro único para cada paciente;
- Integração, consistência, sincronização e envio dos mesmo para a nuvem;
- A atualização das informações;
- Criar uma barreira de segurança confiável, para o acesso às informações (privacidade e confidencialidade);
- O armazenamento das mídias, como laudos,e exames radiológicos, vídeos de cirurgias, entre outros.
- Disponibilidade 24/7 sem interrupções;
- Tornar todo o sistema independente;
3. Quais os conhecimentos básicos que devemos ter para se implementar este projeto?
- Conhecimentos avançados em programação; Domínio intermediário sobre o funcionamento do armazenamento em nuvem; *Domínio sobre banco de dados;
- Entendimento detalhado do funcionamento do sistema de prontuário hospitalar (burocrático, clínico...).
4. Quais soluções similares existem no mercado?
- Existe aplicado no Sistema Único de Saúde(SUS), um sistema que armazena toda a vida de "paciente" de um residente no país, bastante parecido com sistema proposto, diferenciando que o mesmo só armazena informações em texto sobre atendimentos, fazendo com que haja muita burocracia, quando se diz respeito a repetição de exames, entre outros. Esse sistema é denominado E-SUS, e começou a ser aplicado, no munícipio de Uberlândia, no começo do ano de 2014.
- [1]
- [2]
Why
1. Porque é interessante desenvolver este projeto?
- É interessante desenvolver, pois o sistema proposto, dá ao hospital/centro de atendimento, agilidade no atendimento, na busca do histórico de consultas e exames de um paciente, reduz custos públicos e privados e torna possível, mesmo em áreas remotas, acesso rápido e simples a qualquer modalidade de exame médico.
2. Porque deve-se usar a tecnologia escolhida?
- Pela oportunidade de redução de custos, e melhora do sistema de atendimento em saúde, tanto público como privado no país.
Who
1. Quem pode se beneficiar deste projeto?
- O projeto em seu estágio final, beneficiará toda a população brasileira, pois em um único sistema, estará envolvido todo o histórico de atendimentos/exames do paciente.
2. Quem poderá operar o sistema?
- O sistema poderá ser operado em três graus distintos :
- 1º Grau : Pacientes - Pacientes poderão operar o sistema para, por exemplo, obter resultado de exames, mas o acesso do mesmo, será somente em modo visualização. - 2º Grau : Médicos - Terão liberdade acessar todo o histórico de atendimento de uma pessoa, mas não será liberado ao mesmo, exclusão de nenhum registro definitivo. - 3º Grau : Desenvolvedores e responsáveis (manutenção) do sistema - Terão total liberdade sobre exclusão de registros, mas não será possível ao mesmo visualizar a quem pertence o registro.(Questão sigilo médico/paciente)
3. Quem deverá participar do desenvolvimento do sistema?
- Profissionais da área de Engenharia(Engenheiros: Biomédicos, Elétricista, Computacional, Controle e Automação, entre outros, e profissionais técnicos de áreas afins), profissionais da área de programação e de Gestão Hospitalar.
Where
1. Onde os dados serão inseridos?
- Os dados serão inseridos no próprio sistema, consequentemente, armazenado em nuvem.
2. Onde os dados serão externalizados, publicados?
- Os dados serão publicados em tela de visualização do sistema, onde através de um número (prontuário) poderá se visualizar os registros médicos de uma pessoa.
3. Onde esta aplicação poderá ser usada?
- Esta aplicação poderá ser usada em todos os hospitais e centros de atendimento em saúde, como UBS, PSF's, UAPS, UAI e UPA, de ordem pública ou privada.
4. Onde as informações serão armazenadas?
- As informações serão todas lançadas à um banco de dados, que estará armazenado em nuvem.
5. Onde o software deverá ser hospedado?
- O software deverá ser hospedado hospitais e centros de atendimento em saúde.
,
When
1. Em quanto tempo pretende desenvolver o sistema?
- O projeto possui como meta, ser desenvolvido em aproximadamente 36 meses.
2. Quais serão as fases e em quanto tempo cada uma?
- O projeto será dividido em 6 etapas :
- 1ª Etapa: Estudo das tecnologias e da melhor maneira em que poderão ser aplicadas ao sistema aqui proposto. (~6 meses)
- 2ª Etapa: Escolha da opção que melhor se adapte à aos problemas descritos, que levou ao pensamento do projeto. (~2 meses)
- 3ª Etapa: Implementação de um código-fonte. (~8 meses)
- 4ª Etapa: Montagem de um primeiro protótipo, testando o armazenamento parcial e impressão de dados na tela, geração de prontuário, e armazenamento em nuvem. (~ 3 meses)
- 5ª Etapa: Simulação de um teste, aplicando-o a um posto de saúde, em um bairro, transferindo todo o conteúdo de dados do paciente, para o paciente .(~5 meses)
- 6ª Etapa: Migragem de todos os dados, de todos os pacientes do sistema antigo, para o novo.(~12 meses)
- 7ª Etapa: Sistema finalizado, montagem de equipe de suporte para o sistema.
How
1. Como será dividido o desenvolvimento do sistema?
- Estudo do sistema de armazenamento em nuvem, programação e requisitos funcionais do sistema denotando as melhores maneiras de solucionar o "problema" que havia usando o sistema antigo.
- Desenvolvimento do código-fonte, consequentemente o software.
- Teste do protótipo, em um posto de saúde de bairro pequeno, migrando parte dos dados, para o novo sistema, averiguando possíveis falhas.
2. Como será feita a entrada de dados?
- No próprio sistema haverá um espaço apropriado para que se redija detalhes sobre o atendimento, atestados, receitas médicas, e SCAN's de exames de imagem, como Ressonância Magnética e Raios-X, por exemplo.
3. Como será feita a saída de dados?
- Será impresso na tela, quando digitado o prontuário e senha, que cada pessoa terá.
How much
1. Quanto deverá custar o sistema?
- Aproximadamente 15 mil reais.
2. Quantas pessoas deverão ser usadas?
- Deverão ser usadas 10 pessoas.
3. Qual deverá ser o preço de aquisição do seu software para o usuário final?
- (R$ 5 mil - referentes aos direitos de propriedade intelectual), por cada estabelecimento que adquira o sistema.
Diagrama de Classes
Casos de Uso
Detalhamento
- 1º Ambiente
• Identificação do Caso de Uso: Caso de Uso 1
Nome do Caso de Uso: Marcar de consulta
Ator: Paciente
Pré-condições: Ter um cadastro já realizado no banco de dados.
Pós-condições: Se possuir cadastro verídico, a consulta é marcada.
Sequência de Eventos:
| Ação do Ator | Resposta do Sistema |
|---|---|
| - | 1. Sistema mostra o Menu de Opções |
| 2. Paciente diz que quer marcar uma consulta | 3. Sistema solicita o prontuário |
| 4. Cliente informa o prontuário | 5. Include Buscar Cadastro |
| - | 6. Include Escolher Especialista |
| - | 7. Include Enviar Confirmação |
Sequências Alternativas:
4ª.Dados Incompatíveis:
1. O sistema não autoriza a marcação de consulta solicitada pelo Paciente.
2. O sistema volta para o menu de opções.
• Identificação do Caso de Uso: Caso de Uso 2
Nome do Caso de Uso: Enviar Confirmação
Descrição: O Paciente interage com o Software obtendo a confirmação da sua consulta.
Pré-condições: Paciente deve estar logado no sistema, e ter realizado a marcação de alguma consulta.
Pós-condições: Após a confirmação o sistema enviará uma mensagem (código, nº protocolo) ao paciente.
Sequência de Eventos:
| Ação do Ator | Resposta do Sistema |
|---|---|
| - | 1. Sistema exibe consultas disponíveis para confirmação |
| 2. Paciente escolhe uma Consulta Para Confirmar | 3. Sistema Exibe dados relativos a consulta |
| 4. Paciente clica na opção Confirmar Consulta | 5. Include Enviar Confirmação BD |
| 6. Cliente opta entre envio por e-mail ou mensagem SMS | 7. Sistema envia confirmação ao cliente |
Sequência alternativa:
2a – Paciente não escolhe uma opção ou demora muito tempo para escolhe-la.
1 – Sistema volta a tela de menu de opções.
- Inclusões
• Identificação do Caso de Uso: Caso de Uso 3
Nome do Caso de Uso: Buscar Cadastro
Ator: Banco de Dados
Pré-condições: Paciente busca cadastro
Pós-condições: Sequência de Eventos
Sequência de Eventos:
| Ação do Ator | Resposta do Sistema |
|---|---|
| - | 1. Sistema recebe o prontuário e senha |
| - | 2. Conecta com o Banco de Dados |
| 3. Banco de Dados compara prontuário e senha com registros | - |
| - | 6. Sistema solicita Valor a ser sacado |
| 4. BD envia resposta Ok para sistema | 5. Sistema buscou dados com sucesso |
Sequências Alternativas:
1a:O sistema não reconhece o prontuário e senhas do paciente
2. A operação é cancelada.
• Identificação do Caso de Uso: Caso de Uso 4
Nome do Caso de Uso: Escolher especialista
Ator: Banco de Dados
Pré-condições: Paciente cadastrado
Pós-condições: Sequência de Eventos
Sequência de Eventos:
| Ação do Ator | Resposta do Sistema |
|---|---|
| 1. BD solicita um especialista | 2. Sistema recebe pedido |
| - | 3. Conecta com o Banco de Dados |
| - | 4.Encontra especialista disponível |
| - | 5. Sistema envia confirmação. |
Sequências Alternativas:
1a.Não há especialista disponível:
1. O sistema não encontra especialista disponível, e reinicia uma busca até que encontre
2. A operação entra em loop.
• Identificação do Caso de Uso: Caso de Uso 5
Nome do Caso de Uso: Cadastrar Paciente
Ator: Secretária
Pré-condições: Paciente não possui cadastro
Pós-condições: Paciente cadastrado
Sequência de Eventos:
| Ação do Ator | Resposta do Sistema |
|---|---|
| 1. Pesquisa se o paciente já possui cadastro | 2. Include Buscar cadastro |
| - | 3. Sistema apresenta opção de cadastro |
| - | 4. Envia relatório de confirmação de cadastro para cliente |
Sequências Alternativas:
1ª Paciente já possui cadastro.
1 – Operação de cadastro cancelada;
2 – Secretária encaminha o paciente diretamente a um especialista
- Exclusão
• Identificação do Caso de Uso: Caso de Uso 6
Nome do Caso de Uso: Urgência
Ator: Secretária
Pré-condições: Problema de saúde vital.
Pós-condição: Após a consulta é tentado a identificação do paciente
Sequência de Eventos :
| Ação do Ator | Resposta do Sistema |
|---|---|
| 1. Secretária busca especialista | 2. Sistema encontra especialista |
| 5. Secretária encaminha paciente | 4. Sistema finalizado |
Sequências Alternativas:
1a- Caso não é considerado urgência;
2a - Paciente vem a falecer
- 2º Ambiente
• Identificação do Caso de Uso: Caso de Uso 7
Nome do Caso de Uso: Ir Consulta
Ator: Secretária, Médico
Descrição: Processo que registra a presença do médico e do paciente na consulta.
Pré-condições: Paciente deve ter marcado uma consulta anteriormente
Pós-condições: Registro de consulta efetuada.
Sequência de Eventos:
| Ação do Ator | Resposta do Sistema |
|---|---|
| 1. Confirma presença na consulta | 2. Sistema gera relatório de presença |
Sequências Alternativas:
2a.: Médico ou paciente não compareceram na consulta
1 - Sistema gera relatório apontando a falta de um dos dois.
2 - Opção de marcar nova consulta.
- Inclusão
• Identificação do Caso de Uso: Caso de Uso 8
Nome do Caso de Uso: Inserir informações no Banco de Dados
Ator: Médico
Pré-condições: Paciente não possuía certas informações associadas a ele ou apresentou uma nova condição de saúde.
Pós-condições: Dados do paciente acrescentados.
Sequência de Eventos:
| Ação do Ator | Resposta do Sistema |
|---|---|
| 1. Solicita a atualização dos dados do paciente | 2. Sistema mostra o campo de busca de prontuário |
| 3. Insere código do prontuário | 4. Include Buscar cadastro |
| - | 4. Sistema apresenta opções de visualizar ou editar |
| 5. Seleciona opção | 6. Sistema mostra menu de atualização |
| 7. Insere dados novos do paciente | 8. Armazena dados no Banco de Dados |
Sequências Alternativas:
3a.: Código digitado não possui associação com nenhum paciente.
1 - Sistema mostra tela de erro;
2 - Sistema volta a página de busca.
- 3º Ambiente
• Identificação do Caso de Uso: Caso de Uso 9
Nome do Caso de Uso: Atualizar Dados
Descrição: Secretária solicita uma atualização de dados de um determinado paciente e em seguida, enviará os novos dados no sistema.
Atores: Secretária
Pré-condições: Secretária deve estar logada no sistema e o paciente cadastrado.
Pós-condições: Banco de dados referente ao paciente atualizado
Sequência de Eventos:
| Ação do Ator | Resposta do Sistema |
|---|---|
| 1. Secretária solicita a atualização dos dados do paciente | 2. Sistema mostra o campo de busca de prontuário |
| 3. Secretária entra com o código do prontuário | 4. Include Buscar Cadastro |
| - | 5. Sistema mostra os campos disponíveis para atualização |
| 6. Secretária preenche os campos com as novas informações | 7. Sistema atualiza o banco de dados co sucesso |
Sequências Alternativas:
Código não cadastrado:
1 - O sistema não encontra o código do prontuário.
2 - O sistema volta para o menu de opções.
• Identificação do Caso de Uso: Caso de Uso 10
Nome do Caso de Uso: Visualizar Dados
Atores: Paciente, técnico ou médico.
Descrição: O ator solicita a visualização do prontuário de um paciente especifico de acordo com seu nível de acesso
Pré-condições: Ator deve estar logada no sistema, o paciente cadastrado e nível de acesso deve ser.
Pós-condições: -
Sequência de Eventos:
| Ação do Ator | Resposta do Sistema |
|---|---|
| 1. Ator solicita a visualização do prontuário de um paciente já identificado | 2. Sistema busca informações no registro |
| - | 3. Sistema mostra o prontuário solicitado com sucesso |
Sequências Alternativas:
Nível de acesso não permitido:
1 - O sistema impede o nível do usuário Paciente para visualizar prontuário de outros pacientes
2 - Sistema volta para o menu de opções.
• Identificação do Caso de Uso: Caso de Uso 11
Nome do Caso de Uso: Pesquisar informações cadastro
Descrição: Ator realiza uma busca do código do prontuário no sistema
Atores: Paciente, médico e técnico
Pré-condições: Ator deve estar logado no sistema e o paciente cadastrado.
Pós-condições: -
Sequência de Eventos:
| Ação do Ator | Resposta do Sistema | ||
|---|---|---|---|
| 1. Ator entra com o código do prontuário | 2. Sistema busca o código nos registros | ||
| - | 3. Include Verificar nível | - | 4. Sistema exibe os dados |
Sequências Alternativas:
Nível não permitido:
1 - Sistema impede a visualização dos dados.
2 - O sistema volta para o menu de opções.
- Inclusão
•Identificação do Caso de Uso: Caso de Uso 12
Nome do Caso de Uso: Verificar nível
Ator: Banco de Dados
Pré-condições: Tentativa de busca de cadastro
Pós-condições: Sequência de Eventos
Sequência de Eventos:
| Ação do Ator | Resposta do Sistema |
|---|---|
| - | 1. Sistema recebe o código do prontuário |
| - | 2. Conecta com o Banco de Dados |
| - | 3.É verificado o nível |
| 4. BD envia resposta Ok para sistema | 5. Acesso aos dados do paciente liberados com sucesso |
Sequências Alternativas:
1a.: 1 - Nível para visualização não é compatível com o nível requerido na área de acesso
2 - Operação cancelada, sistema retorna ao menu de opções.
Requisitos Não-Funcionais
- Ambiente:
- Navegador (IE, Firefox, Chrome);
- Armazenamento:
- Banco de Dados (MySql, Oracle);
- Hardware Específico:
- Teclado, mouse, leitor de código de barras;
- Nível de Serviço:
- Disponibilidade - 24/7
- Tempo Mínimo de reinicialização após falha;
- Confiabilidade;
- Acessibilidade:
- Letras em aumento;
- Áudio para deficientes visuais;
- Eficiência:
- O sistema deve atender à milhões de usuários, para isso deve contar com um serviço de atualizações e armazenamento mais extenso possível;
- Portabilidade:
- O sistema poderá ser utilizado em várias plataformas, primeiramente em desktops e notebooks;
- Interface web compatível com os navegadores mais populares (Google Chrome, Mozilla Firefox, IE, Opera);
- Entrega:
- O tempo de desenvolvimento do projeto é de aproximadamente 36 meses
- Pela larga utilização, o software deverá ser lançado em uma Beta(versão de teste) restrita à bairros, e seguidamente à alguma cidade, e crescendo o
número de usuários conforme forem detectados os erros que estarão por vir.
- Segurança:
- O sistema deve ser confiável, e para isso deve contar com um bom sistema de segurança.
- Interromper autenticação, bloqueando o sistema, após 4 tentativas de login errados (Enviar e-mail com código de desbloqueio à conta do usuário);
- Verificar corrupção de dados;
- Comunicação:
- Internet para transmissão de dados para nuvem;
- C#, C++, MySql;
- Taxa de transferência será compatível com a taxa de upload-download de arquivos, da internet presente na cidade;
- Éticas:
- O Sistema não poderá vazar dados, exames, ou qualquer outra informação de pacientes à outro usuário a não ser por médicos devidamente identificados;
- Legais:
- O sistema respeitará todo o sigilo médico-paciente;
Código
=>Link no MEGA: https://mega.co.nz/#!sIJ0gLhZ!6Ou16ZZo7TxZ9Se3WmswW6xe3jUeBMmpJFjtgt2JUoI

