UNIVERSIDAD DE GUAYAQUILrepositorio.ug.edu.ec/bitstream/redug/17664/1/UG-FCMF-B...Johana Trejo A,...
179
UNIVERSIDAD DE GUAYAQUIL FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES “DESARROLLO DEL FORMULARIO 033-ODONTOLOGÍA DEL MINISTERIO DE SALUD PÚBLICA APLICANDO ARQUETIPOS BASADOS EN LA NORMA ISO 13606 PARA LA INTEROPERABILIDAD DE LOS SISTEMAS HOSPITALARIOS” PROYECTO DE TITULACIÓN Previa a la obtención del Título de: INGENIERO EN SISTEMAS COMPUTACIONALES AUTORES: ROBERTO CARLOS GONZÁLEZ LEÓN JORGE ANDRÉS ROMERO FRANCO TUTOR: ING. LEILI LOPEZDOMÍNGUEZ RIVAS GUAYAQUIL – ECUADOR 2016
Transcript of UNIVERSIDAD DE GUAYAQUILrepositorio.ug.edu.ec/bitstream/redug/17664/1/UG-FCMF-B...Johana Trejo A,...
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS
COMPUTACIONALES
“DESARROLLO DEL FORMULARIO 033-ODONTOLOGÍA DEL MINISTERIO DE SALUD PÚBLICA APLICANDO ARQUETIPOS BASADOS EN LA NORMA ISO
13606 PARA LA INTEROPERABILIDAD DE LOS SISTEMAS HOSPITALARIOS”
PROYECTO DE TITULACIÓN
Previa a la obtención del Título de:
INGENIERO EN SISTEMAS COMPUTACIONALES
AUTORES: ROBERTO CARLOS GONZÁLEZ LEÓN
JORGE ANDRÉS ROMERO FRANCO
TUTOR: ING. LEILI LOPEZDOMÍNGUEZ RIVAS
GUAYAQUIL – ECUADOR
2016
II
REPOSITORIO NACIONAL EN CIENCIAS Y TECNOLOGÍA
FICHA DE REGISTRO DE TESIS “Desarrollo del formulario 033-Odontología del Ministerio de Salud Pública aplicando arquetipos basados en la norma ISO 13606 para la interoperabilidad de los sistemas hospitalarios” REVISORES: Ing. Johana Trejo A, Mgs REVISORES: Ing. Mario Sánchez, Mae INSTITUCIÓN: UNIVERSIDAD DE GUAYAQUIL
FACULTAD: CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA: INGENIERÍA EN SISTEMAS COMPUTACIONALES
FECHA DE PUBLICACIÓN: N° DE PÁGS.: 157
ÁREA TEMÁTICA: Informática Tecnológica
PALABRAS CLAVES: Formulario 033-Odontología, Desarrollo, Arquetipos, ISO 13606, Interoperabilidad. RESUMEN: En la actualidad las personas que ingresan al sistema de salud ya sea
público o privado deben ingresar los datos del paciente en un formulario de
odontología del MSP, la historia clínica debe ser evaluada por el galeno de turno, a
falta de un sistema médico que permita la interoperabilidad entre hospitales surge la
problemática que se deba recopilar los datos en las diferentes entidades de salud por
el mismo cuadro médico ya que los datos no tienen un estándar y no pueden
compartirse por que están elaborados en diferentes sistemas ocasionando que no se
distribuyan correctamente los recursos, se incremente las quejas de los pacientes en
el MSP y en algunos casos la pérdida de vidas humanas por falta de gestión de
calidad. Por lo cual se tiene la necesidad de crear o implementar arquetipos basados
en la norma ISO 13606 para desarrollar un sistema que permita la interoperabilidad
de los diferentes sistemas de las entidades de salud a nivel nacional.
N° DE REGISTRO: N° DE CLASIFICACIÓN: Nº
DIRECCIÓN URL: ADJUNTO PDF SI NO
CONTACTO CON AUTORES: Roberto Carlos González León
Jorge Andrés Romero Franco
TELEFONO:
0996490587
0982296717
EMAIL:
CONTACTO DE LA INSTITUCIÓN:
Nombre: Ing. Roberto Crespo.
Director de CISC.
TELÉFONO: 2307729
E-Mail: [email protected]
X
III
APROBACIÓN DEL TUTOR
En mi calidad de Tutor del trabajo de titulación, “Desarrollo del formulario 033-
odontología del Ministerio de Salud Pública aplicando arquetipos basados en la
norma ISO 13606 para la interoperabilidad de los sistemas hospitalarios”
elaborado por el Sr. Roberto Carlos González León y el Sr. Jorge Andrés Romero
Franco, alumnos no titulados de la Carrera de Ingeniería en Sistemas
Computacionales, Facultad de Ciencias Matemáticas y Físicas de la Universidad
de Guayaquil, previo a la obtención del Título de Ingeniero en Sistemas, me
permito declarar que luego de haber orientado, estudiado y revisado, la Apruebo
en todas sus partes.
Atentamente
TUTOR
Ing. Leili Lopezdomínguez Rivas
IV
DEDICATORIA
Dedico este trabajo de titulación a mis hijos
Roberto Carlos y Lucas Abraham, quienes son
los pilares de motivación para poder lograr este
objetivo; así también, a mis padres que siempre
me guiaron por el camino de la responsabilidad
y brindaron el tiempo necesario para ver a su
hijo próspero; y en especial, a Dios quien es el
motor para salir adelante de todos los
problemas.
Roberto Carlos González
A Dios por darme salud, sabiduría y haberme
permitido llegar hasta este momento tan
importante de mi formación profesional. A mis
padres por el apoyo y esfuerzo que han
dedicado, siendo mis guías para lograr mis
objetivos propuestos. A los docentes que han
inculcado sus conocimientos para mi formación
académica.
Jorge Romero Franco
V
AGRADECIMIENTO
Quiero dar gracias a Dios en primer
lugar por todas las bendiciones
recibidas para concluir con éxito este
proyecto de titulación, también quiero
agradecer a mis compañeros,
docentes tutores, revisores, amigos y
mi familia ya que de una u otra
manera colaboraron para que este
sueño se realice. Espero en un futuro
no muy lejano poder contribuir con
mis conocimientos adquiridos para el
desarrollo de nuestro país y la
comunidad.
Roberto Carlos González León
Este proyecto es resultado de la
ayuda de Dios por brindarnos la vida
y fortaleza necesaria para cumplir una
de nuestras metas.
A nuestros padres y docentes por sus
buenos consejos.
Jorge Andrés Romero Franco
VI
TRIBUNAL PROYECTO DE TITULACIÓN
Ing. Eduardo Santos Baquerizo, MSc. DECANO DE LA FACULTAD DE
CIENCIAS MATEMÁTICAS Y FÍSICAS
Ing. Roberto Crespo Mendoza Mgs. DIRECTOR
CISC
Ing. Mario Sánchez Delgado, Mae. PROFESOR REVISOR DEL
ÁREA - TRIBUNAL
Ing. Johana Trejo M.Sc PROFESOR REVISOR DEL
ÁREA - TRIBUNAL
Ing. Leili Lopezdomínguez Rivas, Mgs
PROFESOR TUTOR DEL PROYECTO DE TITULACION
Ab. Juan Chávez A
Secretario
VII
DECLARACIÓN EXPRESA
“La responsabilidad del contenido de este
Proyecto de Titulación, nos corresponden
exclusivamente; y el patrimonio intelectual de la
misma a la UNIVERSIDAD DE GUAYAQUIL”
Roberto Carlos González León
Jorge Andrés Romero Franco
VIII
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
DESARROLLO DEL FORMULARIO 033-ODONTOLOGÍA DEL MINISTERIO
DE SALUD PÚBLICA APLICANDO ARQUETIPOS BASADOS EN LA NORMA ISO 13606 PARA LA INTEROPERABILIDAD DE LOS SISTEMAS
HOSPITALARIOS.
Proyecto de Titulación que se presenta como requisito para optar por el título de
INGENIERO EN SISTEMAS COMPUTACIONALES
Autor: Roberto Carlos González León
C.I. 0915774665
Autor: Jorge Andrés Romero Franco
C.I. 0925555211 Tutor: Ing. Leili Lopezdomínguez Rivas
Guayaquil, septiembre del 2016
IX
CERTIFICADO DE ACEPTACIÓN DEL TUTOR En mi calidad de Tutor de proyecto de titulación, nombrado por el Consejo
Directivo de la Facultad de Ciencias Matemáticas y Físicas de la Universidad de
Guayaquil.
CERTIFICO: Que he analizado el Proyecto de Titulación presentado por los
estudiantes Roberto Carlos González León y Jorge Andrés Romero Franco, como
requisito previo para optar por el título de Ingeniero en Sistemas Computacionales
cuyo título es: “Desarrollo del formulario 033-Odontología del Ministerio de Salud
Pública aplicando arquetipos basados en la norma ISO 13606 para la
interoperabilidad de los sistemas hospitalarios”
Considero aprobado el trabajo en su totalidad.
Presentado por:
González León Roberto Carlos C.I.0915774665
Romero Franco Jorge Andrés C.I.0925555211
Tutor: Ing. Leili Lopezdomínguez Rivas
Guayaquil, septiembre del 2016
X
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS
COMPUTACIONALES
AUTORIZACIÓN PARA PUBLICACIÓN DEL PROYECTO DE TITULACIÓN EN FORMATO DIGITAL
1. Identificación del Proyecto de Titulación
Nombre del Alumno: Roberto Carlos González León
Dirección: Cdla. Victoria del Rio Mz. 2952 Villa 18
Teléfono: 3883953-0996490587 E-mail: [email protected] Nombre del Alumno: Jorge Andrés Romero Franco
Dirección: Cdla. Las Orquídeas Mz. 1035 Villa 23
Teléfono: 2890571-0982296717 E-mail: [email protected]
Facultad: Ciencias Matemáticas y Físicas
Carrera: Ingeniería en Sistemas Computacionales
Tituló al que opta: Ingeniero en Sistemas Computacionales
Profesor tutor: Ing. Leili Lopezdomínguez Rivas Título del Proyecto de titulación: “Desarrollo del formulario 033-Odontología
del Ministerio de Salud Pública aplicando arquetipos basados en la norma ISO
13606 para la interoperabilidad de los sistemas hospitalarios” Temas del Proyecto de Titulación: Formulario 033-Odontología, Desarrollo,
Arquetipos, ISO 13606, Interoperabilidad.
XI
2. Autorización de Publicación de Versión Electrónica del Proyecto de Titulación A través de este medio autorizo a la Biblioteca de la Universidad de Guayaquil y a
la Facultad de Ciencias Matemáticas y Físicas a publicar la versión electrónica de
este Proyecto de Titulación.
Publicación electrónica:
Inmediata X Después de 1 año
--------------------------------------------------------------
Roberto Carlos González León.
--------------------------------------------------------------
Jorge Andrés Romero Franco.
3. Forma de Envío: El texto de este Proyecto de Titulación debe ser enviado en formato Word, como
archivo .Doc. O .RTF y .Puf para PC. Las imágenes que la acompañen pueden
ser: .gif, .jpg o .TIFF.
DVDROM X CDROM
XII
ÍNDICE GENERAL FICHA DE REGISTRO DE TESIS ....................................................................... II APROBACIÓN DEL TUTOR ............................................................................... III DEDICATORIA ................................................................................................... IV
AGRADECIMIENTO ............................................................................................V
TRIBUNAL PROYECTO DE TITULACIÓN ......................................................... VI DECLARACIÓN EXPRESA ............................................................................... VII CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES ................ VIII CERTIFICADO DE ACEPTACIÓN DEL TUTOR ................................................. IX
AUTORIZACIÓN PARA PUBLICACIÓN DEL PROYECTO DE TITULACIÓN EN FORMATO DIGITAL ............................................................................................X
ÍNDICE GENERAL ............................................................................................ XII ABREVIATURAS ............................................................................................. XVI SIMBOLOGÍA ................................................................................................. XVII ÍNDICE DE CUADROS .................................................................................. XVIII ÍNDICE DE GRÁFICOS ................................................................................... XIX
RESUMEN ........................................................................................................ XX
INTRODUCCIÓN ............................................................................................ XXII CAPÍTULO I ......................................................................................................... 1
EL PROBLEMA ................................................................................................... 1
Ubicación del problema en un contexto ........................................................... 1
Situación conflicto nudos críticos ..................................................................... 2
Causas y Consecuencias del Problema ........................................................... 3
Delimitación del Problema ............................................................................... 5
Formulación del Problema ............................................................................... 5
Evaluación del Problema ................................................................................. 5
Objetivos .......................................................................................................... 7
Objetivo General .............................................................................................. 7
Objetivos Específicos ....................................................................................... 7
Alcances del problema ..................................................................................... 7
Justificación e Importancia ............................................................................... 8
Metodología del proyecto ................................................................................. 9
CAPÍTULO II ...................................................................................................... 12
MARCO TEÓRICO ............................................................................................ 12
Antecedentes del estudio ............................................................................... 12
XIII
Fundamentación teórica................................................................................. 13
Sistemas de información ........................................................................ 14
Ciclo de vida de un sistema de información (SI). .................................... 15
Actividades de los Sistemas de Información........................................... 16
Beneficios de los sistemas de información. ............................................ 18
Interoperabilidad .................................................................................... 19
Historia Clínica Electrónica..................................................................... 23
Norma INEN- ISO/NTE 13606 ................................................................ 26
Herramientas para el desarrollo del proyecto ......................................... 36
Fundamentación legal .................................................................................... 41
Acuerdos y resoluciones legales del MSP .............................................. 41
No. 0138 Acuerdo del Ministerio De Salud Pública................................. 45
Decreto N.1014 Software Libre en Ecuador ........................................... 46
Ley Orgánica de la Salud ....................................................................... 48
Investigación Científica en Salud, Genética y Sistema de Información en Salud ............................................................................. 48
Ciencia, Tecnología, Innovación y Saberes Ancestrales ........................ 49
Pregunta de Investigación .............................................................................. 50
Variables de la investigación .......................................................................... 50
Variable independiente: .......................................................................... 50
Variable dependiente: ............................................................................ 50
Pregunta científica a contestarse ................................................................... 50
Definiciones conceptuales ............................................................................. 51
CAPÍTULO III ..................................................................................................... 58
PROPUESTA TECNOLÓGICA .......................................................................... 58
Análisis de factibilidad .................................................................................... 58
Factibilidad Operacional ......................................................................... 59
Factibilidad Técnica................................................................................ 60
Factibilidad Legal ................................................................................... 61
Factibilidad Económica .......................................................................... 63
Etapas de la metodología del proyecto .......................................................... 65
Levantar información correspondiente al formulario 033 odontología............. 67
Analizar registros y campos del formulario 033 ...................................... 70
Análisis de requerimientos ..................................................................... 88
Campos del Formulario 033-odontología ................................................ 90
Resultado de la etapa de análisis ........................................................... 93
Diseño .................................................................................................... 95
XIV
Objetivo de la Fase ................................................................................ 95
Resultado de la Fase ............................................................................. 95
Diagrama de Caso de Uso ..................................................................... 95
Diagrama de flujo ................................................................................... 99
Diseño de la interfaz de usuario ........................................................... 104
Entregables del proyecto ............................................................................. 107
Criterios de validación de la propuesta ........................................................ 107
CAPÍTULO IV .................................................................................................. 108
CRITERIOS DE ACEPTACIÓN DEL PRODUCTO .......................................... 108
Conclusiones ............................................................................................... 112
Recomendaciones ....................................................................................... 113
Bibliografía ....................................................................................................... 114
Anexo 1 Formato de entrevista ........................................................................ 116
Anexo 2 Formato de pruebas........................................................................... 117
Anexo 3 Diseños de arquetipos de formulario 033- odontología ...................... 118
Anexo 4 Impresión del formulario..................................................................... 121
Anexo 5 Reuniones evidencias fotográficas ..................................................... 122
Anexo 6 Reuniones de tutorías de formularios básicos del MSP ..................... 123
Anexo 7 Levantamiento de información en consultorio dental. ......................... 124
Anexo 8 Validación de Proyecto de Titulación ................................................. 127
Anexo 9 Manual Técnico y Manual de Usuario ................................................ 128
MANUAL TÉCNICO ......................................................................................... 128
Introducción ......................................................................................... 129
Requerimientos del Hardware .............................................................. 129
Requerimientos del Software ............................................................... 129
Herramientas de desarrollo .................................................................. 130
Instalación de java SDK ....................................................................... 130
Instalación de Eclipse Neón ................................................................. 131
Instalación del Framework Spring ........................................................ 136
Instalación del servidor de aplicaciones Wildfly .................................... 137
Importar proyecto ................................................................................. 139
Instalación PostgreSQL ........................................................................ 140
Importar una base de datos existente en PostgreSQL ......................... 142
MANUAL DE USUARIO ................................................................................... 144
Introducción ......................................................................................... 145
Objetivos .............................................................................................. 145
XV
Ingreso a aplicación ............................................................................. 145
Módulo consulta ................................................................................... 146
XVI
ABREVIATURAS
MSP Ministerio de Salud Pública
HCU Historial Clínico Único
HCE Historial Clínico Electrónico
CIE Código Internacional de Enfermedades
UG Universidad de Guayaquil
RRHH Recursos Humanos
Http Protocolo de transferencia de Hyper Texto
Ing. Ingeniero
CISC Carrera de Ingeniería en Sistemas Computacionales
CC.MM.FF Facultad de Ciencias Matemáticas y Físicas
Mtra. Maestra
MSc. Master
CEN Comité Europeo de Normalización
ISO Organización Internacional de Normalización
MSP Ministerio de salud Pública
UNE Una Norma Española
EIF European Interoperability Framework
SI Sistemas de Información
EHR Electronic Health Record - Historia clínica electrónica
IDE Entorno de Desarrollo Integrado.
SW Software
HD Hardware
XVII
SIMBOLOGÍA
CPO CARIES-PÉRDIDAS Y OBTURADAS
Ceo CARIES- EXTRAIDAS Y OBTURADAS
D Dentición definitiva
d Dentición temporal
XVIII
ÍNDICE DE CUADROS
Pág. Cuadro N. 1 Causas y Consecuencias 3 Cuadro N. 2 Delimitación del problema 5 Cuadro N. 3 Herramientas de desarrollo 60 Cuadro N. 4 Características de hardware 61 Cuadro N. 5 Detalle del costo del proyecto 64 Cuadro N. 6 Antecedentes personales y familiares 73 Cuadro N. 7 Signos vitales 74 Cuadro N. 8 Patologías 75 Cuadro N. 9 Información de las piezas dentales 77 Cuadro N. 10 Niveles de higiene oral simplificada 81 Cuadro N. 11 Datos 86 Cuadro N. 12 Caso de uso de ingresar al sistema 97 Cuadro N. 13 Caso de uso atender turnos 97 Cuadro N. 14 Caso de uso ingreso motivo de consulta 97 Cuadro N. 15 Caso de uso ingreso antecedentes personales 98 Cuadro N. 16 Caso de uso ingreso enfermedad o problema actual 98 Cuadro N. 17 Caso de uso visualización signos vitales 98 Cuadro N. 18 Entregables del proyecto 107 Cuadro N. 19 Arquetipo de odontología 108 Cuadro N. 20 Pruebas de aceptación del software 110
XIX
ÍNDICE DE GRÁFICOS Gráfico N. 1 Modelo general de un sistema 14 Gráfico N. 2 Dimensiones de la interoperabilidad 21 Gráfico N. 3 Modelo Referencial 28 Gráfico N. 4 Detalle de la Estructura del MR 31 Gráfico N. 5 Secciones de encabezamiento de arquetipo 32 Gráfico N. 6 Diagrama de iteraciones de las interfaces 34 Gráfico N. 7 Anverso del formulario 033 de odontología 68 Gráfico N. 8 Reverso de formulario 033 de odontología 69 Gráfico N. 9 Datos Generales 70 Gráfico N. 10 Ciclo de vida de la edad del paciente 71 Gráfico N. 11 Motivo de consulta 72 Gráfico N. 12 Enfermedad o problema actual 72 Gráfico N. 13 Antecedentes personales y familiares 73 Gráfico N. 14 Signos vitales 74 Gráfico N. 15 Examen del Sistema Estomatognático 76 Gráfico N. 16 Odontograma 77 Gráfico N. 17 Indicadores, índices y simbologías 78 Gráfico N. 18 Piezas dentales 79 Gráfico N. 19 Rango de higiene bucal 80 Gráfico N. 20 Higiene oral simplificada 81 Gráfico N. 21 Enfermedad Periodontal 82 Gráfico N. 22 Mal oclusión 83 Gráfico N. 23 Fluorosis 83 Gráfico N. 24 Índice CPO-ceo 84 Gráfico N. 25 Simbología del Odontograma 84 Gráfico N. 26 Planes de diagnóstico, terapéutico y educacional 85 Gráfico N. 27 Diagnóstico 86 Gráfico N. 28 Datos Referenciales 87 Gráfico N. 29 Tratamiento 88 Gráfico N. 30 Campos del Formulario 033-odontología 92 Gráfico N. 31 Diagrama de caso de uso 96 Gráfico N. 32 Diagrama de Flujo de la aplicación 99 Gráfico N. 33 Diagrama de arquitectura 99 Gráfico N. 34 Diagrama de Ishikawa 101 Gráfico N. 35 Diagrama de Procesos 102 Gráfico N. 36 Modelo Entidad Relación 103 Gráfico N. 37 Diseño de la página inicial del sistema 105 Gráfico N. 38 Diseño del área de trabajo 106 Gráfico N. 39 Archivo en formato HTML 118 Gráfico N. 40 Archivo en formato ADL 119 Gráfico N. 41 Diseño de Arquetipo Entry (Enfermedad Periodontal) 119 Gráfico N. 42 Vista de los campos en HTML 120 Gráfico N. 43 Diseño del arquetipo enfermedad perodental con todos los
campos del formulario 033 120
XX
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
Desarrollo del formulario 033-Odontología del Ministerio de Salud Pública
aplicando arquetipos basados en la norma ISO 13606 para la
interoperabilidad de los sistemas hospitalarios
Autores: Roberto Carlos González León
Jorge Andrés Romero Franco Tutor: Leili Lopezdominguez.
RESUMEN En la actualidad las personas que solicitan atención odontológica en el sistema de
salud ya sea público o privado en el Ecuador deben ingresar los datos del paciente
en el formulario 033 de odontología del Ministerio de Salud Pública, debido a la
falta de un sistema de información médico que permita la comunicación entre los
hospitales a nivel nacional, los datos del paciente no están disponibles
ocasionando pérdida de tiempo y recursos, ya que los datos del paciente son
registrados en forma manual y en algunos casos no existe la información
actualizada. El odontograma es una herramienta de gestión donde se registra la
salud bucal del paciente, y si no se distribuyen correctamente los recursos, se
incrementan las quejas de los pacientes en el Ministerio de Salud Pública por falta
de gestión de calidad. Por lo cual, se tiene la necesidad de implementar arquetipos
basados en la norma ISO 13606 para el desarrollo de la Historia Clínica
Electrónica de odontología que permita la interoperabilidad entre los sistemas de
información clínica de las entidades de salud a nivel nacional
XXI
UNIVERSIDAD DE GUAYAQUIL
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
Development of the dental Form 033- through the Public Health Ministry
applying archetypes based on the norm ISO 13606
by an operative system for hospitals.
Autores: Roberto Carlos León
Jorge Andrés Romero Franco Tutor: Leili Lopezdominguez.
ABSTRACT At the present time people who are seeking dental services, both public and
private health system in Ecuador should submit all of their patient information via
dental form 033 through the Ministry of Public Health, due to the lack of a medical
information system that allows communication between hospitals on the national
level, it has continued worsened the problems that many patients´ data and
information was not readily available, which has resulted in a loss of time and
resources. Patient information is currently registered in a paper system (manual),
and in many cases the information is out of date /obsolete. Thus, the creation of
an odontograma which is an information operative system such as this would better
documents and information register about dental health and clinical history of the
patients. It would better distribute resources and curb the increase of complaints
from patients in the Ministry of Public Health due to the lack of qualified
management in dental services. For this reason, it is necessary to put for the
projects- archetypes based on norm ISO 13606 for the development of Dental
Clinical Electronic History that allows an operative system for getting clinical
information between hospitals on the national level.
XXII
INTRODUCCIÓN Todos los sistemas médicos en los hospitales conforme al avance tecnológico
quieren llevar un control, monitoreo y seguimiento de los procesos operativos y
administrativos; para cumplir los objetivos buscan soluciones tecnológicas de
acuerdo a las necesidades o requerimientos médicos de las áreas o
departamentos.
La tendencia de los hospitales es obtener un sistema centralizado donde los
médicos y asistentes tengan las herramientas para acceder a la información
médica y administrativa del paciente.
Los sistemas informáticos médicos sirven para controlar las historias únicas de los
pacientes que son atendidos en las entidades de salud del Ecuador; las cuales
están organizadas y archivadas en forma manual, lo que dificulta la gestión y
provoca pérdida de tiempo en el acceso a las historias clínicas por falta de un
sistema que permita la interoperabilidad entre las instituciones médicas.
Si analizamos los costos referentes a recuperar la salud y prevenir las
enfermedades podemos indicar que es más factible prevenir que curar; por esta
razón, debemos utilizar un sistema estandarizado, el cual nos permita aplicar las
normas ISO 13606 en todas las entidades que prestan servicios de salud en el
Ecuador.
Lograr interoperabilidad semántica entre sistemas médicos de información implica
un trabajo más complejo ya que dos o más sistemas de información; tanto el
emisor como el receptor; deberían tener la capacidad de entender los datos de
forma automática y reutilizar los datos en sus propios sistemas.
El motivo que origina esta situación es la falta de acuerdos legales apegados a la
constitución de la República del Ecuador y regidos o controlados por el Ministerio
de Salud Pública entre instituciones médicas públicas y privadas, ya que cada
institución maneja su información según sus reglas de negocio a fin de
salvaguardar su estabilidad. La competitividad que existe en la actualidad entre
XXIII
las instituciones que prestan el servicio de salud, es otro factor que indirectamente
genera el problema de que no se comparta la información médica levantada por
la parte operativa o administrativa.
El trabajo está compuesto de cuatro capítulos, que se describen a continuación:
. Capítulo I: En este capítulo vamos a describir el planteamiento del problema, la
ubicación del problema en un contexto, situación conflicto nudos críticos, causa y
consecuencias del problema, delimitación del problema, formulación del problema,
evaluación del problema, objetivo general y específicos, los alcances del
problema, la justificación e importancia, y la metodología del proyecto.
Capítulo II: En este capítulo se describe antecedentes del estudio,
fundamentación teórica, fundamentación legal, pregunta científ ica a contestarse,
y definiciones conceptuales.
Capítulo III: En este capítulo vamos a detallar la propuesta tecnológica donde se
encontrarán análisis de factibilidad, (operacional, técnica, legal, económica),
etapas de la metodología del proyecto, entregables del proyecto, criterios de la
propuesta.
Capítulo IV: En el capítulo se detalla por medio de un análisis, qué se obtuvo en
las encuestas o entrevistas realizadas para dar las conclusiones y
recomendaciones.
1
CAPÍTULO I
EL PROBLEMA
PLANTEAMIENTO DEL PROBLEMA
Ubicación del problema en un contexto
La falta de conocimiento de las normas ISO 13606 y la no utilización de las
tecnologías de la información en el ámbito de la salud en el Ecuador afecta
notablemente en los servicios de atención médica y en especial al odontológico
que brindan las instituciones médicas del país, lo cual no permite mejorar los
procesos de control tanto administrativo como operativo. No guardan la
información de los registros de los datos de los pacientes de forma digital, ya que
antes de la llegada de los sistemas de información, los datos clínicos eran
almacenados y registrados manualmente en documentos o archivos físicos, con
altas probabilidades de confundirse con facilidad, causando pérdida de tiempo y
recursos al momento de buscar los registros de la historia clínica única.
El problema con los actuales sistemas de información médica es que no permiten
intercambiar o visualizar información de la historia clínica única de los pacientes
atendidos en diferentes instituciones de salud; razón por la cual, los usuarios
deben levantar o llenar los documentos de ingreso antes de la atención médica,
por falta de un sistema de información que permita la comunicación entre varios
sistemas médicos.
2
Por tal motivo el desarrollo de sistemas que puedan compartir información bajo
una norma o estándar entre diferentes sistemas de las entidades médicas puede
transformar el campo de medicina en nuestro país y convertirse temporalmente en
una solución a la falta de interoperabilidad.
De esta problemática es donde hasta el momento han surgido varias normas y
estándares que sirven de directrices y que permiten diseñar sistemas de
información en salud siendo su objetivo lograr la interoperabilidad, entre las cuales
tenemos, producto de varios años de investigación. En Europa, específicamente
en España, surgió la norma CEN 13606 que ha sido tomada por ISO
convirtiéndose en CEN/ISO 13606, la cual ha tenido varias modificaciones
permitiendo tener como resultado hasta la actualidad cinco partes de la norma. Es
importante recalcar que ésta no es la única norma que posee dichas
características, también una de las más reconocidas en Sudamérica es la norma
HL7, que es un conjunto de estándares o directrices que ayudan o aportan sus
reglas para el intercambio electrónico de información clínica.
Situación conflicto nudos críticos
La ausencia de propuestas que ayuden a mejorar la comunicación entre los
sistemas de información de la salud y que ofrezcan interoperabilidad semántica.
Generalmente este tipo de sistemas de información en salud son realizados a
medida; es decir, bajo los requerimientos y reglas que establezca determinado
usuario y no aplican las normas ISO 13606 regidos por el Ministerio de Salud
Pública del Ecuador.
El problema es que en las clínicas o centros odontológicos las historias clínicas
únicas (HCU) o electrónicas (HCE) no cuentan con el odontograma en forma
digital que permite visualizar el estado o salud bucal de los pacientes; ocasionando
que el médico tenga que levantar la información cada vez que el usuario solicite
atención médica, causando pérdida de tiempo al momento de interpretar el
diagnóstico realizado por otro colega por no cumplir con los estándares.
3
Causas y Consecuencias del Problema Recordemos que el principal problema es la falta de interoperabilidad de los
sistemas hospitalarios. Cuadro N. 1 Causas y Consecuencias
CAUSAS CONSECUENCIA Falta de un sistema de
información en el área
de bioinformática.
Ocasiona en que se vuelvan a realizar nuevas
aperturas de registro odontológicos, los cuales
directamente afectan a personas de recursos
económicos escasos.
Incumplimiento de las
normas ISO 13606.
La inexistencia del odontograma, impide que
puedan diagnosticar el tratamiento de forma más
ágil, de tal manera que se extiende el tiempo de
espera del paciente para culminar el tratamiento.
RRHH con escasos
conocimientos de la
tecnología informática.
En la actualidad en el área de la medicina aún se
siguen llevando registros de los pacientes de
manera física (Papel). Desconocimiento de
resultados obtenidos.
Falta de Asignación
presupuestaria.
No se puede adquirir un sistema y equipos
actualizados, para el Control monitoreo y
seguimiento de la gestión de calidad del servicio.
Elaborado Por: Roberto Carlos González León Fuente: Datos de la investigación
5
Delimitación del Problema Cuadro N. 2 Delimitación del problema
Campo Salud.
Área Bioinformática
Aspecto Aplicación de arquetipos en el formulario 033 de odontología
MSP
Tema Desarrollo del formulario de 033-Odontologia del Ministerio de
Salud Pública y desarrollo aplicando arquetipos basados en la
norma ISO 13606 para la interoperabilidad entre los sistemas
hospitalarios.
Elaborado Por: Roberto Carlos González León Fuente: Datos de la investigación
Formulación del Problema
¿Cómo el Desarrollo del Formulario 033-Odontología del MINISTERIO DE SALUD
PÚBLICA aplicando arquetipos basados en la Norma ISO 13606 podrá lograr la
interoperabilidad de los sistemas hospitalarios en beneficio de los pacientes del
MSP?
Evaluación del Problema
Los aspectos generales de evaluación son:
Delimitado:
El problema se enmarca en la falta de comunicación entre los sistemas médicos
informáticos, específicamente en los que gestionan la historia clínica única del
formulario 033 de odontología del MSP en las diferentes instituciones públicas y
privadas a nivel nacional.
6
Relevante: Debido a inexistencia de la interoperabilidad entre sistemas, los datos clínicos
médicos de los pacientes que fueron atendidos en una institución médica se
encuentran aislados o resguardados dentro de un sistema local de tal manera que
de asistir a otra institución distinta a donde se encuentran sus datos se deberá
crear una nueva historia clínica única, con duplicidad de datos e inconsistencia de
información. Evidente: La falta de propuestas y proyectos que fomenten y solucionen el intercambio
semántico de la HCE de los pacientes en los sistemas médicos actuales, evidencia
que se debe mejorar el servicio de salud en Ecuador.
Concreto: En el proyecto a desarrollar se conocen los principales puntos a tratar y en base
al problema se dará una propuesta precisa para la implementación de los
formularios de odontología en una HCE. Factible: Es factible brindar un desarrollo de un sistema web para solucionar la
interoperabilidad ya que podemos encontrar información relevante acerca de la
norma ISO 13606 y así con la investigación plantear una implementación de una
aplicación que brinde una solución al mismo. Original: El desarrollo de arquetipos es un tema novedoso ya que en Ecuador no existen
diseños de modelos de información de arquetipos basados en los estándares ISO
13606 para los sistemas médicos informáticos y no cuentan con el odontograma
7
Objetivos
Objetivo General
Desarrollar un sistema de información para el Ministerio de Salud Pública,
aplicando arquetipos basados en la norma ISO 13606 que permite la
interoperabilidad entre los sistemas hospitalarios.
Objetivos Específicos
Analizar la norma ISO 13606 y levantar línea base para la creación de
arquetipo en función al Formulario 033-Odontología.
Desarrollar el arquetipo para la estructura y recuperación de datos.
Desarrollar la Historia Clínica Electrónica del Formulario 033-Odontología
del Ministerio de Salud Pública para ser utilizada en el diseño y representación de los datos en denominados arquetipos.
Alcances del problema
Al finalizar la investigación se tiene como objetivo el desarrollo de la Historia
Clínica Electrónica de odontología del MSP basada en la norma ISO/NTE 13606,
se levanta la información sobre la norma, y los elementos necesarios para
establecer el desarrollo, para lograr nuestro objetivo seguiremos los siguientes
puntos:
El proyecto abarca exclusivamente el formulario 033-Odontología del cual se
espera obtener como entregables el formulario 033 en modelos de información y
un banco de arquetipos.
Los arquetipos se lo elaboran con la herramienta LinkEHR que genera archivos
con extensión. adl y facilita la búsqueda de etiquetas del formulario.
8
El buen uso y correcto llenado de los datos del formulario es responsabilidad
estrictamente del odontólogo tratante o auxiliar de odontología que debe ingresar
la información de cada paciente.
El desarrollo de este proyecto es para las instituciones de salud a nivel nacional,
por lo tanto, no será implementado.
Justificación e Importancia
En la actualidad el MSP utiliza los formularios básicos HCU físicos (papel), donde
se registra la información concerniente a la salud actual de un paciente y la
evolución o recuperación de la salud a través de toda su vida, cuyo propósito
primordial es de servir como medio eficiente para la comunicación entre el médico
tratante y los demás profesionales que intervienen en dicha atención; los cuales
son establecidos dentro del Sistema de Información en salud, en el transcurso de
los años han empezado a surgir problemas, los sistemas implementados no se
ajustan a la realidad dada su complejidad y extensión ya que nuestro País carece
de estándares médicos válidos para lograr la interoperabilidad.
No obstante, cada sistema utilizado en los diferentes centros de salud define y
estructura la información a su conveniencia. Este tipo de problemas genera vacíos
en la continuidad de la información del paciente, al momento de trasladarse a otro
centro médico, lo que nos da como resultado un mal diagnostico o retraso.
De igual forma sirve de patrón para aquellas empresas que desarrollan Software
Médico en la formación de nuevas versiones, libres de incompatibilidades en
cuanto a las comunicaciones y manejo de información. Por ese motivo vamos a
trabajar de la mano con la norma CEN/ISO 13606 ya que está diseñada para lograr
interoperabilidad entre sistemas de HCE. Es aquí donde radica la importancia del
estudio, de la misma, en cuanto a información de historia clínica se refiere, debido
9
a esto el proyecto eSalud con la presente investigación tomará las pautas para
elaborar una propuesta de un sistema de HCE.
El proyecto nos abre las puertas al mundo de la medicina a nivel internacional,
teniendo como base, información actualizada sobre la medicina y avances
tecnológicos médicos a nivel mundial que posteriormente sirvan como
conocimiento para desarrollo de proyectos internos, estudios, investigación y
evaluación, que formen parte de la prevención y cura de enfermedades que
afectan al país.
Analizar la norma ISO 13606, interpretar los formularios del MSP y aplicar lo
estudiado es de vital importancia en la investigación, ya que a través de ésta
podremos brindar apoyo en la realización de una herramienta que pueda brindar
interoperabilidad entre sistemas de información clínico, específicamente en
sistemas de HCE que es el principal enfoque en este trabajo ya que a través de la
misma se podrá tener una base de conocimiento
Metodología del proyecto
Se escoge la metodología de cascada, ya que esta se divide en etapas cada una
va de la mano de la otra y para poder avanzar se deberá analizar bien cada una
de ellas, es como el ciclo de vida del software cada fase deberá ser completada
para continuar con el siguiente proceso.
Metodología de Desarrollo
En estudio Joel Quintana y José Daza (2014) concluyeron que, el modelo según
los editores de Tópicos Selectos de Ingeniería es el primer modelo de proceso de
desarrollo de software que se publicó derivado de procesos de ingeniería de
sistemas más generales. Debido a la cascada de una fase a otra, dicho modelo
se conoce como modelo en cascada o como ciclo de vida de software.
10
Análisis y definición de requerimiento: Los servicios, restricciones y metas del
sistema se definen a partir de las consultas con los usuarios. Entonces, se definen
en detalle y sirven como una especificación del sistema.
Diseño del sistema y del software: El proceso de diseño del sistema divide los
requerimientos en sistemas de hardware o de software. Establece una
arquitectura completa del sistema. El diseño del software identifica y describe las
abstracciones fundamentales del sistema software y sus relaciones.
Implementación y pruebas de unidades: Durante esta etapa, el diseño del
software se lleva acabo como un conjunto o unidades de programa. Las pruebas
de unidades implican verificar que cada una cumpla su especificación.
Integración y prueba del sistema: Los programas o las unidades individuales de
programas se integran o prueban como un sistema completo para asegurar que
se cumplan los requerimientos del software. Después de las pruebas, el sistema
software se integra al cliente.
Funcionamiento y mantenimiento: Por lo general (aunque no necesariamente),
ésta es la fase más larga del ciclo de vida. El sistema se instala y se pone en
funcionamiento práctico. El mantenimiento implica corregir errores no
descubiertos en las etapas anteriores del ciclo de vida, mejorar la implementación
de las unidades del sistema y resaltar los servicios del sistema una vez que se
descubren nuevos requerimientos (Pág. 36) (©ECORFAN-Bolivia, 2014).
Supuestos y Restricciones En esta etapa se indican los requerimientos internos y externos al proyecto para
lograr su correcta funcionabilidad y las restricciones que deben considerarse para
obtener mejoras continuas en el sistema de información del Formulario 033 de
Odontología del MSP.
11
Supuestos:
La base de datos contendrá toda la información de la HCE con todos los
servicios que contará la institución de salud.
Se utilizará un servidor de aplicaciones para levantar la aplicación web.
Se debe cumplir la comunicación de los sistemas por medio de los
arquetipos.
Al ingresar el código de HCE cargará automáticamente la información del
paciente HCU.
La historia clínica electrónica puede realizar modificaciones y cambios de
los registros antes de guardar y grabar la información en la HCE.
El sistema debe contar con una bitácora de HCE guardadas para facilitar
la gestión de operaciones y logística.
La generación de citas solo podrá ser agendadas por consulta externa en
el área de admisión.
Restricciones
Las instituciones de salud pública o privada podrán adaptarse al sistema si cuentan con una arquitectura homogénea.
Los soportes de usuario deberán cumplir con el perfil del sistema de
información.
Los candidatos a ocupar el cargo de administrador deben contar con una
hoja de vida con las características con conocimientos sólidos en Sprint
MVC link EHR y PostgreSQL que el sistema está siendo desarrollado.
El diseño de los arquetipos se realiza exclusivamente en la norma ISO
13606.
El sistema no permite cambios y modificaciones luego de grabar la
información en la historia clínica electrónica HCE.
El sistema no contará con un módulo para agendamiento de citas subsecuentes por el odontólogo.
12
CAPÍTULO II
MARCO TEÓRICO
Antecedentes del estudio En años anteriores se procuró llevar un control, monitoreo y seguimiento en las
operaciones de los sistemas de información en el campo de la medicina,
actualmente se realizan gastos de fuertes sumas de dinero en la gestión como son
controles internos, auditorías internas y externas para tener datos exactos y poder
tomar decisiones acertadas para el proceso de mejora continua. Por lo cual se
invierte según las necesidades; es decir, los departamentos solicitan
requerimientos a nivel físico o lógico para proteger sus datos con el objetivo de
realizar las operaciones en el menor tiempo posible.
Para minimizar el tiempo de atención médica se realizan operaciones y tareas
logísticas para la distribución de consultorios y médicos según un cronograma
dispuesto por el MSP el cual indica que la atención médica básica debe realizarse
sin importar la condición económica del paciente, razón por la cual se discrimina
la atención en algunas entidades de salud, pero el registro de atención tiene que
estar sustentado con argumentos y documentos firmados por el supervisor y
medico de turno; con estos antecedentes nace la necesidad de guardar los
registros de los pacientes en fichas (HCU) que ahora están estandarizadas por la
norma ISO 13606, las cuales deben respetarse y aplicarse en todas las
instituciones médicas.
Este problema se da por la falta de comunicación entre los sistemas médicos
conocido con interoperabilidad entre sistemas, es decir no se puede realizar
ninguna operación en el sistema médico cuando se debe trasladar o cambiar de
institución sanitaria.
13
La crisis económica a nivel mundial en el año 2016, nos enseña que se debe evitar
gastos innecesarios tanto a nivel público como privado, para lo cual se deben aplicar
correctivos en todo ámbito y más en la salud ya que de eso depende la estabilidad
emocional de los ecuatorianos. Cuando el ciudadano y la familia goza de buena salud
es más fácil realizar sus actividades al 100% no se estresan ni enferman con facilidad
por esta razón debemos cuidar la salud, ahora se propone prevención médica.
En Ecuador no se han implementado las normas ISO 13606 por lo que es importante
desarrollar proyectos informáticos médicos que ayuden al control, monitoreo y
seguimiento de los recursos para evitar que no se utilicen de forma ineficiente.
Para reforzar el análisis podemos citar lo siguiente: “En América latina unos de los
proyectos que busca crear estándares de información de salud es HL7 LATAM, el
cual es un espacio común para llevar adelante iniciativas y proyectos conjuntos por la
inherente coincidencia de intereses y necesidades que tienen los países de la región,
entre sus miembros podemos mencionar a HL7 Argentina, HL7 Brasil, HL7 Chile, HL7
Colombia, HL7 México, y HL7 Uruguay” (Margarita Elizabeth Cauja Colcha, 2016).
Fundamentación teórica En primer lugar, indicaremos que son los sistemas de información, sus definiciones y
ventajas desventajas que nos ofrecen y sus etapas para poder desarrollarlos. En el
siguiente punto se explicará sobre la comunicación de los sistemas (interoperabilidad)
donde definiremos sus conceptos y los tipos de interoperabilidad que existen
detallando cada tipo mencionado. Posteriormente describiremos conceptos de qué es
una historia clínica electrónica y se la va a comparar con una historia clínica única,
hablaremos de sus beneficios y los principales inconvenientes para su
implementación. Como punto final se analizará la norma ISO 13606 y el diseño de
arquetipos, sus principales componentes y estructura, junto con los acuerdos
reglamentos y leyes del Ministerio de Salud Pública y la ley del uso del SW Libre en
Ecuador.
14
Sistemas de información
Existen muchos conceptos acerca de sistemas de información en adelante SI, algunos autores enfocan los sistemas de información en el ámbito de las empresas
definiéndolo como “un conjunto de recursos técnicos humanos y económicos,
interrelacionados dinámicamente, y organizados en torno al objetivo de satisfacer la
necesidad de información de una organización empresarial para la gestión y la
correcta adopción de decisiones”. (Herederos, Medina Salgado, & Romero, 2011)
Un sistema es un conjunto de componentes que interaccionan entre sí para lograr un
objetivo común. Aunque existe una gran variedad de sistemas, la mayoría de ellos
pueden representarse a través de un modelo formado por cinco bloques básicos:
elementos de entrada, elementos de salida, sección de transformación, mecanismos
de control y objetivos. (Alarcón, 2006).
La mayoría de los conceptos estudiados nos indica que los Sistemas de Información son una miscelánea organizada de componentes los cuales reciben datos de entradas
para convertirlos en información, los distintos componentes procesan la información
y brindan una salida que satisface las necesidades de un sistema.
Gráfico N. 1 Modelo general de un sistema
Elaborado Por: Roberto Carlos González León Fuente: Datos de la investigación
15
Ciclo de vida de un sistema de información (SI).
Todo Sistema de Información pasa una serie de fases a lo largo de su desarrollo e
implementación, a lo que se denomina el ciclo de vida, Raymond (2000) Señala que
”El ciclo de vida de los sistemas es el proceso evolutivo que se sigue al implementar
un sistema o subsistema de información basado en computadora”. El ciclo de vida
consiste en una serie de tareas que siguen de cerca los pasos del enfoque de
sistemas.
Las fases del ciclo de vida de un sistema de información son:
Análisis
Diseño
Desarrollo
Pruebas
implementación y mantenimiento
Análisis. Interpretar los requerimientos para establecer de forma precisa lo que tiene que hacer
el sistema. La etapa de análisis en el ciclo de vida del software corresponde al proceso
mediante el cual se intenta descubrir qué es lo que realmente se necesita y se llega
a una comprensión adecuada de los requerimientos del sistema (Guerrero, 2015).
Diseño. En esta etapa se estudian las posibles alternativas de implementación para el sistema
de información que se ha de construir y se ha de definir la estructura general que
tendrá el sistema. (Brazón, 2015).
Desarrollo En esta etapa se seleccionan las herramientas adecuadas, un entorno de desarrollo
que facilite nuestro trabajo y un lenguaje de programación apropiado para el tipo de
16
sistema que vayamos a construir. La elección de estas herramientas dependerá en
gran parte de las decisiones de diseño que hayamos tomado hasta el momento y del
entorno en el que nuestro sistema deberá funcionar (Ministerio de Educación de
Venezuela, s. f.)
Pruebas. Durante las pruebas se tiene como objetivo detectar los errores que se hayan podido
cometer en las etapas anteriores del proyecto. La búsqueda de errores que se realiza
en la etapa de pruebas puede adaptar distintas formas, en función del contexto y de
la fase del proyecto (García, 2011).
Puesta a Producción y Mantenimiento. Berzal (2012) menciona que: Una vez se hayan corregido los errores que pudieran
surgir durante la etapa de pruebas, el SI quedará listo para poder ser utilizado y
durante esta etapa se prepara al personal para que haga uso del mismo, se planifica
una estrategia para que la implementación no tenga un alto impacto en relación con
la productividad del personal. Como sabemos las organizaciones no permanecen
igual, cambian a lo largo del tiempo, entonces el SI necesita ser modificado para que
se adapte a esos cambios, y es por ello que surgen las famosas actualizaciones.
Actividades de los Sistemas de Información.
Como mencionamos durante la definición de SI, estos reciben una entrada, procesan
información y brindan una salida satisfaciendo una necesidad; los SI, cumplen con
cinco actividades básicas que se definen a continuación:
Entrada de los recursos de datos.
Los datos sobre transacciones comerciales y otros sucesos deben obtenerse y
prepararse para el procesamiento por parte de la actividad de entrada. Por lo general,
las entradas son actividades de ingresos de datos, como registro y edición. Es común
que los usuarios finales registran datos sobre transacciones en algún medio físico,
como un formulario de papel, o los ingresan de forma directa a un sistema de
17
información. Normalmente, esto representa una variedad de tareas de edición para
afirmar que se han registrado los datos en forma precisa. Una vez ingresados, los
datos se pueden trasladar a un medio al que pueda acceder la máquina, hasta que
se necesiten para procesamiento (O’Brien, 2006).
Procesamiento de datos en información.
Los datos están comúnmente, sujetos a tareas de procesamiento, como cálculo,
equiparación, distribución, clasificación y resumen. Estas tareas organizan, analizan
y manipulan los datos, transformándolos de esta forma en información para los
usuarios finales. La calidad de cualquier dato almacenado en un sistema de
información también debe mantenerse mediante un proceso continuo de tareas de
rectificación y actualización (Laudon, 2012).
Salida de los productos de información.
La información en distintos formatos se transfiere a los usuarios finales y queda a su
disposición en la actividad de salida. Los sistemas de información tienen como
finalidad la elaboración de productos de información apropiados para los usuarios
finales. Entre los productos de información comunes se incluyen los mensajes,
formularios e imágenes gráficas, las cuales pueden ser proporcionadas por pantallas
de video, respuestas auditivas, productos de papel y multimedios (Vargas, 2013).
Almacenamiento de los recursos de datos.
18
El almacenamiento es un elemento de sistema básico de los sistemas de información.
El almacenamiento es la actividad de sistemas de información en la cual los datos y
la información se guardan de manera organizada para uso posterior. Por ejemplo, al
igual que el material de texto escrito se organiza en palabras, oraciones, párrafos y
documentos, los datos almacenados se organizan comúnmente en campos, registros,
archivos y bases de datos. Esto facilita su posterior uso en el procesamiento o su
recuperación como salida cuando se necesite por los usuarios de un sistema
(O’Brien, 2006).
Control del desempeño del sistema.
Una de las actividades más importantes de los sistemas de información es el control
de su desempeño. Un sistema de información debe producir retroalimentación sobre
las actividades de entrada, procesamiento, salida y almacenamiento. Esta
retroalimentación debe inspeccionarse y evaluarse para determinar si el sistema
cumple los estándares de desempeño establecidos. Entonces, las actividades
apropiadas del sistema deben ajustarse, de manera que se generen productos de
información apropiados para los usuarios finales (Romero, 2012).
Beneficios de los sistemas de información.
Los SI se han convertido dentro de las organizaciones en una herramienta vital para
la toma de decisiones y les permite brindar mejores servicios a sus clientes,”Los
sistemas de información son en la actualidad una herramienta que bien implementada
se convierte en un arma competitiva en los negocios, así como las empresas buscan
diferenciarse de su competencia, los sistemas de información son una manera de
hacerlo” (Bracho, 2011).
Bracho (2011) menciona que los beneficios que se pueden obtener usando
sistemas de información son los siguientes:
19
Acceder a la información de forma rápida brindando un mejor servicio a los
clientes.
Mayor agilidad en los mandos medios para anticipar los requerimientos de los
directivos.
Evaluación de reportes e indicadores, que ayudan a corregir fallas que no pueden
ser detectados y controlados con un sistema manual.
Probabilidad de plantear y generar proyectos dentro de una institución soportados
en sistemas de información que presentan elementos claros y sustentados.
Ahorrar tiempo en la búsqueda de información ya que esta esta almacenada en
un medio físico que puede ser compartido si se lo requiere.
Fomentar la creación de grupos de trabajo e investigación debido a la facilidad
para encontrar y manipular la información.
Solucionar el problema de falta de comunicación entre las diferentes instancias.
Facilitar la comunicación entre directivos.
Mejor organización en el manejo de información clasificada por temas de interés
general y particular.
Establecer varias alternativas de comunicación, utilizando medios informáticos
como el correo electrónico, teleconferencia, acceso directo a bases de datos y
redes.
Permitir acceso a programas y convenios e intercambios institucionales.
Mejorar la productividad ya que permiten automatizar tareas manuales.
Interoperabilidad
¿Qué es Interoperabilidad?
La interoperabilidad es la habilidad que tienen las organizaciones para intercambiar
información entre ellos y utilizarla según su conveniencia, la interoperabilidad ha sido
un factor de gran importancia respecto a la mejora de los servicios y cooperación
entre empresas o mejorar la comunicación entre procesos internos. En el ámbito de
la informática, la interoperabilidad es la capacidad del software y del hardware
20
perteneciente a diferentes máquinas y marcas para compartir datos. En el ámbito de
la documentación se entiende por interoperabilidad la capacidad de un sistema de
hardware o de software para comunicarse con otro sistema en el intercambio de
datos. Una definición de interoperabilidad que supera los límites del hardware y
software, así como el correcto intercambio de datos entre sistemas entiende por
interoperabilidad “los procesos tecnologías y protocolos requeridos para asegurar la
integridad de los datos cuando se transfieren de un sistema a otro” (Martínez y Lara,
2007).
Interoperabilidad de la información.
Los conceptos de interoperabilidad en la literatura científica son relativamente
escasos, las tipologías referentes a interoperabilidad se pueden dar tanto en lo
referente al contenido (sintáctico, semántico) como en el ámbito de la organización
(técnica, semántica, organizativa).
La interoperabilidad de la información comprende la interoperabilidad sintáctica y
semántica sin embargo para garantizar una efectiva interoperabilidad de la
información se debe combinar aspectos técnicos y organizativos.
Interoperabilidad según las distintas corrientes.
Según las distintas corrientes, han logrado ver diferentes enfoques de la
interoperabilidad que mostraremos a continuación:
Dimensiones de interoperabilidad.
Las dimensiones de Interoperabilidad según European Interoperability Framework
(EIF) divide la interoperabilidad en tres dominios o dimensiones:
21
Interoperabilidad Técnica. Se refiere a la conexión de los sistemas mediante
acuerdos sobre las normas y estándares para la presentación, recolección,
intercambio, transformación y transporte de datos.
Interoperabilidad Semántica. Garantiza que los datos transferidos
comparten el mismo significado para los datos vinculados.
Interoperabilidad Organizativa. La organización de los procesos de
negocios y estructuras organizativas internas para un mejor intercambio de
datos.
El siguiente grafico detalla las dimensiones mencionadas:
Gráfico N. 2 Dimensiones de la interoperabilidad
Elaboración: European Interoperability Framework Fuente: Datos de la investigación
Niveles de Interoperabilidad. La EIF clasifica los niveles de interoperabilidad que se
mencionan a continuación:
Interoperabilidad jurídica. Las administraciones probablemente tengan que
realizar alguna iniciativa legal para que la colaboración entre administraciones
22
sea acorde a los distintos ordenamientos jurídicos de las partes que participan
en el proceso interoperable debido a incompatibilidades (Salas, 2011).
Interoperabilidad organizativa. Se refiere a la manera en la que cooperan
las organizaciones para alcanzar sus metas adaptadas de común acuerdo
(European Commission, 2010).
Interoperabilidad semántica. Permite a las organizaciones procesar de
manera inteligible la información procedente de fuentes exteriores. Garantiza
que el significado exacto de la información intercambiada sea comprendido y
conservado (Abecasis, 2014).
Interoperabilidad técnica. Se refiere a los aspectos técnicos de la conexión
de sistemas de información. Incluye elementos tales como especificaciones
de interfaz, servicios de interconexión, servicios de integración de datos,
presentación e intercambio de datos, entre otros (Martínez y Lara, 2007).
Capas de interoperabilidad. Bueno (2008) menciona que: El proyecto europeo LIFE, financiado por la Comisión
Europea área de Educación y Cultura, publicó en 2006 un informe detallado sobre la
interoperabilidad de la educación en Europa. Este informe adopta un marco semiótico
para ayudar a entender los distintos aspectos de la interoperabilidad, que contempla
varias capas de la interoperabilidad:
Capa física. Apariencia física, medios de comunicación y cuantía de contacto
disponible
Capa empírica. Implica la entropía, variedad y equívocos encontrados.
Capa sintáctica. Abarca el lenguaje, estructura y lógica empleada para que los
sistemas, subsistemas y módulos puedan interoperar.
Capa semántica. Aborda la interoperabilidad del significado y validez de lo
expresado, como que la información dada por un actor de un sistema
educativo pueda ser entendida correctamente por otro.
23
Capa pragmática. Está referida a las intenciones comunes (como puede ser
un objetivo pedagógico común), a aspectos de responsabilidad como la
confianza y a otras consecuencias de las declaraciones expresadas.
Capa social. Aborda los intereses, creencias y compromisos compartidos;
como resultado, se refiere a la compatibilidad de creencias y valores de
distintos sistemas educativos, que pueden variar de un país o región a otra.
Historia Clínica Electrónica
La Historia Clínica Electrónica es una colección longitudinal de información
Electrónica sobre la salud de los pacientes donde la información sobre salud
es definida como información pertinente a la salud de un individuo, o la información
de los cuidados de salud provistos a un individuo, por medio de cualquier miembro
del equipo de salud. Tiene la posibilidad de dar acceso a la información de salud
solo a los usuarios autorizados. Provee las bases de conocimiento y sistemas de
soporte para la toma de decisiones que mejoren la calidad, seguridad y eficiencia de
la atención de los pacientes. Tiene el objetivo primordial de dar soporte para la
eficiencia de los procesos de cuidados de salud ( Dicks, 1991, citado por Sabartés,
Ricard, 2013).
Michel (2011) señala que una HCE (historia clínica electrónica) es una colección de
los detalles de salud de un paciente. Es decir, es una nueva forma de guardar y
estructurar la información del paciente. Al igual que las fichas de hospital, los archivos
de HCE de los pacientes se distribuyen en secciones donde los profesionales
ingresan la información para suministrar cuidado médico al paciente o realizar tareas
administrativas.
La información guardada en una HCE puede incluir el historial médico de un paciente
(tales como el estado de las vacunas, resultados de exámenes de laboratorio, y
registros de crecimiento y desarrollo), información sobre el seguro médico y de
facturación y otros datos relacionados con la salud.
24
La implementación de una HCE no tiene porqué de entrada, producir un cambio
significativo en la manera de trabajar de los distintos profesionales; sin embargo,
puede ser una oportunidad para revisar la organización de los Servicios y la manera
de trabajar (Sabartés, 2013).
Cómo se accede a la información.
Michel (2011) señala que la mayoría de las instituciones hospitalarias tienen sus
propios gestores de bases de datos de HCE exclusivas que están configuradas para
que sean accesibles desde cualquier computadora. De tal forma que los médicos,
enfermeros u otras instituciones médicas que tengan permiso para iniciar sesión
mediante un usuario y contraseña puedan acceder a la información que necesiten.
Los profesionales también pueden tener acceso a la información de forma remota por
medio de una computadora a través de servidores dedicados de una institución
siempre que se den los permisos necesarios. Así mismo, los sistemas son accesibles
directamente a través de Internet.
Cuáles son los beneficios.
Michel (2011) menciona que, todos saben las bromas sobre la escritura ilegible de
los médicos. Pero las ventajas de las HCE superan los problemas de legibilidad. Las
HCE también pueden: almacenar los datos de manera segura. El almacenamiento de
datos de HCE ayuda a conservar la información médica de un paciente. Todo cambio
que se realice en una HCE se puede explorar junto con la identificación de la persona
que lo realizó y la hora. La información no puede ser borrada de los registros. A
diferencia de la información ingresada en papel en donde hay posibilidad de que se
25
pierdan, se archiven incorrectamente o que se deterioren con el paso del tiempo. En
el año 2005, el huracán Katrina destruyó los registros clínicos en papel de miles de
pacientes en Luisiana, Misisipí y Alabama, por ejemplo, y nunca se recuperó la
mayoría de esa información (Sahara, 2013).
Evitan errores médicos. Se pueden evitar errores médicos. Se ha demostrado que las
HCE eliminan hasta un 95 % de los errores médicos. El porcentaje aumenta según el
nivel del software. En la actualidad, muchos sistemas de HCE apoyan a los médicos
a recetar medicamentos de forma más eficaz, ya que los sistemas hacen los cálculos
correctos para las dosis necesarias de estos medicamentos. También poseen
información sobre las interacciones con otros medicamentos que podrían ser nocivas
para el paciente, alergias o posibles reacciones alérgicas y alertan a los médicos
(Serna Adriana y Ortiz Olga, 2014) .
Ahorran tiempo. Un sistema de HCE permite a un médico ser rápido y riguroso porque
proporciona una serie de alertas y menús desplegables en los que puede ingresar.
No existen restricciones en cuanto a los médicos que puedan revisar al mismo tiempo
un registro clínico eliminando el tiempo de espera en relación a los registros en papel.
De tal manera, que un médico puede revisar los resultados de los exámenes mientras
un enfermero ingresa los signos vitales y el departamento de facturación envía
trámites al seguro a través del sistema (Michel, 2011) .
Ahorran espacio. Gracias a los sistemas de HCE, los enormes archivos pronto se
dejarán de usar para archivar papeles. Este espacio puede ser ocupado en oficinas
dentro del hospital se pueden convertir en áreas/salas para aumentar el número de
pacientes y así mejorar la atención al paciente, quizás algunas habitaciones
adicionales para pacientes u otro centro de exámenes por imágenes (Gencat, 2013).
Capacitan a los pacientes. Los padres pueden participar activamente en el cuidado
médico de sus hijos, cuando tienen un mejor acceso a los archivos médicos. Esto
significa que pueden realizar consultas de los resultados de exámenes, revisar las
instrucciones del médico para el cuidado en casa e incluso revisar que no existan
errores (Otero, 2011).
26
Barreras para la Implementación.
Sabartés (2013) señala que cuando se decide implementar una HCE se debe tener
en cuenta que existen una serie de inconvenientes. Las barreras que se pueden
presentar en la implementación de una HCE son:
Financieras: Ya que los costos de inversión y mantenimiento son muy altos,
existiendo incertidumbre del retorno de la inversión. Técnicas: La falta de infraestructura se podría convertir en una de las
principales barreras en la implementación, así como la posible falta de agilidad
en los usuarios al manipular un nuevo sistema, la falta de soporte o
personalización de los sistemas. Temporales: Ya que la implementación de este tipo de sistemas requieres un
tiempo extenso; es decir, los plazos de ejecución son largos, implicando el
ingreso de datos y la transferencia de información histórica al nuevo soporte
electrónico. Psicológicas: La implementación de un sistema de HCE puede ser
considerando una pérdida de autonomía por la incertidumbre de los usuarios. Sociales: Por la necesidad de cooperación entre profesionales de la salud
que poseen variados perfiles o por falta de confianza con las empresas
distribuidoras. Legales: Relacionadas con la confidencialidad de la información de la HCE. Gestión del cambio: Debido a la falta de incentivos, participación o
liderazgo. Organizativas: Según la complejidad de la organización y sus actividades.
Norma INEN- ISO/NTE 13606
Esta norma fue adoptada en el Ecuador en el año 2014. (Inen, 2014)
Fueron adoptados 2 partes:
27
Modelo de referencia (Parte 1)
Especificación de Interfaces (Parte 5)
El comité Interno INEN es el responsable de la adopción de esta Norma Técnica
ecuatoriana. Esta norma nos proporciona información para comunicar Historias
Clínicas electrónicas de pacientes.
También da soporte a la interoperabilidad de sistemas y componentes de la
información de la HCE que es necesario comunicar.
La norma está compuesta de 5 partes:
Modelo de Referencia.
Modelo de Arquetipos.
Arquetipos de Referencia y lista de Términos.
Seguridad.
Especificación de Interfaces.
Modelo de Referencia (MR).
Es un modelo de información para comunicar la historia clínica electrónica de
cualquier paciente.
El modelo de referencia en adelante MR, define las estructuras para organizar la
información. La estructura más general es el extracto, que contiene la parte
seleccionada de la HCE de un paciente para ser transferida a otro sistema. “Los
extractos forman parte de los mensajes, los extractos incluyen información
demográfica para reconocer al paciente y a todos los agentes involucrados,
información sobre las políticas de acceso, información clínica y otros tipos de información auxiliar como auditorías o firmas.” (Rubio, 2009).
28
Este modelo “Define un conjunto de clases que forman los componentes básicos de
la Historia Clínica Electrónica, es decir, refleja las características estables de una Historia Clínica Electrónica” (Muñoz, s. f.).
El Modelo Referencial define componentes jerárquicos del extracto de Historia Clínica
Electrónica. En la siguiente grafica se detalla la estructura del MR:
Gráfico N. 3 Modelo Referencial
Elaboración: Norma INEN ISO 13606-1 Fuente: Datos de la investigación
La estructura del MR la detallaremos a continuación:
EHR_EXTRACT (Extracto de HCE): “Es el contenedor de más alto nivel de
parte o toda la HCE de un único sujeto de la asistencia, para la comunicación
entre un sistema proveedor de la HCE y un receptor de la HCE” (Rubio, 2009).
29
FOLDER (Carpeta): “La organización de alto nivel dentro de una HCE, que la
divide en compartimentos relativos a la asistencia prestada para una única
condición, por un equipo o institución clínica, o durante un tiempo fijado tal como un episodio de asistencia”. (Rubio, 2009). Ejemplos de carpeta podrían
ser: atención a diabetes, esquizofrenia, pediatría, Hospital Reina Sofía,
Episodios 2000-01, etc.
COMPOSITION (Composición): “El conjunto de información grabada en una
HCE por un agente, como resultado de un único encuentro clínico o una sesión de documentación de la historia”. (Rubio, 2009) Ejemplos de composición
podrían ser: Nota de evolución, formulario de resultado de pruebas de
laboratorio, informe radiológico, impreso de derivación, visita clínica, informe
de alta, etc.
SECTION (Sección): “Datos de la HCE dentro de una composición
perteneciente a una cabecera clínica, que usualmente refleja el flujo de
información reunido durante un encuentro clínico, o estructurado para una más beneficiosa lectura futura” (Rubio, 2009). Ejemplos de sección serían:
antecedentes, información de alergias, hallazgos objetivos, dieta, análisis,
examen de la retina, etc.
ENTRY (Entrada): “La información registrada en una HCE como resultado de
una acción clínica, una observación, una interpretación clínica o un propósito clínico. Esto se conoce también como declaración clínica”. (Rubio, 2009). Ejemplos de entrada serían: síntoma, observación, medicamento prescrito,
recuento de leucocitos, etc.
CLUSTER (Grupo): “Estructura de datos para organizar otros elementos tales
como las series temporales, y para representar las columnas de una tabla” (Rubio, 2009). Ejemplos de clústers son: resultados de un audiograma,
30
interpretación de un encefalograma, diagnósticos diferenciales ponderados,
etcétera.
ELEMENT (Elemento): “Representa el valor de un dato en la HCE. Ejemplos
de elemento son: presión sanguínea sistólica, ritmo cardíaco, nombre de medicamento, síntoma, peso del cuerpo, etc.” (Rubio, 2009).
31
Gráfico N. 4 Detalle de la Estructura del MR
Elaboración: Norma INEN ISO 13606-1
Fuente: Datos de la investigación.
Modelo de Arquetipo.
Especificación de intercambio de arquetipos: “Un arquetipo es una definición de una
estructura de información utilizada en un dominio particular y que está basada en un Modelo de Referencia.” (Rubio, 2009).
Un arquetipo puede representar información formal de conceptos clínicos que son
utilizados por los profesionales de la salud en sus actividades, por ejemplo, informe
de alta, historia clínica de primaria, resultados bioquímicos, diagnóstico, etc.
Un ejemplo de arquetipo puede ser la prescripción de medicina definida por un
profesional de la salud, el mismo podría tener la siguiente información: Nombre de la
medicina, intervalo de tiempo, unidad de medida del medicamento, fecha y hora de
suministro al paciente.
Secciones de encabezamiento del arquetipo Las secciones de encabezamiento del arquetipo son las siguientes:
32
Gráfico N. 5 Secciones de encabezamiento de arquetipo
Elaboración: Norma INEN ISO 13606 Fuente: datos de la investigación
Arquetipos de referencia y lista de términos
Contiene un grupo normativo de términos codificados y uno de arquetipos, el primero
establece controladamente un vocabulario para utilizarlo en el modelo de referencia,
los términos son:
SUBJECT_CATEGORY de entrada
ITEM_CATEGORY, estructura de datos.
VERSION_STATUS, estado de una versión.
FUNCTIONAL_ROLE, medios electrónicos.
ACT_STATUS,” valores de estado acto”
LINK_NATURE, “relación entre el origen y el destino record_component”.
LINK_ROLE, “subcategoría de los términos de enlace corresponsal.”
STRUCTURE_TYPE, “estructura de un clúster”
33
Seguridad
Describe una metodología para la especificación de los privilegios necesarios para
acceder a los datos de HCE. Esta metodología forma parte de la arquitectura global
de comunicaciones de la HCE definido en la norma ISO 13606-1. (ISO, 2009).
Especificación de interfaces
Especifica la arquitectura de la información requerida para las comunicaciones
interoperables entre los sistemas y servicios que necesitan o proporcionan datos
EHR.
Define un conjunto de interfaces para solicitar y proporcionar:
Un EHR_EXTRACT para un tema determinado de la atención como se define
en la norma ISO 13.606-1.
Uno o más ARCHETYPE (s) tal como se define en la norma ISO 13606-2.
Un EHR_AUDIT_LOG_EXTRACT para un tema determinado de la atención
como se define en la norma ISO / TS 13.606-4.
Define el conjunto de interacciones para solicitar cada uno de estos artefactos, y para
proporcionar los datos a la parte solicitante o rechazar la solicitud. Una interfaz para
consultar una HCE o poblaciones de las HCE, por ejemplo, para la auditoría clínica o
de investigación, están más allá de su ámbito de aplicación, aunque se ha previsto
ciertos criterios de selección para especificar al solicitar un EHR_EXTRACT que
también podría servir para las consultas de la población (ISO, 2010).
34
Gráfico N. 6 Diagrama de iteraciones de las interfaces
Elaboración: Norma INEN ISO/NTE 13606-5 Fuente: Datos de la investigación
A continuación, se detallan cada uno de los elementos de la iteración:
EHR_requester. Autoriza la comunicación del artefacto.
EHR_provider. Un servicio de repositorio que contiene y puede devolver el
artefacto solicitado.
EHR_recipient que pretende y está automatizado para recibir el artefacto.
Es necesario localizar al EHR_provider y establecer los servicios a los que da soporte,
a través de un directorio publicado, servicio de localización o por un conocimiento
previo del EHR_requester. Una vez que está localizado, los interfaces de los servicios
relevantes deben estar accesibles para las partes en comunicación (por ejemplo, es
necesario disponer de las autorizaciones relevantes). (NORMA INEN ISO/NTE, 2015)
El EHR_provider necesita conocer con antelación la autenticación y las
autorizaciones (privilegios) del EHR_requester o este último debe requerir el acceso
a los medios para verificarlos en el momento de la petición. (NORMA INEN ISO/NTE,
2015).
35
Request_Ehr_Extract
Descripción
Esta interfaz específica la información que debe o puede proporcionar un
EHR_requester para definir lo más precisamente posible los datos de la EHR que se
pide que incluya el EHR_provider en el EHR_EXTRACT. Se pueden proporcionar
restricciones sobre los datos de la historia clínica, tales como un intervalo de fichas,
una lista de Arquetipos a incluir, etc. (NORMA INEN ISO/NTE, 2014).
Es necesario que las políticas de seguridad que se aplican a esta petición, incluyendo
las autorizaciones pertinentes para el EHR_requester y cualquier consentimiento
específico que haya sido otorgado para esta petición en concreto, sean acordadas
por anticipado, o comunicadas en paralelo a esta petición. (NORMA INEN ISO/NTE,
2015)
Request Archetypes
Descripción
Esta interfaz específica a la información que puede ser proporcionada por un
EHR_requester para definir un conjunto de Arquetipos que se le poden al
EHR_provider que proporcione al EHR_recipient. La interfaz de petición permite al
EHR_requester proporciona una serie de descriptores mediante los cuales se pueden
seleccionar los arquetipos adecuados de un repositorio. Si se especifican múltiples
restricciones, los artefactos suministrados deben ser conformes con todas las
restricciones (es decir con su intersección). (NORMA INEN ISO/NTE, 2015).
36
Request Ehr_Audit_Log_Extract
Descripción
Esta interfaz especifica la información que debe proporcionarse por un
EHR_requester para definir tan precisamente como sea posible los datos de un
registro de auditoría que se piden al EHR_provider que incluye dentro de un
EHR_AUDIT_LOG_EXTRACT.
Es necesario que las políticas de seguridad que se aplican a esta petición, incluyendo
las autoridades pertinentes para el EHR_resquester y cualquier consentimiento
específico que haya sido otorgado para esta petición en concreto, sean acordadas
por anticipado o comunicadas en paralelo a esta petición.
Herramientas para el desarrollo del proyecto
Java
Java es la base para prácticamente todos los tipos de aplicaciones de red, además
del estándar global para desarrollar y distribuir aplicaciones móviles y embebidas,
juegos, contenido basado en web y software de empresa. Con más de 9 millones de
desarrolladores en todo el mundo, Java le permite desarrollar, implementar y utilizar
de forma eficaz interesantes aplicaciones y servicios. Recuperado de (Java, 2014).
Desde portátiles hasta centros de datos, desde consolas para juegos hasta súper
computadoras, desde teléfonos móviles hasta Internet, Java está en todas partes.
Java es una tecnología que se usa para el desarrollo de aplicaciones que convierten
a la Web en un elemento más interesante y útil. Java no es lo mismo que javascript,
que se trata de una tecnología sencilla que se usa para crear páginas web y
solamente se ejecuta en el explorador.
Java le permite jugar, cargar fotografías, chatear en línea, realizar visitas virtuales y
utilizar servicios como, por ejemplo, cursos en línea, servicios bancarios en línea y
37
mapas interactivos. Si no dispone de Java, muchas aplicaciones y sitios web no
funcionarán.
Por defecto, Java le notificará inmediatamente que hay nuevas actualizaciones listas
para instalarse. Si desea estar al día y mantener la seguridad de su computadora, es
importante que acepte e instale las actualizaciones. Si recibe una notificación de
actualización de Java en su computadora Windows y no recuerda haberla descargado
o instalado, lo más probable es que Java estuviera ya instalado en la nueva
computadora. Recuperado de https://www.java.com/es/about/whatis_java.jsp
Ide de desarrollo
Un entorno de desarrollo integrado, es un entorno de programación que ha sido
empaquetado como un programa de aplicación, es decir, consiste en un editor de
código, un compilador, un depurador y un constructor de interfaz gráfica (GUI).
Los IDE proveen un marco de trabajo amigable para la mayoría de los lenguajes de
programación tales como C++, PHP, Python, Java, C#, Delphi, Visual Basic, etc. En
algunos lenguajes, un IDE puede funcionar como un sistema en tiempo de ejecución,
en donde se permite utilizar el lenguaje de programación en forma interactiva, sin
necesidad de trabajo orientado a archivos de texto. (Fergarciac, 2013)
Spring
Spring es un framework alternativo al stack de tecnologías estándar en aplicaciones
JavaEE. Nació en una época en la que las tecnologías estándar JavaEE y la visión
"oficial" de lo que debía ser una aplicación Java Enterprise tenían todavía muchas
aristas por pulir. Los servidores de aplicaciones eran monstruosos devoradores de
recursos y los EJB eran pesados, inflexibles y era demasiado complejo trabajar con
ellos. En ese contexto, Spring popularizó ideas como la inyección de dependencias o
38
el uso de objetos convencionales (POJOs) como objetos de negocio, que suponían
un soplo de aire fresco. Estas ideas permitían un desarrollo más sencillo y rápido y
unas aplicaciones más ligeras. Eso posibilitó que de ser unframework inicialmente
diseñado para la capa de negocio pasará a ser un completo stack de tecnologías para
todas las capas de la aplicación.
Las ideas "innovadoras" que en su día popularizó Spring se han incorporado en la
actualidad a las tecnologías y herramientas estándar. Así, ahora mismo no hay una
gran diferencia entre el desarrollo con Spring y el desarrollo JavaEE "estándar", o al
menos no tanta como hubo en su día. No obstante, Spring ha logrado aglutinar una
importante comunidad de desarrolladores en torno a sus tecnologías y hoy por hoy
sigue constituyendo una importante alternativa al estándar que merece la pena
conocer. En la actualidad, las aportaciones más novedosas de Spring se centran en
los campos de Big Data/NoSQL, HTML5/móviles y aplicaciones sociales.
Básicamente, la mayor diferencia práctica que podemos encontrar hoy en día entre
desarrollar con Spring y con JavaEE estándar es la posibilidad de usar un servidor
web convencional al estilo Tomcat para desplegar la aplicación. Las tecnologías
JavaEE más sofisticadas requieren del uso de un servidor de aplicaciones, ya que los
APIs los implementa el propio servidor, mientras que Spring no es más que un
conjunto de librerías portables entre servidores. En otras palabras, usando JavaEE
estándar, nos atamos al servidor de aplicaciones y usando Spring nos atamos a sus
APIs. Eso sí, los desarrolladores de Spring se han preocupado bastante de armonizar
con el estándar en la medida de lo posible, por ejemplo dando la posibilidad de usar
anotaciones estándar aun con implementaciones propias por debajo. La idea es
obstaculizar lo menos posible una posible portabilidad a JavaEE, idea que es de
agradecer en un mundo en que todos los fabricantes intentan de una forma u otra
mantener un público cautivo. (Copyright © 2012-2013 Depto. Ciencia de la
computación e IA, 2014)
39
Eclipse
Eclipse es una plataforma de desarrollo de código abierto basada en Java. Por si
misma, es simplemente un marco de trabajo y un conjunto de servicios para la
construcción del entorno de desarrollo de los componentes de entrada.
Afortunadamente, Eclipse tiene un conjunto de complementos, incluidas las
Herramientas de Desarrollo de Java (JDT)
Mientras que la mayoría de los usuarios están felices de usar Eclipse como un IDE
de Java, sus ambiciones no se detienen ahí. Eclipse también incluye el Entorno de
Desarrollo de Complementos (PDE), que es de interés principalmente para los
desarrolladores que quieren extender Eclipse, dado que les permite construir
herramientas que se integran sin dificultades con el entorno de Eclipse. Dado que
todo en Eclipse es un complemento, todos los desarrolladores de herramientas tienen
un campo de juego de nivel para ofrecer extensiones a Eclipse y para proporcionar
un entorno de desarrollo integrado y unificado para los usuarios.
Esta paridad y consistencia no está limitada a las herramientas de desarrollo de Java.
Aunque Eclipse se escribe en el lenguaje Java, su uso no se limita al lenguaje Java.
Por ejemplo, los complementos se encuentran disponibles o planificados para incluir
soporte para los lenguajes de programación como C/C++ y COBOL. El marco de
trabajo de Eclipse puede también utilizarse como base para otros tipos de
aplicaciones que no se relacionen con el desarrollo del software, como los sistemas
de gestión de contenido.
El ejemplo principal de una aplicación basada en Eclipse es el entorno de trabajo de
IBM® WebSphere® Studio, que forma la base de la familia de IBM de las
herramientas de desarrollo de Java. WebSphere Studio Application Developer, por
ejemplo, agrega soporte para JSP, servlets, EJB, XML, servicios web y el acceso a la
base de datos. (IBM, 2012).
40
WILDFLY
Es una aplicación gestionada flexible, ligera, que representa una nueva versión
mejorada del servidor de aplicación JBoss. Está escrita en Java e implementa la
especificación de Java EE. Wildfly es completamente gratis y de código abierto,
disponible para ser usada en muchas plataformas.
Sus principales características son:
Despliegue rápido y la habilidad de editar recursos estáticos sin redespliegue. Cada
servicio puede ser iniciado y detenido en aislamiento. Pesos ligeros a través de
gestión de memoria eficiente. Enfoque modular.
POSTGRESQL
Es un sistema de gestión de bases de datos objeto-relacional, distribuido bajo licencia
BSD y con su código fuente disponible libremente. Es el sistema de gestión de bases
de datos de código abierto más potente del mercado y en sus últimas versiones no
tiene nada que envidiarles a otras bases de datos comerciales.
Utiliza un modelo cliente/servidor y usa multiprocesos en vez de multihilos para
garantizar la estabilidad del sistema. Un fallo en uno de los procesos no afectará el
resto y el sistema continuará funcionando. ( http://www.postgresql.org,2010)
Una base de datos de clase empresarial, PostgreSQL cuenta con sofisticadas
características tales como control multi-versión de concurrencia (MVCC), punto en el
tiempo de recuperación, los espacios de tabla, la replicación asincrónica,
transacciones anidadas (puntos de retorno), en línea / backups en caliente, un
sofisticado planificador de consulta / optimizador, y escribir de manera anticipada
registro para tolerancia a fallos. Es compatible con los juegos de caracteres
internacionales, la codificación de caracteres de varios bytes, Unicode, y es
consciente de las configuraciones regionales de la clasificación, mayúsculas y
41
minúsculas, y el formato. Es altamente escalable tanto en la enorme cantidad de
datos que puede manejar y en el número de usuarios concurrentes que puede
acomodar. Hay sistemas activos de PostgreSQL en entornos de producción que
manejan más de 4 terabytes de datos.(www.postgresql.org/about/,2011)
Fundamentación legal El presente proyecto de titulación se sustenta bajo el punto de vista jurídico legal que
se rige en el territorio Ecuatoriano mediante la ley del MSP , acuerdo 00004934 donde
indica el uso de la historia clínica (Publica, 2014), decreto presidencial decreto N.
1014 que indica el uso de software libre en las instituciones Públicas del Ecuador y
Normas ISO 13606 donde indica el estándar para la interoperabilidad de las historias
clínicas electrónicas que se encuentran plasmadas en la Constitución Política del Ecuador.
Acuerdos y resoluciones legales del MSP
Ministerio de Salud Pública
Despacho Ministerial No. 00001190
EL MINISTRO DE SALUD PÚBLICA C O N SI DE R A N DO:
QUE; la Constitución de la República del Ecuador dispone: "Art.32.- La salud es un
derecho que garantiza el Estado, cuya realización se vincula al ejercicio de otros
derechos, entre ellos el derecho al agua, la alimentación, la educación, la cultura
física, el trabajo, la seguridad social, los ambientes sanos y otros que sustentan el
buen vivir.
El Estado garantizará este derecho mediante políticas económicas, sociales,
culturales, educativas y ambientales; y el acceso permanente, oportuno y sin
exclusión de programas, acciones y servicios de promoción y atención integral de
42
salud, salud sexual y salud reproductiva. La prestación de los servicios de salud se
regirá por los principios de equidad, universalidad, solidaridad, interculturalidad,
calidad, eficiencia, precaución y bioética, con enfoque de género y generacional.";
QUE; el Art. 154, numeral 1, de la Constitución de la República del Ecuador, faculta
que, a los Ministros de Estado, les corresponde ejercer la rectoría de las políticas
públicas del área a su cargo y expedir los acuerdos y resoluciones administrativas
que requiera su gestión; esto en concordancia con lo dispuesto en el Art. 17 del
Estatuto de Régimen Jurídico y Administrativo de la Función Ejecutiva, reformado
mediante Decreto Ejecutivo NO 2428, publicado en el Registro oficial NO 536 de 18
de marzo del 2002;
QUE; el Art. 227 de la Constitución de la República del Ecuador prescribe que la
administración pública constituye un servicio a la colectividad que se rige por los
principios de eficacia, eficiencia, calidad, jerarquía, desconcentración,
descentralización, coordinación, participación, planificación, transparencia y
evaluación
QUE; el Art. 361 de la Constitución de la República del Ecuador prescribe: "El Estado
ejercerá la rectoría del sistema a través de la autoridad sanitaria nacional, será
responsable de formular la política nacional de salud, y normará, regulará y controlará
todas las actividades relacionadas con la salud, así como el funcionamiento de las
entidades del sector.";
QUE; la Ley Orgánica de Salud manda: "Art. 4.- La autoridad sanitaria nacional es el
Ministerio de Salud Pública, entidad a la que le corresponde el ejercicio de las
funciones de rectoría en salud; así como la responsabilidad de la aplicación, control y
vigilancia del cumplimiento de esta Ley; y, las normas que dicte para su plena vigencia
serán obligatorias.";
Art. 6.- Es responsabilidad del Ministerio de Salud Pública:
43
1. Definir y promulgar la política nacional de salud con base en los principios y
enfoques establecidos en el artículo 1 de esta Ley, así como aplicar, controlar y vigilar
su cumplimiento;
2. Ejercer la rectoría del Sistema Nacional de Salud;
QUE; mediante Decreto Ejecutivo NO 332 de 21 de abril del 2010, el señor Presidente
Constitucional de la República del Ecuador, designó al Dr. David Chiriboga Allnutt,
Ministro de Salud Pública;
QUE; existen las normativas internacionales ISO TC 215 y HL7 (informática en salud)
y terminologías internacionales para asegurar la interoperabilidad entre aplicaciones
sanitarias electrónicas. Son el conjunto de especificaciones necesarias para el
intercambio de la información clínica entre los tres niveles de atención, evitar la
pérdida de Información y eliminar la ambigüedad;
QUE; el Ministerio de Salud, como Autoridad Sanitaria Nacional, tiene la
responsabilidad y atribución de determinar la normativa y estándares para el registro
de datos clínicos a las entidades del Sistema Nacional de Salud;
QUE; mediante memorando N° CG-10-295-2011 de 27 de septiembre del 2011, se
conformó una comisión para la aprobación de los estándares a utilizarse en el Sistema
Nacional de Salud;
Acuerdo 04934
El Acuerdo 04934 indica que se debe utilizar el número de cédula como código único
de historia clínica única, para cumplir con la disposición se incluirá los 10 dígitos en
el campo del código de historia clínica único (Ministerio de salud Publica, 2015)
44
Acuerdo Ministerial 04934,
Acuerdo Ministerial 04934, suscrito el 30 de julio de 2014, a través del cual se
determina el uso de un solo código de Historia Clínica Única, el mismo que será
utilizado a Nivel Nacional.
Se dispone a todas las Unidades Operativas del Ministerio de Salud Pública del
primer, segundo y tercer nivel, el uso de la cédula de ciudadanía como código único
de la HCU.
El 24 de noviembre de 2014 mediante circular MSP-CGP-10-2014-0001, suscrita por
el Ec. Santiago Rivera Coordinador General de Planificación, hace referencia al
documento anterior y emite directrices para la aplicación del Acuerdo Ministerial
04934.
El 4 de diciembre de 2014 se envía las directrices a los Directores de Distritos y
hospitales con copia a todos los Estadísticos mediante circular MSP-CZONAL1-2014-
0012 suscrita por la Dra. Yu Ling Reascos y se dispone el cumplimiento inmediato.
El 11 de marzo de 2015 mediante memorando MSP-CZONAL1-2015-1640-M,
suscrito por la Dra. Yu Ling Reascos, Coordinadora Zonal 1 de Salud se solicita a los
directores de Distritos y Hospitales un reporte del avance del cumplimiento del
mencionado Acuerdo.
El 13 de marzo de 2015 la Dra. Marisol Ruilova Maldonado, Viceministra de Atención
Integral el Salud, mediante memorando MSP-VAIS-2015-0308-M, envía el
“Recordatorio del cumplimiento obligatorio del Acuerdo 04934”.
OBJETIVO: Informar el avance en el cumplimiento de la disposición del uso de un sólo código de
Historia Clínica Única en la Zona 1.
RESULTADOS Luego de realizar el seguimiento en los Distritos y Hospitales de la Zona 1, se
determina que, hasta la presente fecha, se ha cumplido aproximadamente un 51% en
45
el avance del cambio de número de Historia Clínica por el código único (cédula de
ciudadanía).
ACTIVIDADES A CUMPLIR En la Planificación Operativa Anual POA de la Coordinación Zonal 1, está
contemplado realizar seguimiento mediante visitas a las Unidades Operativas de los
Distritos y a Hospitales de la Zona 1 con el fin de verificar el cumplimiento del 100%
en el Acuerdo 04934, además del monitoreo y supervisión de las demás actividades
de Estadística.
Cabe mencionar que de acuerdo a disposición de la Ministra de Salud Pública ha
solicitado la creación del Sigobito 379, en el cual se deberá garantizar el cumplimiento
del acuerdo y se reportará cada 15 días.
No. 0138 Acuerdo del Ministerio De Salud Pública
Art. 1.- Aprobar y publicar los formularios básicos actualizados de la historia clínica
única de acuerdo a la numeración y nomenclatura establecida. Art. 2.- Los números y nombres de los formularios básicos de la historia clínica única
serán los siguientes:
001 ADMISIÓN Y ALTA
002 CONSULTA EXTERNA ANAMNESIS Y EXAMEN FÍSICO
003 ANAMNESIS Y EXAMEN FÍSICO
005 EVOLUCIÓN Y PRESCRIPCIONES
006 EPICRISIS
007 INTERCONSULTA
008 EMERGENCIA
010 LABORATORIO CLÍNICO
012 IMAGENOLOGÍA
013 HISTOPATOLOGÍA
020 SIGNOS VITALES
46
021 ADMINISTRACIÓN DE MÉDICAMENTOS
024 AUTORIDADES Y CONSENTIMIENTO INFORMADO
033 ODONTOLOGÍA
038 TRABAJO SOCIAL
053 REFERENCIA Y CONTRAREFERENCIA
054 CONCENTRADO DE LABORATORIO
055 CONCENTRADO DE LABORATORIO
Art. 3.- Serán parte complementaria de la Historia Clínica Única los siguientes
instrumentos:
ANEXO – 1 FICHA FAMILIAR
ANEXO – 2 ATENCIÓN PRE – HOSPITALARIA
MANUAL DE USO
Art. 4.- Disponer a todos los establecimientos de salud públicos y privados a nivel
nacional la inmediata aplicación de los formularios básicos actualizados y anexos.
Art. 5.- El Consejo Nacional de Salud (CONASA) concertará con todas las entidades
del Sistema Nacional de Salud, la difusión y aplicación obligatoria de los formularios
y anexos señalados en el presente Acuerdo. (Chang Campos, 2008).
Decreto N.1014 Software Libre en Ecuador
Art. 1: Establecer como política pública para las entidades de Administración Pública
Central la utilización del Software Libre en sus sistemas y equipamientos informáticos.
Art. 2: Se entiende por software libre, a los programas de computación que se pueden
utilizar y distribuir sin restricción alguna, que permitan el acceso a los códigos fuentes
y que sus aplicaciones puedan ser mejoradas.
47
Estos programas de computación tienen las siguientes libertades:
Utilización de programa con cualquier propósito de uso común.
Distribución de copias sin restricción alguna
Estudio y modificación de programa (Requisito: código fuente disponible)
Publicación del programa mejorado (Requisito: código fuente disponible)
Art. 3: Las entidades de la administración pública central previa a la instalación del
software libre en sus equipos, deberán verificar la existencia de capacidad técnica
que brinde el soporte necesario para este tipo de software.
Art. 4: Se faculta la utilización de software propietario (no libre) únicamente cuando
no exista una solución de software libre que supla las necesidades requeridas, o
cuando esté en riesgo de seguridad nacional, o cuando el proyecto informático se
encuentre en un punto de no retorno.
Al evaluar el decreto se define que el desarrollo del proyecto no infringe ninguna de
las cláusulas antes mencionadas, y que se encuentra dentro del margen de la ley ya
que el desarrollo del mismo se lo realizó en base a los conocimientos adquiridos
durante el ciclo de estudio dentro de la Carrera profesional y usando herramientas
open source.
El proyecto es factible, se respalda en la Ley de la propiedad intelectual de la
Legislación Nacional de Ecuador en el Art. 8 y Art 9 del Objeto del derecho del Autor,
al evaluar esta ley se define que el proyecto no incurre en ninguna falta con el derecho
de autor ya que todas las ideas, conocimientos y experiencias tomadas de libros,
artículos científicos, han sido debidamente mencionados como lo establece las
normas APA 6ta edición y las leyes vigentes. (Rafael Correa Delgado, 2008)
48
Ley Orgánica de la Salud
Art.2.- Todos los integrantes del Sistema Nacional de Salud para la ejecución de las
actividades relacionadas con la salud, se sujetarán a las disposiciones de esta Ley,
sus reglamentos y las normas establecidas por la autoridad sanitaria nacional.
Art. 3.- La salud es el completo estado de bienestar físico, mental y social y no solamente la
ausencia de afecciones o enfermedades. Es un derecho humano inalienable,
indivisible, irrenunciable e intransigible, ¿cuya protección y garantía es
responsabilidad primordial del Estado; y, el resultado de un proceso colectivo de
interacción donde Estado, sociedad, familia e individuos convergen para la
construcción de ambientes, entornos y estilos de vida saludables.
Investigación Científica en Salud, Genética y Sistema de Información en Salud
Art. 207.
La investigación científica en salud, así como el uso y desarrollo de la biotecnología,
se realizará orientada a las prioridades y necesidades nacionales, con sujeción a
principios bioéticos, con enfoques pluricultural, de derechos y de género,
incorporando las medicinas tradicionales y alternativas.
Art 208.
La investigación científica tecnológica en salud será regulada y controlada por la
autoridad sanitaria nacional, en coordinación con los organismos competentes, con
sujeción a principios bioéticos y de derechos, previo consentimiento informado y por
escrito, respetando la confidencialidad.
49
Art. 360. El sistema garantizará, a través de las instituciones que lo conforman, la promoción
de la salud, prevención y atención integral, familiar y comunitaria; con base en la
atención primaria de salud; articulará los diferentes niveles de atención; y promoverá
la complementariedad con las medicinas ancestrales y alternativas.
La red pública integral de salud será parte del sistema nacional de salud y estará
conformada por el conjunto articulado de establecimientos estatales, de la seguridad
social y con otros proveedores que pertenecen al Estado, con vínculos jurídicos,
operativos y de complementariedad.
Art. 362. La atención de salud como servicio público se prestará a través de las entidades
estatales, privadas, autónomas, comunitarias y aquellas que ejerzan las medicinas
ancestrales alternativas y complementarias. Los servicios de salud serán seguros, de
calidad y calidez, y garantizarán el consentimiento informado, el acceso a la
información y la confidencialidad de la información de los pacientes.
Los servicios públicos estatales de salud serán universales y gratuitos en todos los
niveles de atención y comprenderán los procedimientos de diagnóstico, tratamiento,
medicamentos y rehabilitación necesarios.
Ciencia, Tecnología, Innovación y Saberes Ancestrales
Art. 386. El sistema comprenderá programas, políticas, recursos, acciones, e incorporará a
instituciones del Estado, Universidades Y Escuelas Politécnicas, Institutos de
investigación públicos y particulares, empresas públicas y privadas, organismos no
gubernamentales y personas naturales o jurídicas, en tanto realizan actividades de
50
investigación, desarrollo tecnológico innovación y aquellas ligadas a los saberes
ancestrales.
El estado, a través de organismo competente, coordinará el sistema, establecerá los
objetivos y políticas, de conformidad con el Plan Nacional de Desarrollo, con la
participación de los actores que lo conforman.
Pregunta de Investigación ¿Por qué debemos desarrollar un arquetipo que nos guie hacia la interoperabilidad
de la HCE y qué beneficios podrían obtener los usuarios utilizando la norma ISO
13606 en los sistemas informáticos médicos en el país?
Variables de la investigación
Variable independiente:
Aplicar arquetipos basados en la norma ISO13606.
Variable dependiente:
VI1: Interoperabilidad del Sistema de hospitalarios.
VI2: desarrollo del formulario 033-ODONTOLOGIA del Ministerio de Salud Pública.
Pregunta científica a contestarse
¿Cómo incide la Implementación la Historia Clínica Electrónica del Formulario 033-
Odontología del MSP utilizando arquetipos en el diseño y representación de los
datos?
¿Cómo influye analizar la norma ISO 13606 y levantar línea base para la creación de
arquetipos con profesionales médicos en función al Formulario 033-Odontología?
¿Cuál es el impacto si se desarrolla el arquetipo para la estructura y recuperación de datos?
51
Definiciones conceptuales Administración de la ingeniería de sistemas: Una herramienta que debe cumplir
una serie de requisitos, tanto genéricos como específicos del ámbito (geográfico y
funcional) al que va dirigida. Los esfuerzos de la administración deben enfocarse
sobre aquellos aspectos en que se detectan mayores carencias, no deben emplearse
en re implementar soluciones existentes y satisfactorias.
Análisis de factibilidad: En general los análisis de factibilidad, se completan durante
la fase de diseño de sistemas, en general durante la consideración de la evaluación
de las diferentes alternativas de solución propuestas. Los estudios de factibilidad
consideran la factibilidad técnica, económica y operacional de cada alternativa, así
como si el proyecto es o no apropiado dados los factores políticos y otros del contexto
institucional.
Arquetipo: Un arquetipo es el primer modelo de alguna cosa. El concepto, en este
sentido, puede vincularse a un prototipo como el molde original en que se produce
por primera vez un objeto. Los arquetipos son patrones de los cuales derivan otros
elementos o ideas. Puede tratarse de algo físico o simbólico, siempre capaces de
generar algo más a partir de sí mismos.
Big data: en términos generales podríamos referirnos como a la tendencia en el
avance de la tecnología que ha abierto las puertas hacia un nuevo enfoque de
entendimiento y toma de decisiones, la cual es utilizada para describir enormes
cantidades de datos que tomaría demasiado tiempo y sería muy costoso cargarlos a
un base de datos relacional para su análisis. De tal manera que, el concepto de Big
Data aplica para toda aquella información que no puede ser procesada o analizada
utilizando procesos o herramientas tradicionales. Sin embargo, Big Data no se refiere
a alguna cantidad en específico, ya que es usualmente utilizado cuando se habla en
términos de petabytes y exabytes de datos. (IBM, 2012)
52
Términos de capacidad:
Gigabyte = 109 = 1,000,000,000
Terabyte = 1012 = 1,000,000,000,000
Petabyte = 1015 = 1,000,000,000,000,000
Exabyte = 1018 = 1,000,000,000,000,000,000
Buckup: Se trata de una copia de seguridad, recomendable hacerla de vez en
cuando, puesto que en muchas ocasiones se produce un fallo o avería del disco duro
en el que depositamos nuestro material. (www.abc.es, s.f.)
Costo y efectividad del sistema: Es una técnica importante dentro del ámbito de la
teoría de la decisión. Pretende determinar la conveniencia de proyecto mediante la
enumeración y valoración posterior en términos monetarios de todos los costos y
beneficios derivados directa e indirectamente de dicho proyecto. Este método se
aplica a obras sociales, proyectos colectivos o individuales, empresas privadas,
planes de negocios, etc., prestando atención a la importancia y cuantificación de sus
consecuencias sociales y/o económicas.
Creación de un sistema: Es el proceso de elaborar reglas que realicen una función
en específico. El diseño de un sistema de información produce los elementos que
establecen cómo el sistema cumplirá los requerimientos identificados durante el
análisis del sistema. A esta etapa se le conoce también con el nombre de Diseño
Lógico.
DataSource: Una fuente de datos representa una base de datos del mundo real,
como puede ser una base de datos relacional Oracle.
Cuando registramos una fuente de datos en el servicio de nombres JNDI (Java Name
Directory Interface), cualquier aplicación puede recuperar la fuente de datos desde el
servicio de nombres y utilizarla para realizar una conexión a la base de datos que
representa.
Al usar fuentes de datos, las aplicaciones no necesitan tener información específica
como el nombre de la base de datos, el ID del usuario, o la clave para obtener una
53
conexión a BD. Toda esta información se almacena en forma de propiedades en el
objeto DataSource. Esto hace que la aplicación sea más portable porque no es
necesario escribir en el código el nombre del driver, lo cual frecuentemente implica
incluir el nombre de un fabricante en particular. (Amarilla, 2004).
Framework: Es un ambiente para desarrolladores que dependiendo de la integración
de componentes o lenguajes que se utilicen se facilita la programación de
aplicaciones como soportes y ayudas, bibliotecas virtuales, plantillas y más. HCE: La Historia Clínica Electrónica (HCE), también llamada historia de salud
electrónica, es el conjunto global y estructurado de información relacionado con los
procesos asistenciales de un paciente, soportado por una plataforma informática. El
sistema permite el almacenamiento y la recuperación de información
asistencial basado en procedimientos digitales, diseñado para facilitar el
seguimiento de las acciones, anotaciones e instrucciones sobre las actuaciones en
materia de salud de los ciudadanos.(Definición de HCE, s. f.). Hibernate: Es una capa de persistencia objeto/relacional y un generador de
sentencias sql. Te permite diseñar objetos persistentes que podrán incluir
polimorfismo, relaciones, colecciones, y un gran número de tipos de datos. De una
manera muy rápida y optimizada podremos generar BBDD en cualquiera de los
entornos soportados: Oracle, DB2, MySql, etc.. Y lo más importante de todo, es open
source, lo que supone, entre otras cosas, que no tenemos que pagar nada por
adquirirlo. (González, 2003).
HTML5: es un lenguaje markup (de hecho, las siglas de HTML significan Hyper Text
Markup Language) usado para estructurar y presentar el contenido para la web. Es
uno de los aspectos fundamentales para el funcionamiento de los sitios, pero no es
el primero. Es de hecho la quinta revisión del estándar que fue creado en 1990. A
fines del año pasado, la W3C la recomendó para transformarse en el estándar a ser
usado en el desarrollo de proyectos venideros. Por así decirlo, qué es HTML5 está
relacionado también con la entrada en decadencia del viejo estándar HTML 4, que se
54
combinaba con otros lenguajes para producir los sitios que podemos ver hoy en día.
Con HTML5, tenemos otras posibilidades para explotar usando menos recursos. Con
HTML5, también entra en desuso el formato XHTML, dado que ya no sería necesaria
su implementación. (Hunt, s.f.).
Impedancia: más conocido a nivel mundial Impedance Mismatch, consiste en el
problema o falta de concordancia objeto-relacional, esto consiste en un grupo de
dificultades y problemas técnico-conceptuales a los que s enfrentan los diseñadores
de bases de datos y los programadores. Estos problemas son generalmente la
incompatibilidad de tipos de datos entre los tipos de datos de las bases de datos y los
tipos de datos del lenguaje de programación que se utilice en determinado momento.
(http://repositorio.utn.edu.ec, 2016)
Interoperabilidad: Podemos decir que interoperabilidad son los procesos,
tecnologías y protocolos requeridos para asegurar la integridad de los datos cuando
se transfieren de un sistema a otro. ISO 13606: Especifica la comunicación de parte o la totalidad de la historia clínica
electrónica (HCE) de un solo sujeto identificado de la atención sistemas a Historia
Clínica Electrónica (ISO, 2008).
Java EE (Java Enterprise Edition): Es un entorno independiente de la plataforma
centrado en Java para desarrollar, crear e implementar en línea aplicaciones
empresariales basadas en web. Java EE incluye muchos componentes de Java
Standard Edition (Java SE). La plataforma Java EE consta de un conjunto de
servicios, API y protocolos que proporcionan la funcionalidad necesaria para
desarrollar aplicaciones basadas en web de varios niveles.
Java EE simplifica el desarrollo de aplicaciones y reduce la necesidad de
programación y formación para programadores al crear componentes modulares
55
normalizados y reutilizables, así como al permitir controlar muchos aspectos de la
programación automáticamente por nivel.
Si es un desarrollador empresarial, necesita Java EE. Los desarrolladores
empresariales necesitan Java EE porque crear aplicaciones empresariales
distribuidas no es sencillo, y necesitan una solución de alta productividad que les
permita centrarse únicamente en escribir su lógica empresarial y disponer de una
gama completa de servicios de clase empresarial en la que confiar, como objetos
distribuidos transaccionales, orientado a mensajes y servicios de directorio y
asignación de nombres. (Java, 2014).
MVCC: es una técnica de concurrencia optimista en donde ninguna tarea o hilo es
bloqueado mientras se realiza una operación en la tabla, porque el otro hilo usa su
propia copia (versión) del objeto dentro de una transacción.
Si bien obviamente la implementación interna de este algoritmo es distinta en cada
motor de bases de datos, a grandes rasgos se podría decir que el MVCC internamente
lo que hace es identificar cada transacción con un numero univoco y a cada registro
de la tabla, con un numero de versión. Entonces, cada transacción trabaja con su
copia y si se modifica un registro de una tabla, el contador de versión del registro se
incrementa. Si 2 transacciones modificaron la misma tabla, se hace un merge de
ambas tablas combinando las últimas versiones de cada registro. Si las 2
transacciones, modificaron exactamente el mismo registro, entonces en ese caso,
cuando se de commit (palabra reservada que su función es guardar o actualizar
cambios), el registro que finalmente queda, corresponde a la última transacción en
realizar una modificación sobre ese registro.
(https://grimpidev.wordpress.com/2011/02/08/control-de-concurrencia-multiversion-
mvcc/, s.f.)
MERGE: se pueden realizar operaciones de inserción, actualización o eliminación en
una sola instrucción utilizando la instrucción MERGE. La instrucción MERGE le
permite combinar un origen de datos con una tabla o vista de destino y, a
56
continuación, realizar varias acciones con el destino según los resultados de esa
combinación. Por ejemplo, puede utilizar la instrucción MERGE para realizar las
operaciones siguientes:
Condicionalmente insertar o actualizar filas en una tabla de destino.
Si la fila existe en la tabla de destino, actualizar una o varias columnas; de lo contrario, insertar los datos en una fila nueva.
Sincronizar dos tablas.
Insertar, actualizar o eliminar filas en una tabla de destino según las diferencias con los datos de origen. (Microsoft, 2008).
Open source: Son software de licencia libre con características y funcionalidades
básicas que son totalmente gratis para los usuarios. Hay quienes piensa que cuando
las empresas dan probar productos por un periodo corto de tiempo tipo 30 días no
significa que es open source es simplemente un demo del producto para que puedan
usar todas sus características y enfaticen más.
POJO (acrónimo de Plain Old Java Object): es una sigla creada por Martin
Fowler, Rebecca Parsons y Josh MacKenzie en septiembre de 2000 y utilizada por
programadores Java para enfatizar el uso de clases simples y que no dependen de
unframework en especial. Este acrónimo surge como una reacción en el mundo Java
a los frameworks cada vez más complejos, y que requieren un complicado andamiaje
que esconde el problema que realmente se está modelando. En particular surge en
oposición al modelo planteado por los estándares EJB anteriores al 3.0, en los que
los "Enterprise JavaBeans" debían implementar interfaces especiales.
Es una nueva palabra para designar algo viejo, tan viejo como una tarjeta perforada.
No existe en Java una nueva tecnología con ese nombre, sino que el nombre existe
en el marco de una revalorización de la programación "simplemente orientada a
objetos". (Martin , Rebecca, & Josh, 2000)
57
Plugins: En términos generales se denomina plug-in (o add- on) a cualquier
componente que añade o modifica la funcionabilidad de una aplicación principal
integrándose con ella mediante un API proporcionando un ex profeso. Los Plugins
son un mecanismo que se emplea habitualmente cuando se desea que
programadores ajenos al desarrollo del proyecto matriz puedan integrarse con la
aplicación. (Francisco Moya).
Tecnología stack (pila tecnológica): Un conjunto de software que proporciona la
infraestructura para un ordenador. Las pilas difieren ya sea instalado en un cliente o
un servidor.
Clientes - OS y las utilidades relacionadas La pila de la tecnología en una
máquina cliente incluye el sistema operativo y los programas de apoyo
relacionados y todos los entornos de ejecución necesarias para soportar las
aplicaciones, tales como Java (ver Java Virtual máquina ).La pila puede incluir
las aplicaciones, a pesar de que generalmente se considera una separada
"pila de aplicaciones." La palabra "tecnología" incluye el software del sistema,
no el software de aplicación.
Servidores Emplear Servicios: Para los servidores, la pila incluye todos los
programas mencionados para los clientes con la adición de software de base
de datos y soporte para varios lenguajes de programación. Si basado en la
Web, ya sea pública o privada, se incluye una variedad de software de
servidor, como servidor web, servidor de correo, servidor FTP y otro software
de “servicios”.
(Copyright © 1981- 2016 El Lenguaje de ordenadores Company, 2016)
58
CAPÍTULO III
PROPUESTA TECNOLÓGICA
La propuesta de este proyecto de titulación es el Desarrollo del formulario 033-
odontología del Ministerio de Salud Pública aplicando arquetipos basados en la norma
ISO 13606 para la interoperabilidad de los sistemas hospitalarios. Con la elaboración
de este proyecto se pretende automatizar el formulario 033 de odontología del MSP,
los procesos de comunicación entre médicos, funcionarios y pacientes, ofreciéndoles
una herramienta informática, para optimizar el tiempo de atención, llevar un control
en la gestión de las operaciones, con un registro de las actividades realizadas por
los odontólogos.
A continuación, detallamos las factibilidades del proyecto.
Análisis de factibilidad
En análisis de factibilidad se realizará un análisis operacional, técnico, legal y
económico, teniendo en cuenta los recursos e información disponibles y además se
identifican las posibilidades de éxito que tendrá el desarrollo del presente proyecto ya
que en la actualidad existen necesidades o requerimientos solicitados por los
especialistas en el área de odontología como es el formulario 033 electrónico con el
odontograma incluido en el sistema de información médico.
59
Factibilidad Operacional
El desarrollo del proyecto no se necesita contratar recurso humano perito en la
materia de medicina en la especialidad de odontología, debido a que la elaboración y
ejecución del mismo se dará de manera personalizada por parte de los integrantes
del proyecto de titulación, y el equipo de desarrollo de eSalud.
El desarrollo de una historia clínica electrónica de odontología es de gran aporte en
la sociedad, especialmente a los funcionarios que laboran en las organizaciones
médicas, odontólogos y pacientes ya que unifica las áreas de la salud-tecnología en
el aspecto de medicina preventiva y correctiva. El desarrollo de este proyecto de
titulación cuenta con el apoyo de la Universidad Estatal de Guayaquil, Facultad de
Ciencias Médicas, Facultad de Matemáticas y Físicas, Carrera de Ingeniería en
Sistemas Computacionales, la Facultad de Odontología y Dirección Investigación
Proyectos Académicos (DIPA) además las autoridades encargadas del mismo.
Es factible operativamente porque se han considerado tanto las opiniones de
usuarios, médicos, odontólogos y pacientes, como requerimiento o necesidad
implícita para el proyecto, logrando así obtener un producto alineado con los objetivos
que se persiguen, además es factible porque mejora la gestión de los procesos
internos de monitoreo y seguimiento.
Debido a la importancia que tiene para el grupo eSalud contar con una herramienta
que automatice el ingreso de la información de cada paciente en el Formulario 033
odontología; considerando dicha importancia y basándose en los objetivos de una
mejora continua y optimización de recursos en la realización de los procesos, las
autoridades encargadas del proyecto brindarán todo el apoyo necesario para el
desarrollo del presente proyecto.
Es factible ya que se han tomado en cuenta, para la realización del mismo, las
opiniones tanto de los usuarios que han manejado procesos similares como de los
60
que van a manejar el proceso que se lleva a cabo actualmente y conscientes de la
necesidad de un cambio aportarán con sus comentarios y sugerencias logrando así
un producto que se alinee con los objetivos del departamento y además es factible
porque cumple con el formato de formularios básicos N° 033 de odontología del MSP.
Además, podemos indicar que todos los rubros que se deben cancelar por concepto
de contratación de galenos en la especialidad de odontología, director, líder analistas
coordinadores, desarrolladores y demás recursos humanos no se toman en cuenta,
pero si se los deben contemplar para futuras implementaciones si fuera necesario.
Factibilidad Técnica
Los funcionarios de turno encargados del Proyecto eSalud cuentan con los recursos
necesarios y se desarrolla bajo los mínimos requerimientos a lo que corresponde
hardware y software. Es factible en el aspecto técnico porque las herramientas de
software que se desarrolla son libre Open Source, las cuales detallamos a
continuación:
Cuadro N. 3 Herramientas de desarrollo
Tipo de Software Nombre Software Sistema Operativo Windows 8.1 Gestor de Base de datos PostgreSQL
PGADMIN III Lenguaje de Programación Java Servidor de Aplicaciones Wildfly 10.0 Spring
HIBERNATE Eclipse Neon
Elaborado Por: Jorge Andrés Romero Franco
Fuente: Datos de la investigación
61
También se cuenta con las siguientes herramientas de hardware necesarias para
desarrollar del proyecto:
Cuadro N. 4 Características de hardware
Equipo Características Técnicas
Laptop
Marcar: HP Procesador: Intel Core i7 2.60 GHz. Memoria RAM: 8Gb Disco Duro: 1000Gb Sistema Operativo: Windows 7
Elaborado Por: Jorge Andrés Romero Franco
Fuente: Datos de la investigación
Factibilidad Legal
El desarrollo de este proyecto se respalda netamente en el decreto N. 1014 el día
jueves 10 de abril del 2008 en donde se emitió por parte del Presidente de la
Republica de Ecuador Ec. Rafael Correa Delgado, el uso de software libre en la
Instituciones Públicas del Ecuador.
Decreto N.1014 Software Libre en Ecuador Art. 1: Establecer como política pública para las entidades de Administración Pública
Central la utilización del Software Libre en sus sistemas y equipamientos informáticos.
Art. 2: Se entiende por software libre, a los programas de computación que se pueden
utilizar y distribuir sin restricción alguna, que permitan el acceso a los códigos fuentes
y que sus aplicaciones puedan ser mejoradas.
Estos programas de computación tienen las siguientes libertades:
62
Utilización de programas con cualquier propósito de uso común.
Distribución de copias sin restricción alguna
Estudio y modificación de los programas (Requisito: código fuente
disponible)
Publicación del programa mejorado (Requisito: código fuente disponible)
Art. 3: Las entidades de la administración pública central previa a la instalación del
software libre en sus equipos, deberán verificar la existencia de capacidad técnica
que brinde el soporte necesario para este tipo de software.
Art. 4: Se faculta la utilización de software propietario (no libre) únicamente cuando
no exista una solución de software libre que supla las necesidades requeridas, o
cuando esté en riesgo de seguridad nacional, o cuando el proyecto informático se
encuentre en un punto de no retorno.
Al evaluar el decreto se define que el desarrollo del proyecto no infringe ninguna de
las clausulas antes mencionadas, y que se encuentra dentro del margen de la ley ya
que el desarrollo del mismo se lo realizó en base a los conocimientos adquiridos
durante el ciclo de estudio dentro de la carrera profesional y usando herramientas
open source.
El proyecto es factible, se respalda en la Ley de la propiedad intelectual de la
Legislación Nacional de Ecuador en el Art. 8 y Art 9 del Objeto del derecho de Autor,
al evaluar esta ley se define que el proyecto no incurre en ninguna falta con el derecho
de autor ya que todas las ideas, conocimientos y experiencias tomadas de libros,
artículos científicos, han sido debidamente mencionados como lo establecen las
normas APA 6ta edición y las leyes vigentes.
Según los estatus, normas y reglamentos con respecto a la propiedad intelectual, este
proyecto no infringe en ninguna forma posible lo establecido en la misma, debido a
que se desarrolla en base a lo aprendido a lo largo de la carrera profesional y
63
desarrollada de forma personalizada. De la misma forma no incurre en falta alguna
con el derecho de autor ya que todas las ideas, conocimientos y experiencias tomadas
de libros, folletos, revistas científicas entre otros, han sido debidamente mencionados
como lo establece las normas APA 6ta edición y las leyes vigentes.
El software y herramientas utilizados en el presente proyecto de titulación son de uso
libre (open source) como lo dispuso el Presidente de la República del Ecuador Ec.
Rafael Correa Delgado en el decreto N° 1014 Articulo 1, esto nos garantiza el
completo y absoluto cumplimento dentro del margen de la ley.
Factibilidad Económica
Este proyecto es factible económicamente debido a que la infraestructura, hardware
y Software de la Universidad de Guayaquil está a disposición del DIPA y que las
autoridades a cargo del Proyecto eSalud nos proveen, no es necesario adquirir
herramientas de hardware ni realizar algún gasto económico para el desarrollo del
proyecto.
Todas las herramientas usadas para la elaboración y ejecución del proyecto son open
source los cuales no necesitan de licencia, lo que reduce costos que se deben incurrir
en el desarrollo de aplicaciones de software en condiciones normales.
Se considera como costos adquiridos por los integrantes del proyecto para la
elaboración, que se detalla a continuación:
64
Cuadro N. 5 Detalle del costo del proyecto
RUBROS FUENTES
ESTUDIANTES OTROS
Recursos Humanos $3200
Recursos Hardware $1000
Recursos Software $0
Viajes y Salidas de campo $50
Recursos Varios $50
Servicios básico e internet $400
Suministritos de oficina $100
Total de la inversión 4800
Elaborado Por: Roberto Carlos González León. Fuente: Vías de la investigación.
La tabla anterior muestra que la inversión por parte de los estudiantes a realizar en el
proyecto, es de $ 4800, pero no está contemplado el costo del recurso humano que
interviene en este proyecto de titulación como es el de Director, analistas, revisores,
coordinadores y docentes tutores. Se puede verificar que el proyecto es el desarrollo
de la Historia Clínica Electrónica y la automatización del formulario básico 033 de
odontología del Ministerio de Salud Pública del Ecuador es factible económicamente;
ya que el costo es mínimo a consideración de los beneficios que proporcionará para
la sociedad ecuatoriana.
65
Etapas de la metodología del proyecto
Luego de haber investigado cómo sería el desarrollo del proyecto; se escogió la
metodología del modelo cascado, debido a que se necesita llevar fases tanto de
análisis como de diseño las cuales se detallan de la siguiente manera: Análisis y definición de requerimiento: Se analizaron los requerimientos a través de entrevistas con los profesionales en el
área de odontología, para ver cuál es el enfoque y el alcance que deben tener para
la creación y el desarrollo del Historial clínico electrónico para los pacientes de
acuerdo a los Formularios ya existentes del Ministerio de Salud Pública y poder aplicar
la norma ISO 13606 para poder obtener la Interoperabilidad de los sistemas.
Análisis de los requisitos del software: Los requisitos del software fueron explicados en reuniones realizadas a lo largo del
desarrollo del proyecto con médicos de todas las especialidades que laboran en
Instituciones Públicas, se determinó que existe un alto nivel de datos almacenados
en el proceso de ingreso de la historia clínica del paciente por lo que se requiere un
software con buen rendimiento y altos niveles de transaccionalidad para mejorar la
calidad de atención a los pacientes y mejorar de los procesos actuales.
Diseño:
Para seleccionar el diseño que va hacer implementado en el proyecto, se realizaron
investigaciones sobre estudios científicos de otros países basados a la aplicación de
la norma ISO 13606 en sistemas médicos. Entre las opciones analizadas se optó por
la arquitectura del framework J2EE, el cual se acopla más a las necesidades y
requerimiento que implica la funcionalidad y operatividad del sistema medico
propuesto, el esquema mencionado se divide en cuatro capas, entre las que tenemos:
Capa de Presentación Hace referencia a la capa que permite la interacción entre el sistema y el
usuario final, gestiona la visualización de los datos y a su vez ayuda a
66
recolectarla para hacer utilizada en los servicios exhibidos por la capa de
servicio, con el propósito de satisfacer los casos de uso de la aplicación, para
el presente caso el sistema clínico.
Capa de Servicio Contiene la lógica de la aplicación, en forma de transacciones de negocio,
están serian ingresar, almacenara y visualizar. Gestiona como los datos son
obtenidos desde la capa de presentación, esta información debe ser
modificada o transformada acorde al problema o acción que se tenga que dar
solución.
Capa de Persistencia
Esta capa maneja la abstracción y resolución del acceso a los datos por medio
de un motor de base de datos relacional, para esta parte de iteración dentro
del proyecto se utilizó el aplicativo PostgreSQL como gestor de datos. El
propósito de la capa es ser la única que identifique como es la permanencia
de los objetos de dominio de la aplicación y como recuperarlos abstrayendo la
intersección de impedancias entre objetos y tablas relacionales.
Capa de Modelo del Dominio Contiene las diferentes clases que modelan el dominio, como son entidades,
relaciones y las restricciones de negocios que mantienen. La capa de
persistencia identifica al dominio, conoce cómo poder recuperar y almacenar
objetos de dominio.
Codificación: Se maneja un modo de programación basado en esquemas estandarizados y otros
tomados como guías de un grupo sistemas o plataforma existentes, entre estos
controles tenemos: llevar un formato de indentación en las líneas de código
67
principales del proyecto por cada objeto creado, es decir llevar un codificación con su
respectivo comentario que permita referencia la funcionalidad de ellas, seguir una
estructura de desarrollo acorde, claro y entendible para otras personas que en su
momento intervengan en las fuentes, y se orienten sobre la operatividad del sistema
propuesto. Las clases capa que pertenecen al modelo del dominio que fueron
generadas directamente con una conexión a la base PostgreSQL.
Prueba:
Involucra la realización de pruebas internas del software en conjunto con el director
del proyecto y los usuarios perteneciente al área de odontología. Se utilizó como
herramienta de verificación y validación un documento de plan de pruebas, el cual
comprende todos los posibles escenarios de caso de uso del sistema y a su vez este
servirá como medio principal de aceptación de entrega de un proyecto de calidad
entre los involucrados. Funcionamiento y mantenimiento: El desarrollo se va llevar de tal manera que si surge algún requerimiento o cambio no
contemplado, el cual es solicitado por los especialistas en odontología se puedan
realizar y no afecten la continuidad del proceso, esto se da gracias a distribución que
se ha manejado para el desarrollo del sistema.
Levantar información correspondiente al formulario 033 odontología.
El formulario 033 de odontología es uno de los 20 formularios básicos del MSP
aprobados en la norma ISO 13606, consta de varios campos donde se registra la
información relevante del paciente. Para facilitar el análisis en el desarrollo del
proyecto de los registros se lo dividirá en 2 composiciones:
1. Anverso
2. Reverso
68
Gráfico N. 7 Anverso del formulario 033 de odontología
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
PRESIÓN ARTERIAL
VESTIBULAR
U
r
MODERADA
E NFE RM E DAD P E RIODONT AL
( - - - - - - - )
65 9
o TOTAL
SEVERAd
0 - 1MODERADA
1716 55
0 - 1 - 2 - 3 - 9
SEVERA
ANGLE II0 - 1 - 2 - 3
51ANGLE III
SIMBOLOGÍA DEL ODONTOGRAMA75
26 27
36 37
46 47
31 41 71
11 21
85
SNS-MSP / HCU-form.033/ 2008 ODONTOLOGÍA (1)
azul SELLANTE REALIZADO ENDODONCIA CORONA
T OT ALE S
ESTABLECIMIENTO NOMBRE APELLIDO
DESCRIBIR ABAJO LA PATOLOGÍA DE LA REGIÓN AFECTADA ANOTANDO EL NUM ERO
------ PRÓTESIS FIJA
ec
PÉRDIDA (OTRA CAUSA)
SEXO (M- F) EDAD
9. ENF. CARDIACA6. ASMA
Nº HIS T ORIA CLÍNICA
PINTAR CON: AZUL PARA TRATAMIENTO REALIZADO - ROJO PARA PATOLOGÍA ACTUAL MOVILIDAD Y RECESIÓN: MARCAR "X " (1, 2 ó 3), SI APLICA
7 3 7 4
18
8. HIPER TENSIÓN
7. DIABETES
2 4 2 5
6 2
2 8
6 5
3 8
5 1 6 3
SELLANTE NECESARIO
X rojo EXTRACCIÓN INDICADA
PRÓTESIS REMOVIBLE
D
16 1517
RECESIÓN
MOVILIDAD
6. PALADAR 7. PISO
5. TUBER CULOSIS
9. GLÁNDULAS SALIVALES 10. ORO FARINGE 11. A. T. M.
8. CARRILLOS
2 ENFERMEDAD O PROBLEMA ACTUAL
2. MEJILLAS3. MAXILAR SUPERIOR
TEMPERATURA °C
1. LABIOS
PRÓTESIS TOTAL
CARIES
OBTURADO
6 1
rojo
azul
12 11
X azul PÉRDIDA POR CARIES
rojo
8 1
14 13
O TOTALPC
ANGLE ICÁLCULO
HIGIE NE ORAL S IM P LIFICADA
PIEZAS DENTALES
7 INDICADORES DE SALUD BUCAL
PLACA LEVE
FLUOROS ISM AL OCLUS IÓN
LEVEGINGIVITIS
RECESIÓN
4 24 8 4 7 4 5
MOVILIDAD
8 38 5 8 4 8 3
4 6 4 4 4 3
5 4 5 3 5 2
ODONTOGRAMA
FRECUENCIA CARDIACA min.
5 - 9 AÑOS PROGRAMADO
3 73 6
7 57 2
6
7 1
8
3 3
LINGUAL
3 1 3 43 24 1
5 5
VESTIBULAR
EXAMEN DEL SISTEMA ESTOMATOGNÁTICO54. MAXILAR
INFERIOR
12. GANGLIOS
5. LENGUA
4F. RESPIRAT.
min.
1. ALERGIA ANTIBIÓTICO
SIGNOS VITALES
10. OTRO2. ALERGIA ANESTESIA
MAYOR DE 20 AÑOS10- 14 AÑOS PROGRAMADO
MENOR DE 1AÑO 1 - 4 AÑOS 5- 14 AÑOS NO PROGRAMADO
EMBARAZADA
2 3
15 - 19 AÑOS
ÍNDICES CPO-ceo
2 1 2 2 2 6 2 7
3 5
6 4
3. HEMO RRAGIAS 4. VIH/SIDA
ANTECEDENTES PERSONALES Y FAMILIARES
1
REGISTRAR SÍNTOM AS: CRONOLOGÍA, LOCALIZACIÓN, CARACTERÍSTICAS, INTENSIDAD, CAUSA APARENTE, SÍNTOM AS ASOCIADOS, EVOLUCIÓN, ESTADO ACTUAL.
MOTIVO DE CONSULTA ANOTAR LA CAUSA DEL PROBLEM A EN LA VERSIÓN DEL INFORM ANTE
3
69
Gráfico N. 8 Reverso de formulario 033 de odontología
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
CÓDIGONUMERO DE HOJA
FECHA DE APERTURA
FECHA DE CONTROL
SESIÓN 9
PROFESIONAL FIRMA
FECHA
CÓDIGO
FIRMA
CÓDIGO
FIRMAFECHA
SESIÓN 7
SESIÓN 4
SESIÓN 6
FECHA
FECHA
SESIÓN 5
4
1 3
CIE PRE DEF DIAGNÓSTICO PRE= PRESUNTIVO DEF= DEFINITIVO CIE PRE DEF
PLANES DE DIAGNÓSTICO, TERAPÉUTICO Y EDUCACIONALBIOMETRIA
QUIMICA SANGUINEA RAYOS - X
10OTROS
SNS-MSP / HCU-form.033 / 2008 ODONTOLOGÍA (2)
FECHA
FIRMAFECHA
SESIÓN CÓDIGO
FIRMA
CÓDIGO
FIRMA
8
FECHA
CÓDIGO
CÓDIGO
CÓDIGO
FIRMA
FIRMA
SESIÓN
FIRMA
SESIÓN 2
3
FECHA
SESIÓN
SESIÓN Y FECHA
2
12
FECHA
PROCEDIMIENTOS
TRATAMIENTO
11
1
DIAGNOS T ICOS Y COM P LICACIONE S
CÓDIGO
CÓDIGO Y FIRM APRESCRIPCIONES
FIRMA
CÓDIGO
70
Analizar registros y campos del formulario 033
La historia clínica electrónica es la automatización del formulario 033 de odontología
del MSP, en el cual debe ser analizados en detalle cada uno de los campos de la
HCE. Para aplicar el diseño de la norma ISO 13606 en la HCE-odontología los
campos y registros se organizarán en secciones y composiciones las cuales se
dividirán en dos partes la primera será la composición 1 el anverso de formulario 033
de odontología y la segunda composición el reverso. El anverso consta del
encabezamiento y 9 secciones.
Encabezamiento En esta sección registraremos las subsecciones que detallamos a continuación:
1. Cabecera que corresponden a datos generales del paciente.
2. Ciclo de vida que corresponde a la edad del paciente
Cabecera La cabecera contiene 6 campos para registrar los datos, deben ser validados y
registrados en los campos asignados en esta sección, como es el nombre de la
institución Médica donde el paciente es atendido, el nombre y apellido del paciente,
el sexo, la edad y el número de HCE. Como indica en el siguiente cuadro:
Gráfico N. 9 Datos Generales
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
ESTABLECIMIENTO NOMBRE APELLIDO SEXO (M- F) EDAD Nº HIST ORIA CLÍNICA
71
Ciclo de vida de la edad del paciente
En esta sección del formulario identificamos o marcamos con una x donde
corresponda la edad del paciente a ser atendido que consta de 7 ciclos: menor de un
año, de 1 a 4 años; de 5 a 9 años programado, de 5 a 14 años no programado; de 10
a 14 años programado; de 15 a 19 año; mayores de 20 años y un campo para
embarazo donde indicamos el estado de gestación o embarazo para tomar las
precauciones debidas antes de ser atendida por el odontólogo.
Gráfico N. 10 Ciclo de vida de la edad del paciente
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
El formulario 033 tiene 9 secciones en la primera parte del anverso las cuales se
detallan a continuación:
Sección 1 Motivo de consulta
En esta sección consta de un solo campo o registro que es de tipo texto en la cual el
usuario de la ficha debe describir la causa que origina la solicitud de consulta, en
palabras textuales del informante.
5 - 9 AÑOS PROGRAMADO
MAYOR DE 20 AÑOS10- 14 AÑOS PROGRAMADO
MENOR DE 1AÑO 1 - 4 AÑOS 5- 14 AÑOS NO PROGRAMADO
EMBARAZADA 15 - 19 AÑOS
72
Gráfico N. 11 Motivo de consulta
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
Sección 2
Enfermedad o problema actual Esta sección del formulario 033 de odontología consta de un solo campo y se registra
únicamente caracteres de tipo texto, en el cual se debe escribir el resultado
organizado del interrogatorio de síntomas sobre el problema odontológico. En otras
palabras, se deben registrar síntomas: cronología, localización, características,
intensidad, causa aparente, síntomas asociados, evolución, estado actual.
Gráfico N. 12 Enfermedad o problema actual
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
1 MOTIVO DE CONSULTA ANOTAR LA CAUSA DEL PROBLEM A EN LA VERSIÓN DEL INFORM ANTE
2 ENFERMEDAD O PROBLEMA ACTUAL REGISTRAR SÍNTOM AS: CRONOLOGÍA, LOCALIZACIÓN, CARACTERÍSTICAS, INTENSIDAD, CAUSA APARENTE, SÍNTOM AS ASOCIADOS, EVOLUCIÓN, ESTADO ACTUAL.
73
Sección 3 Antecedentes personales y familiares
Se debe marcar con “x” en el cuadro amarillo el tipo de antecedente personal que
tiene el paciente, si es familiar indicará que familiar tiene el antecedente hasta tercer
grado consanguinidad y primer grado de afinidad en el campo textual. Observaciones:
Si refiere antecedentes con riesgo se le aconseja una interconsulta médica.
Si el paciente no tiene antecedentes se debe escribir en la parte textual “NO
REFIERE ANTECENDETES FAMILIARES”.
En esta sección del formulario consta de 10 campos o registros:
Cuadro N. 6 Antecedentes personales y familiares
Elaborado Por: Ministerio de Salud Pública del Ecuador
Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
Gráfico N. 13 Antecedentes personales y familiares
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
9. ENF. CARDIACA6. ASMA8. HIPER TENSIÓN
7. DIABETES
5. TUBER CULOSIS
1. ALERGIA ANTIBIÓTICO 10. OTRO
2. ALERGIA ANESTESIA
3. HEMO RRAGIAS 4. VIH/SIDA
ANTECEDENTES PERSONALES Y FAMILIARES3
ANTECEDENTES PERSONALES Y FAMILIARES
1 Alergia antibiótico 2 Alergia anestesia 3 Hemorragias 4 VIH/SIDA 5 Tuberculosis 6 Asma 7 Diabetes 8 Hipertensión 9 Enfermedad Cardiaca
10 Otro
74
Sección 4 SIGNOS VITALES
En esta sección del formulario tenemos 4 campos donde el auxiliar del odontólogo o
la enfermera deberán ingresar y llenar los datos de los siguientes campos:
Cuadro N. 7 Signos vitales
Elaborado Por: Roberto Carlos González León y Jorge Andrés Romero Franco
Fuente: Formulario 033-Odontologia Ministerio de Salud Pública.
Gráfico N. 14 Signos vitales
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
Si el paciente presenta presión arterial, frecuencia cardiaca, temperatura, frecuencia
respiratoria fuera del rango normal en cualquiera de estos cuatro campos termina el
registro y en la sección de tratamiento en parte de prescripción solicitar interconsulta
colocar la patología en la columna diagnóstico y complicaciones.
La toma de signos vitales la realizará el auxiliar del odontólogo en caso de no contar
con el personal lo realizará la enfermera.
Signos vitales 1. Presión Arterial
2. Frecuencia Cardiaca
3. Temperatura
4. Frecuencia Respiratoria
4 SIGNOS VITALES
PRESIÓN
ARTERIAL
FRECUENCIA
CARDIACA min.
TEMPERATURA °C
F.
RESPIRAT.
min.
75
Sección 5
EXAMEN DEL SISTEMA ESTOMATOGNÁTICO
En esta sección consta de doce campos, en las cuales se debe marcar “x”
solamente si existe patología y describir en la parte inferior en el campo textual.
Cuadro N. 8 Patologías
PATOLOGÍAS 1 LABIOS 2 MEJILLAS 3 MAXILAR SUPERIOR 4 MAXILAR INFERIOR 5 LENGUA 6 PALADAR 7 PISO 8 CARRILLOS 9 GLÁNDULAS SALIVALES
10 ORO FARINGE 11 ARTICULACIÓN TEMPOROMANDIBULAR 12 GANGLIOS
Elaborado Por: Roberto Carlos González León y Jorge Andrés Romero Franco
Fuente: Datos de investigación.
76
Gráfico N. 15 Examen del Sistema Estomatognático
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
Sección 6
Odontograma En esta sección del formulario tiene como objetivo llevar un control del estado actual
de las piezas dentales del paciente, se encuentran dividas en 32 campos de piezas
dentales además 64 campos para recesión (32) y movilidad (32) y 20 piezas dentales
temporales denominadas dientes de leche de la siguiente manera:
DESCRIBIR ABAJO LA PATOLOGÍA DE LA REGIÓN AFECTADA ANOTANDO EL NUM ERO
6. PALADAR 7. PISO
9. GLÁNDULAS SALIVALES 10. ORO FARINGE 11. A. T. M.
8. CARRILLOS2. MEJILLAS3. MAXILAR SUPERIOR1. LABIOS
EXAMEN DEL SISTEMA ESTOMATOGNÁTICO54. MAXILAR
INFERIOR
12. GANGLIOS
5. LENGUA
77
Cuadro N. 9 Información de las piezas dentales
Elaborado Por: Roberto Carlos González León y Jorge Andrés Romero Franco Fuente: Datos de investigación.
Gráfico N. 16 Odontograma
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
VESTIBULAR
PINTAR CON: AZUL PARA TRATAMIENTO REALIZADO - ROJO PARA PATOLOGÍA ACTUAL MOVILIDAD Y RECESIÓN: MARCAR "X " (1, 2 ó 3), SI APLICA
7 3 7 4
18 2 4 2 5
6 2
2 8
6 5
3 8
5 1 6 3
16 1517
RECESIÓN
MOVILIDAD
6 1
12 11
8 1
14 13
RECESIÓN
4 24 8 4 7 4 5
MOVILIDAD
8 38 5 8 4 8 3
4 6 4 4 4 3
5 4 5 3 5 2
ODONTOGRAMA
3 73 6
7 57 2
6
7 1
3 3
LINGUAL
3 1 3 43 24 1
5 5
VESTIBULAR2 3
2 1 2 2 2 6 2 7
3 5
6 4
78
El odontograma es una herramienta que facilita el registro del estado de las piezas
dentales de cada paciente y se identifican 32 piezas definitivas y 20 temporales como
ver en la gráfica 16 en la sección lingual, se encuentran 20 círculos que representan
las denominadas piezas temporales o dientes de leche; los 32 cuadrados junto a la
sector vestibular son las 32 piezas definitivas que están numeradas por un código, las
que tienen código 18,28,38,48 son los tercer morales o muelas del juicio; La recesión
y la movilidad solo se utilizan para las piezas que son definitivas en el grado de
movilidad solo podrá ingresa del 1 al 3, en la recesión solo podrá ingresar del 1 al 4
Secciones 7-8-9
El formulario 033-Odontologia tiene una estándar básico el cual no se puede modificar
por lo tanto las secciones 7-8-9 se encuentran juntas por estética de la historia clínica.
Gráfico N. 17 Indicadores, índices y simbologías
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
U
r
MODERADA
E NFE RM E DAD P E RIODONT AL
( - - - - - - - )
65 9
o TOTAL
SEVERAd
0 - 1MODERADA
1716 55
0 - 1 - 2 - 3 - 9
SEVERA
ANGLE II0 - 1 - 2 - 3
51ANGLE III
SIMBOLOGÍA DEL ODONTOGRAMA75
26 27
36 37
46 47
31 41 71
11 21
85
azul SELLANTE REALIZADO ENDODONCIA CORONA
T OT ALE S
------ PRÓTESIS FIJA
ec
PÉRDIDA (OTRA CAUSA)SELLANTE NECESARIO
X rojo EXTRACCIÓN INDICADA
PRÓTESIS REMOVIBLE
D
PRÓTESIS TOTAL
CARIES
OBTURADO
rojo
azul
X azul PÉRDIDA POR CARIES
rojo
O TOTALPC
ANGLE ICÁLCULO
HIGIE NE ORAL S IM P LIFICADA
PIEZAS DENTALES
7 INDICADORES DE SALUD BUCAL
PLACA LEVE
FLUOROS ISM AL OCLUS IÓN
LEVEGINGIVITIS
8 ÍNDICES CPO-ceo
79
Sección 7 INDICADORES DE SALUD BUCAL
En esta sección se va a describir las cuatro subsecciones que son los indicadores de
salud bucal, los cuales detallamos a continuación:
1. Higiene oral simplificada
2. Enfermedad periodontal
3. Mal oclusión
4. Fluorosis
Subsección 7.1 Higiene oral simplificada En esta subsección consta de cuatro campos los cuales detallamos a continuación:
1. Piezas dentales. - Donde se marcará con “X” en la pieza que se realiza la
observación
Gráfico N. 18 Piezas dentales
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
2. Placa. - En este campo se ingresa un número entre 0 y 3 para indicar el
grado de placa que tiene la pieza dental donde el cero indica ausencia de
placa.
65
1716 55
51
75
26 27
36 37
46 47
31 41 71
11 21
85
TOTALES
PIEZAS DENTALES
80
3. Cálculo. - En este campo se ingresa un número entre 0 y 3 para indicar el
grado de cálculo que tiene la pieza dental donde el cero indica ausencia de
cálculo. 4. Gingivitis. - En este campo se ingresa un número 1 para indicar si tiene
sangrado y 0 para indicar ausencia de sangrado en la pieza dental.
Gráfico N. 19 Rango de higiene bucal
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
Funcionamiento Se marcan las piezas dentales con una x en el cuadrito amarillo y en las columnas
placa cálculo o gingivitis se ingresa el rango siguiente:
PLACA: 0-1-2-3 sólo se podrán ingresar estos indicadores.
CÁLCULO: 0-1-2-3 sólo se podrán ingresar estos indicadores.
GENGIVITIS: 0-1 sólo se ingresa 0 y 1 (0 no sangra, 1 si sangra).
0 - 10 - 1 - 2 - 3 0 - 1 - 2 - 3
CÁLCULOPLACA GINGIVITIS
81
Gráfico N. 20 Higiene oral simplificada
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
Cuadro N. 10 Niveles de higiene oral simplificada
Rango Placa Bacteriana Cálculo Gingivitis
0 Ausencia Ausencia
Ausencia de
sangrado
1
Placa a nivel del tercio
gingival Cálculo supragingival
presencia del
sangrado
2 Placa hasta el tercio medio Cálculo subgingival
3
Placa en toda la superficie de
la pieza
Cálculo sub y
supragingival
Elaborado Por: Roberto Carlos González León y Jorge Andrés Romero Franco Fuente: Datos de investigación.
En esta misma sección el cuadro TOTALES por cada columna se realiza el
siguiente cálculo:
TOTALES = A/B Donde A es la suma de la columna placa, cálculo, gingivitis respectivamente.
Y donde B es la suma de todas las piezas dentales marcadas con “X”.
Son tres cálculos que deben indicar los totales por cada columna ejemplo:
65
0 - 1
1716 55
0 - 1 - 2 - 3 0 - 1 - 2 - 3
51
75
26 27
36 37
46 47
31 41 71
11 21
85
TOTALES
CÁLCULO
HIGIENE ORAL SIMPLIFICADA
PIEZAS DENTALES PLACA GINGIVITIS
82
1. total, de placa
2. total, de cálculo
3. total, de gingivitis
Sección 7.2 Enfermedad Periodontal
En esta sección vamos a marcar con una “X” el tipo de enfermedad periodontal que
se observa a nivel general y se divide en tres campos, los cuales se detallan en la
siguiente gráfica:
Gráfico N. 21 Enfermedad Periodontal
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
Sección 7.3 Mal oclusión
En esta sección vamos a marcar con una “X” el tipo de Mal Oclusión que se observa
a nivel general y se divide en tres campos, los cuales se detallan en la siguiente
gráfica:
ENFERMEDAD PERIODONTAL
MODERADA
SEVERA
LEVE
83
Gráfico N. 22 Mal oclusión
E Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
En esta sección vamos a marcar con una “X” el tipo de Fluorosis que se observa a
nivel general y se divide en tres campos, los cuales se detallan en la siguiente gráfica:
SECCION 7.4
Gráfico N. 23 Fluorosis
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
Sección 8
Índice CPO-ceo En esta sección los Índices CPO (CARIES-PÉRDIDAS Y OBTURADAS) y ceo
(CARIES EXTRAIDAS Y OBTURADAS) se definen de la siguiente manera:
Dentición definitiva se registra en el cuadro con la (D) mayúscula y solo para
las piezas definitivas.
Dentición temporal se registra en el cuadro con la (d) minúscula y solo para las piezas temporales.
ANGLE II
ANGLE III
ANGLE I
MAL OCLUSIÓN
MODERADA
SEVERA
LEVE
FLUOROSIS
84
Gráfico N. 24 Índice CPO-ceo
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
Sección 9
Simbología del Odontograma En esta sección es informativo las simbologías indicadas son las que se van utilizar
en el odontograma para indicar la acción que se realiza o se diagnostica en la pieza
dental: Gráfico N. 25 Simbología del Odontograma
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
Observación: Todos los símbolos de color azul son tratamientos realizados en la pieza dental.
Todos los símbolos de color rojo son necesarios o situación actual de la pieza dental.
o TOTALd
ec
DO TOTALPC
8 ÍNDICES CPO-ceo
U
r
( - - - - - - - )
9 SIMBOLOGÍA DEL ODONTOGRAMA
azul SELLANTE REALIZADO ENDODONCIA CORONA
------ PRÓTESIS FIJA
PÉRDIDA (OTRA CAUSA)SELLANTE NECESARIO
X rojo EXTRACCIÓN INDICADA
PRÓTESIS REMOVIBLE
PRÓTESIS TOTAL
CARIES
OBTURADO
rojo
azul
X azul PÉRDIDA POR CARIES
rojo
85
Sección 10
Planes de diagnóstico, terapéutico y educacional
En esta sección se va a indicar con una “X” el tipo de examen complementario, que
consta de cuatro campos: 1. Biometría 2. Química sanguínea 3. Rayos - x 4. Otros
Anotar los exámenes complementarios solicitados para definir o ampliar el
criterio diagnóstico
Anotar la concentración, presentación, vía, dosis unitaria, frecuencia y días
que se administrará el medicamento prescrito
Anotar las indicaciones para prevención de complicaciones y cumplimiento del tratamiento.
Gráfico N. 26 Planes de diagnóstico, terapéutico y educacional
Elaborado Por: Ministerio de Salud Pública del Ecuador
Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
Sección 11 Diagnóstico
En esta sección se marca con “x” si se trata de un diagnóstico presuntivo en
el campo de la columna PRE o definitivo en el campo de la columna DEF del
paciente.
Escribir el código asignado a la enfermedad de acuerdo a la clasificación
internacional de enfermedades aplicada a odontología en el campo de la columna CIE.
PLANES DE DIAGNÓSTICO, TERAPÉUTICO Y EDUCACIONALBIOMETRIA
QUIMICA SANGUINEA RAYOS - X
10OTROS
86
Gráfico N. 27 Diagnóstico
Elaborado Por: Ministerio de Salud Pública del Ecuador
Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
Sección Datos
En esta sección vamos a tener cinco campos donde nos vamos a encontrar datos que
pueden ser precargados, se lo detalla en siguiente cuadro:
Cuadro N. 11 Datos
Datos Fecha de apertura Fecha de control Profesional Firma Número de hoja
Elaborado Por: Roberto Carlos González León y Jorge Andrés Romero Franco
Fuente: Datos de investigación.
Fecha Apertura: En este campo va ir previamente cargada fecha de admisión del
paciente. Fecha Control: En este campo dependiendo la disponibilidad del odontólogo le
asigna al paciente una cita subsecuente. Profesional: En este campo va a venir el nombre del odontólogo y su código laboral.
Firma: En este campo vendrá la firma digital del odontólogo que se encuentre
cargada en el base de datos. Numero de hoja: En este campo se ingresa el número de hoja de acuerdo a los
diagnósticos que se vaya dando.
4
1 3
CIE PRE DEF DIAGNÓSTICO PRE= PRESUNTIVO DEF= DEFINITIVO CIE PRE DEF
2
11
87
Gráfico N. 28 Datos Referenciales
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
Sección 11 Tratamiento
Esta sección va a estar compuesta de 5 subsecciones donde el odontólogo detalla el
diagnóstico previo y el tratamiento que realizará el paciente:
Sesión y fecha: Registrar el número de orden de la sesión correspondiente,
la fecha.
Diagnósticos y complicaciones: Describir la evolución de la enfermedad y
progreso del tratamiento. Nuevos datos del examen odontológico y del
resultado de exámenes de diagnóstico.
Procedimientos: Registrar las actividades e intervenciones preventivas y
curativas realizadas.
Prescripciones: Anotar el nombre de los medicamentos e insumos prescritos
Código y firma: Registrar el nombre y código del profesional y la firma.
NUMERO DE HOJA
FECHA DE APERTURA
FECHA DE CONTROL
PROFESIONAL FIRMA
88
Gráfico N. 29 Tratamiento
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
Análisis de requerimientos
Objetivos de la fase
Para iniciar el proceso de análisis de los requerimientos, se deben determinar los
aspectos que debe cumplir el sistema de información de la HCE, esto se logra
mediante levantamiento de información de investigaciones antes hechas de
Promeinfo2 que ayude a definir todas las especificaciones de lo que debe cumplir la
automatización de la historia clínica odontológica.
Técnicas Utilizadas Entrevistas: Se realizó entrevista al Dr. Ronald Alvarado pactando por medio de preguntas para
que nos indicará ¿Cuáles son las necesidades que existen en los centros
hospitalarios y los requerimientos que debe cumplir la HCE?, Sugirió que se desarrolle
el odontograma electrónico en la HCE, solicitó mejorar el diseño de la aplicación por
un diseño que ayude al usuario incluyendo el odontograma y el código de historia
SESIÓN 4FECHA
CÓDIGO
FIRMA
FECHA
CÓDIGO
FIRMA
SESIÓN
FIRMA
SESIÓN 2
3
FECHA
SESIÓN
SESIÓN Y FECHA
12
FECHA
PROCEDIMIENTOS
TRATAMIENTO
1
DIAGNOSTICOS Y COMPLICACIONES
CÓDIGO
CÓDIGO Y FIRMAPRESCRIPCIONES
FIRMA
CÓDIGO
89
clínica debe ser por ley el número de cédula ya que el actual no tiene definido un
estándar para ese campo, recomendó que si es factible ingresar el número de cedula
y automáticamente se cargue todos los datos del paciente. Reuniones: Se realizaron reuniones con Ing. Bernardo Iñiguez y el Ing. Jorge Medina quienes
laboran en la Universidad de Guayaquil en la Carrera de Ingeniería en Sistemas
Computacionales CISC y los doctores Eloy Rivera y Ronald Alvarado Flores, quienes
laboran en la Facultad de Medicina, los cuales nos dieron a conocer sus
requerimientos para que sea plasmado en el sistema entre estos requerimientos, se
tiene como lineamiento desarrollar un sistema que soporte la alta transaccionabilidad
entre los usuarios, utilizar herramientas open source para el desarrollo del sistema,
y la seguridad que se usará para los datos. Las que se pueden observar en el Anexo
5.
Revisión de Registros: Como aporte en el análisis de la información se revisaron los
formatos de Excel que se utilizan en el manejo actual del control y registro de la
información del Formulario 033 odontología, esto ayudó a tener una mejor idea de
toda la información que se debía considerar al momento de definir las funcionalidades
del sistema. Estos formatos se pueden observar el anexo # 8.
Se puede identificar que se tiene 13 grupos de datos entre los cuales el primer grupo
consta los datos generales, pero no cuenta con el campo de contacto; es decir, correo
electrónico y teléfono del paciente el cual limita la comunicación entre médico y
paciente. Los 12 grupos son campos técnicos de la medicina que deben ser llenados
por el funcionario perito o capacitado para poder ingresar la información de los
pacientes, se puede constatar que ésta ficha de odontología se ingresan los datos en
el formulario 033 -odontología por dos o más personas a la vez (admisión o ingreso,
estadística o enfermería y odontólogo especialista).
90
También se puede verificar que todas las fichas manuales lo cual implica que cada
vez que debe ser atendido el paciente debe volver a ingresar la información de la ficha
médica o formulario 033 de Odontología del MSP.
La ficha odontológica consta de dos partes que son anverso y reverso.
Campos del Formulario 033-odontología
Objetivo Mantener un registro secuencial y cronológico de los datos recopilados del
diagnóstico, tratamiento, evolución del progreso y/o variaciones del tratamiento y de
las prescripciones efectuadas por el profesional Odontólogo de acuerdo a las
recomendaciones de las guías de práctica estomatológica.
Toda persona que desea ser atendida por un médico con especialidad en odontología
debe ser evaluado para poder dar un diagnóstico y su respectivo tratamiento que
depende del cuadro clínico que presente, los más comunes están detallados a
continuación:
Grupo 1
Cabecera del formulario 033 -odontología. - Contiene los datos generales del
paciente que detallamos a continuación:
ESTABLECIMIENTO. - Es la institución clínica donde se atiende el
paciente.
NOMBRE Y APELLIDO. - En este campo se ingresa los nombres y apellidos
del paciente.
SEXO. - Se ingresa femenino o masculino dependiendo el sexo del
paciente.
91
EDAD. - Se ingresa la edad del paciente.
NÚMERO DE HISTORIA CLÍNICA. - Se registra el código de la historia
clínica electrónica debe ser el número de la cédula del paciente
Grupo 2
Cuerpo del Formulario 033 -odontología. – el cuerpo consta de 12 secciones que
a su vez contienen varios campos para registrar el estado actual del paciente y
diagnosticar el tratamiento adecuado para el paciente.
92
Gráfico N. 30 Campos del Formulario 033-odontología
Nº TÍTULOS SUBTÍTULOS INSTRUCCIONES DE LLENADO
ANVERSO: ODONTOLOGÍA (1) ESTABLECIMIENTO NOMBRE Y APELLIDO SEXO EDAD NÚMERO DE HISTORIA CLÍNICA 1 MOTIVO DE
CONSULTA DESCRIBIR LA CAUSA QUE ORIGINA LA SOLICITUD DE CONSULTA, EN PALABRAS TEXTUALES DEL USUARIO
2 ENFERMEDAD O PROBLEMA ACTUAL ESCRIBIR EL RESULTADO ORGANIZADO DEL INTERROGATORIO DE
SÍNTOMAS SOBRE EL PROBLEMA ODONTOLÓGICO
3 ANTECEDENTES PERSONALES Y FAMILIARES
PERSONALES MARCAR “X” SI SE DETECTA ANTECEDENTE DE ENFERMEDADES PERSONALES. ESCRIBIR EL RESULTADO DEL INTERROGATORIO ACERCA DE PROBLEMAS DE SALUD RELEVANTES DEL USUARIO
FAMILIARES MARCAR “X” SI SE DETECTA ANTECEDENTE DE ENFERMEDADES FAMILIARES RESULTADO DEL INTERROGATORIO ACERCA DE PROBLEMAS DE SALUD RELEVANTES DE LOS MIEMBROS DE LA FAMILIA
4 SIGNOS VITALES REGISTRAR LOS DATOS OBTENIDOS SOBRE, PRESIÓN ARTERIAL, FRECUENCIA CARDIACA min, FRECUENCIA RESPIRATORIA min, TEMPERATURA ºC,
5 EXAMEN DEL SISTEMA ESTOMATOGNÁTICO
MARCAR “X” SOLAMENTE SI EXISTE PATOLOGÍA Y DESCRIBIR EN LA PARTE INFERIOR
6 ODONTOGRAMA REGISTRAR LOS RESULTADOS DE LA EXPLORACIÓN ODONTOLOGICA Y LA APRECIACIÓN DIAGNOSTICA DE LOS TEJIDOS DUROS Y BLANDOS DE LA DENTICIÓN DEFINITIVA Y / O TEMPORAL, UTILIZANDO LOS SÍMBOLOS CORRESPONDIENTES
7 INDICADORES DE SALUD BUCAL
HIGIENE ORAL SIMPLIFICADA - HOS
ÍNDICE QUE RESULTA DE LA VALORACIÓN DE HIGIENE ORAL EN DIENTES TEMPORALES Y/O DEFINITIVOS
ENFERMEDAD PERIODONTAL - EP
ÍNDICE QUE RESULTA DE LA VALORACIÓN DE LOS TEJIDOS PERIODONTALES EN DENTICIÓN TEMPORAL Y/O DEFINITIVA
MAL OCLUSIÓN ÍNDICE QUE RESULTA DE LA VALORACIÓN DE LA OCLUSIÓN DE MAXILARES EN DENTICIÓN TEMPORAL Y DEFINITIVA
FLUOROSIS ÍNDICE QUE RESULTA DE LA VALORACIÓN DEL EXCESO DE FLUOR DEPOSITADO EN EL ESMALTE DENTARIO QUE PRODUCE DEFORMACIONES Y COLORACIÓN ANORMAL
8 ÍNDICES CPO - ceo REGISTRAR EL ÍNDICE QUE RESULTA DE LA VALORACIÓN DEL GRADO DE AFECTACIÓN DE LOS TEJIDOS DENTARIOS TEMPORALES O DEFINITIVOS
9 SIMBOLOGÍA DEL ODONTOGRAMA
SELLANTES LOCALIZACIÓN DE LA COLOCACIÓN DE OBTURACIONES TEMPORALES EN PIEZAS DENTARIAS PARA PREVENIR CARIES DENTAL.
EXODONCIAS NÚMERO DE PIEZAS DENTALES FALTANTES O EXTRAÍDAS.
PRÓTESIS CARACTERÍSTICAS DE LAS PRÓTESIS REMOVIBLES Y NO REMOVIBLES DESTINADAS A REESTABLECER LA FUNCIONALIDAD DEL APARATO ESTOMATOGNATICO.
REVERSO: ODONTOLOGÍA (2)
10 PLANES DE DIAGNÓSTICO, TERAPÉUTICO Y EDUCACIONAL
ANOTAR LOS EXÁMENES COMPLEMENTARIOS SOLICITADOS PARA DEFINIR O AMPLIAR EL CRITERIO DIAGNÓSTICO ANOTAR LA CONCENTRACIÓN, PRESENTACIÓN, VÍA, DOSIS UNITARIA, FRECUENCIA Y DÍAS QUE SE ADMINISTRARÁ EL MÉDICAMENTO PRESCRITO ANOTAR LAS INDICACIONES PARA PREVENCIÓN DE COMPLICACIONES Y CUMPLIMIENTO DEL TRATAMIENTO
11 DIAGNÓSTICOS CATEGORÍA MARCAR “X” EN DIAGNÓSTICO PRESUNTIVO O DEFINITIVO
CIE ESCRIBIR EL CÓDIGO ASIGNADO A LA ENFERMEDAD DE ACUERDO A LA CLASIFICACIÓN INTERNACIONAL DE ENFERMEDADES APLICADA A ODONTOLOGÍA
FECHA HORA NOMBRE DEL PROFESIONAL CÓDIGO NÚMERO DE HOJA
12 TRATAMIENTO
SESIÓN Y FECHA REGISTRAR EL NÚMERO DE ORDEN DE LA SESIÓN CORRESPONDIENTE, LA FECHA
DIAGNÓSTICOS Y COMPLICACIONES
DESCRIBIR LA EVOLUCIÓN DE LA ENFERMEDAD Y PROGRESO DEL TRATAMIENTO. NUEVOS DATOS DEL EXAMEN ODONTOLÓGICO Y DE LOS RESULTADO DE EXÁMENES DE DIAGNÓSTICO
PROCEDIMIENTOS REGISTRAR LAS ACTIVIDADES E INTERVENCIONES PREVENTIVAS Y CURATIVAS REALIZADAS
PRESCRIPCIONES ANOTAR EL NOMBRE DE LOS MÉDICAMENTOS E INSUMOS PRESCRITOS CÓDIGO Y FIRMA REGISTRAR EL NOMBRE Y CÓDIGO DEL PROFESIONAL Y LA FIRMA
Elaborado Por: Ministerio de Salud Pública del Ecuador Fuente: Acuerdo 0000138 Formulario 033-Odontologia Ministerio de Salud Pública.
93
Resultado de la etapa de análisis
Luego de analizar la información que se recolectó como método de investigación, se
definieron los requisitos del sistema, los mismos que están aprobados y se describen
a continuación.
Requisitos Futuros: Actualmente la HCE está desarrollada y plenamente activa para su ejecución y uso;
en caso, los directivos deseen realizar nuevas mejoras o mantenimiento a la
aplicación se deberá realizar la investigación pertinente de las nuevas mejoras esto
quedará a manos de las personas encargadas de aquellos procesos.
Requisitos Funcionales: Son las funciones y servicios que brindará el sistema de información a los usuarios.
El Formulario 033 odontología realizará las siguientes funciones:
Permitirá crear la cuenta de los usuarios, enviando una cuenta y contraseña
al correo electrónico para seguridad de los usuarios.
El ingreso al Formulario 033-odontología es ingresando el usuario y la
contraseña.
La consultar imágenes, odontograma y datos del paciente.
Control de rol de usuarios.
Consultar de HCE.
Consultar a la Base datos.
Permitirá a los usuarios actualizar sus datos y guardarlos.
Ingresar datos de los pacientes en la HCE.
Enviar información al correo electrónico del paciente o médico indicando su
próxima consulta subsiguiente.
Cerrar Sesión de manera segura.
Bloquear usuarios.
94
Requisitos no Funcionales:
El lenguaje de programación y entorno para la ejecución del sistema es Java
debido a que es portable, orientado a objetos, brinda seguridad y diseño para
sistemas en red.
La estructura Interna es en N- capas.
El diseño de la interfaz de usuario se realizó con el Framework Prinfaces
Se usó para la codificación de la aplicación el lenguaje de programación Java
con Framework Prinfaces
Para el desarrollo del software se usó IDE Eclipse por ser de código abierto y
multiplataforma y posee la ventaja que puede ejecutar gran cantidad de
elementos en sitios web.
Para la construcción de la aplicación web por ser ligero y flexible se usó
Wildfly server.
Para el desarrollo de la base de datos se usó PostgreSQL por ser de código
abierto, y poseer varias características que lo hacen único entre estos
beneficios es la integridad de los datos.
Se usó Hibernate para el mapeo objeto/relacional para ambientes Java, entre
sus ventajas esta la recuperación de datos que ayuda a reducir el tiempo de
desarrollo.
95
Diseño
Objetivo de la Fase
Encontrar la representación gráfica idónea para el diseño de las funciones del sistema
usando diagramas que cubran las necesidades de los actores o beneficiarios que
usarán el sistema.
Técnicas Utilizadas
Se realizó el diseño del modelo de caso de uso de acuerdo al estudio del modelo
entidad – relación que diseñó Promeinfo2 en la primera etapa, diseños que fueron
mejorados con las recomendaciones tomadas en las entrevistas y reuniones,
adicional con la información obtenida en la entrevista.
Resultado de la Fase
Una vez realizadas las modificaciones en los modelos de diagramas de acuerdo a las
especificaciones que requiere el desarrollo del sistema de información, se definen los
siguientes diagramas para el diseño:
Diagramas de Caso de Uso
Diagrama de Entidad Relación
Diagrama de Flujo
Diagrama de Arquitectura de
Software
Diseño de la interfaz de usuario
Diagrama de Caso de Uso
Una vez detallado los requisitos se empezó a diseñar el modelo de casos de uso que
a continuación se muestra en la gráfica 31:
96
Gráfico N. 31 Diagrama de caso de uso
Elaborado por: Roberto Caros González León
Fuente: Estudio realizado
CASO DE USOS DE HISTORIA CLÍNICA ELECTRÓNICA 033 ODONTOLOGÍA MSP
ODONTÓLOGO 1.REGISTRAR MOTIVO DE
CONSULTA
3. ANTECEDENTES PERSONALES
7. REGISTRAR ÍNDICES DE
SAUD BUCAL
2.ENFERMEDAD O PROBLEMA
ACTUAL
4. SIGNOS VITALES
6. REGISTRAR
ODONTOGRAMA
5. EXAMEN DEL SISTEMA
ESTOMATOGNÁTICO
8.ÍNDICES
CPO-ceo
10. PLANES DE DIAGNÓSTICO TERAPÉUTICO
Y EDUCACIONAL
11.REGISTRAR
DIAGNÓSTICO
12.REGISTRAR
TRATAMIENTO
ENFERMERA O
ASISTENTE
HISTORIA CLÍNICA
ELECTRÓNICA
9. SIMBOLOGÍA
97
A continuación, se describe cada uno de los casos de uso del proyecto del diagrama
anterior de la forma más detallada, para entender mejor el funcionamiento del
sistema: Cuadro N. 12 Caso de uso de ingresar al sistema
Nombre Ingresar al sistema Actor Odontólogo Tipo Primario Descripción El actor introduce su usuario y contraseña e ingresa. Si los datos
ingresados no son correctos, el sistema mostrará un mensaje en pantalla informando que los datos son incorrectos y q vuelva a introducirlos.
Elaborado Por: Roberto Carlos González León y Jorge Andrés Romero Franco
Fuente: Datos de investigación.
Cuadro N. 13 Caso de uso atender turnos
Nombre Atender Turnos Actor Odontólogo Tipo Primario Descripción El actor ingresará a la sección de
Agenda, donde podrá visualizar los diferentes turnos que tiene para ese día y los irá atendiendo de acuerdo al horario establecido.
Elaborado Por: Roberto Carlos González León y Jorge Andrés Romero Franco
Fuente: Datos de investigación.
Cuadro N. 14 Caso de uso ingreso motivo de consulta
Nombre Visualizar Motivo de Consulta Actor Odontólogo Tipo Primario Descripción El actor ingresa una descripción, la cual
quedará almacenada para estar al tanto de la siguiente consulta, si la hay.
Elaborado Por: Roberto Carlos González León y Jorge Andrés Romero Franco Fuente: Datos de investigación.
98
Cuadro N. 15 Caso de uso ingreso antecedentes personales
Nombre Visualiza Antecedentes Personales Actor Odontólogo Tipo Primario Descripción El actor Visualiza datos clínicos del
paciente.
Elaborado Por: Roberto Carlos González León y Jorge Andrés Romero Franco Fuente: Datos de investigación.
Cuadro N. 16 Caso de uso ingreso enfermedad o problema actual
Nombre Visualizar Enfermedad o Problema Actual
Actor Odontólogo Tipo Primario Descripción El actor visualiza en el formulario la
enfermedad o problema actual, tal y como el paciente relato en su consulta.
Elaborado Por: Roberto Carlos González León y Jorge Andrés Romero Franco
Fuente: Datos de investigación.
Cuadro N. 17 Caso de uso visualización signos vitales
Nombre Visualiza Signos Vitales Actor Odontólogo Tipo Primario Descripción El actor podrá visualizar en el
formulario la información sobre Presión Arterial, Frecuencia Cardiaca, Temperatura y Frecuencia Respiratoria.
Elaborado Por: Roberto Carlos González León y Jorge Andrés Romero Franco
Fuente: Datos de investigación.
99
Diagrama de flujo
A continuación, podemos observar el diagrama de flujo de la aplicación:
Gráfico N. 32 Diagrama de Flujo de la aplicación
Elaborado por: Roberto Caros González León
Fuente: Estudio realizado
El diagrama de flujo nos indica la forma de ingresar al sistema donde los usuarios dependiendo el rol
que tengan asignado podrán visualizar las opciones de Menú Principal si es Médico (Odontólogo),
administrativo o paciente.
Diagrama de arquitectura de Software
Gráfico N. 33 Diagrama de arquitectura
Elaborado por: Jorge Andrés Romero Franco Fuente: Estudio realizado
100
Se realizó el diagrama de arquitectura tomando en cuenta las herramientas open
source que mejor se acoplaban al tipo de red social que se desarrolla.
A continuación, se explicará cada una de las capas del proyecto: -Capa Entidad En esta capa se crearán las clases que tengan la misma estructura de las tablas
de la base de datos, las cuales se usarán para poder almacenar los registros que
se ingresan o consultan de las tablas que se encuentren en la base de datos y las
cuales usaremos en la aplicación. -Capa DAO En esta capa se crearán las clases con las cuales ejecutaremos los procedimientos
almacenados de la base de datos para realizar las diferentes operaciones con los
registros de las tablas. -Capa Servicio Web En esta capa se crearán los métodos web que son los necesarios para poder
invocar a los métodos que se encuentran en la capa DAO y pueda ser usada por
la capa aplicación web. -Capa Aplicación Web En esta capa se hará el llamado de los métodos que se encuentran en la capa
servicio web y así mismo en ésta capa se crearán los formularios que utilizarán los
usuarios para ingresar y consultar registros que se encuentren en las tablas de la
base de datos.
101
Gráfico N. 34 Diagrama de Ishikawa
Elaborado Por: Roberto Caros González León y Jorge Andrés Romero Franco Fuente: Datos de investigación
El diagrama de Ishikawa nos va indicar las causas y subcausas que originan el
problema de “La falta de interoperabilidad de los sistemas de información médicos en
el área de odontología del MSP”
Falta de un sistema de información en el área de bioinformática.
Personal con escasos conocimientos de la tecnología informática.
Diagnósticos erróneos
Carece de un sistema de Control monitoreo y seguimiento de la gestión de calidad del servicio.
Ilegibilidad de información manuscrita por parte del odontólogo.
Falta de Asignación presupuestaria.
Incumplimiento de las normas ISO 13606.
No se puede adquirir Sistemas de información y equipos actualizados.
Falta de control en los estándares en las clínicas odontológicas.
SISTEMAS DE INFORMACIÓN
NORMA ISO 13606 PRESUPUESTO
102
Gráfico N. 35 Diagrama de Procesos
Elaborado Por: Jorge Andrés Romero Franco Fuente: Datos de investigación.
Este diagrama nos indica el estudio y el análisis de todas las operaciones que se van a llevar a cabo en el transcurso del proyecto de titulación.
103
Gráfico N. 36 Modelo Entidad Relación
Elaborado Por: Jorge Andrés Romero Franco Fuente: Datos de investigación
104
El modelo entidad relación de la base de datos del Formulario 033-Odontologia
constara con campos de auditoria donde se podrán llevar un control de los registros
que llevan los pacientes por sesión sea por consulta o por tratamientos.
Diseño de la interfaz de usuario
El diseño de la interfaz se elaboró de tal forma que sea de fácil uso para el usuario
final y no tenga complicaciones para poder utilizar todas las opciones que provee la
aplicación.
Cada página presentará las siguientes características:
Se han considerado los colores azul, celeste, gris y blanco para el fondo y la mayoría
de los componentes, porque la investigación realizada refleja que el color azul y los
colores opacos causan menos cansancio para la vista, gracias a esto habrá una
mayor productividad del personal y menos estrés a la hora de estar ejecutando el
sistema en un tiempo considerable. Se mencionan las referencias de las
investigaciones (iPixel factory, 2013) y (Sánchez Montoya, Ordenador y discapacidad
2da edición, 2002).
Contorno de la página del Formulario azul.
Color de la barra de menús: gris, blanco y celeste cuando el mouse se
sobrepone en el menú.
Color de fondo de las páginas blanco.
Color de áreas de texto blanco.
Color de botones gris y celeste cuando el ratón se sobrepone en el botón.
Color de fuente de las áreas de texto negro.
Color de fuente de los botones: negro.
105
Gráfico N. 37 Diseño de la página inicial del sistema
Elaborado por: Jorge Andrés Romero Franco Fuente: Estudio realizado
106
Gráfico N. 38 Diseño del área de trabajo
Elaborado por: Jorge Andrés Romero Franco
Fuente: Estudio realizado
107
En los gráficos 37 y 38 tenemos el diseño del prototipo del formulario 033-odontologia
HCE.
Entregables del proyecto
Cuadro N. 18 Entregables del proyecto
Producto Medio de Entrega Manual de Usuario Medio Digital, Impreso Manual Técnico Medio Digital, Impreso Diseño de la última versión de: - Base de Datos - Arquitectura - Archivos de Configuración Medio Digital Software Operativo Medio Digital
Elaborado Por: Roberto Carlos González León, Jorge Andrés Romero Franco.
Fuente: Roberto Carlos González León, Jorge Andrés Romero Franco.
Criterios de validación de la propuesta Formulario 033 de Odontología, fue revisado y aprobado por el coordinador del
proyecto Ing. Jorge Medina, indicando que cumple los requerimientos e indicaciones
definidas, obteniendo resultados satisfactorios de las pruebas realizadas. Se adjunta como soporte de las pruebas el acta de aceptación del proyecto.
108
CAPÍTULO IV
CRITERIOS DE ACEPTACIÓN DEL PRODUCTO
La aceptación del presente proyecto será emitida por Coordinador de Proyecto eSalud
del Sistema Historia Clínica electrónica del formulario básico 033 de odontología,
mediante una reunión formal, que a su vez firmará el documento de aceptación una
vez validados los requisitos iniciales del proyecto. A continuación, se detallan los
criterios acordados bajos los cuales se considerará que la herramienta desarrollada
cumple con las especificaciones exigidas:
Cuadro N. 19 Arquetipo de odontología
Requerimientos Criterios de Aceptación Nivel de Cumplimiento
Visualizar el
Motivo de la consulta
Permitirá al odontólogo observar la causa que
origina la solicitud de consulta, en palabras textuales del usuario.
100%
Visualizar
Antecedentes
Personales
Permitirá al odontólogo observar acerca de
problemas de salud anteriores al motivo de consulta
100%
Visualizar
Antecedentes
Familiares
Permitirá al odontólogo observar la Descripción de
los problemas de salud relevantes de los miembros
de la familia.
100%
Registrar
Enfermedad o
Problema Actual
Permitirá registrar el resultado organizado de las
preguntas de síntomas que aquejan al paciente.
100%
109
Visualizar Signos
Vitales
Permitirá al odontólogo observar los datos
obtenidos sobre temperatura, presión arterial, pulso, frecuencia respiratoria y peso / talla
100%
Visualizar
Diagnostico Cie
10
Permitirá registrar el diagnóstico con el código
asignado de acuerdo a la clasificación internacional
de enfermedades.
100%
Visualizar Plan de
tratamiento
Permitirá registrar los exámenes, prescripciones de
fármacos o intervenciones quirúrgicas programadas
y las recomendaciones o indicaciones acerca de los
estilos de vida.
100%
Visualizar
Prescripción
Permitirá visualizar las indicaciones para
farmacoterapia como: nombre, presentación, vía, dosis, frecuencia y periodo.
100%
110
Cuadro N. 20 Pruebas de aceptación del software
Requerimientos Criterios de Aceptación Nivel de Cumplimiento
Ingresar al Sistema Permita ingresar al usuario registrado y dependiendo de
su rol se le muestre la pantalla correspondiente.
100%
Ingresar el Motivo
de la consulta
Permitirá al odontólogo ingresar la causa que origina la
solicitud de consulta, en palabras textuales del usuario.
100%
Ingresar Antecedentes
Personales
Permitirá al odontólogo ingresar los problemas de salud anteriores al motivo de consulta
100%
Ingresar
Antecedentes Familiares
Permitirá al odontólogo ingresar la descripción de los
problemas de salud relevantes de los miembros de la familia.
100%
Registrar
Enfermedad o Problema Actual
Permitirá registrar el resultado organizado de las
preguntas de síntomas que aquejan al paciente.
100%
Ingresar Signos
Vitales
Permitirá al odontólogo ingresar los datos obtenidos sobre
temperatura, presión arterial, pulso, frecuencia
respiratoria y peso / talla
100%
Registrar
Diagnostico Cie 10
Permitirá registrar el diagnóstico con el código asignado
de acuerdo a la clasificación internacional de
enfermedades.
100%
Registrar Plan de
tratamiento
Permitirá registrar los exámenes, prescripciones de
fármacos o intervenciones quirúrgicas programadas y las
recomendaciones o indicaciones acerca de los estilos de vida.
100%
Registrar
Prescripción
Permitirá registrar las indicaciones para farmacoterapia
como: nombre, presentación, vía, dosis, frecuencia y
periodo.
100%
Ingresar
Odontograma
El odontólogo visualiza el odontograma y verifica los
diagnósticos.
100%
111
Guardar HCU Permitirá ingresar la información del Formulario 002 en la base de datos, evitando que falte información por llenar.
100%
Generar Reporte Permitirá generar el reporte de las consultas, donde podrá
filtrar por fecha de rangos y/o médicos.
100%
Imprimir Reporte Permitirá imprimir o descargar en archivo tipo PDF el reporte de las consultas generadas.
100%
112
Conclusiones
Luego de concluir el desarrollo de formulario - 033 de odontología del Ministerio de
Salud Pública aplicando arquetipos basados en la norma ISO 13606 para la
interoperabilidad de los Sistemas hospitalarios que operan en el Ministerio de salud
Pública del Ecuador indicamos lo siguiente:
Se logró analizar y levantar línea base para la creación de los arquetipos en
función del Formulario 033-Odontología aplicando la norma ISO 13606
Se desarrolló el arquetipo para la estructura y recuperación de datos.
Se desarrolló una Historia Clínica Electrónica del Formulario 033-Odontología
del Ministerio de Salud Pública para ser utilizada en el diseño y representación
de los datos en denominados arquetipos.
Se presenta una herramienta amigable con el usuario no técnico debido a que
el sistema puede comunicar información de la Historia Clínica Electrónica
entre diferentes sistemas médicos.
113
Recomendaciones
El presente proyecto de titulación del desarrollo de formulario - 033 de odontología
del Ministerio de Salud Pública aplicando arquetipos basados en la norma ISO 13606
para la interoperabilidad de los Sistemas hospitalarios está sujeto a un sistema de
gestión de calidad y un proceso de mejoras continuas entre las cuales tenemos:
Se sugiere que el sistema de información del formulario 033 de odontología
debe ser actualizado antes de que culmine el ciclo de vida, máximo a los 3
años y establecer el uso de esta aplicación en todas las instituciones de salud
pública y privada a nivel nacional debido a que el beneficio será directamente
para los pacientes que tendrán su HCE a nivel nacional.
Se esperaría a futuro y acorde a las necesidades del proyecto, la creación del
módulo de integración de las Normas ISO 13606.
Se recomienda, salvo su mejor criterio, realizar el estudio de un módulo de
agendamiento de citas médicas subsecuentes, con el propósito de brindar una
mejor calidad en el servicio de atención médica en el área de odontología.
Se propone la implementación de un módulo de monitoreo y seguimiento de
las operaciones clínicas odontológicas.
Recomendamos capacitar al personal de los centros de salud odontológicos y
todo el recurso humano que esté involucrado en las actividades y tarea del
sistema de información de odontología con el fin de hacer un uso de la
propuesta.
Se recomienda realizar un estudio para incrementar campos o registros en el
formulario 033 del MSP, como por ejemplo campo de correo electrónico y
teléfono móvil con el objetivo de implementar la encuesta y evolución del
servicio recibido por la organización médica odontológica.
Se recomienda realizar un estudio del proceso de operaciones y logística para
mejorar la distribución de los recursos médicos.
114
Bibliografía ©ECORFAN-Bolivia. (2014). Tópicos Selectos de Ingeniería. En J. D. Joel Quintanilla,
Aplicaciones TIC (pág. 112). BOLIVIA: ECORFAN. Alarcón, V. F. (2006). http://upcommons.upc.edu/handle/2099.3/36751. Obtenido de
https://books.google.com.ec/books?id=Sqm7jNZS_L0C&pg=PA11&lpg=PA11&dq=Un+sistema+es+un+conjunto+de+componentes+que+interaccionan+entre+s%C3%AD+para+lograr+un+objetivo+com%C3%BAn.+Aunque+existe+una+gran+variedad+de+sistemas,+la+mayor%C3%ADa+de+ellos+pueden
Amarilla, J. L. (27 de 02 de 2004). http://www.um.es/. Obtenido de http://www.um.es/: http://www.um.es/atica/acceso-a-base-de-datos-desde-aplicaciones-web-en-java-4
Copyright © 1981- 2016 El Lenguaje de ordenadores Company. (2016). http://www.pcmag.com/encyclopedia/term/61186/technology-stack. Obtenido de http://www.pcmag.com/encyclopedia/term/61186/technology-stack: http://www.pcmag.com/
Copyright © 2012-2013 Depto. Ciencia de la computación e IA. (06 de 06 de 2014). http://www.jtech.ua.es/j2ee/publico/spring-2012-13/sesion01-apuntes.html. Obtenido de http://www.jtech.ua.es/j2ee/publico/spring-2012-13/sesion01-apuntes.html: http://www.jtech.ua.es/
Fergarciac. (25 de 01 de 2013). fergarciac.wordpress.com. Obtenido de https://fergarciac.wordpress.com/2013/01/25/entorno-de-desarrollo-integrado-ide/
Francisco Moya, C. G. (s.f.). Desaorrollo de videos juegos: Tecnicas Avanzadas. espacursos. González, H. S. (22 de 04 de 2003). www.javahispano.org. Obtenido de
www.javahispano.org: http://www.javahispano.org/portada/2011/7/5/manual-hibernate.html
Guerrero, A. C. (20 de 07 de 2015). http://www.gestiopolis.com/ciclo-de-vida-de-un-sistema-de-informacion/. Obtenido de http://www.gestiopolis.com/ciclo-de-vida-de-un-sistema-de-informacion/: http://www.gestiopolis.com
Herederos, C. d., Medina Salgado, S., & Romero, S. M.-R. (2011). https://books.google.com.ec. Obtenido de https://books.google.com.ec/books?id=2pqwKkqxxosC&printsec=frontcover&source=gbs_ge_summary_r&cad=0#v=onepage&q&f=false
http://repositorio.utn.edu.ec. (18 de 10 de 2016). Obtenido de http://repositorio.utn.edu.ec: http://repositorio.utn.edu.ec/bitstream/123456789/571/1/Tesis.pdf
http://www.gestiopolis.com/ciclo-de-vida-de-un-sistema-de-informacion/. (s.f.). Obtenido de http://www.gestiopolis.com/ciclo-de-vida-de-un-sistema-de-informacion/: http://www.gestiopolis.com/ciclo-de-vida-de-un-sistema-de-informacion/
https://grimpidev.wordpress.com/2011/02/08/control-de-concurrencia-multiversion-mvcc/. (s.f.). Obtenido de https://grimpidev.wordpress.com/2011/02/08/control-de-concurrencia-multiversion-mvcc/: https://grimpidev.wordpress.com
Hunt, L. (s.f.). http://alistapart.com/article/previewofhtml5. Obtenido de http://alistapart.com/article/previewofhtml5: http://alistapart.com/
115
IBM. (18 de 06 de 2012). https://www.ibm.com/developerworks/ssa/local/im/que-es-big-data/. Obtenido de https://www.ibm.com/developerworks/ssa/local/im/que-es-big-data/: www.ibm.com
Inen, I. E. (20 de marzo de 2014). http://www.normalizacion.gob.ec. Recuperado el 13 de septiembre de 2016, de INFORMÁTICA SANITARIA. COMUNICACIÓN DE LA HISTORIA: http://www.normalizacion.gob.ec/wp-content/uploads/downloads/2014/NORMAS_2014/DRO/nte_inen_iso_13606_1extracto.pdf
Java. (2014). https://www.java.com. Obtenido de https://www.java.com/es/about/ Java. (s.f.). https://www.java.com/es/download/faq/techinfo.xml. Obtenido de
https://www.java.com/es/download/faq/techinfo.xml: www.java.com M. F., R. P., & J. M. (2000). https://es.wikipedia.org/wiki/Plain_Old_Java_Object. Obtenido
de https://es.wikipedia.org/wiki/Plain_Old_Java_Object: es.wikipedia.org Microsoft. (2008). https://technet.microsoft.com/es-es/library/cc280522(v=sql.105).aspx.
Obtenido de https://technet.microsoft.com/es-es/library/cc280522(v=sql.105).aspx: https://technet.microsoft.com
Ministerio de salud Publica. (26 de 05 de 2015). https://aplicaciones.msp.gob.ec/. Recuperado el 14 de 09 de 2016, de Uso de un solo código de Historia Clínica: https://aplicaciones.msp.gob.ec/salud/archivosdigitales/sigobito/tareas_seguimiento/1715/13_informe_avance%20uso%20de%20c%C3%A9dula%20como%20n%C3%BAmero%20de%20HC.pdf
Publica, M. d. (05 de 08 de 2014). http://somossalud.msp.gob.ec/. Obtenido de ac_00004934_2014 30 jul.pdf: https://aplicaciones.msp.gob.ec/salud/archivosdigitales/documentosDirecciones/dnn/archivos/ac_00004934_2014%2030%20jul.pdf
PUBLICA, M. D. (26 de 05 de 2015). https://aplicaciones.msp.gob.ec/. Recuperado el 14 de 09 de 2016, de Uso de un solo código de Historia Clínica: https://aplicaciones.msp.gob.ec/salud/archivosdigitales/sigobito/tareas_seguimiento/1715/13_informe_avance%20uso%20de%20c%C3%A9dula%20como%20n%C3%BAmero%20de%20HC.pdf
Rafael Correa Delgado. (11 de 04 de 2008). http://www.administracionpublica.gob.ec. Recuperado el 14 de 09 de 2016, de http://www.administracionpublica.gob.ec/wp-content/uploads/downloads/2014/06/DecretoEjecutivo1014.pdf
www.abc.es. (s.f.). http://www.abc.es/tecnologia/consultorio/20150203/abci-backup-definicion-que-es-201502031524.html. Obtenido de http://www.abc.es/tecnologia/consultorio/20150203/abci-backup-definicion-que-es-201502031524.html: http://www.abc.es/
116
Anexo 1 Formato de entrevista
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS Versión: 1.0 CARRERA DE INGENIERÍA EN SISTEMAS
COMPUTACIONALES Acta de reunión de Entrevista
DATOS GENERALES Fecha reunión 24 de agosto del
2016 Código Reunión TPT-FO-2016-08-24 Fecha próxima
reunión 28 de agosto del 2016 Dependencia Grupo de proyecto de titulación
Responsable del Acta
Nombre Contacto
Cargo Correo Electrónico Extensión Telefónica
Roberto Carlos González
[email protected] 0959414563 Analista líder
Antecedentes de la Reunión Tema
Reunión Entrevista a médico odontólogo de la Facultad de
Odontología de la Universidad de Guayaquil Hora Inicio 17h00
Lugar Facultad de Odontología de la Universidad de Guayaquil Hora Fin 18h00
Antecedentes de la Temática
Facultad de Odontología de la Universidad de Guayaquil
Asistentes
Nombre Contacto
Cargo Correo Electrónico Extensión Telefónica
Roberto Carlos González [email protected] 0959414563 Líder de
proyecto Jorge Romero [email protected] 0982296717 Desarrollador
Desarrollo de la Reunión Preguntas Respuestas Observación Plazo
1
Aceptación Para constancia de la conformidad de la presente acta y de aceptación de los miembros de la
Reunión firman los participantes a la reunión. NOTA: Si no existen observaciones a este documento en el periodo de dos (2) días laborales,
se lo considera como aceptado. Nombre Firma
Roberto Carlos González Jorge Romero
Elaborado Por: Roberto Carlos González León Fuente: Datos de la investigación
117
Anexo 2 Formato de pruebas
FACULTAD DE CIENCIAS MATEMÁTICAS Y FÍSICAS Versión:
1.0
CARRERA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES
Acta de Pruebas DATOS GENERALES
Fecha reunión 24 de agosto del 2016 Código Reunión AP-FO-2016-08-24
Fecha próxima reunión
28 de agosto del 2016 Dependencia Grupo de proyecto de
titulación
Responsable del Acta
Nombre Contacto
Cargo Correo Electrónico Extensión Telefónica
Roberto Carlos González [email protected] 0959414563
Analista líder
Antecedentes de la Reunión Tema Reunión Entrevista a médico odontólogo de la Facultad de
Odontología de la Universidad de Guayaquil Hora Inicio 17h00
Lugar Facultad de Odontología de la Universidad de Guayaquil Hora Fin 18h00
Antecedentes de la Temática
Facultad de Odontología de la Universidad de Guayaquil
Asistentes
Nombre Contacto
Cargo Correo Electrónico Extensión Telefónica
Roberto Carlos González
[email protected] 0959414563 Líder de
proyecto
Jorge Romero [email protected] 0982296717 Desarrolla
dor
Pruebas con Usuario Prueba Escenario de
Prueba Resultado esperado
Resultado obtenido Observación
1 Escenarios de pruebas
Aceptación Para constancia de la conformidad de la presente acta y de aceptación de los miembros de la
Reunión firman los participantes a la reunión. NOTA: Si no existen observaciones a este documento en el periodo de dos (2) días laborales,
se lo considera como aceptado. Nombre Firma
Roberto Carlos González Jorge Romero
Elaborado Por: Roberto Carlos González León Fuente: Datos de la investigación
118
Anexo 3 Diseños de arquetipos de formulario 033- odontología
La herramienta Link EHR nos facilita la elaboración de los arquetipos como son los
mas basicos element, cluster entry composition y section, los datos del formulario
033 estan divididos en dos partes y cada una tiene varias secciones con diferentes
elementos.
Se procede a identificar los campos que se deben crear los arquetipos dependindo
del tipo de darto que lleve el registro de la historia clinica de odontologia.
Para facilitar el diseño del formulario 033 se procedera a separar en dos
composiciones anverso del formulario y reverso del formulario.
Luego se validara los campos de los arquetipos.
El campos se mestran en el arbol de arquetipos y luedo se visualiza en formato html
y archivos adl. Como lo muestra en la siguiente grafica: Gráfico N. 39 Archivo en formato HTML
Elaborado Por: Roberto Carlos González León
Fuente: Datos de la investigación
119
Presentacion de los campos que deben incluirse en el formulario según la NORMA
USO 13606, LinkEHR, nos ofrece también la posibilidad de una vista del arquetipo en
formato ADL, según se muestra en la siguiente gráfica. Gráfico N. 40 Archivo en formato ADL
Elaborado Por: Roberto Carlos González León
Fuente: Datos de la investigación
Gráfico N. 41 Diseño de Arquetipo Entry (Enfermedad Periodontal)
Elaborado Por: Roberto Carlos González León Fuente: Datos de la investigación
120
Gráfico N. 42 Vista de los campos en HTML
Elaborado Por: Roberto Carlos González León Fuente: Datos de la investigación
Gráfico N. 43 Diseño del arquetipo enfermedad perodental con todos los
campos del formulario 033
Elaborado Por: Roberto Carlos González León
Fuente: Datos de la investigación
121
Anexo 4 Impresión del formulario
Elaborado Por: Jorge Andrés Romero Franco. Fuente: Datos de la investigación
122
Anexo 5 Reuniones evidencias fotográficas
Reunión donde se realiza la presentación de los 20 formularios básicos del MSP para el proyecto de eSalud.
Elaborado Por: Roberto Carlos González León
Fuente: Datos de la investigación
Médicos de diferentes especialidades los cuales indican sus requerimientos
Elaborado Por: Roberto Carlos González León
Fuente: Datos de la investigación
123
Anexo 6 Reuniones de tutorías de formularios básicos del MSP
Reunion donde se revisa los avances y reliza correciones a la metodología.
Elaborado Por: Roberto Carlos González León Fuente: Datos de la investigación
124
Anexo 7 Levantamiento de información en consultorio dental.
Consultorio es atendido por dos o tres personas por paciente.
Elaborado Por: Roberto Carlos González León Fuente: Datos de la investigación
El especialista realiza el tratamiento previo al diagnóstico primera consulta.
Elaborado Por: Roberto Carlos González León
Fuente: Datos de la investigación
125
Examen complementario de rayos X ayudan a diagnosticar el cuadro médico de forma efectiva
Elaborado Por: Roberto Carlos González León Fuente: Datos de la investigación
Sistema actual no posee la sección del odontograma.
Elaborado Por: Roberto Carlos González León Fuente: Datos de la investigación
126
Sistema indica atención de especialidad de Pediatría- odontológica
Elaborado Por: Roberto Carlos González León Fuente: Datos de la investigación
Signos vitales se ingresan en el sistema en el área de enfermería o admisión o
consulta externa.
Elaborado Por: Roberto Carlos González León Fuente: Datos de la investigación
127
Anexo 8 Validación de Proyecto de Titulación
128
Anexo 9 Manual Técnico y Manual de Usuario
MANUAL TÉCNICO
129
Introducción
La elaboración del manual técnico servirá como guía para darle continuidad a futuros
requerimientos para el proyecto y puedan tener una facilidad de configuración para el
ambiente de desarrollo donde se va a trabajar.
Requerimientos del Hardware
Para la implementación y el desarrollo del sistema se cuenta con un servidor con las
características mínimas:
Procesador: Intel Core I3 o superior
Memoria RAM: 4 GB o Superior
Disco Duro 1 TB
Requerimientos del Software
A continuación, indicaremos los sistemas operativos que se pueden utilizar en la
implementación del proyecto.
Para instalación de la base de datos
Sistema Operativo: Windows 8 o superior.
Para instalar las herramientas de desarrollo
Sistema Operativo: Windows 8 o superior.
130
Herramientas de desarrollo
Se detalla a continuación las herramientas de desarrollo:
PostgreSQL
Java 8
Spring Framework
WildFly (JBoss)
Eclipse Neon
Instalación de java SDK
Para realizar una correcta instalación de Java se debe seguir los siguientes pasos:
1. Dirigirse al navegador de la pc o laptop en la cual se va a trabajar, luego
ingresar a la página oficial de Oracle para descargar java por medio del
siguiente link:
http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-
2133151.html
2. Se debe escoger la versión según el sistema operativo instalado en la maquina
física.
3. Una vez finalizado la descarga se da click en el icono que ejecuta el instalador
de java.
4. Se siguen los pasos que se muestran durante la instalación y se habrá
instalado java en la pc o laptop.
131
Gráfico N. 1 Instalación del java
Elaborado por: Jorge Romero
Fuente: Datos de la Investigación
Instalación de Eclipse Neón
Para instalar “Eclipse Luna” se deben seguir los siguientes pasos:
1. Dirigirse al navegador de la pc o laptop e ingresar a la página oficial de eclipse
para descargar java:
https://Eclipse.org/downloads/packages/Eclipse-ide-java-developers/neon1rc2
2. Escoger la versión según el sistema operativo.
132
Gráfico N. 2 Página Oficial de Eclipse
Elaborado por: Jorge Romero
Fuente: Datos de la Investigación
3. Una vez finalizada la descarga damos click en el icono que ejecuta el
instalador “Eclipse.exe”.
Gráfico N. 3 Carpeta contenedora de Eclipse
Elaborado por: Jorge Romero
Fuente: Datos de la Investigación
Configuramos la ruta donde deseamos que se guarden los proyectos que creamos y
se habrá instalado Eclipse en la pc.
133
Si al ejecutar Eclipse se levanta una ventana de error que nos dice lo siguiente:
A Java Runtime Environment (JRE) or Java Development Kit (JDK) must be available
in order to run Eclipse. No Java virtual machine was found after searching the following
locations: C: Users…Eclipsejrebinjavaw.exe javaw.exe in your current PATH.
Para que no se genere este error se procede a realizar el siguiente paso:
Nos dirigimos al buscador de nuestro sistema operativo.
Para el Sistema Operativo Windows 8 el buscador se encuentra ubicado en la
esquina superior derecha referenciado por una imagen de “lupa”. En el caso
de tener instalado Windows 7 o Vista, la opción se ubica en el botón inicio.
En S.O. XP se dirige directamente al “panel de control”.
Como segundo paso se procede a digitar en el buscador las palabras
“Variables de entorno”. Presionamos el recuadro de “Configuraciones”, y
elegimos la opción “Editar las variables de entorno del sistema”.
Gráfico N. 4 Buscador en Windows 8
Elaborado por: Jorge Romero Fuente: Datos de la Investigación
134
Gráfico N. 5 Buscador en Windows 10
Elaborado por: Jorge Romero
Fuente: Datos de la Investigación
Se abrirá un cuadro de diálogo en el escritorio que se llama “Propiedades del
sistema”, donde se dará click sobre el botón “Variables de entorno”. En la
nueva ventana se pulsará sobre el botón “Nueva variable del sistema” y se
procede a ingresar la siguiente información:
Nombre de la variable: JAVA_HOME.
Valor de la variable: Ruta de donde está instalado su JDK de java, por defecto
está en C: \Program Files\Java\jdk.
135
Gráfico N. 6 Ventanas de configuración para la variable de entorno
Elaborado por: Jorge Romero
Fuente: Datos de la Investigación
Volvemos a dar click en el icono del Eclipse y ya funciona:
Gráfico N. 7 Visualización de la pantalla de inicio Eclipse
Elaborado por: Jorge Romero
Fuente: Datos de la Investigación
136
Gráfico N. 8 Visualización del entorno de desarrollo
Elaborado por: Jorge Romero
Fuente: Datos de la Investigación
Instalación del Framework Spring
Para poder instalar el Framework Jsf se deben seguir los siguientes pasos:
1. Ejecutar el entorno de Desarrollo Eclipse.
2. Dar click en el menú help (ayuda).
3. Dentro del menú help, damos click en la opción Eclipse Marketplace
4. Se abrirá una ventana en la cual escribimos Jsf en el cuadro de texto Find y
damos click en el botón Go.
5. Nos aparecerá la opción para descargar el paquete de Spring tools, damos
click en el botón install.
6. Seguimos los pasos y se habrá instalado el framework spring en el entorno de
desarrollo Eclipse.
137
Gráfico N. 9 Eclipse Marketplace
Elaborado por: Jorge Romero
Fuente: Datos de la Investigación
Instalación del servidor de aplicaciones Wildfly
Para poder instalar el servidor de aplicaciones Wildfly, debemos proceder con los
siguientes pasos:
1. Ejecutar el entorno de desarrollo Eclipse
2. Dar click en el menú ayuda (Help).
3. Dentro del menú help, damos click en la opción Eclipse Marketplace
4. Se abrirá una ventana de diálogo, en la cual escribimos las palabras “jboos
tolos” en el cuadro de texto Find y damos click en el botón Go.
5. Nos aparecerá la opción para descargar el paquete de “jboss tolos”, damos
click en el botón install.
138
6. Luego nos vamos al menú Windows y damos click en la opción preference.
7. Aparecerá una ventana. Del lado izquierdo damos click en server/runtime
environment y damos click en la opción add.
8. Seleccionamos Wildfly como tipo de servidor a configurar, escogemos la ruta
donde queremos que se descargue y se configure el Wildfly.
9. Damos click en finish y se habrá configurado el servidor de aplicaciones.
Gráfico N. 10 Eclipse Marketplace Opción (JBOSS)
Elaborado por: Jorge Romero
Fuente: Datos de la Investigación
139
Gráfico N. 11 Ventana de configuración del Wildfly
Elaborado por: Jorge Romero
Fuente: Datos de la Investigación
Importar proyecto
Para importar el proyecto en Eclipse, se procede a realizar los siguientes pasos:
1. Damos click en el menú archivo, y seleccionamos la opción “importar”.
2. Se abre una ventana, damos click en la carpeta general, seleccionamos
Proyecto existente y damos click en el botón siguiente.
3. Damos click en el check que dice seleccionar archivo de almacenamiento y
damos click en el botón navegar.
4. En la ventana que aparece, buscamos la ruta donde se encuentra el archivo
del proyecto con la extensión .zip o .rar
5. Regresamos a la ventana anterior y damos click en finish.
140
Gráfico N. 12 Ventana para la importación de proyectos
Elaborado por: Jorge Romero
Fuente: Datos de la Investigación
Instalación PostgreSQL
Para instalar PostgreSQL, se deberán seguir los siguientes pasos:
1. Nos dirigimos a la siguiente página, para descargar la versión para nuestro
sistema operativo: http://www.enterprisedb.com/products-services-training/pgdownload#windows
141
Gráfico N. 13 Página oficial Descarga de PostgreSQL
Elaborado por: Jorge Romero
Fuente: Datos de la Investigación
2. Nos dirigimos a la carpeta que se descargó y ejecutamos el archivo setup.exe.
3. Aceptamos los términos y las licencias y damos click en siguiente.
4. Seleccionamos las características que deseamos instalar en PostgreSQL y
damos click en siguiente.
5. Configuramos los usuarios y contraseñas para los diferentes servicios que se
van a instalar de PostgreSQL y damos click en siguiente.
6. Seleccionamos el tipo de usuario con el cual nos autenticaremos al ejecutar el
SQL Server y damos click en siguiente.
7. Configuramos los servicios de reportes de PostgreSQL damos click en
siguiente.
8. Y se procederá a instalar el PostgreSQL
142
Gráfico N. 14 Entorno del pgAdmin III (PostgreSQL)
Elaborado por: Jorge Romero
Fuente: Datos de la Investigación
Importar una base de datos existente en PostgreSQL
Para poder importar una base de datos dentro de PostgreSQL, necesitamos realizar
los siguientes pasos: 1. Ejecutamos el PostgreSQL.
2. Damos click derecho en la carpeta base de datos y seleccionamos la opción
restaurar base de datos.
3. En la sección Origen, damos click en la opción Dispositivo.
4. Se abrirá una nueva ventana y damos click en el botón Agregar.
5. Seleccionamos el archivo .bak de la base de datos que deseamos restaurar y
damos click en Agregar.
6. Le podemos cambiar el nombre de la base de datos, damos click en Aceptar y la
base de datos se habrá restaurado.
143
Gráfico N. 15 Importación de Bases De Datos
Elaborado por: Jorge Romero
Fuente: Datos de la Investigación
Gráfico N. 16 Visualización de una base de datos ya importada
Elaborado por: Jorge Romero
Fuente: Datos de la Investigación
Base de datos
Importada
144
MANUAL DE USUARIO
145
Introducción
Este documento detalla toda la información de cómo utilizar la aplicación. El proyecto
se desarrolló en conjunto con la guía de los profesionales de Promeinfo. Este
desarrollo permite al médico especialista perito en el cargo de odontólogo registrar en
el formulario 033-Odontología todos los diagnósticos que cada paciente pueda
presentar por cada cita que se realiza.
Objetivos
El objetivo de este manual es guiar al odontólogo en el funcionamiento del formulario
033-Odontología para que sus tareas realizadas a diario sean llevadas con un mejor
control y una mejor atención para los pacientes.
Ingreso a aplicación
Para ingresar al aplicativo se debe abrir un navegador de preferencia Google Chrome,
Mozilla Firefox, Opera e ir a la siguiente dirección: http://127.0.0.1:9997/sistema-medico-ug/
Aparecerá la siguiente pantalla de inicio de sesión:
Donde habrán dos roles de usuario:
Admin(Odontólogo)
Paciente
146
Gráfico Nº 1: Inicio de Sesión
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación
El odontólogo podrá ingresar al sistema digitando su usuario y clave correspondiente.
Módulo consulta
Gráfico Nº 2 : Módulo de Consulta de Paciente
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación
El odontólogo podrá consultar los pacientes que se encuentren registrados por medio
de la identificación o el nombre:
147
Gráfico Nº 3: Identificación
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación
Gráfico Nº 4: Nombre
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación
Al presionar la tecla “Enter” nos mostrará los datos del paciente en un cuadro al lado
derecho de la consulta:
148
Gráfico Nº 5: Verificación de Datos
Elaborado Por: Jorge Andrés Romero Franco. Fuente: Datos de la Investigación
El odontólogo se dirigirá hacia la parte superior izquierda donde se dará click en el
botón y escogerá la opción ingreso: Gráfico Nº 6: Opción de Ingreso
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación
149
Al dar click sobre la opción Ingreso se mostrará el formulario para proceder con la
consulta: Gráfico Nº 7: Formulario de Odontología Parte 1
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación
Gráfico Nº 8: Formulario de Odontología Parte 2
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación
150
Gráfico Nº 9: Formulario de Odontología Parte 3
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación El sistema contará con las siguientes secciones:
Gráfico Nº 10: Cabecera del formulario
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación
Estará compuesta por los siguientes campos:
Establecimiento
Nombre
Apellido
Sexo
Edad
Nº Historia Clínica
Una vez realizada la consulta al paciente, sus datos vendrán precargados en esta
cabecera antes mencionada.
151
Gráfico Nº 11: Motivo y Enfermedades
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación
En estas secciones el odontólogo podrá ingresar el motivo por el cual ingreso el
paciente por primera vez, este campo no será modificable y en la enfermedad o
problema actual se registra si tiene alguna complicación.
Gráfico Nº 12: Antecedentes y Signos Vitales
Elaborado Por: Jorge Andrés Romero Franco. Fuente: Datos de la Investigación
En la sección de antecedentes familiares, se debe marcar con “X” en el cuadro
amarillo el tipo de antecedente personal que tiene el paciente, si es familiar indicará
que familiar tiene el antecedente hasta tercer grado consanguinidad y primer grado
de afinidad; en el campo textual y en la parte de signos vitales tenemos 4 campos
donde el auxiliar del odontólogo o la enfermera deberán ingresar y llenar los datos, y
si tiene alguna observación tiene un campo al final donde puede prescribir alguna
complicación que evite que el paciente pueda ser atendido.
152
Gráfico Nº 13: Exámenes del Sistema Estomatognático
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación
Esta sección consta de doce campos, en las cuales se debe marcar “x” solamente si
existe patología y describir en la parte inferior en el campo textual.
Gráfico Nº 14: Odontograma
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación
Esta sección del formulario tiene como objetivo llevar un control del estado actual de
las piezas dentales del paciente, se encuentran dividas en 32 campos de piezas
dentales además 64 campos para recesión (32) y movilidad (32) y 20 piezas dentales
temporales denominadas dientes de leche.
El odontólogo al presionar una de las piezas dentales, se mostrará una pantalla
flotante:
153
Gráfico Nº 15: Presionar Objeto de Pieza Dental
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación
Gráfico Nº 16:
Pantalla Flotante de la Pieza Dental
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación
En esta opción se podrá escoger que tipo de diagnóstico se llevó a cabo de la pieza
dental para indicar si se realizó una acción o queda registrado para tratar la pieza en
la siguiente cita.
154
Gráfico Nº 17: Indicador de Salud Bucal
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación.
En esta sección se podrá indicar un diagnóstico general de la cavidad bucal donde el
odontólogo podrá seleccionar con una check las que piezas dentales afectadas e
indicar el nivel de enfermedad periodontal, la mal oclusión y Fluorosis de las piezas
dentales.
Gráfico Nº 18: Índices CPO-ceo
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación.
En esta sección los Índices CPO (CARIES-PÉRDIDAS Y OBTURADAS) y ceo
(CARIES EXTRAIDAS Y OBTURADAS) se definen de la siguiente manera:
155
Dentición definitiva se registra en el cuadro con la (D) mayúscula y solo para
las piezas definitivas.
Dentición temporal se registra en el cuadro con la (d) minúscula y solo para
las piezas temporales.
Gráfico Nº 19: Planes de Diagnostico, Terapéutico y Educacional
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación.
En esta sección se va a indicar con una “x” el tipo de examen complementario, que
consta de cuatro campos:
5. Biometría
6. Química sanguínea
7. Rayos - x
8. Otros
Anotar los exámenes complementarios solicitados para definir o ampliar el
criterio diagnóstico
Anotar la concentración, presentación, vía, dosis unitaria, frecuencia y días
que se administrará el medicamento prescrito
Anotar las indicaciones para prevención de complicaciones y cumplimiento del
tratamiento.
156
Gráfico Nº 20: Diagnóstico
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación.
En esta sección se marca con “x” si se trata de un diagnóstico presuntivo en
el campo de la columna PRE o definitivo en el campo de la columna DEF del
paciente.
Escribir el código asignado a la enfermedad de acuerdo a la clasificación
internacional de enfermedades aplicada a odontología en el campo de la
columna CIE.
Gráfico Nº 21: Tratamiento
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación.
En el botón de la esquina superior derecha de esta sección, el odontólogo dará
click y se le presentará una pantalla emergente donde estará compuesto de la
siguiente manera:
Esta sección va a estar compuesta de 5 subsecciones donde el odontólogo detalla el
diagnóstico previo y el tratamiento que realizará el paciente:
Sesión y fecha: Registrar el número de orden de la sesión correspondiente,
la fecha.
157
Diagnósticos y complicaciones: Describir la evolución de la enfermedad y
progreso del tratamiento. Nuevos datos del examen odontológico y del
resultado de exámenes de diagnóstico.
Procedimientos: Registrar las actividades e intervenciones preventivas y
curativas realizadas.
Prescripciones: Anotar el nombre de los medicamentos e insumos prescritos.
Código y firma: Registrar el nombre y código del profesional y la firma.
Una vez finalizado la consulta e ingresados todos los registros, se dará click en el
botón y se le mostrará una alerta en la esquina superior derecha de guardado exitoso. El paciente también podrá ingresar al sistema, pero solo tendrá la opción de visualizar
el formulario y podrá imprimirlo de ser necesario:
Gráfico Nº 22: Visualización del Formulario por el paciente
Elaborado Por: Jorge Andrés Romero Franco.
Fuente: Datos de la Investigación.
