SISTEMAS

NOMBRE:CURSO: SEGUNDO DE BACHILLERATO TCNICO LICENCIADO:EMILIO GUAMAN AO LECTIVO2013 - 2014

TEMA:Diseo, e implementacin de un sistema para la automatizacin de las Historias Clnicas del Subcentro.INTRODUCCINEn los ltimos aos hemos asistido a cambios radicales en el uso de las tecnologas de la informacin y la comunicacin (TIC).Como es lgico la medicina no ha escapado a esta revolucin tecnolgica.Estamos asistiendo a un cambio trascendental en la forma de generar, consultar y comunicar la informacin clnica.Ya es posible pensar que han desaparecido muchas de las barreras que impedan una comunicacin a distancia, simultnea y en cualquier momento con otros profesionales asistenciales.Adems las TIC suponen importantes avances a nivel de acceso y a nivel de incorporar herramientas de soporte a la decisin.En este sentido la Historia Clnica Automatizada es una herramienta que favorece la calidad, la seguridad y la continuidad asistencial.Permite adems tener un control sobre las acciones realizadas.Sin embargo la complejidad del trabajo mdico, la heterogeneidad de los usuarios y profesionales, y el gran nmero de sistemas de informacin implicados hacen que se trate de una tarea difcil.Para conseguir su implementacin en un centro sanitario es necesario un activo compromiso de todos los usuarios implicados.El liderazgo de la Direccin tambin es clave para su implementacin.La implementacin de la Historia Clnica Automatizada es una decisin estratgica que pretende mejorar la efectividad y la eficiencia.Tambin obedece a una realidad marcada por las expectativas de nuestros pacientes y por la aparicin de nuevas tcnicas mdicas.Poder controlar los costos, optimizar los procesos y reasignar los recursos son retos permanentes de cualquier Direccin.Hospitales privados muestran importantes avances en la incorporacin de tecnologas de la informacin para conseguir estos objetivos y la Historia Clnica Automatizada es uno de ellos.La implantacin de un proyecto de estas caractersticas tiene muchas implicaciones relacionadas con la prevencin, el diagnstico, el tratamiento y la monitorizacin de pacientes, as como con la planificacin y el control de la gestin.Es aqu donde pueden contribuir sistemas como la Historia Clnica Automatizada.Para ello se necesita una infraestructura tecnolgica, la interoperabilidad para intercambiar datos y establecer medidas de seguridad de proteccin de la informacin. Otro paso no menos importante lo constituye la integracin con otros sistemas existentes para permitir el intercambio de informacin clnica.Este trabajo quiere constituir un aporte al proceso de implementacin de una Historia Clnica Automatizada en un centro de salud. Se abordan las distintas reas en las que debe ser aplicado: prescripcin Automatizada y sistemas de gestin tcnico-administrativos, entre otros. Pretende contribuir a clarificar conceptos, precisar cmo implementar estas aplicaciones, mostrar los factores clave, identificar beneficios y alertas sobre riesgos y dificultades que sirvan de orientacin a otros proyectos de estas caractersticas. Mi experiencia quiere ser una fuente relevante de aprendizaje para futuros proyectos de implementacin especialmente por la baja difusin de experiencias y la escasez de estudios evaluativos realizados.La introduccin empieza analizando el contexto histrico, legal y sanitario de la Historia Clnica. Contina con una presentacin de la Historia Clnica Automatizada ms especfica y se abordan aspectos como los Servicios de Admisin y Documentacin Clnica, la seguridad de la informacin clnica, los sistemas de informacin, las tecnologas de la informacin y comunicacin y la interoperabilidad.El captulo II presenta la hiptesis antes de describir la metodologa utilizada.En Material y Mtodos se describe el modelo de gestin de proyecto con todos sus procesos de definicin del proyecto, planificacin, ejecucin, seguimiento y control y cierre. Se tratan los instrumentos especficos: Comisin de Historia Clnica y Comit Tcnico. Se abordan las distintas reas en las que debe ser aplicado: pruebas diagnsticas, peticiones clnicas, informes de alta, documentacin clnica interna, prescripcin Automatizada, unidad de digitalizacin, informes de monitorizacin y la propia Historia Clnica Automatizada. Se revisan aspectos generales sobre seguridad e investigacin y docencia.El captulo V presenta los resultados basados en cada una de las reas en las que ha sido aplicada: pruebas diagnsticas, peticiones clnicas, informes de alta, documentacin clnica, prescripcin Automatizada, histrico y documentacin clnica externa, informes de monitorizacin, con especial nfasis en los dos aos de experiencia de uso de la Historia Clnica Automatizada. Se describen versiones y la encuesta de valoracin realizada.En el captulo VI se discute la hiptesis planteada y se presentan algunas implicaciones para futuros proyectos.El captulo VII muestra las conclusiones.Al final se presenta un glosario de trminos, en muchas ocasiones desconocidos cuando se Inicia un proyecto de implementacin de Historia Clnica AutomatizadaOBJETIVOSOBJETIVO GENERAL Analizar, disear, desarrollar e implementar la automatizacin de las Historias Clnicas en un centro de Salud.OBJETIVO ESPECFICO Presentar la informacin clnica estructurada y actualizada de forma que permita un crecimiento escalable y modulable en el futuro. Gestionar la informacin de salud y realizar la explotacin de los resultados clnicos, econmicos y administrativos a travs de informes de monitorizacin que permitan el soporte en la toma de decisiones. Permitir un acceso instantneo, en todo momento y desde cualquier punto por varios usuarios simultneamente. Poder disponer de la informacin clnica independientemente de donde y cuando se haya producido. Realizar sistemas de control de acceso, perfil de usuario y trazabilidad que garanticen la seguridad y confidencialidad de la informacin clnica. Reducir los espacios fsicos y los recursos necesarios para la gestin de la documentacin clnica. Garantizar la conservacin de la informacin clnica en un formato adecuado.

ETAPAS DEL CICLO DE VIDA

ANLISISUn modelo de Historia Clnica debe centrarse en la atencin sanitaria y sus objetivos deben ser la mejora de la calidad asistencial y la continuidad asistencial.En la fase de anlisis se analizan los flujos y procesos organizativos, las aplicaciones informticas implicadas y se identifican los requerimientos funcionales y tcnicos del usuario. Tal como se ha comentado, realizar un proceso de anlisis por una persona aficionado supone prescindir de procesos clave que deberan estar presentes, implicando muchos recursos para un pequeo beneficio.Para planificar y disear una Historia Clnica Automatizada se precisa conocer con detalle las necesidades de informacin de los usuarios finales. Para ello se identifica a los usuarios, se conoce la informacin que necesitan y como acceden a la informacin necesaria. Se recogen los requerimientos funcionales evitando que se vayan aportando a lo largo del proyecto.En esta fase se dispone de un Plan de Trabajo que implica la distribucin de tareas, estableciendo un cronograma y la definicin de los responsables de cada una de ellas. Adems se valoran los posibles riesgos y cambios que se puedan producir durante la ejecucin del proyecto.Es preciso escribir lo que se hace y hacer lo que se escribe para demostrar que se realizan los requisitos establecidos.Por todo lo anteriormente comentado en la fase de anlisis se dispone de documentacin desarrollada a partir de los requerimientos iniciales donde consta el motivo del proyecto, los objetivos, el alcance, los lmites, los requerimientos funcionales y tcnicos, la duracin estimada, los recursos, las restricciones y los riesgos. Tambin se dispone de documentacin que puede considerarse esencial. En definitiva se trata de describir el aplicativo final y realizar un anlisis para el mismo.Adems se dispone de un Plan Tcnico orientado a analizar y definir las necesidades de la arquitectura final. El Comit Tcnico debe realizar un anlisis de viabilidad de la solucin propuesta estudiando toda la documentacin y debe proporcionar la informacin adecuada a la Comisin de Historia Clnica para una toma de decisin final.

DISEOEn la fase de diseo se realiza un anlisis funcional y de diseo de la solucin de acuerdo a lo definido en la fase de anlisis. Se especifican los posibles usos del aplicativo y el diseo de su arquitectura. Es muy importante que la solucin se plantee con una tecnologa actual y basada en estndares. Deber: Ser una solucin de fcil aprendizaje para los programadores, con posibilidad de crecimiento, de respuesta rpida, fiable, flexible y con posibilidad de integracin con otras aplicaciones, entre otros. Un ejemplo es la tecnologa multicapas utilizada en nuestro caso, basada en tecnologa Web. Tener en cuenta aspectos de seguridad, disponer de distintos niveles de acceso como de lectura y escritura, asegurar la trazabilidad, etc... y a la vez permitir el intercambio de informacin entre usuarios y/o centros, es decir, mantener el eterno equilibrio entre disponibilidad y seguridad. Valorar aspectos de integracin, es decir, basarse en estndares para permitir la comunicacin con otras aplicaciones. Tener un rendimiento adecuado a las necesidades y al nmero de usuarios que lo van a utilizar, factor clave para evitar un rechazo del usuario final.

DESARROLLOEn la fase de desarrollo se construye el aplicativo. De acuerdo a lo comentado en la fase de diseo se trata de una solucin abierta que permite Integrar las propuestas de los profesionales y programada con una tecnologa vigente, ya que lo que hoy es actual en unos meses ya no lo es.En esta fase se debe disponer de un potente equipo tcnico. Un motivo de fracaso o de desarrollo incompleto de los requerimientos establecidos puede ser no contar con las personas adecuadas. Otras veces es debido a una falta de dedicacin exclusiva del personal del proyecto.En nuestro caso la decisin fue desarrollar nuestros propios aplicativos. Sin embargo no es posible una solucin para todo, por lo que se definieron subproyectos de una gran especificidad. Se consider que el ncleo de los procesos asistenciales, es decir admisin, citacin y la base de la Historia Clnica Automatizada serian de desarrollo propio.

PRUEBAS Y TRANSICINEn la fase de pruebas y transicin se dispone de una primera versin, versin beta del aplicativo, que se prueba para corregir los defectos. Adems se forma al usuario, siempre bajo la supervisin del Comit Tcnico y se proporciona el mantenimiento del software.

IMPLEMENTACINEn la fase de implantacin se instala la aplicacin en la organizacin, adecundola a las caractersticas funcionales y operativas. Implica realizar las integraciones necesarias y la validacin final.Es una fase crtica por lo que deben tenerse en cuenta todos los aspectos: que se va a hacer, en que momento, quien lo va a hacer y de qu manera.Son claves elementos como una correcta construccin de los aplicativos, disponer de una infraestructura adecuada, realizar una correcta migracin y las integraciones necesarias, tener en cuenta los circuitos, gestionar adecuadamente los roles y los usuarios, disponer de un soporte funcional y tcnico especialmente al inicio, tener planes de contingencia y haber tenido en cuenta la posterior explotacin.El paso a produccin es una de las fases ms importantes en la gestin de un proyecto de estas caractersticas. Se deben evitar sorpresas como la falta de infraestructuras, la formacin o documentacin del equipo tcnico, la falta de adecuacin de la solucin a los requerimientos, etc... por lo que es preciso integrar a los responsables de programacin de servicio en todos los procesos. Los responsables de programacin documentan toda la informacin antes de ponerla en produccin, documento que debe conocer la direccin del proyecto y que se debe ir actualizando progresivamente.Es requisito indispensable el liderazgo que debe ser de la alta Direccin y nunca dejar el proyecto en manos de los informticos, a menudo realizar cambios organizativos profundos y obtener una aplicacin adecuada con la participacin de los profesionales. Aun as hay que estar preparados para las resistencias que se pueden minimizar con una correcta formacin y definicin de los roles implicados y una adecuada financiacin.Las resistencias pueden proceder de la generacin de nuevos circuitos, de la dificultad de usabilidad de la aplicacin, de experiencias negativas previas, del escaso soporte en el punto de atencin al paciente o del elevado coste de aplicaciones inadecuadas (Adams et aL, 2003).Es necesario conseguir vencer la resistencia al cambio durante esta fase. Lo habitual es un rechazo a lo desconocido que puede venir influenciado por aspectos personales, estructurales, culturales, etc....Para vencer las resistencias el diseo de la aplicacin se adapta a las necesidades y circuitos de trabajo de los usuarios finales, se prueba siempre la aplicacin antes de implantarla, se forma a los usuarios y se comunica peridicamente sobre el estado y objetivos del proyecto. Tambin se intenta que se entienda como un proyecto global de la organizacin, se muestran las ventajas, se va implantando progresivamente para permitir la adaptacin de los usuarios y se contemplan todos los requisitos mnimos, implicando a todos los profesionales. El objetivo es obtener una solucin final agradable, gil e intuitiva.

ACEPTACINTal como se ha comentado la reduccin de nuevos circuitos, la usabilidad del aplicativo, las experiencias positivas previas, el soporte inicial, la formacin, las infraestructuras adecuadas, la adaptacin a los requerimientos mnimos iniciales, la comunicacin, la adaptacin progresiva, un aplicativo adecuado, la reduccin de las incidencias y la implicacin de los profesionales, puede facilitar la aceptacin del nuevo aplicativo.Algunos de estos aspectos pueden depender de cada organizacin como los personales, los estructurales, los culturales, etc....Si el proyecto contempla todos estos aspectos por lo general se consigue la aceptacin por el usuario final.La fase de aceptacin es necesaria y se formula, a poder ser escrito para asegurar la implicacin del usuario final y evitar que el proyecto se alargue con la aparicin de nuevos requerimientos. En todo caso se trasladan estos nuevos requerimientos a una nueva fase.

MANTENIMIENTO Y SOPORTELa fase de mantenimiento y soporte es la fase en la que se realiza el mantenimiento que permite la continuidad de la aplicacin en la organizacin. Implica la resolucin de incidencias y la generacin de mejoras para una evolucin adecuada del aplicativo.

El soporte consiste en realizar actividades de ayuda funcional y tcnica durante la puesta en marcha de la aplicacin.

Se dispone de un Plan de Mantenimiento que permite la resolucin de los errores detectados, la actualizacin de versiones, con la definicin del periodo de implantacin de estas versiones y un servicio orientado al soporte que se basa en la tipologa de la incidencia detectada con capacidad de respuesta. Es necesario especialmente al initio disponer de una atencin continuada, estableciendo un tiempo de respuesta inmediata y un tiempo de resolucin mximo segn el tipo de incidencia. Las vas para resolverlas podrn ser desde una atencin in-situ a una atencin telefnica o e-mail.

SEGUIMIENTO Y CONTROLLas actividades de seguimiento y control se realizan a lo largo de todos los procesos de anlisis, diseo, desarrollo, pruebas, implantacin, aceptacin, mantenimiento y soporte. Permiten verificar el grado de avance del proyecto segn el cronograma establecido evaluando desde la asignacin de tareas hasta la gestin de las incidencias, los puntos crticos, etc.... que se van produciendo.

Se realizan actividades retrospectivas, como la revisin del presupuesto, auditorias concretas, la revisin de los objetivos iniciales, revisin de la documentacin... en tiempo real, como valorar las incidencias detectadas, o prospectivas, como consultas a grupos de expertos, visitas a otros centros o tcnicas de grupo especficas.Se debe considerar que una evaluacin peridica es una oportunidad de mejora de los procesos para permitir una mejor eficacia y conocer las desviaciones. Para ello se mide, supervisa y analiza el avance del proyecto. Lo ideal es detectarlas con la mxima anticipacin. Esto implica el seguimiento y el control de las actividades, los recursos humanos y los materiales.En nuestro caso la herramienta utilizada van hacer Visual Basic 6.00 y Access. Se trata de una herramienta que permite gestionar varios proyectos a la vez, pudiendo realizar un seguimiento de las distintas incidencias y su estado de resolucin.

Con el proceso de seguimiento y control se cierra el proceso bsico de planificar, hacer, chequear y actuar.

CIERREUna vez finalizados los procesos de definicin del proyecto, planificacin, ejecucin, seguimiento y control, se llega al proceso de cierre del proyecto.

Los procesos de cierre se orientan a terminar todas las acciones para poder entregar el resultado final. Implica el registro de toda la Documentacin.

El xito de un proyecto se puede medir por la no dependencia de individuos, porque la incorporacin del nuevo personal es rpida, por la existencia de documentacin que se va actualizando peridicamente, por la aceptacin de los usuarios, por la baja resolucin de incidencias o errores, por la mejora en la comunicacin entre usuarios y aplicativos, por la mejora en la satisfaccin del usuario, porque las nuevas mejoras se perciben rpidamente, porque se tiende a trabajar de forma ms generalizada y porque existe un control que impide la aparicin de sorpresas de ltima hora. En el proceso de cierre se realiza un acta de recepcin, una encuesta de satisfaccin y un informe de cierre.Cualquiera de los procesos mencionados de definicin del proyecto, planificacin, ejecucin, seguimiento y control, y cierre puede contener diferentes subprocesos, como (Carnicero et al., 2007): Integracin: los distintos elementos del proyecto se integran adecuadamente. Alcance: se incluye todo el trabajo requerido, es decir, supone tener claro cules son los objetivos a conseguir. Tiempo: puntualidad en la realizacin del proyecto. Costes: costes y presupuesto estimado. Calidad: el proyecto rene los requerimientos para los que fue diseado. Recursos humanos: organizacin y Direccin del equipo Comunicacin: procesos que aseguran una adecuada comunicacin entre los implicados para una correcta toma de decisiones. Riesgos: riesgos de un proyecto y gestin de las distintas situaciones, Adquisiciones: compra de productos o servicios.

DISEO DE BASE DE DATOS

Modelado Entidad-RelacinEl modelo de datos entidad-relacin est basado en una percepcin del mundo real que consta de una coleccin de objetos bsicos, llamados entidades, y de relaciones entre esos objetos.EntidadRepresenta una cosa u "objeto" del mundo real con existencia independiente, es decir, se diferencia unvocamente de cualquier otro objeto o cosa, incluso siendo del mismo tipo, o una misma entidad.Una entidad puede ser un objeto con existencia fsica como: una persona, un animal, una casa, etc. (entidad concreta); o un objeto con existencia conceptual como: un puesto de trabajo, una asignatura de clases, un nombre, etc. (entidad abstracta).Una entidad est descrita y se representa por sus caractersticas o atributos. Por ejemplo, la entidad Persona puede llevar consigo las caractersticas: Nombre, Apellido, Gnero, Estatura, Peso, Fecha de nacimiento, etc.AtributosLos atributos son las caractersticas que definen o identifican a una entidad. Estas pueden ser muchas, y el diseador solo utiliza o implementa las que considere ms relevantes. Los atributos son las propiedades que describen a cada entidad en un conjunto de entidades.En un conjunto de entidades, cada entidad tiene valores especficos asignados para cada uno de sus atributos, de esta forma, es posible su identificacin unvoca.Cada una de las entidades pertenecientes a este conjunto se diferencia de las dems por el valor de sus atributos. Ntese que dos o ms entidades diferentes pueden tener los mismos valores para algunos de sus atributos, pero nunca para todos.En particular, los atributos identificativos son aquellos que permiten diferenciar a una instancia de la entidad de otra distinta. Por ejemplo, el atributo identificativo que distingue a un alumno de otro es su nmero de id.Para cada atributo, existe un dominio del mismo, este hace referencia al tipo de datos que ser almacenado o a restricciones en los valores que el atributo puede tomar (cadenas de caracteres, nmeros, solo dos letras, solo nmeros mayores que cero, solo nmeros enteros...).Cuando algn atributo correspondiente a una entidad no tiene un valor determinado, recibe el valor nulo, bien sea porque no se conoce, porque no existe o porque no se sabe nada al respecto del mismo.RelacinDescribe cierta dependencia entre entidades o permite la asociacin de las mismas.Una relacin tiene sentido al expresar las entidades que relaciona.Conjunto de relacionesConsiste en una coleccin, o conjunto, de relaciones de la misma naturaleza.Se llama grado del conjunto de relaciones a la cantidad de conjuntos de entidades participantes en la relacin.RestriccionesSon reglas que deben mantener los datos almacenados en la base de datos.Restricciones de participacinDado un conjunto de relaciones R en el cual participa un conjunto de entidades A, dicha participacin puede ser de dos tipos:Total: Cuando cada entidad en A participa en al menos una relacin de R.Parcial: Cuando al menos una entidad en A NO participa en alguna relacin de R.Correspondencia de cardinalidadesDado un conjunto de relaciones en el que participan dos o ms conjuntos de entidades, la correspondencia de cardinalidad indica el nmero de entidades con las que puede estar relacionada una entidad dada.Dado un conjunto de relaciones binarias y los conjuntos de entidades A y B, la correspondencia de cardinalidades puede ser:Uno a Uno: Una entidad de A se relaciona nicamente con una entidad en B y viceversa.Uno a varios: Una entidad en A se relaciona con cero o muchas entidades en B. Pero una entidad en B se relaciona con una nica entidad en A.Varios a Uno: Una entidad en A se relaciona exclusivamente con una entidad en B. Pero una entidad en B se puede relacionar con 0 o muchas entidades en AVarios a Varios: Una entidad en A se puede relacionar con 0 o muchas entidades en B y viceversa.ClavesEs un subconjunto del conjunto de atributos comunes en una coleccin de entidades, que permite identificar unvocamente cada una de las entidades pertenecientes a dicha coleccin. Asimismo, permiten distinguir entre s las relaciones de un conjunto de relaciones.Dentro de los conjuntos de entidades existen los siguientes tipos de claves:Superclave: Es un subconjunto de atributos que permite distinguir unvocamente cada una de las entidades de un conjunto de entidades. Si se aade un atributo al anterior subconjunto, el resultado seguir siendo una superclave.Clave candidata: Dada una superclave, si sta deja de serlo quitando nicamente uno de los atributos que la componen, entonces sta es una clave candidata.Clave primaria: Es una clave candidata, elegida por el diseador de la base de datos, para identificar unvocamente las entidades en un conjunto de entidades.Los valores de los atributos de una clave, no pueden ser todos iguales para dos o ms instancias.Para poder distinguir unvocamente las relaciones en un conjunto de relaciones R, se deben considerar dos casos:R NO tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de las claves primarias de todos los conjuntos de entidades participantes.R tiene atributos asociados: En este caso, se usa como clave primaria de R la unin de los atributos asociados y las claves primarias de todos los conjuntos de entidades participantes.Si el conjunto de relaciones, R, sobre las que se pretende determinar la clave primaria est compuesto de relaciones binarias, con los conjuntos de entidades participantes A y B, se consideran los siguientes casos, segn sus cardinalidades:R es de muchos a uno de A a B entonces slo se toma la clave primaria de A, como clave primaria de R.R es de uno a muchos de A a B entonces se toma slo la clave primaria de B, como clave primaria de R.R es de uno a uno de A a B entonces se toma cualquiera de las dos claves primarias, como clave primaria de R.R es de muchos a muchos de A a B entonces se toma la unin de los atributos que conforman las claves primarias de A y de B, como clave primaria de R.

TABLA PACIENTE