Completed

Programador para sitio web

Published on the March 22, 2018 in IT & Programming

About this project

Open

Características generales

- Se desarrollará una aplicación web responsive (se podrá consultar desde desktop, y así mismo desde dispositivos móviles).

- La aplicación soportará 3 tipos de usuarios. Administradores, Médicos y pacientes.

- Cada receta va a tener su código, para asegurar que no se puedan duplicar, y el sistema se va a dejar preparado para integrarle el bloque de firma digital (pendiente de averiguar) y la receta al darle la orden de imprimir también se la puede descargar en la computadora en formato PDF.

- Las recetas confirmadas no podrán editarse y pertenecerán exclusivamente a quien la registró.(Las recetas de otros médicos pueden visualizarse y no modificarse. Una receta que ya generó su código tampoco puede modificarse)

- La información se va a comunicar de forma encriptada. El sitio va a contar con HTTPS, y todas las peticiones van a estar protegidas por un token que se va a refrescar consecutivamente.


- Todos los movimientos van a poder ser exportados en ficheros CSV, para su posterior análisis en Excel.
1)
-    Establecer un diseño base (responsive) al sitio. Esto incluye una página de inicio de sesión, de registro, y acceso a un panel de usuario.
Sistema de autenticación.
              Forma de registración de Médicos => Registro e inicio de sesión con correo y contraseña, además de la posibilidad de recuperar la contraseña vía correo electrónico => forma de registración de los usuarios médicos: lo hace el administrador. Puede hacerlo 1 a 1 o registrar en forma masiva desde un CSV.
En ambos casos el sistema generaría una contraseña para el médico y la enviaría a través de un correo.
El médico podría incluso usar la contraseña generada porque nadie la tendría, ni el mismo administrador.
Pero si quiere una contraseña que pueda recordar, la podrá cambiar.
              Forma de registración de Pacientes => desde un formulario a completar por el paciente generando una contraseña ó mismo método que se usa para registrar médicos.
El administrador tiene la facultad de darlo de alta como darlo de baja a ambos tipos de usuario.

-    Definición de los 3 roles de usuario (Médico, Administrador, paciente), y acceso a paneles distintos.
-    Diseño del formulario de registro de recetas (para Médicos). Incluye:
En el encabezado: poder poner logo (opción de poder subir imagen del logo en el margen izquierdo y ampliar formato) y/o tipeo de datos que quede predefinido como formato.
En el cuerpo:
Diagnóstico: campo de diagnóstico que es desplegable por código o por texto, se puede tipear palabra y trae todas las opciones que incluye esa palabra (algo que haga fácil la búsqueda ya que son muchos diagnósticos)
Un campo adicional por si el médico quiere aclarar algo del diagnóstico con sus palabras.
Medicamentos: son cantidad de filas a disponer desde el back office. Descripción de una fila=>
campo de descripción de Monodroga/s campo de troquel y campo de nombre medicamento y al lado campo numérico para poner cantidad.
El método de búsqueda del medicamento puede ser por código de droga, o una palabra o una parte de la palabra de la droga y trae las opciones de droga y una vez seleccionada, acota el universo para traer los medicamentos que se componen de esa droga para que seleccione el médico también el nombre comercial. Ó Por troquel y trae automáticamente la droga y el nombre de medicamento ó una palabra o parte de la palabra en el nombre de medicamento y una vez seleccionada, aparece la droga y el troquel automáticamente (el código de droga no debe ser visible en la receta ya que es código interno en el sistema, el resto sí)
Un espacio para la firma
Fecha del dia de emisión . Se ve como un calendario, se puede seleccionar la fecha en curso o posterior.

Tema firma digital => dejar preparado el sistema para poder incorporar bloque de firma digital (pendiente de averiguar)
En el pie: como opcional poder poner domicilio)

-    Que el médico pueda visualizar todas las recetas vigentes y no vigentes de los distintos médicos que atendieron a ese paciente aplicando filtro de fechas. Si la receta es vigente aparezca en negrita y las no vigentes gris para más rápida visualización. Se podrá hacer clic sobre una receta para ver su contenido pero no podrá modificarla.


2)
-    Modelamiento de base de datos, y posibilidad de cargar desde CSV información de Médicos, Diagnósticos, Medicamentos, y Pacientes y tablas opcionales que el administrador le asignará el nombre que quiera a cada una de ellas (cada CSV debe tener un formato específico, que será posible descargar desde el panel de administración a modo de guía. Y se tiene que programar la marca de cada paciente de esa tabla optativa que está sin receta vigente. Tiene que aparecer la fecha de vencimiento de la última receta que se emitió para este paciente o una “X” si no hay ninguna en los registros)
-    Registro de recetas.
Los médicos podrán registrar recetas. ÉStas se guardarán y tendrán un botón Confirmar. Si el médico no confirma una receta, ésta quedará en modo borrador.
Una vez que se le dio la opción “Imprimir” esa receta ya no la puede editar. No la puede modificar.
-    Las recetas Confirmadas tendrán una opción de Imprimir con posibilidad de imprimir desde el dispositivo donde se esté generando la receta.
3)
-    Se evaluará según los warning presentados. Quedan los warnings del slide 7. El administrador puede construir la cantidad que requiera de warnings de esas combinaciones.

Una aclaración: Básicamente será la combinación de 2 o más campos de las tablas que existen dentro de la solución y el texto del warning lo elige el administrador. Y ese warning tendría que aparecer cuando se cumple esa regla en la receta generada. Este warning en caso de activarse es sólo para visualización del médico.
Y no podrá imprimir hasta que en un campo de texto justifique por qué ignoró el warning. Ese texto también es de visualización para la reporteria y no para la receta que se va a quedar el paciente. Si el médico generador de la receta respeta ese warning y corrige su receta, ese warning debe desaparecer de los registros para la reporteria.


4)
-    Reporteria: Pendiente de definición pero van a ser varios con la posibilidad de exportar en csv o Excel..

Category IT & Programming
Subcategory Web development
What is the scope of the project? Medium-sized change
Is this a project or a position? Project
I currently have I have an idea
Required availability As needed
API Integrations Other (Other APIs)
Roles needed Developer

Delivery term: Not specified

Skills needed

Other projects posted by E. C.